"We're under DDoS" covers several different attacks with different signatures and different answers. Worth separating them.
Key Takeaways
- Layer 4 floods exhaust connections, sockets, or bandwidth. Layer 7 floods exhaust your application while every request looks legitimate.
- A host-based agent cannot mitigate a volumetric attack. If the uplink is saturated, the bandwidth is gone before your server sees a packet.
- What a host agent does well is application-layer abuse and attacks from identifiable sources, where blocking genuinely stops it.
- Telling the two apart is the operational decision that matters: one you handle, the other means calling your provider.
- Fixed thresholds are wrong for every server except the one you tuned them on. Baseline per server and alert on deviation.
Table of Contents
- Layer 4: connection and packet floods
- Layer 7: application floods
- Telling them apart quickly
- What a host agent can and cannot do
- Detection before mitigation
Layer 4: connection and packet floods
SYN flood - half-open connections exhausting the backlog. Check:
ss -s
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn
A large SYN_RECV count relative to ESTABLISHED is the tell. Connection exhaustion - many complete connections held open, consuming file descriptors and worker slots. UDP flood - bandwidth saturation, usually visible as inbound traffic far exceeding anything your application would generate.
Confirming saturation rather than guessing
Interface counters tell you whether the pipe itself is the problem:
ip -s link show
cat /proc/net/dev
Sample twice a few seconds apart and compare. If inbound bytes are climbing at close to your link capacity, this is volumetric and nothing you do on the host will change it. Your provider's bandwidth graph is the more trustworthy source here, because it sits outside the server and is unaffected by whatever the box is struggling with. Also worth checking whether the kernel is dropping traffic before your application ever sees it:
netstat -s | grep -iE "listen|overflow|drop"
Listen queue overflows mean connections are arriving faster than your application accepts them, which points at connection exhaustion rather than raw bandwidth.
Layer 7: application floods
Harder, because every request looks legitimate in isolation.
HTTP flood - high request rate against expensive endpoints. Search pages and anything hitting the database are favourite targets.
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
Scanner probes - requests for /wp-admin, /.env, /phpmyadmin on a server running none of them. Not a flood exactly, but the same source usually escalates.
WordPress brute force - repeated POSTs to wp-login.php or xmlrpc.php.
Finding which endpoint is being hit
Source counts tell you who. Path counts tell you what it is costing you:
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '$9 >= 500 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
The second command surfaces the endpoints already failing under load, which is usually where the attack is aimed. A flood against a cached static page is survivable; the same volume against a search endpoint that queries the database is not.
The trap with proxies and tunnels
If traffic reaches you through Cloudflare, a load balancer, or a tunnel, every request arrives from a small set of proxy addresses. Counting connecting addresses then produces what looks like a flood from a handful of sources when it is simply all your normal users arriving through one door.
Read the forwarded client address instead, and only trust that header from your known proxy ranges. Getting this wrong in either direction is costly: you either miss real attacks or block an edge node and take out a slice of legitimate traffic. The wider set of failure modes is in how automated IP blocking works and how it goes wrong.
Telling them apart quickly
Under pressure, the useful sequence is short:
-
Is the box reachable at all? If SSH is unusable and interface counters are pinned, this is volumetric. Stop investigating and contact your provider.
-
Is CPU high or is the application waiting? High CPU in application workers points at Layer 7. Low CPU with a full listen queue points at connection exhaustion.
-
How many distinct sources? A few hundred is blockable. Tens of thousands is not, and needs upstream handling.
-
Is one endpoint disproportionately hit? That is Layer 7, and rate limiting that specific path often resolves it faster than blocking sources.
What a host agent can and cannot do
Be clear about this, because vendors are not. A host-based agent cannot mitigate a volumetric DDoS. If your uplink is saturated, the packets have already consumed the bandwidth before anything on the server sees them. That mitigation has to happen upstream - at your provider, or behind a scrubbing service.
What a host agent does well is the attacks where the source is identifiable and the volume is survivable: application-layer floods, credential stuffing, scanner probes, and brute force. There, blocking the source IP genuinely stops the attack.
Distinguishing the two matters operationally. If you are seeing an HTTP flood from a few hundred sources, blocking works. If your interface counters are pinned and the box is unreachable, no agent will save you and you need to be on the phone to your provider.
This is worth restating because the marketing in this category is consistently dishonest about it. Claims that a host agent performs traffic scrubbing or absorbs volumetric spikes describe something physically impossible, the traffic has already arrived. When evaluating any platform, ask specifically which of these two cases it addresses, as covered in Linux server security as a service: a buying guide.
Detection before mitigation
Either way, you need to know it is happening. Baseline your normal request rate, connection counts, and inbound bandwidth, then alert on deviation, not on fixed thresholds, which are wrong for every server except the one you tuned them on.
There is a second reason detection matters beyond availability. A flood is sometimes cover. While attention is on the traffic, the actual objective may be something quieter happening in parallel, which is why it is worth checking afterwards for the artefacts in how to tell if your Linux server has been compromised rather than closing the incident once traffic returns to normal.
SecAI baselines each server individually and detects both Layer 4 and Layer 7 patterns, auto-blocking identifiable sources while flagging volumetric events that need upstream action. See it alongside the rest of the detection stack. The category-level view is in the guide to Linux server security software.
Frequently Asked Questions
How do I know if it is a real DDoS or just a traffic spike? Look at what the traffic requests. Legitimate spikes distribute across your site the way normal usage does. Attacks concentrate on one path, or arrive with no referrer and no static asset requests.
Can I stop a volumetric attack with iptables? No. Dropping packets at the host does not recover bandwidth already consumed on the link. That has to be handled before the traffic reaches you.
Does a CDN solve this? For volumetric attacks against origin, largely yes, provided your origin address is not publicly discoverable. If attackers can reach the origin directly, the CDN is bypassed.
What is the fastest way to survive an HTTP flood right now? Rate limit the specific endpoint being hit, and serve a cached or static response for it if possible. Blocking sources helps when the source set is small.
Should I enable SYN cookies?
They are enabled by default on most modern distributions and help with SYN floods specifically. Verify with sysctl net.ipv4.tcp_syncookies rather than assuming.
For the automated version, and an honest account of what a host can and cannot do about volumetric traffic, see Linux DDoS detection and host-side mitigation.