IIS 6.0 on Windows Server 2003: Security

Welcome to the fourth installment of Internet Information Services 6.0 on Windows Server 2003. This series of articles discusses IIS 6.0 on Windows Server 2003 and is designed to be both a refresher for the IT professional familiar with designing and administrating IIS 4.0 and IIS 5.0, and for newcomers looking to get their feet wet.

The fourth installment of our IIS 6 on Windows Server 2003 series examines the differences in functionality between UrlScan 2.5 with IIS versions 4 and 5 vs. IIS 6’s built-in features.

This installment continues our introduction to Internet Information Services 6.0 on Windows Server 2003 with an overview of the differences between how UrlScan 2.5 (the most recent version of the tool as of this writing) is used with IIS versions 4 and 5 vs. IIS 6.0’s built-in features that provide similar security functionality.

This is not to say that you cannot use UrlScan on IIS 6.0 systems; the overall functionality of the tool is to block specific HTTP requests in an effort to restrict the types of calls that can be made to the IIS server and that can be run on IIS versions 4.0, 5.0, 5.1, and 6.0.

In certain circumstances, UrlScan provides additional functionality beyond what IIS 6.0 provides on its own, and there are situations in which an administrator may wish to configure these additional settings on his IIS 6.0 system to lock down the service.

Those who have administered IIS in the past, whether it was Internet Information Server 4.0 on the NT4 platform or Internet Information Services 5.0 on the Windows 2000 platform, are well aware of the difficulty of securing the service from would-be attackers, as both versions installed with most of the services running by default. IIS 6.0 on Windows Server 2003 is a departure from this, as all of the services are disabled by default.

The following is a list of the different settings that can be enabled via the UrlScan tool and the comparable settings found in IIS 6.0.

• DenyExtensions limits ISAPI or CGI code calls on the Web server. These “deny extensions” setting are established by calling out the file name extensions that are not allowed to run. IIS 6.0 inherently provides this functionality by allowing administrators to set which ISAPI and CGI code can run on the server directly (by applying the DenyExtensions setting) rather than preventing particular code based on file name extensions. Thus, it is not necessary to know the specific file extensions that might be entered in the URL that are trying to use the ISAPI and CGI code
• DenyVerbs under UrlScan 2.5 can be set to by prevent HTTP requests that could be used to invoke WebDAV. The design of IIS 6.0 allows the administrator to explicitly enable or disable WebDAV so that it is not necessary to inspect each HTTP request. Those using WebDAV may find it necessary to set certain DenyVerbs under UrlScan to prevent certain types of requests.
• DenyHeaders are used to prevent certain HTTP header requests that could invoke WebDAV if it is enabled on the IIS server. IIS 6.0 provides the same type of functionality by allowing the administrator to explicitly enable or disable WebDAV so that it is not necessary to inspect the each HTTP request. Those using WebDAV may find it necessary to set certain DenyHeaders under UrlScan to prevent certain types of requests.
• NormalizeUrlBeforeScan is used to specify whether IIS will process the raw URL the client sends or the canonicalized URL processed on the server. While this is necessary for versions of IIS prior to version 6.0, the lockdown mechanism in IIS 6.0 is based on the executable code permitted to run — not the URL that the client requested.
• VerifyNormalization allows UrlScan to detect potential issues with URL canonicalization on legacy IIS systems. This is not needed on IIS 6.0 because the HTTP.SYS component used in IIS 6.0 has enhanced canonicalization code expressly written to help protect against these types of attacks.

The DenyUrlSequences setting in UrlScan can detect sequences used in URL-based attacks on a Web server, and it protects IIS servers versions 4 and 5, against this type of attack by not allowing the character sequences. It is not necessary for IIS to deny URL sequences through these specific settings because IIS 6.0 is not susceptible to URL-based attacks by default. This is just one setting UrlScan uses that is configured through the UrlScan.ini file.

