Boswell's Q&A

Get Your Fix of Q&A Despite URLScan

Configure URLScan to access blocked URLs.

• By Bill Boswell
• 10/05/2004

Question: I'm an administrator at a large university and I have an interesting problem regarding your column.

We recently installed URLScan 2.5 on our Exchange 2003 servers and now I can't read your Q&A column using OWA, because URLScan rejects the "&" in the title. KB article 823175 explains the issue.

In brief, your Q&A column is blocked because of an entry in the DenyURLSequences section of the URLScan.ini file:

[DenyUrlSequences]

.. ; Do not permit directory traversals.
./ ; Do not permit trailing dot on a directory name.
\ ; Do not permit backslashes in URL.
% ; Do not permit escaping after normalization.
& ; Do not permit multiple Common Gateway Interface processes to run on a single request.

Here's the error from the Exchange server:

10-01-2004 - 11:56:12] Client at 1.1.1.1: URL contains sequence '&', which is disallowed. Request will be rejected. Site Instance='1', Raw URL='/exchange/username/Inbox/Re:%20Boswell%27s%20Q%26A:%20Log%20Jam-4.EML'

What do you suggest we do?

—Tony

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Answer: My knee-jerk reaction was to tell Tony to remove the "&" from URLScan.ini so he wouldn’t miss a single one of my scintillating commentaries. However, putting ego aside, I decided to do a little research first before suggesting a fix.

For those of you who have not heard of URLScan, it is a Microsoft tool that was initially released as a companion to IISLockdown, a tool for turning off unnecessary features in IIS. The two tools are now separate. The most current copy of IIS Lockdown Wizard, version 2.1, can be downloaded here. The most current copy of URLScan, version 2.5, can be downloaded here.

The combination of IISLockdown and URLScan can block the vast majority of exploits aimed at IIS 4 and 5. This includes applications running on IIS, such as Internet Services API (ISAPI) applications, Common Gateway Interface (CGI) applications, scripts, executables and so forth.

Now to the problem at hand: keeping URLScan from blocking my column. Many exploits involve playing games with the data requests sent to the IIS server. These requests take the form of URL strings, such as changing to a higher directory (traversal exploits) or embedding encoded characters (% exploits) or running multiple applications using &. URLScan was designed to block malformed or unauthorized strings before they arrive at the IIS engine. This not only protects the server from attack, it reduces the load on a fully patched server by rejecting invalid requests immediately rather than letting the requests get processed and rejected by IIS.

In IIS 6.0 (released along with Windows Server 2003), Microsoft rewrote IIS from the ground up and incorporated all the lessons they learned over the years about protecting applications running on the server. As a result, the IISLockdown tool is not required on IIS 6.0. Also, the vast majority of features in URLScan were incorporated directly into the new HTTP.SYS driver, making URLScan all but redundant.

However, there are a few features in URLScan that are not present in IIS 6.0. For example, if you want to block the IIS version number in the header returned to a browser client, you must use URLScan. The question is, then, should you install URLScan on IIS 6.0 or not? What is the best practice?

In my research to answer this question, I came across an excellent webcast from Microsoft called "URLScan 2.5 and IIS 6.0" presented by Chris Adams, the Microsoft Web Platform Supportability Lead, and the developer of URLScan, Wade Hilmo. You can view an on-demand replay of this webcast here.

In this webcast, Wade states that the URLSequences feature is no longer required on IIS 6.0. To quote the slide accompanying the presentation: "It is not necessary for IIS 6.0 to deny URL sequences. By design, IIS 6.0 is not susceptible to URL based attacks that use any of the character sequences listed in the default DenyURLSequences section of the Urlscan.ini file provided by Microsoft."

In the commentary accompanying the slides, Wade goes on to say that if you encounter URLs that use a proscribed character, there's nothing wrong with removing that character from the .INI file. A white paper that contains pretty much the same information as the webcast is available here.

Based on the information in the white paper and the webcast, I would say that you should only install URLScan on an IIS 6.0 server if you really need one of the small features that aren't already embedded into the core IIS code. If you do install URLScan and you want to read my Q&A column in OWA, or access other content that might be blocked by the URLSequences feature, you can remove the character from Urlscan.ini file.

Hope this helps!

Feedback: “Neither Rain Nor Snow Nor Security Popups” A column two weeks ago about changing the security settings in Outlook to allow a scripted application to send mail using MAPI prompted Steve to write in with the following: "In terms of eliminating the annoying pop-ups when trying to use Outlook to send automated e-mails, there is another way: Eliminate Outlook! There are numerous command-line SMTP programs that can be downloaded for free (I have used 'postie' for this) that allow sending outbound SMTP mail, with attachments, without user intervention. Not knowing the details of how your reader's system worked and what was required, maybe command line wasn't an option. But if it was, it's a whole lot easier than trying to work around Outlook's security annoyances." Steve's suggestion is excellent, but it assumes that the firewall will permit outbound traffic over TCP port 25 from the desktop running the SMTP program. This port is often blocked. It's possible to configure SMTP to use a smart host, so you could point the application at an SMTP server behind the firewall. However, most organizations block this kind of relaying to prevent inadvertent or intentional spamming. Still, if you want to make the necessary perimeter security adjustments, you can use SMTP rather than Outlook to send e-mail and avoid changing the security settings of the local client. Also, if you want to use SMTP from an XP desktop, you may want to know that the IIS suite of services in XP comes with an SMTP service, so try it first before downloading yet another service onto a machine. If you have anything else to add about configuring Outlook and security settings, be sure to write me at mailto:[email protected].