DirectAdmin Server Under DDoS: Find the Target and Block It

A DirectAdmin server under DDoS shows the same symptoms as any other overloaded box: load average climbing, Apache or nginx worker processes maxed out, everything sluggish. The difference is that once you confirm it is actually an attack, every account on the server is at risk until you find which domain is the actual target and isolate it.

Confirm it is actually an attack

Start with connection counts per IP. A handful of addresses each holding hundreds of connections open is a strong signal, a few thousand distinct IPs each making a handful of requests looks more like a botnet-driven Layer 7 flood.

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Cross-check against the web server's access log for the same window. If one vhost accounts for the overwhelming majority of requests, you have found your target.

for f in /var/log/httpd/domains/*.log; do echo "$(tail -2000 "$f" | wc -l) $f"; done | sort -rn | head -10

On nginx-fronted DirectAdmin setups the equivalent logs live under /var/log/nginx/domains/. Either way, one file with an order of magnitude more recent lines than the rest confirms the target domain.

Identify the request pattern

Knowing the target domain is not enough to block effectively, you need to know what the requests actually look like so you can write a rule that matches the attack without matching real visitors.

tail -20000 /var/log/httpd/domains/targetdomain.com.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

A flood hammering / or /wp-login.php thousands of times a minute from varied IPs but identical or near-identical user agents is a classic Layer 7 application flood, not a legitimate traffic spike. Legitimate spikes (a product launch, a news mention) spread naturally across many different pages and referrers.

Block it at the firewall and web server level

1. 1

   Enable CSF's SYN flood protection

   In /etc/csf/csf.conf, set SYNFLOOD = "1" along with SYNFLOOD_RATE and SYNFLOOD_BURST tuned to your normal traffic, then csf -r to reload. This drops excess new connections at the kernel level before they reach Apache or nginx.

2. 2

   Rate limit the specific target at the web server

   For Apache, mod_evasive or mod_ratelimit can cap requests per IP per second for the targeted vhost specifically, without touching the rest of the server.

3. 3

   Block the worst offending IPs immediately

   csf -d IP_ADDRESS 'DDoS source, temporary' blocks a single address instantly. For a list, while read ip; do csf -d "$ip"; done < offenders.txt processes it in bulk.

4. 4

   Put the target domain behind a CDN or reverse proxy if the flood continues

   If the attack is large enough to saturate the server's own bandwidth rather than just its application layer, blocking at the server no longer helps, the traffic needs to be absorbed further upstream.

This whole sequence, confirm the target, read the pattern, tune the rate limit, verify load actually drops, takes real judgment under time pressure, and it is the same sequence every time a different domain gets targeted. BashEdge runs this triage automatically at the network edge in front of DirectAdmin, starts in monitor mode so you can see what it would have blocked before it blocks anything, and stops for approval before changing enforcement on a live account.

csf -d IP 'flood source'  # applied per matched IP in the pattern above

Verify the server actually recovered

Load average dropping is the first sign, but confirm the target domain is genuinely serving normal traffic again, not just that the attack traffic stopped hitting logs.

watch -n 5 'uptime; echo ---; netstat -ntu | wc -l'

Load average should settle back to its normal baseline within a few minutes of the block taking effect, and total connection count should stop climbing. If load stays elevated after the flood traffic is confirmed blocked, check for a second, smaller target you may have missed, attacks sometimes probe multiple domains before settling on one.

Prevent the repeat

• Leave CSF's SYN flood protection and connection tracking enabled permanently once tuned, rather than turning it on only during an incident.
• Set conservative default rate limits on login and search endpoints across every hosted domain, these are the most commonly targeted paths.
• Keep an alerting threshold on load average and connection count so you know within minutes, not when a customer calls to say their site is down.