ModSecurity DoS protection on IIS

We require a DoS protection on our web site that is running on IIS, so we decided to try out ModSecurity. We installed ModSecurity 2.9.2 with OWASP CRS 3.0.2. After doing a bit of digging we opted to set PL to level 3. Now, at this PL if the burst counter (IP:DOS_BURST_COUNTER) is greater equal 1, then the blocking flag is being set (IP:DOS_BLOCK). The blocking flag (IP:DOS_BLOCK) expires within a timeout period (TX:DOS_BLOCK_TIMEOUT).

We didn't change the default values, but, anyway, here they are:

SecAction \
 "id:900700,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.dos_burst_time_slice=60',\
  setvar:'tx.dos_counter_threshold=100',\
  setvar:'tx.dos_block_timeout=600'"

The issue is that by default ModSecurity is trying to drop connection which, as it say in wiki, "is currently not available on Windows based builds.". So, it floods the EventLog with messages like "ModSecurity: Access denied with code 500 (phase 1) (Error: Connection drop not implemented on this platform. Operator EQ matched 1 at IP:dos_block." which is unacceptable for us and returns code 500 which is not expected behavior.

We tried to overwrite the action by adding these rules:

SecRuleUpdateActionById 912120 "t:none,deny,status:403"
SecRuleUpdateActionById 912130 "t:none,deny,status:403"

However, in this case the first request from a user is always blocked returning status 403. The following request is fine though.

So, is there a way to set up DoS protection on IIS the way it doesn't flood the EventLog and block the first user request?

[victorhora]

@AnryCryman

It might be due to the fact that 912120 contains a chain action.

See note at SecRuleUpdateActionById: "Note : If the target rule is a chained rule, you must currently specify chain in the SecRuleUpdateActionById action list as well. This will be fixed in a future version."

Try adding the chain action to your SecRuleUpdateActionById directive.

Yeah, that worked. Thanks for the help.

[tbsmello]

@AnryCryman

It might be due to the fact that 912120 contains a chain action.

See note at SecRuleUpdateActionById: "Note : If the target rule is a chained rule, you must currently specify chain in the SecRuleUpdateActionById action list as well. This will be fixed in a future version."

Try adding the chain action to your SecRuleUpdateActionById directive.

I´m with the same problem of AnryCryman.
How to add chain in 912120 rule?

BR.,
Thiago