Disabling TRACE verb on IIS 6.0

Disabling TRACE verb on IIS 6.0

am 13.07.2005 21:01:04 von Omid

I have alraedy posted this on IIS-Security, and since I have not recieved any
responses, I am posting it here again:

Hi,
I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS 6.0 web
server for HTTP TRACE verb. If I send a TRACE verb to my web site, I recieve:

HTTP/1.1 Error 501 - Not Implemented

which based on KB247643 is an indication of TRACE verb being disabled on my
site, a good sign for my specific requirement.

However if I send HTTP OPTIONS verb to the same web site I receive:

HTTP/1.1 200 OK\r\n
Allow: OPTIONS, TRACE, GET, HEAD\r\n
Content-Length: 0\r\n
Server: Microsoft-IIS/6.0\r\n
Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
\r\n

Does this indicate the TRACE is enabled? or Allowed? Which one of the above
two responses supercedes the other?

I am responding back to an audit report and need to confirm this.

Thanks
Omid

Re: Disabling TRACE verb on IIS 6.0

am 14.07.2005 06:40:22 von wadeh

Hi Omid,

If making a TRACE request results in a 501, you can say definitively that
the TRACE verb is disabled.

The reason for the discrepency in the OPTIONS output is that the OPTIONS
request is not handled by the IIS core. It is handled by WebDAV (which is
actually not even produced by the IIS team) and the WebDAV code apparently
does not recognize the registry setting that disables TRACE. Also, the
functionality to disable TRACE went into the IIS 6 code very late in the
development cycle, so there would have been no opportunity for the other
team to modify WebDAV to account for this.

I hope that this clears up the question for you.

Thank you,
-Wade A. Hilmo,
-Microsoft

"Omid" wrote in message
news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> I have alraedy posted this on IIS-Security, and since I have not recieved
any
> responses, I am posting it here again:
>
> Hi,
> I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS 6.0 web
> server for HTTP TRACE verb. If I send a TRACE verb to my web site, I
recieve:
>
> HTTP/1.1 Error 501 - Not Implemented
>
> which based on KB247643 is an indication of TRACE verb being disabled on
my
> site, a good sign for my specific requirement.
>
> However if I send HTTP OPTIONS verb to the same web site I receive:
>
> HTTP/1.1 200 OK\r\n
> Allow: OPTIONS, TRACE, GET, HEAD\r\n
> Content-Length: 0\r\n
> Server: Microsoft-IIS/6.0\r\n
> Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> \r\n
>
> Does this indicate the TRACE is enabled? or Allowed? Which one of the
above
> two responses supercedes the other?
>
> I am responding back to an audit report and need to confirm this.
>
> Thanks
> Omid
>
>

Re: Disabling TRACE verb on IIS 6.0

am 14.07.2005 17:09:02 von Omid

Wade,

Thanks very much for the info. I have two follow up questiond though:

1-I don't recall disabling trace manually, is it disabled by deafult?, and
where is the setting for disabling/enabling TRACE in IIS 6.0?

2-I need a refernce to a Microsoft KB or any document for that matter that
states what you have mentioned here. I am replying back to an audit report
that claims TRACE is enabled on my IIS site and need to provide evidence that
it isn't. To generate their report, they have used some thrid party tool to
send "OPTIONS" verb to the server.

Thanks
Omid

"Wade A. Hilmo [MS]" wrote:

