Urlscan

URLScan is a template-driven ISAPI filter that intercepts requests to Microsoft's IIS Web server, and rejects them if they meet certain user -defined criteria. The URLScan filter allows the administrator to configure IIS to reject requests based on the following criteria:

• The request method (or verb, such as GET, POST, HEAD, and so on)

• The file extension of the resource requested (such as .htr, .printer, and so on)

• Suspicious URL encoding, such as exemplified by the IIS Directory Traversal vulnerabilities

• Presence of non-ASCII characters in the URL

• Presence of specified character sequences in the URL

• Presence of specified headers in the request

Requests denied by URLScan can be logged, and log entries typically include the reason for the denial, the complete URL requested, and source IP address of the requesting client. In response to denied requests, clients receive an HTTP 404 "Object not found" response by default. This reduces the possibility of inadvertently disclosing any information about the nature of the server to a possible attacker. Also, URLScan provides the administrator with the option of deleting or altering the "Server:" header in the response, which can be used to obscure the vendor and version of the web server from simple HTTP requests.

Note 

With IIS6.0, Microsoft incorporated most of the protective capabilities of URLScan into the web server itself. If you run IIS6 or later (and you should be), deploying URLScan is not necessary in most cases. Unless noted otherwise , the remainder of this appendix refers to running URLScan on IIS 5.x or earlier.

If you run IIS 5.x or earlier , and you want to take advantage of the greatly increased security that URLScan can offer your site, here are the broad steps you must take to deploy it:

1. Make sure that Windows family products are updated before installing URLScan.

2. Download and run the latest URLScan installer.

3. Edit the UrlScan.ini configuration file according to your needs, if necessary.

4. Restart IIS.

The last three steps can be performed automatically using the IIS Lockdown tool. We will discuss each of these steps in detail in this appendix. We have divided our discussion into basic and advanced levels. For those who want fire and forget security without bothering to understand much about what URLScan is doing, read the next section, "Basic URLScan Deployment." If you are hands-on and want the technical details of how to manually deploy URLScan and tune it to suit your needs, skip ahead to the section "Advanced URLScan Configuration."

Caution 

URLScan will not install or maintain the latest security updates on your systemyou need to do this separately!

Basic Urlscan Deployment (IIS5.X And Earlier)

The best way to deploy URLScan is to simply download the latest installer from the link listed at the end of this chapter and run it. Once deployed, it's simply a matter of configuring the UrlScan.ini file and restarting IIS for the changes to take effect. Before we jump to advanced URLScan configuration, however, let's quickly discuss another popular mechanism for installing URLScan: the IIS Lockdown tool.

IIS Lockdown (IIS5.x and Earlier)

The IIS Lockdown tool is available from the link listed at the end of this chapter. The tool has not been updated in some time, but it remains an easy, " one-stop shop" for securely configuring IIS5.x and earlier. IIS Lockdown also contains URLScan (albeit an outdated version which will need to be updated immediately after installation).

Running IIS Lockdown invokes a wizard with several prompts. The first several options deal with configuration of local Internet services and don't pertain to URLScan. However, we'll walk you through these because they are IIS5.x and earlier best practices, and because you'll need to understand them in order to get to the point where URLScan can be installed.

Note 

If you are not sure whether IIS Lockdown settings are appropriate for you, don't worryyou can rerun the wizard and it will give you the option to undo all changes (except services that are removed!). This will also disable (but not uninstall) URLScan.

The first prompt in the IIS Lockdown wizard is to select a server template. Templates are simply a way to allow you to tailor the security settings of the system to its role. Figure C-1 shows the various roles that are available.

Figure C-1: The first screen of the IIS Lockdown wizard prompts the user to select a server template.

The most secure template on this screen is "Static Web server," but it configures the server quite restrictively (for example, ASP scripts cannot be served by a server configured with this template). If your server is only going to serve static HTML files, this is the way to go. Otherwise, you'll need to select the template from the list that best matches your server's role. Since most of the templates are designed around Microsoft products, this should be fairly straightforwardjust pick the product that you are using. However, be aware that these other options do not disable additional features that are shut off by the Static Web Server template, and these may result in security exposures. This is the classic trade-off of security versus functionality.

We recommend you select the "View template settings" option on this screen, as shown in Figure C-1. This will present you with a list of services that will be enabled or disabled in the next screen in the IIS Lockdown wizard, which is shown in Figure C-2.

