DirectAdmin Server Security After CSF: Complete Migration Guide

For years, ConfigServer Security & Firewall (CSF) was the standard security solution on DirectAdmin servers. System administrators installed CSF alongside DirectAdmin to manage firewall rules, block brute force attackers, and secure their hosting environments. With CSF's development stalled and modern Linux distributions moving beyond iptables, DirectAdmin administrators face an urgent question: what replaces CSF, and how do you migrate without leaving your server exposed?

This guide walks you through the complete migration process from CSF to VistoShield Server Edition on a DirectAdmin server. We cover pre-migration preparation, installation, configuration import, verification, and post-migration hardening. Whether you are managing a single dedicated server or a fleet of DirectAdmin nodes, these steps will get you from CSF to VistoShield with zero downtime.

Why DirectAdmin Administrators Need to Move Beyond CSF

DirectAdmin servers typically run on modern Linux distributions — AlmaLinux 9, Rocky Linux 9, Debian 12, or Ubuntu 24.04. All of these default to nftables for packet filtering, yet CSF only generates iptables rules. This mismatch causes several problems specific to the hosting environment:

The iptables Compatibility Problem

When you install CSF on a modern distribution, it typically installs iptables-legacy packages and disables nftables to avoid conflicts. This means your server is running deprecated software to accommodate a security tool that has not been updated. On AlmaLinux 9 and Rocky Linux 9, the iptables-nft package translates iptables commands to nftables under the hood, but this translation layer introduces edge cases that CSF was never tested against.

IPv6 Gaps in Hosting

DirectAdmin fully supports IPv6, and most hosting providers now assign IPv6 addresses to customer domains. CSF's separate IPv6 configuration means administrators must maintain two parallel rulesets. In practice, many administrators have IPv6 rules that are out of sync with their IPv4 rules, leaving services exposed on the IPv6 stack.

WordPress-Specific Threats

The majority of websites on DirectAdmin hosting servers run WordPress. CSF has zero awareness of WordPress-specific attack patterns — brute force attacks against wp-login.php, XML-RPC abuse, REST API exploitation, and plugin vulnerability scanning all bypass CSF's detection unless they happen to trigger generic authentication failure patterns in system logs.

Pre-Migration Checklist

Before beginning the migration, complete these preparatory steps to ensure a smooth transition.

1. Document Your Current CSF Configuration

Export your current CSF configuration for reference. The key files to preserve are:

# Core configuration
/etc/csf/csf.conf

# Allow and deny lists
/etc/csf/csf.allow
/etc/csf/csf.deny
/etc/csf/csf.ignore

# Custom iptables rules (if any)
/etc/csf/csfpre.sh
/etc/csf/csfpost.sh

# Port configuration from csf.conf
TCP_IN, TCP_OUT, UDP_IN, UDP_OUT values

Create a backup of these files:

mkdir -p /root/csf-backup
cp /etc/csf/csf.conf /root/csf-backup/
cp /etc/csf/csf.allow /root/csf-backup/
cp /etc/csf/csf.deny /root/csf-backup/
cp /etc/csf/csf.ignore /root/csf-backup/
cp /etc/csf/csfpre.sh /root/csf-backup/ 2>/dev/null
cp /etc/csf/csfpost.sh /root/csf-backup/ 2>/dev/null

2. Note Your Open Ports

Record which ports CSF currently allows. For a typical DirectAdmin server, this includes:

Service	Port(s)	Protocol
SSH	22 (or custom)	TCP
HTTP	80	TCP
HTTPS	443	TCP
DirectAdmin	2222	TCP
FTP	21, 20	TCP
FTP Passive	35000-35999	TCP
SMTP	25, 465, 587	TCP
POP3	110, 995	TCP
IMAP	143, 993	TCP
MySQL (local only)	3306	TCP
DNS	53	TCP/UDP

Verify this against your actual CSF configuration:

grep "^TCP_IN" /etc/csf/csf.conf
grep "^TCP_OUT" /etc/csf/csf.conf
grep "^UDP_IN" /etc/csf/csf.conf
grep "^UDP_OUT" /etc/csf/csf.conf

3. Count Your Blocklist Entries

Understanding the size of your current blocklist helps predict migration time and verify completeness afterward:

wc -l /etc/csf/csf.deny
wc -l /etc/csf/csf.allow
wc -l /etc/csf/csf.ignore

4. Check Your Linux Distribution and Firewall Backend

# Check distribution
cat /etc/os-release | head -5

# Check if nftables is available
nft --version 2>/dev/null

# Check current iptables backend
iptables --version
# If output shows "nf_tables" you are using the nftables translation layer
# If output shows "legacy" you are using true iptables

5. Verify DirectAdmin Version

/usr/local/directadmin/directadmin version

Ensure DirectAdmin is up to date before proceeding. VistoShield integrates with modern DirectAdmin versions and requires the current plugin system.

Step 1: Install VistoShield Server Edition

VistoShield can be installed alongside CSF initially. Both tools can coexist during the migration period, with only one actively managing the firewall at a time.

