3 ms·
Any idea if "accept filters" will help mitigate this attack? See "man accf_http" on FreeBSD; not sure what the equivalents for other operating systems may be.
by SageRaven 16y ago
Any idea if "accept filters" will help mitigate this attack? See "man accf_http" on FreeBSD; not sure what the equivalents for other operating systems may be.
I know that varnish, Apache, and nginx support this feature. Speaking of... does having a reverse proxy like varnish help in these kinds of attacks?
- peterwwillis 16y agoActually I wasn't aware of such a feature, it's kind of neat. But no, that won't help with this attack (the filter works only on HEAD and GET methods, and this attack is about the content after a POST). It looks like this filter deals with reducing the CPU required to handle the request portion of an initial HTTP connection. I suppose this could help with preventing the server from being starved of resources for an attack on solely transmitting an HTTP request, but that could be mitigated by a 5 or 10 second timeout on getting a HEAD/GET request from the client initially (which should be reasonable even for dial-up and mobile connections). And I personally haven't ever seen a DoS attack on a proxy layer that ate up more CPU than any other resource, so I don't see this filter as being a significant advantage over the basic tuning you can do with connections on the proxies. Oh, and as tptacek mentioned, a reverse proxy like varnish can definitely help in different DoS scenarios. I haven't used varnish in the real world so I can't speak to specific advantages, but in general, dedicated reverse proxies are a great way to offload initial processing, provide more resources for a high number of connections and deal with host-level attack mitigation so the app servers don't have to waste time on it.