Securing Internet Information Services 5.0 and 5.1

Introduction

Web servers are frequent targets for various types of security attacks. Some of these attacks are serious enough to cause significant damage to business assets, productivity, and customer relationships—and all attacks are inconvenient and frustrating. The security of your Web servers is vital to the success of your business.

This document explains how to begin the process of securing a Web server that is running Internet Information Services (IIS) 5.0 on the Microsoft® Windows® 2000 Server, Standard Edition operating system, or Internet Information Services 5.1 on the Microsoft® Windows® XP operating system. First, this section describes some of the most common threats that affect Web servers. Then, this document provides prescriptive guidance for making your Web server more secure against such attacks.

This document provides the following guidance for increasing the security of your Web server:

•	Reducing the attack surface, or the extent to which your server is exposed to potential attackers, of your Web server
•	Configuring accounts and permissions for the users and groups that access your Web site
•	Making the IIS metabase and log files more secure against access by unauthorized users
•	Configuring Secure Sockets Layer (SSL) on your Web server IMPORTANT: All of the step-by-step instructions that are included in this document were developed by using the Start menu that appears by default when you install your operating system. If you have modified your Start menu, the steps might differ slightly.

After you complete the steps in this document, your Web server will still have significant protection from the following types of attacks that sometimes threaten Internet-facing servers:

•	Profiling attacks that gather information about your Web site, which can be reduced by blocking unneeded ports and disabling unneeded protocols.
•	Denial-of-service attacks that flood your Web server with requests, which can be minimized by applying security patches and software updates.
•	Unauthorized access by a user without the correct permissions, which can often be thwarted by configuring Web and NTFS permissions.
•	Arbitrary execution of malicious code on your Web server, which can be minimized by preventing access to system tools and commands.
•	Elevation of privileges that allows a malicious user to use a high-privileged account to run programs, which can be minimized by using least-privileged service and user accounts.
•	Damage from viruses, worms, and Trojan horses, which can be contained by disabling unneeded functionality, using least-privileged accounts, and promptly applying the latest security patches.

Note: Because securing a Web server is a complex and ongoing process, complete security cannot be guaranteed.

Top of page

Before You Begin

This section explains the system requirements and describes the characteristics of the example Web server used in this document.

System Requirements

The Web server used as an example in this document has the following system requirements:

•

The operating system is installed on an NTFS partition. For information about NTFS, search for "NTFS" in Help and Support Center for Windows Server 2003.

•

Required patches and updates for Windows 2000 Server or Windows XP have been applied to the server.

•

The server is running either Windows 2000 Server, with Service Pack 4 installed, or Windows XP, with Service Pack 1 installed.

IMPORTANT: If Service Pack 1 or Service Pack 4 is not installed on a particular computer or if you do not know whether it is installed, you can go to the Windows Update page on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkID=22630 and have Windows Update scan your computer for available updates. If Service Pack 1 or Service Pack 4 shows up as an available update, install any required service pack before proceeding with the procedures in this document.

The information in this document can help you take the first steps toward configuring a more secure Web server. However, to make your Web server as secure as possible, you need to understand the behavior of the applications that run on the server. This document does not contain information about configuring specific applications for security.

Web Server Characteristics

The Web server that is used as an example in this document has the following characteristics:

•	Is running either IIS 5.0 (for Windows 2000 Server) or IIS 5.1 (for Windows XP).
•	Hosts one Internet-facing Web site.
•	Is a dedicated Web server.
•	Is behind a firewall that allows traffic only on HTTP Port 80 and HTTPS Port 443.
•	Permits anonymous access to the Web site.
•	Serves HTML and ASP pages.
•	Does not support FTP (file uploading and downloading), SMTP (e-mail), or NNTP (newsgroup) protocols.
•	Does not use Internet Security and Acceleration Server.
•	Requires the administrator to log on locally to administer the Web server.

In addition to the preceding requirements, the following conditions in the example exist:

•	FrontPage® 2002 Server Extensions from Microsoft are not configured on the Web server.
•	Applications on the Web server do not require database connectivity.

Top of page

Reducing the Attack Surface of Your Web Server

Begin the process of securing your Web server by reducing its attack surface, for example, by enabling only those components, services, and ports that are necessary for your Web server to operate correctly.

This section provides the following step-by-step instructions for reducing the attack surface of your Web server:

•	Running the IIS Lockdown Tool
•	Customizing the UrlScan configuration

Running the IIS Lockdown Tool

Using the IIS Lockdown Tool, you can choose a specific server role, depending on the types of applications that your Web server hosts, and then improve security for that server by using customized templates that either disable or secure various features.

By running the IIS Lockdown Tool, you can automate much of the process of securing your Web server. However, remember that no tool replaces the need for timely installation of service packs and hot fixes.

Note: It is recommended that you read the documentation that accompanies the IIS Lockdown Tool before you run the tool.

This section provides the following step-by-step instructions for running the IIS Lockdown Tool:

•	Installing the IIS Lockdown Tool
•	Determining whether your Web server serves dynamic content
•	Determining whether the IIS Lockdown Tool has already been run on your Web server
•	Running the IIS Lockdown Tool

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: IIS Lockdown Tool, Internet Services Manager must be installed.

•

To install the IIS Lockdown Tool

Download the IIS Lockdown Tool from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkId=22848.

Click Save to save the file to a local folder on your hard drive, for example, C:\WINNT\system32\inetsrv.

