Migrating from CSF

Move an existing ConfigServer Security & Firewall (CSF) setup to SecLayer with one command — your allow/deny lists, ignore files and configuration come across, and CSF is switched off, not uninstalled.

Overview

The --csfmigrate command copies your CSF data into SecLayer, then stops and disables CSF's services and starts SecLayer's firewall, login failure daemon and DDoS protection. It does not uninstall CSF. CSF's files under /etc/csf, its binaries and its configuration are left untouched on disk, so you can review them later or switch back if you need to.

Running the Migration

Run as root on the server:

Add -q (or --quiet) to suppress progress output; everything is still written to the log file:

CSF is detected by the presence of /etc/csf/csf.conf. If CSF is not installed, the command reports that there is nothing to migrate and changes nothing.

During Installation

When the SecLayer installer finds CSF, it asks whether to migrate now (the default answer is No). For unattended installs, pass --migrate-csf=yes or --migrate-csf=no to the installer. If you skip it, you can run seclayer --csfmigrate at any time later. Until then, the Security Check page shows a Stop the previous firewall (CSF) step.

What Gets Migrated

IP Lists

• csf.allow → /etc/seclayer/seclayer.allow (whitelist)
• csf.deny → /etc/seclayer/seclayer.deny (blacklist)
• csf.ignore → /etc/seclayer/ignore/seclayer.ignore

Every entry is validated as an IP address or CIDR range before it is added; invalid lines are skipped. Each migrated entry is tagged # Migrated from CSF, keeping the original CSF comment in brackets.

Login Failure Daemon Ignore Files

csf.pignore, csf.fignore, csf.signore, csf.rignore, csf.suignore, csf.mignore, csf.uidignore and csf.logignore are copied to the matching seclayer.* files in /etc/seclayer/ignore/.

Other Configuration Files

These CSF files are copied to the matching /etc/seclayer/seclayer.* file:

• csf.redirect — port redirects
• csf.dyndns — dynamic DNS hosts
• csf.blocklists — blocklist feeds
• csf.rblconf — RBL check settings
• csf.smtpauth, csf.syslogs, csf.syslogusers, csf.logfiles
• csf.resellers, csf.cloudflare, csf.dirwatch, csf.sips

The copied lines are appended under a # === Migrated from CSF on <date> === header, so anything already in the SecLayer file is kept.

Settings from csf.conf

SecLayer uses the same setting names as CSF, so values such as TCP_IN, TCP_OUT, LF_ALERT_TO, CT_LIMIT and the LF_* thresholds are copied into /etc/seclayer/seclayer.conf as-is. The only renamed key is LF_CSF, which becomes LF_SECLAYER.

Every value goes through the same validation as a change made on the Configuration page. Settings that fail validation or that SecLayer does not support are not migrated, and the output lists them by name so you can review them.

What Happens to CSF

Once every item has migrated successfully:

1. The lfd and csf services are stopped (systemctl stop).
2. Both services are disabled (systemctl disable), so CSF does not start again after a reboot.
3. The SecLayer firewall is started with the migrated rules, and seclayer-firewall is enabled at boot so the server is never left without a firewall.
4. DDoS protection is turned on (DDOS_ENABLE = 1).
5. The login failure daemon (seclayer-lfd), which also runs DDoS protection, is enabled at boot and started.

Note: if your csf.conf had TESTING = 1, that setting is migrated too, and the login failure daemon does not run in testing mode. In that case the migration leaves the daemon stopped and says so. Turn off testing mode on the Security Check page once you have confirmed you can still reach the server.

CSF is not uninstalled: its uninstall script is not run and nothing under /etc/csf, /usr/local/csf or /var/lib/csf is deleted. To avoid confusion later, we recommend uninstalling CSF yourself once you are happy with SecLayer (for example with /etc/csf/uninstall.sh).

If Something Fails

A file that cannot be read or migrated does not stop the rest of the migration. However, if any item fails, CSF is left running and SecLayer does not take over, so the server is never protected by an incomplete rule set. The output lists the items that failed. Fix the cause and run seclayer --csfmigrate again.

Running the migration again is safe: IPs and lines that were already migrated are skipped, so nothing is duplicated.

Log File

Every run is logged to /var/seclayer/logs/csf-migrate.log, including the counts for each list and the names of any settings that were not migrated.

After Migrating

1. Open the Security Check page (or run seclayer --security-check) and complete any remaining steps — for example, allowing your own IP address or turning off testing mode.
2. Review your lists on Allow IPs and Deny IPs.
3. Check any settings reported as not migrated on the Configuration page.