Migrate from CSF to VistoShield: Step-by-Step Guide

Introduction: Why Migrate from CSF?

ConfigServer Security & Firewall (CSF) has been a staple of Linux server security for over a decade. Combined with its Login Failure Daemon (LFD), it provided iptables firewall management, brute-force protection, and basic intrusion detection for servers running cPanel, DirectAdmin, Webmin, and standalone configurations. For many years, it was the go-to solution for hosting providers and system administrators.

However, CSF development has slowed significantly. Updates have become infrequent, new features are rare, and support for modern distributions and control panels has lagged. As server security threats have evolved — with more sophisticated attacks, the rise of WordPress as a primary target, and the need for application-layer protection — CSF’s capabilities have not kept pace.

VistoShield was built to address these gaps. The Server Edition provides everything CSF offers (iptables firewall, LFD, IP blocklists, country blocking) plus significant enhancements: better performance, modern codebase, active development, and seamless integration with the WordPress Edition for application-layer protection. Critically, VistoShield is designed to be a drop-in replacement, understanding CSF’s configuration format and providing import tools for a smooth migration.

This guide walks you through the complete migration process, from backing up your CSF configuration to verifying that VistoShield is running correctly with your existing rules and settings.

Before You Begin: Pre-Migration Checklist

Before starting the migration, complete the following preparation steps:

1. Document Your Current CSF Configuration

Record your current CSF settings for reference. Even though VistoShield can import most settings automatically, having a reference is valuable for verification.

# Export current CSF configuration
cat /etc/csf/csf.conf > /root/csf-config-backup.txt

# Record current iptables rules
iptables -L -n --line-numbers > /root/iptables-backup.txt
ip6tables -L -n --line-numbers > /root/ip6tables-backup.txt

# Record current CSF status
csf -v > /root/csf-version.txt
csf -l > /root/csf-rules-backup.txt

2. Backup CSF Data Files

CSF uses several data files that contain your custom allow/deny lists, port configuration, and other settings:

# Create a complete backup of the CSF directory
tar czf /root/csf-full-backup-$(date +%Y%m%d).tar.gz /etc/csf/

# Key files to be aware of:
# /etc/csf/csf.conf       - Main configuration
# /etc/csf/csf.allow      - Allowed IPs (whitelist)
# /etc/csf/csf.deny       - Denied IPs (blacklist)
# /etc/csf/csf.ignore     - IPs to ignore in LFD
# /etc/csf/csf.blocklists - Blocklist configuration
# /etc/csf/csf.pignore    - Process ignore list
# /etc/csf/csf.fignore    - File integrity ignore list
# /etc/csf/csf.rignore    - Reverse DNS ignore list
# /etc/csf/csf.signore    - Script ignore list

3. Note Your Custom Port Configuration

Record which ports you have open in CSF. These will need to match in VistoShield:

# Extract port configuration from csf.conf
grep "^TCP_IN\|^TCP_OUT\|^UDP_IN\|^UDP_OUT" /etc/csf/csf.conf

Typical output:

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,53,80,110,113,443,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

4. Schedule the Migration

The migration process involves stopping CSF and starting VistoShield. During the transition (typically 1–2 minutes), the server will briefly be without firewall protection. Schedule the migration during a low-traffic maintenance window and consider temporarily enabling any cloud-level firewall (AWS Security Groups, Cloudflare, etc.) as a safety net.

5. Verify System Requirements

Ensure your server meets VistoShield’s requirements. For detailed requirements, see the Requirements page.

• CentOS 7+, AlmaLinux 8+, Rocky Linux 8+, Ubuntu 18.04+, or Debian 10+
• Root SSH access
• iptables or nftables (VistoShield supports both)
• Perl 5.10+ (already present if CSF is running)
• At least 256 MB free RAM

Step 1: Install VistoShield (Without Starting)

First, download and install VistoShield without activating it, so both CSF and VistoShield are present but only CSF is running.

# Download VistoShield installer
cd /tmp
wget https://vistoshield.com/install.sh

# Run installer in preparation mode (does not start the daemon)
bash install.sh --prepare-only

The --prepare-only flag installs VistoShield binaries and creates the configuration directory at /etc/vistoshield/ without starting the daemon or modifying iptables. This allows you to configure VistoShield before the switchover.

Step 2: Import CSF Configuration

VistoShield includes a migration tool that reads your CSF configuration and converts it to the VistoShield format. This handles the majority of settings automatically.

# Run the CSF import tool
vistoshield --import-csf

# The tool will:
# 1. Read /etc/csf/csf.conf and convert settings
# 2. Import /etc/csf/csf.allow to /etc/vistoshield/csf.allow
# 3. Import /etc/csf/csf.deny to /etc/vistoshield/csf.deny
# 4. Import /etc/csf/csf.ignore to /etc/vistoshield/csf.ignore
# 5. Import blocklist configuration
# 6. Import country blocking settings
# 7. Generate a migration report

The import tool produces a detailed report showing what was imported, what was converted, and any settings that require manual review.

Settings Mapping: CSF to VistoShield

