Using Tools to Secure IIS

Using Tools to Secure IIS

Two tools are available to secure an IIS server: the IIS Lockdown tool and the URLScan filter. These tools remove known weaknesses in the IIS configuration and provide filters to prevent known attacks against the IIS server.

The IIS Lockdown Tool

By default, Windows 2000 includes the installation of IIS. The IIS Lockdown tool allows you to secure IIS configuration without removing and reinstalling the service. The IIS Lockdown tool can be run by an administrator or can be scripted to allow the unattended application of IIS Lockdown settings to an IIS server. The installation of the tool is broken down into security configuration sections:

• Selecting a server template

• Configuring Internet services

• Enabling script maps

• Applying additional security

Selecting a Server Template

The Select Server Template page provides a list of predefined IIS configuration templates. Each template contains IIS settings designed for the software in the IIS Server template name. By selecting a server template from the list, the IIS Lockdown tool will apply the necessary settings to secure IIS in that environment.

When you select a server template, you can view the specific settings by enabling the View Template Settings check box. This option allows you to review the configured settings and apply any modifications necessary for your IIS environment.

Creating a Custom Server Template

You can create custom server templates in the IISlockd.ini file for use with the IIS Lockdown tool. All custom server templates appear in the IIS Lockdown tool as available templates. You can create a custom server template by editing the IISlockd.ini file to include your custom settings.

The first step is to include pointers to your custom server template section. You must declare your custom template in either the ServerTypesNT4, the ServerTypes, or UnattendedServerType lines in the [Info] section, as shown next. In this case, CustomTemplate is available for both manual and unattended installations.

[Info] ServerTypesNT4=sbs4.5,exchange5.5,frontpage,proxy,staticweb,dynamicweb, other,iis_uninstalled ServerTypes=CustomTemplate,sbs2000,exchange5.5,exchange2k, sharepoint_portal,frontpage,biztalk,commerce,proxy,staticweb, dynamicweb,other,iis_uninstalled UnattendedServerType=CustomTemplate Unattended=TRUE Undo=FALSE

Once you define the pointers, you must create a section based on the referral in the [Info] section that details the settings for the custom server template. The following example ensures that

• Only the Web service is installed. All other services are disabled, rather than uninstalled.

• Only ASPs are enabled.

• Anonymous rights for running system utilities and viewing content are enabled.

• IIS Samples, IIS scripts, the Microsoft Advanced Data Connector (MSADC) virtual directory, the IIS Administration virtual directory, and the IIS Help virtual directory are removed from the IIS server.

• URLScan is enabled and the URLScan.ini file is stored in the %windir%\system32\Inetsrv\URLscan folder.

These settings are all defined in the [CustomTemplate] section, which enforces the previous settings and is shown next. The section name is based on the tag assigned to the section in the [Info] section shown earlier.

[CustomTemplate] label="A Custom Server Template" Enable_iis_http=TRUE Enable_iis_ftp= FALSE Enable_iis_smtp= FALSE Enable_iis_nntp= FALSE Enable_asp= TRUE Enable_index_server_web_interface= FALSE Enable_server_side_includes= FALSE Enable_internet_data_connector= FALSE Enable_internet_printing= FALSE Enable_HTR_scripting= FALSE Enable_webDAV= FALSE Disable_Anonymous_user_system_utility_execute_rights= TRUE Disable_Anonymous_user_content_directory_write_rights= TRUE Remove_iissamples_virtual_directory=TRUE Remove_scripts_directory=TRUE Remove_MSADC_virtual_directory=TRUE Remove_iisadmin_virtual_directory=TRUE Remove_iishelp_virtual_directory=TRUE UrlScan_Install=ENABLED UrlScan_IniFileLocation=%Windir%\System32\Inetsrv\Urlscan AdvancedSetup = UninstallServices=FALSE

Configuring Internet Services

If you enable the View Template Settings check box or choose to configure the other server template, you can configure which Internet services are available at the IIS server. You can select whether each service is enabled or disabled, as shown in Figure 21-5.

Figure 21-5. Defining the startup state for IIS

An enabled service is indicated by a selected check box. A disabled service is indicated by an unselected check box. If a service is grayed out, it is not installed on the IIS server.

You can also remove unselected services by enabling the Remove Unselected Services check box. This option removes any unselected services, rather than leaving the services disabled.

We recommend you leave services disabled. Many applications depend on dynamic-link libraries (DLLs) enabled by IIS. If a service is disabled, the DLLs remain available for other applications. If the service is removed, some applications will reinstall and enable IIS to gain access to the required DLLs.

