Protecting Nagios From Zero-Day Exploits with ModSecurity
Server - Nagios


Building an Application Firewall

You have built a rock solid firewall, tested it with nmap scanning for ports that were open, locked down SSH with port knocking, restricted outgoing ports with iptables, setup psad to block attacks, and tcp_wrappers to limit access so you are set right? Well, not exactly....

Unfortunately, the increasing number of attacks at the HTTP layer may have exposed your site to sql injection that brought your site down. The typical defense mechanisms used today work at the TCP/IP level and are not capable of working with the HTTP level. The solution, build a reverse proxy with ModSecurity, or use ModSecurity on your existing web server to protect your site from attacks at the HTTP level.

The real advantage of ModSeucrity is that it not only protects your system from known Cross-Site Scripting and SQL injection attacks, among many other things....but it also can provide zero-day

Protecting Nagios With ModSecurity


A WAF or Web Application Firewall is a firewall that detects and prevents attacks on your Nagios server. One of the provisions that ModSecurity can provide is transaction logging of the request bodies for your web traffic. This is important because web servers log traffic so that you can analyze for marketing purposes but not for the kinds of malicious requests that are made. This provides a way for attackers to get access to your site, usually with POST requests. ModSecurity provides for full logging of these types of requests. In addition, ModSecurity allows for real time monitoring to detect attacks as they occur and respond appropriately to those attacks.


Installation from Source

Move to a directory to download ModSecurity.

cd /usr/local/src


Before you get too far be sure to download the necessary applications so you can compile the program. This may take you awhile as you will need to install all of the dependencies as well.

yum install -y gcc cpp libxml2 httpd-devel gcc c++ pcre-devel libxml2-devel make

If you are running a 64-bit system you will have to run this command as well. There is a bug in yum in CentOS 5 so this must be installed as it is not done automatically.

yum install apr-devel.x86_64

Now unpack the file and move into the directory that is created.

tar zxvf modsecurity*

cd modsecurity-apache_2.5.x/apache2

Run the configure script.


Compile with make.



Install ModSecurity.

make install


The libraries will be installed in:



Edit the /etc/httpd/conf/httpd.conf file and add these lines.

LoadModule unique_id_module modules/

LoadFile /usr/lib/

LoadModule security2_module modules/


Now you need to set up the rules for ModSecurity. The Core Rule Set provides protection from unknown vulnerabilities. In order to set up the rules you will need to create a directory called:

mkdir /etc/httpd/conf.d/modsecurity


Edit the /etc/httpd/conf/httpd.conf file to include the configuration files in the directory you created.