Click Start, click Run, type cmd, and then click OK.

In the command-prompt window, navigate to the location where you saved the IIS Lockdown Tool file, and then type the following command: iislockd.exe/q /c

This command unpacks the following files:

•	IISLockd.chm .This is the compiled help file for the IIS Lockdown Tool.
•	RunLockdUnattended.doc. This file includes instructions for running the IIS Lockdown Tool unattended.
•	UrlScan.exe and associated files. These files install UrlScan. By default, these files are unpacked to C:\WINNT\system32\inetsrv\urlscan. For more information about UrlScan, see "Customizing UrlScan Configuration" later in this document.

•

To determine whether your Web server serves dynamic content

Right-click My Computer on the Desktop, click Explore, and then browse to the directory where the content for your Web server is stored.

Search for the following file name extensions:


.asp	.ida	.idq
.htw	.shtml	.shtm
.stm	.idc	.htr
.cgi	.dll	.exe

If the search returns any items, your Web server serves dynamic content. For example, the Web server used as an example in this chapter serves .asp files, so a search would reveal files with that file-name extension.

•

To determine whether the IIS Lockdown Tool has already been run on your Web server

1.	On the Desktop, right-click My Computer, click Explore, browse to the C:\WINNT\system32\inetsrv folder, and then locate the Oblt-rep.log file.
2.	Browse to the C:\WINNT\|System32\Inetsrv\MetaBack folder, and locate the Oblt-once.md0 and Oblt-mb.md0 files. If these files do not exist, it is likely that the IIS Lockdown Tool has not been run on your Web server. You can continue with the next task, "To run the IIS Lockdown Tool."
3.	To run the IIS Lockdown Tool again, disregarding any previous installations, delete these files or move them to a different location.

If you have already run the IIS Lockdown Tool on your Web server, skip the remaining procedures in this section and go on to the "Configuring UrlScan Configuration" section.

Note: It is recommended that you review the remaining sections of this document to ensure that the IIS Lockdown Tool settings on your Web server provide the level of security that you require.

•

To run the IIS Lockdown Tool

1.	On the Desktop, right-click My Computer, click Explore, and browse to the directory where you stored the IIS Lockdown Tool files, for example, C:\WINNT\system32\inetsrv.
2.	Double-click IISlockd.exe, click Next, read the End User License Agreement (EULA), click I agree, and then click Next.
3.	On the Select Server Template page, click Dynamic Web Server (ASP enabled), select the View template settings check box, and then click Next. Note: Screenshots in this document reflect a test environment, and the information might differ from the information displayed on your screen.
4.	On the Internet Services page, click Remove unselected services, click Yes in response to the Warning message box, and then click Next.
5.	On the Script Maps page, verify that Active Server Pages check box is clear, and then click Next.
6.	On the Additional Security page, ensure that all check boxes are selected, and then click Next.
7.	On the UrlScan page, select the Install UrlScan filter on the server check box, and then click Next.
8.	On the Ready to Apply Settings page, review the changes you selected, and then click Next. Note: To change your selections, click Back, and then make the necessary changes. The IIS Lockdown Tool updates your server configuration based on the options that you specify.
9.	On the Applying Security Settings page, click View Report to view a list of the changes made by the IIS Lockdown Tool, and then click Next.
10.	Click Finish.

Verifying New Settings

Verify that the appropriate security settings for the IIS Lockdown Tool have been applied to your local computer.

•

To verify changes made by the IIS Lockdown Tool

1.	Right-click My Computer on the Desktop, click Explore, and then browse to the C:\WINNT\System32\inetsrv directory.
2.	Double-click the oblt-log.log file to view the changes made by the IIS Lockdown Tool.

The following table shows the changes made by the IIS Lockdown Tool based on your changes, as well as the vulnerabilities minimized by locking down these items.

IIS Lockdown Tool Changes to Minimize Security Issues

Page	Action	Security Issues Minimized
Internet Services	Disabled FTP, SMTP, and NNTP services	Any running service is a potential point of attack. These services are particularly vulnerable.
Script Maps	Disabled the following file extensions by mapping them to 404.dll: Indexing Service (.idq, .htw, .ida) Server-side includes (.shtml, .shtm, .stm) Internet Data Connector (.idc). HTR scripting (.htr)Internet printing (.printer)	idq, .ida: buffer overflow could allow an attacker to gain complete control of the server. htw: a user could inadvertently open an hostile link through a browser or HTML-compliant e-mail client. shtml, .shtm, .stm: ssiinc.dll security issue can return to the browser any attacker-specified content located on the Web server. idc: cross-site scripting security issue can return an entire URL in an error page, allowing attackers to run arbitrary script code at the server. htr: revelation of the source code of ASP files. printer: provide an attacker with a remote console on the target IIS system.
Additional Security	Removed the following virtual directories: IIS Samples MSADC IISHelp Scripts IISAdmin Printers directory for Internet printing Removed the IISAdmin Web site Restricted anonymous access to system tools Restricted anonymous users from writing to Web content directories. Created two new local groups called Web Anonymous Users and Web Applications, and added Deny access control entries (ACEs) for these groups to the access control list (ACL) on key tools and directories. Added the default anonymous Internet user account, IUSR_ComputerName, to Web Anonymous Users. Added the default Web application identity, IWAM_ComputerName, to Web Applications. Disabled Web Distributed Authoring and Versioning (WebDAV). Installed the UrlScan ISAPI filter.