Enabling Script Maps

IIS can limit what scripts can be executed on an IIS server by defining script maps. Script maps associate script files, such as ASP pages, with a specific scripting engine for processing. Script maps are implemented by using Internet Server Application Programming Interface (ISAPI).

In the Script Maps page, you can enable and disable predefined script maps. If a script map is disabled, the default script map is replaced with a script that causes the server to respond with a HTTP 404 File not found error. The following script maps can be enabled or disabled:

• Active Server Pages (.asp)

  This technology enables the creation of dynamic Web pages. When a user connects to an ASP page, the server executes the ASP script at the server and generates an HTML page. The resultant HTML page is returned to the user who connected to the ASP page.

• Index Server Web Interface (.idq)

  These scripts allow an administrator to remotely manage Index Server services from the Web. The scripts also allow a user to create custom Web-based queries against an Index Server. If you do not require these features, you can disable this script map.

  Disabling the .idq script mapping does not prevent your Web site from allowing standard Web-based searches that utilize Index Server.

• Server-Side Includes (.shtml, .shtm, .stm)

  These scripts enable a Web server to add text, graphics, or application information to a Web page before it is sent to a user.

• Internet Data Connector (.idc)

  These scripts allow queries to be sent to backend databases and then display the results in an HTML-formatted page.

• HTR Scripting (.htr)

  These scripts are similar to ASP scripts. HTR scripts are commonly used for allowing logon passwords to be changed via a Web server. For example, Microsoft Outlook Web Access (OWA) uses HTR scripts to enable users to change their passwords from the OWA Web site.

• Internet Printing (.printer)

  These scripts allow you to send and manage print jobs sent from the Internet to your network s TCP/IP-based printers.

You must determine whether each script map is required for your IIS environment. Some script maps (such as server-side includes and .idc scripts) can be updated to use ASP pages.

Applying Additional Security

The Additional Security page allows you to implement extra measures for your IIS server, as shown in Figure 21-6.

Figure 21-6. Defining additional security settings in the IIS Lockdown tool

The extra measures that you can take include the following:

• Remove Selected Virtual Directories.

  IIS automatically installs with several virtual directories that provide access to IIS Samples, MSADC, IIS Help files, sample scripts, and the Web-based IIS Administration pages. You can choose to remove each of these from the IIS server.

• Define Permissions For Anonymous Users.

  You can configure IIS to prevent anonymous Web users from executing system utilities such as the command prompt or Trivial File Transfer Protocol (TFTP). Also, you can prevent anonymous users from uploading data to content directories.

• Disable Web-Based Distributed Authoring And Versioning (WebDAV).

  This option allows you to prevent the creation of Web folders on the IIS server. Web folders allow a share to be published as a virtual directory with directory browsing enabled. In addition, a drive letter can be mapped to the WebDAV folder. This option must not be enabled at a Microsoft Exchange 2000 server because WebDAV is used for the mail store drive.

URLScan

URLScan is an ISAPI filter that screens and analyzes HTTP requests as Microsoft IIS receives them. The URLScan filter will apply settings based on the IIS Server template selected in the IIS Lockdown tool.

The URLScan Filter

As mentioned in the description of the IIS Lockdown tool, URLScan is an ISAPI filter that screens and analyzes inbound HTTP requests as IIS receives them. The URLScan filter will apply settings based on the IIS Server template selected in the IIS Lockdown tool. This ISAPI filter can be installed on IIS. If you install the Internet Security and Acceleration (ISA) Server Feature Pack, the ISAPI filter can be installed on an ISA server that protects multiple IIS servers.

URLScan analyzes all incoming HTTP requests against a URLScan filter configuration file to determine whether the request should be allowed. If the request is allowed, the Web server responds with the requested resource. If the request is denied, the Web server sends an Object not found response to the client, rather than sending details about why the request is denied.

Installing URLScan

URLScan can be automatically installed when you run the IIS Lockdown tool or manually installed by modifying the properties of the IIS server. When you install the IIS Lockdown tool, you have the option to install URLScan. In this case, the URLScan filter is configured to match the server environment selected in the IIS Lockdown tool. After you complete installation, you can manually modify the configuration of the URLScan.ini file to customize Web server security.

Configuring URLScan

The URLScan ISAPI filter screens incoming HTTP requests and blocks requests based on the configuration of the URLScan.ini file. By default, this file is stored in the %systemroot%\system32\Inetsrv\URLScan folder and must reside in the same folder as URLScan.dll if you modify the default storage location.

You must restart the WWW Publishing service to enable any configuration changes in the URLScan.ini file.

