URLScan.net

UrlScan is a security tool that restricts the types of HTTP requests that IIS will process. the UrlScan security tool helps prevent harmful requests from reaching the server.

How to configure the URLScan Tool to protect IIS servers


 

The URLScan cnfiguration stored in a single file named URLScan.ini file, which is located in the %WINDIR%\System32\Inetsrv\URLscan\ folder & holds all URLScan settings. To configure URLScan, just edit thet file in a text editor such as Notepad, make the changes, and then save the file & restart IIS services.
Changes made int the configuration file will not take effect untill Internet Information Services (IIS) is restarted. One way you can do this quickly is to run the IISRESET command at a command prompt.

The [Options] section

In the [Options] section, you can configure a number of URLScan options. Each line in this section has the following format:
OptionName=OptionValue
The available options and their default values are as follows:

UseAllowVerbs=1

By default, this option is set to 1. If this option is set to 1, URLScan only permits HTTP requests that use the verbs that are listed in the [AllowVerbs] section. URLScan blocks any requests that do not use these verbs. If this option is set to 0, URLScan ignores the [AllowVerbs] section, and instead blocks only requests that use verbs that are listed in the [DenyVerbs] section.


UseAllowExtensions=0

By default, this option is set to 0. If this option is set to 0, URLScan blocks requests for file name extensions that are listed in the [DenyExtensions] section, but permits requests for any other file name extensions. If this option is set to 1, URLScan only permits requests for files with extensions that are listed in the [AllowExtensions] section, and it blocks requests for any other files.


NormalizeUrlBeforeScan=1

IIS receives requests that are URL encoded. This means that certain characters may be replaced with a percent sign (%) followed by a particular number. For example, %20 corresponds to a space, so a request for http://myserver/My%20Dir/My%20File.htm is the same as a request for http://myserver/My Dir/My File.htm. Normalization is the process of decoding URL-encoded requests. By default, this option is set to 1. If the NormalizeUrlBeforeScan option is set to 1, URLScan analyzes the decoded request. If it is set to 0, URLScan analyzes the undecoded request instead. Setting this option to 0 hinders the ability of URLScan to block certain kinds of attacks.

VerifyNormalization=1

Because the percent sign (%) itself can be URL encoded, an attacker can submit a carefully crafted request to a server that is basically double-encoded. If this occurs, IIS may accept a request that it would otherwise reject as not valid. By default, this option is set to 1. If the VerifyNormalization option is set to 1, URLScan normalizes the URL two times. If the URL after the first normalization is different from the URL after the second normalization, URLScan rejects the request. This prevents attacks that rely on double-encoded requests.


AllowHighBitCharacters=0

By default, this option is set to 0. If this option is set to 0, URLScan rejects any requests that contain non-ASCII characters. This can prevent certain types of attacks, but it may also block out requests for certain legitimate files, such as files with non-English names.


AllowDotInPath=0

By default, this option is set to 0. If this option is set to 0, URLScan rejects any request that contains multiple periods (.). This prevents attempts to disguise requests for dangerous file name extensions by putting a safe file name extension in the path information or query string portion of the URL. For example, if this option is set to 1, URLScan might permit a request for http://servername/BadFile.exe/SafeFile.htm because it thinks that it is a request for an HTML page, when it is actually a request for an executable (.exe) file with the name of an HTML page in the PATH_INFO area. When this option is set 0, URLScan may also deny requests for directories that contain periods.


RemoveServerHeader=0

By default, a Web server returns a header that identifies what Web server software it is running in all responses. This can increase the server vulnerability because an attacker can determine that a server is running IIS and then attack known IIS problems, instead of trying to attack an IIS server by using exploits that are designed for other Web servers. By default, this option is set to 0. If you set the RemoveServerHeader option to 1, you prevent your server from sending the header that identifies it as an IIS server. If you set RemoveServerHeader to 0, this header is still sent.


AlternateServerName=(not specified by default)

If RemoveServerHeader is set to 0, you can specify a string in the AlternateServerName option to specify what will be passed back in the Server header. If RemoveServerHeader is set to 1, this option is ignored.


EnableLogging=1

By default, URLScan keeps a complete log of all blocked requests in %WINDIR%\System32\Inetsrv\URLScan. You can set EnableLogging to 0 if you do not want to keep this log.


PerProcessLogging=0

By default, this option is set to 0. If this option is set to 1, URLScan creates a separate log for each process that hosts URLScan.dll. If it is set to 0, all processes log to the same file.


PerDayLogging=1

By default, this option is set to 1. If this value is set to 1, URLScan creates a new log file each day. Each log file is named Urlscan.MMDDYY.log, where MMDDYY is the date of the log file. If this value is set to 0, all logging is saved in the same file, regardless of the date.

