[c-nsp] ASA Firewalls placement in the network!

[Ge Moua]

>> The worst thing you can do is put a stateful firewall in front of a 
busy DNS server - every single packet creating new state will bring
most hardware-based firewalls to their knees, because "session churn"
is usually handled at much lower packet rate as "pure packet throughput
for existing state"...


I concur and have battle scar to attest for this; we tried to put a 
stateful firewall in front of our public NTP server (which also happen 
to be our DNS servers) and the firewall tipped over within 5 minutes; 
state tables got exhausted quick.

- Ge

Univ of Mn







Gert Doering wrote:
> Hi,
>
> On Fri, Oct 09, 2009 at 10:06:49PM -0500, Brian Johnson wrote:
>   
>> So are you actually saying that DPI is a bad thing relative to server
>> protection? What makes this a bad idea? In what way does it make them
>> more vulnerable to attacks?
>>     
>
> Well, the point of a well-maintained server is that it is *open* to
> the world - if you want a web server to be visible by the world, then
> there isn't much you can do, besides "open HTTP to it".  And other
> services should not be running in the first place.
>
> So, if you put a fiewall in front of a well-maintained server, all you 
> add is "extra state table handling" with all the problems it brings 
> - state table overflow (=new connections getting dropped), state getting 
> desynchronized with the server, firewall CPU exploding long before the
> server is hitting any load boundaries, and worst of all, weaknesses in
> the firewall products that can be used to crash the firewall, DoSing
> the server.
>
> The worst thing you can do is put a stateful firewall in front of a 
> busy DNS server - every single packet creating new state will bring
> most hardware-based firewalls to their knees, because "session churn"
> is usually handled at much lower packet rate as "pure packet throughput
> for existing state"...
>
>
> Now, for a typical "office network", things look different, because you
> don't have that stringent control over the machines behind the firewall
> (so you never know who installed what application on their machine), and
> the typical direction for connection setup is different (outbound 
> connection = state handling is needed for the return packets).
>
>
> Your example of "crafted packets that crash the server but can be handled
> by the firewall" brings up the interesting question why one would upgrade
> the firewall (to recognize this packet), but not the server (to be not
> vulnerable to the bad packet in the first place)... - and *that* is 
> what I meant by "well-maintained server" in the first paragraph.
>
> Now, if your servers are not hardened enough, I'm happy to sell you a 
> firewall to put in front of it - but it won't do zilch against the next 
> buggy PHP application that will be used to exploit the server via 
> perfectly nice HTTP requests - no crafted packets, just bad applications...
>
>
> (I'm also one of those people that think the claim "NAT will improve
> your security" was true 10 years ago, but wont't help at all for
> todays security issues - browser exploits, e-mail viruses, etc.)
>
> gert
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/