ModSecurity

Installation

ModSecurity is web application layer firewall, it's basically Apache server module and provides website protection from attacks.

Here, work is done on the system that runs Oracle Linux 5.8 (2.6.18-308.1.1.0.1.el5)

Two RPMs lua-5.1.4-4.el5.x86_64.rpm and mod_security-2.6.8-6.el5.x86_64.rpm have been installed. This installs mod_security with no rules and no integration into Apache. The installation creates empty directory /etc/httpd/modsecurity.d/activated_rules/. This is place where symbolic links will be created later.

Configuration

Review the file /etc/httpd/conf.d/mod_security.conf (it was created during the installation). Make sure these lines make sense and directories/files exist.

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so
Include /etc/httpd/modsecurity.d/*.conf
Include /etc/httpd/modsecurity.d/activated_rules/*.conf
SecDebugLog /var/log/httpd/modsec_debug.log
SecAuditLog /var/log/httpd/modsec_audit.log

Add this line in the /etc/httpd/conf/httpd.conf file

Include /etc/httpd/conf.d/mod_security.conf

Check for any syntax errors in Apache config file.

# service httpd configtest

The mod_security is now integrated into Apache and next is to configure some rules.

Rules

ModSecurity is a web application firewall engine that provides very little protection on its own. In order to become useful, ModSecurity must be configured with rules. The OWASP ModSecurity CRS Project's goal is to provide "pluggable" set of generic attack detection rules that provide a base level of protection.
Ref url: https://www.owasp.org//index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project?hmac=5614b5991261647832e4e9ef1a56a024120fd258

Note, for mod_security version 2.6.8 we need to use OWASP mod_security version 2.2.5 (file SpiderLabs-owasp-modsecurity-crs-v2.2.5-0-g28e4ec8.tar)

Get the file SpiderLabs-owasp-modsecurity-crs-v2.2.5-0-g28e4ec8.tar
Untar it and place the content in /usr/local/mod_security/ directory
Copy the file modsecurity_crs_10_setup.conf.example into modsecurity_crs_10_setup.conf

[root@my-www-box]# ls -la /usr/local/mod_security
total 132
drwxr-xr-x  9 root root  4096 Jan 19 16:33 .
drwxr-xr-x 23 root root  4096 Jan 19 15:05 ..
drwxrwxr-x  2 root root  4096 Sep 19  2012 activated_rules
drwxrwxr-x  2 root root  4096 Jan 19 16:23 base_rules
-rw-rw-r--  1 root root 37681 Sep 19  2012 CHANGELOG
drwxrwxr-x  2 root root  4096 Sep 19  2012 experimental_rules
-rw-rw-r--  1 root root  7508 Sep 19  2012 INSTALL
-rw-rw-r--  1 root root 11357 Sep 19  2012 LICENSE
drwxrwxr-x  2 root root  4096 Sep 19  2012 lua
-rw-rw-r--  1 root root 13544 Sep 19  2012 modsecurity_crs_10_setup.conf
-rw-rw-r--  1 root root 13544 Sep 19  2012 modsecurity_crs_10_setup.conf.example
drwxrwxr-x  2 root root  4096 Sep 19  2012 optional_rules
-rw-rw-r--  1 root root  1485 Sep 19  2012 README.md
drwxrwxr-x  2 root root  4096 Sep 19  2012 slr_rules
drwxrwxr-x  4 root root  4096 Sep 19  2012 util

Finally go to the directory /etc/httpd/modsecurity.d/activated_rules/ and create symbolic links for rules you want to implement. Enable one rule at the time and monitor them for some time.
Example of implementing the "Bad robots detection" rule

[root@my-www-box]# ls -la /etc/httpd/modsecurity.d/activated_rules
drwxr-xr-x 2 root root 4096 Jan 19 16:26 .
drwxrwxr-x 3 root root 4096 Jan 19 15:07 ..
lrwxrwxrwx 1 root root   65 Jan 19 16:26 modsecurity_35_bad_robots.data -> /usr/local/mod_security/base_rules/modsecurity_35_bad_robots.data
lrwxrwxrwx 1 root root   63 Jan 19 16:25 modsecurity_35_scanners.data -> /usr/local/mod_security/base_rules/modsecurity_35_scanners.data
lrwxrwxrwx 1 root root   53 Jan 19 16:18 modsecurity_crs_10_setup.conf -> /usr/local/mod_security/modsecurity_crs_10_setup.conf
lrwxrwxrwx 1 root root   69 Jan 19 16:24 modsecurity_crs_35_bad_robots.conf -> /usr/local/mod_security/base_rules/modsecurity_crs_35_bad_robots.conf

Logging

ModSecurity logs very nicely in /var/log/httpd/modsec_audit.log
It's expected that implementing ModSecurity block something you don't want to be blocked, I see this with updating bugs in Bugzilla.

Here is example from logs

--b4d46b1c-A--
[10/Feb/2016:15:34:16 --0800] 31CXS4n@EBAAAEerqb8AAAAZ 

--b4d46b1c-B--
POST /bugzilla/process_bug.cgi HTTP/1.1 
Host: bugzilla
Connection: keep-alive
Content-Length: 1034
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: https://bugzilla
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) 
Content-Type: application/x-www-form-urlencoded
Referer: https://bugzilla/bugzilla/show_bug.cgi?id=15
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

--b4d46b1c-C--
delta_ts=2016-02-10+14%3A18%3A53&longdesclength=9&id=15273&token=1455146899

--b4d46b1c-F--
HTTP/1.1 403 Forbidden
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 196
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--b4d46b1c-E--

--b4d46b1c-H--
Message: Access denied with code 403 (phase 2). [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_40_generic_attacks.conf"] [line "181"] 
[id "950005"] [rev "2.2.5"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] 
[tag "WASCTC/WASC-33"] [tag "OWASP_TOP_10/A4"] [tag "PCI/6.5.4"]
Action: Intercepted (phase 2)
Apache-Handler: cgi-script
Stopwatch: 1455147256420171 2887 (- - -)
Stopwatch2: 1455147256420171 2887; combined=2031, p1=120, p2=1907, p3=0, p4=0, p5=4, sr=45, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.8 (http://www.modsecurity.org/); OWASP_CRS/2.2.5.
Server: Apache

--b4d46b1c-Z--

Here I see this attempt to update bug for some reason was identified as generic attack, but it's okay update, so I just remove the line 181 from the file modsecurity_crs_40_generic_attacks.conf and reload apache service and after that bug update is successful.

Back to the main page