Firewall Wizards mailing list archives

Re: Firewall RISKS


From: "MIKE SHAW" <mas () sbscorp com>
Date: Tue, 08 Jun 1999 15:23:16 -0500


In any case, even if you do insist on dropping ten toys onto the same
segment as your SMTP/DNS/whatever servers, if you've set them up as
I've described it doesn't really matter.  If I'm not worried about exposing
my DNS server to the world, why would I worry about exposing it to
my internal network[1]?

The point isn't that the DNS server will be vulnerable.  The point is that if you allow any port via a router, that 
port is just one more doorway for any trojans/exploits/backdoors that might end up inside.  Firewalls (via application 
proxy/mail gateways private/public DNS, etc) will close most of these gaps.  Sure you've still got to be on your toes, 
but you have substantially decreased your risk by preventing many things that a router can't touch.

And if you're worried about Bad Things happening to your wintel Boxen
and are expecting a firewall to prevent them, then you're already
suffering from a GCE[2].

Let me reiterate: Firewalls are not a silver bullet, but they prevent the misuse of many of the inherent security flaws 
in TCP/IP.  They can reduce the damage and prevent the success of many trojans/worms/virii.

You seem to be trying to fix an essentially braindead
infrastructure with a firewall.  If you've designed your quote security
unquote architecture such that compromise of a single desktop is
bankrollable into a compromise of the entire enterprise, you've got
problems that firewalls aren't going to solve for you.

Remember what I said about TCP/IP being inherently insecure.  Add to that the insecurities in most major OS' (a couple 
in particular), and then knock the whole thing out of whack by making the system usable to the end user (which 
unfortunately often involves herds of wintel boxes).  This is the real world, and in the real world there is no such 
thing as a non-braindead infrastructure.  You can tighten up your routers 'till the cows come home.  You can patch your 
servers, scan for virii and make a bulletproof security policy.  You know what?  You're STILL vulnerable because the 
system is there to be used, and with that comes the possiblity for misuse.

A firewall is a tool for both eliminating and reducing some of these inherent security problems that come with normal 
use.  If you insist on creating an imaginary world where nobody wants/needs to do anything, I guess a firewall does 
seem pretty silly.  If the solution for auto accidents is to take the tires off your car, then brake pads and a helmet 
seem silly too.  But, given the best (real world) security configuration possible, a Firewall will ALWAYS enhance that 
configuration, and that makes it *essential*.

Don't get me wrong, I happen to think firewalls are just swell for
some applications.  But your assertion that a firewall is an essential
(or rather `*essential*') part of any security infrastructure is just
flat out wrong.

If I'm wrong, then I'm in good company.  Every book I've read, every seminar/class and conference I've been to contain 
firewalls as an integral part of the complete security strategy.  Every site that I've seen that was serious about 
security has one.  Every case study or attempt at hacking I've seen was or would have been made much more difficult by 
an effectively deployed firewall.

And going back to the original post.  An effecively deployed firewall would not have prevented the exploitation of the 
Cold Fusion default script.  But it would have significantly limited the capability to expand the breach, and would 
have aided in tracking the kiddie.

Firewalls -are- mechanisms for policy enforcement.  So is an 8" air gap.
And login(1).  And possibly thumbscrews, depending on your employer's
attitude toward the lusers.

Too medieval.  I'd prefer some sort of shock treatment.  But that's interesing.  Would you argue that a login was not 
an essential part of a securty scheme?

Oh, and haven't you seen the RFC on use of *asterisks*? ; )

-Mike













Current thread: