Brute-Force Protection with CSF — How iWebVault Blocks Attackers

Every iWebVault server runs CSF (ConfigServer Security & Firewall) — the firewall that watches for attack patterns and automatically blocks malicious IPs before they can do damage. CSF runs at the kernel level, sitting between the open internet and every service on the server. You typically never see it working. The exception is when you accidentally trip it yourself by entering your own password wrong too many times. This guide explains how CSF protects you and what to do if you ever lock yourself out.

What CSF blocks

• Repeated failed logins. 5+ failed attempts on SSH, FTP, cPanel, webmail, or POP3/IMAP triggers a temporary or permanent block.
• Port scans. IPs probing closed ports get blocked instantly.
• Known-bad IPs. CSF imports blocklists of confirmed attackers from multiple intelligence feeds. These IPs never reach your services.
• SYN flood / DDoS patterns. Rate-limiting at the kernel level.
• Suspicious process activity. CSF’s LFD (Login Failure Daemon) watches processes too — unusual patterns trigger alerts and bans.

How blocks work

Two types:

• Temporary block — usually 5-30 minutes. For an IP that triggered a soft threshold. Self-clears.
• Permanent block — added to the deny list indefinitely. For repeat offenders, known-bad sources, or higher-severity triggers (port scans).

When you’re blocked, every connection attempt from your IP — to cPanel, webmail, SSH, anywhere — gets refused at the firewall before your service even sees it. From your browser, this looks like a connection timeout or “site can’t be reached”.

“I think I’m blocked — what do I do?”

Symptoms:

• cPanel suddenly stops loading (connection timeout, not “wrong password”).
• Your website loads, but cPanel/webmail/SSH don’t.
• SSH connection just hangs or “Connection refused”.
• From a different network (mobile data, friend’s wifi) everything works fine.

The “different network works” test is the telltale sign — service is up, your IP specifically is blocked.

Unblocking your own IP

Method 1: Find your IP and request unblock

1. Visit whatismyipaddress.com from the affected network — note your public IP.
2. Open a support ticket from any device that’s NOT blocked (mobile data, different computer).
3. Subject: “CSF IP unblock request”. Include the IP you found in step 1.
4. We unblock typically within minutes of seeing the ticket. Auto-clear of temporary blocks happens regardless.

Method 2: Wait it out (temporary blocks only)

If you suspect a temporary block (you mistyped your password 5-6 times), wait 30 minutes and try again. Most temporary blocks have cleared by then.

Method 3: Use a different IP

Switching to mobile data, a VPN, or a different network gives you a different public IP — unblocked by definition. Useful for emergencies but doesn’t fix the underlying block; address it via Method 1.

Preventing self-blocks

• Use a password manager. Eliminates typo-driven failed logins. Single biggest fix.
• Set up SSH keys. SSH password attempts are the most common cause of CSF blocks. SSH key guide.
• Verify password resets immediately. If you reset a password, log in once to confirm it works — don’t accidentally try the old password 5 times later.
• Configure email clients carefully. Outlook/Apple Mail with wrong settings can rapidly trigger blocks by retrying failed logins on a loop. Fix your settings before letting the client retry indefinitely.
• Whitelist your static IP if you have one. Open a ticket requesting CSF whitelist for your IP — we add it to the permanent allow list so accidental triggers don’t block you.

CSF logs you can request

If you ever want to see what attacks have been blocked against your account specifically (curiosity, security audit, demonstrating to a regulator), we can pull a CSF summary on request. Open a support ticket; we can generate a 7-day or 30-day attack summary showing blocked attempts by source country, target service, and frequency. Useful sometimes for compliance reporting; usually mostly interesting.

CSF for VPS customers

If you have a managed VPS from iWebVault with cPanel, CSF is pre-installed and managed for you. For self-managed VPS, CSF is something you should install yourself. Basic install:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Then disable Testing Mode in /etc/csf/csf.conf (set TESTING = "0") and restart: csf -r.

Sane defaults out of the box. The settings worth reviewing:

• LF_DENY_SMTP_AUTH — failed SMTP auth threshold (default 10).
• LF_SSHD — failed SSH attempts before ban (default 5).
• LF_SMTPAUTH — failed SMTP auth attempts (default 10).
• DENY_IP_LIMIT — max IPs in deny list (default 200; raise to 10000 if you want long-term blocks).
• DROP_OUT_LOGGING — whether to log outbound dropped packets (off by default; turn on briefly for debugging).

The other layers

CSF is one of several security layers on iWebVault. The others:

• Imunify360 — malware detection and WAF. Customer guide.
• ConfigServer Exploit Scanner — separate malware scanner.
• CPGuard — cPanel-specific exploit detection.
• cPHulk — cPanel’s built-in brute-force protection (works alongside CSF).

Different layers catch different attacks. CSF is the kernel-level firewall; Imunify360 is the application-level WAF and malware scanner. Both running together is defense in depth.

Common CSF questions

“My team can’t access cPanel anymore after working from a new office.” The shared office IP got blocked — typically from someone else’s brute-force attempt that wasn’t actually theirs. Ticket to unblock; consider whitelisting the office IP permanently.

“Why am I blocked when I just changed my password?” The old password is still in your mail client, file manager, or autocomplete. After password change, update all those tools immediately or they’ll retry the old password and trigger the block.

“My VPN IP keeps getting blocked.” Shared VPN IPs are often used by attackers as well as legitimate users. CSF blocks one bad actor on the IP, you (sharing the IP) get caught in the block. Either use a private/dedicated VPN IP, or whitelist your specific VPN IP if you control it.

“How long do permanent blocks stay?” Indefinitely, until manually cleared. Permanent blocks are reserved for confirmed-bad sources; legitimate customer IPs caught accidentally are cleared promptly when reported.

What’s next

• Eliminate password-based login: SSH key authentication.
• If you’ve been compromised: Malware cleanup guide.
• Imunify360 detections: Imunify360 customer guide.

CSF works silently in the background protecting every iWebVault server. The most you’ll usually notice it is when you’ve blocked yourself — and even then, a 30-second support ticket gets you back in. Worth orders of magnitude more than the rare inconvenience.