•

To verify that the IIS Lockdown Tool configuration is in force on a Web server

1.	On the Desktop, right-click My Computer, click Explore, and then browse to the C:\WINNT\system32\inetsrv directory.
2.	Locate the oblt-undo.log and oblt-undone.log files.

If the log files are absent, or if they are present and their data and time stamps are earlier than those for oblt-log.log, the IIS Lockdown Tool configuration is in force on the Web server.

After running the IIS Lockdown Tool, you can re-enable a file name extension manually. This is preferable to re-running the IIS Lockdown Tool and remove its configuration.

•

To manually remap file name extensions after running the IIS Lockdown Tool

1.	Click Start, click Programs, click Administrative Tools, and then select Internet Services Manager.
2.	Right-click the Web site, and then click Properties.
3.	Click the Home Directory tab, and then click Configuration.
4.	Locate the file name extension you want to remap.
5.	Double-click the file, and then change the path from 404.dll to C:\WINNT\system32\inetsrv\file name.dll, where file name is the extension you want to remap. For example: idq.dll.

Customizing UrlScan Configuration

UrlScan is installed when you run the IIS Lockdown Tool. UrlScan is an Internet Services Application Programming Interface (ISAPI) filter that protects a Web server from attacks by filtering and rejecting HTTP requests based on a set of rules. The rules apply to all sites hosted by the Web server. When correctly installed, UrlScan runs automatically whenever IIS is started.

You can change UrlScan rules by editing the UrlScan.ini file. This file must reside in the same directory as the UrlScan.dll file, which is the file that runs UrlScan.

This section provides the following step-by-step instructions for customizing UrlScan configuration:

•	Customizing the UrlScan configuration
•	Verifying new UrlScan settings

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer, UrlScan.ini file, Notepad, iisreset command.

•

To customize the UrlScan configuration

Right-click My Computer on the Desktop, click Explore, and then browse to the C:\WINNT\system32\inetsrv\urlscan directory.

Double-click the UrlScan.ini file to open it in Notepad. Make your changes, and then save and close the file.

The following table shows the sections in the UrlScan.ini file.

Sections in the UrlScan.ini File

