In Progress ZC-11209 - ModSec custom rules lost after Leapp upgrade

[gramzon]

After upgrade from CentOS 7 to RockyLinux 8 I am getting this hit in modsec blocking some applications from submitting login request to my backend.


Message: Warning. Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "440"] [id "920420"] [rev "2"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]

However, I have checked for occurances of "allowed_request_content_type" in modsec conf, and it appears to me there should be no problem here:

./REQUEST-901-INITIALIZATION.conf:
SecRule &TX:allowed_request_content_type "@eq 0" "id:901162, phase:1, pass, nolog, setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'"

./REQUEST-920-PROTOCOL-ENFORCEMENT.conf:
SecRule TX:0 "!^%{tx.allowed_request_content_type}$" "t:none, ctl:forceRequestBodyVariable=On, setvar:'tx.msg=%{rule.msg}', setvar:tx.anomaly_score=+%{tx.critical_anomaly_score}, setvar:tx.%{rule.id}-OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var_name}=%{matched_var}"

All configurations are enabled in ModSec Vendor Rule Sets.

 

[gramzon]

I found the problem. Rule 901162 was disabled.
I have replaced it with a custom rule at some point, but the upgrade disabled all my custom rules, as the modsec2.user.conf file is empty now.

This was the file prior to the upgrade:

SecUploadDir /tmp
SecTmpDir /tmp
SecDataDir /tmp
SecRequestBodyAccess On
# Limit client hits by user agent

<LocationMatch "/">
SecRule REQUEST_HEADERS:User-Agent "@pm facebookexternalhit" "id:400009,phase:2,nolog,pass,setvar:global.ratelimit_facebookexternalhit=+1,expirevar:global.ratelimit_facebookexternalhit=5"

SecRule GLOBAL:RATELIMIT_FACEBOOKEXTERNALHIT "@gt 1" "chain,id:4000011,phase:2,deny,status:429,setenv:RATELIMITED,nolog,msg:'RATELIMITED BOT'"
SecRule REQUEST_HEADERS:User-Agent "@pm facebookexternalhit"

Header always set Retry-After "5" env=RATELIMITED
ErrorDocument 429 "Too Many Requests"
</LocationMatch>
# Fix wp elementor access denied (this is unsafe)

<LocationMatch "/wp-admin/admin-ajax.php">
SecRuleRemoveById 949110

SecRuleRemoveById 980130

</LocationMatch>
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134

<Locationmatch "/wp-login.php">
# Setup brute force detection.
# React if block flag has been set.
SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 10 minutes, more than 10 login attempts in 3 minutes.'"

# Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"

SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
SecRule ip:bf_counter "@gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=600,setvar:ip.bf_counter=0"

</LocationMatch>
ErrorDocument 401 default
# Default HTTP policy: allowed_request_content_type (rule 900220)
SecRule &TX:allowed_request_content_type "@eq 0" "id:1901162, phase:1, pass, nolog, setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain|text/x-gwt-rpc'"

After restoring the custom rules everything works fine.

 

[cPRex]

Hey there! I'm doing some testing with this now and I'll let you know what I find!

 

[cPRex]

The good news - this isn't specifically related to ELevate, as the removal of the customization happens when the ea-apache24 packages get removed.
The bad news - I don't have a workaround available just yet, besides manually restoring the file as you did.

I've created case ZC-11209 to have our developers take a look at this, and I'll be sure to post an update once I get one.