How to Detect a DDoS Attack on a Linux Server via CLI Tools

 

When your Linux server load suddenly spikes, guessing the cause is not an option. Your websites slow down, APIs time out, and even your SSH connection might begin to lag. In these critical moments, you need to know immediately whether you are dealing with a legitimate traffic surge, a misbehaving internal application, or a Distributed Denial-of-Service (DDoS) attack.

This tutorial provides a hands-on, step-by-step guide to diagnosing malicious traffic using standard Linux command-line utilities.

1. Monitor Network Interface Traffic (Volumetric Attacks)

The most common form of a DDoS attack is a volumetric flood. Before digging into your web server logs, you should check the raw traffic hitting your network interfaces.

Monitor Real-Time Bandwidth with iftop 

Run the following command: sudo iftop -n (Note: The -n flag prevents DNS resolution, which is crucial during an attack because DNS lookups will severely slow down the tool)

Check Packets Per Second (PPS) with sar 

Sometimes an attack overloads the network card with millions of tiny packets. sar -n DEV 1 If your inbound traffic (RX) or PPS is pinned to its absolute limit, yet your server's CPU usage remains relatively normal, this indicates a Layer 3 network-level flood.

2. Analyze Active Connections and TCP States (Protocol Attacks)

If your bandwidth is not completely saturated but legitimate users are still failing to connect, the attacker is likely exhausting your server's TCP state tables.

Count Total Connections by IP Address 

ss -H -tn | awk '{print $5}' | sed 's/:[^:]*$//' | sort | uniq -c | sort -nr | head -10

Detect a SYN Flood Attack A SYN flood repeatedly sends initial connection requests (SYN) but never completes the TCP handshake. To count connections stuck in the SYN_RECV state: ss -H -n -t state syn-recv | wc -l (Pro-Tip: To get a rapid summary of your current TCP states without locking up your terminal, simply type ss -s)

3. Inspect Web Server Access Logs (Layer 7 HTTP Floods)

If your network bandwidth looks fine and your TCP connections are stable, but your server's CPU or memory is maxed out, you might be facing an Application-layer attack.

Find the Most Hammered URLs (Nginx Example): 

tail -n 10000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

Identify the Top Attacking IPs via Web Logs: 

tail -n 10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10




4. Defense and Upstream Mitigation

Once the observed traffic patterns are consistent with a DDoS attack, you can begin mitigation to stabilize your server.

• Block specific attacking IPs using iptables: sudo iptables -A INPUT -s ATTACKER_IP -j DROP

• Enable TCP SYN Cookies: sudo sysctl -w net.ipv4.tcp_syncookies=1

The Limits of Local Server Defense: 

While commands like iptables are useful for blocking small-scale or targeted attacks, a software firewall on your server cannot stop a volumetric DDoS attack. If an attacker sends a 50Gbps flood to your 1Gbps interface, dropping packets at the OS level still means the pipe is clogged.

To survive large-scale volumetric or complex multi-vector DDoS attacks, malicious traffic must be filtered before it ever reaches your server. This requires upstream traffic scrubbing or migrating to infrastructure that features always-on, high-capacity network-level mitigation.

View Full Tutorial: How to Detect a DDoS Attack on a Linux Server Using Command-Line Tools