[146504] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Ok; let's have the "Does DNAT contribute to Security" argument

daemon@ATHENA.MIT.EDU (Cameron Byrne)
Tue Nov 15 00:42:36 2011

In-Reply-To: <155340.1321334485@turing-police.cc.vt.edu>
Date: Mon, 14 Nov 2011 21:41:25 -0800
From: Cameron Byrne <cb.list6@gmail.com>
To: Valdis.Kletnieks@vt.edu
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On Nov 14, 2011 9:22 PM, <Valdis.Kletnieks@vt.edu> wrote:
>
> On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
>
> > Using two firewalls in serial from two different vendors doubles the
> > complexity. Yet it almost always improves security: fat fingers on one
> > firewall rarely repeat the same way on the second and a rogue packet
> > must pass both.
>

Complexity equals downtime. I know at least one definition of security
includes availability .

> Fat fingers are actually not the biggest issue - a far bigger problem are
brain
> failures.  If you thought opening port 197 was a good idea, you will have
done
> it on both firewalls.  And it doesn't even help to run automated config
> checkers - because you'll have marked port 197 as "good" in there as
well. ;)
>
> And it doesn't even help with fat-finger issues anyhow, because you
*know* that
> if your firewall admin is any good, they'll just write a script that
loads both
> firewalls from a master config file - and then proceed to fat-finger said
> config file.

And, stateful firewalls are a very common dos vector.  Attacking firewall
sessions per second capacity and blowing up a session table can bring a
service down real quick. Furthermore, firewalls are frequently installed at
a choke point ... Which makes them a topological single point of
failure.... So, they are deployed in pairs .... And therefore have a nice
cascading failure behavior when hit with a dos.

Cb

home help back first fref pref prev next nref lref last post