Follow the installation instructions in the VistoShield documentation for your specific distribution. The installation process detects your server environment, identifies the available firewall backend (nftables or iptables), discovers DirectAdmin, and configures itself accordingly.

After installation, VistoShield starts in audit mode by default. In this mode, it monitors traffic and logs what it would block, but does not actually interfere with CSF's active firewall rules. This allows you to verify VistoShield's behavior before switching over.

Step 2: Import CSF Configuration

VistoShield provides a migration tool that reads your CSF configuration and translates it to VistoShield's format. This handles the port configuration, allow/deny lists, and common lfd settings.

# Run the CSF migration import
vistoshield migrate --from csf --config /etc/csf/csf.conf

# The tool will report what it imported:
# - Port configuration (TCP_IN, TCP_OUT, UDP_IN, UDP_OUT)
# - Allow list entries from csf.allow
# - Deny list entries from csf.deny
# - Ignore list entries from csf.ignore
# - lfd settings (login failure thresholds, etc.)

What Gets Imported

• Port rules: CSF's TCP_IN, TCP_OUT, UDP_IN, UDP_OUT are mapped to VistoShield's port policy configuration.
• Allow list: All entries from csf.allow are imported to VistoShield's whitelist with the original comments preserved.
• Deny list: All entries from csf.deny are imported to VistoShield's blocklist. Temporary entries (with TTL) have their remaining duration calculated and preserved.
• Ignore list: Process ignore entries from csf.ignore are mapped to VistoShield's equivalent.
• LFD settings: Login failure thresholds and temporary ban durations are mapped to VistoShield's brute force detection settings.

What Requires Manual Review

• Custom iptables rules: If you have csfpre.sh or csfpost.sh with custom rules, these need manual translation to VistoShield's custom rule format or to nftables syntax.
• CONNLIMIT and PORTFLOOD: CSF's connection limiting settings need to be mapped to VistoShield's rate limiting configuration. The migration tool will flag these for review.
• SMTP_BLOCK and other service-specific settings: Some CSF settings that control specific service behavior may not have direct equivalents and require configuration through DirectAdmin or service-level settings.

Step 3: Verify Configuration in Audit Mode

With the imported configuration loaded, VistoShield operates in audit mode. During this phase, review the audit log to verify that VistoShield's decisions align with CSF's behavior:

# View audit log for the last hour
vistoshield log --audit --since 1h

# Check for any legitimate IPs that would be blocked
vistoshield log --audit --action block --since 1h

# Verify port policy matches expectations
vistoshield config --show ports

Run audit mode for at least 24 hours to capture a full cycle of traffic patterns. During this period, CSF remains your active firewall — VistoShield is only observing and logging.

Common Issues to Watch For

• Port discrepancies: Verify that all ports your services use are correctly allowed. Compare vistoshield config --show ports with your documented CSF port list.
• IP whitelist coverage: Ensure your management IPs, monitoring service IPs, and any trusted third-party IPs are in the whitelist.
• Service detection: VistoShield auto-detects running services. Verify it has correctly identified all services on your DirectAdmin server.

Step 4: Switch From CSF to VistoShield

Once you have verified VistoShield's configuration in audit mode, perform the switchover. This should be done during a low-traffic maintenance window:

# Step 4a: Stop CSF and its login failure daemon
csf -x
service lfd stop

# Step 4b: Disable CSF from starting on boot
systemctl disable csf
systemctl disable lfd

# Step 4c: Activate VistoShield as the primary firewall
vistoshield activate

# Step 4d: Verify the firewall is active
vistoshield status

After activation, immediately verify connectivity:

# From a separate session/machine, verify SSH access
ssh user@your-server-ip

# Verify web access
curl -I https://your-server-hostname

# Verify DirectAdmin access
curl -I https://your-server-hostname:2222

# Verify email ports (if applicable)
telnet your-server-ip 25
telnet your-server-ip 993

Important: Always have out-of-band access to your server (IPMI, KVM, or hosting provider console) before switching firewall tools. If something goes wrong, you need a way to access the server that does not depend on network firewall rules.

Step 5: Configure DirectAdmin Integration

VistoShield provides a DirectAdmin plugin that integrates with the control panel interface. This gives you a familiar management interface within DirectAdmin for:

• Viewing and managing firewall rules
• Monitoring blocked IPs and attack patterns
• Managing the whitelist and blocklist
• Configuring brute force detection thresholds
• Viewing security events and logs
• Managing per-user security settings

The DirectAdmin plugin is typically installed automatically during the VistoShield installation process. Verify it is accessible at DirectAdmin > Admin > VistoShield.

Step 6: Enable WordPress Protection

This is where VistoShield goes far beyond what CSF ever offered. For every WordPress site on your DirectAdmin server, you can now enable application-layer protection through the VistoShield WordPress Edition.

WordPress Plugin Installation

The VistoShield WordPress plugin can be installed per-site through the WordPress admin dashboard, or deployed server-wide through DirectAdmin's plugin management. The WordPress plugin communicates with the server-level VistoShield engine, enabling features that no standalone WordPress security plugin can provide:

