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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:04:05 PDT