I've been testing mod security against dos attacks using the persistent collections to track IPs with our own custom rules that track request hit rates down to the uri level but have hit bump in the road with a small problem.
From what I understand, collections are persisted at at the end of each transaction, ie after the response body has been generated. In a scenario where a response takes a few seconds to be generated after the request has been received (due to heavy data processing), I could fire off a whole lot of identical requests concurrently in those few seconds and actual number of request would burst the thresh hold but not blocked until at a certain count above the threshold, depending on how low the thresh hold was set. Analyzing the debug and audit logs, I worked out that when the collections are retrieved from the database for each concurrent request (in phase 1), the counter value read from storage for each concurrent request is the same, since no responses have yet to be generated in that first few seconds that would lead to collections being persisted.
Is there a way around this? We've been using mod-evasive but we've observed the weakness mentioned by Ryan Barnett in this thread http://article.gmane.org/gmane.comp.apache.mod-security.user/9251
. Obviously, one solution would be to speed up the response time but we would also like to have a way to correctly track requests rates in these type scenarios while optimizations are being done.
I've looked at the crs dos protection rules but I think it would also hit this problem.
Any advise would be appreciated.