Friday, December 27, 2013

Apache Modsecurity Firewall

ModSecurity is a hybrid web application firewall that relies on the host web server for some of the work.  It is a free open source web application firewall that was recently acquired by Trustwave (www.trustwave.com) as part of their SpiderLabs research division.

ModSecurity can be implemented in all forms of web application platforms like Ruby, Java and PHP. In the early Jan 2013, Trustwave published  the mitigation measure of Ruby on Rails XML exploits through the implementation of ModSecurity Firewall. (Reference: http://blog.spiderlabs.com/2013/01/modsecurity-mitigations-for-ruby-on-rails-xml-exploits.html)

Inorder to make good use of Modsecurity, it must be configured with rules.  OWASP ModSecurity Core Rule Set  ( modsecurity CRS) provides generic protection from unknown vulnerabilities often found in web applications, which are in most cases custom coded.

Installation of ModSecurity on Ubuntu 14.04

The installation steps of Modsecurity on the Apache, Ubuntu 12.04 are as follow:

1. Get Repo (http://packages.ubuntu.com/trusty/httpd/libapache2-mod-security2 http://packages.debian.org/search?searchon=sourcenames&keywords=modsecurity-apache )

apt-get install libapache2-mod-security2

using apt-get install libapache2-modsecurity on the Ubuntu will download and install the older version of modsecurity. If you want to use the older version of modsecurity then the modsecurity CRS must also be of older version. The latest version of ModSecurity CRS requires features in 2.7.0 and above of modsecurity (ver, accuracy and maturity actions). If you are using the modsecurity version lower than 2.7.0 and  latest Modsecurity CRS then action like ver, accuracy will generate error while parsing. (Reference:https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2012-September/001210.html)

If you could not find the repo then you have to add the universe repository in the /etc/apt/source.list

deb http://us.archive.ubuntu.com/ubuntu trusty main universe

2. Verify with
#apachectl -M | grep --color security

output:

security2_module (shared)

You should see a module named security2_module (shared) which indicates that the module was loaded

3. Modsecurity's installation includes a recommended configuration file which has to be renamed:

#cp /etc/modsecurity/modsecurity.conf-recommended modsecurity.conf


4. Reload Apache

#service apache2 reload

 You'll find a new log file for mod_security in the Apache log directory:

#ls -l /var/log/apache2/modsec_audit.log


output:
-rw-r----- 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log


Configuring ModSecurity

1. Make changes to /etc/modsecurity/modsecurity.conf
        Change the line SecRuleEngine DetectionOnly to SecRuleEngine On

    # Enable ModSecurity, attaching it to every transaction. Use detection

    # only to start with, because that minimises the chances of post-installation

    # disruption.

    #

    SecRuleEngine DetectionOnly


    ModSecurity won’t do anything implicitly. It won’t even activate unless you tell it to. By not doing anything implicitly, we ensure that ModSecurity does only what you tell it to. This, on the one hand, ensures that you need to understand a feature before you use it, and, on the other hand, makes it clear that your configuration is your responsibility. On the other hand the default configuration is hard to make interm of security and security is not free it comes with price ( CPU, RAM, etc).

2. Another directive to modify is SecResponseBodyAccess, change it to Off from the On (default). If you require the data leakage detection and protection then use as the default.

        # Allow ModSecurity to access response bodies.

        # You should have this directive enabled in order to identify errors

        # and data leakage issues.

        #

        # Do keep in mind that enabling this directive does increases both

        # memory consumption and response latency.

        #

        SecResponseBodyAccess Off

  3. Download Modsecurity CRS (https://github.com/SpiderLabs/owasp-modsecurity-crs)
        Install it or replace the /usr/share/modsecurity-crs with the CRS you have downloaded. The CRS will consist of number of sub folders like activated_rules,  base rules, etc. The documentation is available at /usr/share/doc/modsecurity-crs

4. In Ubuntu 14.04 and apache 2.4, you don't have to make mod-security.conf file manually, if you do then it wont work. Instead there is already a file named security2.conf in /etc/apache2/mods-enabled/    and you can include directory path in it. No quotes are required.
    #vi /etc/apache2/mods-enabled/security2.conf

  Add the following directives inside :

        Include /usr/share/modsecurity-crs/*.conf

        Include /usr/share/modsecurity-crs/activated_rules/*.conf

    The activated_rules directory is similar to Apache's mods-enabled directory. The rules are available in directories:

                /usr/share/modsecurity-crs/base_rules

               /usr/share/modsecurity-crs/optional_rules

               /usr/share/modsecurity-crs/experimental_rules

5. Symlinks must be created inside the activated_rules directory to activate these. Let us activate the SQL injection rules.

    #cd /usr/share/modsecurity-crs/activated_rules/

               ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf

6. Apache has to be reloaded for the rules to take effect.
    #service apache2 reload


Test the configuration and settings with the vulnerable web application like DVWA. When the modsecurity firewall is On the sql injection get prevented by the firewall with display of 403 error.