RE: UrlScan vs. IISShield

["Tiago Halm" <thalm () netcabo pt>]

Features not covered by UrlScan, such as:

- HTTP Version validation
- Header Name and Value size limit
- Header Name and Value encoding abuse detection
- Header Name and Value high bit detection
- Host & Port valid combination
- Url Schema usage and validation
- Query String Sequence constraint
- Query String encoding abuse detection
- Query String High bit detection

are all features implemented by IISShield providing a broad and detailed
mechanism for configuring and  protecting IIS for all usage scenarios.
IISShield provides a more solid prespective on what to protect and how to
protect over the HTTP Protocol Layer.

Regarding IISShield usage in IIS 6.0 in a more technical prespective, IIS
ISAPI Filters have several notifications to which they can "subscribe" in
order to be notified and customize the IIS behavior.

These notifications and their meaning are available at (text may wrap):
http://msdn.microsoft.com/library/en-us/iisref/htm/Filters_EntryPoint_HttpFi
lterProc.asp?frame=true

The most important notifications which I am about to mention are:
a) SF_NOTIFY_READ_RAW_DATA
b) SF_NOTIFY_PREPROC_HEADERS
Note that a) occurs always before b)

Starting with IIS6, IIS supports two isolation modes:
- Worker Process Isolation Mode - WPIM (default)
- IIS5 Isolation Mode

When IIS6 runs in WPIM, ISAPI Filters are not allowed to "listen" to the
SF_NOTIFY_READ_RAW_DATA notification.  This notification is only available
in IIS5 Isolation Mode.

Having said this, I will explain the meaning of these notifications for an
ISAPI Filter for HTTP Layer Firewalling prespective.

SF_NOTIFY_READ_RAW_DATA
This notification allows an ISAPI Filter to scan and parse the byte stream
that is reaching IIS (think of it as a process that first reads the contents
of a file and inserts it into a buffer before it starts parsing that same
data), just before IIS starts interpreting that same stream. By
"interpreting", I mean before IIS starts parsing the stream and preparing a
set of structures to give an ISAPI Filter a different way to deal with that
same data.
In conclusion, the ISAPI Filter has only (that is the good part) a low level
access to a simple byte buffer which IIS has not yet parsed.

SF_NOTIFY_PREPROC_HEADERS
This notification occurs **after** IIS has parsed the HTTP byte stream in
terms of protocol format (that is one of the many reasons by which you can
exploit IIS - for example when delivering an HTTP Request format which IIS
is not capable to understand but when trying to parse the format it manages
to provoque a possible buffer overflow)

IISShield's protection and parsing engine occurs over the
SF_NOTIFY_READ_RAW_DATA notification is order to be as low level as possible
and as secure as it can be. Since IISShield behaves this way (the only
secure way) IISShield will only work over IIS6 when in IIS5 isolation mode.

On the other hand, UrlScan works in IIS6 in WPIM. Why? Simply because in
IIS6 WPIM UrlScan does **not** subscribe to the SF_NOTIFY_READ_RAW_DATA
notification (it can't subscribe, because otherwise it would not work). Note
that my prespective in terms of UrlScan is a user prespective, and, after
installing UrlScan in IIS6, my UrlScan statement is based in the file
%SYSTEMROOT%\inetsrv\metabase.xml in the FilterFlags node of URLSCAN,
meaning that I may be wrong, but I believe this is the only possible
explanation for UrlScan to work in IIS6 WPIM. Note that UrlScan works in
conjunction with the HTTP.sys driver security and performance capabilities.

...
<IIsFilter      Location ="/LM/W3SVC/Filters/URLSCAN"
                FilterDescription="UrlScan ISAPI Filter"
                FilterEnableCache="TRUE"
                FilterFlags="NotifyPreProcHeaders | NotifyOrderHigh"
                FilterPath="C:\WINDOWS\system32\inetsrv\urlscan\urlscan.dll"
                FilterState="1"
        >
</IIsFilter>
...

In conclusion, IISShield offers a significant protection engine in
comparison to UrlScan. When running in IIS6, IISShield needs for IIS6 to run
in IIS5 isolation mode.

In a security prespective, it comes to the choice between security over
performance.

Other IISShield details can be found at:
http://www.kodeit.org/tools/iisshield.htm

IISShield Mailing List is at:
http://groups.yahoo.com/group/IISShield/

Regards,
Tiago Halm

-----Original Message-----
From: bowulf () myrealbox com [mailto:bowulf () myrealbox com] 
Sent: quarta-feira, 6 de Agosto de 2003 15:03
To: security-basics () securityfocus com
Subject: UrlScan vs. IISShield




I have seen the new ISAPI filter released called IISShield.  What would be 

the benefit of going to that filter as opposed to URLScan?  Also what 

modifications do you make to your own verb lists or prohibited strings?

---------------------------------------------------------------------------
----------------------------------------------------------------------------


---------------------------------------------------------------------------
----------------------------------------------------------------------------