With help from Christian Folini, I now have a workaround. I entered this as a new rule in cPanel WHM's "ModSecurity Tools" section and restarted Apache:
SecRule REQUEST_URI "^\/mailman\/options\/.*" "id:900240,phase:1,nolog,pass,t:none,setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/'" This is modified from the disabled SecAction 900240 in crs-setup.conf. The ".com/" is removed from the list of extensions, and REQUEST_URI is added to restrict its action to the specified pages. Now: http://lists.xxx.xxx/mailman/options/listname/localpart--at--domain.com is admitted http://lists.xxx.xxx/mailman/Xoptions/listname/localpart--at--domain.com is blocked On Mon, Oct 9, 2017 at 12:20 PM, Russell Clemings <rclemi...@gmail.com> wrote: > Using OWASP ModSecurity Core Rule Set ver.3.0.2 on cPanel v66.0.23; CentOS > 7.3. > > I'm getting false positives on 920440 when hitting certain Mailman (v. > 2.1.23) user options pages -- specifically ones ending in ".com" -- which > is a lot of them, because Mailman includes the user's email address in the > URL for the options pages. > > What's the best way to deal with this without disabling the rule > completely? Is there already a fix? If so I couldn't find it. > > Sanitized example: > > (Now posted at https://pastebin.com/MFyyVNZk because Barracuda won't let > it onto the list.) > > >
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
