Firewall Wizards mailing list archives
Re: Firewall RISKS
From: "Stephen P. Berry" <spb () incyte com>
Date: Wed, 16 Jun 1999 17:44:23 -0700
-----BEGIN PGP SIGNED MESSAGE----- In message <609B8FA424F9D111A91A00805FD71EE2CF46EA@dslexxch3.spsxch>, kevin.she ldrake () baedsl co uk writes:
If we assume that we are trying to protect against hackers and DoS attacks from the outside network (internet), we are assuming that the attacks are being made against flaws in the software running the services on the machines. These flaws are generally accidentally introduced into the software and the testing that is performed pre-release either does not show them up or the software is released with known bugs pending fixes. Due to this, you are statistically likely to be running flawed software (maybe not to the extent that they can be exploited, but certainly to not provide functionality exactly as specified/required/offered.) A firewall and packet filter will firstly limit the services available to the outside world to the ones you wish to allow (it is certainly possible that you haven't realised that rshd is running until it is exploited); and secondly, it can perform protocol analysis in order to spot and drop illegal attacks.
Consider: (most) firewalls are (at least partially) software. Iterate your argument. [I'll forgo discussion of the bogus `statistically likely' argument] In any case: stipulated. Yes, bad software gets written. Let's, just for grins, posit that the latest bind (which is source available) and the lastest squid (also source available)[1] are more buggy than your average firewall product (which probably isn't going to be source available)[2], and work (below) on this hypothesis.
As extra credit, what is the failure mode in the scenario you present, how do you control it, and how does this compare to the firewall-less scenario?
What you are doing is shifting your trust from the operating systems of your working machines to the firewall that was built purely to implement a security policy. It is likely, then, that the firewall will be more resiliant to attacks than your working machines.
This isn't an answer to the question(s) I ask above. At any rate, I'm not sure that professed intent in a design can be assumed to be translated into functionality in the implementation. In fact, I'm pretty sure it can't be. Anyone familiar with the historical record will be able to supply counterexamples to your argument. That being said, you are correct in suggesting that having a specific design goal in mind can be valuable---or indeed necessary---in implementing a security solution. It's not clear that this isn't just as true for application-level daemons as it is for firewalls---which is what you seem to be suggesting.
Trivially, I'd say a workable no-firewall setup given the above [removed] constraints would be to simply multihome whatever servers need to be exposed to both the internet and the internal network (i.e., bind 8.x, a squid server, u.s.w.). Secure them appropriately. Have all your desktop toys talk to the internal interfaces of these boxen.
The problem here is that you are running probably flawed services directly to the internet where every hacker can attack them. I think your basic ignorance is shown in the 'Secure them appropriately' statement - either that or you're having a laugh. Maybe I am not party to this new technology that can secure software - do you have a reference to it?
You could start with `man chroot'. As far as exposing `probably flawed' services to the Outside, it isn't clear what you think your firewall is going to do for you. If you're just doing packet filtering, chances are you're not buying yourself anything except (perhaps) having another IP stack between the bad guy and your appication[3]. If you're using an application gateway, all you're doing is relying on it instead of the application itself. Whether or not this is a good bet[4] will depend on the application and the proxy in question. In any case, this scenario is vulnerable to the same argument you're trying to use to recommend it. Anyway, when I say you should secure your servers appropriately, the process involves things like OS selection, choosing the application, making sure the two play well together, uninstalling everything that isn't necessary to the service the machine will be providing, running the daemon in a chroot if possible, setting up auditing, leaving whatever tricks and traps are appropriate, and so forth. Let me give you a ferinstance. Go to (one of) your DNS server(s). Is telnet(1) installed? If so, why? Is inetd(8) running? If so, why? How many people have access to the machine, and how often do they log in? Do you allow remote access to the machines (as opposed to requiring login on the console), and if so why? What sort of audit trail is left when someone logs in? Just something left in {u|w}tmp? Something sent to syslog(2)? Ever consider modifying login(1) to send a mail message whenever it's executed[5]? How about sh(1)? Or ls(1)? My point is that if you're setting up your DNS server/MTA/HTTP proxy/whatever by just doing a `./config;make;make install', you're probably Wrong[6].
(I assume that should the gateway server be successfully attacked, routing could then be turned on allowing routed access to your internal, insecure machines.)
This would be true if your firewall was compromised. If an attacker compromised one of the multihomed servers, they could try to get it to route traffic between the two segments. If you've set up the machine (and the segments) appropriately, this should be nontrivial and is something that should leave an hell of an audit trail. Anyway, I'll reiterate at this point that I'm -not- suggesting that firewalls are useless or that they shouldn't be used or anything of the sort. My contention is simply that they are not the be-all, end-all of IT security as appears to be generally (and devoutly) believed. You can implement sane security policies without the use of firewalls. - -Steve - ----- 1 Just because those are the ones I'd explicitly mentioned previously. 2 `Average firewall product' here will probably mean `commercial firewall product'. In fact, given the last market-share statistics I've seen, it would probably mean `Firewall-1'. But the actual product is irrelevant (since I'm stipulating it's less buggy than our application-level daemons)---I'm just grousing to indicate that I think this happens to be a fairly lousy thing to be stipulating. 3 Which, mind you, can be useful in some circumstances. But given that we're talking about a machine that's being configured for the express purpose of providing some particular service, you should be able to choose an IP stack in which you have some confidence (i.e., a selection process similar to the one you'd go through in choosing the firewall OS). So I think this (too) falls under the `frequently useful but not essential' category. 4 Or, for that matter, whether or not it will even affect the outcome of any given exploit attempt. 5 Or something else similar. I.e., have a daemon running that will halt the system if it isn't handed some sort of nonce within n seconds of a successful login. I'm not, mind you, suggesting that such things are appropriate in all circumstances. You're arguing that firewalls are good at containment. Sure enough. But there are other (in some cases better) ways of doing containment. 6 And if you're using a GUI to install it...but, no...best not to think of such things. That way madness lies. 7 This is the famous recursive footnote[7]. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN2hESSrw2ePTkM9BAQHBJQP+M6ema8hpxXPZQ3Qwnak/GV8W8nkURmAW XIzaEpsk4dqSQ2CTu9D+tyfYwsh7HyYQtu/vRyhZ3jhrm/+Os/hn+RzOmQQ7tgIT 4GLzL+MrBiSlZTaVoESFuekDREh4ifBbTRN2aOGs/9HZT3ByRqnyNcj1TZUuTT2S WOxyyGLWkNs= =u6ji -----END PGP SIGNATURE-----
Current thread:
- Re: Firewall RISKS, (continued)
- 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)
- RE: Firewall RISKS Sheldrake, Kevin (Jun 25)
- Re: Firewall RISKS MIKE SHAW (Jun 28)