[Options] describes general URLScan options.
[AllowExtensions] and [DenyExtensions] define the file name extensions URLScan permits.
[AllowVerbs] and [DenyVerbs] define the verbs (also known as HTTP methods) that URLScan permits.
[DenyHeaders] lists the HTTP headers not permitted in an HTTP request. If an HTTP request contains one of the HTTP headers listed in this section, URLScan rejects the request.
[DenyURLSequences] lists the strings not permitted in an HTTP request. URLScan rejects HTTP requests that contain a string that appears in this section.
[RequestLimits] enforces limits on the size, in bytes, of separate parts of requests reaching the server.

AllowDotInPath sets UrlScan to reject any request where the file extension is ambiguous due to a dot-in-path condition. The default setting for this is “0,” which will cause URLScan to reject any request that contains multiple periods (.). The AllowDotInPath setting is not used outright in IIS 6.0 because this version of IIS does not lock down the service using filter notifications.

The RemoveServerHeader setting of UrlScan shields the true the identity of the server from client connections when the server header is presented to the connecting client. IIS 6.0 does not include the RemoveServerHeader configuration setting since it offers little additional security, as there are other means by which to detect the individual server name and the installed operating system.

EnableLogging, PerProcessLogging, and PerDayLogging are settings that control how UrlScan records its logging information. Since UrlScan is an add-on component it must control its own logging information independent of the operating system and previous versions of IIS. All of the inherent lockdown settings of IIS 6.0 are logged within the W3SVC logs of the server so these additional settings, which UrlScan supplies, are not needed.

AllowLateScanning permits administrators to configure whether UrlScan inspects URLs before or after other filters in use on the server. The lockdown method built into IIS 6.0 is based on the ISAPI or CGI code running on the server. It is not based on the call that the client requested, so this setting and subsequent filtering is not of any additional use on IIS 6.0.

RejectResponseUrl is used with UseFastPathReject. It sends all rejected calls to the specific URL listed in RejectResponseUrl instead of the normal 404 response. (UseFastPathReject may be configured to ignore these settings.) This is usually used to reject calls into the server that are trying to call on executable code that otherwise is not allowed to run. The additional settings are not needed on IIS 6.0 systems because any requests rejected due to a lockdown of executable code will generate a 404.2 custom error, and any static files rejected due to an unknown MIME type will generate a 404.3 custom error.

The UseFastPathReject setting is normally set to “UseFastPathReject=1” by default so URLScan ignores the RejectResponseUrl setting. This allows the IIS server to return a 500 error message to the requesting system. The default setting allows for fast server response with regard to processing time. If the setting in RejectResponseUrl is used it does not allow for the same amount of different logging options that RejectResponseUrl allows.

These additional configuration settings are not needed on IIS 6.0 systems because any requests rejected due to a lockdown of ISAPI or CGI code will generate a 404.2 custom error, and any static files rejected due to an unknown MIME type will generate a 404.3 custom error. IIS 6.0 provides the lockdown functionality by setting which ISAPI and CGI code can be run on the server directly by applying the DenyExtensions setting rather than preventing particular code based on file name extensions of by using filters.

The AllowHighBitCharacters setting allows UrlScan to detect non-ASCII characters in URLs and allow them to be processed or discarded depending on the setting. On IIS 6.0 systems, the allowed character range of URLs is handled by HTTP.SYS and can be modified in the system registry at:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersEnableNonUTF8

MaxAllowedContentLength settings configure UrlScan to place limits on the size of requests made on the Web server. IIS 6.0 limits the size of requests directly from the settings in the metabase in both MaxRequestEntityAllowed and ASPMaxRequestEntityAllowed.

The MaxUrl, MaxQueryString, and MaxHeader settings configure UrlScan to limit the size of URL requests that clients make, query strings, and specific headers sent to IIS since legacy versions of IIS cannot have these settings configured manually. On IIS 6.0 the HTTP.SYS component of the service is used to set size limits. These values are edited by adjusting the AllowRestrictedChars, MaxFieldLength, UrlSegmentMaxLength, and UrlSegmentMaxCount values in the system registry.

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersAllowRestrictedChars

is used to configure the AllowRestrictedChars settings.

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersMaxFieldLength

is used to configure the MaxFieldLength settings.

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersUrlSegmentMaxLength

is used to configure the UrlSegmentMaxLength settings.

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesHTTPParametersUrlSegmentMaxCount

is used to configure the UrlSegmentMaxCount settings.