[120893] in North American Network Operators' Group
Re: I don't need no stinking firewall!
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Tue Jan 5 23:26:56 2010
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Date: Wed, 6 Jan 2010 04:23:28 +0000
In-Reply-To: <alpine.DEB.1.10.1001051609340.23901@castor.opentrend.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 6, 2010, at 4:24 AM, Robert Brockway wrote:
> Hi Roland. I disagree strongly with this position.
You can disagree all you want, but it's still borne out by real-world opera=
tional experience.
;>
> The problem is that your premise is wrong.
Just what about my premise is wrong? Nothing in your message repudiates - =
or even addresses - a single thing I've said.
;>
> Stateful firewalls (hereafter just called firewalls) offer several advan=
tages.
Not in front of servers, they don't.
Clients, yes. Servers, no.
> This list is not necessarily exhaustive.
No, it doesn't include all - or even any - of the reasons firewalls are ina=
ppropriate for placement in front of servers, not by a long shot.
;>
> (1) Security in depth. In an ideal world every packet arriving at a=20
> server would be for a port that is intended to be open and listening.=20
> Unfortunately ports can be opened unintentionally on servers in several=20
> ways: sysadmin error, package management systems pulling in an extra=20
> package which starts a service, etc. By having a firewall in front of th=
e=20
> server we gain security in depth against errors like this.
Stateless ACLs in router/switch hardware capable of handling mpps takes car=
e of this.
> (2) Centralised management of access controls. Many services should only=
=20
> be open to a certain set of source addresses. While this could be manage=
d=20
> on each server we may find that some applications don't support this well=
,=20
> and management of access controls is then spread across any number of=20
> management interfaces. Using a firewall for network access control reduce=
s=20
> the management overhead and chances of error. Even if network access=20
> control is managed on the server, doing it on the firewall offers=20
> additional security in depth.
Stateless ACLs in router/switch hardware capable of handling mpps takes car=
e of this.
>=20
> (3) Outbound access controls. In many cases we want to stop certain type=
s=20
> of outbound traffic. This may contain an intrusion and prevent attacks=20
> against other hosts owned by the organisation or other organisations.=20
> Trying to do outbound access control on the server won't help as if the=20
> server is compromised the attacker can likely get around it.
Stateless ACLs in router/switch hardware capable of handling mpps takes car=
e of this.
> (4) Rate limiting. The ability to rate limit incoming and outgoing data=
=20
> can prevent certain sorts of DoSes.
Rate-limiting during a DDoS - i.e., an attack against state and *capacity* =
- is absolutely the *worst* thing one can possibly do, in almost all circum=
stances.=20
Yet another security myth which is easily disproved via hands-on operationa=
l experience.
=20
> (5) Signature based blocking.
Signatures are obsolete before they're ever created; 15 years of firewalls =
and so-called IDS/'IPS', and the resultant hundreds of millions of botted h=
osts, pretty much put paid to this canard.
> Modern firewalls can be tied to intrusion=20
> prevention systems which will 'raise the shields' in the face of=20
> certain attacks.
These systems are worse than useless, they're actively harmful; they form D=
DoS chokepoints themselves, drastically increase the attack surface, and ca=
n also be gamed.=20
> Many exploits require repeated probing and this provides a way to stop t=
he attack before it is successful.
In the same way that powering off the server ensures perfect confidentialit=
y and integrity of its data, applications, and services.
;>
> Do you have any evidence to support this assertion?
Yes - many years of watching the biggest, baddest firewalls choke and die u=
nder trivial DDoS. Including the better part of a decade working for the =
largest firewall vendor in the world.
> You've just asserted that all firewalls have a specific vulnerability.
No, I've asserted that all stateful firewalls created in the history of the=
world to date, commercial or open-source, are based upon a specific *funda=
mental architectural premise* which precludes their placement in front of s=
ervers. =20
This isn't the same as saying they've a *vulnerability*. I'm saying they'r=
e unsuited to be placed in front of servers.
> I don't see how you can assert they all have this=20
> vulnerability.
Again, I'm not asserting they've a vulnerability. I'm asserting that it do=
esn't make much sense to pound nails with a monkey-wrench.
;>
> In any case, my experience tells me that a DDoS will be successful due to=
=20
> exhaustion of available network capacity before it exhausts the state=20
> table on the firewall.
My experiences defending against DDoS attacks from the 1990s to the present=
nanosecond indicate otherwise.
;>
> Again, I don't believe such a global claim can be made given the wide var=
iety of architectures used for firewalls.
Again, *all* stateful firewalls produced to date share a fundamental archit=
ectural premise which renders them unsuitable for placement in front of ser=
vers.
In fact, one major firewall vendor recently implemented a 'stateful inspect=
ion bypass' feature as a direct result of this issue; apparently, one is su=
pposed to purchase their $100KUSD 10gb/sec stateful firewall, wedge it into=
one's network (forcing artificial and undesirable traffic symmetry in orde=
r to do so) . . . and then *disable* the stateful inspection one supposedly=
purchased it to perform in the first place, heh.
;>
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
