mod_security with ispconfig vhost

Discussion in 'General' started by Jesse Norell, Nov 23, 2016.

  1. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    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 - 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.
    Jagrys likes this.
  2. Jagrys

    Jagrys New Member

    I'm also interested. I've got tests on my agenda but not sure if I start it before new year (few issues to resolve with higher priority) :-/
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    Sure, please feel free to post it to git.
  4. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    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:
    # 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:

    <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"
    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:
    SecRuleUpdateTargetById 932160 !ARGS:'notes'
    But that didn't work, apparently due to a known bug ( 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.

  5. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

  6. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

Share This Page