> Hi Omid,
>
> If making a TRACE request results in a 501, you can say definitively that
> the TRACE verb is disabled.
>
> The reason for the discrepency in the OPTIONS output is that the OPTIONS
> request is not handled by the IIS core. It is handled by WebDAV (which is
> actually not even produced by the IIS team) and the WebDAV code apparently
> does not recognize the registry setting that disables TRACE. Also, the
> functionality to disable TRACE went into the IIS 6 code very late in the
> development cycle, so there would have been no opportunity for the other
> team to modify WebDAV to account for this.
>
> I hope that this clears up the question for you.
>
> Thank you,
> -Wade A. Hilmo,
> -Microsoft
>
> "Omid" wrote in message
> news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> > I have alraedy posted this on IIS-Security, and since I have not recieved
> any
> > responses, I am posting it here again:
> >
> > Hi,
> > I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS 6.0 web
> > server for HTTP TRACE verb. If I send a TRACE verb to my web site, I
> recieve:
> >
> > HTTP/1.1 Error 501 - Not Implemented
> >
> > which based on KB247643 is an indication of TRACE verb being disabled on
> my
> > site, a good sign for my specific requirement.
> >
> > However if I send HTTP OPTIONS verb to the same web site I receive:
> >
> > HTTP/1.1 200 OK\r\n
> > Allow: OPTIONS, TRACE, GET, HEAD\r\n
> > Content-Length: 0\r\n
> > Server: Microsoft-IIS/6.0\r\n
> > Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> > Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> > \r\n
> >
> > Does this indicate the TRACE is enabled? or Allowed? Which one of the
> above
> > two responses supercedes the other?
> >
> > I am responding back to an audit report and need to confirm this.
> >
> > Thanks
> > Omid
> >
> >
>
>
>

Re: Disabling TRACE verb on IIS 6.0

am 15.07.2005 04:29:18 von wadeh

Hi Omid,

TRACE handling is disabled by default. It can be enabled by a registry key.
The following article describes a number of registry keys, and the one in
question is the first on the list:

http://www.microsoft.com/technet/prodtechnol/WindowsServer20 03/Library/IIS/d779ee4e-5cd1-4159-b098-66c10c5a3314.mspx

As for documentation explaining why OPTIONS lists it, I doubt that anything
exists for that. My explanation below for why the WebDAV handler doesn't
know about whether TRACE is enabled or disabled is a hypothesis on my part
(but it is a very educated hypothesis.)

Thank you,
-Wade A. Hilmo,
-Microsoft

"Omid" wrote in message
news:1E5728B8-B687-464A-B413-2DC14A123A45@microsoft.com...
> Wade,
>
> Thanks very much for the info. I have two follow up questiond though:
>
> 1-I don't recall disabling trace manually, is it disabled by deafult?, and
> where is the setting for disabling/enabling TRACE in IIS 6.0?
>
> 2-I need a refernce to a Microsoft KB or any document for that matter that
> states what you have mentioned here. I am replying back to an audit report
> that claims TRACE is enabled on my IIS site and need to provide evidence
that
> it isn't. To generate their report, they have used some thrid party tool
to
> send "OPTIONS" verb to the server.
>
> Thanks
> Omid
>
> "Wade A. Hilmo [MS]" wrote:
>
> > Hi Omid,
> >
> > If making a TRACE request results in a 501, you can say definitively
that
> > the TRACE verb is disabled.
> >
> > The reason for the discrepency in the OPTIONS output is that the OPTIONS
> > request is not handled by the IIS core. It is handled by WebDAV (which
is
> > actually not even produced by the IIS team) and the WebDAV code
apparently
> > does not recognize the registry setting that disables TRACE. Also, the
> > functionality to disable TRACE went into the IIS 6 code very late in the
> > development cycle, so there would have been no opportunity for the other
> > team to modify WebDAV to account for this.
> >
> > I hope that this clears up the question for you.
> >
> > Thank you,
> > -Wade A. Hilmo,
> > -Microsoft
> >
> > "Omid" wrote in message
> > news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> > > I have alraedy posted this on IIS-Security, and since I have not
recieved
> > any
> > > responses, I am posting it here again:
> > >
> > > Hi,
> > > I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS 6.0
web
> > > server for HTTP TRACE verb. If I send a TRACE verb to my web site, I
> > recieve:
> > >
> > > HTTP/1.1 Error 501 - Not Implemented
> > >
> > > which based on KB247643 is an indication of TRACE verb being disabled
on
> > my
> > > site, a good sign for my specific requirement.
> > >
> > > However if I send HTTP OPTIONS verb to the same web site I receive:
> > >
> > > HTTP/1.1 200 OK\r\n
> > > Allow: OPTIONS, TRACE, GET, HEAD\r\n
> > > Content-Length: 0\r\n
> > > Server: Microsoft-IIS/6.0\r\n
> > > Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> > > Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> > > \r\n
> > >
> > > Does this indicate the TRACE is enabled? or Allowed? Which one of the
> > above
> > > two responses supercedes the other?
> > >
> > > I am responding back to an audit report and need to confirm this.
> > >
> > > Thanks
> > > Omid
> > >
> > >
> >
> >
> >

