Protecting Nagios From Zero-Day Exploits with ModSecurity
| 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
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.
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.
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.
Now unpack the file and move into the directory that is created.
Run the configure script.
Compile with make.
Install ModSecurity.
The libraries will be installed in:
Edit the /etc/httpd/conf/httpd.conf file and add these lines.
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:
Edit the /etc/httpd/conf/httpd.conf file to include the configuration files in the directory you created.
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.
You should see the rules in the /etc/httpd/conf.d/modsecurity directory, something like this:
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.
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.
When you make changes, save the settings and then restart Apache for the changes to take effect.
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.
SecAuditLogParts ABCFHZ SecAuditLogType Serial SecAuditLogRelevantStatus ^(?:5|4\d[^4]) SecDataDir /var/log/httpd/data SecAuditEngine RelevantOnly
Serial will allow you one file that will contain all events. If you want individual file you could change it to “Concurrent”.
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.
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
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.
+ 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) ---------------------------------------------------------------------------
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. |
