Chapter 16 – Securing Your Web Server


Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

Applies to:

  • Internet Information Services (IIS) 5.0
  • Microsoft Windows® 2000 operating system

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter presents a methodology and a series of steps required to secure a Web server. The steps are divided into common configuration categories, including patches and updates, ports, protocols, accounts, services, files and directories and others. This allows you to systematically walk through the securing process from top to bottom or pick a particular category and complete specific steps. The chapter also covers the basic hardening steps for the .NET Framework for Web servers that host ASP.NET Web applications.


In This Chapter
How to Use This Chapter
Threats and Countermeasures
Methodology for Securing Your Web Server
IIS and .NET Framework Installation Considerations
Installation Recommendations
Steps for Securing Your Web Server
Step 1. Patches and Updates
Step 2. IISLockdown
Step 3. Services
Step 4. Protocols
Step 5. Accounts
Step 6. Files and Directories
Step 7. Shares
Step 8. Ports
Step 9. Registry
Step 10. Auditing and Logging
Step 11. Sites and Virtual Directories
Step 12. Script Mappings
Step 13. ISAPI Filters
Step 14. IIS Metabase
Step 15. Server Certificates
Step 16. Machine.Config
Step 17. Code Access Security
Snapshot of a Secure Web Server
Staying Secure
Remote Administration
Simplifying and Automating Security
Additional Resources

In This Chapter

  • A proven methodology to secure Web servers
  • An explanation of the most common Web server security threats
  • Steps to secure your server
  • A reference table that illustrates a secure Web server


A secure Web server provides a protected foundation for hosting your Web applications, and Web server configuration plays a critical role in your Web application's security. Badly configured virtual directories, a common mistake, can lead to unauthorized access. A forgotten share can provide a convenient back door, while an overlooked port can be an attacker's front door. Neglected user accounts can permit an attacker to slip by your defenses unnoticed.

What makes a Web server secure? Part of the challenge of securing your Web server is recognizing your goal. As soon as you know what a secure Web server is, you can learn how to apply the configuration settings to create one. This chapter provides a systematic, repeatable approach that you can use to successfully configure a secure Web server.

The chapter begins by reviewing the most common threats that affect Web servers. It then uses this perspective to create a methodology. The chapter then puts the methodology into practice, and takes a step-by-step approach that shows you how to improve your Web server's security. While the basic methodology is reusable across technologies, the chapter focuses on securing a Web server running the Microsoft Windows 2000 or Microsoft Windows Server 2003™ operating system and hosting the Microsoft .NET Framework.

How to Use This Chapter

This chapter provides a methodology and the steps required to secure your Web server. You can adapt the methodology for your own situation. The steps are modular and demonstrate how you can put the methodology in practice. You can use these procedures on existing Web servers or on new ones.

To gain the most from this chapter:

  • Read Chapter 2, "Threats and Countermeasures." This will give you a broader understanding of potential threats to Web applications.
  • Use the Snapshot. The section "Snapshot of a Secure Web Server" lists and explains the attributes of a secure Web server. It reflects input from a variety of sources including customers, industry experts, and internal Microsoft development and support teams. Use the snapshot table as a reference when configuring your server.
  • Use the Checklist. "Checklist: Securing Your Web Server" in the "Checklist" section of this guide provides a printable job aid for quick reference. Use the task-based checklist to quickly evaluate the scope of the required steps and to help you work through the individual steps.
  • Use the "How To" Section. The "How To" section in this guide includes the following instructional articles:
    • "How To: Use URLScan"
    • "How To: Use Microsoft Baseline Security Analyzer"
    • "How To: Use IISLockdown"

Threats and Countermeasures

The fact that an attacker can strike remotely makes a Web server an appealing target. Understanding threats to your Web server and being able to identify appropriate countermeasures permits you to anticipate many attacks and thwart the ever-growing numbers of attackers.

The main threats to a Web server are:

  • Profiling
  • Denial of service
  • Unauthorized access
  • Arbitrary code execution
  • Elevation of privileges
  • Viruses, worms, and Trojan horses

Figure 16.1 summarizes the more prevalent attacks and common vulnerabilities.


Figure 16.1

Prominent Web server threats and common vulnerabilities


Profiling, or host enumeration, is an exploratory process used to gather information about your Web site. An attacker uses this information to attack known weak points.


  • Common vulnerabilities that make your server susceptible to profiling include:
  • Unnecessary protocols
  • Open ports
  • Web servers providing configuration information in banners


Common attacks used for profiling include:

  • Port scans
  • Ping sweeps
  • NetBIOS and server message block (SMB) enumeration


Countermeasures include blocking all unnecessary ports, blocking Internet Control Message Protocol (ICMP) traffic, and disabling unnecessary protocols such as NetBIOS and SMB.

Denial of Service

Denial of service attacks occur when your server is overwhelmed by service requests. The threat is that your Web server will be too overwhelmed to respond to legitimate client requests.


Vulnerabilities that increase the opportunities for denial of service include:

  • Weak TCP/IP stack configuration
  • Unpatched servers


Common denial of service attacks include:

  • Network-level SYN floods
  • Buffer overflows
  • Flooding the Web server with requests from distributed locations


Countermeasures include hardening the TCP/IP stack and consistently applying the latest software patches and updates to system software.

Unauthorized Access

Unauthorized access occurs when a user without correct permissions gains access to restricted information or performs a restricted operation.


Common vulnerabilities that lead to unauthorized access include:

  • Weak IIS Web access controls including Web permissions
  • Weak NTFS permissions


Countermeasures include using secure Web permissions, NTFS permissions, and .NET Framework access control mechanisms including URL authorization.

Arbitrary Code Execution

Code execution attacks occur when an attacker runs malicious code on your server either to compromise server resources or to mount additional attacks against downstream systems.


Vulnerabilities that can lead to malicious code execution include:

  • Weak IIS configuration
  • Unpatched servers


Common code execution attacks include:

  • Path traversal
  • Buffer overflow leading to code injection


Countermeasures include configuring IIS to reject URLs with "../" to prevent path traversal, locking down system commands and utilities with restrictive access control lists (ACLs), and installing new patches and updates.

Elevation of Privileges

Elevation of privilege attacks occur when an attacker runs code by using a privileged process account.


Common vulnerabilities that make your Web server susceptible to elevation of privilege attacks include:

  • Over-privileged process accounts
  • Over-privileged service accounts


Countermeasures include running processes using least privileged accounts and using least privileged service and user accounts.

Viruses, Worms, and Trojan Horses

Malicious code comes in several varieties, including:

  • Viruses. Programs that are designed to perform malicious acts and cause disruption to an operating system or applications.
  • Worms. Programs that are self-replicating and self-sustaining.
  • Trojan horses. Programs that appear to be useful but that actually do damage.

In many cases, malicious code is unnoticed until it consumes system resources and slows down or halts the execution of other programs. For example, the Code Red worm was one of the most notorious to afflict IIS, and it relied upon a buffer overflow vulnerability in an ISAPI filter.


Common vulnerabilities that make you susceptible to viruses, worms, and Trojan horses include:

  • Unpatched servers
  • Running unnecessary services
  • Unnecessary ISAPI filters and extensions


Countermeasures include the prompt application of the latest software patches, disabling unused functionality such as unused ISAPI filters and extensions, and running processes with least privileged accounts to reduce the scope of damage in the event of a compromise.

Methodology for Securing Your Web Server

To secure a Web server, you must apply many configuration settings to reduce the server's vulnerability to attack. So, how do you know where to start, and when do you know that you are done? The best approach is to organize the precautions you must take and the settings you must configure, into categories. Using categories allows you to systematically walk through the securing process from top to bottom or pick a particular category and complete specific steps.

Configuration Categories

The security methodology in this chapter has been organized into the categories shown in Figure 16.2.


Figure 16.2

Web server configuration categories

