On Tue, Jan 5, 2010 at 11:41 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote: DDoS attacks are attacks against capacity and/or state. Start reducing
DDoS, by its very nature is a type of attack that dances around common security measures like conventional firewalls, by its very nature. The possibility of someone dropping a nuke on your facility, shouldn't stop you from locking your doors at night. If necessary, use another arrangement to detect that threat, and protect firewall+servers from it. Having no 'firewall' type safeguard at all (stateless or otherwise) would appear pretty risky.
Because, by definition, all incoming packets to the server are unsolicited.
For UDP servers sure.. not for TCP.. the initial SYN is unsolicited, for inbound TCP connections. Once the server acknowledges the connection by invoking accept(), the rest of it the packets are solicited, the packets are either part of an active connection, or unwanted. There are other types of noise, 'stealth port scans', port 25, 445, 139, 22 probes, DNS cache poisoning attempts, and sequence prediction, TCP connection hijacking attempts, TCP Reset attempts, LAND attacks, that firewalls protect against (through port randomization), etc.
[...]and also forms a DDoS chokepoint due to the non-infinite state-table which >forms the basis for said stateful firewalling.
The number of states which can be required is not infinite, it's really only a question of how efficient your equipment can be, if you can find suitable choices for your stateful gear. Even if your firewall has a whole 1 gigabit connection, find some stateful firewall, that can efficiently track a maximum of at least 22,321,500 X2 states. (For 100 megabits, a much smaller table will do) Set the connection timeout to an idle time of 15 seconds, so a connection expires if a packet is not received in 15 seconds. The line rate of Gigabit Ethernet is < 1/((0.096+0.064+0.512)*10^-6) => 1488096 pps in each direction. So, even if every single packet is the SYN for a valid new connection, you will not exceed the maximum size of the table based on that rate. In the worst case, you receive 22321440 packets over 15 seconds. On the 16th second, 1488096 connections expire and 1488096 connections are added, since every packet was a new connection. Now relax your timeout reqs according to your preferences _real world_ estimates of maximum connection rate.... "Overflowing the state table" then becomes only a possible outcome that has some acceptable level of probability, assuming that your other protections have already failed... -- -J