httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chabot" <vo...@amninc.net>
Subject RE: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed In 1.3.31 Or Not?
Date Mon, 17 May 2004 16:23:54 GMT
Sorry to reply to this message, it's really to Kira.

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).  What if one day
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.

That being said, why don't you grep the SEARCH line out of the logs?  Or
rotate your logs?  Or link you logs to /dev/null (heh).  A google search
will tell you how to do these things.

Or, I'm not sure about this, but perhaps you could install snort, with
an active response rule, intercept and respond to the traffic before it
hits apache?  I'm far from an expert, a newbie really, but it seems out
of place for apache to even have an option to not log certain things.
It's job is to log everything, all exploit attempts.  If you don't find
some of the information useful, it's your job to filter it out, rather
than implementing some complex filter inside apache... it's a webserver,
not a log filter.

Now... anyone read my "suexec w/chroot + shared ssl" problem?  Or do I
need to make a bug report?  (Hehehe, kidding.)

Ben

> -----Original Message-----
> From: Joshua Slive [mailto:joshua@slive.ca] 
> Sent: Monday, May 17, 2004 12:11 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] Re: Bug Versions 1.3.28/29 Fixed 
> In 1.3.31 Or Not?
> 
> 
> 
> [I'm sorry to reply again.  I suggest most people simply ignore this
> thread.  I just can't let false information stand unchallenged.]
> 
> On Mon, 17 May 2004, Purl Gurl wrote:
> > This WebDav bug, I have doubts Apache will ever address
> > this bug. It is a bug because Apache allows "any" request
> > method, and should not. Request methods should be limited
> > to only those actually in use. Other supporting evidence
> > for this being a bug is ip blocking is disabled for
> > request methods; Apache hooks this before ip blocking.
> > Additionally, Apache writes the WebDav garbage to a
> > log file and does not allow an administrator to parse
> > before it is written.
> >
> > In short, WebDav script kiddies have complete control
> > over Apache. This is inexcusable.
> 
> False.  The only thing script kiddies can do is cause log 
> entries to be
> written, and they can do that lots of different ways.
> 
> > Why this is inexcusable is WebDav idiots can send in this
> > hack at a rate of one per second, around the clock, and
> > suffer no consequences. Requests at one per second is not
> > a sufficient rate to kick in preventative denial of service
> > functions. A script kiddie can pump log records at a rate
> > of eight kilobytes per second, with no effort. Apache
> > claims this is not a problem. I strongly disagree.
> 
> If you were somehow able to magically prevent SEARCH 
> requests, the exact
> same attack would be possible with GET requests.  There is absolutely
> nothing apache can do to prevent people from sending huge 
> requests to the
> server.  This is part of being on the Internet.  What apache can do is
> deal with those requests in the most efficient and expedient way: deny
> them immediately and do no further processing (other than logging).
> 
> If your log file can't handle requests of this size, you 
> better reduce the
> value of LimitRequestLine in httpd.conf.  That will prevent the
> logfile-growing-too-quickly problem.
> 
> > True problem here is Apache does not allow hooking in a
> > module to address those request methods which are handled
> > by Apache's frontend, well before administrative methods.
> 
> It is true that this is a missing feature.  But it is missing 
> by design
> choice.  If a request is malformed, then it would be a 
> possible security
> hazard to let it go through all the normal processing.  So it 
> is simply
> denied and logged.  Now, with the present apache 
> architecture, this means
> the only way to prevent the logging is with a piped-log 
> program.  But as
> I've said, I don't see that as a significant flaw.
> 
> > In summary, Apache affords no method to deal with request methods
> > which generate an error return response. This causes serious
> > problems for administrators, problems which are exceptionally
> > well documented, despite being denied by Apache Org.
> 
> False again.  It is only very specific error responses that 
> short-circuit
> normal processing: those caused by malformed requests.  And the only
> "problem" this causes is logfile lines, which most people WANT to have
> in order to monitor their server.
> 
> Joshua.
> 
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP 
> Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>    "   from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
> 


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message