A DDoS attack isn’t about overwhelming your server with traffic; it’s about overwhelming your network’s ability to handle traffic with traffic.
Imagine a busy highway interchange. A DDoS attack is like a massive, coordinated traffic jam deliberately caused by thousands of cars (malicious requests) suddenly converging on the entrance ramps, blocking any legitimate traffic (your users) from getting through, even if your destination roads (your servers) are perfectly capable of handling them. The goal isn’t to crash the destination, but to make it unreachable.
Here’s how it looks in the wild. Let’s say you’re running a popular e-commerce site. A common attack vector is a UDP flood. Thousands of compromised devices (botnet) send UDP packets to random ports on your server. Your server, expecting legitimate traffic on specific ports, dutifully checks each incoming UDP packet. It finds no application listening on those random ports and generates an ICMP "Destination Unreachable" response for each. The sheer volume of these responses, plus the initial flood, consumes all your available bandwidth and CPU, effectively shutting down your site.
# Example of a server responding to a single UDP packet on an unexpected port
# (This is a simplified representation, actual packet inspection is more complex)
root@server:~# tcpdump -i eth0 udp and port 12345
10:30:01.123456 IP 192.168.1.100.54321 > server.local.12345: UDP, length 100
10:30:01.123460 IP server.local.icmp > 192.168.1.100: Destination Unreachable, Destination Port Unreachable (10.10.10.10)
This UDP flood is just one flavor. Another is a SYN flood. Instead of UDP, attackers send a flood of TCP SYN packets, the first step in establishing a connection. Your server responds with a SYN-ACK, and then waits for the final ACK from the client to complete the handshake. But the attacker’s machines never send the ACK. They just send more SYN packets. Your server keeps all these half-open connections in its memory (the "syn backlog"), waiting for ACKs that will never come. Eventually, this backlog fills up, and your server can’t accept any new legitimate connection requests.
# Monitoring the SYN backlog on a Linux server
root@server:~# netstat -nt | grep SYN_RECV | wc -l
50000 # This number is alarmingly high, indicating a potential SYN flood
Then there are reflection and amplification attacks. These are particularly nasty because they use your bandwidth against you. An attacker spoofs your server’s IP address and sends a small request to a third-party server (like an open DNS resolver) with a request that, when answered, generates a much larger response. For example, sending a DNS query for a large zone file, but originating from your IP. The massive DNS response then floods your network, not the attacker’s.
Attacker -> DNS Server (spoofed from Victim IP)
DNS Server -> Victim IP (massive response)
HTTP floods are more direct. They mimic legitimate web traffic, bombarding your web server with HTTP GET or POST requests. These can be "slowloris" attacks where the attacker keeps connections open by sending partial requests very slowly, or "brute force" requests that overwhelm the application layer by forcing your server to process many resource-intensive queries.
# Example of a simple HTTP GET flood using curl (scaled up massively by a botnet)
# On the attacker side, this would be run from thousands of IPs:
for i in $(seq 1 10000); do curl -s "http://your-target-site.com/index.html" > /dev/null; done
Botnets are the engine behind most large-scale DDoS attacks. These are networks of compromised computers, often infected with malware, controlled remotely by an attacker. Each bot acts as a tiny soldier, ready to unleash traffic on command, making it incredibly hard to block a single source.
Mitigation starts with understanding your network’s capacity. If you know your pipe is 1 Gbps, you can more easily identify when it’s being flooded with 10 Gbps. Network infrastructure like firewalls and intrusion prevention systems (IPS) are the first line of defense. They can be configured to drop packets that don’t conform to expected patterns, rate-limit traffic from suspicious IPs, and block known malicious sources.
# Example: Dropping UDP packets to specific ports if not used by legitimate services
iptables -A INPUT -p udp --dport 12345 -j DROP
# Example: Rate-limiting new TCP connections to prevent SYN floods
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP
For more sophisticated attacks, especially those targeting the application layer or involving reflection/amplification, specialized DDoS mitigation services are crucial. These services use massive global networks of scrubbing centers to absorb and filter malicious traffic before it ever reaches your origin servers. They employ techniques like BGP anycast to distribute traffic across multiple points of presence and advanced anomaly detection to identify and block attack patterns in real-time.
The key to surviving a DDoS attack is resilience and layered defense. You need to be able to absorb some level of attack, detect it quickly, and have mechanisms in place to either block it at the edge or divert traffic to specialized scrubbing centers. Without these, even the most robust application will be rendered useless.
After successfully mitigating a UDP flood, the next common issue you’ll encounter is a SYN flood.