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:

  1. 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.
  2. Set
    the NTFS permissions on the drive:
    Developers = Full
    IUSER = Read and execute only
    System and admin = Full
  3. 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.
  4. Use the
    Microsoft tools for locking down the machine: IIS Lockdown
    and UrlScan.
  5. Enable
    logging using IIS. In addition to the IIS logging, if possible, use
    logging from the firewall as well.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Finally,
    make sure that you regularly run Windows Update and verify that the
    patches actually get deployed.
Next Steps: Build your skills with these hand-picked resources
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Maximize IIS logging to track user activity
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Take advantage of the IIS ‘What If’ security tool
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Fifteen tips for properly securing IIS Web servers (TechProGuild)
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Use these tools to tighten security in IIS (TechProGuild)
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Microsoft: Hardening IIS Servers
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Guide to the Secure Configuration and Administration of IIS 5.0
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=IIS Security Checklist
>” width=”8″ height=”10″ align=”absmiddle”><br />
 <a target=Hardening an IIS 4.0 Web Server