AllowDotInPath. When you set AllowDotInPath to 0, URLScan rejects URLs that contain more than one period. (Be aware that some Microsoft documentation is contradictory, but this definition is accurate.) Although the [DenyExtensions] section is useful in preventing attacks that involve file extensions, sometimes URLScan can't determine the true extension of a requested file because URLScan runs before IIS parses the URL. By setting AllowDotInPath to 0, you prevent attackers from embedding a period earlier in the path to hide the true extension of the file. Note, however, that this setting also blocks access to any legitimate folders or files that have embedded periods; you might have to rename them.
RemoveServerHeader. Usually, when IIS responds to a client, a Web server identifies in the header the type of Web server software it uses. For example, an IIS server on Win2K would send "Server: Microsoft-IIS/5.0." Identifying the server and IIS version you use might let an attacker tailor an attack to that version. Setting RemoveServerHeader to 1 prevents IIS from identifying itself, but note that this setting breaks FrontPage Server Extensions.
AlternateServerName. You can take server protection a step further and use AlternateServerName to make attackers think your server is a different type of server. For example, setting RemoveServerHeader to 1 and AlternateServerName to GWS/2.0 might make an attacker think you run GWS instead of IIS. (Note that AlternateServerName works only when you set RemoveServerHeader to 1.)
Log Settings
URLScan's logging capability is useful for diagnosing problems and monitoring attacks. Each time IIS starts, URLScan logs a detailed description of its current configuration. Then, each time URLScan rejects a request, it logs the date, time, and raw URL—and records exactly why it rejected the URL. Five settings in the [options] section—EnableLogging, PerProcessLogging, PerDayLogging, LogLongUrls, and LoggingDirectory—control whether and how URLScan performs logging.
EnableLogging. EnableLogging controls whether URLScan logs activity. Because the URLScan log is invaluable, I recommend that you accept the default value of 1 to enable logging.
PerProcessLogging. I recommend leaving PerProcessLogging set to 0, which is the default, to avoid the need to check multiple logs. However, if you run applications at different levels of application protection and therefore in different processes (see http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwarndc.htm for information about IIS's application-protection options), you might want to set PerProcessLogging to 1 to instruct URLScan to create separate log files for each process. URLScan appends the process ID for each process to the corresponding log's filename.
PerDayLogging. I recommend that you set PerDayLogging to 1. URLScan then creates a new log each day, which helps keep your URLScan logs manageable. The format for log filenames is urlscan.mmddyy.log. I also recommend checking your logs at least once a week to note any attacks on your server.
LogLongUrls. When URLScan versions earlier than URLScan 2.5 logged rejected URL requests, the tool limited the line written to the log file to 1024 characters. Usually, that log-file size is long enough to accommodate the entire line, including the URL. However, this new URLScan setting lets you configure URLScan to log very long URLs. If you set LogLongUrls to 1, URLScan logs up to 128KB for each line.
LoggingDirectory. Earlier versions of URLScan created log files in the same folder in which urlscan.dll resided—usually in \%winroot%\system32\inetsrv\urlscan. With URLScan 2.5, you can send URLScan logs to a different folder by setting LoggingDirectory to the appropriate fully qualified path (e.g., C:\urlscanlogs).
Filter Priority Settings
The AllowLateScanning setting controls whether URLScan loads as a high-priority or low-priority filter. Usually, you should set AllowLateScanning to 0 so that URLScan runs as a high-priority filter to catch and reject problem URLs before they reach other ISAPI filters. When you set AllowLateScanning to 1 and run URLScan as a low-priority filter, URLScan examines URLs after any other ISAPI filters have modified them. If you use the low-priority setting, which is required for FrontPage extensions, also make sure that URLScan is low in the list of ISAPI filters when you install it.
Rejecting URLs
Two settings control how URLScan rejects URLs and what information it returns to the user: RejectResponseUrl and UseFastPathReject.
RejectResponseUrl. RejectResponseUrl lets you specify the path (e.g., /errormsgs/badurl.html) to a file on the local server that contains the text for the error page that the server will display when URLScan rejects a request. URLScan creates three server variables that you can reference in your file:
- HTTP_URLSCAN_STATUS_HEADER provides the reason that URLScan rejected the request.
- HTTP_URLSCAN_ORIGINAL_VERB specifies the verb the client sent.
- HTTP_URLSCAN_ORIGINAL_URL specifies the original URL the client requested.
Register
