DDoS protection for
DirectAdmin servers

Back to Blog

DirectAdmin's Place in the Hosting Stack

DirectAdmin has carved out a significant share of the hosting control panel market by being the opposite of cPanel: lightweight, affordable, and resource-efficient. Where a cPanel server idles at 400-600 MB of RAM with all its services running, a DirectAdmin server with comparable functionality runs closer to 200-300 MB. The licensing cost difference is even more dramatic since cPanel moved to per-account pricing. For hosting providers selling budget shared hosting or reseller packages, DirectAdmin is often the only economically viable option.

This lightweight footprint is an advantage for hosting density, allowing you to run more accounts per server, but it creates a false sense of security. DirectAdmin's efficiency means the server has more headroom during normal operations, which can mask the early stages of a DDoS attack. Where a cPanel server might show high CPU at 5,000 concurrent connections because cPHulk, cpsrvd, and various monitoring daemons are already consuming resources, a DirectAdmin server might absorb 5,000 connections without visible degradation. The attack only becomes apparent at higher volumes, by which point mitigation is harder.

DirectAdmin also runs a smaller community than cPanel, which means fewer third-party security plugins, fewer guides on DDoS hardening, and less collective operational knowledge about handling attacks. Most DA administrators find themselves adapting cPanel-oriented guides to their environment, which does not always translate cleanly.

DirectAdmin-Specific Attack Surfaces

Port 2222: The Admin Interface

DirectAdmin's web interface runs on port 2222 by default. Unlike cPanel's separate ports for admin and user interfaces, DirectAdmin serves all access levels through a single port. Admin, reseller, and user logins all go through port 2222, and the interface rendered depends on the account's privilege level. This consolidation means a single port handles all control panel traffic, making it a concentrated target.

The DirectAdmin process (directadmin) handles connections directly rather than proxying through Apache or Nginx. While this is efficient, it means the DA daemon itself is the bottleneck. A connection flood against port 2222 exhausts DirectAdmin's connection handling capacity, locking out all users: admins, resellers, and end users alike. Unlike a web server that can be independently scaled with worker processes, DirectAdmin's connection handling is tied to a single daemon.

# Check DirectAdmin's current connection count
ss -ntp state established '( dport = 2222 or sport = 2222 )' | wc -l

# Watch connection rate in real time
watch -n1 "ss -ntp state established '( dport = 2222 )' | awk '{print \$5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10"

Port 53: DNS Services

DirectAdmin servers commonly run BIND (named) for DNS hosting. DNS is one of the most exploited protocols in DDoS attacks, both as a target and as an amplification vector. An open recursive resolver on a DA server can be abused to amplify attacks against other targets. Even with recursion disabled, authoritative DNS query floods can consume significant CPU and bandwidth.

DA's DNS configuration in /etc/named.conf often uses default settings that do not include rate limiting. BIND 9.9+ supports Response Rate Limiting (RRL), but it is not enabled by default on most DA installations.

# Check if your BIND allows recursion (bad)
dig @localhost google.com

# Add rate limiting to BIND on DirectAdmin
# In /etc/named.conf, inside the options block:
options {
    rate-limit {
        responses-per-second 10;
        window 5;
    };
    # Disable recursion for authoritative-only servers
    recursion no;
    allow-query { any; };
};

Mail Ports (25, 110, 143, 465, 587, 993, 995)

DirectAdmin supports both Exim and Dovecot for mail services. The mail stack on a DA server exposes seven ports minimum. SMTP connection floods against port 25 are among the most common attacks against hosting servers because every SMTP connection triggers process spawning, DNS lookups for reverse resolution, and potentially SpamAssassin processing before the connection is even authenticated.

Web Services (80, 443)

DA supports Apache, Nginx, OpenLiteSpeed, and LiteSpeed Enterprise as web servers. The web ports face the same HTTP flood risks as any hosting server, with WordPress-heavy environments being particularly vulnerable to attacks targeting xmlrpc.php, wp-login.php, and wp-cron.php.