Section	Description
[Options]	General UrlScan options. For example, directory traversal attacks have exploited project path names that contain multiple periods ("."). If some of your directory names contain multiple periods, you must set AllowDotInPath=1 in UrlScan.ini. Other characters that are rejected by UrlScan include the comma (,) and the pound sign (#).
[AllowVerbs] and [DenyVerbs]	Verbs (also known as HTTP methods, such as GET and POST) that UrlScan permits.
[DenyHeaders]	HTTP headers that are not permitted in an HTTP request. If an HTTP request contains one of the prohibited headers, UrlScan rejects the request.
[AllowExtensions] and [DenyExtensions]	File name extensions (for example, .exe, .dll, ..cgi) permitted by UrlScan.
[DenyURLSequences]	Strings that are not permitted in an HTTP request. UrlScan rejects HTTP requests that contain a string that is listed in this section.

Open a command prompt and type iisreset to recycle IIS and accept the changes you made to the UrlScan.ini file.

Verifying New Settings

Verify that the appropriate security settings for the UrlScan configuration have been applied to your local computer.

•

To verify the UrlScan configuration

1.	Right-click My Computer on the Desktop, click Explore, and then browse to the C:\WINNT\system32\inetsrv\urlscan directory.
2.	To view the record of changes, double-click the UrlScandate.log file to open it in Notepad.

Disabling Unneeded Protocols

By preventing the use of unneeded protocols, you reduce the potential for attack.

This section provides the following step-by-step instructions for disabling unneeded protocols:

•	Disabling SMB on an Internet-facing connection
•	Disabling NetBIOS over TCP/IP

Disabling SMB and NetBIOS

Host enumeration attacks scan the network to determine the IP address of potential targets. To reduce the likelihood of successful host enumeration attacks against Internet-facing ports on your Web server, disable all network protocols except Transmission Control Protocol (TCP). Web servers do not require Server Message Block (SMB) or NetBIOS on their network adapters.

Note: When you disable SMB and NetBIOS, the server cannot function as a file server or a print server, no network browsing is possible, and you cannot manage the Web server remotely. If your server is a dedicated Web server that requires administrators to log on locally, these restrictions should not affect the operation of the server.

SMB uses the following ports:

•	TCP port 139
•	TCP and UDP port 445 (SMB Direct Host)

NetBIOS uses the following ports:

•	TCP and User Datagram Protocol (UDP) port 137 (NetBIOS name service)
•	TCP and UDP port 138 (NetBIOS datagram service)
•	TCP and UDP port 139 (NetBIOS session service)

Disabling only NetBIOS is not sufficient to prevent SMB communication because if a standard NetBIOS port is unavailable, SMB uses TCP port 445 (known as the SMB Direct Host). You must disable NetBIOS and SMB separately.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer, System Tools, Device Manager.

•

To disable SMB on an Internet-facing connection

1.	Click Start, click Settings, and then click Network and Dial-up Connections.
2.	Right-click your Internet-facing connection, and then click Properties.
3.	Clear the Client for Microsoft Networks check box.
4.	Clear the File and Printer Sharing for Microsoft Networks check box, and then click OK.

•

To disable NetBIOS over TCP/IP

1.	On the Desktop, right-click My Computer, and then click Manage.
2.	Expand System Tools, and then select Device Manager.
3.	Right-click Device Manager, click View, and click Show hidden devices.
4.	Expand Non-Plug and Play Drivers.
5.	Right-click NetBios over Tcpip, click Disable, and then click Yes. This procedure disables the SMB direct-hosted listener on TCP port 445 and UDP port 445. It also disables the Nbt.sys driver and requires that you restart the system. When you restart the system, you might see error messages from Service Control Manager. These messages are the expected result of disabling NetBIOS.

Verifying New Settings

Verify that the appropriate security settings have been applied to your Web server.

•

To verify that SMB is disabled

1.	Click Start, click Settings, and then click Network and Dial-up Connections.
2.	Right-click your Internet-facing connection, and then click Properties.
3.	Verify that both the Client for Microsoft Networks and the File and Printer Sharing for Microsoft Networks boxes are clear, and then click OK.

•

To verify that NetBIOS is disabled

1.	Click Start, right-click My Computer, and then click Manage.
2.	Double-click System Tools, and then select Device Manager.
3.	Right-click Device Manager, click View, and then click Show hidden devices.
4.	Double-click Non-Plug and Play Drivers, and then right-click NetBios over Tcpip. The Enable selection now appears on the context menu, which means that NetBIOS over TCP/IP is currently disabled.
5.	Click OK to close Device Manager.

Disabling Null Sessions to Prevent Anonymous Logons

To prevent anonymous access, disable null sessions. These are unauthenticated or anonymous sessions established between two computers. If null sessions are not disabled, an attacker can connect to your server anonymously without being authenticated.

An attacker who establishes a null session can perform a variety of attacks, including enumeration techniques, which are used to collect system-related information from the target computer ? information that can greatly assist subsequent attacks. Information that can be returned over a null session includes domain and trust details, shares, user information (including groups and user rights), and registry keys.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Local Security Policy.

•

To disable null sessions

1.	Click Start, click Programs, click Administrative Tools, and then click Local Security Policy.
2.	Under Security Settings, double-click Local Policies, and then click Security Options.
3.	Double-click Additional restrictions for anonymous connections, and then select No access without explicit anonymous permissions under Local policy setting.
4.	Restart the Web server for the change to take effect.

Verifying New Settings

Verify that the appropriate security settings for disabling null sessions have been applied to your local computer.

•

To verify that null sessions are disabled

On a remote computer, click Start, click Run, type cmd, and then click OK.

Type the following command at the command prompt: net use\\ <IP address of your Web server>
You should receive the following message:

System error 5 has occurred.
Access is denied.

Top of page

Configuring Accounts

You should remove unused accounts because an attacker might discover and use them. Always require strong passwords ? weak passwords increase the likelihood of a successful brute force or dictionary attack. Use accounts that run with least privilege. Otherwise, an attacker can use accounts with too much privilege to gain access to unauthorized resources.

This section provides the following step-by-step instructions for configuring accounts:

•	Disabling unused accounts
•	Disabling null sessions to prevent anonymous access

Disabling Unused Accounts

Unused accounts and their privileges can be used by an attacker to gain access to a server. You should periodically audit local accounts on the server and disable any accounts that are not being used. Disable accounts on a test server before you disable them on a production server to ensure that disabling an account does not adversely affect the way your application operates. If disabling the account does not cause any problems on the test server, disable the account on your production server.

Note: If you choose to delete an unused account instead of disabling it, be aware that you cannot recover a deleted account and that the Administrator account and the Guest account cannot be deleted. Also, be sure to delete the account on a test server before you delete it on your production server.

This section provides the following step-by-step instructions for disabling unused accounts:

•	Disabling the Guest account
•	Renaming the Administrator account
•	Disabling the IUSR_ComputerName account

Disabling the Guest Account

Anonymous connections to the server use the built-in Guest account. To restrict anonymous connections to the computer, keep this account disabled. The Guest account is disabled by default on Windows 2000.

Note: You cannot disable the Guest account on a domain controller.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer.

•

To disable the Guest account

1.	On the Desktop, right-click My Computer, and then click Manage.
2.	Expand Local Users and Groups, and then double-click the Users folder. Typically, the Guest account is displayed with a red X icon to indicate that it is disabled. If the Guest account is not disabled, continue to Step 3 to disable it.
3.	Right-click the Guest account. and then select Properties.
4.	Click the General tab, check Account is disabled, and then click OK. The Guest account should now be displayed with a red X icon.

Renaming the Administrator Account

The default local Administrator account is a target for malicious use because of its elevated privileges on the computer. To improve security, rename the default Administrator account and assign it a strong password.

Note: You cannot rename the local Administrator account on a domain controller.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer.

•

To rename the Administrator account and assign a strong password

1.	Right-click My Computer on the Desktop, and then click Manage.
2.	Expand Local Users and Groups, and then double-click the Users folder.
3.	Right-click the Administrators account, and then click Rename.
4.	Type a name in the field and then press Enter.
5.	Right-click the Administrators account, and then click Set Password.
6.	In the New password field, type a new password.
7.	In the Confirm password box, type the same new password, and then click OK.

Renaming the IUSR_ComputerName Account

The default anonymous Internet user account, IUSR_ComputerName, is created during IIS installation. The value of ComputerName is the NetBIOS name of your server at IIS installation time.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer.

•

To rename the IUSR account

1.	Right-click My Computer on the Desktop, and then click Manage.
2.	Expand Local Users and Groups, and then double-click the Users folder.
3.	Right-click the IUSR_ComputerName account, and then click Rename.
4.	Type a new name in the edit box, and then click outside the box.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that an account is disabled

Click CTRL+ALT+DEL and then click Log Off to log off of the Web server.

On the Log on to Windows dialog box, type the name of the disabled account in the User name box, type the password for the disabled account, and then click OK.
You should receive the following message:

Your account has been disabled. Please see your system administrator.

•

To verify that an account is renamed

1.	Press CTRL+ALT+DEL, and then click Log Off to log off of the Web server.
2.	On the Log on to Windows dialog box, type the former name of the renamed account in the User name box, type the password for the renamed account, and then click OK. The following message appears: The system could not log you on. Make sure your User name and domain are correct, and then type your password again. Letters in passwords must be typed using the correct case.
3.	Click OK, and then type the new name of the renamed account in the User name box.
4.	Type the password for the renamed account, and then click OK. You should be able to log on to the computer with the renamed account.

Top of page

Securing Files and Directories

Use strong access controls to protect sensitive files and directories. In most situations, an approach that allows access to specific accounts is more effective than one that denies access to specific accounts. Set access at the directory level whenever possible. As files are added to the folder they inherit permissions from the folder, so you need to take no further action.

This section provides the following step-by-step instructions for securing files and directories:

•	Relocating and setting permissions for IIS log files
•	Configuring IIS metabase permissions

Relocating and Setting Permissions for IIS Log Files

To increase the security of the IIS log files, you should relocate them to a nonsystem drive that has been formatted to use the NTFS file system. This location should not be the same as the location of your Web site content.

This section provides the following step-by-step instructions for relocation and setting permissions for IIS log files:

•	Moving the location of the IIS log files to a nonsystem partition
•	Setting ACLs on IIS log files
•	Verifying new settings

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer, Internet Services Manager.

•

To move the location of the IIS log files to a nonsystem partition

1.	Right-click My Computer on the Desktop, and then click Explore.
2.	Browse to the location where you want to relocate the IIS log files.
3.	Right-click the directory one level above where you want to relocate the IIS log files, click New, and then click Folder.
4.	Name the folder, for example, ContosoIISLogs, and then press Enter.
5.	Click Start, click Programs, click Administrative Tools, and then select Internet Services Manager.
6.	Right-click the Web site and then choose Properties.
7.	Click the Web Site tab, and then click Properties in the Enable Logging frame.
8.	On the General Properties tab, click Browse, and select the folder you just created to store the IIS log files.
9.	Click OK twice.

Note: If you already have IIS log files in their original location at C:\WINNT\System32\logfiles, you must move these files to the new location manually. IIS does not move those files for you.

•

To set ACLs on IIS log files

1.	On the Desktop, right-click My Computer, and then click Explore.
2.	Browse to the directory that contains the IIS log files.
3.	Right-click the folder, click Properties, and then click the Security tab.
4.	In the top pane, select Administrators, and ensure that the permissions in the bottom pane are set to Full Control.
5.	In the top pane, select System, and ensure that the permissions in the bottom pane are set to Full Control.
6.	In the top pane, select Everyone, click Remove, and then click OK.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that log files are moved and secured

1.	Click Start, click Search, and then click For Files or Folders.
2.	Type a partial or complete file name in the Search for files named box, select a location in the Look in box, and then click Search Now. The search should return the new location of the log files.
3.	Click CTRL+ALT+DEL and then click Log Off.
4.	Log on to the Web server using an account that does not have permission to access the log files.
5.	Right-click My Computer, click Explore, and then browse to the location of the protected log files.
6.	Right-click the log file, and then click Open. Typically, you see the following message: Access is denied.

Configuring IIS Metabase Permissions

The IIS metabase is a binary file that contains most IIS configuration information. Only members of the Administrators group and the LocalSystem account should have Full Control access to the metabase. It is important that you audit all attempts to access the metabase by the Everyone group.

This section provides the following step-by-step instructions for configuring IIS metabase permissions:

•	Restricting access to the MetaBase.bin file
•	Auditing access to the MetaBase.bin file
•	Disabling the FileSystemObject component

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer.

•

To restrict access to the MetaBase.bin file

1.	Right-click My Computer on the Desktop, and then click Explore.
2.	Browse to the C:\WINNT\system32\inetsrv\MetaBase.bin file, right-click the file, and then click Properties.
3.	On the Security tab, remove all file permissions to the metabase, and then grant Full Control to only Administrators and LocalSystem.

•

To audit access to the MetaBase.bin file

Right-click My Computer on the Desktop, and then click Explore.

Browse to the C:\WINNT\system32\inetsrv\MetaBase.bin file, right-click the file, and then click Properties.

Click the Security tab, click Advanced, click Auditing, and then click Add.

Select Everyone, click Add, and then click OK.

Select Successful and Failed for the following access types, and then click OK.

•	Traverse Folder/Execute File
•	List Folder/Read Data
•	Create Files/Write Data

Verifying New Settings

Verify that the appropriate security settings for auditing and restricting access to the MetaBase.bin file have been applied to your local computer.

•

To verify restricted access to the MetaBase.bin file

1.	Click CTRL+ALT+DEL and then click Log Off.
2.	Log on to the Web server using an account that does not have permission to access the MetaBase.bin file.
3.	Right-click My Computer, click Explore, and then browse to the location of MetaBase.bin.
4.	Right-click the MetaBase.bin file, and then click Open. You should see the following message: Access is denied.

Disabling the FileSystemObject Component

ASP, Windows Script Host, and other scripting applications use the FileSystemObject (FSO) component to create, delete, gain information about, and manipulate drives, folders, and files. Consider disabling the FSO component, but be aware that this will also remove the Dictionary object. Also, verify that no other programs require this component.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Command prompt.

•

To disable the FileSystemObject component

1.	Click Start, click Run, type cmd in the Open box, and then click OK.
2.	Change to the C:\WINNT\system32 directory.
3.	At the command prompt, type regsvr32 scrrun.dll /u and then press ENTER. The following message appears: DllUnregisterServer in scrrun.dll succeeded.
4.	Click OK.
5.	At the command prompt, type exit to close the command prompt window.

Top of page

Securing Web Sites and Virtual Directories

Relocate Web root directories and virtual directories to a nonsystem partition to protect against directory traversal attacks, which allow an attacker to execute operating system programs and tools. Because it is not possible to traverse across drives, relocating Web site content to another drive offers added protection against these attacks.

This section provides the following step-by-step instructions for securing Web sites and virtual directories:

•	Moving your Web site to a nonsystem drive
•	Disabling the parent paths setting
•	Configuring Web site permissions

Moving Your Web Site to a Nonsystem Drive

Do not use the default \inetpub\wwwroot directory as the location for your Web site content. For example, if your system is installed on the C: drive, consider moving your site and content directory to the D: drive in order to mitigate the risks associated with directory traversal attacks, in which an attacker attempts to browse the directory structure of a Web server.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Internet Services Manager, command prompt.

•

To move your Web site to a nonsystem drive

1.	Click Start, click Programs, click Administrative Tools, and then click Internet Services Manager.
2.	Right-click the Web site that has the content you want to move, and then click Stop.
3.	On the task bar, click Start, click Run, type cmd, and then click OK.
4.	Type the following command at the command prompt: xcopy c:\inetpub\wwwroot\<site name> <drive>:\wwwroot\<site name> /s /i /o
5.	Go back to the Internet Services Manager snap-in.
6.	Right-click the Web site, and then click Properties.
7.	Click the Home Directory tab, click Browse, and then browse to the new location of the directory where you just copied the files.
8.	Right-click the Web site, and click Start.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that Web site content has been moved to a nonsystem drive or folder

1.	Click Start, click Programs, click Administrative Tools, and then click Internet Services Manager.
2.	Right-click the Web site that contains the content you moved, and then click Properties.
3.	Click the Home Directory tab, verify that the Local Path box contains the new location of the files, and then click OK.

Disabling the Parent Paths Setting

This IIS metabase setting prevents the use of parent paths in script and application calls. Disabling parent paths helps guard against directory traversal attacks. The following example shows a parent path in an ASP file:

<!--#include file="../<filename.ext>"-->

When parent paths are disabled, the ASP file should contain path statements in the following format:

<!--#include virtual="/<virtual path>/<filename.ext>"-->

where <virtual path> is the name of the virtual directory where the file resides on your Web server.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Internet Services Manager.

•

To disable parent paths

1.	Click Start, click Programs, click Administrative Tools, and then click Internet Services Manager.
2.	Right-click the root of your Web site, and then click Properties.
3.	Click the Home Directory tab, and then click Configuration.
4.	Click the App Options tab, and then clear the Enable parent paths check box.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that parent paths are disabled

1.	Click Start, click Programs, click Administrative Tools, and then click Internet Services Manager.
2.	Right-click the root of your Web site, and click Properties.
3.	Click the Home Directory tab, and then click Configuration.
4.	Click the App Options tab, ensure that the Enable parent paths check box is clear, and then click OK.

Configuring Web Site Permissions

You can configure your Web server's access permissions for specific sites, directories, and files. These permissions apply to all users regardless of their specific access rights.

Configuring Permissions on File System Directories

Internet Information Services relies on NTFS permissions for securing individual files and directories from unauthorized access. Unlike Web site permissions, which apply to all users, you can use NTFS permissions to precisely define which users can access your content and how those users are allowed to manipulate that content.

Access control lists (ACLs) indicate which users or groups have permission to access or modify a particular file. Instead of setting ACLs on each file, consider creating new directories for each file type, setting ACLs on each directory, and allowing the ACLs to inherit to the files.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: My Computer.

•

To copy Web site content into a separate folder

1.	On the Desktop, right-click My Computer, and then click Explore.
2.	Browse to the folder that contains your Web site content.
3.	Select the top-level folder of your Web site content.
4.	On the File menu, click New, and then click Folder.
5.	Give the folder a name, and then press Enter.
6.	Hold down CTRL and select each of the pages that you want to copy.
7.	Right-click the pages, and then click Copy.
8.	Right-click the new folder, and then click Paste. Note: If you have hyperlinks to these pages, you must update them to reflect their new location.

•

To set permissions on physical directories

1.	Right-click My Computer on the Desktop, and then click Explore.
2.	Click the content folder that contains the page or pages that you want to protect.
3.	Right-click the folder, click Properties, and then click the Security tab.
4.	Remove the Everyone group from the list of names in the top pane, and then click Add.
5.	Type the names of the users or groups to whom you want to grant access to the content, and then click OK. Note: These users and groups must already be part of the domain in which the Web server resides. If they are not, you must add them before you proceed.
6.	In the top pane, select the user or group that you just added, select the permissions that you want to grant in the bottom pane, and then click OK. Read & Execute permissions are sufficient for most users or groups, but in some specific cases you might need to grant Write or Full Control permissions.

Configuring Permissions on Virtual Directories

Most users do not require access to all content on your Web server. To protect the content on your Web server, you must configure appropriate access permissions on your Web server's virtual directories.

•

To set permissions on virtual directories

1.	Click Start, click Programs, click Administrative Tools, and then select Internet Services Manager.
2.	Right-click the Web site for which you want to set permissions on virtual directories, click All Tasks, and then click Permissions Wizard.
3.	Follow the steps in the wizard.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that write access is denied to physical and virtual directories

1.	Press CTRL+ALT+DEL, and then click Log Off.
2.	Log on to the Web server using an account that has Read & Execute permission on the physical or virtual directory.
3.	Right-click My Computer on the Desktop, click Explore, browse to the location of a file you want to copy to the physical or virtual directory.
4.	Right-click the file, and then click Copy.
5.	Browse to the location of the physical or virtual directory, and right-click the directory. The Paste option should not be available on the context menu. This means that you do not have Write access to the directory.

Top of page

Configuring Secure Sockets Layer on Your Web Server

Configure Secure Sockets Layer (SSL) security features on your Web server to verify the integrity of your content, verify the identity of users, and encrypt network transmissions. SSL security relies on a server certificate that allows users to authenticate your Web site before they transmit personal information, such as a credit card number.

This section provides the following step-by-step instructions for configuring SSL on your Web server:

•	Obtaining and install a server certificate
•	Enforcing and enabling SSL connections on your Web server

Obtaining and Installing a Server Certificate

Certificates are issued by non-Microsoft organizations called certification authorities (CAs). The server certificate is typically associated with your Web server, specifically with the Web site where you have configured SSL. You must generate a request for a certificate, send the request to the CA, and then install the certificate after you receive it from the CA.

Certificates require a pair of encryption keys, one public and one private, to enforce security. When you generate a request for a server certificate, you actually generate the private key. The server certificate you receive from the CA contains the public key.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Internet Services Manager, Web Server Certificate Wizard.

•

To generate a request for a server certificate

1.	Right-click My Computer on the Desktop, and then click Manage.
2.	Expand the Services and Applications section, and then expand Internet Information Services.
3.	Right-click the Web site on which you want to install a server certificate, and then click Properties.
4.	On the Directory Security tab, in the Secure Communications section, click Server Certificate to start the Web Server Certificate Wizard, and then click Next.
5.	Select Create a New Certificate, and then click Next.
6.	Select Prepare the request now, but send it later, and then click Next.
7.	In the Name field, enter a name that you can remember. It defaults to the name of the Web site for which you are generating the certificate request, for example, http://www.contoso.com.
8.	Specify a bit length, and then click Next. The bit length of the encryption key determines the strength of the encryption. Most non-Microsoft CAs prefer that you choose a minimum of 1024 bits.
9.	In the Organization section, enter your organization and organizational unit information. Ensure that this information is accurate, and then click Next.
10.	In the Your Site's Common Name section, enter the host computer name with the domain name, and then click Next.
11.	Enter your geographical information, and then click Next.
12.	Save the file as a .txt file. The default file name and location is C:\certreq.txt. The following example shows what a certificate request file looks like. -----BEGIN NEW CERTIFICATE REQUEST----- MIIDATCCAmoCAQAwbDEOMAwGA1UEAxMFcGxhbjgxDDAKBgNVBAsTA1BTUzESMBAG A1UEChMJTWljcm9zb2Z0MRIwEAYDVQQHEwlDaGFybG90dGUxFzAVBgNVBAgTDk5v cnRoIENhcm9saW5hMQswCQYDVQQGEwJVUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAtW1koGfdt+EoJbKdxUZ+5vE7TF1ZuT+xaK9jEWHESfw11zoRKrHzHN0f IASnwg3vZ0ACteQy5SiWmFaJeJ4k7YaKUb6chZXG3GqL4YiSKFaLpJX+YRiKMtmI JzFzict5GVVGHsa1lY0BDYDO2XOAlstGlHCtENHOKpzdYdANRg0CAwEAAaCCAVMw GgYKKwYBBAGCNw0CAzEMFgo1LjAuMjE5NS4yMDUGCisGAQQBgjcCAQ4xJzAlMA4G A1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDATCB/QYKKwYBBAGCNw0C AjGB7jCB6wIBAR5aAE0AaQBjAHIAbwBzAG8AZgB0ACAAUgBTAEEAIABTAEMAaABh AG4AbgBlAGwAIABDAHIAeQBwAHQAbwBnAHIAYQBwAGgAaQBjACAAUAByAG8AdgBp AGQAZQByA4GJAGKa0jzBn8fkxScrWsdnU2eUJOMUK5Ms87Q+fjP1/pWN3PJnH7x8 MBc5isFCjww6YnIjD8c3OfYfjkmWc048ZuGoH7ZoD6YNfv/SfAvQmr90eGmKOFFi TD+hl1hM08gu2oxFU7mCvfTQ/2IbXP7KYFGEqaJ6wn0Z5yLOByPqblQZAAAAAAAA AAAwDQYJKoZIhvcNAQEFBQADgYEAhpzNy+aMNHAmGUXQT6PKxWpaxDSjf4nBmo7o MhfC7CIvR0McCQ+CBwuLzD+UJxl+kjgb+qwcOUkGX2PCZ7tOWzcXWNmn/4YHQl0M GEXu0w67sVc2R9DlsHDNzeXLIOmjUl935qy1uoIR4V5C48YNsF4ejlgjeCFsbCoj Jb9/2RM= -----END NEW CERTIFICATE REQUEST-----
13.	Confirm your request details, and then click Next.

•

To submit a request for a server certificate

1.	Contact your CA to determine their requirements for submitting a request.
2.	Copy the contents of the .txt file you created in the preceding procedure into the request format required by your CA.
3.	Send the request to your CA.

When you receive the certificate from your CA, you are ready to install the certificate on your Web server.

•

To install a server certificate

1.	Copy the text of the certificate key you received from the CA and paste it into a .txt file.
2.	Save the file as Cert.txt.
3.	Right-click My Computer, and then click Manage.
4.	Expand the Services and Applications section, and then expand Internet Information Services.
5.	Right-click the Web site on which you want to install a server certificate, and then click Properties.
6.	On the Directory Security tab, in the Secure Communications section, click Server Certificate to start the Web Server Certificate Wizard, and then click Next.
7.	Select Process the Pending Request and install the certificate, and then click Next.
8.	Browse to the text file that you saved in Step 1. Click Next twice, and then click Finish.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify that a certificate is installed on a Web server

1.	Click Start, click Programs, click Administrative Tools, and then click Internet Services Manager.
2.	Right-click the Web site that has a certificate you want to view, and then click Properties.
3.	On the Directory Security tab, in the Secure communications area, click View Certificate, review the certificate, and then click OK twice.

Enabling and Enforcing SSL Connections on Your Web Server

After you have installed the server certificate, you must enable SSL connections on your Web server. Then, you must enforce SSL connections.

Requirements

•	Credentials: You must be logged on as a member of the Administrators group on the Web server.
•	Tools: Internet Services Manager MMC snap-in.

•

To enable SSL connections on your Web server

1.	Right-click My Computer and then click Manage.
2.	Expand the Services and Applications section, and then expand Internet Information Services.
3.	Right-click the Web site on which you want to install a server certificate, and then click Properties.
4.	On the Web Site tab, in the Web Site Identification section, verify that the SSL Port field is populated with the numeric value 443, and then click Advanced. Typically, you see two fields, and the IP address and port of the Web site are listed in the Multiple identities for this web site field.
5.	Under the Multiple SSL Identities for this web site field, click Add if port 443 is not already listed.
6.	Select the server's IP address, type the numeric value 443 in the SSL Port field, and then click OK.

•

To enforce SSL connections

1.	Right-click My Computer and then click Manage.
2.	Expand the Services and Applications section, and then expand Internet Information Services.
3.	Right-click the Web site on which you want to install a server certificate, and then click Properties.
4.	Click the Directory Security tab. In the Secure Communications section, click Edit.
5.	Select Require Secure Channel (SSL), choose an encryption strength, and then click OK. Note: If you specify 128-bit encryption, users who use 40-bit or 56-bit strength browsers cannot communicate with your site unless they upgrade their encryption strength.

Verifying New Settings

Verify that the appropriate security settings have been applied to your local computer.

•

To verify SSL connections on your Web server

Open your browser and try to connect to your Web server by using the standard http:// protocol. For example, in the Address box, type: http://www.contoso.com
Typically, if SSL is enforced, the following error message appears:

The page must be viewed over a secure channel.
The page you are trying to view requires the use of "https" in the address.

Try to connect to the same page by typing the following: https://www.contoso.com
Typically, you can see the default page for your Web server.

Top of page

Related Information

For more information about securing IIS 5.0 and IIS 5.1, see the following:

•	"From Blueprint to Fortress: A Guide to Securing IIS 5.0" on the TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22688.
•	"Secure Internet Information Services 5 Checklist" on the TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22689.
•	Microsoft Security Bulletin Search on the TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22690.

For more information about IIS 5.0 and IIS 5.1, see the following:

•	Internet Information Services (IIS) Security Center on the TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=22691.
•	Windows 2000 Web and Application Services technology center on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22692.
•	Internet Information Services 5.1 on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=22693.

Top of page

Securing Internet Information Services 5.0 and 5.1

On This Page

Introduction

Before You Begin

System Requirements

Web Server Characteristics

Reducing the Attack Surface of Your Web Server

Running the IIS Lockdown Tool

Customizing UrlScan Configuration

Disabling Unneeded Protocols

Disabling SMB and NetBIOS

Disabling Null Sessions to Prevent Anonymous Logons

Configuring Accounts

Disabling Unused Accounts

Disabling the Guest Account

Renaming the Administrator Account

Renaming the IUSR_ComputerName Account

Securing Files and Directories

Relocating and Setting Permissions for IIS Log Files

Configuring IIS Metabase Permissions

Disabling the FileSystemObject Component

Securing Web Sites and Virtual Directories

Moving Your Web Site to a Nonsystem Drive

Disabling the Parent Paths Setting

Configuring Web Site Permissions

Configuring Permissions on File System Directories

Configuring Permissions on Virtual Directories

Configuring Secure Sockets Layer on Your Web Server

Obtaining and Installing a Server Certificate

Enabling and Enforcing SSL Connections on Your Web Server

Related Information