The rationale behind the categories is as follows:

  • Patches and Updates

    Many security threats are caused by vulnerabilities that are widely published and well known. In many cases, when a new vulnerability is discovered, the code to exploit it is posted on Internet bulletin boards within hours of the first successful attack. If you do not patch and update your server, you provide opportunities for attackers and malicious code. Patching and updating your server software is a critical first step towards securing your Web server.

  • Services

    Services are prime vulnerability points for attackers who can exploit the privileges and capabilities of a service to access the local Web server or other downstream servers. If a service is not necessary for your Web server's operation, do not run it on your server. If the service is necessary, secure it and maintain it. Consider monitoring any service to ensure availability. If your service software is not secure, but you need the service, try to find a secure alternative.

  • Protocols

    Avoid using protocols that are inherently insecure. If you cannot avoid using these protocols, take the appropriate measures to provide secure authentication and communication, for example, by using IPSec policies. Examples of insecure, clear text protocols are Telnet, Post Office Protocol (POP3), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP).

  • Accounts

    Accounts grant authenticated access to your computer, and these accounts must be audited. What is the purpose of the user account? How much access does it have? Is it a common account that can be targeted for attack? Is it a service account that can be compromised and must therefore be contained? Configure accounts with least privilege to help prevent elevation of privilege. Remove any accounts that you do not need. Slow down brute force and dictionary attacks with strong password policies, and then audit and alert for logon failures.

  • Files and Directories

    Secure all files and directories with restricted NTFS permissions that only allow access to necessary Windows services and user accounts. Use Windows auditing to allow you to detect when suspicious or unauthorized activity occurs.

  • Shares

    Remove all unnecessary file shares including the default administration shares if they are not required. Secure any remaining shares with restricted NTFS permissions. Although shares may not be directly exposed to the Internet, a defense strategy — with limited and secured shares — reduces risk if a server is compromised.

  • Ports

    Services that run on the server listen to specific ports so that they can respond to incoming requests. Audit the ports on your server regularly to ensure that an insecure or unnecessary service is not active on your Web server. If you detect an active port that was not opened by an administrator, this is a sure sign of unauthorized access and a security compromise.

  • Registry

    Many security-related settings are stored in the registry and as a result, you must secure the registry. You can do this by applying restricted Windows ACLs and by blocking remote registry administration.

  • Auditing and Logging

    Auditing is one of your most important tools for identifying intruders, attacks in progress, and evidence of attacks that have occurred. Use a combination of Windows and IIS auditing features to configure auditing on your Web server. Event and system logs also help you to troubleshoot security problems.

  • Sites and Virtual Directories

    Sites and virtual directories are directly exposed to the Internet. Even though secure firewall configuration and defensive ISAPI filters such as URLScan (which ships with the IISLockdown tool) can block requests for restricted configuration files or program executables, a defense in depth strategy is recommended. Relocate sites and virtual directories to non-system partitions and use IIS Web permissions to further restrict access.

    Note   By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore, you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. However, if you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.

    IIS 6.0 on Windows Server 2003 has functionality equivalent to URLScan built in. Your decision whether to install UrlScan should be based on your specific organizational requirements. For more information, see "Installing UrlScan 2.5."

  • Script Mappings

    Remove all unnecessary IIS script mappings for optional file extensions to prevent an attacker from exploiting any bugs in the ISAPI extensions that handle these types of files. Unused extension mappings are often overlooked and represent a major security vulnerability.

  • ISAPI Filters

    Attackers have been successful in exploiting vulnerabilities in ISAPI filters. Remove unnecessary ISAPI filters from the Web server.

  • IIS Metabase

    The IIS metabase maintains IIS configuration settings. You must be sure that the security related settings are appropriately configured, and that access to the metabase file is restricted with hardened NTFS permissions.

  • Machine.config

    The Machine.config file stores machine-level configuration settings applied to .NET Framework applications including ASP.NET Web applications. Modify the settings in Machine.config to ensure that secure defaults are applied to any ASP.NET application installed on the server.

    Note   The .NET Framework 2.0 provides a machine-level Web.config file with settings related to ASP.NET 2.0. You need to review these settings to ensure that secure defaults are applied to any ASP.NET application installed on the server.

  • Code Access Security

    Restrict code access security policy settings to ensure that code downloaded from the Internet or Intranet have no permissions and as a result will not be allowed to execute.

IIS and .NET Framework Installation Considerations

Before you can secure your Web server, you need to know which components are present on a Windows 2000 or Windows Server 2003 server after IIS and the .NET Framework are installed. This section explains which components are installed.

What Does IIS Install?

IIS installs a number of services, accounts, folders, and Web sites. Some components that IIS installs may not be used by your Web applications, and if present on the server, could make the server vulnerable to attack. Table 16.1 lists the services, accounts, and folders that are created by a full installation of IIS on Windows 2000 or Windows Server 2003 with all components selected.

Table 16.1   IIS Installation Defaults

Item Details Default
Services IIS Admin Service (for administration of Web and FTP services)

World Wide Web Publishing Service

FTP Publishing Service

Simple Mail Transport Protocol (SMTP)

Network News Transport Protocol (NNTP)






Accounts and Groups IUSR_MACHINE (anonymous Internet users)

IWAM_MACHINE (out-of-process ASP Web applications; not used for ASP.NET applications except those running on a domain controller; your Web server should not be a domain controller)

Added to Guest group

Added to Guest group

Folders %windir%\system32\inetsrv (IIS program files)

%windir%\system32\inetsrv\iisadmin (Files used for remote IIS admin)

%windir%\help\iishelp (IIS help files)

%systemdrive%\inetpub (Web, FTP, and SMTP root folders)

Web Sites Default Web Site–port 80: %SystemDrive%\inetpub\wwwroot

Administration Web Site–port 3693: %SystemDrive%\System32\inetsrv\iisadmin

Anonymous access allowed

Local machine and Administrators access only

What Does the .NET Framework Install?

When you install the .NET Framework on a server that hosts IIS, the .NET Framework registers ASP.NET. As part of this process, a local, least privileged account named ASPNET is created. This runs the ASP.NET worker process (aspnet_wp.exe) and the session state service (aspnet_state.exe), which can be used to manage user session state.

Note   On server computers running Windows 2000 and IIS 5.0, all ASP.NET Web applications run in a single instance of the ASP.NET worker process and application domains provide isolation. On Windows Server 2003, IIS 6.0 provides process-level isolation through the use of application pools.

Table 16.2 shows the services, accounts, and folders that are created by a default installation of version 1.1 of the .NET Framework.

Table 16.2   .NET Framework Installation Defaults

Item Details Default
Services ASP.NET State Service: Provides support for out-of-process session state for ASP.NET. Started manually
Accounts and Groups ASPNET: Account used for running the ASP.NET worker process (Aspnet_wp.exe) and session state service (Aspnet_state.exe). Added to Users group
Folders %windir%\Microsoft.NET\Framework\{version}





\Temporary ASP.NET Files

ISAPI Extensions Aspnet_isapi.dll: Handles requests for ASP.NET file types. Forwards requests to ASP.NET worker process (Aspnet_wp.exe).  
ISAPI Filters Aspnet_filter.dll: Only used to support cookie-less session state. Runs inside Inetinfo.exe (IIS) process.  
\{version} Aspnet_isapi.dll

Installation Recommendations

By default, the Windows 2000 Server setup installs IIS. However, the recommendation is that you do not install IIS as part of the operating system installation but install it later, after you have updated and patched the base operating system. After you install IIS, you must reapply IIS patches and harden the IIS configuration to ensure that it is fully secured. Only then is it safe to connect the server to the network.

Note   By default, Windows Server 2003 does not install IIS, but it is still available and can be installed later if required.

IIS Installation Recommendations

If you are installing and configuring a new Web server, follow the procedure outlined below.

To build a new Web server

  1. Install Windows 2000 Server, but do not install IIS as part of the operating system installation.

  2. Apply the latest service packs and patches to the operating system. (If you are configuring more than one server, see "Including Service Packs with a Base Installation," later in this section.)

  3. Install IIS separately by using Add/Remove Programs in the Control Panel.

    If you do not need the following services, do not install them when you install IIS 5.0:

    Note   In IIS 6.0, these services are not installed by default.

    • File Transfer Protocol (FTP) Server
    • Microsoft FrontPage® 2000 Server Extensions
    • Internet Service Manager (HTML)
    • NNTP Service
    • SMTP Service
    • Visual InterDev RAD Remote Deployment Support

Note   By installing IIS on a fully patched and updated operating system, you can prevent attacks that take advantage of known vulnerabilities (such as NIMDA) that have now been patched.

.NET Framework Installation Recommendations

Do not install the .NET Framework Software Development Kit (SDK) on a production server. The SDK contains utilities that the server does not require. If an attacker gains access to your server, the attacker can use some of these tools to assist other attacks.

Instead, install the redistributable package, which you can obtain from the "Downloads" link at the .NET Framework site on at

Including Service Packs with a Base Installation

If you need to build multiple servers, you can incorporate service packs directly into your Windows installations. Service packs include a program called Update.exe to combine a service pack with your Windows installation files.

To combine a service pack with a Windows installation

  1. Download the latest service pack.

  2. Extract Update.exe from the service pack by launching the service pack setup with the -x option, as follows:

    w3ksp3.exe -x

  3. Integrate the service pack with your Windows installation source, by running update.exe with the -s option, passing the folder path of your Windows installation as follows:

    **update.exe -s c:\**YourWindowsInstallationSource

For more information, see the MSDN article, "Customizing Unattended Win2K Installations" at

Steps for Securing Your Web Server

The next sections guide you through the process of securing your Web server. These sections use the configuration categories introduced in the "Methodology for Securing Your Web Server" section of this chapter. Each high-level step contains one or more actions to secure a particular area or feature.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Patches and Updates





Files and Directories




Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Auditing and Logging

Sites and Virtual Directories

Script Mappings

ISAPI Filters

IIS Metabase

Server Certificates


Code Access Security

Step 1. Patches and Updates

Update your server with the latest service packs and patches. You must update and patch all of the Web server components including Windows 2000 or Windows Server 2003 (and IIS), the .NET Framework, and Microsoft Data Access Components (MDAC).

During this step, you:

  • Detect and install the required patches and updates.
  • Update the .NET Framework.

Detect and Install Patches and Updates

Use the Microsoft Baseline Security Analyzer (MBSA) to detect the patches and updates that may be missing from your current installation. MBSA compares your installation to a list of currently available updates maintained in an XML file. MBSA can download the XML file when it scans your server or you can manually download the file to the server or make it available on a network server.

