Disable TRACE IIS 6

We have had results from a pen test and they state that we have TRACE HHTP
enabled and also the OPTIONS request returns GET, HEAD, POST, PUT,
DELETE,TRACE, OPTIONS, CONNECT

We have disabled TRACE via the registry (EnableTraceMethod = 0)
I have installed urlscan and allowed only GET, HEAD, POST verbs
I've got into the home directory > configuration for the root, default and
each virutal site and edited each extension so that only GET, HEAD and POST
are allowed

We do not use WebDAV - prohibited and only use ASP

However, using Nesses, netcat and wfetch all return the same:
OPTIONS still show GET, HEAD, POST, PUT, DELETE,TRACE, OPTIONS, CONNECT
TRACE / HTTP/1.0 still returns a 200 OK and not a 501
PUT /../..HTTP/1.0 returns a 403 forbidden tho I am unsure whether that
matters or not?

Any ideas? Is thois a false positve?
Thanks

Re: Disable TRACE IIS 6

On Dec 7, 2:16 am, Rob wrote:
> We have had results from a pen test and they state that we have TRACE HHTP
> enabled and also the OPTIONS request returns GET, HEAD, POST, PUT,
> DELETE,TRACE, OPTIONS, CONNECT
>
> We have disabled TRACE via the registry (EnableTraceMethod = 0)
> I have installed urlscan and allowed only GET, HEAD, POST verbs
> I've got into the home directory > configuration for the root, default and
> each virutal site and edited each extension so that only GET, HEAD and POST
> are allowed
>
> We do not use WebDAV - prohibited and only use ASP
>
> However, using Nesses, netcat and wfetch all return the same:
> OPTIONS still show GET, HEAD, POST, PUT, DELETE,TRACE, OPTIONS, CONNECT
> TRACE / HTTP/1.0 still returns a 200 OK and not a 501
> PUT /../..HTTP/1.0 returns a 403 forbidden tho I am unsure whether that
> matters or not?
>
> Any ideas? Is thois a false positve?
> Thanks


Return value of OPTIONS is static so you can ignore it.

URLScan will reject PUT with 404 if it is running so it looks like
URLScan is not running on your system as you think.

TRACE has special code in IIS that skips over URLScan's attempt to
reject it, so EnableTraceMethod=0 is the only way. Are you sure your
TRACE actually worked to reveal anything after you set the registry
key because simply returning 200 doesn't mean there's a problem...

Consider the security setting of Known Extensions -- IIS returns 404
for disabled extensions or unknown file extensions even if the file
exists -- because to do anything else gives away information.
Likewise, if OPTIONS and TRACE start doing different things by
configuration, it gives away information...


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//