CSF Post-Shutdown Survival Guide: Migration & Configuration

 

For over a decade, ConfigServer Security & Firewall (CSF) was the undisputed firewall solution for cPanel/WHM servers. If you ran a shared hosting environment, a reseller setup, or even a standalone VPS with cPanel, CSF was almost certainly part of your security stack. Its WHM integration, Login Failure Daemon (LFD), and straightforward configuration made it the default choice for system administrators who needed robust firewall management without wrestling with raw iptables rules.

Then ConfigServer pulled the plug.

Way to the Web Ltd (W2W/ConfigServer) permanently shut down on August 31, 2025, ending all support and distribution. Their update servers at download.configserver.com went offline, leaving every CSF installation pointing at a dead endpoint. The good news? cPanel has stepped in with an official fork, and several community forks have emerged to keep CSF alive. The less good news? If you’re not on cPanel, or if you’re looking at the long-term trajectory of iptables-based firewalling on modern Linux, you may still want a migration plan.

This guide covers everything: the cPanel fork and how to leverage it, community fork options for non-cPanel servers, and full migration paths to alternative firewall stacks for those who want to move on entirely.

The State of Play: What the CSF Shutdown Actually Means

Let’s be clear about what happened and what’s changed since. Way to the Web Ltd closed its doors on August 31, 2025, ending all development, support, and distribution of ConfigServer products. Before shutting down, W2W released the CSF source code “as-is” under the GNU General Public License v3 (GPLv3), which opened the door for forks.

Your existing CSF installation didn’t self-destruct on that date. The iptables rules CSF wrote are still active, LFD is still watching your logs, and your csf.conf is still being read. But the original update servers at download.configserver.com are offline, which means:

• Auto-updates are broken — CSF’s LFD cronjob tries to check for updates daily. With the servers gone, those checks spam your root inbox with connection errors.
• Security patches stopped — No new fixes for vulnerabilities discovered in CSF itself.
• Domain risk — The configserver.com domain could theoretically be acquired by a malicious actor and used to serve trojaned “updates” to any server still pinging it with auto-update enabled.
• nftables gap — CSF was built around iptables. The Linux world is moving to nftables as the default, and CSF’s nftables compatibility was never fully realized before the shutdown.

The most critical immediate action for any CSF installation is to either point to a maintained fork or disable the broken auto-update mechanism.

Option 0: The cPanel Fork (For cPanel/WHM Servers)

If you’re running CSF on a cPanel/WHM server, this is the path of least resistance, and it’s the officially supported one.

What cPanel Is Doing

cPanel announced in January 2026 that they will maintain a public fork of CSF focused on critical security and stability fixes. Here’s what you need to know:

• The fork is based on the final upstream release from W2W.
• It will be published in cPanel & WHM’s public GitHub repository under GPLv3 (consistent with the original license).
• The scope is maintenance only — security patches and stability fixes. Don’t expect new features or major development. cPanel has no incentive to do heavy R&D on GPL code that competitors can freely use.
• Updates will be distributed through the same auto-update mechanism the original CSF used.

The February 18, 2026 Auto-Update

On February 18, 2026, cPanel will automatically update the CSF configuration on eligible servers to point to cPanel’s update mirrors instead of the dead W2W source. This happens automatically if all of the following are true:

• Your server is using cPanel & WHM with the original CSF plugin.
• CSF is configured to use the original ConfigServer/W2W update source.
• Your server is running CSF version 14.0 or newer.
• The AUTO_UPDATES setting is enabled.

What it changes: Only the update source URL. Your firewall rules, configuration, whitelists, and blacklists are untouched.

What it does NOT change if any of these are true:

• Your server already uses an alternate CSF provider (community fork).
• Your server is running CSF version 13.x or older.
• The AUTO_UPDATES setting is disabled.

If You Want to Opt Out

If you prefer to manage CSF updates manually or use a different fork:

# Via WHM:
# Navigate to ConfigServer Security & Firewall
# Select csf - ConfigServer Firewall
# Open Firewall Configuration
# Under Initial Settings, set AUTO_UPDATES to off
# Save your changes

