RE: mitigating the lack of a firewall

[David LeBlanc <dleblanc () mindspring com>]

Phil Cox had some good points, but I wanted to add on...

At 09:35 AM 2/15/00 -0800, Starkey, Kyle wrote:
> OK so it isn't that bad, but I would be frightened putting an NT IIS server
> out on the internet standing alone.  This type of a machine, while it can be
> locked down is still pretty vulnerable to stack attacks due to the weak
> stack the MS threw together as an after thought.  

Look up how to harden it against SYN floods.  That's a first step.  Also, a
NT 4.0 box with no patches may be in trouble, but one that has the current
stack is in pretty good shape.  Also, Win2k has the benefit of 20-20
hindsight, and is (IMHO) a better choice.  I'd also turn off multicast.

> If you are going to put
> this box out on the interent all by itself and it was only serving static
> content then I would say this might be OK, but at least block inbound ports
> with some router ACL's to give you that warm cozy feeling.  

I would recommend at least a router in front of it, but even if you do have
a router, using even the rudimentary port filtering to restrict inbound
connections to port 80 is helpful.  I also like running a non-routable
network behind it for administration.

> If this box is
> serving up dynamic content that requires you to reach into the enterprise
> and get some data from your internal DB server, then NO, you should
> definately put it behind a firewall (and ACL's just to be safe).  

Actually, I would try to avoid that configuration regardless of choice of
OS.  If at all possible, I'd push the data out through the firewall.
Pulling data out through the firewall is really risky and hard to do safely
no matter what OS you're running.

> At the
> very least Bruce turn off the netbios connections on all interfaces so that
> some one doesn't walk into your box and suck out the SAM (passwords kept
> here).  

A more effective way to protect the SAM is by running syskey.  I also like
to either move most of the common admin utilities out of system32, or ACL
them to allow access to local admins only - use a specific user or group,
NOT administrators.  LocalSystem is a member of administrators, and IIS
normally runs as LocalSystem and changes user context to IUSR_machine - if
things like net.exe, ftp.exe, etc. are ACL'd such that neither of these
users can run them, it makes it much more difficult even if one assumes
that something bad has happened, and the web server is now executing
command lines as LocalSystem.

Whether and how to disable 137-139 (and 445 on Win2k) depends on your
choice of how to admin the machine - if you need a back-end LAN to admin
it, you shouldn't turn it all off.  I typically use a layered approach -
use the port filtering so that nothing should get to it, unbind NetBIOS
from the external interface, and substantially harden the machine at the
host - set a strong password for the local admin, and in the case of a web
server, it is actually useful to rename the account.

> Also run a vulnerability scanner (ISS, Cybercop, etc.) against it to
> make sure you haven't missed anything, rememeber to not load the sample
> files on IIS.  

You also want to remove all the file associations that you're not using.
If you're not putting anything with a .foo extension (silly example) on
your site, remove the association in IIS.

This isn't a comprehensive list - I don't know if it is still around, but
the PC Week interactive hack 'contest' configuration for NT 4.0 is what I
used when I set up the machine (based on help from several others), and it
did emerge unscathed, so...  Note that that machine was indeed behind a
firewall, but I set it up so that it ought to survive the firewall going open.


David LeBlanc
dleblanc () mindspring com