The URLScan.ini file consists of seven sections:

• Options

  Allows the definition of default security options for the URLScan ISAPI filter.

• AllowVerbs

  Defines which HTTP verbs or methods are allowed in HTTP requests.

• DenyVerbs

  Defines which HTTP verbs or methods are explicitly not allowed in HTTP requests.

• DenyHeaders

  Defines which HTTP request headers are explicitly not allowed in HTTP requests.

• AllowExtensions

  Defines a list of file extensions that are allowed in HTTP URL requests.

• DenyExtensions

  Defines a list of file extensions that are explicitly not allowed in HTTP URL requests.

• RequestLimits

  Defines and enforces limits on the size for each part of an HTTP request that reaches the Web server. All sizes are defined in bytes. The RequestLimits section is recognized only when running URLScan version 2.5 or later.

Options Section

The Options section defines the main options for the URLScan filter. It also designates which additional sections are used while processing incoming HTTP requests. You can define the following options:

• UseAllowVerbs

  If set to a value of 1, URLScan reads the AllowVerbs section of URLScan.ini and rejects any request that does not contain an HTTP verb included in the AllowVerbs section. If set to 0, URLScan reads the DenyVerbs section of URLScan.ini and rejects any request that contains a listed HTTP verb. The default value is 1.

• UseAllowExtensions

  If set to a value of 1, URLScan allows only HTTP requests for files whose extensions are included in the AllowExtensions section of URLScan.ini. If set to 0, URLScan reads the DenyExtensions section of URLScan.ini and rejects any HTTP requests for files with an extension included in the DenyExtensions list. The default value is 0.

• NormalizeURLBeforeScan

  If set to a value of 1, URLScan analyzes the requested URL after IIS decodes and normalizes the URL. If set to 0, URLScan analyzes the raw URL sent by the Web client. The default value is 1.

  We do not recommend setting the NormalizeURLBeforeScan option to a value of 0. This is because doing so exposes the IIS server to canonicalization attacks that bypass proper analysis of the URL extensions and gain permissions to certain types of files hosted on a Web server that are file types implemented through ISAPI extensions.

• VerifyNormalization

  If set to a value of 1, URLScan verifies normalization of the URL. This action will defend against canonicalization attacks that attempt to conceal the true URL requested. For example, the string %252e is an example of a double-encoded string for the . character. The %25 decodes to a % character, and the resulting %2e decodes to the . character. If set to 0, this test is not performed by URLScan. The default value is 1.

• AllowHighBitCharacters

  If set to a value of 1, URLScan allows any characters outside the ASCII character set to exist in the URL. If set to 0, URLScan rejects any request in which the URL contains a character outside the ASCII character set. Although this feature can protect against Unicode attacks, it can lead to the rejection of valid URLs if you implement URLs with Unicode characters. The default value is 0.

• AllowDotInPath

  If set to a value of 0, URLScan rejects any requests containing multiple instances of the dot ( . ) character in a URL. If set to 1, URLScan does not perform this test. URLScan assumes that an extension is the part of the URL beginning after the last dot in the string and ending at the first question mark, the first slash character after the dot, or the end of the string. The default value is 0.

• RemoveServerHeader

  If set to a value of 1, URLScan removes the server header on all responses. If set to 0, URLScan does not perform this action. The default value is 0.

  This option prevents only one method of determining that the Web server is an IIS server. Many other ways of determining whether the Web server is running IIS exist.

• EnableLogging

  If set to a value of 1, URLScan logs its actions into the URLScan.log file that is in the same directory as the URLScan.dll file. If set to 0, logging is disabled. The default value is 1.

• LoggingDirectory

  Allows you to specify a custom folder in which to store the URLScan log file. The folder must be a local folder, such as C:\Logfiles. If this option is not specified, URLScan creates the log file in the same folder as the URLScan.dll file. This option is available only in URLScan version 2.5 and later.

• LogLongURLs

  If set to a value of 1, URLScan will log up to 128 KB per request. If set to 0, URLScan will log the first 1024 bytes of the request. The default value is 0. This option is available only in URLScan version 2.5 and later.

• PerProcessLogging

  If set to a value of 1, URLScan appends the process ID of the IIS process hosting URLScan.dll to the log file s name. If set to 0, all processes are logged into the same log file, which is named URLScan.log. The default value is 0.

• AlternateServerName

  Allows you to create a different string that is presented in the server header. This setting is ignored if the RemoveServerHeader option is set to a value of 1. By default, the AlternateServerName is a null value.