# Or via command line:
sed -i 's/^AUTO_UPDATES = "1"/AUTO_UPDATES = "0"/' /etc/csf/csf.conf
csf -ra

Disable AUTO_UPDATES before February 18, 2026 to prevent the automatic source change.

If You Want to Opt In Later

If you initially opt out but later want to receive updates from the cPanel fork:

/scripts/autorepair cpanel_csf_install

Then re-enable AUTO_UPDATES in your csf.conf.

The Bottom Line on the cPanel Fork

For cPanel/WHM servers, this is the recommended path. It preserves your existing WHM integration, requires zero migration effort, and gives you a maintained update channel backed by a company that has a direct interest in keeping its ecosystem secure. The downside is that it’s maintenance-mode only — don’t expect innovation, nftables support, or new detection capabilities.

Option 0.5: Community Forks (For Non-cPanel Servers)

If you’re running CSF on a DirectAdmin, CyberPanel, Webmin, or standalone server without cPanel, the cPanel fork isn’t your path. Several community forks have stepped up:

Aetherinox/csf-firewall (ConfigServer.dev)

This is the most actively developed community fork. Key highlights:

• Active development with both bug fixes and new functionality planned.
• Includes iptables/nftables support.
• Provides its own maintained blocklist and IPSET service, updated every 12 hours.
• Comprehensive documentation at https://aetherinox.github.io/csf-firewall/.
• Licensed under GPLv3.

# Installation (manual)
cd /usr/src
wget https://github.com/Aetherinox/csf-firewall/archive/refs/heads/main.tar.gz -O csf-aetherinox.tar.gz
tar xzf csf-aetherinox.tar.gz
cd csf-firewall-main
sh install.sh

Black-HOST/csf

Another community-maintained fork that continues the legacy of the original W2W codebase:

• Focused on keeping CSF secure and compatible with modern systems.
• Provides migration instructions from the original v14/v15.00.
• Licensed under GPLv3.

To migrate from the original CSF to this fork, you update your download server configuration in csf.conf and let the auto-update cron handle the rest.

Sentinel Firewall

A CSF fork maintained by the OpenPanel team. Worth evaluating if you’re in the OpenPanel/CyberPanel ecosystem.

Which Community Fork to Choose?

For non-cPanel servers, the Aetherinox fork at ConfigServer.dev appears to be the most comprehensive option with the broadest development ambitions, including nftables work. However, treat any community fork with the same scrutiny you would any critical security component — review the code, monitor the repository activity, and don’t blindly auto-update.

Immediate Action: Disable Broken Auto-Updates (If You Haven’t Already)

Regardless of which path you choose, do this right now if your CSF is still pointing at the dead W2W servers:

# Check your current update source
grep "^URLGET" /etc/csf/csf.conf
grep "^AUTO_UPDATES" /etc/csf/csf.conf

# Disable auto-updates to stop the error spam and security risk
sed -i 's/^AUTO_UPDATES = "1"/AUTO_UPDATES = "0"/' /etc/csf/csf.conf
csf -ra

# Verify the change
grep "^AUTO_UPDATES" /etc/csf/csf.conf

This stops the daily cron errors and eliminates the risk of a compromised configserver.com domain serving malicious updates. You can re-enable auto-updates after pointing to a maintained fork.

The Case for Migrating Away from CSF Entirely

Even with forks available, there are legitimate reasons to consider a full migration:

• nftables is the future. CSF was built around iptables. Modern distributions (AlmaLinux 9, Ubuntu 24.04, Debian 12+) use nftables by default with an iptables-nft compatibility layer that introduces subtle behavioral differences. Community forks are working on nftables support, but it’s not fully there yet.
• Dependency on a single maintainer. The cPanel fork is maintenance-only. Community forks depend on individual contributors. Distribution-native tools like firewalld and fail2ban have larger contributor bases and are actively developed.
• Technical debt. If you’re planning an OS migration (e.g., CentOS 7 to AlmaLinux 9), it’s a natural breakpoint to modernize your firewall stack at the same time.