To detect and install patches and updates

  1. Download and install MBSA.

    You can do this from the MBSA home page at

    If you do not have Internet access when you run MBSA, MBSA cannot retrieve the XML file that contains the latest security settings from Microsoft. You can use another computer to download the XML file, however. Then you can copy it into the MBSA program directory. The XML file is available from

  2. Run MBSA by double-clicking the desktop icon or selecting it from the Programs menu.

  3. Click Scan a computer. MBSA defaults to the local computer.

  4. Clear all check boxes apart from Check for security updates. This option detects which patches and updates are missing.

  5. Click Start scan. Your server is now analyzed. When the scan is complete, MBSA displays a security report, which it also writes to the %userprofile%\SecurityScans directory.

  6. Download and install the missing updates.

    Click the Result details link next to each failed check to view the list of security updates that are missing. The resulting dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.

For more information on using MBSA, see "How To: Use the Microsoft Baseline Security Analyzer" in the "How To" section of this guide.

Update the .NET Framework

At the time of this update (January 2006), MBSA cannot detect .NET Framework updates and patches. Therefore, you must manually detect .NET Framework updates.

To manually update .NET Framework

  1. Determine which .NET Framework service pack is installed on your Web server.

    To do this, see Microsoft Knowledge Base article 318785, "INFO: Determining Whether Service Packs Are Installed on .NET Framework."

  2. Compare the installed version of the .NET Framework to the current service pack.

    To do this, use the .NET Framework versions listed in Microsoft Knowledge Base article 318836, "INFO: How to Obtain the Latest .NET Framework Service Pack."

Step 2. IISLockdown

The IISLockdown tool helps you to automate certain security steps. IISLockdown greatly reduces the vulnerability of a Windows 2000 Web server. It allows you to pick a specific type of server role, and then use custom templates to improve security for that particular server. The templates either disable or secure various features. In addition, IISLockdown installs the URLScan ISAPI filter. URLScan allows Web site administrators to restrict the kind of HTTP requests that the server can process, based on a set of rules that the administrator controls. By blocking specific HTTP requests, the URLScan filter prevents potentially harmful requests from reaching the server and causing damage.

Note   By default, IIS 6.0 has security-related configuration settings similar to those made by the IIS Lockdown Tool. Therefore you do not need to run the IIS Lockdown Tool on Web servers running IIS 6.0. However, if you are upgrading from a previous version of IIS (5.0 or lower) to IIS 6.0, it is recommended that you run the IIS Lockdown Tool to enhance the security of your Web server.

During this step, you:

  • Install and run IISLockdown.
  • Install and configure URLScan.


Install and Run IISLockdown

IISLockdown is available as an Internet download from the Microsoft Web site at

Save IISlockd.exe in a local folder. IISlockd.exe is the IISLockdown wizard and not an installation program. You can reverse any changes made by IISLockdown by running IISlockd.exe a second time.

If you are locking down a Windows 2000-based computer that hosts ASP.NET pages, select the Dynamic Web server template when the IISLockdown tool prompts you. When you select Dynamic Web server, IISLockdown does the following:

  • It disables the following insecure Internet services:
    • File Transfer Protocol (FTP)
    • E-mail service (SMTP)
    • News service (NNTP)
  • It disables script mappings by mapping the following file extensions to the 404.dll:
    • Index Server
    • Web Interface (.idq, .htw, .ida)
    • Server-side include files (.shtml, .shtm, .stm)
    • Internet Data Connector (.idc)
    • .HTR scripting (.htr), Internet printing (.printer)
  • It removes the following virtual directories: IIS Samples, MSADC, IISHelp, Scripts, and IISAdmin.
  • It restricts anonymous access to system utilities as well as the ability to write to Web content directories using Web permissions.
  • It disables Web Distributed Authoring and Versioning (WebDAV).
  • It installs the URLScan ISAPI filter.

**Note   **If you are not using classic ASP, do not use the static Web server template. This template removes basic functionality that ASP.NET pages need, such as support for the POST command.

Log Files

IISLockdown creates two reports that list the changes it has applied:

  • %windir%\system32\inetsrv\oblt-rep.log. This contains high-level information.
  • %windir%\system32\inetsrv\oblt-log.log. This contains low-level details such as which program files are configured with a deny access control entry (ACE) to prevent anonymous Internet user accounts from accessing them. This log file is also used to support the IISLockdown Undo Changes feature.

Web Anonymous Users and Web Application Groups

IISLockdown creates the Web Anonymous Users group and the Web Application group. The Web Anonymous Users group contains the IUSR_MACHINE account. The Web Application group contains the IWAM_MACHINE account. Permissions are assigned to system tools and content directories based on these groups and not directly to the IUSR and IWAM accounts. You can review specific permissions by viewing the IISLockdown log, %windir%\system32\inetsrv\oblt-log.log.

The 404.dll

IISLockdown installs the 404.dll, to which you can map file extensions that must not be run by the client. For more information, see "Step 12. Script Mappings."


If you install the URLScan ISAPI filter as part of IISLockdown, URLScan settings are integrated with the server role you select when running IISLockdown. For example, if you select a static Web server, URLScan blocks the POST command.

Reversing IISLockdown Changes

To reverse the changes that IISLockdown performs, run IISLockd.exe a second time. This does not remove the URLScan ISAPI filter. For more information, see "Removing URLScan" in the next topic.

More Information

See the following articles for more information about the IISLockdown tool:

  • For more information on running IISLockdown, see "How To: Use IISLockdown.exe" in the "How To" section of this guide.
  • For information on troubleshooting IISLockdown, see Microsoft Knowledge Base article 325864, "How To: Install and Use the IIS Lockdown Wizard." (The most common problem is receiving unexpected "404 File Not Found" error messages after running IISLockdown.)
  • For information on automating IISLockdown, see Microsoft Knowledge Base article 310725, "How To: Run the IIS Lockdown Wizard Unattended in IIS."

Install and Configure URLScan

URLScan is installed when you run IISLockdown, although you can download it and install it separately.

Note   IIS 6.0 on Windows Server 2003 has functionality equivalent to URLScan built in. Your decision whether to install UrlScan should be based on your specific organizational requirements. For more information, see "Installing UrlScan 2.5."

To install URLScan without running IISLockdown

  1. Download IISlockd.exe from

  2. Run the following command to extract the URLScan setup:

    iislockd.exe /q /c

URLScan blocks requests that contain unsafe characters (for example, characters that have been used to exploit vulnerabilities, such as ".." used for directory traversal). URLScan logs requests that contain these characters in the %windir%\system32\inetsrv\urlscan directory.

You configure URLScan using settings in the .ini file %windir%\system32\inetsrv\urlscan\urlscan.ini.

In addition to blocking malicious requests, you can use URLScan to defend your server against denial of service attacks before the requests reach ASP.NET. To do this, set limits in the MaxAllowedContentLength, MaxUrl, and MaxQueryString arguments in the URLScan.ini file. For more information, see "How To: Use URLScan" in the "How To" section of this guide.

Reversing URLScan Changes

There is no automatic operation to remove URLScan. If you have problems with URLScan, you can either remove it from IIS or you can analyze the problem by logging requests that are rejected. To do this, use the option RejectResponseUrl=/~* in the URLScan .ini file.

For more information about how to remove ISAPI filters, see "Step 13. ISAPI Filters," later in this chapter.

More Information

See the following articles for more information about the URLScan tool:

  • For information on running URLScan, see "How To: Use URLScan" in the "How To" section of this guide.
  • For information about URLScan configuration and the URLScan.ini file settings, see Microsoft Knowledge Base article 326444, "How To: Configure the URLScan Tool."

Step 3. Services

Services that do not authenticate clients, services that use insecure protocols, or services that run with too much privilege are risks. If you do not need them, do not run them. By disabling unnecessary services you quickly and easily reduce the attack surface .You also reduce your overhead in terms of maintenance (patches, service accounts, and so on.)

If you run a service, make sure that it is secure and maintained. To do so, run the service using a least privilege account, and keep the service current by applying patches.

During this step, you:

  • Disable unnecessary services.
  • Disable FTP, SMTP, and NNTP unless you require them.
  • Disable the ASP.NET State service unless you require it.

Disable Unnecessary Services

Windows services are vulnerable to attackers who can exploit the service's privileges and capabilities and gain access to local and remote system resources. As a defensive measure, disable Windows services that your systems and applications do not require. You can disable Windows services by using the Services MMC snap-in located in the Administrative Tools programs group.

Note   Before you disable a service, make sure that you first test the impact in a test or staging environment.

In most cases, the following default Windows services are not needed on a Web server: Alerter, Browser, Messenger, Netlogon (required only for domain controllers), Simple TCP/IP Services, and Spooler.

The Telnet service is installed with Windows, but it is not enabled by default. IIS administrators often enable Telnet. However, it is an insecure protocol susceptible to exploitation. Terminal Services provides a more secure remote administration option. For more information about remote administration, see "Remote Administration," later in this chapter.

Disable FTP, SMTP, and NNTP Unless You Require Them

FTP, SMTP, and NNTP are examples of insecure protocols that are susceptible to misuse. If you do not need them, do not run them. If you currently run them, try to find a secure alternative. If you must run them, secure them.

Note   IIS Lockdown provides options for disabling FTP, SMTP, and NNTP.

**Note   **By default,****IIS 6.0 disables these services at the time of installation.

To eliminate the possibility of FTP exploitation, disable the FTP service if you do not use it. If FTP is enabled and is available for outbound connections, an attacker can use FTP to upload files and tools to a Web server from the attacker's remote system. Once the tools and files are on your Web server, the attacker can attack the Web server or other connected systems.