• AllowLateScanning

  If set to a value of 1, URLScan registers as a low-priority filter. This allows other ISAPI filters to modify the URL before it is analyzed by URLScan. If set to 0, URLScan registers as a high-priority filter. The default value is 0.

  If you implement both Microsoft FrontPage Server Extensions and URLScan, you must set the AllowLateScanning option to a value of 1. In addition, URLScan must be placed after FrontPage Server Extensions on the filter load list.

• PerDayLogging

  If set to a value of 1, URLScan creates a new log file each day and adds a date to the log file name. If a day passes with no URLScan activity, no log is created for that day. If set to 0, URLScan opens a single file called URLScan.log. The default value is 1.

• RejectResponseURL

  Allows you to define a response URL string that is returned to a Web client when URLScan rejects an HTTP request. In the RejectResponseURL string, you can use the following variables to tailor a response:

  • HTTP_URLSCAN_STATUS_HEADER

    Provides the reason why the HTTP request is rejected

  • HTTP_URLSCAN_ORIGINAL_VERB

    Provides the verb given in the original HTTP request

  • HTTP_URLSCAN_ORIGINAL_URL

    Provides the rejected URL requested in the original HTTP request

  You can place URLScan into a logging-only mode by setting RejectResponseURL to a value of /~*. With this setting, URLScan performs all configured scanning and logs the results but still allows IIS to serve the rejected page. This mode allows you to test URLScan.ini settings without actually rejecting any requests.

• UseFastPathReject

  If set to a value of 1, URLScan ignores the RejectResponseURL and returns a short HTTP 404 File not found response to the client when an HTTP request is rejected. If set to 0, the RejectResponseURL option is used to create the rejection response. The default value is 0.

AllowVerbs Section

The AllowVerbs section contains a list of HTTP verbs that are allowed in HTTP requests. If the UseAllowVerbs option is set to 1, URLScan rejects any HTTP requests containing a verb not explicitly listed. The entries in this section are case sensitive.

DenyVerbs Section

The DenyVerbs section contains a list of HTTP verbs that are explicitly not allowed in HTTP requests. If the UseAllowVerbs option is set to 0, URLScan rejects any HTTP requests that contain a listed verb. The entries in this section are case insensitive.

DenyHeaders Section

The DenyHeaders section contains a list of request headers. Any HTTP requests that contain a request header listed in this section are rejected. The entries in this section are case insensitive.

AllowExtensions Section

The AllowExtensions section contains a list of allowed file extensions. If the UseAllowExtensions option is set to a value of 1, any request containing a URL with an extension not listed is rejected. You can specify URLs that do not have an extension by adding an extension represented by a dot and no trailing characters.

DenyExtensions Section

The DenyExtensions section contains a list of disallowed file extensions. If the UseAllowExtensions option is set to 0, any request containing a URL with an extension in the listing is rejected. The entries in this section are case insensitive.

RequestLimits Section

This section allows you to enforce limits on the size of an HTTP request. The size definitions can be defined for each section of an HTTP request. The size restrictions are defined in the following three entries:

• MaxAllowedContentLength

  Enforces a maximum value for the content length. MaxAllowedContentLength does not actually prevent the server from accepting more data than the amount that this value is set to if the action is performed by using a chunk transfer, in which the data is broken into separate chunks, transferred, and then reassembled. The default value is roughly 2 GB.

• MaxURL

  Restricts the length of the requested URL, not the length of the query string. The value of this registry will vary depending on how you install URLScan. If you manually extract URLScan.dll, the default setting is 260 bytes. If you install URLScan by installing the IIS Lockdown tool, the default setting is 16 KB.

• MaxQueryString

  Restricts the length of the query string. The value is defined in bytes, with a default value of 4 KB.

In addition to these settings, you can create custom limitations by request header type by creating an entry based on the header name and adding the prefix Max- . For example, to limit the length of the Content-Type header to 200 bytes, you can add the entry Max-Content-Type=200 in the RequestLimits section.

URLScan Logging

If URLScan denies a Web request, it will log the action into the %systemroot%\ system32\inetsrv\urlscan\URLScan.log file. The log file will include the reason for the denial and additional information about the request:

• The complete URL requested

  Details whether a false URL was requested or whether an attacker attempted to gain access to a nonpublished folder by using a directory traversal attack.

• IP address of the source of the request

  Helps determine the origin of the attack. Remember that the IP address can also be the IP address of a network address translation (NAT) device, a proxy server address, or a spoofed IP address.

  If the IP address is a spoofed IP address, you will not be able to determine the true IP address that initiated the request. The IP address recorded in the URLScan log file is the spoofed IP address, not the true IP address of the remote client.