Most CSF settings map directly to VistoShield equivalents. The following table shows key mappings:

CSF Setting	VistoShield Setting	Notes
TCP_IN / TCP_OUT	TCP_IN / TCP_OUT	Direct mapping
UDP_IN / UDP_OUT	UDP_IN / UDP_OUT	Direct mapping
LF_TRIGGER	LF_TRIGGER	Direct mapping
LF_SSHD	LF_SSHD	Direct mapping
LF_FTPD	LF_FTPD	Direct mapping
LF_SMTPAUTH	LF_SMTPAUTH	Direct mapping
LF_POP3D	LF_POP3D	Direct mapping
LF_IMAPD	LF_IMAPD	Direct mapping
CC_DENY	CC_DENY	Direct mapping
CC_ALLOW	CC_ALLOW	Direct mapping
DENY_IP_LIMIT	DENY_IP_LIMIT	Direct mapping
CONNLIMIT	CONNLIMIT	Direct mapping
PORTFLOOD	PORTFLOOD	Direct mapping
SYNFLOOD	SYNFLOOD	Direct mapping
TESTING	TESTING	Direct mapping
csf.allow	csf.allow	File imported directly
csf.deny	csf.deny	File imported directly

VistoShield intentionally maintains compatibility with CSF’s configuration format to make migration as seamless as possible. Administrators familiar with CSF will find VistoShield’s configuration immediately recognizable.

Step 3: Review and Adjust Configuration

After the import, review the generated VistoShield configuration to ensure everything looks correct:

# Review the imported configuration
less /etc/vistoshield/vistoshield.conf

# Compare key settings with your CSF backup
diff <(grep "^TCP_IN" /root/csf-config-backup.txt) <(grep "^TCP_IN" /etc/vistoshield/vistoshield.conf)
diff <(grep "^LF_" /root/csf-config-backup.txt) <(grep "^LF_" /etc/vistoshield/vistoshield.conf)

Settings That May Need Manual Adjustment

While most settings import directly, some may need manual review:

• Custom regex patterns: If you added custom log parsing patterns to CSF, these may need to be adapted to VistoShield’s regex format
• Third-party integration scripts: If CSF triggered custom scripts on certain events, you will need to reconfigure these for VistoShield’s event system
• Cluster mode: If you used CSF’s cluster synchronization, VistoShield has its own cluster mechanism that requires separate configuration
• cPanel/DirectAdmin hooks: Panel-specific hooks are automatically reconfigured when you install the VistoShield panel module

Step 4: Stop CSF and Start VistoShield

This is the switchover point. The commands below stop CSF, remove it from startup, and activate VistoShield. Execute them in sequence:

# Stop CSF and LFD
csf -x
systemctl stop csf
systemctl stop lfd

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

# Clear any remaining CSF iptables rules
iptables -F
iptables -X

# Start VistoShield
systemctl start vistoshield
systemctl enable vistoshield

# Verify VistoShield is running
systemctl status vistoshield
vistoshield --status

The time between stopping CSF and starting VistoShield is typically under 10 seconds. During this window, the server has no active firewall rules. If you are concerned about this gap, you can use a pre-configured cloud firewall as temporary protection.

Step 5: Verify Firewall Rules

After VistoShield starts, verify that your firewall rules are loaded correctly:

# Check iptables rules are loaded
iptables -L -n | head -50

# Verify port configuration matches your expectations
vistoshield --ports

# Verify allow list is loaded
vistoshield --allow-list

# Verify deny list is loaded
vistoshield --deny-list | head -20

# Check that LFD is running and monitoring
vistoshield --lfd-status

# Verify country blocking is active (if configured)
vistoshield --cc-status

Critical Verification Checks

Check	Command	Expected Result
VistoShield daemon running	systemctl status vistoshield	Active (running)
SSH port open	vistoshield --ports | grep 22	TCP_IN: 22 (open)
HTTP/HTTPS open	vistoshield --ports | grep "80\|443"	TCP_IN: 80, 443 (open)
Your IP is whitelisted	vistoshield --allow-list | grep YOUR_IP	IP listed
LFD monitoring active	vistoshield --lfd-status	Running, monitoring N services
Blocklists loaded	vistoshield --blocklist-status	Lists loaded with IP counts

Step 6: Test External Connectivity

From an external machine (not the server itself), verify that services are accessible:

# Test SSH access
ssh user@your-server-ip

# Test HTTP
curl -I http://your-server-ip

# Test HTTPS
curl -I https://your-domain.com

# Test that a non-opened port is blocked
nmap -p 3306 your-server-ip  # Should show filtered/closed

If you manage the server through a hosting control panel, log in to cPanel, DirectAdmin, or Webmin to verify panel access is working correctly.

Step 7: Install the Control Panel Module

If you were using CSF’s control panel integration, install the corresponding VistoShield module:

For cPanel/WHM

vistoshield --install-cpanel-module

For DirectAdmin

vistoshield --install-directadmin-module

For Webmin

vistoshield --install-webmin-module

