[120900] in North American Network Operators' Group
Re: I don't need no stinking firewall!
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Wed Jan 6 00:42:32 2010
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Date: Wed, 6 Jan 2010 05:41:40 +0000
In-Reply-To: <1262752784-sup-6499@sfo.thejof.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote:
> However, the "well managed" part seems to be a sticking point for most or=
ganizations I've seen. No doubt, shops that use this effectively have some =
sort of homebrew or commercial firewall management platform that let's you =
place policy in one place and make sure that it's pushed out
> properly.
Concur 100% - all the commercial systems which have purported to do this to=
date have been unusable, miserable failures. Folks tend to use homegrown =
systems, starting with something as basic as RCS.
Tom Ptacek over at Matasano is working on a firewall/ACL rules management s=
ystem which, given his track record of innovation, one hopes may buck this =
trend.
> Why so? Because of something this does to the device doing the rate limit=
ing (I assume an upstream router of some sort), or because it renders the a=
ttack successful?
The latter.
DDoS attacks are attacks against capacity and/or state. Start reducing cap=
acity, and you end up making it even easier for the attacker's programatica=
lly-generated attack traffic to 'crowd out' the legitimate user traffic.
It's self-defeating.
;>
> I'm not so sure I follow you here. How does a "fundamental architectural
> premise" (I assume you mean keeping track of application-layer session
> state) *preclude* it from being placed in front of a server? Sure,
> it's a poor use of raw silicon and electrical power, but why does that
> rule out in advance placing it in front of a server?
Because, by definition, all incoming packets to the server are unsolicited.=
Therefore, it's a waste of money, and also forms a DDoS chokepoint due to=
the non-infinite state-table which forms the basis for said stateful firew=
alling.
It will fall over and die under any kind of serious attack.
> In theory though, someone could construct a massive state-tracking machin=
e that can still keep track of stateful traffic, Mpps and above.
See above; in front of the server, there's no state to track in the first p=
lace, heh. =20
Fish, meet bicycle.
;>
Additionally, it becomes an impractical physics problem (physical dimension=
s, logic density, power consumption, heat dissipation, et. al.) to construc=
t a device which could even plausibly attempt this due to the extreme capac=
ity/resource asymmetry which favors the attacker (i.e., botnets with thousa=
nds, tens of thousands, hundreds of thousands, and even millions of comprom=
ised hosts).
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
