the bubble: everyone is vulnerable. well at least one year ago (or something) every kind of http server was.
the bug: there is no bug. this is one of the flaws we live with that would require on-the-fly fixes (by sysadmin). im not sure how this became a news headline. ah wait. i also remember the "dns exploit" that was (re-)"discovered" and "fixed" by cisco,microsoft and some john doe. i also remember djb telling them ages before about it - and ofcourse providing the fix as well. but no one heard about it until the companies decided they're ready to make some profit from it. open your eyes, people.
the glitch: there is. a quite-general fix was described above by someone (killing the oldest unfinished requests) but on a heavy attack this could also kill legit requests. one should really customize a tcp pattern-based filter depending on the attack combined with safe application layer rules.
p.s.
the "timeout" settings are useless. you can fingerprint that and force timeout resets on the server side with minimum bandwidth consumptions. see an old article with source code, etc (i think you need to fix a small compilation error to be able to use it): http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html
Slashdot Mirror
the bubble: everyone is vulnerable. well at least one year ago (or something) every kind of http server was. the bug: there is no bug. this is one of the flaws we live with that would require on-the-fly fixes (by sysadmin). im not sure how this became a news headline. ah wait. i also remember the "dns exploit" that was (re-)"discovered" and "fixed" by cisco,microsoft and some john doe. i also remember djb telling them ages before about it - and ofcourse providing the fix as well. but no one heard about it until the companies decided they're ready to make some profit from it. open your eyes, people. the glitch: there is. a quite-general fix was described above by someone (killing the oldest unfinished requests) but on a heavy attack this could also kill legit requests. one should really customize a tcp pattern-based filter depending on the attack combined with safe application layer rules. p.s. the "timeout" settings are useless. you can fingerprint that and force timeout resets on the server side with minimum bandwidth consumptions. see an old article with source code, etc (i think you need to fix a small compilation error to be able to use it): http://pub.mud.ro/~cia/computing/apache-httpd-denial-of-service-example.html