If any of that resonates, read on for the full migration paths.

Before You Migrate: Audit Your CSF Configuration

Before ripping CSF out, document exactly what it’s doing. CSF accumulates configuration over years, and sysadmins tend to forget half of what they’ve tweaked. Run a full audit first.

Export Your Current Ruleset

# Dump the active iptables rules CSF manages
iptables-save > /root/csf-migration/iptables-backup.rules
ip6tables-save > /root/csf-migration/ip6tables-backup.rules

# Copy the full CSF config directory
cp -a /etc/csf /root/csf-migration/csf-config-backup

# Grab the key config files specifically
cp /etc/csf/csf.conf /root/csf-migration/
cp /etc/csf/csf.allow /root/csf-migration/
cp /etc/csf/csf.deny /root/csf-migration/
cp /etc/csf/csf.ignore /root/csf-migration/
cp /etc/csf/csf.pignore /root/csf-migration/
cp /etc/csf/csf.blocklists /root/csf-migration/

Document Your Open Ports

CSF’s port configuration lives in csf.conf. Extract the critical values:

grep -E "^(TCP_IN|TCP_OUT|UDP_IN|UDP_OUT|TCP6_IN|TCP6_OUT|UDP6_IN|UDP6_OUT)" /etc/csf/csf.conf

A typical cPanel server looks something like this:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,37,43,53,80,110,113,443,587,993,995,2086,2087,2089,2703"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Write this down. This becomes your baseline for whatever firewall you migrate to.

Catalog LFD Triggers

LFD is the part people forget. It’s not just a firewall — it’s an active intrusion prevention system. Check what LFD is actually catching:

# Review recent LFD actions
grep "LFD" /var/log/lfd.log | tail -100

# Check your process tracking settings
grep -E "^(PT_|LF_|CT_)" /etc/csf/csf.conf | grep -v "^#"

# Export your permanent blocks
wc -l /etc/csf/csf.deny
cat /etc/csf/csf.deny | head -50

Pay particular attention to:

• LF_SSHD — SSH brute force threshold
• LF_FTPD — FTP brute force threshold
• LF_SMTPAUTH — SMTP authentication failure threshold
• LF_POP3D / LF_IMAPD — Mail service thresholds
• LF_CPANEL — cPanel login failure threshold
• CT_LIMIT — Connection tracking limit
• PT_LIMIT — Process time limit

These settings need equivalents in your new setup.

Migration Path 1: firewalld + fail2ban (Recommended for RHEL-Based Servers)

For those choosing to migrate away from CSF entirely.

If you’re on AlmaLinux 8/9, Rocky Linux, or CloudLinux, firewalld is already installed and waiting. Combined with fail2ban for intrusion prevention, this is the most natural successor to CSF on RHEL-derived systems.

Why This Combination Works

firewalld handles the packet filtering with zone-based management and native nftables support. fail2ban monitors logs and dynamically blocks offenders — the same role LFD played. Together, they replicate 90% of CSF’s functionality with tools that are actively maintained and distribution-native.

Step 1: Install and Configure firewalld

# Ensure firewalld is installed
dnf install firewalld -y

# Don't start it yet — configure first
systemctl enable firewalld

Create a cPanel-specific zone configuration. This is cleaner than dumping everything into the default public zone:

# Create a custom zone for cPanel services
firewall-cmd --permanent --new-zone=cpanel-server

# Add your TCP ports (matching your CSF TCP_IN)
firewall-cmd --permanent --zone=cpanel-server --add-port=22/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=25/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=53/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=80/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=110/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=143/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=443/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=465/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=587/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=993/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=995/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2077/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2078/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2082/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2083/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2086/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2087/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2095/tcp
firewall-cmd --permanent --zone=cpanel-server --add-port=2096/tcp

# Add UDP ports
firewall-cmd --permanent --zone=cpanel-server --add-port=53/udp