Re: Disabling TRACE verb on IIS 6.0

am 15.07.2005 07:24:38 von Tiago Halm

Wade, OPTIONS is a quite core verb of the HTTP protocol.
However, you state that the OPTIONS request is handled by WebDav?? (and by
WebDav I would assume its core DLL, httpext.dll). Disabling that DLL
(unACLing it fully or even deleting it) would then prevent IIS from
answering OPTIONS?
I think not.

While I'm not in any way aware of the inner workings of IIS, I would assume
OPTIONS is handled by the core of IIS and has a default response. The fact
that the response always includes all available verbs does not mean they are
available or that they are not blocked by any kind of filtering scheme
running inside the Web Server.

www.microsoft.com is blocking OPTIONS via a filtering scheme.
However, my IIS6 does not block OPTIONS and answers "OPTIONS, TRACE, GET,
HEAD, POST" as you would expect it to.

I presume WebDav "adds" some more additional methods like "DELETE, PUT,
COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH", but these
"additional" methods should be queried by the IIS core to WebDav's DLL and
should only be returned if WebDav is "enabled". The "enabled" concept in
IIS5 is somewhat not defined, but in IIS6 it is defined and works as
expected.

I am probably mistaken in some statements above in terms of the IIS inner
workings, but stating that OPTIONS is handled by WebDav is not coherent.

PS: I always find your posts unvaluable, so please take this comment in a
good sense.

Tiago Halm


"Wade A. Hilmo [MS]" wrote in message
news:u9rP5TOiFHA.2180@TK2MSFTNGP15.phx.gbl...
> Hi Omid,
>
> TRACE handling is disabled by default. It can be enabled by a registry
key.
> The following article describes a number of registry keys, and the one in
> question is the first on the list:
>
>
http://www.microsoft.com/technet/prodtechnol/WindowsServer20 03/Library/IIS/d779ee4e-5cd1-4159-b098-66c10c5a3314.mspx
>
> As for documentation explaining why OPTIONS lists it, I doubt that
anything
> exists for that. My explanation below for why the WebDAV handler doesn't
> know about whether TRACE is enabled or disabled is a hypothesis on my part
> (but it is a very educated hypothesis.)
>
> Thank you,
> -Wade A. Hilmo,
> -Microsoft
>
> "Omid" wrote in message
> news:1E5728B8-B687-464A-B413-2DC14A123A45@microsoft.com...
> > Wade,
> >
> > Thanks very much for the info. I have two follow up questiond though:
> >
> > 1-I don't recall disabling trace manually, is it disabled by deafult?,
and
> > where is the setting for disabling/enabling TRACE in IIS 6.0?
> >
> > 2-I need a refernce to a Microsoft KB or any document for that matter
that
> > states what you have mentioned here. I am replying back to an audit
report
> > that claims TRACE is enabled on my IIS site and need to provide evidence
> that
> > it isn't. To generate their report, they have used some thrid party tool
> to
> > send "OPTIONS" verb to the server.
> >
> > Thanks
> > Omid
> >
> > "Wade A. Hilmo [MS]" wrote:
> >
> > > Hi Omid,
> > >
> > > If making a TRACE request results in a 501, you can say definitively
> that
> > > the TRACE verb is disabled.
> > >
> > > The reason for the discrepency in the OPTIONS output is that the
OPTIONS
> > > request is not handled by the IIS core. It is handled by WebDAV
(which
> is
> > > actually not even produced by the IIS team) and the WebDAV code
> apparently
> > > does not recognize the registry setting that disables TRACE. Also,
the
> > > functionality to disable TRACE went into the IIS 6 code very late in
the
> > > development cycle, so there would have been no opportunity for the
other
> > > team to modify WebDAV to account for this.
> > >
> > > I hope that this clears up the question for you.
> > >
> > > Thank you,
> > > -Wade A. Hilmo,
> > > -Microsoft
> > >
> > > "Omid" wrote in message
> > > news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> > > > I have alraedy posted this on IIS-Security, and since I have not
> recieved
> > > any
> > > > responses, I am posting it here again:
> > > >
> > > > Hi,
> > > > I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS 6.0
> web
> > > > server for HTTP TRACE verb. If I send a TRACE verb to my web site, I
> > > recieve:
> > > >
> > > > HTTP/1.1 Error 501 - Not Implemented
> > > >
> > > > which based on KB247643 is an indication of TRACE verb being
disabled
> on
> > > my
> > > > site, a good sign for my specific requirement.
> > > >
> > > > However if I send HTTP OPTIONS verb to the same web site I receive:
> > > >
> > > > HTTP/1.1 200 OK\r\n
> > > > Allow: OPTIONS, TRACE, GET, HEAD\r\n
> > > > Content-Length: 0\r\n
> > > > Server: Microsoft-IIS/6.0\r\n
> > > > Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> > > > Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> > > > \r\n
> > > >
> > > > Does this indicate the TRACE is enabled? or Allowed? Which one of
the
> > > above
> > > > two responses supercedes the other?
> > > >
> > > > I am responding back to an audit report and need to confirm this.
> > > >
> > > > Thanks
> > > > Omid
> > > >
> > > >
> > >
> > >
> > >
>
>