DirectAdmin's Built-in Brute Force Protection

DirectAdmin includes a built-in brute force monitor that tracks failed login attempts and blocks offending IPs. The configuration lives in /usr/local/directadmin/data/admin/brute_force.conf. It watches for failed SSH, FTP, DirectAdmin panel, and mail logins, blocking IPs that exceed configured thresholds.

# Default brute_force.conf settings
ip_blacklist=10
ip_whitelist=5
user_blacklist=20
unblock_minutes=1440

# These settings mean:
# Block IP after 10 failed attempts from same IP
# Block user after 20 failed attempts on same username
# Auto-unblock after 1440 minutes (24 hours)

This is useful for blocking credential stuffing attacks, but it has the same limitation as cPHulk on cPanel: it only processes authentication failures. A request flood that does not attempt to authenticate, just hitting the login page or other endpoints repeatedly, will not trigger brute force protection. The attacker does not need to fail a login. They just need to send requests.

The brute force monitor also operates reactively. It waits for failed attempts to accumulate before blocking. A distributed attack using 10,000 IPs with each IP making only 5 attempts stays under the threshold while still generating 50,000 authentication requests. Each request consumes server resources even though no single IP triggers a block.

ConfigServer Firewall on DirectAdmin

CSF supports DirectAdmin and integrates with it for IP block management and login failure tracking. The installation process on DA is straightforward:

# Install CSF on DirectAdmin
cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

# CSF auto-detects DirectAdmin and configures integration
# Verify DA integration
cat /etc/csf/csf.conf | grep DIRECTADMIN
# Should show: DIRECTADMIN = "1"

With CSF on DirectAdmin, you get the same firewall capabilities as on cPanel: SYN flood protection via syncookies, connection tracking limits, port flood detection, and login failure integration. But the limitations are identical too. CSF is a host-based firewall that processes packets after they arrive. Volumetric attacks saturate the network port regardless of how many iptables rules CSF applies.

CSF Configuration Tuning for DA Servers

# /etc/csf/csf.conf optimizations for DirectAdmin

# Enable SYN flood protection
SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

# Connection tracking limits
CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_PORTS = "22,25,53,80,110,143,443,465,587,993,995,2222"

# Port flood detection for DirectAdmin port
PORTFLOOD = "22;tcp;5;300,2222;tcp;20;5,80;tcp;50;5,443;tcp;50;5"

# This limits:
# SSH: 5 connections per 300 seconds per IP
# DA panel: 20 connections per 5 seconds per IP
# HTTP/HTTPS: 50 connections per 5 seconds per IP

# Enable process tracking to catch runaway processes during attacks
PT_LIMIT = "0"
PT_USERMEM = "512"
PT_USERTIME = "1800"

DA's Lightweight Footprint: An Advantage for Detection

Here is where DirectAdmin's design philosophy actually helps with DDoS protection. Because DA consumes fewer resources than cPanel, there is more CPU and memory headroom available for running a detection agent alongside the control panel. On a server with 8 GB of RAM, cPanel and its associated services might consume 3-4 GB at idle, leaving 4-5 GB for hosted accounts and any additional tools. DirectAdmin in the same configuration consumes 1-2 GB, leaving 6-7 GB for workloads.

A traffic monitoring agent that captures and analyzes packet metadata needs CPU cycles for packet processing and memory for storing traffic baselines. On a resource-constrained cPanel server, this overhead can be the difference between the server coping under moderate load and the server swapping to disk. On a DirectAdmin server with its leaner profile, the same agent has minimal impact.

Practical Hardening Checklist for DirectAdmin

Restrict DirectAdmin Panel Access

# Option 1: Change DA to listen only on a specific IP
# In /usr/local/directadmin/conf/directadmin.conf
serverip=10.0.0.1
# This makes DA only accessible via the private IP

# Option 2: Use iptables to restrict port 2222
iptables -A INPUT -p tcp --dport 2222 -s 198.51.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 2222 -j DROP

