URLScan UpdateFrom: Lester, Don (dlester@CLINITECH.NET)
- Previous message: Russ: "Re: Important Information Regarding MS01-054 and WindowsME"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-ID: <6CC25018D3C8D411B2F500508B4456AE8E2013@wvc-exchange> Date: Wed, 7 Nov 2001 15:46:26 -0800 From: "Lester, Don" <dlester@CLINITECH.NET> Subject: URLScan Update To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
I have received a lot of feedback regarding my earlier post about URLScan.
It turns out, unfortunately, the work-around I posted does not work in all
cases. Out of frustration, I opened a ticket with Microsoft support. I
wish the result of that was better news, but here is what we found:
The bad news is that the version you can download from the web site does not
work correctly. They are supposed to fix this, but when/if that will ever
actually happen is anyone's guess.
The good news is that if you are one of the lucky people that has a
Microsoft Technet subscription you should have recently received the greatly
anticipated Microsoft Security Tool Kit CD (if not, you can order it from
Microsoft). I do not like how this CD works. It does a lot of things
without asking, and the installation itself does not seem to allow you to
skip the IIS Lockdown installation and proceed to the URLScan installation.
It is one continuous operation that installs one module after another.
BUT, after all of this, it is still bugged. Microsoft alleged it was fixed,
but I worked with their support staff to find the means to make the
UseAllowExtensions option work for default pages. It still isn't documented
anywhere, and hopefully they will eventually fix their broken product. The
programmer asserted that it was working as intended, and should only allow
the extensions specifically listed. I suggested he look at any standard
firewall product and compare his work with the rest of the world's standard
practices. I also invited him to present a scenario when an IIS server
should not serve the default page (ie, /) for a given directory.
I had a lot of requests for the INI file. This is the one I am currently
using for testing, but it will be restricted even more before this box goes
into production. The lone . in the allow extensions section is intentional.
That is the workaround for the bug. It does work here for all cases I have
run it through, but that doesn't mean it will work for everyone (though I
hope it does). Microsoft has some work to do on their security package. If
you want to be sure you are using the same version, my urlscan.dll is
UseAllowVerbs=1 ; if 1, use [AllowVerbs] section, else use
UseAllowExtensions=1 ; if 1, use [AllowExtensions] section, else
use [DenyExtensions] section
NormalizeUrlBeforeScan=1 ; if 1, canonicalize URL before processing
VerifyNormalization=1 ; if 1, canonicalize URL twice and reject
request if a change occurs
AllowHighBitCharacters=0 ; if 1, allow high bit (ie. UTF8 or MBCS)
characters in URL
AllowDotInPath=0 ; if 1, allow dots that are not file
RemoveServerHeader=0 ; if 1, remove "Server" header from response
EnableLogging=1 ; if 1, log UrlScan activity
PerProcessLogging=0 ; if 1, the UrlScan.log filename will contain
a PID (ie. UrlScan.123.log)
AllowLateScanning=0 ; if 1, then UrlScan will load as a low
PerDayLogging=1 ; if 1, UrlScan will produce a new log each
day with activity in the form UrlScan.010101.log
RejectResponseUrl= ; UrlScan will send rejected requests to the
URL specified here. Default is /<Rejected-by-UrlScan>
UseFastPathReject=0 ; If 1, then UrlScan will not use the
RejectResponseUrl or allow IIS to log the request
; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
; Extensions listed here are commonly used on a typical IIS server.
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; Don't allow multiple CGI processes to run on a single request