Re: Disabling TRACE verb on IIS 6.0

am 18.07.2005 16:40:07 von wadeh

Hi Tiago,

There are a number of core HTTP verbs that are handled by WebDAV. For
example, PUT and DELETE are handled by WebDAV. In the case of these two
verbs, the WebDAV implementation is the only one, and these requests will
fail is WebDAV is not enabled. I was thinking that the same was true of
OPTIONS, but based on your post, I took a look at the code.

My initial response is correct if WebDAV is enabled on the server. As you
suggest, there is more to the answer. When I posted my
off-the-top-of-my-head response, I forgot that we have an OPTIONS handler in
the core web server. If WebDAV is not enabled, then we use this code path.
There is no case where WebDAV and the core server collaborate on building
the Allow header. It's done by WebDAV if it's enabled, or our code if
WebDAV is disabled.

The IIS core code always adds OPTIONS and TRACE, and then it adds others
based on the metadata for the URL. There is no case where it will omit the
OPTIONS handler. The reason for this is probably the same as why I believe
that the WebDAV handler does it. The option to disable TRACE was done very
late in the project. (I think that it may have been the last design change
that we did before RTM.)

Thank you,
-Wade A. Hilmo,
-Microsoft

"Tiago Halm" wrote in message
news:O7SDR0PiFHA.2916@TK2MSFTNGP14.phx.gbl...
> Wade, OPTIONS is a quite core verb of the HTTP protocol.
> However, you state that the OPTIONS request is handled by WebDav?? (and by
> WebDav I would assume its core DLL, httpext.dll). Disabling that DLL
> (unACLing it fully or even deleting it) would then prevent IIS from
> answering OPTIONS?
> I think not.
>
> While I'm not in any way aware of the inner workings of IIS, I would
assume
> OPTIONS is handled by the core of IIS and has a default response. The fact
> that the response always includes all available verbs does not mean they
are
> available or that they are not blocked by any kind of filtering scheme
> running inside the Web Server.
>
> www.microsoft.com is blocking OPTIONS via a filtering scheme.
> However, my IIS6 does not block OPTIONS and answers "OPTIONS, TRACE, GET,
> HEAD, POST" as you would expect it to.
>
> I presume WebDav "adds" some more additional methods like "DELETE, PUT,
> COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH", but these
> "additional" methods should be queried by the IIS core to WebDav's DLL and
> should only be returned if WebDav is "enabled". The "enabled" concept in
> IIS5 is somewhat not defined, but in IIS6 it is defined and works as
> expected.
>
> I am probably mistaken in some statements above in terms of the IIS inner
> workings, but stating that OPTIONS is handled by WebDav is not coherent.
>
> PS: I always find your posts unvaluable, so please take this comment in a
> good sense.
>
> Tiago Halm
>
>
> "Wade A. Hilmo [MS]" wrote in message
> news:u9rP5TOiFHA.2180@TK2MSFTNGP15.phx.gbl...
> > Hi Omid,
> >
> > TRACE handling is disabled by default. It can be enabled by a registry
> key.
> > The following article describes a number of registry keys, and the one
in
> > question is the first on the list:
> >
> >
>
http://www.microsoft.com/technet/prodtechnol/WindowsServer20 03/Library/IIS/d779ee4e-5cd1-4159-b098-66c10c5a3314.mspx
> >
> > As for documentation explaining why OPTIONS lists it, I doubt that
> anything
> > exists for that. My explanation below for why the WebDAV handler
doesn't
> > know about whether TRACE is enabled or disabled is a hypothesis on my
part
> > (but it is a very educated hypothesis.)
> >
> > Thank you,
> > -Wade A. Hilmo,
> > -Microsoft
> >
> > "Omid" wrote in message
> > news:1E5728B8-B687-464A-B413-2DC14A123A45@microsoft.com...
> > > Wade,
> > >
> > > Thanks very much for the info. I have two follow up questiond though:
> > >
> > > 1-I don't recall disabling trace manually, is it disabled by deafult?,
> and
> > > where is the setting for disabling/enabling TRACE in IIS 6.0?
> > >
> > > 2-I need a refernce to a Microsoft KB or any document for that matter
> that
> > > states what you have mentioned here. I am replying back to an audit
> report
> > > that claims TRACE is enabled on my IIS site and need to provide
evidence
> > that
> > > it isn't. To generate their report, they have used some thrid party
tool
> > to
> > > send "OPTIONS" verb to the server.
> > >
> > > Thanks
> > > Omid
> > >
> > > "Wade A. Hilmo [MS]" wrote:
> > >
> > > > Hi Omid,
> > > >
> > > > If making a TRACE request results in a 501, you can say definitively
> > that
> > > > the TRACE verb is disabled.
> > > >
> > > > The reason for the discrepency in the OPTIONS output is that the
> OPTIONS
> > > > request is not handled by the IIS core. It is handled by WebDAV
> (which
> > is
> > > > actually not even produced by the IIS team) and the WebDAV code
> > apparently
> > > > does not recognize the registry setting that disables TRACE. Also,
> the
> > > > functionality to disable TRACE went into the IIS 6 code very late in
> the
> > > > development cycle, so there would have been no opportunity for the
> other
> > > > team to modify WebDAV to account for this.
> > > >
> > > > I hope that this clears up the question for you.
> > > >
> > > > Thank you,
> > > > -Wade A. Hilmo,
> > > > -Microsoft
> > > >
> > > > "Omid" wrote in message
> > > > news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> > > > > I have alraedy posted this on IIS-Security, and since I have not
> > recieved
> > > > any
> > > > > responses, I am posting it here again:
> > > > >
> > > > > Hi,
> > > > > I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS
6.0
> > web
> > > > > server for HTTP TRACE verb. If I send a TRACE verb to my web site,
I
> > > > recieve:
> > > > >
> > > > > HTTP/1.1 Error 501 - Not Implemented
> > > > >
> > > > > which based on KB247643 is an indication of TRACE verb being
> disabled
> > on
> > > > my
> > > > > site, a good sign for my specific requirement.
> > > > >
> > > > > However if I send HTTP OPTIONS verb to the same web site I
receive:
> > > > >
> > > > > HTTP/1.1 200 OK\r\n
> > > > > Allow: OPTIONS, TRACE, GET, HEAD\r\n
> > > > > Content-Length: 0\r\n
> > > > > Server: Microsoft-IIS/6.0\r\n
> > > > > Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> > > > > Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> > > > > \r\n
> > > > >
> > > > > Does this indicate the TRACE is enabled? or Allowed? Which one of
> the
> > > > above
> > > > > two responses supercedes the other?
> > > > >
> > > > > I am responding back to an audit report and need to confirm this.
> > > > >
> > > > > Thanks
> > > > > Omid
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
>
>

