HTTP access to your websites can be analyzed and suspicious traffic can be rejected before that traffic hits IIS services. URLScan protects a server from attacks by filtering and rejecting certain packets that you define. When URLScan is first installed, it rejects the following request types:
CGI (.exe) pages
WebDAV
FrontPage server extensions
Index Server
Internet printing
Server-side includes
This tool is configured via the urlscan.ini file, which is installed in the %windir%\system32\
intesrv\urlscan folder. There are several sections to this file, and a typical section is shown in Figure 2.15.
F I G U R E 2 . 1 5 The urlscan.ini file displaying the DenyVerbs section 4332.book Page 67 Wednesday, May 19, 2004 4:01 PM
The Options section of the urlscan.ini file defines how valid and invalid requests are han-dled. The Options section includes the following:
UseAllowVerbs Allowed values for the UseAllowVerbs option are either one (1) or zero (0).
The default is one. When set to one, the tool rejects any request containing an HTTP verb that is not explicitly listed in the AllowVerbs section of the file. This section is case-sensitive. If this option is set to zero, the tool rejects any request that contains verbs in the DenyVerbs section of the file. This section is not case-sensitive.
UseAllowExtensions Allowed values for the UseAllowExtensions option are either one (1) or zero (0). The default is zero. When set to the default, the tool rejects any request in which the file extension associated with the request is listed in the DenyExtensions section of the file.
When set to one, the tool rejects any request in which the file extension associated with the request is not listed in the AllowExtensions section of the file.
NormalizeURLBeforeScan Allowed values for this option are either one (1) or zero (0). The default is one. When set to the default, the tool analyzes all packets after IIS has normalized the URL request. When set to zero, the tool analyzes all requests in their raw form. This option will open your server to canonicalization attacks.
VerifyNormalization Allowed values for the VerifyNormalization option are either one (1) or zero (0). The default is one. When set to the default, this tool verifies the URL normalization and helps defend against canonicalization attacks. The best practice is to leave this at the default value.
AllowHighBitCharacters Allowed values for the AllowHighBitCharacters option are either one (1) or zero (0). The default is zero. When set to the default, this tool rejects any request in which the URL contains a character not found in the ASCII character set.
AllowDotInPath Allowed values for the AllowDotInPath option are either one (1) or zero (0).
The default is zero. When set to the default, the tool rejects any URL that contains multiple dots (.). When set to one, the tool does not check for multiple instances of dots. In default mode, the tool rejects names with dots such as http://mail.domainname.com/exchange.
Canonicalization
Canonical means the simplest or most standard form of something. Canonicalization is the pro-cess of converting something from one representation to its simplest form.
Web applications must deal with lots of canonicalization issues, from URL encoding to IP address translation. For example, a URL canonicalization vulnerability results when a security decision is based on a URL and not all possible URL forms are considered. If a URL is allowed access, it is possible to send a URL that appears as if it is pointing to one resource when, in fact, it is pointing to a different resource. When security decisions are based on canonical forms of data, it is therefore essential that the application is able to deal with canonicalization issues accurately. Only experienced administrators should configure the application.
IIS 5 Server Security 69
RemoveServerHeader Allowed values for the RemoveServerHeader option are either one (1) or zero (0). The default is zero. When set to the default, the tool allows server headers in all server responses. When set to one, the tool removes the server header from all server responses.
EnableLogging Allowed values for the EnableLogging option are either one (1) or zero (0).
The default is one. When set to the default, the tool logs its actions in the urlscan.log file.
When set to zero, no logging is performed.
PerProcessLogging Allowed values for the PerProcessLogging option are either one (1) or zero (0). The default is zero. When set to the default, the tool does not associate the log filename with each process that is being logged. When set to one, the tool appends the process ID of the IIS process hosting URLScan.dll to the log filename.
AlternativeServerName The AlternativeServerName option works in concert with the RemoveServerHeader option. When RemoveServerHeader is set to zero, the string of characters entered here replaces the default header in all server responses.
AllowLateScanning Allowed values for the AllowLateScanning option are either one (1) or zero (0). The default is zero. When set to one, the tool registers itself as a low-priority filter, which means that other tools can scan and modify the incoming URL before URLScan. When set to the default, the tool scans in high-priority mode.
PerDayLogging Allowed values for the PerDayLogging option are either one (1) or zero (0).
The default is one. When set to the default, a new log file is created for each day when the first log entry is written for that day. If there are no entries, no log file is generated.
RejectResponseUrl The input values for the RejectResponseUrl option are a string of charac-ters in the form /path/filename.ext. This is the URL that is run when the tool rejects a request. The URL must be local.
UseFastPathReject Allowed values for the UseFastPathReject option are either one (1) or zero (0). The default is zero. When set to the default, this option is ignored. But when set to one, the tool ignores the settings in the RejectResponseUrl and displays a 404 response to the client when it rejects a request.
The urlscan.ini file also contains sections for the following:
Allowed verbs
Denied verbs
Denied headers
Allowed extensions
Denied extensions
If you install URLScan on each IIS web server, it acts as an endpoint intrusion detection sys-tem (IDS). If you install URLScan on an ISA (Internet Security and Acceleration) server, it can act as a network-based IDS for all IIS servers on your network. At the network perimeter, you can block all types of requests instead of letting those requests traverse your network and then get blocked at the server level.
Although the IIS Lockdown tool works at the service level, URLScan works at the URL level to help secure your website. When you select one of the templates during the installation of IIS
4332.book Page 69 Wednesday, May 19, 2004 4:01 PM
Lockdown, a preconfigured urlscan.ini file is also installed, easing the burden of adminis-tration for you. And if necessary, you can go back and tweak the urlscan.ini file to work exactly the way you need it to work.
IIS 6 Server Security
With the release of Windows Server 2003, IIS 6 is now available. IIS 6 is a distinct improvement over IIS 5 in reliability, performance, and security. As you install IIS Lockdown and URLScan, you will notice that they are designed for use with IIS 5. Microsoft made a dramatic change in the phi-losophy around Windows server development; security now takes priority over ease of use. The Windows Server 2003 team worked hard to make IIS more secure with version 6. In particular, IIS 6 now comes completely locked down when installed. You do not need to lock down IIS 6 with any special utilities. While a version of URLScan is provided for IIS 6, it not needed in most cases.
IIS 6 is completely locked down and will support only static HTML files when first installed. If you want to support ASP files, for example, you need to configure IIS 6 to enable ASP file support.
Open the Internet Information Services (IIS) Manager by choosing Start Administrative Tools Internet Information Services (IIS) Manager. Once you have opened the MMC snap-in, expand the server name and click Web Service Extensions, as shown in Figure 2.16.
Securing an IIS 5 Website Using the Anonymous Account
Let’s say you want to present company files on the Internet for general public consumption, such as product and general information documents. Obviously, you want this site to be secure and yet accessible via the Anonymous account. Follow these steps:
1. Install the IIS Lockdown and URLScan tools.
2. Select the Static Web Site option in IIS Lockdown and accept the defaults in the urlscan.ini file.
3. Use a Group Policy to disable the Anonymous account membership in the Everyone and Network user security groups.
4. Explicitly give permissions to the Anonymous user account to the resources that will be presented in the website.
5. Rename the Anonymous user account with a name that “blends in” with the other names in your Active Directory so that a hacker cannot readily discern which accounts are intended for web access and which are not.
6. Require SSL for client connectivity if you want to ensure that data communications between your visitors and the web server are encrypted. With public documents, this might not be a desired outcome, but it is certainly available if you want to use it.