• Login Guard: Brute force protection with progressive lockouts that escalate to server-level firewall blocks for persistent attackers.
• Bot Detector: Identifies and manages automated traffic across all WordPress sites on the server.
• Firewall: WordPress-specific WAF rules that complement the server-level firewall.
• Security Scanner: File integrity monitoring, malware detection, and vulnerability checking.
• Activity Log: Comprehensive audit trail of all WordPress actions — user logins, content changes, plugin updates, and configuration modifications.

Step 7: Remove CSF

After running VistoShield as the primary firewall for at least one week with no issues, remove CSF to avoid confusion and eliminate the legacy iptables dependencies:

# Remove CSF
cd /etc/csf
sh uninstall.sh

# Remove leftover iptables-legacy packages (if nftables is your backend)
# Only do this if VistoShield confirmed nftables backend
# Check first:
vistoshield config --show backend
# If output is "nftables", you can safely remove legacy iptables:
# apt remove iptables  (Debian/Ubuntu)
# dnf remove iptables-legacy  (RHEL-family)

Keep the CSF backup you created in the pre-migration checklist for at least 30 days as a reference.

Post-Migration: Security Hardening Beyond CSF

With VistoShield in place, you now have capabilities that CSF never offered. Take advantage of them to improve your DirectAdmin server's security posture.

Enable Bot Detection

One of the most impactful features for hosting servers is automated bot management. Enable the Bot Detector to reduce server load from scrapers, vulnerability scanners, and spam bots that previously consumed your resources unchecked. See our bot detection guide for configuration details.

Configure Progressive Lockouts

Replace CSF's flat lockout policy with progressive lockouts. Instead of blocking an IP for a fixed duration after N failures, configure escalating durations: 5 minutes for the first violation, 30 minutes for the second, 2 hours for the third, and 24 hours for the fourth. This reduces false positives from legitimate users who mistype passwords while effectively neutralizing persistent attackers.

Set Up Threat Intelligence Feeds

Configure VistoShield's threat intelligence feeds to automatically download and apply updated blocklists. Unlike CSF's static blocklist configuration, VistoShield manages feed subscriptions with automatic refresh intervals, deduplication, and expiration handling.

Enable File Integrity Monitoring

Deploy the Security Scanner across WordPress sites to monitor for unauthorized file changes. This catches compromises that network-level firewalls cannot detect, such as injected backdoors in plugin files or modified WordPress core files.

Configure the Activity Log

The Activity Log provides an audit trail that is essential for multi-user hosting environments. It tracks which users logged in, what changes they made, which plugins they installed, and when configuration was modified. This information is invaluable for diagnosing security incidents and meeting compliance requirements.

Troubleshooting Common Migration Issues

Service Connectivity After Switchover

If a service becomes unreachable after activating VistoShield, check the port configuration first:

# List all allowed ports
vistoshield config --show ports

# Check if a specific port is allowed
vistoshield config --check-port 2222/tcp

# Temporarily allow a port if needed
vistoshield allow --port 2222/tcp

Locked Out of SSH

If you lock yourself out of SSH, use your hosting provider's out-of-band console (IPMI/KVM) to access the server and either whitelist your IP or temporarily disable the firewall:

# Emergency: disable firewall temporarily
vistoshield deactivate

# Then whitelist your IP and reactivate
vistoshield allow --ip YOUR_IP --comment "Admin access"
vistoshield activate

DirectAdmin Plugin Not Showing

If the VistoShield panel does not appear in DirectAdmin after installation, verify the plugin registration:

# Check VistoShield DirectAdmin plugin status
vistoshield directadmin --status

# Reinstall the DirectAdmin plugin component
vistoshield directadmin --install

High Number of Blocks After Migration

If you see a spike in blocked connections after migration, review the block log to distinguish between legitimate threats and false positives:

# View recent blocks with details
vistoshield log --blocks --since 1h --verbose

# Check if any whitelisted IPs are being blocked
vistoshield log --blocks --check-whitelist

Key Takeaways

Migrating from CSF to VistoShield on DirectAdmin is a straightforward process with the migration tool handling configuration import. The result is a modern security stack that protects both the server infrastructure and the WordPress sites running on it.

• Preparation is essential: Document your CSF configuration, back up allow/deny lists, and note open ports before starting.
• Use audit mode: Run VistoShield in audit mode alongside CSF for at least 24 hours to verify behavior.
• Have out-of-band access: Always ensure you can access your server through a method that does not depend on firewall rules.
• Enable WordPress protection: After server migration, deploy the WordPress Edition to gain application-layer security that CSF never provided.
• Progressive hardening: Use VistoShield's advanced features — bot detection, progressive lockouts, file integrity monitoring — to improve your security posture beyond what CSF offered.
• Complete the transition: Remove CSF after a successful migration period to avoid legacy iptables compatibility issues.

For detailed command references and advanced configuration options, visit the VistoShield documentation. If you are evaluating VistoShield against other CSF alternatives, see our comprehensive comparison of CSF alternatives.