Sending Email Alert From Apache ModSecurity

Apache Modsecurity can be configured to provide different passive response, an email alert is one of it. To get this done, we need to have mail service enabled in our host server. Generally an installation of Postfix or similar application will do the task.

Configuration steps

1. Create a emailing script and place it anywhere in the server. There in the following examples we have created a folder "my_test_rules" and placed my custom email script.

# cd /usr/share/modsecurity-crs/my_test_rules
#nano send_simple_email_alert.sh

  #!/bin/sh
  echo "Fake user tried to access the web application" | mail -s "server under attack" your_email@domain.com
  echo Done.

2. Write a custom rule that will execute the email script when triggered like sample rule below:

#nano test_request_headers_and_send_email.conf

  SecRule REQUEST_HEADERS:User-Agent "FAKE-USER" "deny,log,id:'1234123457',exec:/usr/share  /modsecurity-crs/my_test_rules/send_simple_email_alert.sh"

3. Add the Sym link of the custom rule in the activated_rules directory under /usr/share/modsecurity-crs

#cd /usr/share/modsecurity-crs/activated_rules
#ln -s ../my_test_rules/test_request_headers_and_send_email.conf

4. Reload Apache

#service apache2 restart

We can send detail email with the use of variables and directives of the ModSecurity firewall. An example below:

send_detail_email_alert.sh

#!/bin/sh
echo "False user tried to access the web application: Server: \
$SERVER Attacking IP: $REMOTEIP Attacking host: $REMOTEHOST \
Request URI: $REQUESTURI Arguments: $ARGS Unique ID: $UNIQUEID RuleTriggered: $RULE \
Time: `date '+%D %H:%M'`" | mail -s "local server under attack" your_email@domain.com \
echo Done.

test_request_headers_and_send_detail_email.conf

SecRule REQUEST_HEADERS:User-Agent "FALSE-USER" "deny,log,id:'1234123499',setenv:SERVER=%{SERVER_ADDR}, \
setenv:REMOTEIP=%{REMOTE_ADDR},setenv:REQUESTURI=%{REQUEST_URI},setenv:ARGS=%{ARGS}, \
setenv:UNIQUEID=%{UNIQUE_ID},setenv:RULE=%{rule.id}, \
exec:/usr/share/modsecurity-crs/my_test_rules/send_alert_email_false-user.sh"

Integrating ModSecurity with ClamAV Antivirus

ClamAV is free opensource antivirus engine designed for detecting Trojans, viruses, malware and other malicious threats. Here in this article we will look at setting up clamAV in Ubuntu 14.04 LTS server, integrate it with Apache ModSecurity Firewall and scan the uploaded file through a web application.

Install ClamAV

    Install clamav and clamav-daemon from repo

    $ sudo apt-get install clamav clamav-daemon -y

Update clamav malware patterns

    $ sudo freshclam

Start clamav-daemon

    $ sudo /etc/init.d/clamav-daemon start


Add Anti-virus scanning rules in the ModSecurity

    Create a soft link to an Anti-virus rule file. i.e modsecurity_crs_46_av_scanning.conf

    # cd /usr/share/modsecurity-crs/activated_rules
    # ln -s ../optional_rules/modsecurity_crs_46_av_scanning.conf


    Edit configuration in the rule file modsecurity_crs_46_av_scanning.conf
    # nano modsecurity_crs_46_av_scanning.conf

    Here, edit the location of script in the "@inspectfile" operator.

    SecRule FILES_TMPNAMES "@inspectFile /usr/share/modsecurity-crs/util/av-scanning/runav.pl" \
    "phase:2,t:none,block,msg:'Virus found in uploaded    file',id:'950115',tag:'MALICIOUS_SOFTWARE/VIRUS',tag:'PCI/5.1',severity$


    Restart Apache2
    # service apache2 restart

Test the configuration by uploading a test virus file through the upload function of an web application hosted in the server. You can use EICAR test file if you dont want to take risk using real malicious files.
Check modsecurity log if ModSecurity is in DetectionOnly mode, else ModSecurity will do the default action set in the Active Mode. i.e 403 Forbidden error display

Note: File upload service might get little bit sluggish due to scanning task by ClamAV.

Hiding Sensitive Data in Apache ModSecurity Log

We can hide the sensitive data from the audit log of the ModSecurity by using a "sanitiseArg" variable action for log.
Assuming that you have an application that uses the parameters password, oldPassword, and newPassword to transmit, we can write rule:

SecAction phase:5,nolog,pass,\
  sanitiseArg:password,\
  sanitiseArg:oldPassword,\
  sanitiseArg:newPassword

If you dont know the parameters name in advance then you can do something like this:

SecRule ARGS_NAMES password phase:5,nolog,pass,\
  sanitiseMatched

In the following example, we look for anything that resembles a credit card number and then sanitize it:

SecRule ARGS @verifyCC phase:5,nolog,pass,\
  sanitiseMatched

Here, "@verifyCC" is provided by modsecurity for detecting credit card pattern.

Custom Redirection in Apache ModSecurity WAF

We can redirect the user to a specific page when a specific rule get triggered. We can achieve this by directly modifying the original rule or by writing a custom rule which will update the actions of rules. The better way is to write a custom rule which will update the actions of a rule. A modsecurity directive "SecRuleUpdateActionById" will be used.

Syntax: SecRuleUpdateActionById

Example below:

#nano custom_rule_AV_redirect.conf

SecRuleUpdateActionById 950115 "redirect:http://www.technology.com/"
Here, Rule ID 950115  is an ID of modsecurity_crs_46_av_scanning.conf rule that is active.

We have to make symlink of this custom rule into the activation_rules directory of
 /usr/share/modsecurity-crs/ .

Redirecting all 403 status

If you want to set up the default redirection to all the 403 status coming through modsecurity then you can simple use "ErrorDocument" directive of Apache in the configuration file of your site in /etc/apache2/sites-enabled/

Syntax: ErrorDocument

Example:

ErrorDocument 403 https://www.owasp.org

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.