Surviving a SYN flood
A SYN flood does not need much bandwidth. It fills your connection table with half-open connections until there is no room for a real one. The defences are well understood.
How it works
The attacker sends a storm of connection openings and never completes them. Each leaves a half-open entry waiting, and once the table is full the server turns away genuine users. It is cheap to send and classically effective against an untuned host — a resource-exhaustion attack, not a bandwidth one, which is why it differs from a volumetric flood.
SYN cookies and tuning
SYN cookies let the server answer without storing state for a half-open connection, reconstructing it only if the handshake completes — so the table cannot be filled by openings that never finish. Combined with a larger backlog, short timeouts for half-open entries, and sane TCP tuning, a host rides out a great deal. Dropping the junk statelessly up front protects the state table.
What we take off your hands
The largest floods are absorbed on our network before they reach your port, as part of the DDoS filtering included with every server — you usually see only a busier graph. Harden the host for what gets through, tell us with timestamps when you are under one, and keep the application's own application-layer defences in place.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base