If you use FTP protocol, neither the user name and password you use to access the FTP site nor the data you transfer is encoded or encrypted. IIS does not support SSL for FTP. If secure communications are important and you use FTP as your transfer protocol (rather than World Wide Web Distributed Authoring and Versioning (WebDAV) over SSL), consider using FTP over an encrypted channel such as a Virtual Private Network (VPN) that is secured with Point-to-Point Tunneling Protocol (PPTP) or Internet Protocol Security (IPSec).

Disable the ASP.NET State Service Unless You Require It

The .NET Framework installs the ASP.NET State service (aspnet_state.exe) to manage out-of-process user session state for ASP.NET Web applications and Web services. By default, this service is configured for manual startup and runs as the least privileged local ASPNET account. If none of your applications store state by using this service, disable it. For more information on securing ASP.NET session state, see the "Session State" section in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Step 4. Protocols

By preventing the use of unnecessary protocols, you reduce the potential for attack. The .NET Framework provides granular control of protocols through settings in the Machine.config file. For example, you can control whether your Web Services can use HTTP GET, POST or SOAP. For more information about configuring protocols in Machine.config, see "Step 16. Machine.Config."

During this step, you:

  • Disable or secure WebDav.
  • Harden the TCP/IP stack.
  • Disable NetBIOS and SMB.

Disable or Secure WebDAV

IIS supports the WebDAV protocol, which is a standard extension to HTTP 1.1 for collaborative content publication. Disable this protocol on production servers if it is not used.

Note   IISLockdown provides an option to remove support for WebDAV.

Note   By default**,** IIS 6.0 disables this protocol at the time of installation.

WebDAV is preferable to FTP from a security perspective, but you need to secure WebDAV. For more information, see Microsoft Knowledge Base article 323470, "How To: Create a Secure WebDAV Publishing Directory."

If you do not need WebDAV, see Microsoft Knowledge Base article 241520, "How To: Disable WebDAV for IIS 5.0."

Harden the TCP/IP Stack

Windows 2000 and Windows Server 2003 support the granular control of many parameters that configure its TCP/IP implementation. Some of the default settings are configured to provide server availability and other specific features.

Disable NetBIOS and SMB

Disable all unnecessary protocols, including NetBIOS and SMB. Web servers do not require NetBIOS or SMB on their Internet-facing network interface cards (NICs). Disable these protocols to counter the threat of host enumeration.

Note   The SMB protocol can return rich information about a computer to unauthenticated users over a Null session. You can block null sessions by setting the RestrictAnonymous registry key as described in "Step 9. Registry."

Note   Test your changes before implementing them in production. Disabling sharing or NetBIOS can negatively impact manageability for your scenario. For example, IIS uses the NetUserChangePassword API which depends on NetBIOS. If you permit users to change passwords through IIS, this will no longer work.

Disabling NetBIOS

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 NetBIOS is not sufficient to prevent SMB communication because if a standard NetBIOS port is unavailable, SMB uses TCP port 445. (This port is referred to as the SMB Direct Host.) As a result, you must take steps to disable NetBIOS and SMB separately.

To disable NetBIOS over TCP/IP

Note   This procedure disables the Nbt.sys driver and requires that you restart the system.

  1. Right-click MyComputer on the desktop, and click Manage.

  2. Expand System Tools, and select DeviceManager.

  3. Right-click DeviceManager, point to View, and click Show hidden devices.

  4. Expand Non-Plug and Play Drivers.

  5. Right-click NetBios over Tcpip, and click Disable.

    This disables the NetBIOS direct host listener on TCP 445 and UDP 445.

Disabling SMB

SMB uses the following ports:

  • TCP port 139
  • TCP port 445

To disable SMB, use the TCP/IP properties dialog box in your Local Area Connection properties to unbind SMB from the Internet-facing port.

To unbind SMB from the Internet-facing port

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

Note   The WINS tab of the Advanced TCP/IP Settings dialog box contains a Disable NetBIOS over TCP/IP radio button. Selecting this option disables the NetBIOS session service that uses TCP port 139. It does not disable SMB completely. To do so, use the procedure above.

Step 5. Accounts

You should remove accounts that are not used because an attacker might discover and use them. Require strong passwords. Weak passwords increase the likelihood of a successful brute force or dictionary attack. Use least privilege. An attacker can use accounts with too much privilege to gain access to unauthorized resources.

During this step, you:

  • Delete or disable unused accounts.
  • Disable the Guest account.
  • Rename the Administrator account.
  • Disable the IUSR Account.
  • Create a custom anonymous Web account.
  • Enforce strong password policies.
  • Restrict remote logons.
  • Disable Null sessions (anonymous logons).

Delete or Disable Unused Accounts

Unused accounts and their privileges can be used by an attacker to gain access to a server. Audit local accounts on the server and disable those that are unused. If disabling the account does not cause any problems, delete the account. (Deleted accounts cannot be recovered.) Disable accounts on a test server before you disable them on a production server. Make sure that disabling an account does not adversely affect your application operation.

Note   The Administrator account and the Guest account cannot be deleted.

Disable the Guest Account

The Guest account is used when an anonymous connection is made to the computer. To restrict anonymous connections to the computer, keep this account disabled. The guest account is disabled by default on Windows 2000 and Windows Server 2003. To check whether or not it is enabled, display the Users folder in the Computer Management tool. The Guest account should be displayed with a cross icon. If it is not disabled, display its Properties dialog box and select Account is disabled.

Rename 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.

If you intend to perform local administration, configure the account to deny network logon rights and require the administrator to log on interactively. By doing so, you prevent users (well intentioned or otherwise) from using the Administrator account to log on to the server from a remote location. If a policy of local administration is too inflexible, implement a secure remote administration solution. For more information, see "Remote Administration" later in this chapter.

Disable the IUSR Account

Disable the default anonymous Internet user account, IUSR_MACHINE. This is created during IIS installation. MACHINE is the NetBIOS name of your server at IIS installation time.

Create a Custom Anonymous Web Account

If your applications support anonymous access (for example, because they use a custom authentication mechanism such as Forms authentication), create a custom least privileged anonymous account. If you run IISLockdown, add your custom user to the Web Anonymous Users group that is created. IISLockdown denies access to system utilities and the ability to write to Web content directories for the Web Anonymous Users group.

If your Web server hosts multiple Web applications, you may want to use multiple anonymous accounts, one per application, so that you can secure and audit the operations of each application independently.

For more information about hosting multiple Web applications see Chapter 20, "Hosting Multiple Web Applications."

Enforce Strong Password Policies

To counter password guessing and brute force dictionary attacks on your application, apply strong password policies. To enforce a strong password policy:

  • Setpassword length and complexity. Require strong passwords to reduce the threat of password guessing attacks or dictionary attacks. Strong passwords are eight or more characters and must include both alphabetical and numeric characters.
  • Setpassword expiration. Passwords that expire regularly reduce the likelihood that an old password can be used for unauthorized access. Frequency of expiration is usually guided by a company's security policy.

Table 16.3 shows the default and recommended password policy settings.

Table 16.3   Password Policy Default and Recommended Settings

Password Policy Default Setting Recommended Minimum Setting
Enforce password history 1 password remembered. 24 passwords remembered.
Maximum password age 42 days 42 days
Minimum password age 0 days 2 days
Minimum password length 0 characters 8 characters
Passwords must meet complexity requirement. Disabled Enabled
Store password using reversible encryption for all users in the domain. Disabled Disabled

In addition, record failed logon attempts so that you can detect and trace malicious behavior. For more information, see "Step 10. SQL Server Security" in Chapter 18, "Securing Your Database Server."

Restrict Remote Logons

Remove the Access this computer from the network privilege from the Everyone group to restrict who can log on to the server remotely.

Disable Null Sessions (Anonymous Logons)

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

Once an attacker establishes a null session, he or she can perform a variety of attacks, including enumeration techniques used to collect system-related information from the target computer — information that can greatly assist subsequent attacks. The type of information that can be returned over a null session includes domain and trust details, shares, user information (including groups and user rights), registry keys, and more.

Restrict Null sessions by setting RestrictAnonymous to 1 in the registry at the following subkey:


For more information, see Microsoft Knowledge Base article 246261, "How To: Use the RestrictAnonymous Registry Value in Windows 2000."

For more information on using RestrictAnonymous in Windows Server 2003, see RestrictAnonymouse.

Additional Considerations

The following is a list of additional steps you can consider to further improve security on your Web server:

  • Require approval for account delegation.

    Do not mark domain accounts in Active Directory as trusted for delegation unless you first obtain special approval to do so.

  • Do not use shared accounts.

    Do not create shared account for use by multiple individuals. Authorized individuals must have their own accounts. The activities of individuals can be audited separately and group membership and privileges appropriately assigned.

  • Restrict the Local Administrators Group Membership.

    Try to limit administration accounts to two. This helps provide accountability. Also, passwords must not be shared, again to provide accountability.

  • Require the Administrator to log on interactively.

    If you perform local administration only, you can require your Administrator account to log on interactively by removing the Access this computer from the network privilege.

Step 6. Files and Directories

Install Windows 2000 and Windows Server 2003 on partitions formatted with the NTFS file system so that you benefit from NTFS permissions to restrict access. 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.

During this step, you:

  • Restrict the Everyone group.
  • Restrict the anonymous Web account(s).
  • Secure or remove tools, utilities, and SDKs.
  • Remove sample files.

Restrict the Everyone Group

The default NTFS permissions for Windows 2000 grant members of the Everyone group full control access to a number of key locations, including the root directory, \inetpub, and \inetpub\scripts.

