httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Herb Stein" <>
Subject RE: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed In 1.3.31 Or Not?
Date Tue, 18 May 2004 02:25:16 GMT
> -----Original Message-----
> From: Purl Gurl []
> Sent: Monday, May 17, 2004 12: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.

You're married to Fraiser, right?

> > 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:

Herb Stein
The Herb Stein Group, Inc.
314 952-4601

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