lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 10 Jan 2007 10:04:03 +0000
From: bugtraq <>
Subject: Re: a cheesy Apache / IIS DoS vuln (+a question)

On Tue, Jan 09, 2007 at 12:15:02AM -0600, William A. Rowe, Jr. wrote:
> bugtraq wrote:
> > 
> > a quick fix for this can be available at least on bsd, there is accf_http 
> > that can be modified not to pass the connection to apache until a full request
> > is read (either get or post, full, not just the first get request header, 
> > of course this can be even worst for a lot of post data).
> For what it is worth, Apache 2.2.x and later introduce support for http accept()
> filtering on platforms which support httpfilter.  Since Apache 2.0.x, AcceptEx
> is supported on Win32 to pend accept() for at least the initial request payload.
> Of course this is not without some resource utilization for the incomplete
> request payloads, but at least it does offload the resources from the web
> server itself to the kernel socket layer.

1. apache does support socket level filtering but u must have the right code for every kind of attack. e.g. a default http accept filter on (free)bsd will just wait for the_request header. after that the web server will face the same problem. only delayed. ofcourse that filter should be seen more like an example
2. you get to fight again when sending the data - attacker wouldnt close the socket, but will slow down the read filling netbufs on server  side 
3. you have no chance to identify the bots without learning traffic patterns before ... 

offtopic, you can even use tor network - until one point (which?)  those *are* legit requests and tor network is slow enough to simplify the schedulers on attacker side :)
and i dont know how easy can be to proove attacker's guilt at the *real* value

not saying this is a big problem for everyone, but for most of the people it is and antiddos business sharks just waitin for the occasion to eat you more painful and prolly faster than attacker :P

> Bill

adrian ilarion ciobanu (cia)

Powered by blists - more mailing lists