...

...

...

...

"rq" == Rob Quinn <rquinn@sec.sprint.net> writes:

...

When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go.

rq> Probably. And I would certainly rate "clueful people" _far_ rq> above a firewall when it comes times to prioritize your security rq> needs and resources. Mind having a talk with my management?

...

chose a resilient and flame tested daemon, and watch the patchlist for it.

rq> You've never seen a security vendor come out with a patch or rq> workaround before an application vendor? Sure. Sometimes they come out with patches that wouldn't be needed if you didn't have the firewall ;) Stateful firewalls also suffer from state propagation problems. High bandwidth redundant links and firewalls don't get along well together. Some firewall packages will allow you to statelessly pass high bandwidth traffic (tcp,udp/53) in the DNS example, which helps with load management and failover. But then you're back to where you were without the firewall. Decent IDSes run on spanning ports against your uplinks, decent logging on packet filtering routers, etc will all give you the benefits of the firewall. In general, and IDS is a better IDS than a firewall, and so forth. The primay benefit of firewalls is simplicity of configuration, and the ability to allow outbound services without opening huge inbound holes (tcp,udp/53, tcp/20, udp > 1023, etc). This is generally not the case with deployed ISP servers. Finally, the "crunchy ouside" thing takes over way too often. Management is lulled into a happy place by the word "firewall", and even good security engineers get lazy. I realize that this is 100% a meat problem, but it's a problem either way. ericb -- Eric Brandwine | If people are good only because they fear punishment, UUNetwork Security | and hope for reward, then we are a sorry lot indeed. ericb@uu.net | +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E