Get Your Fix of Q&A Despite URLScan
Configure URLScan to access blocked URLs.
- By Bill Boswell
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:
.. ; 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 184.108.40.206: URL contains sequence
'&', which is disallowed. Request will be rejected. Site Instance='1',
What do you suggest we do?
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
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
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!
“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
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].
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.