Any Significant Change in ModSecurity Mini HowTo (2017)

Discussion in 'ISPConfig 3 Priority Support' started by yupthatguy, Apr 21, 2021.

Tags:
  1. yupthatguy

    yupthatguy Member HowtoForge Supporter

    I am just about ready to install ModSecurity and I ran across this excellent tutorial [Below]. As it is ~4 years old, has there been any significant changes in the ModSecurity / ISPConfig relationship that I should know about? (FYI, I am on Debian 10.5, Buster)

    https://www.howtoforge.com/community/threads/mini-howto-modsecurity-crs-3-0-on-debian-jessie.74898/
    [Below]

    ModSecurity Mini HowTo.

    By Jesse Norell

    This is a quick howto for getting modsecurity crs 3 running with ispconfig 3.1 on apache in debian 8 (jessie). Written 11/30/2016, and likely things will change in the future. Modsecurity can be installed on all web server nodes in a multi-server installation, including the ispconfig control panel.

    Start with installing the OS and ISPConfig according to the Perfect Server guide: https://www.howtoforge.com/tutorial/perfect-server-debian-8-jessie-apache-bind-dovecot-ispconfig-3/

    Add the jessie-backports repository if you haven't already done so:
    Code:
    # cat <<EOF >/etc/apt/sources.list.d/jessie-backports.list
    deb http://http.debian.net/debian jessie-backports main
    deb-src http://http.debian.net/debian jessie-backports main
    EOF
    
    # apt-get update
    
    Install the apache module:
    Code:
    # apt-get install libapache2-mod-security2
    
    You can install modsecurity with nginx as well, but I don't have any experience there. Maybe someone else can post that bit?

    Now install modsecurity-crs:
    Code:
    # apt-get -t jessie-backports install modsecurity-crs
    
    Configure modsecurity-crs rules to be included by apache. This is right from /usr/share/doc/modsecurity-crs/README.Debian:
    Code:
    # cd /usr/share/modsecurity-crs/rules
    # cp REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example \
       /etc/modsecurity/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
    # cp RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example \
       /etc/modsecurity/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
    
    # cat <<EOF > /etc/modsecurity/ispconfig.conf
    <IfModule security2_module>
           Include /usr/share/modsecurity-crs/owasp-crs.load
    </IfModule>
    EOF
    
    And this part is based on ongoing discussion at https://www.howtoforge.com/community/threads/mod_security-with-ispconfig-vhost.74833/:

    Code:
    # cat <<EOF >> /etc/modsecurity/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
    
    <Directory /usr/local/ispconfig/interface/web/client/>
      # 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
    
      # php injection/attack hits seen by Bicet
      SecRuleRemoveById 933150
      SecRuleRemoveById 959100
    
      # modify a site Custom Php.ini
      # POST /sites/web_vhost_domain_edit.php
      # ARGS:custom_php_ini
      SecRuleRemoveById 933120
    
    </Directory>
    
    <Directory /usr/share/phpmyadmin>
      # mod_security rules (crs3) that hit on legitimate phpmyadmin use
      SecRuleRemoveById 942100
      SecRuleRemoveById 941120
    </Directory>
    EOF
    
    Now create a modsecurity.conf file and configure settings as needed; what I'm using right now is:
    Code:
    # mkdir /var/cache/modsecurity/tmp/ /var/cache/modsecurity/upload/
    # chown www-data /var/cache/modsecurity/tmp/ /var/cache/modsecurity/upload/
    # chmod 700 /var/cache/modsecurity/tmp/ /var/cache/modsecurity/upload/
    # cd /etc/modsecurity/
    # cp modsecurity.conf-recommended modsecurity.conf
    # sed -i 's/^SecRequestBodyLimit .*$/SecRequestBodyLimit 134217728/g' modsecurity.conf
    # sed -i 's/^SecPcreMatchLimit .*$/SecPcreMatchLimit 150000/g' modsecurity.conf
    # sed -i 's/^SecPcreMatchLimitRecursion .*$/SecPcreMatchLimitRecursion 150000/g' modsecurity.conf
    # sed -i 's|^SecTmpDir .*$|SecTmpDir /var/cache/modsecurity/tmp/|g' modsecurity.conf
    # sed -i 's|^SecDataDir .*$|SecDataDir /var/cache/modsecurity/|g' modsecurity.conf
    # sed -i 's|^#SecUploadDir .*$|SecUploadDir /var/cache/modsecurity/upload/|g' modsecurity.conf
    # sed -i 's/^#SecUploadFileMode .*$/SecUploadFileMode 0600/g' modsecurity.conf
    # sed -i 's/^SecAuditLogParts .*$/SecAuditLogParts ABIFHZ/g' modsecurity.conf
    
    ISPConfig disables ModSecurity out of the box, we're going to enable it. You could run in detection mode if you want to make sure everything works (in particular, the remote API has not been tested with modsecurity at this time!). This only needs done on the ISPConfig control panel node, not slave webservers if you have those:
    Code:
    # sed -i 's/SecRuleEngine Off/SecRuleEngine On/g' /etc/apache2/sites-available/ispconfig.vhost
    
    Now enable modsecurity, restart apache:
    Code:
    # a2enmod security2
    # apachectl restart
    
    Once you've made sure apache is running, you can watch modsecurity's log:

    Code:
    # tail -f /var/log/apache2/modsec_audit.log
    
    ModSecurity is now running in DetectionOnly mode for all vhosts except the control panel itself, so there is no additional security for your websites at this point. Watch the log, and when you're ready to enable it, set 'SecRuleEngine On' in /etc/modsecurity/modsecurity.conf.

    When you have a site hitting false positives (and that will happen at times), you can set 'SecRuleEngine DetectionOnly' for the specific website that is affected, not for the entire server, and then work on the rules that are hitting as false-positive. Once you've identified rules that false-positive for a site, you can disable them for just that site in apache config.

    More info on CRS at https://modsecurity.org/crs/ including 'Handling False Positives' links.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Test it, then you know if it still works or not. Personally, I won't' install mod_security on a server unless in special cases where you have a dedicated system where very old sites need to be hosted that can not be updated anymore and have to be kept alive for some time or when you have cases where an active attack is going on and a site gets re-infected and you have not found out how this happens to solve it properly. And you should take into account that mod_security has to run every request through hundreds of regex rules, so this has an impact on your server performance.
     
  3. yupthatguy

    yupthatguy Member HowtoForge Supporter

    Fair enough, just thought that an update might help other users as well. Additionally, I was trying to be preemptive, rather than reactive, and thereby try to reduce my post volume to this forum.

    For various reasons, I am 1,000% positive my sites will come under regular attack. I embarrass and challenge major corporations with the things I publish. In my situation, being preemptive with elevated security is the better choice. My current modsecurity strategy is a global configuration with per site exceptions as needed.

    I am on an alibaba VPS, not physical dedicated server, therefore allocating more resources as necessary or even spinning up a new server to share load is a few clicks. My focus is creating the most paranoid o_O, secure webserver as I can, before I re-focus on the web-development.
     
  4. yupthatguy

    yupthatguy Member HowtoForge Supporter

    Ok question:

    all of the steps in the tutorial above seem to work with the exception of

    Code:
    # cd /usr/share/modsecurity-crs/rules
    # cp REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example \
       /etc/modsecurity/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
    # cp RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example \
       /etc/modsecurity/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
    
    # cat <<EOF > /etc/modsecurity/ispconfig.conf
    <IfModule security2_module>
          Include /usr/share/modsecurity-crs/owasp-crs.load
    </IfModule>
    EOF
    
    These files no longer exists, and instead are configured out-of-the-box:
    Code:
    # cd /usr/share/modsecurity-crs/rules
    # cp REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example \
       /etc/modsecurity/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
    # cp RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example \
       /etc/modsecurity/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
    
    Meanwhile, this file:

    Code:
    # cat <<EOF > /etc/modsecurity/ispconfig.conf
    <IfModule security2_module>
          Include /usr/share/modsecurity-crs/owasp-crs.load
    </IfModule>
    EOF
    
    Seems to cause an error where apache complains that rules with the same id exist and prevents apache from restarting:

    Code:
    [email protected]:/etc/modsecurity# apachectl restart
    AH00526: Syntax error on line 829 of /etc/modsecurity/crs/crs-setup.conf:
    ModSecurity: Found another rule with the same id
    Action 'restart' failed.
    
    Perhaps folks with more knowledge than I can confirm that the solution seems to be to simply not create the /etc/modsecurity/ispconfig.conf file? Meaning, a separate ispconfig.conf is no longer necessary.
     
  5. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    I haven't set this up in a while, but that does sound likely to be the solution; if guess the packaging has changed to include that file now. I'll try to look into that on a buster machine some time.
     

Share This Page