Response rules are running with 'SecResponseBodyAccess Off'

[noloader]

I help maintain the Crypto++ library. Our online manual is at https://www.cryptopp.com/docs/ref/. ModSecurity is blocking some of the pages served from the manual, like the documentation for our Base64 classes. The Base64 decoder docs are at https://www.cryptopp.com/docs/ref/class_base64_decoder.html.

We turned off response scanning with SecResponseBodyAccess Off, but response rules are still running and blocking the manual pages.

My apologies if I misunderstand how to disable outbound scanning. We consider our static pages as trusted, so they don't need scanning when served to a client.

Logs and dumps

With ModSecEngine On and SecResponseBodyAccess Off, I get an access denied for the Base64 decoder documentation. Our error.log has the following entry. Notice the response rule RESPONSE-980-CORRELATION is running and blocking the documentation page.

[Sun Apr 04 22:11:34.901355 2021] [:error] [pid 3177] [client 71.179.5.32:51931]
 [client 71.179.5.32] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_
anomaly_score. [file "/usr/share/modsecurity-crs/rules/RESPONSE-980-CORRELATION.
conf"] [line "86"] [id "980130"] [msg "Inbound Anomaly Score Exceeded (Total Inb
ound Score: 5 - SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=5,HTTP=0,SESS=0): individual
 paranoia level scores: 5, 0, 0, 0"] [tag "event-correlation"] [hostname "www.cr
yptopp.com"] [uri "/docs/ref/class_base64_decoder.html"] [unique_id "YGo5lvoRia9
njOk1io5PIwAAAAE"], referer: https://www.cryptopp.com/docs/ref/annotated.html

To Reproduce

Navigate to https://www.cryptopp.com/docs/ref/class_base64_decoder.html.

Expected behavior

Unimpaired access to the web page.

Here's a copy of the page from the Wayback machine: https://web.archive.org/web/20160821004853/https://www.cryptopp.com/docs/ref/class_base64_decoder.html.

Server:

Ubuntu 20.04, x86_64, fully patched:

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

ModSecurity version:

# apt-cache show libapache2-mod-security2
Package: libapache2-mod-security2
Architecture: amd64
Version: 2.9.3-1
Priority: optional
Section: universe/httpd
Source: modsecurity-apache
Origin: Ubuntu
...

Webserver version:

# apt-cache show apache2
Package: apache2
Architecture: amd64
Version: 2.4.41-4ubuntu3.1
Priority: optional
Section: web
Origin: Ubuntu
...

Rule Set:

No public or commercial rule sets. Just the stuff that Ubuntu 20 provides, which is the default ModSecurity gear.

Additional context

None.

[zimmerle]

Hi @noloader,

According to the log message you have OWASP CRS enabled. The OWASP CRS is asking ModSecurity to block the request. It is likely that you have a second SecResponseBodyAccess entry that is enabling the request body in your system. Have a look at your configuration to see if you have this second entry.

[zimmerle]

Related to #2465

[noloader]

Thanks @zimmerle,

It looks like SecResponseBodyAccess is Off:

# grep -IR SecResponseBodyAccess /etc
/etc/modsecurity/modsecurity.conf:# SecResponseBodyAccess On
/etc/modsecurity/modsecurity.conf:SecResponseBodyAccess Off
/etc/modsecurity/modsecurity.conf-recommended:SecResponseBodyAccess On

[airween]

@noloader there is no correlation: SecResponseBody Off means that the affected variables (eg. RESPONSE_BODY) will empty for rules which uses. See the reference.

The rules will be evaluated always (if there is no any exception), you can't control it with this directive - and this is the normal behavior.

The referenced issue (2465) describes a wrong behavior in case of modsecurity3.

Based on the attached log: looks like the triggered rule is the 980130. This rules checks the INBOUND_ANOMALY_SCORE. This score incremented in phases 1 and 2, while the engine analyzes the request, not the response. Check your log, you will find all triggered rules, and you can make few exceptions to avoid this behavior.

Perhaps this is a CRS issue, not ModSecurity.

[noloader]

Thanks @airween,

So I'm not sure what to do now.

We installed and enabled ModSecurity, and we started having problems serving pages. We tried to turn off outbound scanning because our pages are static and trusted. The pages are still being scanned.

At this point we've disabled ModSecurity. We can't have it DoS'ing our site.

Do you have any other suggestions?

[airween]

Do you have any other suggestions?

Please close this issue, and open a new one here. Please fill the issue template carefully: share all relevant info, but don't forget to anonymize it.

You can set the engine to detect the attacks but don't block them with SecRuleEngine DetectOnly - in that case all rule will evaluated, and you will have the necessary log entries.