# FTP passive range (check your pure-ftpd or proftpd config)
firewall-cmd --permanent --zone=cpanel-server --add-port=49152-65534/tcp

# Assign your main interface to this zone
firewall-cmd --permanent --zone=cpanel-server --change-interface=eth0

# Set as default
firewall-cmd --permanent --set-default-zone=cpanel-server

Step 2: Migrate Your Whitelist/Blacklist

Convert CSF’s allow and deny lists to firewalld rich rules:

#!/bin/bash
# migrate-csf-lists.sh
# Migrate csf.allow to firewalld whitelist

while IFS= read -r line; do
    # Skip comments and empty lines
    [[ "$line" =~ ^#.*$ || -z "$line" ]] && continue
    # Extract IP (CSF format: IP # comment)
    ip=$(echo "$line" | awk '{print $1}')
    [ -z "$ip" ] && continue
    echo "Whitelisting: $ip"
    firewall-cmd --permanent --zone=cpanel-server --add-rich-rule="rule family='ipv4' source address='$ip' accept"
done < /root/csf-migration/csf.allow

# Migrate csf.deny to firewalld blacklist
while IFS= read -r line; do
    [[ "$line" =~ ^#.*$ || -z "$line" ]] && continue
    ip=$(echo "$line" | awk '{print $1}')
    [ -z "$ip" ] && continue
    echo "Blacklisting: $ip"
    firewall-cmd --permanent --zone=cpanel-server --add-rich-rule="rule family='ipv4' source address='$ip' drop"
done < /root/csf-migration/csf.deny

Important caveat: If your csf.deny has thousands of entries, firewalld rich rules aren’t efficient for that scale. Use ipset instead:

# Create an ipset for bulk blocks
firewall-cmd --permanent --new-ipset=csf-blocklist --type=hash:net

# Populate from csf.deny
while IFS= read -r line; do
    [[ "$line" =~ ^#.*$ || -z "$line" ]] && continue
    ip=$(echo "$line" | awk '{print $1}')
    [ -z "$ip" ] && continue
    firewall-cmd --permanent --ipset=csf-blocklist --add-entry="$ip"
done < /root/csf-migration/csf.deny

# Apply the ipset as a drop source
firewall-cmd --permanent --zone=cpanel-server --add-rich-rule="rule source ipset='csf-blocklist' drop"

Step 3: Install and Configure fail2ban

dnf install fail2ban fail2ban-firewalld -y

Create /etc/fail2ban/jail.local to replicate LFD behavior:

[DEFAULT]
# Use firewalld for banning
banaction = firewallcmd-rich-rules[actiontype=<rich-rule>]
banaction_allports = firewallcmd-rich-rules[actiontype=<rich-rule>]

# Default ban settings — adjust to match your CSF thresholds
bantime  = 3600
findtime = 600
maxretry = 5

# Ignore your trusted IPs
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP.HERE

[sshd]
enabled  = true
port     = 22
filter   = sshd
logpath  = /var/log/secure
maxretry = 5
# CSF equivalent: LF_SSHD = 5

[cpanel-login]
enabled  = true
port     = 2082,2083,2086,2087,2095,2096
filter   = cpanel
logpath  = /usr/local/cpanel/logs/login_log
maxretry = 10
# CSF equivalent: LF_CPANEL = 10

[pureftpd]
enabled  = true
port     = 21
filter   = pure-ftpd
logpath  = /var/log/messages
maxretry = 10
# CSF equivalent: LF_FTPD = 10

[postfix-sasl]
enabled  = true
port     = 25,465,587
filter   = postfix[mode=auth]
logpath  = /var/log/maillog
maxretry = 5
# CSF equivalent: LF_SMTPAUTH = 5

[dovecot]
enabled  = true
port     = 110,143,993,995
filter   = dovecot
logpath  = /var/log/maillog
maxretry = 10
# CSF equivalent: LF_POP3D/LF_IMAPD = 10

[recidive]
enabled  = true
bantime  = 86400
findtime = 86400
maxretry = 3
# Bans repeat offenders for 24 hours

You’ll need a custom filter for cPanel logins. Create /etc/fail2ban/filter.d/cpanel.conf:

[Definition]
failregex = .*login attempt.*from\s+<HOST>\s+.*failed.*
            .*FAILED LOGIN.*ip=<HOST>.*
ignoreregex =

Step 4: The Cutover

This is the critical moment. Do this during a maintenance window:

# 1. Stop CSF and LFD
csf -x
service lfd stop

# 2. Flush CSF's iptables rules
iptables -F
iptables -X
iptables -Z
ip6tables -F
ip6tables -X
ip6tables -Z

# 3. Start firewalld
systemctl start firewalld

# 4. Verify your rules are active
firewall-cmd --zone=cpanel-server --list-all

# 5. Start fail2ban
systemctl start fail2ban
systemctl enable fail2ban

# 6. Test connectivity
# From another terminal, verify SSH, HTTP, WHM all respond
# Check that blocked ports are actually blocked

# 7. Disable CSF from starting on boot
systemctl disable csf
systemctl disable lfd

Migration Path 2: nftables Direct (For Advanced Admins on Ubuntu/Debian)

If you’re running Ubuntu 24.04 or Debian 12+ with cPanel or DirectAdmin, nftables is the native firewall framework. This is the lower-level option — more control, more complexity, but no abstraction layers between you and the kernel’s packet filtering.

Create an nftables Ruleset for cPanel

#!/usr/sbin/nft -f
# /etc/nftables.conf — cPanel server ruleset

flush ruleset

table inet filter {
    # Trusted IP set — replaces csf.allow
    set whitelist_v4 {
        type ipv4_addr
        flags interval
        elements = {
            YOUR.OFFICE.IP.HERE,
            YOUR.SECOND.IP.HERE
        }
    }

    # Blocked IP set — replaces csf.deny
    set blocklist_v4 {
        type ipv4_addr
        flags interval, timeout
        timeout 24h
    }

    # Country block set (if you used CSF's CC_DENY)
    set country_block {
        type ipv4_addr
        flags interval
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # Stateful tracking
        ct state established,related accept
        ct state invalid drop

        # Loopback
        iifname "lo" accept

        # Drop blocked IPs early
        ip saddr @blocklist_v4 drop
        ip saddr @country_block drop

        # Accept whitelisted IPs for everything
        ip saddr @whitelist_v4 accept

        # ICMP — allow ping (CSF ICMP_IN equivalent)
        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

        # SSH
        tcp dport 22 ct state new limit rate 5/minute accept

        # DNS
        tcp dport 53 accept
        udp dport 53 accept

        # Web
        tcp dport { 80, 443 } accept

        # Mail
        tcp dport { 25, 110, 143, 465, 587, 993, 995 } accept

        # cPanel/WHM
        tcp dport { 2077, 2078, 2082, 2083, 2086, 2087, 2095, 2096 } accept

        # FTP + passive range
        tcp dport 21 accept
        tcp dport 49152-65534 accept

        # Log and drop everything else
        limit rate 5/minute log prefix "nftables-dropped: " level warn
        drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Dynamic Blocking with nftables + fail2ban

Configure fail2ban to use nftables natively. Create /etc/fail2ban/action.d/nftables-common.local:

[Init]
nftables_family = inet
nftables_table  = filter
nftables_set_prefix = fail2ban

Then your jail.local:

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

This makes fail2ban add offending IPs directly to nftables sets — fast, efficient, and kernel-native.

Migration Path 3: APF + BFD (The Closest Drop-In Replacement)

If you want something that feels like CSF — text-based config files, simple commands, and similar mental model — Advanced Policy Firewall (APF) with Brute Force Detection (BFD) is the closest match. It’s maintained by R-fx Networks, the same team behind Linux Malware Detect (maldet).

# Install APF
cd /usr/local/src
wget https://www.rfxn.com/downloads/apf-current.tar.gz
tar xzf apf-current.tar.gz
cd apf-*
./install.sh

# Install BFD
cd /usr/local/src
wget https://www.rfxn.com/downloads/bfd-current.tar.gz
tar xzf bfd-current.tar.gz
cd bfd-*
./install.sh

APF’s config at /etc/apf/conf.apf uses a nearly identical port syntax to CSF:

# These map directly from your CSF configuration
IG_TCP_CPORTS="20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
IG_UDP_CPORTS="20,21,53"
EG_TCP_CPORTS="20,21,22,25,37,43,53,80,110,113,443,587,993,995,2086,2087,2089,2703"
EG_UDP_CPORTS="20,21,53,113,123"

The trust and deny files work the same way:

# Copy your CSF lists directly
cp /root/csf-migration/csf.allow /etc/apf/allow_hosts.rules
cp /root/csf-migration/csf.deny /etc/apf/deny_hosts.rules

The catch with APF: It’s simpler than CSF, and that means fewer features. There’s no WHM integration, no built-in country blocking, and BFD isn’t as sophisticated as LFD was. It’s a viable stopgap but not a long-term enterprise solution.

CSF Configuration Mapping Reference

Here’s a quick-reference table mapping CSF’s most commonly configured options to their equivalents across each alternative:

CSF Setting	Purpose	firewalld Equivalent	nftables Equivalent	fail2ban Equivalent
TCP_IN	Inbound TCP ports	--add-port=X/tcp	tcp dport { } accept	N/A (firewall handles)
TCP_OUT	Outbound TCP ports	Rich rules on output	Output chain rules	N/A
csf.allow	Trusted IPs	Rich rules / ipset	Named set + accept	ignoreip
csf.deny	Blocked IPs	Rich rules / ipset	Named set + drop	N/A (static blocks)
LF_SSHD	SSH brute force	N/A	Rate limiting	[sshd] jail
LF_FTPD	FTP brute force	N/A	Rate limiting	[pureftpd] jail
LF_CPANEL	cPanel login fails	N/A	N/A	Custom [cpanel] jail
LF_SMTPAUTH	SMTP auth fails	N/A	N/A	[postfix-sasl] jail
CC_DENY	Country blocking	GeoIP ipsets	GeoIP sets	N/A
CT_LIMIT	Connection tracking	Rich rule rate limits	ct count / limit	N/A
SYNFLOOD	SYN flood protection	Built into nftables backend	tcp flags & syn limit rate	N/A
ICMP_IN	Ping control	--add-icmp-block	icmp type echo-request	N/A
PORTFLOOD	Per-port rate limiting	Rich rules with rate limits	meter + limit rate	N/A

Country Blocking Without CSF

CSF’s country-based blocking (CC_DENY and CC_ALLOW) was one of its most popular features, especially for servers under heavy attack from specific regions. Here’s how to replicate it:

Using firewalld + ipset

# Download the latest country IP blocks (example: block CN, RU)
cd /tmp
wget -q https://www.ipdeny.com/ipblocks/data/aggregated/cn-aggregated.zone
wget -q https://www.ipdeny.com/ipblocks/data/aggregated/ru-aggregated.zone

# Create ipsets
firewall-cmd --permanent --new-ipset=country-cn --type=hash:net
firewall-cmd --permanent --new-ipset=country-ru --type=hash:net

# Populate
while read cidr; do
    firewall-cmd --permanent --ipset=country-cn --add-entry="$cidr"
done < cn-aggregated.zone

while read cidr; do
    firewall-cmd --permanent --ipset=country-ru --add-entry="$cidr"
done < ru-aggregated.zone

# Apply blocks
firewall-cmd --permanent --add-rich-rule="rule source ipset='country-cn' drop"
firewall-cmd --permanent --add-rich-rule="rule source ipset='country-ru' drop"
firewall-cmd --reload

Automating Updates

Create a cron job to refresh the country blocks weekly:

#!/bin/bash
# /usr/local/bin/update-country-blocks.sh

COUNTRIES="cn ru"
ZONE_URL="https://www.ipdeny.com/ipblocks/data/aggregated"

for country in $COUNTRIES; do
    wget -q -O /tmp/${country}.zone ${ZONE_URL}/${country}-aggregated.zone
    if [ -f /tmp/${country}.zone ]; then
        firewall-cmd --permanent --delete-ipset=country-${country} 2>/dev/null
        firewall-cmd --permanent --new-ipset=country-${country} --type=hash:net
        while read cidr; do
            firewall-cmd --permanent --ipset=country-${country} --add-entry="$cidr"
        done < /tmp/${country}.zone
        firewall-cmd --permanent --add-rich-rule="rule source ipset='country-${country}' drop"
    fi
done

firewall-cmd --reload

# Add to crontab
echo "0 3 * * 0 /usr/local/bin/update-country-blocks.sh" >> /var/spool/cron/root

Post-Migration Verification Checklist

After cutover, don’t just assume everything is working. Verify methodically:

Connectivity checks:

# From an external machine, test all critical ports
for port in 22 25 80 443 2083 2087; do
    nc -zv YOUR_SERVER_IP $port
done

# Verify blocked ports are actually blocked
nc -zv YOUR_SERVER_IP 3306   # MySQL should be blocked
nc -zv YOUR_SERVER_IP 6379   # Redis should be blocked

Firewall rule verification:

# firewalld
firewall-cmd --list-all --zone=cpanel-server

# nftables
nft list ruleset

# Verify fail2ban is active and watching
fail2ban-client status
fail2ban-client status sshd

Intrusion prevention testing:

# From a test IP, deliberately trigger a ban
# (e.g., 5 failed SSH attempts)
# Then verify the ban appears:
fail2ban-client status sshd
# Should show your test IP in the banned list

Log monitoring:

# Tail the fail2ban log during testing
tail -f /var/log/fail2ban.log

# Verify firewall drops are being logged
journalctl -f -t kernel | grep -i "drop\|reject"

Removing CSF Cleanly

Before you do this: If you’re on cPanel/WHM, seriously consider staying on CSF via the cPanel fork instead of migrating. The WHM integration, the familiar tooling, and the zero-effort update path make it the pragmatic choice for most cPanel environments. The migration paths above are primarily for non-cPanel servers or environments where you’ve made a deliberate decision to modernize your firewall stack.

If you’ve verified your new firewall is solid and you’re committed to the migration, remove CSF completely:

# CSF includes its own uninstaller
cd /etc/csf
sh uninstall.sh

# Verify it's gone
which csf        # Should return nothing
ls /etc/csf      # Should not exist
systemctl status csf  # Should report not found
systemctl status lfd  # Should report not found

# Clean up any remaining cron jobs
crontab -l | grep -v csf | crontab -

Check WHM’s “ConfigServer Security & Firewall” plugin page — it should be gone. If the menu entry persists, clear cPanel’s plugin cache:

/usr/local/cpanel/bin/rebuild_sprites
/usr/local/cpanel/bin/register_appconfig --build

Final Thoughts

The CSF story has taken a better turn than many of us expected. cPanel stepping in with a maintained fork was the right move, and it means the majority of CSF users, those running cPanel/WHM, can breathe easier. If you’re in that camp, make sure your server is ready for the February 18 auto-update (or opt out consciously), and you’re covered for the near term.

For non-cPanel users, the community forks, particularly ConfigServer.dev (Aetherinox), are providing a solid continuation path with active development and nftables work in progress.

But the broader lesson here stands: depending on a single-maintainer security tool for your production infrastructure is a risk that compounds over time. Whether you stay on a CSF fork, migrate to firewalld + fail2ban, go raw nftables, or pick up APF + BFD, the key is making a deliberate choice rather than letting inertia decide for you.

For those on cPanel: leverage the fork, keep AUTO_UPDATES pointed at a maintained source, and monitor the situation.

For those migrating: pick a path, test it thoroughly in staging, and execute the cutover. Your future self will thank you.

For everyone: disable those broken auto-update checks if you haven’t already. That’s a five-second fix with real security implications.