The problem could happen also if a CL is sent and not enough data is
posted. So i don't think control for complete headers will solve the
entire problem. I'm actually playing with dynamic timeout considering
time between request line and first header to adapt future timeout of
the socket, but it will remain a possible attack between request line
and first incomplete header. The second possible counter mesure is to
increment a per ip counter for waiting connexions (in connection filter,
inc before ap_get_brigade, dec after getting it). If there is too much
connexion at waiting state from the same ip, the ip is blacklisted. The
aim is to differentiate waiting connexion than working connexion. A
separate thread could also check a socket list to see when was the
latest data and kill it if there is too much waiting connexion from the
same ip... But all of this will add some lock and performances issues :(


Graham Leggett wrote:
> Dirk-Willem van Gulik wrote:
>> So what we did in the mid '90 when we where hit by pretty much the same
>> was a bit simpler - any client which did not complete its headers within
>> a a few seconds (or whatever a SLIP connection over a few k baud or so
>> would need) was simply handed off by passing the file descriptor over a
>> socket to a special single apache process. This one did a very single
>> threaded async simple select() loop for all the laggards and would only
>> pass it back to the main apache children once header reading was
>> complete. This was later replaced by kernel accept filters.
> Are kernel accept filters widespread enough for it to be reasonably
> considered a generic solution to the problem? If so, then the solution
> to this problem is to just configure them correctly, and you're done.
> Regards,
> Graham
> --

Reply via email to