Figure C-2: The IIS Lockdown wizard indicates which Internet services will be enabled or disabledremember, if you select "Remove unselected services" here, you won't be able to roll back uninstalled services with IIS Lockdown!

This shows the services that IIS Lockdown will enable and disable, according to the template that you selected in the previous screen. It's probably safe to accept these configurations by simply clicking Next, but we wanted to highlight the option to "Remove unselected services" on this screen. We think it's a good idea to select this option to ensure that these services can never be enabled without reinstallation, but be aware that any service uninstalled via this screen cannot be rolled back using the IIS Lockdown tool. Every other setting configured by IIS Lockdown can be rolled back, just not uninstalled servicesyou'll have to manually reinstall them using the appropriate Windows installation media.

The next step in the IIS Lockdown wizard specifies what script maps should be disabled. We discussed the importance of script mappings in Chapter 3basically, they provide a link between a given file extension and a set of code on the server so that when clients request a file with that extension, they can run the linked code. These code modules have traditionally been the source of many security vulnerabilities, so disabling script maps prevents attackers from simply requesting a file with a certain extension in order to exploit a vulnerability. We advise following the recommended script mappings shown on this screen, as they are based on the server template selected in the first step. You may optionally disable even more script mappings here if you know what you're doing. Figure C-3 shows the script mappings screen from the IIS Lockdown wizard with all mappings disabled, which is the default with the Static Web Server template.

Figure C-3: The script mappings screen from the IIS Lockdown wizard

IIS Lockdown then prompts for removal of sample directories, file permissions on system utilities and content directories, and to disable WebDAV. We recommend selecting all options on this screen, but be aware that WebDAV is necessary for some Microsoft products such as Outlook Web Access. If you selected the appropriate template in step one, you should just accept the defaults here.

Finally, the last screen in the IIS Lockdown wizard prompts to install URLScan. No options are provided here, as shown in Figure C-4. Simply make sure the radio button is selected and click Next.

Figure C-4: The last step in the IIS Lockdown wizardinstalling URLScan

IIS Lockdown then presents a list of all of the options that have been selected and asks once more if you want to complete the wizard. If you select Next, the wizard will implement all of the configurations you've selected, including the installation of URLScan. By default, URLScan is installed into the directory %windir%\system32\ inetsrv\urlscan, but you should rarely ever have to go in here after you have it configured the first time.

At this point, your server is configured according to the settings you specified using IIS Lockdown, and URLScan is installed and enabled using those same settings (there is some degree of redundancy here, which makes for good security "defense- in-depth "). You could leave well enough alone at this point, but we think you should take two additional steps to ensure that your server is protected as well as it should be. First, you should specify an alternate web server name in the URLScan configuration file, and then you should update URLScan to the most recent version . We'll describe those steps next.

To specify an alternate web server name, open the file %windir%\system32\ inetsrv\urlscan\urlscan.ini in a text editor like Notepad, and look for the line that reads

 AlternateServerName= 

After the equals sign on this line, enter whatever fake server name you desire . Here's something that will confuse the average attacker or Internet worm:

 AlternateServerName=Webserver 1.0 

This changes the banner presented by your web server to "Webserver 1.0," which prevents attackers from easily discovering what type of web server you are running using the banner- grabbing techniques outlined in Chapter 2. Once you make this change, you'll need to restart the IIS service. You can do this manually, or you can simply go on to the next step, updating URLScan, which restarts IIS for you. If you leave this setting at its default (i.e., not defined), and the RemoveServerHeader setting equals 1 in the [Options] section of UrlScan.ini, IIS will return its true banner for each request.

Note 

To restart IIS on Windows 2000 and later, open a command prompt and type iisreset . On Windows NT, restart the World Wide Web service by typing net stop w3svc and then net start w3svc .

To update URLScan to the most recent version (2.5 as of this writing), download and run the most recent URLScan installer. This updates the URLScan code to the most recent version, makes necessary modifications to the URLScan configuration file to support new features (custom configurations are spared), and resets the IIS service. When it finishes, you should see the following screen:

With IIS Lockdown and URLScan in operation, the behavior of your web server is now drastically altered , depending on what template or other options you selected during the IIS Lockdown wizard. You may be quite disconcerted to see "Object disabled" in your browser when you attempt to connect to your newly secured serverremember, if you selected the Static Web Server template or manually disabled the ASP script mapping, the server will no longer serve ASP scripts, which are the only default content provided with IIS.

