httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Purl Gurl <>
Subject Re: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed In 1.3.31 Or Not?
Date Mon, 17 May 2004 17:02:37 GMT
Ben Chabot wrote:

> Sorry to reply to this message, it's really to Kira.

You are casting me as a "bad guy" which is inappropriate.

Use of Ad Hominem, which is so typical of the ignorant,
only serves to annoy me and serves to encourage me to
be more admanant in excercising my freedom of opinion.

I am here to discuss and learn. I am not here to present
myself an easy target for the ignorant.

> At any rate, Kira, you are logging hack attempts, yet you want to shut
> off logging of the IIS webdav exploit (or so it seems).

As disclosed in many discussions, here and elsewhere, it is impossible
to "shut off" logging of Webdav exploits via Apache. This is a well
known bug although denied by many.

I am miffed by selected people who claim this is not a bug,
and in subsequent conversation, labeled this a bug. Some
do not keep track of what they write.

Only cure is piped logging which requires additional system
resources and memory hogging software.

Parsing logs after injury, is possible but presents serious
problems such as having to shut down Apache before parsing
so not to lose current data not yet flushed by Apache.

> there is a similar exploit that works and you aren't logging it?  It's a
> good idea to log it all, today those logs might be useless, but it's
> hard to say what will be useful in the future.

Log all thrity-thousand bytes of the WebDav entry or the default
eight-thousand plus bytes? Why? I only need to see "SEARCH" in
the request to know it is WebDav and to know this method should
not be allowed. Why log kilobytes of garbage? Why allow request
methods which are not valid?
> That being said, why don't you grep the SEARCH line out of the logs?

I do this, which is a waste of system resources. Yes, this places
a Band-Aid on the wound but does not cure the source of injury.

> Or, I'm not sure about this, but perhaps you could install snort,

Yes, I use SNORT. However, SNORT is a passive system and may or may
not intervene, depending on platform, hooking of lan cards and
other factors. For many case examples, SNORT is useless because
Apache does not allow ip blocking for some request methods.

SNORT, like Apache, is excellent software. Do not misunderstand
what I write. I am saying, for some circumstances, both Apache
and SNORT become useless because of bugs or limitations. This
is quite common. Nonetheless, some of these bugs can be fixed.

Again yes, you can capture these exploits via sniffing, via
IDS software, such as SNORT. However, many find nothing can
be done to prevent these problems; you know about the problems
and know you are defenseless.

Hooking lan cards is very challeging and is supported on only
specific platforms, such as Linux and NT5. In most cases, a
person is required to establish a stand-alone machine to act
as a transparent firewall or NAT translating machine. In other
cases, a stand-alone server machine can handle all needed
functions adequately, but at a serious system resource cost.

Our family webserver is currently spread out over three machines.
I really don't want to buy more machines to cure a problem which
could be easily cured by Apache, if those bugs did not exist.

Thanks for your input, it is valuable to all readers. Many will
investigate your suggestions and learn. Once many have learned
the true and factual nature of these problems, then resolution
methods will be presented. While readers adamantly claim these
are not problems, no resolution will ever be offered, a classic
display of the Ostrich Syndrome.


The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message