Block IP addresses that trigger repeated ModSecurity warnings?

Laz

Registered
Jun 18, 2018
1
0
1
United Kingdom
cPanel Access Level
Root Administrator
Hi there,

I am trying to block repeated ModSecurity alerts from IP addresses under the OWASP CRS in CSF. However, I have been informed that any rules classed as a warning will not be considered by CSF as qualifying for the LF_MODSEC=5 configuration rule.

Here is an old example that was run about a dozen times without being triggered by LF_MODSEC=5:

Code:
Message: Warning. Pattern match "(?i:(?:\\s*?(?:exec|execute).*?(?:\\W)xp_cmdshell)|(?:[\"'`]\\s*?!\\s*?[\"'`\\w])|(?:from\\W+information_schema\\W)|(?:(?:(?:current_)?user|database|schema|connection_id)\\s*?\\([^\\)]*?)|(?:[\"'`]$
Stopwatch: 1497396385997298 1338 (- - -)
Stopwatch2: 1497396385997298 1338; combined=716, p1=202, p2=406, p3=22, p4=68, p5=18, sr=34, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.0 (http://www.modsecurity.org/); OWASP_CRS/3.0.0.
Server: Apache
Engine-Mode: "ENABLED"
Is there anyway to set CSF to block IP addresses that trigger repeated ModSecurity warnings across all rulesets? As CSF currently allows these warnings to trigger countless times without taking any firewall actions.

I am fairly new to ModSecurity, so I apologise if I am going about this the wrong way; any help will be greatly appreciated.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
Hi @Laz

You can change the way ModSecurity behaves in a few different ways. You can modify
Code:
/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/crs-setup.conf
to change the Anomaly Mode Blocking Threshold Levels:

Code:
# -- [[ Anomaly Mode Blocking Threshold Levels ]] ------------------------------
#
# Here, you can specify at which cumulative anomaly score an inbound request,
# or outbound response, gets blocked.
#
# Most detected inbound threats will give a critical score of 5.
# Smaller violations, like violations of protocol/standards, carry lower scores.
#
# [ At default value ]
# If you keep the blocking thresholds at the defaults, the CRS will work
# similarly to previous CRS versions: a single critical rule match will cause
# the request to be blocked and logged.
#
# [ Using higher values ]
# If you want to make the CRS less sensitive, you can increase the blocking
# thresholds, for instance to 7 (which would require multiple rule matches
# before blocking) or 10 (which would require at least two critical alerts - or
# a combination of many lesser alerts), or even higher. However, increasing the
# thresholds might cause some attacks to bypass the CRS rules or your policies.
#
# [ New deployment strategy: Starting high and decreasing ]
# It is a common practice to start a fresh CRS installation with elevated
# anomaly scoring thresholds (>100) and then lower the limits as your
# confidence in the setup grows. You may also look into the Sampling
# Percentage section below for a different strategy to ease into a new
# CRS installation.
There's also paranoia levels that can be increased to implement further sensitivity. Keep in mind though this is broad and affects all rules not specific rules. For information and help customizing the specific rules/rulesets you might want to take a look at their mod-security-users mailing list here ModSecurity: Download Code

Thanks!