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 :(
Matthieu 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 > --
