How a Denial-Of-Service Attack Works #1
The old school way
TCP is a protocol which all web servers must implement, but the specification, or rather the exact implementation of the specification, has flaws which an attacker can abuse. It’s actually fairly easy to create an attacking application, however most Routers and Servers implement a simple fix. Also, Windows has for sometime had security measures to prevent a user (knowingly or unknowingly) create TCP packets in the manner I’m about to describe.
I’ve chosen to write about the TCP-Flood DOS attack methodology because it’s one of the longest standing forms of attack that even some modern-day systems are surprisingly susceptible to, even though router manufacturers have long since known how to circumvent the issues. Furthermore, it’s interesting to me because this is something I’ve known about for a long time that a majority of people have no idea how it works - or how a single attacker on a single machine can do so much damage.
The Critical Headers
All web servers must implement TCP for HTTP to be successful, and it’s within the header-structure of a TCP packet where the vulnerability lies. According to the TCP spec - when handshaking occurs the client must send a packet (SYN), to which the server will acknowledge the response (SYN-ACK) - the client will then respond with an acknowledgement of its acknowledgement (ACK).
For me, that’s a bit over-verbose and something as basic as a network call shouldn’t need to check & double-check.
When the attacker sends their first message the Router or Server will typically send their response and store the clients details in a buffer - the connection (or port) is left in a “half-open” state. That port/session must expire or be acknowledged correctly by the client/attacker in order for it to be released.
Lack of Response
The problem is a result of these “half-open” connections, since a server can only have “so-many” ports/sessions open at any one time, or the buffer that stores the initial client/attacker request may be saturated. The effect is that any new connections are then denied - hence Denial of Service.
All the attacker has to do is spoof/forge the TCP packets to present a different originating address, and send a flood of the “SYN” open connection packets - hence TCP Flood
The Solution
I’m led to believe that hardware manufacturers had a problem combatting this for a while - doing things like increasing buffer sizes and decreasing session times to make the symptoms of this style of DOS attack short-lived. However, both approaches are useless if the attacker floods too much
The resolution is to simply never open a connection, nor remember the client details until the third step (ACK) has been received. Which in my opinion is a correction of the deficiencies of the initial TCP spec.