Include conf.d/*.conf

Include conf.d/modsecurity/*.conf


The rules are located in the directory that was created when you uncompressed the modescurity tar.gz file, modsecurity-apache_2.5.x. The directory is called “rules” and in it you will see base_rules, optional_rules and a file which is the custom rules file. Copy base_rules and the custom rules file to your modsecurity directory.

cd modsecurity-apache_2.5.x/rules

cp base_rules/* /etc/httpd/conf.d/modsecurity/

cp modsecurity_crs_10_config.conf /etc/httpd/conf.d/modsecurity/


You should see the rules in the /etc/httpd/conf.d/modsecurity directory, something like this:

























The rules set is found in /etc/httpd/conf.d/modsecurity. This is the configuration folder for all of the rules that you can use. Spend some time reading and testing these files to verify that you have the settings that work for your site. You do have a working system after the install but you will want to do some configuration on your own. These files are built out of directives. The directives have options that are often listed as On/Off or have a number to indicate a level that you would like to run.


You will want to start your configuration changes with this file, here is a summary.


This configuration option allows you to turn On or Off or DeteectionOnly for ModSecurity. This setting is essential to understand because if you make a mistake elsewhere in the configuration you can turn ModSecurity Off witht this setting or use DetectionOnly to see results in the logs.

SecRuleEngine Off


When you make changes, save the settings and then restart Apache for the changes to take effect.

service httpd restart


Custom Rules to Start With

Create this custom file and add these lines to set up several settings you may use later for finding errors, your logs.


# Set Up Logs

SecAuditEngine RelevantOnly

SecAuditLog /var/log/httpd/modsec_audit.log

SecAuditLogParts ABCFHZ

SecAuditLogType Serial

SecAuditLogRelevantStatus ^(?:5|4\d[^4])

SecDataDir /var/log/httpd/data


SecAuditEngine RelevantOnly




SecAuditLogRelevantStatus "^(?:5|4\d[^4]) "


Serial will allow you one file that will contain all events. If you want individual file you could change it to “Concurrent”.

SecAuditLogType Serial

SecAuditLog /var/log/httpd/modsec_audit.log


You can modify the way the logs contain information. Here is the typical setting and the comments in the file will help you figure out the changes you may want.

SecAuditLogParts "ABCFHZ"


Here is a description taken from the config file.

A - audit log header (mandatory)

B - request headers

C - request body (present only if the request body exists and ModSecurity is configured to intercept it)

E - intermediary response body (present only if ModSecurity is configured to intercept response bodies, and if the audit log engine is configured to record it). Intermediary response body is the same as the actual response body unless ModSecurity intercepts the intermediary response body, in which case the actual response body will contain the error message (either the Apache default error message, or the ErrorDocument page).

F - final response headers (excluding the Date and Server headers, which are always added by Apache in the late stage of content delivery).

H - audit log trailer

I - This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don't want to have (often large) files stored in your audit logs.

Z - final boundary, signifies the end of the entry (mandatory)


Now setup the configuration you need to access the site. This will eliminate any other IPs from accessing your Nagios web interface. Thus your security is greatly enhanced.



You will enter in this file, the last to be processed, the

SecRule REMOTE_ADDR "^192\.168\.0\.103$" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

SecRule REMOTE_ADDR "^127\.0\.0\.1$" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly


Note that not only are you adding the IP Address of any sites that will access Nagios, but you must also add the localhost so that Nagios can monitor the HTTP on the localhost.


What Difference Does ModSecurity Make on Nagios?

Here is a default install of ModSecurity tested with nikto. In the test nothing has been done with ModSecurity except turn it on.


This is a default Nagios 3.2.3 install with no security added. Note the Allowed HTTP Methods.

perl -h

- Nikto v2.1.4


+ Target IP:

+ Target Hostname:

+ Target Port: 80

+ Start Time: 2011-03-12 09:17:51


+ Server: Apache/2.2.3 (CentOS)

+ Apache/2.2.3 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.


+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST

+ OSVDB-3268: /icons/: Directory indexing found.

+ OSVDB-3233: /icons/README: Apache default file found.

+ 6448 items checked: 1 error(s) and 5 item(s) reported on remote host

+ End Time: 2011-03-12 09:18:18 (27 seconds)


+ 1 host(s) tested


This Nagios install has ModSecurity added by simply turning it on and disguising the operating system. The return information is that is this a Microsoft server (which it is not) and that almost all options to attack this Nagios instance are eliminated with ModSecurity without making any real adjustments.


perl -h

- Nikto v2.1.4


+ Target IP:

+ Target Hostname:

+ Target Port: 80

+ Start Time: 2011-03-12 09:24:10


+ Server: Microsoft-IIS/7.0

+ No CGI Directories found (use '-C all' to force check all possible dirs)

+ Microsoft-IIS/7.0 appears to be outdated (4.0 for NT 4, 5.0 for Win2k, current is at least 7.5)

+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST

+ 6448 items checked: 1 error(s) and 2 item(s) reported on remote host

+ End Time: 2011-03-12 09:24:51 (41 seconds)




+ 1 host(s) tested

ModSecurity even with a default install provides a powerful tool to protect your Nagios installation. If you are interested in live training on how to configure Nagios with ModSecurity see the Advanced Nagios Class.