Back to the main page



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.

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.


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/
LoadModule unique_id_module modules/
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.


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:

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)


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
[10/Feb/2016:15:34:16 --0800] 31CXS4n@EBAAAEerqb8AAAAZ 

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


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


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 (; OWASP_CRS/2.2.5.
Server: Apache


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