Requirements for IPv6 Firewalls

Dobbins, Roland rdobbins at arbor.net
Sat Apr 19 04:10:26 UTC 2014


On Apr 19, 2014, at 10:29 AM, Jeff Kell <jeff-kell at utc.edu> wrote:

> I call BS...

You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, because it's very easy to knock them over due to state exhaustion.  In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts.

Also, you might want to search the NANOG email archive on this topic.  There's lots of previous discussion, which boils down to the fact that serious organizations running serious applications/services don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers.

The only way to secure hosts/applications/service against compromise is via those hosts/applications/services themselves.  Inserting stateful middleboxes doesn't actually accomplish anything to enhance confidentiality and integrity, actually increases the attack surface due to middlebox exploits (read the numerous security notices for various commercial and open-source stateful firewalls for compromise exploits), and has a negative impact on availability.

Again, take a look at this preso:

<https://app.box.com/s/a3oqqlgwe15j8svojvzl>

And take a look at pp. 17-18 of this preso:

<https://app.box.com/s/ko8lk4vlh1835p36na3u>

I've seen 3mb/sec of spoofed SYN-flooding take down a supposedly 20gb/sec stateful firewall due to state exhaustion in about 2 minutes; I've seen 6kpps of HOIC take down a supposedly 10gb/sec load-balancer due to state-table exhaustion in 60 seconds.  Each of those devices required an ~30-minute hard reboot - and those are just two of too many examples to keep track of, heh.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton





More information about the NANOG mailing list