Understanding DDoS Attacks: From Packet Floods to Application Layer Strikes

1. Anatomy of an Attack

Imagine you own a popular pizza shop. You built a phone line that can handle 10 orders at once. Suddenly, a rival hires 1,000 bots to call your shop simultaneously. They order nothing; they just breathe into the phone, hang up, and call again. Real customers get a busy signal. Your business stops. You are technically "open," but effectively closed.

This is a DDoS (Distributed Denial of Service) attack. "Distributed" means the attack comes from many sources simultaneously (Botnet), making it impossible to stop by just blocking one IP address.

2. Attack Vectors Explained

Attackers use different weapons depending on what they want to break.

The Sledgehammer: Volumetric Attacks (Layer 3/4)

The goal is to consume all available bandwidth or connection slots.

• UDP Flood: The attacker sends vast amounts of UDP garbage traffic to random ports. The server checks for an application at that port, finds none, and replies with "ICMP Destination Unreachable". Doing this millions of times overwhelms the firewall/server.
• SYN Flood: The attacker initiates a TCP connection (SYN) but never completes the handshake (no ACK). The server waits... and waits... storing this half-open connection in RAM. Eventually, RAM fills up, and the server stops accepting new connections (Backlog Queue Saturation).
• DNS Amplification: The attacker asks a public DNS server "Tell me everything about google.com" (a small request) but spoofs the return address to be your server's IP. The DNS server sends a massive response to you. The attacker turns a 1kb request into a 50kb attack (50x amplification).

The Sniper: Application Attacks (Layer 7)

The goal is to crash the web server process (Apache, Nginx) or the Database.

• HTTP Flood: Looks like legitimate traffic. A botnet requests GET /search?q=very_complex_query thousands of times. It forces your DB to calculate expensive joins/sorts until CPU hits 100%. If you haven't optimized your DB queries, you are an easy target.
• Slowloris: The attacker opens a connection and sends an HTTP header: X-Header: a... waits 10 seconds... b... waits 10 seconds... c. The server keeps the thread open, waiting for the header to finish. A small laptop can take down a massive web server by tying up all its threads this way. It requires very little bandwidth but is highly effective against Thread-based servers like Apache.

3. Defense Strategies (Shields Up)

You cannot defeat a DDoS attack with a single firewall rule. You need a multi-layered approach.

1. Cloud & CDN (The Sponge)

If an attack is 500 Gbps, and your pipe is 10 Gbps, you lose. Period. You need a bigger pipe. CDNs like Cloudflare, Akamai, AWS CloudFront have multi-Tbps capacity. They sit in front of your server. They act as a giant sponge, absorbing the flood. Only filtered, legitimate requests are forwarded to your origin server. This is called Scrubbing.

2. Anycast Routing (Divide and Conquer)

In a Unicast network, one IP = one physical server. All traffic goes there. In an Anycast network, one IP = hundreds of servers around the world. The network routes traffic to the physically nearest server. If a botnet in Russia attacks, the traffic goes to the Russian data center. A botnet in Brazil hits the Brazil center. The attack is diluted across the global infrastructure, making it manageable. It turns a tsunami into manageable waves.

3. Blackholing and Sinkholing

• Blackholing (Null Routing): When an IP is under heavy attack, the ISP routes all traffic for that IP into a "black hole" (drops it). The target goes offline, but at least the rest of the network survives. This is a last resort.
• Sinkholing: Redirecting malicious traffic to a specific server (Sinkhole) for analysis. Security researchers use this to study botnets.

4. Rate Limiting and WAF

• Rate Limiting: "Allow strictly 10 requests per second per IP for the login endpoint." This stops brute-force attacks and simple flooders.
• WAF (Web Application Firewall): Inspects the content of the request. It can block SQL injections, XSS attempts, and known bot user-agents.
• Challenges: Modern defenses challenge suspicious IPs with a CAPTCHA or JavaScript challenge instead of just blocking them. Real browsers pass; dumb bots fail.

4. What Developers Can Do

While network engineers fight the floods, developers can harden the application (Layer 7).

• Cache aggressively: Serve static HTML for landing pages. A cached page takes almost 0 CPU to serve. Use Stale-While-Revalidate.
• Optimize expensive endpoints: If /report/yearly-stats takes 5 seconds to run, an attacker will hammer it. Isolate it (Microservices) or cache it heavily.
• Timeouts: Configure your web server (Nginx/Apache) to drop connections that are too slow (countering Slowloris). Set client_body_timeout and client_header_timeout to low values.
• Hide Origin IP: If you use Cloudflare, configure your firewall (AWS Security Group) to only accept traffic from Cloudflare's IP ranges. If an attacker finds your real IP, they can bypass the CDN protections.

5. Under Attack? What Now?

If you are currently under attack, don't panic.

1. Enable "Under Attack Mode": If you are using Cloudflare, turn this on. It will present a JS challenge to every visitor for 5 seconds. It kills user experience (UX), but it saves the site.
2. Analyze Logs: Look at your Nginx/Apache logs. tail -f access.log | grep 200 Look for patterns. Are they all hitting /login? Are they all using the same User-Agent "Python-urllib"?
3. Contact Support: If you are on AWS or GCP, open a high-priority ticket. They have bigger guns than you do.

6. Case Study: The GitHub Attack (2018)

To understand the scale, let's look at the famous GitHub incident. In Feb 2018, GitHub was hit by a massive 1.35 Tbps attack. Attackers used Memcached Amplification. They sent tiny packets to unsecured Memcached servers, which replied with massive responses (50,000x amplification) directed at GitHub.

How did GitHub survive? Within 10 minutes, they routed their traffic through Akamai Prolexic. Akamai's global infrastructure absorbed the 1.35 Tbps tsunami like a sponge. The site was back online in 20 minutes. This proved that even the biggest attacks can be mitigated if you have enough bandwidth (and budget).

7. Common Myths about DDoS

1. "I'm too small to be a target."
   • False. Script kiddies attack random IPs just for fun or practice. Bots scan the entire internet. You are a target just by being online.
2. "My Firewall will stop it."
   • False. Traditional firewalls (Stateful Firewalls) track connections. A DDoS attack can exhaust the firewall's state table, causing the firewall itself to crash before your server does. You need stateless mitigation.
3. "I can block the attacker's IP."
   • False. In a Distributed attack, there are 100,000 IPs. You cannot block them manually. You need automated behavioral analysis.

8. Conclusion

DDoS attacks are a fact of life on the internet. They are cheap to launch (you can rent a botnet for $50) but expensive to defend against. The best defense is Architecture. By moving your static assets to CDNs, hiding your origin, and implementing smart caching, you make your application resilient not just to attacks, but to legitimate traffic spikes (like being featured on Reddit/Hacker News). Security and Performance often go hand-in-hand. If your site is fast and efficient, it's harder to take down.