Re: Firewall RISKS

["Stephen P. Berry" <spb () incyte com>]

-----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-----