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:
- Re: Transfering off-system firewall audit trails, (continued)
- Re: Transfering off-system firewall audit trails Lance Spitzner (Jun 15)
- Re: Transfering off-system firewall audit trails Christoph Schneeberger (Jun 16)
- Re: Transfering off-system firewall audit trails Richard Rees (Jun 15)
- eSafe Protect desktop experince Mark Lemmo (Jun 14)
- Re: Firewall RISKS Stephen P. Berry (Jun 14)
- Re: Firewall RISKS char sample (Jun 04)
- Re: Firewall RISKS ark (Jun 04)
- Re: Firewall RISKS MIKE SHAW (Jun 04)
- Re: Firewall RISKS Stephen P. Berry (Jun 14)
- Re: Firewall RISKS Stephen P. Berry (Jun 14)
- Re: Firewall RISKS MIKE SHAW (Jun 14)
- Re: Firewall RISKS MIKE SHAW (Jun 15)
- Re: Firewall RISKS Tim Kramer (Jun 16)
- Re: Firewall RISKS Stephen P. Berry (Jun 15)
- RE: Firewall RISKS kevin . sheldrake (Jun 16)
- Re: Firewall RISKS Stephen P. Berry (Jun 20)
- RE: Firewall RISKS andrew . c . howard (Jun 16)
- RE: Firewall RISKS kevin . sheldrake (Jun 20)
- Re: Firewall RISKS Stephen P. Berry (Jun 21)
- RE: Firewall RISKS Sheldrake, Kevin (Jun 23)
- Re: Firewall RISKS Stephen P. Berry (Jun 23)