What are your next steps? If you need to roll back IIS Lockdown for some reason, read the next section. If you need to tune your URLScan configuration more specifically , move on to the section "Advanced URLScan Configuration" later in this chapter. Otherwise, congratulationsyour server is now protected by URLScan 2.5!

Rolling Back IIS Lockdown   OK, something went wrong, and now your web server is completely broken after you ran IIS Lockdown on it. How can you reverse the effects of IIS Lockdown?

Simplererun iislockd.exe! The first time it is run, IIS Lockdown keeps a log of all the configurations it makes in the file %windir%\system32\inetsrv\oblt-log.log. As long as this file is not removed or altered, when you rerun iislockd.exe, it will present the screen shown in Figure C-5.

Figure C-5: Using IIS Lockdown in rollback mode

If you select Next in this window, you are prompted once more if you want to remove the settings specified when you first ran IIS Lockdown:

Selecting Yes at this screen will reverse all of the configuration changes made by IIS Lockdown and will disable URLScan (but will not delete it, so you can manually enable it later if you wish). Remember that if you elected to remove services during IIS Lockdown previously, you will not be able to restore them using this methodyou must manually reinstall them using the appropriate Microsoft installation media.

Unattended IIS Lockdown Installation   For those who wish to automate the deployment of the IIS Lockdown wizard and URLScan across multiple servers, IIS Lockdown can be configured to run in an unattended fashion according to predefined settings specified in a file called Iislockd.ini. In Iislockd.ini, the [ Info ] section contains basic configuration information used by the IIS Lockdown wizard. The short file called RunLockdUnattended.doc that comes with the IIS Lockdown installation explains the basics of creating Iislockd.ini files, and there is a sample Iislockd.ini file available in the distribution (don't delete or overwrite this original, as it contains the syntax for configuring all available options!). The key parameter is to set Unattended=TRUE in the file, and then run the IIS Lockdown tool in the same directory as the desired Iislockd.ini file using the command line or calling it from a script. We've actually had erratic results using this feature ("No memory" error messages), so your mileage may vary. It's probably a better idea to incorporate URLScan into the standard template for web servers throughout your organization, which means it will be deployed automatically with any new web server in the configuration you defined.

Caution 

The IIS Lockdown installer is named iislockd.exe, the same as the tool itselfdon't get them mixed up!

Advanced Urlscan Configuration

This section will present a brief overview of the settings that can be configured within UrlScan.ini. It is adapted from the URLScan documentation provided by Microsoft, and we strongly recommend reading the original documentation in addition to this section, as the documentation has more complete information. Our intention here is to provide a quick reference for readers who want a short, plainly-worded explanation of each of the sections in UrlScan.ini, along with our recommendations for how each should be set. This section is organized around the basic sections of the UrlScan.ini file.

Caution 

We don't recommend manually installing UrlScan.dll and/or UrlScan.ini because you risk losing any new configuration features and default settings that are typically appended automatically by the latest installer.

Options Section

Each setting is prefaced by the allowed options, 0,1 or string.

• UseAllowVerbs (0,1)  If set to 1, URLScan rejects any request containing an HTTP verb not explicitly listed in the AllowVerbs section (case-sensitive). If set to 0, URLScan rejects any request containing an HTTP verb listed in the DenyVerbs section (not case-sensitive). The highest security is obtained by setting this to 1, and then having a short list of verbs in the AllowVerbs section, such as GET.

• UseAllowExtensions (0,1)  If set to 1, URLScan rejects any request that contains a file extension not explicitly listed in the AllowExtensions section. If set to 0, URLScan rejects any request that contains a file extension listed in the DenyExtensions section. Both the AllowExtensions and DenyExtensions sections are case-insensitive. If you have tight reign over the content on your web site, set this to 1 and list the appropriate extensions in AllowExtensions. More typically, for sites with diverse content, set this to 0 and populate DenyExtensions as we recommend later in "DenyExtensions Section." The extensions that are typically needed by a web server are ".asp", ".aspx", ".cer", ".cdx", ".asa", ".html", ".js", ".htm", ".jpg", ".jpeg", and ".gif", and should typically be the only ones that are part of the list of AllowExtensions section.

• NormalizeUrlBeforeScan (0,1)  When set to 1, IIS is allowed to normalize the request before URLScan filters it. Normalization involves decoding URLs from hexadecimal or other encodings, canonicalization of filenames, and so on. If set to 0, URLScan filters the raw URLs as sent by the client. We recommend setting this to 1 to avoid canonicalization attacks like the IIS Unicode and double decode directory traversal exploits.

• VerifyNormalization (0,1)  Setting this to 1 verifies normalization to ensure that requests are not encoded multiple times in an attempt to bypass standard normalization routines. We recommend setting this to 1.

• AllowHighBitCharacters (0,1)  If set to 0, URLScan rejects any request where the URL contains a character outside of the ASCII character set. This feature can defend against UNICODE- or UTF-8based attacks but will also reject legitimate requests on IIS servers that use a non-ASCII code page. We say 0 for this one.

• AllowDotInPath (0,1)  When set to 0, URLScan rejects any requests containing multiple instances of the dot (.) character within the entire URL. This defends against the case where an attacker uses path info to hide the true extension of the request (for example, something like "/ path /TrueURL.asp/BogusPart.htm"). Be aware that if you have dots in your directory names , requests containing those directories will be rejected with this setting. We recommend setting this to 0.

• RemoveServerHeader (0,1)  When set to 1, URLScan removes the server header on all responses. This prevents attackers from determining what HTTP server software is running. We prefer to set this to 0 and specify a fake server header using the AlternateServerName setting discussed next.

• AlternateServerName (string)  If this setting is present and if RemoveServerHeader is set to 0, IIS replaces its default "Server:" header in all responses with this string. If RemoveServerHeader is set to 1, no Server header is sent to clients, and AlternateServerName has no meaning. We recommend setting RemoveServerHeader=0 and specifying an obscure value here; for example, AlternateServerName=Webserver 1.0.

• DenyUrlSequences (string)  This lists common URL attack signatures that are simply rejected if matched. The default options here are "..", "./", "\", ":", "%" and "&". Additional values recommended to append to this list are "#", "<", ">", "$", "@", "!", "," and "~". Note that IIS6 automatically rejects character sequences listed in the default DenyUrlSequences section of the UrlScan.ini file provided by Microsoft.

• EnableLogging (0,1)  If set to 1, URLScan logs its actions into a file called UrlScan.log, which will be created in the same directory that contains UrlScan.dll. If set to 0, no logging will be done. Note that the LoggingDirectory setting can be used to specify a custom location to write URLScan logs, but it is only available if you're using UrlScan.dll version 2.5 or later. We recommend setting this to 1 only if you are actively trying to troubleshoot URLScan, or you have serious curiosity about what sort of attacks your web server may be subject to. The IIS logs should be keeping a good record of web server activity, and unless you've got extra free time to examine all of the malicious requests URLScan rejects on a busy server, it's probably not worth it to even log them.

• PerProcessLogging (0,1)  When set to 1, URLScan appends the process ID of the IIS process hosting UrlScan.dll to the log filename (for example, UrlScan.1664.log). To our knowledge, this feature is only useful on IIS 6 and above, which can host filters in more than one process concurrently. Unless you're running IIS6, set it to 0.

• PerDayLogging (0,1)  If set to 1, URLScan creates a new log file each day and appends a date to the log filename (for example, UrlScan.052202.log). If set to 0, URLScan creates one monolithic log. Since we don't recommend logging URLScan rejects unless actively troubleshooting, this setting is sort of meaningless.

• LogLongUrls (0,1)  Added in URLScan 2.5. Setting this to 1 raises the limit of the length of URLs stored in the URLScan logs to 128 kilobytes (KB). If the value is set to 0, then log entries contain only the first 1,024 bytes of the URL. Unless resources are an issue, this should be set to 1 (although per our previous recommendation to disable URLScan logging altogether, this is sort of irrelevant unless you are actively debugging URLScan or have enabled login following a suspected attack in order to conduct forensic analyses).

• AllowLateScanning (0,1)  This sets the priority of the URLScan filter. We recommend setting this to 0 (high priority) unless you're using FrontPage Server Extensions (FPSE), in which case you should set this to 1 so that the FPSE filter has priority over URLScan. If you are using FPSE, you should also use IISAdmin to move URLScan below fpexedll.dll.

• RejectResponseUrl (string)  The default is empty, which actually sends / Rejected-By-URLScan to clients and causes them to display an HTTP 404 "Object Not Found" page. You can set a custom rejected-response page by specifying a URL in the form "/path/file_name.ext". The URL needs to be located on the local web server. We like to leave this as the default (empty), which gives attackers very little information. If you elect to create a custom URL, you can use some special server variables created by URLScan to populate the page with specific information on why the request was rejected see the URLScan documentation for more info. Also, remember that if you set RejectResponseUrl= /~*, URLScan performs all of the configured scanning and logs the results but will allow IIS to serve the page even if it would normally be rejected. This mode is useful if you would like to test UrlScan.ini settings without actually rejecting any requests.

• UseFastPathReject (0,1)  If set to 1, URLScan ignores the RejectResponseUrl and returns a short 404 response to the client in cases where it rejects a request (Figure C-6 shows the short response). If this option is used, IIS cannot return a custom 404 response or log many parts of the request into the IIS log (the URLScan log files will still contain complete information about rejected requests). We say set this to 0 and configure your own custom 404.

  
  Figure C-6: If UseFastPathReject is set to 1, this is what clients will see for HTTP 404 rejected requests.

AllowVerbs Section

If UseAllowVerbs is set to 1 in the Options section, URLScan rejects any request containing an HTTP verb (or method) not explicitly listed in this section. The entries in this section are case-sensitive. We advocate setting UseAllowVerbs=1 and listing as few verbs as possible here (if you can get away with only listing GET here, go for it!).

DenyVerbs Section

If UseAllowVerbs is set to 0 in the Options section, URLScan rejects any request containing an HTTP verb (or method) that is listed in this section. The entries in this section are case-insensitive. Again, we think using the AllowVerbs section wisely is a better option, but if you can't conclusively list all of the HTTP methods your application requires, you may need to use this option. We still think you should know what methods you support, though.

DenyHeaders Section

Any request containing a request header listed in this section will be rejected. The entries in this section are case-insensitive.

AllowExtensions Section

If UseAllowExtensions is set to 1 in the Options section, any request containing a URL with an extension not explicitly listed here is rejected. The entries in this section are case-insensitive. Note that you can specify extensionless requests (for example, requests for a default page or a directory listing) by placing a single dot (.) somewhere in this section, as shown in line 2 of the following example:

 [AllowExtensions] . .htm .html etc. 

We think it's easier to specify file extensions that you will allow, rather than using the DenyExtensions section to try and single out all the requests you won't permit. But this depends again on how well you know your own app.

DenyExtensions Section

The DenyExtensions section contains a list of file extensions. If UseAllowExtensions is set to 0 in the Options section, any request containing a URL with an extension listed here is rejected. The entries in this section are case-insensitive. As with AllowExtensions, you can specify extensionless requests with a single dot (.) somewhere in this section. If you want to use this section, we suggest you consult the urlscan-static.ini template file that comes with the IIS Lockdown tool. It has a good DenyExtensions section.

RequestLimits Section

Added in URLScan 2.5, the RequestLimits section includes the following entries:

• MaxAllowedContentLength (value)  Enforces a content length limit per request. The default limit is 2GB; we recommend dropping this to 100KB (obviously, this is very app-specific and should be rigorously tested ). Note that a chunked transfer-encoded POST will avoid this limit, as it only applies to one POST.

• MaxUrl (value)  Restricts the length of the request URL, in bytes. Note that the length of the query string is not restricted by this setting. When you upgrade URLScan by using the installer, the default value is 16KB. If you manually extract UrlScan.dll from UrlScan.exe and you do not update UrlScan.ini, the default setting will be 260 bytes. In this case, you will have to add MaxUrl = 16384 to UrlScan.ini to overwrite the default setting.

• MaxQueryString (value)  Restricts the length of the query string, in bytes. The default value is 4KB.

• Max[ Header_Name ] (value)  URLScan can impose a byte limit on the size of any HTTP header by prepending "Max-" to the name of the header. For example, to impose a limit of 100 bytes on the "Content-Type" header, you'd add the following to UrlScan.ini: Max-Content-Type=100. Any headers that are not listed in the RequestLimits section are not checked for length limits. To list a header without specifying a maximum value (perhaps to explicitly remind administrators that it is not to be configured), use 0. For example, Max-User-Agent=0.

IIS6 Request Restriction Settings   Here's a good example of why URLScan provides little added benefit when installed on IIS6: many of the previous URLScan configurations are configured elsewhere in IIS6 and are thus pretty much superseded. For example, rather than using the URLScan RequestLimits settings just described, IIS6 configures limits on the size of requests in the Registry, under HKLM\System\CurrentControlSet\Services\ HTTP\Parameters.

Table C-1 provides a brief overview of IIS6 HTTP parameter Registry settings related to security, along with our recommended configuration.

Table C-1: IIS6 Request Restriction Settings Under HKLM\System\CurrentControlSet\Services\HTTP\Parameters

Parameter	Restricts	Default/Recommended
MaxFieldLength	HTTP header length	16KB/(same)
MaxRequestBytes	Total size of the request line, including headers	16KB/(same)
UrlSegmentMaxCount	Number of slashes in a URL request	255/100
UrlSegmentMaxLength	Number of characters in URL	260/(same)
AllowRestrictedChars	Hexadecimal-escaped characters	0/0
PercentUAllowed	%uNNNN notation in URLs	1/0
EnableNonUTF8	Non-UTF-8encoded URLs, ANSI, or double-byte character set (DBCS)	1/(same)

Managing Urlscan

Once you've got URLScan up and running, it's pretty much on autopilot, with a few exceptions. For one, if you need to change your URLScan configuration (by updating the UrlScan.ini configuration file), you'll need to restart IIS in order for the new settings to take effect. We'll reiterate basic Microsoft guidance on restarting IIS in this section, along with some considerations about setting the priority for the URLScan ISAPI filter and removing URLScan.

Reloading URLScan

ISAPI filters like URLScan are loaded into memory only during IIS startup, so every time you make modifications to UrlScan.dll or UrlScan.ini, you must restart IIS. Usually the URLScan installer performs this for you, but here are some tips just in case.

On IIS 4, you need to manually stop and start each IIS service that requires URLScan protection. Typically, this is only the World Wide Web service, or W3SVC, which can be stopped by typing the following at a command prompt:

 net stop w3svc /Y 

To start the W3SVC, now type

 net start w3svc 

On IIS 5 and later, the iisreset command can be used. Simply type iisreset at a command prompt, and all IIS services will be restarted. Here is a simple batch file that gracefully stops IIS services, backs up the W3SVC logs, and starts IIS again:

 @@echo off IISRESET /STOP /NOFORCE if errorlevel == 1 goto EXIT copy %systemroot%\system32\LogFiles\W3SVC1 d:\backup\W3SVC1 IISRESET /START :EXIT 

This script may prove useful if you need to gracefully restart IIS.

Adjusting URLScan Priority

Generally, you'll never need to adjust the priority of the URLScan ISAPI filter (which defines in what order ISAPI filters touch an incoming request). The following guidance is only provided for the rare instances where this becomes necessary.

Open the ISAPI Filters screen in the IISAdmin tool, as shown in Figure C-7. If URLScan is not at the top of the list and does not have a priority of High, you should consider changing it. URLScan should intercept all incoming requests before they are passed to any other DLLs so that it can prevent malicious requests to those DLLs. Use the arrow buttons on the left side of this screen to adjust URLScan's priority until it looks something like Figure C-7.

Figure C-7: A successfully loaded URLScan ISAPI filter

There are some cases where URLScan should not be loaded first, depending on what products you may be running on the web server. To date, the only exception we are aware of occurs if you use FrontPage Server Extensions (FPSE). In this case, you may need to move the URLScan filter below the FPSE ISAPI filter (fpexedll.dll) and change its priority to Low.

Note 

URLScan priority can also be set using the AllowLateScanning setting in UrlScan.ini.

Disabling URLScan

If you should ever need to disable URLScan, you have a few options.

If, after you install URLScan, your web application begins dropping certain client requests, you can set URLScan into a logging-only mode that will permit all requests but will log any requests that it would normally reject. This can be quite helpful for troubleshooting. To put URLScan in logging-only mode, add the value /~* (slash-tilde-asterisk) to the RejectResponseUrl line in UrlScan.ini so that it looks like this:

 RejectResponseUrl=/~* 

Then restart IIS to load the new config.

If you simply want to disable URLScan, you can uninstall the ISAPI filter. In the IISAdmin console, simply select the URLScan filter on the ISAPI Filters tab and click Remove (or Prohibit on IIS6), and then restart IIS. This will not delete UrlScan.dll or UrlScan.ini. In order to re-enable URLScan, you'll either have to run the installer (say, if you download an updated version of URLScan) or manually re-enable the URLScan ISAPI by reversing the above procedure.