Move IP reputation rules to separate plugin

Motivation

The IP reputation rules could potentially be moved to a separate plugin instead of being part of standard CRS.

Proposed solution

The 910 rules as well as the rule 949100 could be moved to a separate plugin. In that case, rule 949100 could even become a 910 rule. This would also affect the configuration and initialization variables associated with these rules.

The variables containing the necessary flags, would still need to be part of CRS as they are set by other CRS rules.

Alternatives

Keep them in CRS but refactor these rules to better fit into CRS and add tests to ensure they are working properly.

Additional context

• The IP reputation rules have GeoIP dependencies that are not required for the rest of CRS, particularly rule 910100.
• The IP reputation rules in general use a separate blocking mechanism in 949100 to do reputation-based blocking, which is turned off by default.
• The IP reputation rules 910100 and 910000 both also increase the anomaly score. However, in the case of rule 910000, this is useless as it is only increased in case TX:DO_REPUT_BLOCK is turned on, in which case regular CRS blocking based on the anomaly score is circumvented in favor of blocking immediately with rule 949100.
• There are no regression tests to verify these rules are working properly.

[dune73]

In the case of DoS I see performance reasons. They do not apply with the rest of the stuff and I take it is more historical. CRS3 was the first version that really pushed anomaly scoring as default, but we did not really touch these rules for said release.

And there is nothing wrong with a plugin blocking directly, it’s just that it does not integrate with CRS that much technically afterwards (which does not rule out it being a CRS plugin from my perspective).

[studersi]

This would actually be more complicated than expected to move to a plugin.

Aside from the basic blocking mechanism and the variables used for that (i.e. do_reput_block, reput_block_duration), there are other variables set by other CRS rules (i.e. reput_block_flag, reput_block_reason).

Considering that the IP reputation flags are exclusively used in REQUEST-913-SCANNER-DETECTION.conf, the plugin could potentially update the actions of the scanner rules as follows using SecRuleUpdateActionById, however I have never tried this:

SecRuleUpdateActionById 913000-913999 "'setvar:'ip.reput_block_flag=1',setvar:'ip.reput_block_reason=%{rule.msg}',expirevar:'ip.reput_block_flag=%{tx.reput_block_duration}'"