AllowLateScanning=0

By default, this option is set to 0. If this option is set to 0, URLScan runs as a high-priority filter, which means that it executes before any other Internet Server Application Programming Interface (ISAPI) filters that are installed on the server. If this option is set to 1, URLScan runs as a low-priority filter, so that other filters can modify the URL before URLScan performs any analysis. FrontPage Server Extensions (FPSE) requires this option to be set to 1.


RejectResponseUrl=(not specified by default)

This option specifies the virtual path to a file that runs when URLScan blocks a request. This permits you to customize the response that is sent to the client for blocked requests. You must specify RejectResponseUrl as a virtual path to the appropriate file, such as /Path/To/RejectResponseHandler.asp. You can specify a file that URLScan typically blocks, such as an Active Server Pages (ASP) page. You can also use the following server variables from the page:

HTTP_URLSCAN_STATUS_HEADER: This specifies why the request has been blocked.

HTTP_URLSCAN_ORIGINAL_VERB: This specifies the original verb from the blocked request (for example, GET, POST, HEAD, or DEBUG).

HTTP_URLSCAN_ORIGINAL_URL: This specifies the original URL from the blocked request. If you set RejectResponseUrl to the special value of /~*, URLScan uses logging-only mode. This permits IIS to serve all requests, but it adds an entry to the URLScan log for any requests that are typically blocked. This is useful if you want to test your URLScan.ini file.

If you do not specify a value for RejectResponseUrl, URLScan uses the default value of /<Rejected-By-UrlScan>.


UseFastPathReject=0

By default, this option is set to 0. If this option is set to 1, URLScan ignores the RejectResponseUrl setting and immediately returns a 404 error message to the browser. This is faster than processing RejectResponseUrl, but it does not permit as many logging options. If this option is set to 0, URLScan uses the RejectResponseUrl setting to process the request.

The [AllowVerbs] and [DenyVerbs] sections



   The [AllowVerbs] and [DenyVerbs] sections define the HTTP verbs (also known as methods) that URLScan permits. Common HTTP verbs include GET, POST, HEAD, and PUT. Other applications, such as FPSE and Web Distributed Authoring and Versioning (WebDAV), use additional verbs.

Both the [AllowVerbs] and the [DenyVerbs] sections have the same syntax. They are made up of a list of HTTP verbs, and each verb appears on its own line.

URLScan decides which section to use based on the value of the UseAllowVerbs option in the [Options] section. By default, this option is set to 1. If UseAllowVerbs is set to 1, URLScan only permits requests that use the verbs that are listed in the [AllowVerbs] section. A request that does not use one of these verbs is rejected. In this case, the [DenyVerbs] section is ignored.
If UseAllowVerbs is set to 0, URLScan denies requests that use verbs that are explicitly listed in the [DenyVerbs] section. Any requests that use verbs that do not appear in this section are permitted. In this case, URLScan ignores the [AllowVerbs] section.

The [DenyHeaders] section

When a client requests a page from a Web server, it typically sends over some HTTP headers that contain additional information about the request. Common HTTP headers include the following:

Host:

This header contains the name of the Web server.

Accept:

This header defines the file types that the client can handle.

User-Agent:

This header contains the name of the browser that requests the page.

Authorization:

This header defines the authentication methods that the client supports.

Clients may send other headers to the server to specify additional information.

In the [DenyHeaders] section, you define HTTP headers that URLScan will reject. If URLScan receives a request that contains any header that is listed in this section, it rejects the request. This section is made up of a list of HTTP headers, with each header appearing on its own line. Header names must be followed by a colon (:) (for example, Header-Name:).

The [AllowExtensions] and [DenyExtensions] sections

Most files have a file name extension that identifies what kind of file they are. For example, file names for Word documents typically end in .doc, HTML file names typically end in .htm or .html, and plain text file names typically end in .txt. The [AllowExtensions] and [DenyExtensions] sections permit you to define extensions that URLScan will block. For example, you can configure URLScan to reject requests for .exe files to prevent Web users from executing applications on your system.

Both the [AllowExtensions] and the [DenyExtensions] sections have the same syntax. They are made up of a list of file name extensions, and each extension appears on its own line. The extension starts with a period (.) (for example, .ext).

URLScan decides which section to use based on the value of UseAllowExtensions in the [Options] section. By default, this option is set to 0. If UseAllowExtensions is set to 0, URLScan only denies requests for file name extensions that are listed in the [DenyExtensions] section. Any file name extensions that are not listed in this section are permitted. The [AllowExtensions] section is ignored.

If UseAllowExtensions is set to 1, URLScan denies requests for any file name extensions that are not explicitly listed in the [AllowExtensions] section. Only requests for a file name extension that is listed in that section are permitted. The [DenyExtensions] section is ignored.