On Tue, Jun 23, 2009 at 05:23:19PM +0200, Fabian Keil typed: > Ruben de Groot <mai...@bzerk.org> wrote: > > > On Mon, Jun 22, 2009 at 05:35:56PM -0500, Dan Nelson typed: > > > In the last episode (Jun 22), Ruben de Groot said: > > > > > > > > My main concern here is if applying the trivial patch I posted would > > > > break anything in the http protocol layer. And if not, why isn't the > > > > POST method included in the http accept filter in the first place? > > > > > > The filter wasn't designed to be an anti-DOS tool; it was an > > > optimization to save some context switches at the beginning of every > > > request. POSTs are > > > > I know this. But in this particular case, it *works* as an anti-DOS > > tool. And a pretty good one too. > > How did you verify this?
By using the slowloris script against my own servers. Running the script from a single client pc: ./slowloris.pl -dns myserver.domain.tld -port 80 -timeout 2000 -num 500 -tcpto 5 -httpready brings apache to its knees. No more connections are accepted as there are allready MaxClients processes running (150) and they're all just sitting there waiting. With accf_http just slightly adjusted as posted, nothing happens at all. Apache just doesn't see the connections, even with multiple clients running the DOS. (Off course, there'll be memory buffers in the kernel filling, but from that I haven't seen any negative side effects yet) > accf_http doesn't require a complete request but will also > pass the connection to the userland if its buffer is full. Haven't seen that, but it sounds sane. > If you continue to send headers that will happen eventually and if > you're impatient, you simply have to send a bit more headers at the > beginning to reach the application faster. Yes. A real and prolonged DDOS is hard to counter. And the accept filter was not designed for that. It was just an observation about this particular script. cheers, Ruben _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"