Download & Install – Version 3.1
To download and install UrlScan 3.1, click on the appropriate download link for your environment:
Download the x86 version from Microsoft Download Center.
Download the x64 version from Microsoft Download Center.
This is an MSI installer that you may run easily. When installing UrlScan 3.1 on IIS 7, it does the following:
Installs the UrlScan.dll and UrlScan.ini files in the %windir%system32inetsrvUrlScan directory. If UrlScan is already installed on the computer, the UrlScan.ini file is updated with any new settings that are not present in the current configuration file.
Adds UrlScan as a global filter to IIS.
Creates a %windir%system32inetsrvUrlScanLogs directory.
When installing UrlScan on a server running IIS 6.0, the UrlScan 3.1 installer makes some additional changes that enable UrlScan 3.1 to work with the new IIS 6.0 process model.
The configuration is stored in UrlScan.ini file that should reside in the same directory as UrlScan.dll.
Administrators may configure UrlScan to reject HTTP requests based on the following criteria:
The HTTP request method or verb
The file name extension of the requested resource
Suspicious URL encoding
Presence of non-ASCII characters in the URL
Presence of specified character sequences in the URL
Presence of specified headers in the request
When UrlScan denies a request it will log the action and the reason for the denial, along with additional information about the request typically, the complete URL and IP address of the source of the request. When a denial occurs, IIS sends a “404 Object not found response to the client. This simple response reduces the possibility of inadvertently disclosing information about the server to a possible attacker.
The [Options] section of a UrlScan.ini file contains a list of name/value pairs that define the general behavior for UrlScan. A few of the settings enable or disable other sections in the UrlScan.ini file. Following sections are available for configuration and the reference documentation
on IIS website provides good explanation of all the sections along with the sample settings.
Rule section could be very usefull here because it allow different rule sets to be created based on technology used like PHP, ASP or ASP.Net. Check this link for few examples on how to specify Rule sets to protect from different vulnerabilities.
Depending on the rule set you have defined it may have minor or major impact on IIS performance becasue all requests would be first filtered by the ISAPI filter that is an additional overhead and you must evalute the performance implications. If any of protection features are already available with your H/w based Firewall or IPS then it’s better to use those and not to enable same in URLScan.
You may also use few features available with in IIS like disabling file extension etc. that are available in URLScan. I could not find any comparison but I assume that managing any feature with IIS engine would be equally or better optimized.
The default options built into UrlScan.dll will result in a configuration that will reject all requests to the server, therefore it is necessary to provide a UrlScan.ini file for IIS to serve HTTP requests when you are using UrlScan. A sample UrlScan.ini file is provided that contains the recommended settings to defend against known attacks against IIS servers at the time of writing.
Chunked-transfer encoding is an HTTP/1.1 feature that transmits the message body in a request or response as chunks that are stamped with their size. HTTP 1.1 allows clients to send POST requests by using chunked-transfer encoding. In most cases, IIS will automatically decode these requests before they are processed. If the size of the request exceeds a particular threshold (by default, 48 KB), then the ISAPI or CGI code to which the request is directed needs to be aware of chunked-transfer encoding to process the request correctly. If you have code running on a server that is receiving POST requests and you are not sure whether it supports chunked-transfer encoding, then consider using UrlScan to prohibit requests that include a “Transfer-Encoding” header.
By default the log files are stored in %windir%System32InetsrvUrlScanLogs for both x86 and x64 installations. Your UrlScan.ini file contains the LoggingDirectory key under the [Options] section that would point to an absolute location to your log file directory or a relative path based on the location of your UrlScan.ini file. If you have a custom folder and are not seeing any logs, it is likely that your IIS worker process does not have write access to the logs folder. For IIS 6.0 grant IIS_WPG group write access to this folder and for IIS 7.0 grant the IIS_IUSRS group write access to this folder. If this is a pre existing folder make sure this directory does not have any sensitive information that can be tampered. Also if you are on x64, file system redirection may affect the custom path you are writing your logs to. UrlScan 3.1 and 3.0 have W3C formatted logs; you can use tools like Log Parser to query information in these log files.
Version 2.5 to 3.1: UrlScan v3.1 will overwrite the pre-existing UrlScan v2.5 filter in the inetsrv directory. It will leave your old UrlScan.ini file intact though and no changes will be needed for this .ini file to make it work with UrlScan v3.1
Version v3.0 Beta or RTM to 3.1: The UrlScan v3.1 MSI will upgrade the UrlScan v3.0 Beta or RTM filters in the inetsrv directory. It will leave your .ini configuration and log files intact and the RTW version will work against your previous configuration. Since new sections have been added to the UrlScan v3.1, you can download the new default .ini file from here to see what more it has to offer and add those to your existing configuration.
If the Urlscan.ini does not exist in the %WINDIR%System32InetsrvURLscan folder, the client will receive a 404 error response. To resolve this issue, restore the Urlscan.ini file from a backup or copy the Urlscan.ini file from an identical server.
Click here to see complete details.