|
Home > Archive > IIS Server Security > December 2007 > Disable TRACE IIS 6
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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
| |
| David Wang 2007-12-07, 7:23 pm |
| On Dec 7, 2:16 am, Rob <R...@discussions.microsoft.com> 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
//
| |
|
| Hi David and thanks for your response.
The odd thing about the OPTIONS values are that on our dev server the
response is only TRACE, GET, HEAD and when I do a TRACE I get the 501
response. The only differences with the live and dev server is that we are
implementing a new site (currently on the dev server) which only uses ASP 2.0
and this is where I think the issue lies. Our live server has some sites
that use ASP 1.1. I've done some digging and can see that http handlers done
through ASP 1.1 send a 403 foribidden response if the verb is not allowed so
I suspect this is where the response is coming from for PUT and DELETE. I
don't yet know enough about the TRACE method to be able to see if anything is
being revealed - that's todays reading! I suspect it's all ok.
"David Wang" wrote:
> On Dec 7, 2:16 am, Rob <R...@discussions.microsoft.com> wrote:
>
>
> 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
> //
>
|
|
|
|
|