Introduction
Security Vulnerabilities
Baseline Security Measures
Hardening IIS Web Servers
Conclusion
Reference

<< Back to Network & Internet Security

_____________

• Vulnerabilities that lead to buffer overflow conditions, resulting in denial of service or execution of rogue commands or programs on the server that houses the IIS Web server.
  
  
• Default sample pages are installed and usually are never removed. These sample pages have bugs that can allow unauthorized remote read-write access to any file on an IIS Web server, or unauthorized execution of remote programs on the server.
  
  
• By default, IIS installs the Web root directory on the system drive, potentially allowing any user to obtain access to (and possibly modify, depending on the assigned permissions and whether or not certain bugs have been fixed) system files.
  
  
• The IIS Web server does not always restrict user access to a specific point in the file system and below. Several vulnerabilities can allow unauthorized access to a higher point in the file system than is normally allowed (a “directory traversal problem”).
  
  
• If the IIS Web service runs on the same system that houses a Windows NT or Windows 2000 domain controller, Web users are authenticated as Domain Users. Attacks can result in unauthorized access to domain resources, even if the Guest account is disabled. 
  
  
• Anonymous accounts, IUSR_<servername> (and in IIS 5.0 and 5.1, IWAM_<servername>) are created when IIS is installed. These accounts are prime targets for attack because they can be accessed by means other than through Web access (e.g., telnet) and may (especially in IIS 4.0) have easy-to-guess passwords.
  
  
• The IIS Web server frequently does not properly check input that it receives. A malicious user may be able to send specially formatted input (e.g., a URL) that results in an unauthorized ability to read files (including files that contain source code) for which public access has not been permitted, to change passwords without authorization, or to cause the server to crash.

• Run as recent a version of IIS (ideally, IIS 5.0 or 5.1) as possible.  Generally speaking, the more recent the version, the fewer the number of security-related bugs.
  
  
• Install the latest Service Pack (SP) on each Windows NT/2000 host that houses each IIS Web server. On Windows NT servers the most recent one is SP6a. On Windows 2000 servers Service Pack 2 is the most recent one. You can obtain both SPs from
http://www.lbl.gov/download/


• Install the latest hotfixes, many of which fix IIS vulnerabilities.
  
  
You can download the Windows NT post-SP6a hotfixes from http://www.lbl.gov/downloads/


For IIS 5.0 running on Windows 2000 with SP3, you can also download post SP3 hotfixes from http://www.lbl.gov/download/

Similarly, for IIS 5.1 running on Windows XP with SP1, you can download post-SP1 hotfixes using the same URL.


Included in the bundled post-SP fixes at the lbl.gov site is the following extremely important one (which you do not need to install because it is already in the bundled fixes):


MS02-62 (the latest cumulative IIS patch)



• In general, avoid installing an IIS Web server on the same physical platform as a domain controller, especially if the domain controller is in a demilitarized zone (DMZ) but the rest of the domain is within an internal network. The reason is that the IIS Web server introduces a much greater than average level of security-related risk. Attackers could exploit IIS vulnerabilities to gain SYSTEM-level access on the Windows NT/2000/XP platform that houses the IIS Web server, then use this access to conquer the rest of the domain. A well-established principle of network security is to make every machine on a DMZ a “throwaway” machine—access to a DMZ machine should be independent of access to all other machines within the network.



