httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chabot" <>
Subject RE: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed In 1.3.31 Or Not?
Date Mon, 17 May 2004 17:29:02 GMT
> Why allow request methods which are not valid?

As far as I understand, it does not "allow" these methods.  It merely
logs the attempt.  Which is the wise thing to do.  Not logging hits that
come against your server is not a good idea.  I don't see why the option
should even be in apache.  Even if you log just a shortened version, you
don't know if it's just the old annoying IIS webdav exploit, or
something new, and you haven't logged it so you can't look and see.  

I don't think it's a "bug fix" to mangle httpd so it doesn't log certain
connection attempts according to your personal tastes.

Just filter your logs and stop worrying about system resources.  Are you
really topped out to the point that running a script hourly or daily is
going to break you?  How about rotating your logs when they get to a
certain size?  You are using webalizer anyway, so processing log files
(instead of forcing apache to do it) is the reasonable thing to do, and
can't be any more intensive than some of the log analyzation you are
doing anyway.

And it's not a "band-aid" fix for a broken apache... apache does exactly
what it's supposed to do, afaik, which is log all connection attempts.
Like someone said, if it wasn't SEARCH filling your logs, it would be
tons of long GET requests.  Anything can fill the logs, this is not a
bug.  I suppose if you get 20M of GET requests in a day, you'll want to
mangle apache so it won't log those either?  Bah... filter your logs and
move on.

But I'm done... Just my two cents... a word of advice, rather than
arguing, why don't you patch apache now, and release the patch for
people who want to use it?  Or write a perl script to filter your logs.
It would probably be a lot more productive than insulting people who are
only trying to make helpful suggestions. (I'd be ecstatic if someone
gave me a helpful suggestion *hint* HEH).


> -----Original Message-----
> From: Purl Gurl [] 
> Sent: Monday, May 17, 2004 1:03 PM
> To:
> Subject: Re: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed 
> In 1.3.31 Or Not?
> Ben Chabot wrote:
> (snipped)
> > 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.
> Kira
> ---------------------------------------------------------------------
> 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:

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