Mod Security

Mod Security

Mod security has a default configuration file, and comes with a core rule set. The configuration works with include files which work for the modsecurity part like this:

httpd.conf
|
|– default-server.conf . . . . . . . . . set up the default server that replies to non-virtual-host requests
| `–conf.d/mod_security2.conf . . . . enable mod-security default configuration
|
`–conf.d/modsecurity/*.conf . . . . . . add the core rule set

Since this include structure is not enabled by default (because the core rule set is not enabled by default) we have to include the core rule set manually.

Create the correct directories and copy the core rule set config files to this directory:

reverseproxy:/usr/share/doc/packages/apache2-mod_security2/rules # mkdir /etc/apache2/conf.d/modsecurity
reverseproxy:/usr/share/doc/packages/apache2-mod_security2/rules # cp *.conf /etc/apache2/conf.d/modsecurity
reverseproxy:/usr/share/doc/packages/apache2-mod_security2/rules # cd /etc/apache2/conf.d/modsecurity

reverseproxy:/etc/apache2/conf.d/modsecurity # ll
-rw-r–r– 1 root root 12325 Jan 31 14:03 modsecurity_crs_10_config.conf
-rw-r–r– 1 root root 5164 Jan 31 14:03 modsecurity_crs_20_protocol_violations.conf
-rw-r–r– 1 root root 3538 Jan 31 14:03 modsecurity_crs_21_protocol_anomalies.conf
-rw-r–r– 1 root root 2496 Jan 31 14:03 modsecurity_crs_23_request_limits.conf
-rw-r–r– 1 root root 6399 Jan 31 14:03 modsecurity_crs_30_http_policy.conf
-rw-r–r– 1 root root 2720 Jan 31 14:03 modsecurity_crs_35_bad_robots.conf
-rw-r–r– 1 root root 28726 Jan 31 14:03 modsecurity_crs_40_generic_attacks.conf
-rw-r–r– 1 root root 2463 Jan 31 14:03 modsecurity_crs_45_trojans.conf
-rw-r–r– 1 root root 8268 Jan 31 14:03 modsecurity_crs_50_outbound.conf

Add the include line for the core rule set in the httpd.conf:

# Include Mod Security Core Rule Set
Include /etc/apache2/conf.d/modsecurity/*.conf

Now we will configure the config files themselves to run modsecurity first in DetectionOnly
mode to prevent the risk for false positives. We also set the logfiles correctly:

vi /etc/apache2/conf.d/mod_security2.conf:
# Basic configuration options
#SecRuleEngine On
SecRuleEngine DetectionOnly

vi /etc/apache2/conf.d/modsecurity/modsecurity_crs_10_config.conf:
SecRuleEngine DetectionOnly
SecAuditLog /var/log/apache2/modsec_audit.log
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 3

Now restart apache:

reverseproxy:/var/log/apache2 # /etc/init.d/apache2 start
Starting httpd2 (prefork) [Mon Jan 31 14:30:35 2011] [warn] worker http://10.10.12.20/start already used by another worker
[Mon Jan 31 14:30:35 2011] [warn] worker http://10.10.12.20/start already used by another worker

Documentation Core Rule Set

Core Rule Set Structure & Usage
====================================

To activate the rules for your web server installation:

1) You may want to edit and customize modsecurity_crs_10_config.conf.
Additionally you may want to edit modsecurity_crs_30_http_policy.conf
which enforces an application specific HTTP protocol usage.

2) Add the following line to your httpd.conf (assuming
you’ve placed the rule files into conf/modsecurity/):

Include conf/modsecurity/*.conf

3) Restart web server.

4) Make sure your web sites are still running fine.

Core Rule Set Content
=========================

In order to provide generic web applications protection, the Core Rule Set
uses the following techniques:

1. HTTP protection – detecting violations of the HTTP protocol and a locally
defined usage policy.

2. Common Web Attacks Protection – detecting common web application security
attack.

3. Automation detection – Detecting bots, crawlers, scanners and other surface
malicious activity.

4. Trojan Protection – Detecting access to Trojans horses.

5. Errors Hiding – Disguising error messages sent by the server

In addition the rule set also hints at the power of ModSecurity beyond
providing security by reporting access from the major search engines to your
site.

HTTP Protection – This first line of protection ensures that all abnormal HTTP
requests are detected. This line of defense eliminates a large number of
automated and non targeted attacks as well as protects the web server itself.
Common Web Attacks Protection Rules on the second level address the common web
application security attack methods. These are the issues that can appear in
any web application. Some of the issues addressed are:

– SQL Injection
– Cross-Site Scripting (XSS)
– OS Command execution
– Remote code inclusion
– LDAP Injection
– SSI Injection
– Information leak
– Buffer overflows
– File disclosure

Automation Detection – Automated clients are both a security risk and a
commercial risk. Automated crawlers collect information from your site, consume
bandwidth and might also search for vulnerabilities on the web site. Automation
detection is especially useful for generic detection of comments spam.

Trojan Protection – ModSecurity Core Rule Set detects access to back doors
installed on a web server. This feature is very important in a hosting
environment when some of this backdoors may be uploaded in a legitimate way and
used maliciously. In addition the Core Rule Set includes a hook for adding
an Anti-Virus program such as ClamAV for checking file uploads.

Errors Hiding – If all fails, the Core Rule Set will detect errors sent by
the web server. Detecting and blocking errors prevents attackers from
collecting reconnaissance information about the web application and also server
as a last line of defense in case an attack was not detected eariler.

Few Word of Caution
——————-

As with every new technology, using the ModSecurity Core Rule Set requires some caution:

– Every Rule Set can have false positive in new environments and any new
installation should initially use the log only Rule Set version or if no such
version is available, set ModSecurity to Detection only using the SecRuleEngine
DetectionOnly command.

After running ModSecurity in a detection only mode for a while review the evens
generated and decide if any modification to the rule set should be made before
moving to protection mode.

From the mod security manual:

SecRuleEngine

Description: Configures the rules engine.
Syntax: SecRuleEngine On|Off|DetectionOnly
Example Usage: SecRuleEngine On
Processing Phase: Any
Scope: Any
Version: 2.0.0
Dependencies/Notes: This directive can also be controlled by the ctl action (ctl:ruleEngine=off) for per rule processing.
Possible values are:
* On – process rules.
* Off – do not process rules.
* DetectionOnly – process rules but never intercept transactions, even when rules are configured to do so.

Mod Security Handling False Positives
Mod security is now configured as detection only. For now, we keep it like this, closely monitoring the mod security logfiles for false positives. When we are sure there are no more false positives (or at least nothing our customers will notice) we can set the SecRuleEngine to On.

This blog also explains how to deal with false positives: Handling False Positives
Mod Security Troubleshooting

Starting httpd2 (prefork) [Mon Jan 31 14:20:51 2011] [warn] worker http://10.10.12.20/start already used by another worker
[Mon Jan 31 14:20:51 2011] [warn] worker http://10.10.12.20/start already used by another worker
Syntax error on line 53 of /etc/apache2/conf.d/modsecurity/modsecurity_crs_10_config.conf:
Invalid command ‘SecRuleEngine’, perhaps misspelled or defined by a module not included in the server configuration

The command line was:
/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL

‘Solution:’ The module mod_security is not enabled. Check for the module with the command ‘httpd2 -M’. If the module is really not there, add the module in /etc/sysconfig/apache2.

reverseproxy:/var/log/apache2 # /etc/init.d/apache2 restart
[Mon Jan 31 14:29:23 2011] [warn] worker http://10.10.12.20/start already used by another worker
[Mon Jan 31 14:29:23 2011] [warn] worker http://10.10.12.20/start already used by another worker
Syntax error on line 191 of /etc/apache2/conf.d/modsecurity/modsecurity_crs_10_config.conf:
ModSecurity: Failed to open the audit log file: /srv/www/logs/modsec_audit.log

‘Solution:’ The directory specified for the logs does not exist. Create the directory with this command:

reverseproxy:/var/log/apache2 # mkdir -p /srv/www/logs/

or change the location to /var/log/apache2. Of course, the same message can be displayed for /srv/www/logs/modsec_debug.log.
Testing Mod Security
You can test if mod security is running correctly by going to the index file of your website by ip-address and adding ‘?file=/etc/passwd’ to the url:

https://10.10.10.20/start/index.html?file=/etc/passwd

This will be noticed, and displayed in the log (not stopped, remember, we’re running in DetectionOnly mode):

less modsec_debug.log

[31/Jan/2011:15:46:31 +0100] [10.10.10.20/sid#7f0c98cffdc8][rid#7f0c98feb488][/start/0100_NavigationPublic.html][2] Warning. Pattern match “^[\d\.]+$” at REQUEST_HEADERS:Host. [
file “/etc/apache2/conf.d/modsecurity/modsecurity_crs_21_protocol_anomalies.conf”] [line “60”] [id “960017”] [msg “Host header is a numeric IP address”] [severity “CRITICAL”] [ta
g “PROTOCOL_VIOLATION/IP_HOST”]
[31/Jan/2011:15:46:42 +0100] [10.10.10.20/sid#7f0c98cffdc8][rid#7f0c98fe2908][/start/index.html][2] Warning. Pattern match “^[\d\.]+$” at REQUEST_HEADERS:Host. [file “/etc/apach
e2/conf.d/modsecurity/modsecurity_crs_21_protocol_anomalies.conf”] [line “60”] [id “960017”] [msg “Host header is a numeric IP address”] [severity “CRITICAL”] [tag “PROTOCOL_VIOL
ATION/IP_HOST”]
[31/Jan/2011:15:46:42 +0100] [10.10.10.20/sid#7f0c98cffdc8][rid#7f0c98fe2908][/start/index.html][2] Warning. Pattern match “(?:\b(?:\.(?:ht(?:access|passwd|group)|www_?acl)|glob
al\.asa|httpd\.conf|boot\.ini)\b|\/etc\/)” at ARGS:file. [file “/etc/apache2/conf.d/modsecurity/modsecurity_crs_40_generic_attacks.conf”] [line “114”] [id “950005”] [msg “Remote
File Access Attempt”] [data “/etc/”] [severity “CRITICAL”] [tag “WEB_ATTACK/FILE_INJECTION”]
[31/Jan/2011:15:46:42 +0100] [10.10.10.20/sid#7f0c98cffdc8][rid#7f0c98fe2908][/start/index.html][2] Warning. Pattern match “(?:\b(?:(?:n(?:et(?:\b\W+?\blocalgroup|\.exe)|(?:map|
c)\.exe)|t(?:racer(?:oute|t)|elnet\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\.exe|echo\b\W*?\by+)\b|c(?:md(?:(?:32)?\.exe\b|\b\W*?\/c)|d(?:\b\W*?[\\/]|\W*?\.\.)|hmod.{0,40}?\+.
{0,3}x))|[\;\|\`]\W*? …” at ARGS:file. [file “/etc/apache2/conf.d/modsecurity/modsecurity_crs_40_generic_attacks.conf”] [line “133”] [id “950006”] [msg “System Command Injectio
n”] [data “/passwd”] [severity “CRITICAL”] [tag “WEB_ATTACK/COMMAND_INJECTION”]

less modsec_audit.log:

Message: Warning. Pattern match “^[\d\.]+$” at REQUEST_HEADERS:Host. [file “/etc/apache2/conf.d/modsecurity/modsecurity_crs_21_protocol_anomalies.conf”] [line “60”] [id “960017”]
[msg “Host header is a numeric IP address”] [severity “CRITICAL”] [tag “PROTOCOL_VIOLATION/IP_HOST”]
Apache-Handler: proxy-server
Stopwatch: 1296487473036980 19376 (997 2882 -)
Producer: ModSecurity for Apache/2.5.6 (http://www.modsecurity.org/); core ruleset/1.6.1.
Server: Apache/2.2.10 (Linux/SUSE)

Mod Security Resources

http://www.modsecurity.org/
http://www.modsecurity.org/documentation/faq.html
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/html-multipage/introduction.html
Install Modsecurity
Install core rule set

 

MY SET OF RULES TO DEFEND THE WEB SERVER
SecFilterEngine On

# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On

# Unicode encoding check
SecFilterCheckUnicodeEncoding On

# Only allow bytes from this range
SecFilterForceByteRange 0 255

# Only log actionable requests
SecAuditEngine RelevantOnly

# The name of the audit log file
SecAuditLog /var/log/apache2/audit_log

# Debug level set to a minimum
SecFilterDebugLog /var/log/apache2/modsec_debug_log
SecFilterDebugLevel 2

# Should mod_security inspect POST payloads
SecFilterScanPOST On

# By default log and deny suspicious requests
# with HTTP status 500
SecFilterDefaultAction “deny,log,status:500”

# Add custom secfilter rules here