• Enable the type(s) of authentication that are appropriate. In IIS 4.0 there are three types of authentication: anonymous (appropriate for public Web servers), challenge-response (appropriate if users have Internet Explorer browsers), and basic (cleartext). Challenge-response authentication is the most secure, but it for the most part does not work with any browsers but IE. IIS 5.X offers five authentication options, several of which are stronger than any in IIS 4.0: anonymous, basic, digest (which uses a strong hashing algorithm to hash the password that is sent from the browser to the Web server), integrated Windows authentication (which works in connection with Kerberos), NTLM (challenge response), and client certificate-based authentication (which is based on SSL, Secure Sockets Layer encryption).
  
  
• Avoid installing an IIS Web server on the system drive (where all the system files reside by default [1]. There are simply too many ways for attackers to work their way up the file system past wwwroot (or whatever the default Web server directory is).
  
  
• Dedicate the partition on which your Web server resides to Web services and nothing else. If not, attackers may be able to exploit IIS vulnerabilities to reach other applications and/or data. 
  
  
• (In IIS 4.0 only [2]) Enable automatic password synchronization in the Internet Security Manager, then change the password for the IUSR_<server name> account to a difficult-to-guess password.  Doing this will not affect Web users at all because their browsers will still be able to obtain and submit this password when they need to do so. Changing this password to a difficult-to-guess password will greatly reduce the likelihood that someone will be able to break into the IUSR_<server name> (and in IIS 5 the IWAM_<server name>) account.
  
  
• Rename the IUSR_ <server name> (and in IIS 5 the IWAM_<server name>) account to add an extra barrier to attackers (who otherwise might immediately begin attacking the IUSR_ and/or IWAM_ account). 
  
  
• Always format each Web-accessible partition as an NTFS partition. If any volume is FAT-formatted, enter:
  
  
convert <partition letter>: /fs:ntfs

For example, to make the d: partition into NTFS partition, enter:

convert d: /fs:ntfs


• Use NTFS permissions to lock down access to the Web server. NTFS permissions are always enforced, regardless of any IIS-specific permissions (see next bullet). Assign a No Access permission to the entire file system structure to the IUSR_<servername> (and, in IIS 5, the IWAM_<server name>) account, then remove this permission from the specific files and directories that you want the anonymous user (i.e., IUSR and, in IIS 5.X, IWAM) to be able to access. In general, limit any access assigned to either of these accounts to Read Only. Do not assign Write permissions to either account unless Web users specifically need to write to one or more pages within the Web server. Avoid assigning any permission other than Read or Write to anyone but Administrators.
  
  
• Set up access for the anonymous user by granting access to Web server resources via the IUSR_ and, in IIS 5.X, IWAM_ accounts. Do not grant access via the ever dangerous Everyone and/or Guest groups.
  
  
•  As an additional precaution against possible runaway access by Web users, use the Internet Service Manager to set the appropriate type of IIS access permissions. In IIS 5.0 go to the Internet Service Manager, highlight the Web server, right click to Properties, then click on Home Directory. Four access options will now appear. Read enables users to read but not add or modify files within a directory, Write (be wary of this one) enables users to modify contents of files and directories and to change attributes, Script Source Access (be wary of this one, too) enables users to get to script file source (but it also requires Read and Write permissions), and Directory Browsing lets users read files in a physical directory, provided that no default page for that directory exists.
  
  
• Ensure that IUSR_ (and, in IIS 5.X, IWAM_) cannot write to critical parts of the Registry in the Windows NT/2000/XP host on which your IIS Web server is installed. In particular, check the permissions for HKEY_LOCAL_MACHINE\Software and everything below it. Remove anything other than Read access for IUSR_ and/or IWAM_. 
  
  
• When you install IIS, a default directory with a path <partition letter>:\Inetpub is created. Subdirectories below Inetpub store content such as Web server files, HTML files, and a directory called “WWWROOT” (the default directory that holds the default document shown to Web users). The default document in the WWWROOT directory is the default home page for the Web site. DEFAULT.HTM within this directory is the actual home page (that is, the document that, if present, comes up on client browsers when users reach a Web site). WWWROOT, not some higher-level directory, needs to be the root directory for Web access for security’s sake. Create subdirectories below this directory to hold the Web server's executables. The advantage is that if an attacker gains unauthorized access to one part of the Web server, that person still will not be able to immediately access every file and directory within the Web server—a component of a good “defense in depth” strategy.
  
  
• Remove (or at least restrict access to Administrators only by setting appropriate NTFS permissions) command-line tools that might be useful to a perpetrator. At a minimum remove or drastically restrict access to:
  
  
-cmd.exe
-net.exe
-ftp.exe
-cacls.exe


• Ensure that connection logging is enabled and set up properly. Note that in the IIS Web server logging is by default enabled. In IIS 5.0, bring up Properties for the Web server (as described earlier), then click on the Web Site tab. In general, have the log data written to a file in W3C format (or, in special cases, a SQL or ODBC database format if the log data are to be written to an SQL or ODBC database, respectively). If you want log data sent to a SQL/ODBC database, enter the data source name, database table name, and a username and password (to access the database). Now click on the Properties box. If log data written are to be written to a file, specify whether you want a new file that contains the log data to be opened daily, weekly, monthly, or when it reaches a size that you designate (e.g., 50 MB). Also specify the name of the directory in which all these files will be placed.
  
  
• Check your Web server's logs regularly to ensure that your Web server is not being flooded with connections from one address or is not being accessed by sites from which attacks are known to originate.
  
  
• If feasible, remove the \IISADMIN directory and all files within it. The only real downside associated with doing this measure is that IIS-based remote password administration (which requires the \IISADMIN directory) could be disrupted. Chances are, however, you do not need this method of remote password administration.

• Avoid creating virtual directories. Although virtual directories are advantageous for disk space utilization purposes, various bugs in IIS may allow users to discover virtual directory paths, then associate those paths with the physical file system, leading to unauthorized access to system and other files.
  
  
• Use delegation to pare down superuser privileges in each IIS Web server as well as in the underlying operating system. If a Webmaster does not need full Administrator privileges to get one's tasks done, assign Operator-level privileges (which are less than the Administrator’s, but greater than a user's privileges) to that person. In IIS 5.0 do this by going to the Internet Service Manager, highlighting the Web server, right clicking to Properties, and clicking on the Operators tab. Add the names of any users to whom Operator-level privileges are to be assigned. 
  
  
• IIS has logging capabilities that are independent of the Windows NT/2000/XP Event Logging. Enable Windows NT/2000/XP Security Logging (especially File and Object Access to files not intended for user Web access and Use of User Rights), then regularly check the Security Log of each system on which an IIS Web server runs to ensure that access by users is appropriate. If anonymous IIS logons occur, regularly verify that IUSR_<server name> (and, in IIS 5, the IWAM_<server name>) account in each system's Security Log is not engaging in actions such as attempting to modify system files and using rights such as setting up shares.
  
  
• Enable IP address filtering within IIS. You can use this feature to block out undesirable source IP addresses, such as IP addresses of sites that have previously attacked your Web server. At the same time, however, it is important to realize that an IP address in a packet header alone may or may not indicate the real source address of any host (except with IPSec, the secure version of the IP protocol). In IIS 5.0 bring up the Internet Security Manager, go to Properties on the Web server, then to Directory Security, then to IP Address and Domain Name Restrictions. Determine for each IP address or address range specified (through clicking on the Add option) whether to allow or deny access to the Web server.
  
  
• Enable SSL Encryption on the Web server. Enabling SSL encryption requires first obtaining a digital certificate from a certification authority (CA) such as Verisign (http://www.verisign.com). (Note that you can obtain server but not client certificates from rootca.lbl.gov.) The Internet Security Manager helps by generating a key request. Contact the CA to request a certificate. After the CA approves the application and sends a key, install the new key using the Internet Security Manager. In IIS 5.0, highlight the Web site, right click to Properties, and then go to Directory Security to Secure Communications to enable SSL. It is also necessary to enable SSL security for every directory intended for access on the Web server. Every SSL client that connects with every directory for which you have set SSL encryption will obtain an encrypted connection. In IIS 4.0 installing SSL is considerably more complicated—refer to Chapter 8 of Windows NT/2000 Network Security (SCHU00).
  
  
• Ensure that Front Page extensions have appropriate NTFS permissions. In general, avoid Write permissions above all else. Better yet, but only if feasible, disable Front Page extensions altogether by entering the following commands using the command prompt:
  
  
cd \Program Files\Common Files\Microsoft Shared\Web Server Extensions\40\bin

fpsrvadm -o uninstall -p all

• Disable NetBIOS on the Windows NT/2000 machine that houses your IIS server. In Windows NT systems go to the Control Panel and then double click on Network. Click on the Bindings tab, then highlight NetBIOS Interface, then click on Disable, then reboot. Do this for every network interface for the platform that houses your IIS Web server. In Windows 2000 go to My Network Places and right click to Properties. Go to Local Area Network and right click to Properties. Highlight File and Printer Sharing for Microsoft Networks, then click on Uninstall. The downside is that any methods of remote Web server administration based on NetBIOS will break. Fortunately, few such methods of remote Web server administration are even available in the first place.

Footnotes