Secure an IIS Web server with these 10 steps

by Guest Contributor | Mar 10, 2006 8:00:00 AM

Tags: Web server, Guest Contributor, server, Internet information service, Internet, Microsoft IIS Server

Takeaway: Follow these 10 steps as a foundation for locking down IIS.

Submitted by Chaim Fried

Problem

Internet Information Services (IIS) is a favorite target of hackers. Thus, it's critical for administrators who manage IIS Web servers to make sure that they are locked down. The default installations of IIS 4.0 and IIS 5.0 are particularly vulnerable.

Solution

Take these 10 steps to secure IIS:

Set up an NTFS drive just for the IIS application and data. If possible, don't allow IUSER (or whatever the anonymous username is) access to any of the other drives. If the application runs into any problems because the anonymous user doesn't have access to programs on the other drive(s), then use FileMon from Sysinternals to troubleshoot which file it can't access and try working around it by moving the program to the IIS drive. If that is impossible, then allow IUSER access just to that file.
Set the NTFS permissions on the drive:
Developers = Full
IUSER = Read and execute only
System and admin = Full
Use a software firewall to make sure that none of the end users (only the developers) have access to any other port on the IIS machine besides port 80.
Use the Microsoft tools for locking down the machine: IIS Lockdown and UrlScan.
Enable logging using IIS. In addition to the IIS logging, if possible, use logging from the firewall as well.
Move the logs from the default location, and make sure that they are being backed up. Set up a replication for the log folders so that a copy is always available in a second location.
Enable Windows auditing on the machine, because there is never enough data when trying to backtrack any attacker's activity. It's even possible to have a script run to check for any suspicious activity using the audit logs, and then send a report to an administrator. Now this might sound a bit extreme, but if security is really important in your organization, this type of action is a good practice. Set up auditing to report any failed account logons. Plus, as with the IIS logs, change the default location (c:\winnt\system32\config\secevent.log) to a different location, and make sure that you have a backup and a replicated copy.
On a regular basis, go through as many security articles (from various sources) as you can. It is always better that you understand as much as possible about IIS and general security practices and not just follow what others (like me) tell you.
Sign up to a mailing list for IIS bugs and stay up to date in reading it. One such list is X-Force Alerts and Advisories from Internet Security Systems.
Finally, make sure that you regularly run Windows Update and verify that the patches actually get deployed.