Ruben de Groot 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. > >> infrequent, always include extra trailing data after the headers, and end >> up doing more processing at the server end than plain GET or HEADs, so >> buffering the first line of the request doesn't really help much. > > Well, it helps against this slowloris script. And I don't see it costing > much. > >> You're better off adding a request-max-time limit to your webserver, or >> doing random-drops of existing connections if you get close to your fd or >> thread limit. > > I'm exploring these options as well, but they have their own drawbacks. > > Anyway, since it doesn't look like I'm breaking anything by buffering the > POST headers, I'm gonna maintain this as a local patch until something > better comes along. >
I was interested to follow this, as I was under the impression http accept filter was more for performance rather than security. Since I use it anyway I was happy to learn of these facts. Although not directly related, per se, you may also be interested in: http://www.modsecurity.org/projects/modsecurity/apache/index.html It can be useful in narrowing the scope of allowable POST content to mitigate SQL injection techniques. The default pattern is overly broad but if you are only intent on tightening up one web app on one server it is possible to tune it to be more specific. Not a magic bullet, but every layer in the onion helps. -Mike _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
