North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: I don't need no stinking firewall!
- From: James Hess
- Date: Wed Jan 06 02:50:03 2010
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
|