First grant FULL CONTROL to the Administrator account to the root (\), then remove access rights for the Everyone group from the following directories.

  • Root (\)
  • System directory (\WINNT\system32)
  • Framework tools directory (\WINNT\Microsoft.NET\Framework\{version})
  • Web site root directory and all content directories (the default is \inetpub\*)

Note   This is not an issue in Windows Server 2003.

Restrict Access to the IIS Anonymous Account

The anonymous account is well known. Attackers target this well known account to perform malicious actions. To secure the anonymous account:

  • Deny write access to Web content directories.

    Make sure that it is not possible for this account to write to content directories, for example, to deface Web sites.

  • Restrict access to System tools.

    In particular, restrict access to command-line tools located in \WINNT\System32.

  • Assign permissions to groups instead of individual accounts.

    Assigning users to groups and applying permissions to groups instead of individual accounts is good practice. For the anonymous account, create a group and add the anonymous account to it and then explicitly deny access to the group for key directories and files. Assigning permissions to a group allows you to more easily change the anonymous account or create additional anonymous accounts because you do not need to recreate the permissions.

    Note   IISLockdown denies write access to content directories for the anonymous account by applying a deny write access control entry (ACE) for the Web Anonymous Users and Web Applications groups. It also adds a deny execute ACL on command-line tools.

  • Use separate accounts for separate applications.

    If your Web server hosts multiple applications, use a separate anonymous account for each application. Add the accounts to an anonymous Web users group, for example, the Web Anonymous Users group created by IISLockdown, and then configure NTFS permissions using this group.

    For more information about using multiple anonymous accounts and hosting multiple applications, see Chapter 20, "Hosting Multiple ASP.NET Applications."

Secure or Remove Tools, Utilities and SDKs

SDKs and resource kits should not be installed on a production Web server. Remove them if they are present.

  • Ensure that only the .NET Framework Redistributable package is installed on the server and no SDK utilities are installed. Do not install Visual Studio .NET on production servers.
  • Ensure that access to powerful system tools and utilities, such as those contained in the \Program Files directory, is restricted. IISLockdown does this for you.
  • Debugging tools should not be available on the Web server. If production debugging is necessary, then you should create a CD that contains the necessary debugging tools.

Remove Sample Files

Sample applications are typically not configured with high degrees of security. It is possible that an attacker could exploit an inherent weakness in a sample application or in its configuration to attack your Web site. Remove sample applications to reduce the areas where your Web server can be attacked.

Additional Considerations

Also consider removing unnecessary Data Source Names (DSNs). These contain clear text connection details used by applications to connect to OLE DB data sources. Only those DSNs required by Web applications should be installed on the Web server.

Step 7. Shares

Remove any unused shares and harden the NTFS permissions on any essential shares. By default all users have full control on newly created file shares. Harden these default permissions to ensure that only authorized users can access files exposed by the share. In addition to explicit share permissions, use NTFS ACLs for files and folders exposed by the share.

Note   Windows Server 2003 restricts sharing by default. You need to run the Server service to enable sharing. If you have enabled the service, you will need to follow these steps.

During this step, you:

  • Remove unnecessary shares.
  • Restrict access to required shares.

Remove Unnecessary Shares

Remove all unnecessary shares. To review shares and associated permissions, run the Computer Management MMC snap-in, and select Shares from SharedFolders as shown in Figure 16.3.


Figure 16.3

Computer Management MMC snap-in Shares

Restrict Access to Required Shares

Remove the Everyone group and grant specific permissions instead. Everyone is used when you do not have restrictions on who should have access to the share.

Additional Considerations

If you do not allow remote administration of your server, remove unused administrative shares, for example C$ and Admin$.

Note   Some applications may require administrative shares. Examples include Microsoft Systems Management Server (SMS) and Microsoft Operations Manager (MOM). For more information, see Microsoft Knowledge Base article 318751, "How To: Remove Administrative Shares in Windows 2000 or Windows NT 4.0."

Step 8. Ports

Services that run on the server use specific ports so that they can serve incoming requests. Close all unnecessary ports and perform regular audits to detect new ports in the listening state, which could indicate unauthorized access and a security compromise.

During this step, you:

  • Restrict Internet-facing ports to TCP 80 and 443.
  • Encrypt or restrict intranet traffic.

Restrict Internet-Facing Ports to TCP 80 and 443

Limit inbound traffic to port 80 for HTTP and port 443 for HTTPS (SSL).

For outbound (Internet-facing) NICs, use IPSec or TCP filtering. For more information, see "How To: Use IPSec for Filtering Ports and Authentication" in the "How To" section of this guide.

Encrypt or Restrict Intranet Traffic

For inside (intranet-facing) NICs, if you do not have a secure data center and you have sensitive information passing between computers, you need to consider whether to encrypt the traffic and whether to restrict communications between the Web server and downstream servers (such as an application server or database server). Encrypting network traffic addresses the threat posed by network eavesdropping. If the risk is deemed sufficiently small you may choose not to encrypt the traffic.

The type of encryption used also affects the types of threats that it addresses. For example, SSL is application-level encryption, whereas IPSec is transport layer encryption. As a result, SSL counters the threat of data tampering or information disclosure from another process on the same machine, particularly one running under a different account in addition to the network eavesdropping threat.

Step 9. Registry

The registry is the repository for many vital server configuration settings. As such, you must ensure that only authorized administrators have access to it. If an attacker is able to edit the registry, he or she can reconfigure and compromise the security of your server.

During this step, you:

  • Restrict remote administration of the registry.
  • Secure the SAM (stand-alone servers only).

Restrict Remote Administration of the Registry

The Winreg key determines whether registry keys are available for remote access. By default, this key is configured to prevent users from remotely viewing most keys in the registry, and only highly privileged users can modify it. On Windows 2000 and Windows Server 2003, remote registry access is restricted by default to members of the Administrators and Backup operators group. Administrators have full control and backup operators have read-only access.

The associated permissions at the following registry location determine who can remotely access the registry.


To view the permissions for this registry key, run Regedt32.exe, navigate to the key, and choose Permissions from the Security menu.

Note   Some services require remote access to the registry. Refer to Microsoft Knowledge Base article 153183, "How to Restrict Access to the Registry from a Remote Computer," to see if your situation demands limited remote registry access.

Secure the SAM (Stand-alone Servers Only)

Stand-alone servers store account names and one-way (non-reversible) password hashes (LMHash) in the local Security Account Manager (SAM) database. The SAM is part of the registry. Typically, only members of the Administrators group have access to the account information.

Although the passwords are not actually stored in the SAM and password hashes are not reversible, if an attacker obtains a copy of the SAM database, the attacker can use brute force password techniques to obtain valid user names and passwords.

Restrict LMHash storage in the SAM by creating the key (not value) NoLMHash in the registry as follows:


For more information, see Microsoft Knowledge Base article 299656, "New Registry Key to Remove LM Hashes from Active Directory and Security Account Manager."

Step 10. Auditing and Logging

Auditing does not prevent system attacks, although it is an important aid in identifying intruders and attacks in progress, and can assist you in diagnosing attack footprints. Enable a minimum level of auditing on your Web server and use NTFS permissions to protect the log files so that an attacker cannot cover his tracks by deleting or updating the log files in any way. Use IIS W3C Extended Log File Format Auditing.

During this step, you:

  • Log all failed Logon attempts.
  • Log all failed actions across the file system.
  • Relocate and secure the IIS log files.
  • Archive log files for offline analysis.
  • Audit access to the Metabase.bin file.

Log All Failed Logon Attempts

You must log failed logon attempts to be able to detect and trace suspicious behavior.

To audit failed logon attempts

  1. Start the Local Security Policy tool from the Administrative Tools program group.
  2. Expand Local Policies and then select Audit Policy
  3. Double-click Audit account logon events.
  4. Click Failure and then OK.

Logon failures are recorded as events in the Windows security event log. The following event IDs are suspicious:

  • 531. This means an attempt was made to log on using a disabled account.
  • 529. This means an attempt was made to log on using an unknown user account or using a valid user account but with an invalid password. An unexpected increase in the number of these audit events might indicate an attempt to guess passwords.

Log All Failed Actions Across the File System

Use NTFS auditing on the file system to detect potentially malicious attempts. This is a two-step process.

To enable logging

  1. Start the Local Security Policy tool from the Administrative Tools program group.
  2. Expand Local Policies and then select Audit Policy
  3. Double-click Audit object access.
  4. Click Failure and then click OK.

To audit failed actions across the file system

  1. Start Windows Explorer and navigate to the root of the file system.

  2. Right-click and then click Properties.

  3. Click the Security tab.

  4. Click Advanced and then click the Auditing tab.

  5. Click Add and then enter Everyone in the Name field.

  6. Click OK and then select all of the Failed check boxes to audit all failed events.

    By default, this applies to the current folder and all subfolders and files.

  7. Click OK three times to close all open dialog boxes.

    Failed audit events are logged to the Windows security event log.

Relocate and Secure the IIS Log Files

By moving and renaming the IIS log files, you make it much more difficult for an attacker to cover his tracks. The attacker must locate the log files before he or she can alter them. To make an attacker's task more difficult still, use NTFS permissions to secure the log files.

Move and rename the IIS log file directory to a different volume than your Web site. Do not use the system volume. Then, apply the following NTFS permissions to the log files folder and subfolders.

  • Administrators: Full Control
  • System: Full Control
  • Backup Operators: Read