The panel module provides a graphical interface for managing VistoShield, similar to the CSF panel interface but with additional features. For detailed instructions, see the respective panel documentation pages: cPanel, DirectAdmin, Webmin.

Step 8: Remove CSF (Optional)

Once you have verified that VistoShield is running correctly and all services are accessible, you can optionally remove CSF from the server:

# Remove CSF using its uninstall script
cd /etc/csf
sh uninstall.sh

# Or manually:
rm -rf /etc/csf
rm -f /usr/sbin/csf
rm -f /usr/sbin/lfd

We recommend keeping the CSF backup (/root/csf-full-backup-*.tar.gz) for at least 30 days after migration in case you need to reference the original configuration.

Step 9: Set Up WordPress Integration (Optional)

One of the key advantages of migrating to VistoShield is the ability to add WordPress-level protection that CSF never offered. If you host WordPress sites on the server, install the VistoShield WordPress Edition plugins:

• Firewall & WAF — Application-layer firewall with SQLi/XSS/LFI/RCE protection
• Login Guard — 2FA, login rate limiting, integrated with server-level LFD
• Security Scanner — Malware detection with quarantine
• Activity Log — Comprehensive audit trail
• Bot Detector — Automated bot detection and blocking

The WordPress plugins communicate with the Server Edition, enabling features like iptables-level blocking for WordPress login failures — something that was not possible with CSF. This dual-layer architecture is described in detail in the documentation.

Troubleshooting Migration Issues

Locked Out After Switchover

If you lose SSH access after the switchover, you likely have an allow list issue. Access the server through your hosting provider’s console (IPMI, VNC, or cloud console) and verify your IP is in /etc/vistoshield/csf.allow. Then restart VistoShield:

systemctl restart vistoshield

Services Not Accessible

If specific services are not accessible after migration, check the port configuration:

vistoshield --ports

Compare with your CSF backup to ensure all required ports are open. Add any missing ports:

# Edit the configuration
vi /etc/vistoshield/vistoshield.conf
# Add the missing port to TCP_IN or UDP_IN

# Restart to apply
vistoshield --restart

High Block Rate After Migration

If you see an unusually high number of IP blocks immediately after migration, check that your LFD thresholds were imported correctly. A common issue is the LF_TRIGGER global threshold being set to a low value that overrides per-service thresholds.

Email Alerts Not Working

If VistoShield email alerts are not arriving, verify the alert configuration:

grep "LF_ALERT\|LF_EMAIL" /etc/vistoshield/vistoshield.conf

Ensure LF_EMAIL_ALERT = 1 and LF_ALERT_TO contains a valid email address.

What You Gain by Migrating

After migrating from CSF to VistoShield, you gain access to several capabilities that CSF does not provide:

Capability	CSF	VistoShield
Active development	Minimal updates	Regular updates
WordPress integration	None	Full plugin suite
Application-layer WAF	None	SQLi/XSS/LFI/RCE protection
WordPress login → iptables	Not possible	Native integration
Malware scanning	None	Security Scanner plugin
Activity logging	Basic LFD log	Comprehensive audit trail
Bot detection	None	Bot Detector plugin
Modern panel modules	Legacy UI	Modern, responsive UI
nftables support	Limited	Full support
License	Proprietary freeware	GPLv2 open source

Post-Migration Optimization

After the migration is verified and stable, take advantage of VistoShield features that were not available in CSF to further enhance your server’s security posture.

Enable IP Reputation Blocklists

If you were not using CSF’s blocklist feature (or were using only a limited set), now is the time to enable VistoShield’s expanded blocklist support. Spamhaus DROP/EDROP and FireHOL Level 1 are recommended as a starting point, providing proactive blocking of known malicious IP ranges with virtually zero false positive risk. See the blocklist configuration in /etc/vistoshield/csf.blocklists.

Enable Enhanced Logging

VistoShield provides more detailed logging than CSF. Enable comprehensive logging to gain better visibility into your server’s security events. The logs integrate with the control panel module, providing searchable, filterable views that CSF’s basic log display could not match.

Set Up WordPress Integration

The single biggest advantage of VistoShield over CSF is the WordPress integration. For every WordPress site on your server, install the WordPress Edition plugins. The Login Guard plugin alone is transformative — it enables iptables-level blocking for WordPress login attacks, something that was completely impossible with CSF. Combined with the WAF, Scanner, Activity Log, and Bot Detector, you achieve a level of WordPress protection that no CSF setup could provide.

Key Takeaways

• Migration from CSF to VistoShield is straightforward thanks to configuration format compatibility and the automated import tool.
• Backup everything first. Create a complete backup of your CSF configuration and data files before starting.
• The import tool handles most settings automatically, mapping CSF configuration directives directly to their VistoShield equivalents.
• Verify thoroughly after the switchover: check ports, allow/deny lists, LFD status, and external connectivity before considering the migration complete.
• The migration opens up new capabilities that CSF cannot provide, especially WordPress integration with the WordPress Edition plugins.
• Consult the Getting Started guide and the Configuration reference for comprehensive documentation on all VistoShield features.