Managing server security on a Webmin-powered Linux server requires more than just keeping software updated. Without a properly configured firewall, your server is exposed to brute force attacks, port scans, and unauthorized access attempts around the clock. ConfigServer Security & Firewall (CSF) is the industry-standard firewall solution for Webmin environments — and setting it up correctly can mean the difference between a secure hosting infrastructure and a compromised server.
This guide walks you through the complete Webmin CSF firewall setup process: from installation and initial configuration to advanced rate limiting, monitoring, and troubleshooting common issues that hosting companies run into every day.
Understanding CSF Firewall Architecture in Webmin
CSF (ConfigServer Security & Firewall) is a stateful packet inspection (SPI) firewall built on top of iptables/nftables. Unlike a basic firewall script, CSF includes Login Failure Daemon (LFD), which monitors log files for authentication failures and automatically blocks offending IPs — similar to Fail2Ban but tightly integrated with cPanel, Webmin, and WHM panels.
For web hosting companies running Webmin, CSF offers several critical advantages:
- Webmin UI integration — manage all firewall rules from within the Webmin interface without touching the command line
- LFD integration — automatic IP blocking on SSH, FTP, SMTP, and web panel brute force attempts
- Port flood protection — rate limiting to stop SYN floods and connection abuse
- Process tracking — detect and alert on suspicious processes that may indicate compromise
- Email alerting — real-time notifications when IPs are blocked or system events trigger
CSF operates in two modes: Testing Mode (firewall rules applied but not yet permanent — the firewall auto-disables itself after 5 minutes to prevent lockouts) and Live Mode (rules are permanent). Always start in Testing Mode when first configuring CSF on a production server.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Installing CSF on Your Webmin Server
Before installing CSF, ensure your server meets the prerequisites. CSF works on CentOS, AlmaLinux, Rocky Linux, Ubuntu, and Debian-based systems running Webmin.
CSF requires iptables and specific kernel modules. Verify they're available:
modprobe ip_tables
modprobe iptable_filter
lsmod | grep ip_tables
cd /tmp
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh
perl /usr/local/csf/bin/csftest.pl
This script checks for all required Perl modules. Any failures listed as REQUIRED must be resolved before CSF will function correctly. Install missing modules via your distribution's package manager (cpan, apt, or yum).
After installation, open Webmin and navigate to Webmin → Webmin Modules → Install Module. The CSF module is bundled with the installation and should appear automatically under Others → ConfigServer Security & Firewall. If it doesn't appear, refresh the Webmin modules list.
In csf.conf, confirm TESTING = "1" — this prevents permanent lockout while you configure rules.
Adjust TCP_IN to match your server's services. A typical web hosting server needs:
TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2222,10000"
Port breakdown: 20-21 (FTP), 22 (SSH — change if using non-standard port), 25/465/587 (SMTP), 53 (DNS), 80/443 (HTTP/HTTPS), 110/143/993/995 (POP3/IMAP), 2222 (alternative SSH), 10000 (Webmin).
TCP_OUT = "20,21,22,25,43,53,80,110,113,443,587,993,995"
Port 43 is required for WHOIS lookups; port 113 (ident) prevents SMTP delays on some mail servers.
LFD_TRIGGER determines how many failures before an IP is blocked. For hosting servers:
LT_SSH = "5" # Block after 5 failed SSH attempts
LT_FTP = "10" # Block after 10 failed FTP attempts
LT_SMTP = "10" # Block after 10 failed SMTP attempts
LT_POP3 = "10" # Block after 10 failed POP3 attempts
Add your office/management IP addresses to /etc/csf/csf.allow:
echo "YOUR.OFFICE.IP.HERE # Management IP" >> /etc/csf/csf.allow
This is critical — failing to whitelist your IP before disabling Testing Mode can lock you out of your own server.
Advanced CSF Features: Rate Limiting, DDoS Protection, and Process Tracking
For hosting companies managing multi-tenant servers, CSF's advanced features provide protection that basic firewalls can't match.
Connection Rate Limiting (CONNLIMIT)
Prevent any single IP from opening too many simultaneous connections to a service:
CONNLIMIT = "22;5,80;50,443;50"
This limits SSH to 5 simultaneous connections per IP, and HTTP/HTTPS to 50. Adjust based on your legitimate traffic patterns.
Port Flood Protection (PORTFLOOD)
Block IPs that make too many connection attempts in a short time window:
PORTFLOOD = "80;tcp;20;5,443;tcp;20;5"
This blocks any IP making more than 20 TCP connections to port 80 or 443 within 5 seconds — effective against basic HTTP flood attacks.
Syn Flood Protection
SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"
Process Tracking (PT_USERPROC)
LFD can monitor running processes and alert when a user's processes exceed thresholds — useful for detecting runaway scripts or malicious activity:
PT_USERPROC = "10" # Alert if user runs more than 10 processes
PT_USERMEM = "200" # Alert if user process uses more than 200MB
PT_USERTIME = "1800" # Alert if process runs longer than 30 minutes
Directory Watching (PT_DELETED)
Enable this to detect deleted files that are still being executed — a common indicator of rootkit activity:
PT_DELETED = "1"
Monitoring, Alerting, and Managing CSF Blocks in Webmin
Once CSF is live, monitoring blocked IPs and responding to false positives is part of daily server management. The Webmin CSF module makes this straightforward.
Viewing blocked IPs
Navigate to Others → ConfigServer Security & Firewall → Temporary IP Bans in Webmin to see all currently blocked IPs with timestamps and reasons. You can unblock IPs directly from this interface.
From the command line:
csf -l # List all current iptables rules
csf -t # Show temporary IP bans
csf -tr 1.2.3.4 # Remove specific IP from temporary ban
Permanently allow or deny IPs
csf -a 1.2.3.4 "Trusted monitoring server" # Add to permanent allow
csf -d 1.2.3.4 "Known attacker" # Add to permanent deny
Email alerting configuration
Set LF_ALERT_TO in csf.conf to receive email notifications for blocks, process alerts, and security events:
LF_ALERT_TO = "[email protected]"
LF_ALERT_FROM = "[email protected]"
Checking LFD logs
tail -f /var/log/lfd.log
Common troubleshooting scenarios:
- Legitimate user blocked — Check
/var/log/lfd.logto see why they were blocked, then add their IP tocsf.allow - CSF blocking your own monitoring server — Add monitoring server IPs to
/etc/csf/csf.ignoreto prevent LFD from tracking its connection attempts - Port not accessible after CSF install — Run
csf -l | grep PORT_NUMBERto check if rules exist; add port toTCP_INif missing - LFD not starting — Check
systemctl status lfdand verify all Perl modules are installed viaperl /usr/local/csf/bin/csftest.pl
Going Live: Disabling Testing Mode and Final Checks
Before disabling Testing Mode, run through this checklist:
- Your management/office IP is in
/etc/csf/csf.allow - All required ports for your services are in
TCP_INandTCP_OUT - LFD thresholds are tuned to avoid blocking legitimate users
- Alert email is configured and tested
- You have console/IPMI access as a backup in case of lockout
When ready, disable Testing Mode:
csf -x # Disable Testing Mode
csf -e # Enable CSF in live mode
csf -r # Restart CSF with new configuration
Or from the Webmin interface: navigate to ConfigServer Security & Firewall → Firewall Configuration, set TESTING to Off, and click Save Settings, then Restart CSF+LFD.
Verify the firewall is active:
csf -l | head -30
systemctl status csf lfd
FAQs
Q: Can I run CSF alongside Fail2Ban on a Webmin server?
A: Yes, but it requires careful configuration to avoid conflicts. Both tools modify iptables rules, and both monitor log files for authentication failures. If running both, configure them to monitor different services — or disable Fail2Ban's SSH monitoring and let LFD handle it exclusively to avoid duplicate bans and rule conflicts.
Q: Why is CSF in Testing Mode auto-disabling itself every 5 minutes?
A: This is by design — Testing Mode disables the firewall every 5 minutes to prevent permanent lockout while you're configuring rules. This is not a bug. Once you've verified your configuration and whitelisted your management IPs, disable Testing Mode to make rules permanent.
Q: How do I update CSF to the latest version?
A: Run the built-in update command: csf -u. This downloads and applies the latest CSF version without losing your configuration. Check your current version with csf -v.
Q: What ports should I open for a server running Webmin only (no mail server)?
A: A minimal Webmin-only server needs: 22 (SSH), 80 (HTTP), 443 (HTTPS), 10000 (Webmin). If using Virtualmin, also add 20000 (Usermin). Remove 25, 110, 143, and all mail ports if your server doesn't handle email.
Q: CSF is blocking a legitimate IP that connects frequently — how do I whitelist it without disabling protection?
A: Add the IP to /etc/csf/csf.ignore (not csf.allow). The csf.ignore file tells LFD to ignore connection attempts from that IP when counting failures, without adding a permanent allow rule to the firewall. This means the IP is still subject to firewall rules but won't be auto-blocked by LFD for connection frequency.
Managing a Webmin server securely is an ongoing effort. If your team is spending too much time responding to attacks, blocked IPs, and security incidents instead of growing your business, CloudHouse's server hardening service can take that burden off your plate — with 24/7 monitoring, proactive CSF tuning, and expert response to security events.
