I don't need no stinking firewall!

James Hess mysidia at gmail.com
Wed Jan 6 07:47:24 UTC 2010

On Tue, Jan 5, 2010 at 11:41 PM, Dobbins, Roland <rdobbins at 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

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

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...


More information about the NANOG mailing list