System Requirements:
- Windows NT 4.0 SP6a
- Windows 2000
- Windows XP
- Internet Information Services 4.0
- Internet Information Services 5.0
- Internet Information Services 5.1
The Problem:
Microsoft released the very useful (and necessary) IIS Lockdown 1.0 in August 2001, and updated it to version 2.1 in the November of the same year, adding support for IIS 5.1 and bundling the URLScan 6.0.3547.0 filter ISAPI extension.
The URLScan component was updated to URLScan 2.5 (6.0.3615.0) in an unceremonious fashion in May 2003 to provide an updated ISAPI and, presumably, some IIS 6 support.
It’s not easy to even find URLScan 2.5 in the Microsoft download centre, but it is there, appearing in the search listings as “Setup.exe”.
If you want to bring a new Windows NT4/5.x Server box up to spec you will invariably use IIS Lockdown, which will install URLScan 6.0.3547.0, restart the IIS Services (or restart in the case of NT4). Bring the system backup, uninstall the IIS Lockdown URLScan, repeat the service restart and finally install URLScan 2.5 and – you guessed it – restart the services a third time.
The Fix:
My theory is “why bother” with that, I just reintegrated the new 2003 version of URLScan into the IIS Lockdown 2.1 installer and voila one install, one service reset, give yourself a pat on the back and go make a cup of tea.
IIS Lockdown 2.1.1 C:Amie Edition : Download : 193KB
If you don’t believe it works, the server you are connecting too right now is using it! (assuming this is still a Windows 2000 Server when you read this).
What is new in URLScan 2.5?
Good question, there isn’t any documentation on the 2.5 release (the readme in my 2.1.1 redist is the original version’s). The default configuration script has been expanded with some new variables.
You can now control how and where URLScan logs too – useful as the original version dumps logs in the Inetsrv\URLscan folder in a rather untidy manner.
If 0, then only 1k is allowed.
LoggingDirectory can be used to specify the directory where the
log file will be created. This value should be the absolute path
(ie. c:\some\path). If not specified, then UrlScan will create
the log in the same directory where the UrlScan.dll file is located.
LoggingDirectory=C:\WINNT\system32\inetsrv\urlscan\logs
A new query string control and maximum file request is also a new feature, allowing you to prevent people from sucking the life out of a persistent HTTP connection.
The entries in this section impose limits on the length of allowed parts of requests reaching the server.
It is possible to impose a limit on the length of the value of a specific request header by prepending “Max-” to the name of the header. For example, the following entry would impose a limit of 100 bytes to the value of the ‘Content-Type’ header: Max-Content-Type=100
To list a header and not specify a maximum value, use 0 (ie. ‘Max-User-Agent=0’). Also, any headers not listed in this section will not be checked for length limits.There are 3 special case limits:
– MaxAllowedContentLength specifies the maximum allowed numeric value of the Content-Length request header. For example, setting this to 1000 would cause any request with a content length that exceeds 1000 to be rejected. The default is 30000000.
– MaxUrl specifies the maximum length of the request URL, not including the query string. The default is 260 (which is equivalent to MAX_PATH).
– MaxQueryString specifies the maximum length of the query string. The default is 4096.