Archive Log Files for Offline Analysis

To facilitate the offline analysis of IIS log files, you can use a script to automate secure removal of log files from an IIS server. Log files should be removed at least every 24 hours. An automated script can use FTP, SMTP, HTTP, or SMB to transfer log files from a server computer. However, if you enable one of these protocols, do so securely so that you do not open any additional attack opportunities. Use an IPSec policy to secure ports and channels.

Audit Access to the Metabase.bin File

Audit all failures by the Everyone group to the IIS metabase.bin file located in \WINNT\System32\inetsrv\. Do the same for the \Metabase backup folder for the backup copies of the metabase.

Additional Considerations

Additionally, you can configure IIS W3C Extended Log File Format Auditing. Select W3C Extended Log File Format on the WebSite tab of the Web site's properties dialog box. You can then choose Extended Properties such as URI Stem and URI Query.

Step 11. Sites and Virtual Directories

Relocate Web roots and virtual directories to a non-system partition to protect against directory traversal attacks. These attacks allow an attacker to execute operating system programs and utilities. It is not possible to traverse across drives. For example, this approach ensures that any future canonicalization worm that allows an attacker to access system files will fail. For example, if the attacker formulates a URL that contains the following path, the request fails:


During this step, you:

  • Move your Web site to a non-system volume.
  • Disable the parent paths setting.
  • Remove potentially dangerous virtual directories.
  • Remove or secure RDS.
  • Set Web permissions.
  • Remove or secure FrontPage Server Extensions.

Move Your Web site to a Non-System Volume

Do not use the default \inetpub\wwwroot directory. For example, if your system is installed on the C: drive, then move your site and content directory to the D: drive. This mitigates the risks associated with unforeseen canonicalization issues and directory traversal attacks.

Disable the Parent Paths Setting

This IIS metabase setting prevents the use of ".." in script and application calls to functions such as MapPath. This helps guard against directory traversal attacks.

To disable parent paths

  1. Start IIS.
  2. Right-click the root of your Web site, and click Properties.
  3. Click the HomeDirectory tab.
  4. Click Configuration.
  5. Click the AppOptions tab.
  6. Clear Enableparentpaths.

Note   If you use the Application Center 2002 Administration Site, see Microsoft Knowledge Base article 288309, "PRB: Disabling Parent Paths Breaks User Interface."

Note   The parent paths setting is disabled by default in IIS 6.0.

Remove Potentially Dangerous Virtual Directories

Sample applications are not installed by default and should not be installed on production Web servers. Remove all sample applications, including the ones that can be accessed only from the local computer with https://localhost, or

Remove the following virtual directories from production servers: IISSamples, IISAdmin, IISHelp, and Scripts.

Note   IISLockdown provides an option to remove the Scripts, IISSamples, IISAdmin, and IISHelp virtual directories.

Remove or Secure RDS

Remote Data Services (RDS) is a component that enables controlled Internet access to remote data resources through IIS. The RDS interface is provided by Msadcs.dll, which is located in the following directory: program files\common files\system\Msadc.

Removing RDS

If your applications do not use RDS, remove it.

To remove RDS support

  1. Remove the /MSADC virtual directory mapping from IIS.

  2. Remove the RDS files and subdirectories at the following location:

    \Program Files\Common Files\System\Msadc

  3. Remove the following registry key:


Note   IISLockdown provides an option to remove the MSADC virtual directory. Note that IISLockdown only removes the virtual directory, not the files or registry key.

Securing RDS

If your applications require RDS, secure it.

