Modsecurity block 31102

[jbourque]

As of Friday 10/18 I have had a problem with the latest updates my clients are getting blocked and I can't tell what is triggering the modsecurity block 31102.

I had to turn off the rule to stop the blocks of legitimate clients to include myself.

warn] ModSecurity: Access denied with code 400. Too many threads [11] of 10 allowed in READ state from 70.198.x.x - Possible DoS Consumption Attack [Rejected

I tried to report the false positive then it said Modsecurity was out of date so I ran aum -u, but I I'm unable to report the issue and since turning off the rule I still get the warnings.

Any thoughts are help would be great.

Joe

[mikeshinn]

Thanks for the question, the documentation on that rule should answer any questions you may have:

https://www.atomicorp.com/wiki/index.php/HIDS_31102

If you have any other questions after reading that article, please let us know. We'd be happy to answer them.

[jbourque]

Mike,

I did read that article, I never had this problem until this weekend. One of my websites was not getting visitors almost all my visitors were getting blocked this weekend and I don't know why, over the past month we had over 27k visitors until this weekend all the traffic stopped due to the blocks.

I had to disable to fix it.

[mikeshinn]

I had to disable to fix it.

If I understand you correctly, you disabled rule 31002? If so, disabling that rule will not prevent the limit from being exceeded. That rule just reports when the limit is exceeded, it does not enforce it. Please see the documentation if you are unsure:

https://www.atomicorp.com/wiki/index.ph ... _Positives

Disabling this rule will not prevent this event from occurring, it will just prevent ASL from alerting you that this is occurring, and optionally from shunning the IP address that is causing this event

We do not recommend you disable this rule. If you do not wish to shun on this rule, just change the Rules configuration for Active Response to "no". See below for tuning guidance if the default READ state limit is too low for your system.

What you probably want to do is increase the limits, as described in the tuning guidance:

https://www.atomicorp.com/wiki/index.ph ... g_Guidance

This limit is configured by this setting:

https://www.atomicorp.com/wiki/index.ph ... STATELIMIT

I never had this problem until this weekend.

That rule is about a year old. So it sounds like your users are just hitting the server with more, slower READ requests. As described in the documentation on the rule, you can increase that limit. I would not recommend you set it above 100.