Comments inline. To reiterate- my entire point is that stateful firewalls are at least sometimes useful in front of large websites. Something of a veer off of the original topic, but not an at all useless exercise IMHO. On Mon, Jan 4, 2010 at 11:47 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
* Defense in depth. You've never had a host that received external traffic ever accidentally have iptables or windows firewall turned off? Even when debugging a production outage or on accident?
Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. 'Stateful inspection' where in fact there is no useful state to inspect is pointless.
Stateful policies help protect against misbehaving software, operations error, malicious internal activity, external attackers and trojans/viruses/bots making outbound connections to arbitrary ports anywhere on the Internet. Seems to have a point to me. See my previous point about blocking outbound connections. If you allow internal hosts to make connections out to any port on any ip, then perhaps this point is invalid. But lots of people _don't_ allow outbound from any to any/any, and thats a good thing in my book. As for performance, you can get .9mpps stateful firewalls for reasonable prices, and gear exists that can scale up to 15mpps.
* Location for IDS/IDP.
Non-sequitur, as these things have nothing to do with one another (plus, these devices are useless, anyways, heh).
The gear I'm talking about above supports IDP on the same platform. If I am going to deploy an IDP, why wouldn't I choose one that is flow based so it blocks attacks rather than send out panicked RST's in response to attacks, and which has a stateful firewall included (yes, any flow based IDP is essentially a stateful firewall, and I suspect that a well managed IDP with customized rules is similar in functionality to what WAF's do out of the box. In fact one vendors WAF product functionality pre-trained out of the box is snort rules)
* Connection cleanup, re-assembling fragments, etc.
Far, far, far better and more scalably handled by the hosts themselves and/or load-balancers.
Huh, I would have sworn I've seen fragment based attacks on certain linux kernels and Windows systems. I'm sure it won't ever happen again. Load-balancers may be a good place for this, but there are good reasons that you would prefer to have this taken care of as close to ingress as possible. For example, if you want to compare packet flows of a connection on either side of a load-balancer, it is easier to do that if the incoming connections have already been cleaned up.
* SYN flood protection, etc.
Firewalls simply don't handle this well, marketing claims aside. They crash and burn.
I believe that to have been true in the not so recent past, I don't think it is true of more recent equipment.
* Single choke point to block incoming traffic deemed undesirable.
Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps.
A firewall with easier to use CLI, web UI, management station and API is a much easier way to implement this and offers lots of control for time-of-day based ACL's, etc. etc. I like screening routers, and in a DOS situation I would recommend blocking as close to ingress as possible (preferably outside your own network!) but for typical blocking of nuisance connections, full featured firewalls that can be integrated with a configuration change tracking tool are a better way to go. And what about when the way of identifying undesirable traffic is something other than the source/dest ip/port such as a URI? (more of an argument for an IDP than a simply stateful firewall)
* Single log point for inbound connections for analysis and auditing requirements.
Contextless, arbitrary syslog from firewalls and other such devices is largely useless for this purpose. NetFlow combined with server/app/service logs is the answer to this requirement.
Really? How does netflow show me that a packet was dropped because of rule X? Or permitted because of rule Y? It's great at showing me data about the flow that was extant, but it doesn't tell me the context of the enforcement performed on it. I can assure you that there is a use in looking over denied packet logs. Firewall logs provide _more_ context than netflow. For DOS detection I get that netflow is probably the best tool to use- not arguing that- you made the statement that stateful firewalls are always useless in front of large websites/webservers. I am saying that they are usefull, at least some of the time, and that it is common for them to be deployed in that manner.
* Allows outbound traffic enforcement.
Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps.
So you advocate allowing any packet with ACK set into the internal network? Again, stateful firewalls make this much less of a management headache.
* Allows conditional inbound traffic from specific approved external hosts- e.g. a partner.
Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps.
See above :^)
* Some firewalls allow programmatic modification of configurations with all the benefits/pain that brings. This is alongside traditional CLI and GUI interfaces.
Ugly, brittle, siloed, to be avoided at all costs.
But doing the same thing across hundreds or thousands of web servers via automated systems = good? Personally I like being able to authorize a lower-tech-savvy member of another team to initiate a temporary configuration change via a tool rather than have to wait for the calvary to show up.
* In some/many cases a zone based firewall configuration can be much easier to work with than a large iptables config. Certainly the management tools are better.
Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps.
Huh?
* Yeah, auditors like it.
Education is the answer here.
;>
If only....
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
-- -- Darren Bolding -- -- darren@bolding.org --