40. DoS and DDoS – Availability Attacks
40.3 Protocol Attacks – SYN Flood and Handshake Abuse
TCP three-way handshake: SYN → SYN-ACK → ACK. SYN flood = many SYNs, incomplete handshakes, fill half-open connection table → new legitimate clients wait / fail.
Blue classics:
- SYN cookies – encode state in SYN-ACK so huge half-open table not needed the same way
- Conntrack / backlog tuning on Linux (careful; document changes)
- Firewall / load-balancer rate limits on new SYNs per IP
- Prefer cloud LB that already handles common floods
# Concepts on a lab Linux YOU own – see SYN cookie sysctl (read-only first)
sysctl net.ipv4.tcp_syncookies
# Enable on YOUR lab VM only after you understand impact (Amazon Linux style awareness):
# sudo sysctl -w net.ipv4.tcp_syncookies=1
| Red team (attacker) does | Blue team (defender) detects / stops |
|---|---|
| High-rate SYN without completing handshake | SYN cookies; SYN rate limits; border ACL |
| Mix SYN with ACK/RST junk to confuse filters | Stateful firewall + vendor DDoS profiles |
| Targets small appliance with tiny conn table | Move critical VIP behind cloud scrub / larger LB |
Ravindra Bagale's Tip
Students hping3 flags copy-paste karun office Wi-Fi try kartat – criminal risk. Lab host-only IP only. Interview madhe SYN cookie + rate limit bola, "how I flooded GitHub" nako. Ghabru naka – discipline = career.
Lab
On Metasploitable / your lab Linux at 192.168.56.20 (or a disposable nginx VM): note ss -s or netstat -s before. From Kali 192.168.56.10 run a short, low-rate SYN probe only to that host-only IP (trainer-approved count, e.g. few hundred, then stop). Observe half-open growth if any. Enable syncookies / firewall rate rule. Re-test gently. Document. No bridged LAN, no public IP.