ZC-11209 - ModSec custom rules lost after Leapp upgrade
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.
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:
./REQUEST-920-PROTOCOL-ENFORCEMENT.conf:
All configurations are enabled in ModSec Vendor Rule Sets.
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.
-
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 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" # Fix wp elementor access denied (this is unsafe) SecRuleRemoveById 949110 SecRuleRemoveById 980130 SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134 # 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" 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.0 -
Hey there! I'm doing some testing with this now and I'll let you know what I find! 0 -
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. 0
Please sign in to leave a comment.
Comments
3 comments