IP.block set by a variety of rules in 910 and 913, leads to unconditional block in 949100

_Issue originally created by user dune73 on date 2016-08-12 08:28:23. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/514._

949100 block unconditionally if ip.block is set. ip.block is set by various rules in 910 and 913 regardless of scoring or blocking policy or any other setting in crs-setup.conf.

We need to discuss this blocking-on default policy for IP repudiation. And we need to describe an opt-out mechanism. At least. In fact I think we need far more documentation for this.

Personally I would prefer if we had a default repudiation-blocking=off policy by default. People will raise their anomaly thresholds to test out the CRS and then surprisingly get arbitrary blocks on bad behaviour of individual clients. This gives a scary feeling.

[CRS-migration-bot]

User dune73 commented on date 2016-09-15 12:55:42:

Here is a brief overview on the use of IP.block:

READS:
        910000  Skip based on ip.block
        949100  BLOCK: Request Denied by IP Reputation Enforcement 

SETS:
        910100  High risk country
        910110  IP Blacklist (commented out) Trustwave SpiderLabs
        910150  HTTP Blacklist match for search engine IP based on tx.block_search_ip
        910160  HTTP Blacklist match for spammer IP based on tx.block_spammer_ip
        910170  HTTP Blacklist match for suspicious IP based on tx.block_suspicious_ip
        910180  HTTP Blacklist match for harvester IP based on tx.block_harvester_ip
        913100  Found User-Agent associated with security scanner
        913110  Found request header associated with security scanner
        913120  Found request filename/argument associated with security scanner
        913101  Found User-Agent associated with scripting/generic HTTP client
        913102  Found User-Agent associated with web crawler/bot

[CRS-migration-bot]

User dune73 commented on date 2016-09-19 12:19:17:

Closing this in favor of PR #580.