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

wget http://sourceforge.net/projects/mod-security/files/modsecurity-apache/2.5.13/modsecurity-apache_2.5.13.tar.gz/download

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.

./configure

Compile with make.

make

 

Install ModSecurity.

make install

 

The libraries will be installed in:

/usr/lib/httpd/modules

 

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

LoadModule unique_id_module modules/mod_unique_id.so

LoadFile /usr/lib/libxml2.so

LoadModule security2_module modules/mod_security2.so

 

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:

modsecurity_35_bad_robots.data

modsecurity_35_scanners.data

modsecurity_40_generic_attacks.data

modsecurity_41_sql_injection_attacks.data

modsecurity_42_comment_spam.data

modsecurity_46_et_sql_injection.data

modsecurity_46_et_web_rules.data

modsecurity_50_outbound.data

modsecurity_50_outbound_malware.data

modsecurity_crs_10_config.conf

modsecurity_crs_20_protocol_violations.conf

modsecurity_crs_21_protocol_anomalies.conf

modsecurity_crs_23_request_limits.conf

modsecurity_crs_30_http_policy.conf

modsecurity_crs_35_bad_robots.conf

modsecurity_crs_40_generic_attacks.conf

modsecurity_crs_41_phpids_converter.conf

modsecurity_crs_41_phpids_filters.conf

modsecurity_crs_41_sql_injection_attacks.conf

modsecurity_crs_41_xss_attacks.conf

modsecurity_crs_42_tight_security.conf

modsecurity_crs_45_trojans.conf

modsecurity_crs_47_common_exceptions.conf

modsecurity_crs_48_local_exceptions.conf

modsecurity_crs_49_enforcement.conf

modsecurity_crs_49_inbound_blocking.conf

modsecurity_crs_50_outbound.conf

modsecurity_crs_59_outbound_blocking.conf

 

 

modsecurity_crs_60_correlation.conf

 

Configuration

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.

modsecurity_crs_10_config.conf

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.

modsecurity_crs_15_customrules.conf

# 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.

modsecurity_crs_65_custom.conf

 

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 nikto.pl -h 192.168.5.163

- Nikto v2.1.4

---------------------------------------------------------------------------

+ Target IP: 192.168.5.163

+ Target Hostname: 192.168.5.163

+ 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.

+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE

+ 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 nikto.pl -h 192.168.5.33

- Nikto v2.1.4

---------------------------------------------------------------------------

+ Target IP: 192.168.5.33

+ Target Hostname: 192.168.5.33

+ 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.