To secure RDS

  1. Delete the samples at the following location:

    \Progam Files\Common Files\System\Msadc\Samples

  2. Remove the following registry key:


  3. Disable Anonymous access for the MSADC virtual directory in IIS.

  4. Create a HandlerRequired registry key in the following location:


  5. Create a new DWORD value, and set it to 1 (1 indicates safe mode, while 0 indicates unsafe mode.

Note   You can use the registry script file Handsafe.reg to change the registry key. The script file is located in the msadc directory: \Program Files\Common Files\System\msadc

For more information about securing RDS, see the following:

Set Web Permissions

Web permissions are configured through the IIS snap-in and are maintained in the IIS metabase. They are not NTFS permissions.

Use the following Web permissions:

  • Read Permissions. Restrict Read permissions on include directories.

  • Write and Execute Permissions. Restrict Write and Execute permissions on virtual directories that allow anonymous access.

  • Script source access. Configure Script source access permissions only on folders that allow content authoring.

  • Write. Configure Write permissions only on folders that allow content authoring. Grant write access only to content authors.

    Note   Folders that support content authoring should be configured to require authentication and SSL for encryption.

Remove or Secure FrontPage Server Extensions

If you do not use FrontPage Server Extensions (FPSE), disable it. If you use FPSE, take the following steps to improve security:

Step 12. Script Mappings

Script mappings associate a particular file extension, such as .asp, to the ISAPI extension that handles it, such as Asp.dll. IIS is configured to support a range of extensions including .asp, .shtm, .hdc, and so on. ASP.NET HTTP handlers are a rough equivalent of ISAPI extensions. In IIS, file extensions, such as .aspx, are first mapped in IIS to Aspnet_isapi.dll, which forwards the request to the ASP.NET worker process. The actual HTTP handler that processes the file extension is then determined by the <HttpHandler> mapping in Machine.config or Web.config.

The main security issues associated with script mappings are:

  • An attacker could exploit a vulnerability found in an extension.

    This could occur if a vulnerability in an extension remains unpatched. Unused extensions increase the area of potential attack. For example, if you do not use a particular extension, you might not pay attention to relevant updates.

  • Server-side resources could be downloaded by the client.

    This could occur when a file extension is not mapped correctly. Files that should not be directly accessible by the client should either be mapped to the appropriate handler, based on its extension, or should be removed.

During this step, you:

  • Map IIS file extensions.
  • Map .NET Framework file extensions.

Map IIS File Extensions

On Windows 2000 and Windows Server 2003, the IIS file extensions of interest include: .asp, .asa, .cer, .cdx, .htr, .idc, .shtm, .shtml, .stm, and .printer.

If you do not use any one of these extensions, map the extension to the 404.dll, which is provided by IISLockdown. For example, if you do not want to serve ASP pages to clients, map .asp to the 404.dll.

The mappings altered by IISLockdown depend on the server template that you choose:

  • Static Web Server. If you run IISLockdown and choose the Static Web server option, then all of the above extensions are mapped to the 404.dll.
  • Dynamic Web Server. If you choose the Dynamic Web server option, which is the preferred option when serving ASP.NET pages, then .htr, .idc, .shtm, .shtml, .stm, and .printer are mapped to the 404.dll, while .asp, .cer, .cdx, and .asa are not. In this case, you should manually map .cer, .cdx, and .asa to the 404.dll. If you are not serving .asp, then you can map that as well.

Why Map to the 404.dll?

By mapping file extensions to the 404.dll, you prevent files from being returned and downloaded over HTTP. If you request a file with an extension mapped to the 404.dll, a Web page with the message "HTTP 404 - File not found" is displayed. You are recommended to map unused extensions to the 404.dll rather than deleting the mapping. If you delete a mapping, and a file is mistakenly left on the server (or put there by mistake) it can be displayed in clear text when it is requested because IIS does not know how to process it.

To map a file extension to the 404.dll

  1. Start IIS.

  2. Right-click your server name in the left window, and then click Properties.

  3. Ensure that the WWWService is selected in the MasterProperties drop-down list, and then click the adjacent Edit button.

  4. Click the HomeDirectory tab.

  5. Click Configuration. The tabbed page shown in Figure 16.4 is displayed.


    Figure 16.4

Mapping application extensions

  1. Select one of the extensions from the list, and then click Edit.

  2. Click Browse and navigate to \WINNT\system32\inetsrv\404.dll.

    Note   This step assumes that you have previously run IISlockd.exe, as the 404.dll is installed by the IISLockdown tool.

  3. Click Open, and then click OK.

  4. Repeat steps 6, 7 and 8 for all of the remaining file extensions.

Map .NET Framework File Extensions

The following .NET Framework file extensions are mapped to aspnet_isapi.dll: .asax, .ascx, .ashx, .asmx, .aspx, .axd, .vsdisco, .jsl, .java, .vjsproj, .rem, .soap, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .licx, .resx, and .resources.

The .NET Framework protects file extensions that should not be directly called by clients by associating them with System.Web.HttpForbiddenHandler in Machine.config. The following file extensions are mapped to System.Web.HttpForbiddenHandler by default: .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx, and .resources.

For more information on HTTP handlers, see Step 16. Machine.Config.

Additional Considerations

Because IIS processes a Web request first, you could map .NET Framework file extensions that you do not want clients to call, to the 404.dll directly. This does two tasks:

  • The 404.dll handles and rejects requests before they are passed to ASP.NET and before they are processed by the ASP.NET worker process. This eliminates unnecessary processing by the ASP.NET worker process. Moreover, blocking requests early is a good security practice.
  • The 404.dll returns the message "HTTP 404 - File not found" and System.Web.HttpForbiddenHandler returns the message "This type of page is not served." Arguably, the "File not found" message reveals less information and thus could be considered more secure.

Step 13. ISAPI Filters

In the past, vulnerabilities in ISAPI filters caused significant IIS exploitation. There are no unneeded ISAPI filters after a clean IIS installation, although the .NET Framework installs the ASP.NET ISAPI filter (Aspnet_filter.dll), which is loaded into the IIS process address space (Inetinfo.exe) and is used to support cookie-less session state management.

If your applications do not need to support cookie-less session state and they do not set the cookieless attribute to true on the <sessionState> element, this filter can be removed.

During this step, you remove unused ISAPI filters.

Remove Unused ISAPI Filters

Remove any unused ISAPI filters as explained in the following section.

To view ISAPI filters

  1. To start IIS, select Internet Services Manager from the Administrative Tools programs group.

  2. Right-click the machine (not Web site, because filters are machine wide), and then click Properties.

  3. Click Edit.

  4. Click the ISAPI Filters tab.

    The tabbed page shown in Figure 16.5 is displayed:


    Figure 16.5

Removing unused ISAPI filters

Step 14. IIS Metabase

Security and other IIS configuration settings are maintained in the IIS metabase file. Harden the NTFS permissions on the IIS metabase (and the backup metabase file) to be sure that attackers cannot modify your IIS configuration in any way (for example, to disable authentication for a particular virtual directory.)

During this step, you:

  • Restrict access to the metabase using NTFS permissions.
  • Restrict banner information returned by IIS.

Restrict Access to the Metabase Using NTFS Permissions

Set the following NTFS permissions on the IIS metabase file (Metabase.bin) in the \WINNT\system32\inetsrv directory.

  • Local System: Full Control
  • Administrators: Full Control

Restrict Banner Information Returned by IIS

Banner information can reveal software versions and other information that may help an attacker. Banner information can reveal the software you run, allowing an attacker to exploit known software vulnerabilities.

When you retrieve a static page, for example, an .htm or a .gif file, a content location header is added to the response. By default, this content header references the IP address, and not the fully qualified domain name (FQDN). This means that your internal IP address is unwittingly exposed. For example, the following HTTP response header shows the IP address in bold font:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

You can hide the content location returned in HTTP response headers by modifying a value in the IIS metabase to change the default behavior from exposing IP addresses, to sending the FQDN instead.

For more information about hiding the content location in HTTP responses, see Microsoft Knowledge Base article 218180, "Internet Information Server Returns IP Address in HTTP Header (Content-Location)."

Step 15. Server Certificates

If your Web application supports HTTPS (SSL) over port 443, you must install a server certificate. This is required as part of the session negotiation process that occurs when a client establishes a secure HTTPS session.

A valid certificate provides secure authentication so that a client can trust the server it is communicating with, and secure communication so that sensitive data remains confidential and tamperproof over the network.

During this step, you validate your server certificate.

Validate Your Server Certificate

Check the following four items to confirm the validity of your Web server certificate:

  • Check that the valid from and valid to dates are in range.
  • Check that the certificate is being used correctly. If it was issued as a server certificate it should not be used for e-mail.
  • Check that the public keys in the certificate chain are all valid up to a trusted root.
  • Check that it has not been revoked. It must not be on a Certificate Revocation List (CRL) from the server that issued the certificate.

Step 16. Machine.Config

This section covers hardening information about machine level settings that apply to all applications. For application specific hardening settings, see Chapter 19, "Securing Your ASP.NET Application."

The Machine.config file maintains numerous machine wide settings for the .NET Framework, many of which affect security. Machine.config is located in the following directory:


Note   You can use any text or XML editor (Notepad, for example) to edit XML configuration files. XML tags are case sensitive, so be sure to use the correct case.

During this step, you:

  • Map protected resources to HttpForbiddenHandler.
  • Verify that disabled.
  • Verify that debug compiles are disabled.
  • Verify that ASP.NET errors are not returned to the client.
  • Verify session state settings.

Map Protected Resources to HttpForbiddenHandler

HTTP handlers are located in the Machine.config file beneath the <httpHandlers> element. HTTP handlers are responsible for processing Web requests for specific file extensions. Remoting should not be enabled on front-end Web servers; enable remoting only on middle-tier application servers that are isolated from the Internet.

Note   If you are running .NET 2.0, the < httpHandlers> setting is located in the machine-level Web.config file, located in the same directory as the Machine.config file.

The following file extensions are mapped in the Machine.config file to HTTP handlers:

  • .aspx is used for ASP.NET pages
  • .rem and .soap are used for Remoting.
  • .asmx is used for Web Services.
  • .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx, and .resources are protected resources and are mapped to System.Web.HttpForbiddenHandler.

For .NET Framework resources, if you do not use a file extension, then map the extension to System.Web.HttpForbiddenHandler in the Machine.config file, as shown in the following example:

<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />

In this case, the .vbproj file extension is mapped to System.Web.HttpForbiddenHandler. If a client requests a path that ends with .vbproj, then ASP.NET returns a message that states "This type of page is not served."

  • The following guidelines apply to handling .NET Framework file extensions:
  • Map extensions you do not use to HttpForbiddenHandler. If you do not serve ASP.NET pages, then map .aspx to HttpForbiddenHandler. If you do not use Web Services, then map .asmx to HttpForbiddenHandler.
  • Disable Remoting on Internet-facing Web servers. Map remoting extensions (.soap and .rem) on Internet-facing Web servers to HttpForbiddenHandler.

Disable .NET Remoting

To disable .NET Remoting disable requests for .rem and .soap extensions, use the following elements beneath <httpHandlers>:

<add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>

Note   This does not prevent a Web application on the Web server from connecting to a downstream object by using the Remoting infrastructure. However, it prevents clients from connecting to objects on the Web server.

Verify That Tracing Is Disabled

You configure tracing in Machine.config by using the <trace> element. While it is useful on development and test servers, do not enable tracing on production servers, because system-level trace information can greatly assist an attacker to profile an application and probe for weak spots.

Use the following configuration on production servers:

<trace enabled="false" localOnly="true" pageOutput="false" 
       requestLimit="10" traceMode="SortByTime"/>

Set enabled="false" on production servers. If you do need to trace problems with live applications, simulate the problem in a test environment, or if necessary, enable tracing and set localOnly="true" to prevent trace details from being returned to remote clients.

Verify That Debug Compiles Are Disabled

You can control whether or not the compiler produces debug builds that include debug symbols by using the <compilation> element. To turn off debug compiles, set debug="false" as shown below:

<compilation debug="false" explicit="true" defaultLanguage="vb" />

Verify That ASP.NET Errors Are Not Returned to Clients

You can use the <customErrors> element to configure custom, generic error messages that should be returned to the client in the event of an application exception condition.

Make sure that the mode attribute is set to "RemoteOnly" as shown in the following example:

<customErrors mode="RemoteOnly" />

After installing an ASP.NET application, you can configure the setting to point to your custom error page as shown in the following example:

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

Verify Session State Settings

If you do not use session state, verify that session state is disabled in Machine.config as shown in the following example:

<sessionState mode="Off" . . . />

Also, ensure that the ASP.NET State Service is disabled. The default session state mode is "InProc" and the ASP.NET State Service is set to manual. For more information about securing session state if you install an ASP.NET application that requires it, see "Session State," in Chapter 19, "Securing Your ASP.NET Application and Web Services."

Step 17. Code Access Security

Machine level code access security policy is determined by settings in the Security.config file located in the following directory: %windir%\Microsoft.NET\Framework\{version}\CONFIG

Run the following command to be sure that code access security is enabled on your server:

caspol -s On

For more information about configuring code access security for ASP.NET Web applications, see Chapter 9, "Using Code Access Security with ASP.NET."

During this step, you:

  • Remove all permissions for the local intranet zone.
  • Remove all permissions for the Internet zone.

Remove All Permissions for the Local Intranet Zone

The local intranet zone applies permissions to code running from UNC shares or internal Web sites. Reconfigure this zone to grant no permissions by associating it with the Nothing permission set.

To remove all permissions for the local intranet zone

  1. Start the Microsoft .NET Framework version 1.1 Configuration tool from the Administrative Tools program group.

  2. Expand RuntimeSecurityPolicy, expand Machine, and then expand CodeGroups.

  3. Expand All_Code and then select LocalIntranet_Zone.

  4. Click Edit Code Group Properties.

  5. Click the PermissionSet tab.

  6. Select Nothing from the drop-down Permission list.

  7. Click OK.

    The dialog box shown in Figure 16.6 is displayed.


    Figure 16.6

Setting LocalIntranet_Zone code permissions to Nothing

Remove All Permissions for the Internet Zone

The Internet zone applies code access permissions to code downloaded over the Internet. On Web servers, this zone should be reconfigured to grant no permissions by associating it with the Nothing permission set.

Repeat the steps shown in the preceding section, "Remove All Permissions for the Local Intranet Zone," except set the Internet_Zone to the Nothing permission set.

Snapshot of a Secure Web Server

A snapshot view that shows the attributes of a secure Web server allows you to quickly and easily compare settings with your own Web server. The settings shown in Table 16.4 are based on Web servers that host Web sites that have proven to be very resilient to attack and demonstrate sound security practices. By following the proceeding steps you can generate an identically configured server, with regard to security.

Table 16.4   Snapshot of a Secure Web Server

Component Characteristics
Patches and Updates Latest service packs and patches are applied for Windows, IIS, and the .NET Framework.
Services Unnecessary services are disabled.

NNTP, SMTP, and FTP are disabled unless you require them.

WebDAV is disabled or secured if used.

Service accounts run with least privilege.

ASP.NET Session State service is disabled if not required.

Protocols The NetBIOS and SMB protocols are not enabled on the server.

The TCP stack has been hardened.

Accounts Unused accounts are removed.

Guest account is disabled.

The default administrator account is renamed and has a strong password.

Default anonymous account (IUSR_Machine) is disabled.

Custom anonymous account is used for anonymous access.

Strong password policies are enforced.

Remote logons are restricted.

Null sessions (anonymous logons) are disabled.

Approval if required for account delegation.

Shared accounts are not used.

Membership of local administrators group is restricted (ideally to two members).

Administrators are required to log on interactively (or a secure remote administration solution is implemented).

Files and Directories Everyone group has no rights to system, Web, or tools directories.

Anonymous account has no access to Web site content directories and system utilities.

Tools, utilities, and SDKs are removed or secured.

Sample files are removed.

Unnecessary DSNs are removed.

Shares Unused shares are removed from the server.

Access to required shares is secured (shares are not enabled to "Everyone" unless necessary.)

Administration shares (C$ and Admin$) are removed if not required.

Ports All ports except 80 and 443 (SSL) are blocked, especially vulnerable ports 135–139 and 445.
Registry Remote administration of the registry is prevented.

SAM has been secured (stand-alone servers only).

Auditing and Logging Login failures are logged.

Object access failures by the Everyone group are logged.

Log files are relocated from %systemroot%\system32\LogFiles and secured with ACLs: Administrators and System have full control.

IIS logging is enabled.

Log files are regularly archived for offline analysis.

Access to the metabase.bin file is audited.

IIS is configured for W3C Extended Log File Format Auditing.

Sites and Virtual Directories Web roots and virtual directories are located on separate volumes from the system volume.

Parent Paths setting is disabled.

Dangerous virtual directories are removed (IIS Samples, MSADC, IISHelp, Scripts, and IISAdmin).

RDS is removed or secured.

Web permissions restrict inappropriate access.

Include directories restrict Read Web permissions.

Folders with Anonymous access restrict Write and Execute Web permissions.

Secured folders that allow content authoring allow Script Source Access Web permissions while all other folders do not.

FPSE is removed if not required.

Script Mappings Unused script-mappings are mapped to 404.dll: .idq, .htw , .ida , .shtml , .shtm , .stm , idc, .htr , .printer.

Note   The 404.dll is installed when you run the IIS Lockdown tool.

ISAPI Filters Unused ISAPI filters are removed.
IIS Metabase Access to IIS Metabase is restricted with NTFS permissions.

Banner information is restricted; the content location in HTTP response headers is hidden.

HttpForbiddenHandler Protected resources are mapped to System.Web.HttpForbiddenHandler
Remoting .NET Remoting is disabled.
  <add verb="*" path="*.rem"
  <add verb="*" path="*.soap"
trace Trace information and detailed error information is not returned to the client:
<trace enabled="false">
compilation Debug compiles are disabled
<compilation debug="false"/>
customErrors Error details are not returned to the client:
<customErrors mode="On" />

A generic error page writes errors to the Event Log.

sessionState Session State is disabled if not needed:
<sessionState mode="Off" />
Code Access Security
Code Access Security Code Access Security is enabled for the machine.

caspol -s On

LocalIntranet_Zone Local intranet zone has no permissions:


Internet_Zone Internet zone has no permissions:


Staying Secure

You need to monitor the security state of your server and update it regularly to help prevent newly discovered vulnerabilities from being exploited. To help keep your server secure:

  • Audit group membership.
  • Monitor audit logs.
  • Stay current with service packs and patches.
  • Perform security assessments.
  • Use security notification services.

Audit Group Membership

Keep track of user group membership, particularly for privileged groups such as Administrators. The following command lists the members of the Administrators group:

net localgroup administrators

Monitor Audit Logs

Monitor audit logs regularly and analyze the log files by manually viewing them or use the technique describe in Microsoft Knowledge Base article 296085, "How To: Use SQL Server to Analyze Web Logs."

Stay Current With Service Packs and Patches

Set up a schedule to analyze your server software and subscribe to security alerts. Use MBSA to regularly scan your server for missing patches. The following links provide the latest updates:

Perform Security Assessments

Use MBSA to regularly check for security vulnerabilities and to identify missing patches and updates. Schedule MBSA to run daily and analyze the results to take action as needed. For more information about automating MBSA, see "How To: Use the Microsoft Baseline Security Analyzer" in the "How To" section of this guide.

Use Security Notification Services

Use the Microsoft services listed in Table 16.5 to obtain security bulletins with notifications of possible system vulnerabilities.

Table 16.5   Security Notification Services

Service Location
TechNet Security Web site

Use this Web page to view the security bulletins that are available for your system.

Microsoft Technical Security Notifications

Use this service to register for regular email bulletins that notify you of the availability of new security notifications.

Additionally, subscribe to the industry security alert services shown in Table 16.6. This allows you to assess the threat of a vulnerability where a patch is not yet available.

Table 16.6   Industry Security Notification Services

Service Location
CERT Advisory Mailing List

Informative advisories are sent when vulnerabilities are reported.

Windows and .NET Magazine Security UPDATE [Content link no longer available, original URL:""]

Announces the latest security breaches and identifies fixes.

NTBugtraq - 020

This is an open discussion of Windows security vulnerabilities and exploits. Vulnerabilities which currently have no patch are discussed.

Remote Administration

Administrators often need to be able to administer multiple servers. Make sure the requirements of your remote administration solution do not compromise security. If you need remote administration capabilities, then the following recommendations help improve security:

  • Restrict the number of administration accounts. This includes restricting the number of administration accounts as well as restricting which accounts are allowed to log on remotely.
  • Restrict the tools. The main options include Internet Services Manager and Terminal Services. Another option is Web administration (using the IISAdmin virtual directory), but this is not recommended and this option is removed by IISLockdown.exe. Both Internet Services Manager and Terminal Services use Windows security. The main considerations here are restricting the Windows accounts and the ports you use.
  • Restrict the computers that are allowed to administer the server. IPSec can be used to restrict which computers can connect to your Web server.

Securing Terminal Services

It is possible to use Microsoft Terminal Services securely, to remotely administer your Web server.

Terminal Services is based on Microsoft's proprietary protocol known as Remote Desktop Protocol (RDP). RDP uses the TCP 3389 port and supports two concurrent users. The following sections describe how to install and configure Terminal Services for secure administration:

  • Install Terminal Services.
  • Configure Terminal Services.

Install Terminal Services

To install Terminal Services:

  1. Install Terminal Services by using Add/Remove Programs from the Control Panel. Use the Add/Remove Windows Components option. You do not need to install the Terminal Services Licensing service for remote administration.
  2. Configure Terminal Services for remote administration mode.
  3. Remove the TsInternetUser account, which is created during Terminal Services installation. This account is used to support anonymous Internet access to Terminal Services, which should not be enabled on the server.

Configure Terminal Services

Use the Terminal Services Configuration MMC snap-in available from the Administrative Tools program group to configure the following:

  1. There are three levels (Low, Medium, and High) of encryption available for connections to Terminal Services. Set the encryption to 128-bit key. Note that the Windows high encryption pack should be installed on both the server and the client.
  2. Configure the Terminal Services session to disconnect after idle connection time limit. Set it to end a disconnected session. A session is considered to be disconnected if the user closes the Terminal Services client application without logging off in a period of ten minutes.
  3. Finally restrict permissions to access Terminal Services. Use the RDP permissions tab in the RDP dialog box. By default, all members of the Administrators group are allowed to access Terminal Services. If you don't want all members of the Administrators group to access Terminal Services, then remove the group and add individual accounts that need access. Note that the SYSTEM account must be in the list.

Use a secure VPN connection between the client and the server or an IPSec tunnel for enhanced security. This approach provides mutual authentication and the RDP payload is encrypted.

Copying Files over RDP

Terminal Services does not provide built-in support for file transfer. However, you can install the File Copy utility from the Windows 2000 Server Resource Kit to add file transfer functionality to the clipboard redirection feature in Terminal Services. For more information about the utility and installation instructions see Microsoft Knowledge Base article 244732, "How To: Install the File Copy Tool Included with the Windows 2000 Resource Kit."

Simplifying and Automating Security

This chapter has shown you how to manually configure security settings for an ASP.NET Web server. The manual process helps you to understand the configuration but can be time consuming Use the following resources to help automate the steps presented in this chapter:

  • For information on how to automate IISLockdown, see Microsoft Knowledge Base article 310725 "How To: Run the IIS Lockdown Wizard Unattended in IIS."
  • You can create and deploy security policies using security templates. For more information, see the following Microsoft Knowledge Base articles:
    • 313434, "How To: Define Security Templates in the Security Templates Snap-in in Windows 2000."
    • 309689, "How To: Apply Predefined Security Templates in Windows 2000."
    • 321679, "How To: Manage Security Templates in Windows 2000 Server."


A secure Web server provides a protected foundation for hosting your Web applications. This chapter has shown you the main threats that have the potential to impact your ASP.NET Web server and has provided the security steps required for risk mitigation. By performing the hardening steps presented in this chapter, you can create a secure platform and host infrastructure to support ASP.NET Web applications and Web services.

The methodology used in this chapter allows you to build a secure Web server from scratch and also allows you to harden the security configuration of an existing Web server. The next step is to ensure that any deployed applications are correctly configured.

Additional Resources

For additional related reading, see the following resources:

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.