# Option 3: With CSF, remove 2222 from TCP_IN and use csf.allow
# /etc/csf/csf.allow
tcp|in|d=2222|s=198.51.100.0/24

Harden the Web Server

If running Nginx (which is increasingly common on DA), add rate limiting at the web server level as an additional layer:

# In nginx.conf (DirectAdmin CustomBuild Nginx config)
http {
    # Define rate limit zones
    limit_req_zone $binary_remote_addr zone=general:10m rate=30r/s;
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;
    limit_conn_zone $binary_remote_addr zone=connlimit:10m;

    server {
        # General rate limit
        limit_req zone=general burst=60 nodelay;
        limit_conn connlimit 50;

        # Stricter limit for WordPress login
        location ~* wp-login\.php {
            limit_req zone=login burst=5 nodelay;
            proxy_pass http://backend;
        }

        # Block xmlrpc.php entirely if not needed
        location = /xmlrpc.php {
            return 444;
        }
    }
}

Protect DNS Services

# If the server is authoritative-only (not a resolver):
# Disable recursion in /etc/named.conf
recursion no;

# Add rate limiting
rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

# If you don't host DNS on this server at all:
systemctl stop named && systemctl disable named
# Remove ports 53 from CSF TCP_IN and UDP_IN

Kernel-Level Protection

# /etc/sysctl.d/99-da-ddos.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.netfilter.nf_conntrack_max = 524288
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.core.somaxconn = 65536

# Apply
# sysctl -p /etc/sysctl.d/99-da-ddos.conf

Deploying Detection on DirectAdmin Servers

Installing a detection agent on a DirectAdmin server is simpler than on cPanel because there are fewer services to conflict with. DA does not have the equivalent of cPHulk's aggressive connection monitoring, so there is no risk of the detection agent's connections being flagged as suspicious.

# Install the agent
pip install ftagent
ftagent init --server-id da-server-01 --api-key your-key

# Verify it runs alongside DA services
systemctl status ftagent
systemctl status directadmin

# Check resource usage (should be minimal)
ps aux | grep ftagent
# Typical: 0.5-1.5% CPU, 30-50MB RAM

The agent's resource footprint is particularly well-suited for DirectAdmin environments. Where DA's philosophy is "do more with less," a bloated monitoring tool would undermine the whole point of choosing DA over cPanel. The detection layer should match the control panel's ethos: effective, lightweight, and non-intrusive.

The Full Protection Stack for DirectAdmin

Putting it all together, a properly protected DirectAdmin server has these layers:

1. Upstream mitigation: A hosting provider or scrubbing service that can handle volumetric floods before they reach your port
2. Network-level detection: An agent monitoring all interfaces at per-second granularity, with automated signaling to trigger upstream mitigation
3. CSF with tuned rules: SYNFLOOD enabled, PORTFLOOD configured for DA-specific ports, CT_LIMIT set appropriately for your server's account density
4. Kernel hardening: SYN cookies, increased conntrack limits, reduced timeouts
5. Web server rate limiting: Nginx or Apache rate limits for request and connection rates
6. DNS hardening: Recursion disabled, RRL enabled, or DNS service disabled entirely if not needed
7. DA brute force monitor: Configured with appropriate thresholds for your environment
8. Attack surface reduction: Panel port restricted to management IPs, unused services disabled, FTP replaced with SFTP

DirectAdmin's lightweight nature is a genuine advantage here. The total overhead of CSF plus a detection agent on a DA server is roughly equivalent to the overhead of cPHulk alone on a cPanel server. You get more protection with less resource consumption, which is exactly the tradeoff that led you to choose DirectAdmin in the first place.

The weak link in most DirectAdmin DDoS strategies is the gap between detection and mitigation. CSF detects connection patterns at 30-second intervals. The brute force monitor detects authentication failures after they happen. Neither detects a volumetric flood in progress. Bridging that gap with real-time, per-second traffic analysis is what turns a "hardened server" into a "protected server." Without that detection layer, you are relying on your hosting provider to notice the attack and act, which might take minutes you do not have.

Back to Blog

Related Articles