mod_security with ispconfig vhost

I'm interested in using mod_security with the ispconfig control panel vhost (default port 8080), has anyone taken the time to identify what rule id's typically get tripped up / need disabled there? The best (almost only) info I've seen is dated, in the comments from https://git.ispconfig.org/ispconfig/ispconfig3/issues/2511 - I'm working with the recently released CRS 3, which surely would need a fresh start in configuring. I'll probably run a while in DetectionOnly mode while sorting through this, but there are some things I don't have the setup to test (use of the remote api in particular).

I'm also curious if this type of config would be wanted/received in upstream, after thorough testing? Ie. rather than just disable mod_security, properly configure it.

 

Sure, please feel free to post it to git.

 

I've done a little work on this, and there aren't many rule hits to deal with. I'm using a debian 8 system with modsecurity-crs 3.0.0-2 from unstable.

Rules I've found to hit so far in ISPConfig are:

Code:

# put "/etc/passwd' in client notes field
SecRuleRemoveById 932160

# edit Server Config > Web > PHP Settings (path names)
SecRuleRemoveById 930120

# edit Server Config > Jailkit
SecRuleRemoveById 932150

And I found one so far that triggered while using phpmyadmin:

Code:

<Directory /usr/share/phpmyadmin>
    # mod_security rules (crs3) that hit on legitimate phpmyadmin use
    <IfModule mod_security2.c>
        # /phpmyadmin/sql.php  hit rule 942100
        SecRuleRemoveById 942100
        #SecRuleRemoveByTag "attack-sqli"
    </IfModule>
</Directory>

Easy to manage those few. Now another question is the best way to handle these. Above the rules are outright removed, which works but is the least secure option.

I tried to ignore 932160 for just the 'notes' argument with:

Code:

SecRuleUpdateTargetById 932160 !ARGS:'notes'

But that didn't work, apparently due to a known bug (https://github.com/SpiderLabs/ModSecurity/issues/89). This same rule update could be done later on in apache config and it should work, but then we have to coordinate the loading of that config across all OS's where ISPConfig with modsecurity is supported. Probably doable, but it seems like it would take considerably more work to manage/maintain/test all the config glue to get that done that to actually tweak the rules, though it's more secure than disabling the entire rule.

Another option is to create a new exclusion rule which would remove the rule id, and could match the url path so eg. 932160 is only removed for 'notes' arg when hitting /client/client.php (from memory I think that was the file). This is the most selective application, and hence the most secure, but would require both managing/coordinating when the rule loads, as well as now having to coordinate rule numbers that we create (so they don't conflict with other local rules a site may create).

We could mix webserver config and and remove rules for only certain files/directories (eg. like phpmyadmin above).

Also we could possibly seek to put the few exclusions needed into upstream crs rules, so it's done for all out of the box.


Thoughts/comments?

 

For anyone interested, it looks like modsecurity-crs 3.0.0-2 just hit jessie-backports yesterday: https://tracker.debian.org/pkg/modsecurity-crs

 

Found another false-positive for phpmyadmin (941120), and I have yet to test roundcube. I posted a small howto at https://www.howtoforge.com/community/threads/mini-howto-modsecurity-crs-3-0-on-debian-jessie.74898/ and I'll keep config updated there.