Re: Disabling TRACE verb on IIS 6.0

am 18.07.2005 18:25:56 von Tiago Halm

Wade, thanks for the clarification.

In the next IIS release, if not already, I would suggest for the OPTIONS
verb (and any other verb for that matter) to be handled first by the core
IIS for a sanity/availability check purpose. Allowing WebDav to handle it
fully, when its enabled, will give some management headaches given the
development teams are separate. Even having development teams in sync, the
layered approach and sanity/availability check purpose will always be
benificial to detect, pin-point and eliminate any attack/failure vector the
web server may suffer.

The efforts spent on securing IIS should be kept layered just like
introduced with IIS6. When this is the case, the TRACE and similar issues
will no longer be a management/support concern because the development
modularization takes care of it.

Anyway, great having you guys here!

Tiago Halm


"Wade A. Hilmo [MS]" wrote in message
news:%236br2Z6iFHA.2484@TK2MSFTNGP15.phx.gbl...
> Hi Tiago,
>
> There are a number of core HTTP verbs that are handled by WebDAV. For
> example, PUT and DELETE are handled by WebDAV. In the case of these two
> verbs, the WebDAV implementation is the only one, and these requests will
> fail is WebDAV is not enabled. I was thinking that the same was true of
> OPTIONS, but based on your post, I took a look at the code.
>
> My initial response is correct if WebDAV is enabled on the server. As you
> suggest, there is more to the answer. When I posted my
> off-the-top-of-my-head response, I forgot that we have an OPTIONS handler
in
> the core web server. If WebDAV is not enabled, then we use this code
path.
> There is no case where WebDAV and the core server collaborate on building
> the Allow header. It's done by WebDAV if it's enabled, or our code if
> WebDAV is disabled.
>
> The IIS core code always adds OPTIONS and TRACE, and then it adds others
> based on the metadata for the URL. There is no case where it will omit
the
> OPTIONS handler. The reason for this is probably the same as why I
believe
> that the WebDAV handler does it. The option to disable TRACE was done
very
> late in the project. (I think that it may have been the last design
change
> that we did before RTM.)
>
> Thank you,
> -Wade A. Hilmo,
> -Microsoft
>
> "Tiago Halm" wrote in message
> news:O7SDR0PiFHA.2916@TK2MSFTNGP14.phx.gbl...
> > Wade, OPTIONS is a quite core verb of the HTTP protocol.
> > However, you state that the OPTIONS request is handled by WebDav?? (and
by
> > WebDav I would assume its core DLL, httpext.dll). Disabling that DLL
> > (unACLing it fully or even deleting it) would then prevent IIS from
> > answering OPTIONS?
> > I think not.
> >
> > While I'm not in any way aware of the inner workings of IIS, I would
> assume
> > OPTIONS is handled by the core of IIS and has a default response. The
fact
> > that the response always includes all available verbs does not mean they
> are
> > available or that they are not blocked by any kind of filtering scheme
> > running inside the Web Server.
> >
> > www.microsoft.com is blocking OPTIONS via a filtering scheme.
> > However, my IIS6 does not block OPTIONS and answers "OPTIONS, TRACE,
GET,
> > HEAD, POST" as you would expect it to.
> >
> > I presume WebDav "adds" some more additional methods like "DELETE, PUT,
> > COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH", but these
> > "additional" methods should be queried by the IIS core to WebDav's DLL
and
> > should only be returned if WebDav is "enabled". The "enabled" concept in
> > IIS5 is somewhat not defined, but in IIS6 it is defined and works as
> > expected.
> >
> > I am probably mistaken in some statements above in terms of the IIS
inner
> > workings, but stating that OPTIONS is handled by WebDav is not coherent.
> >
> > PS: I always find your posts unvaluable, so please take this comment in
a
> > good sense.
> >
> > Tiago Halm
> >
> >
> > "Wade A. Hilmo [MS]" wrote in message
> > news:u9rP5TOiFHA.2180@TK2MSFTNGP15.phx.gbl...
> > > Hi Omid,
> > >
> > > TRACE handling is disabled by default. It can be enabled by a
registry
> > key.
> > > The following article describes a number of registry keys, and the one
> in
> > > question is the first on the list:
> > >
> > >
> >
>
http://www.microsoft.com/technet/prodtechnol/WindowsServer20 03/Library/IIS/d779ee4e-5cd1-4159-b098-66c10c5a3314.mspx
> > >
> > > As for documentation explaining why OPTIONS lists it, I doubt that
> > anything
> > > exists for that. My explanation below for why the WebDAV handler
> doesn't
> > > know about whether TRACE is enabled or disabled is a hypothesis on my
> part
> > > (but it is a very educated hypothesis.)
> > >
> > > Thank you,
> > > -Wade A. Hilmo,
> > > -Microsoft
> > >
> > > "Omid" wrote in message
> > > news:1E5728B8-B687-464A-B413-2DC14A123A45@microsoft.com...
> > > > Wade,
> > > >
> > > > Thanks very much for the info. I have two follow up questiond
though:
> > > >
> > > > 1-I don't recall disabling trace manually, is it disabled by
deafult?,
> > and
> > > > where is the setting for disabling/enabling TRACE in IIS 6.0?
> > > >
> > > > 2-I need a refernce to a Microsoft KB or any document for that
matter
> > that
> > > > states what you have mentioned here. I am replying back to an audit
> > report
> > > > that claims TRACE is enabled on my IIS site and need to provide
> evidence
> > > that
> > > > it isn't. To generate their report, they have used some thrid party
> tool
> > > to
> > > > send "OPTIONS" verb to the server.
> > > >
> > > > Thanks
> > > > Omid
> > > >
> > > > "Wade A. Hilmo [MS]" wrote:
> > > >
> > > > > Hi Omid,
> > > > >
> > > > > If making a TRACE request results in a 501, you can say
definitively
> > > that
> > > > > the TRACE verb is disabled.
> > > > >
> > > > > The reason for the discrepency in the OPTIONS output is that the
> > OPTIONS
> > > > > request is not handled by the IIS core. It is handled by WebDAV
> > (which
> > > is
> > > > > actually not even produced by the IIS team) and the WebDAV code
> > > apparently
> > > > > does not recognize the registry setting that disables TRACE.
Also,
> > the
> > > > > functionality to disable TRACE went into the IIS 6 code very late
in
> > the
> > > > > development cycle, so there would have been no opportunity for the
> > other
> > > > > team to modify WebDAV to account for this.
> > > > >
> > > > > I hope that this clears up the question for you.
> > > > >
> > > > > Thank you,
> > > > > -Wade A. Hilmo,
> > > > > -Microsoft
> > > > >
> > > > > "Omid" wrote in message
> > > > > news:65F1407C-22C4-4BA0-B7DE-FEB4F4A58822@microsoft.com...
> > > > > > I have alraedy posted this on IIS-Security, and since I have not
> > > recieved
> > > > > any
> > > > > > responses, I am posting it here again:
> > > > > >
> > > > > > Hi,
> > > > > > I am using IIS 6.0 resource kit "Wfetch" utility to check my IIS
> 6.0
> > > web
> > > > > > server for HTTP TRACE verb. If I send a TRACE verb to my web
site,
> I
> > > > > recieve:
> > > > > >
> > > > > > HTTP/1.1 Error 501 - Not Implemented
> > > > > >
> > > > > > which based on KB247643 is an indication of TRACE verb being
> > disabled
> > > on
> > > > > my
> > > > > > site, a good sign for my specific requirement.
> > > > > >
> > > > > > However if I send HTTP OPTIONS verb to the same web site I
> receive:
> > > > > >
> > > > > > HTTP/1.1 200 OK\r\n
> > > > > > Allow: OPTIONS, TRACE, GET, HEAD\r\n
> > > > > > Content-Length: 0\r\n
> > > > > > Server: Microsoft-IIS/6.0\r\n
> > > > > > Public: OPTIONS, TRACE, GET, HEAD, POST\r\n
> > > > > > Date: Tue, 12 Jul 2005 17:12:21 GMT\r\n
> > > > > > \r\n
> > > > > >
> > > > > > Does this indicate the TRACE is enabled? or Allowed? Which one
of
> > the
> > > > > above
> > > > > > two responses supercedes the other?
> > > > > >
> > > > > > I am responding back to an audit report and need to confirm
this.
> > > > > >
> > > > > > Thanks
> > > > > > Omid
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
> >
>
>