Re: basic question about firewall usage
On Fri, 9 May 2003, Jamin W. Collins wrote:
> > > This is only true if you don't provide access to these service
> > > through something such as port-forwarding. In such cases running
> > > the service on the firewall is no different. Sure it's still frown
> > > upon, but lack of
> >
> > Running the service on another machine *is* different, because
> > breaking the service doesn't give the attacker the ability to remove
> > whatever protections the firewall has in place
>
> Incorrect. If a service is flawed to allow a cracker to gain access,
> and is not running in a DMZ chances are they now have free reign of your
> network. Sure the firewall is running on another machine but that makes
> little difference.
Assuming a moderately clueful firewall, the attacker will be limited to
fux0ring with your machines, and won't be able to make nearly so much use of
your machines as relays for other attacks. The attacker can install as many
proxies and backdoors as s/h/it likes, but they'll be useless because the
firewall should prevent access to them.
Sure, not too much of a comfort if your company's financial data just went
walking out the (metaphorical) door, but still far better than giving an
attacker even freer reign over your network.
Imagine, for example, that in order for the attacker to get in, they need to
crash apache in some way. Somebody's likely to notice that sort of thing.
Without a firewall (or with a firewall the attacker can fux0r with) they can
punch a hole, install a backdoor, and then restart apache. Downtime? A
couple of minutes. But you're thoroughly r00ted, because s/h/it can get
back in any time they like from now on, with you being none the wiser.
With a real firewall in place, to get in to your machine to do any damage,
they've got to crash apache each time and get in that way. "Somebody's
gonna notice..."
> > - for instance, the attacker can't fire up a proxy on another port and
> > start running spam and DoS attacks through it, because your firewall
> > will[1] be denying connections to all ports on the protected machines
> > except those it knows it should be allowing. If you're port
> > forwarding, then unknown ports just bounce off your firewall's closed
> > ports.
>
> This only works if you're restrictive about the traffic you let out. If
> the box providing the services (or any other box on your internal
> network) is allowed to make outbound requests, the cracker can simply
> contect out to bypass the firewall.
Which still limits their ability to cause havoc, as I've outlined
above.
> > It comes down to what you're looking to protect in the main - your
> > machines, or your reputation on the internet. If it's your machines,
> > then cut your internet cable, because allowing any service is a
> > potential in on (at least) that machine. Segregating every
> > externally-accessible machine into it's own little DMZ will control
> > the damage, but not eliminate it.
>
> A properly configured DMZ can not initiate an outbound connection of any
Since it's a network design, it'd have a hard time initiating anything...
<g>
> kind (to the internal network or the external Internet). Thus, an
> individual gaining access to a DMZ'd machine has access to only that
> machine and nothing else. Personally, I see a DMZ as acceptable.
If you're attacking my arguments to make a DMZ look more acceptable, don't
bother. I know DMZs are a good thing, and for anyone watching this at home:
If you can possibly wangle it, put all externally accessible machines in a
DMZ which is totally untrusted by everything else. Treat your external
servers as though they were already cracked.
All I'm saying is that servers on the regular internal network, secured by a
serviceless firewall, are still better than externally accessible services
on the firewall itself. I hope you'll agree with that.
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
Reply to: