Author Archive for Spenser Reinhardt

Using the New SLA Report within Nagios XI 2014

New to Nagios XI 2014, is the ability to generate reports based on service level agreement (SLA) statistics. In addition to the already included Availability Report, the SLA Report gives you the ability to prove, via already monitored hosts and services within your Nagios system, that you are meeting or exceeding those pesky up-time agreements.

Options for SLA Reporting in Nagios 2014

As per traditional Nagios XI reporting capabilities, there are a wide variety of included time periods that will fit most use cases, as well as the ability to generate reports based on custom time periods. Reports can also be filtered by Host, Hostgroup, and Servicegroup for maximum flexibility when only specific hosts and services need to have reports generated. The final important aspect when generating a report is the modifiable SLA Target value. This allows you up to 5 points of precision when generating reports and can fully calculate the five 9s(99.999%) used in so many cases.

Continue reading ‘Using the New SLA Report within Nagios XI 2014’

Check Out the New Scheduled Backups Component in Nagios XI 2014

One of the coolest new features in Nagios XI 2014, is the Scheduled Backups Component. Backups may not sound cool and exciting, but in the event that your Nagios system has a major issue, or you want to restore on a fresh system, having off-disk backups can be a lifesaver. The Scheduled Backups Component also makes backups extremely easy and straight forward! Are you excited yet? If not, you’ll get there once we are done going through the many available options.

To get started head over to your local Nagios XI machine, and log into the web interface. Once you’re in, open up the Admin page and select Scheduled Backups, down on the bottom left area of your interface. You should see all three backup options are initially disabled, and there is currently no last backup size, as none have been run.

Nagios XI 2014 Scheduled Backup Component

Continue reading ‘Check Out the New Scheduled Backups Component in Nagios XI 2014’

Heartbleed: One Bug to Rule Them All

If you’ve missed the news in the last few days, OpenSSL has been found to contain a rather large issue in it’s implementation of TLSv1.1 and TLS1.2 for versions 1.0.1 through 1.0.1f and 1.0.2-beta. Thankfully, no other versions contain this issue and due to responsible disclosure, a patch is already available in the form of OpenSSL 1.0.1g, which many distributions are already making available via standard package management, such as yum and apt.

As for the juicy details… Heartbleed is a vulnerability caused by a missing bounds check and lack of validation, with the TLS heartbeat extension, that allows for up to 64k of memory to be leaked to an attacker. This is done via initializing a TLS connection over TCP or UDP. When this connection is begun, a heartbeat is shared between the client and server to validate that they are both in good working order. If a malformed, specifically empty, heartbeat is sent, the responding client or server will attempt to copy memory from a packet that is not available and instead respond with data that was previously at the same location that the packet should have been located in memory on the victim’s system. The process is not limited to a newly initialized connection and may be repeated at any point in time with existing connections as well. This could result in leaked memory containing rather benign large chunks of empty memory or severe issues such as private encryption keys, session id’s, passwords, and anything else that might be in the victim’s memory.

Just to clarify, this can affect both clients and servers. Yes, your Android phone’s web browser is just as affected as your Apache web server or OpenLDAP server. So, while updating your OpenSSL version, firmware and operating system are extremely important, one must also consider applications and services that ship with internal versions of OpenSSL or include libraries with compilation that standard updates may not correct.

Resolving this on most systems including current CentOS, RHEL, and Debian based distributions can already be found via standard updates with the included package managers. Systems that do not currently provide updated versions of OpenSSL can be manually updated by building version 1.0.1g from source or building previous versions with the -DOPENSSL_NO_HEARTBEATS flag. In the case of embedded systems such as switches, routers and phones, a firmware update request may have to be made to the vendor directly.

After seeing the large effect this particular bug is having worldwide, we decided to modify existing proof of concept code and provide Nagios users with an automated way to check your systems. Through a Nagios plugin, you can now validate whether your TCP services are vulnerable to the bug with both TLSv1.1 and TLSv1.2. Soon to be implemented updates will include checking of STARTTLS vulnerabilities and UDP connections.

Without further ado, we present the check_heartbleed plugin and heartbleed testing page.

Nagios Exchange: check_heartbleed.py
Nagios.com/heartbleed-tester

Securing Nagios XI Web Front-End with Mod_Security

Today we’re going to walk-through installing a web application firewall for Nagios XI. While not mandatory, this is an important task for anyone with a Nagios XI interface that is accessible through the internet. We do our best to create a secure application and make every effort to protect the data accessible via our software. However, mistakes are made and zero-day exploits do happen, as such, implementing additional measures such as mod_security is a great way to add additional difficulty for any potential attackers.

Mod_Security, is an Apache module that enables a host based web application firewall(waf) before any web traffic actually touches the applications served by Apache. This allows attacks such as sql injection(sqli), cross-site scripting(xss), cross-site request forgery(csrf), and many others to be detected and stopped before they have a chance to effect the web application and back-end databases. In the case of Nagios XI we are most worried about things like sqli, xss, command injection, remote and local file inclusion, and path traversal, as these have the most potential to take or modify vital data or gain access to the server. Mod_Security comes with list of predefined set of rules, that companies like Trustwave and groups like OWASP, regularly submit to and maintain. The module and rules definitions are entirely open source, although there are paid variations of the rules as well.

Setting up Mod_Security to protect your Nagios XI interface is pretty straightforward. The general idea is to install yum provided packages, disable some rules that cause issues with Nagios functionality, and restart Apache. Shall we begin?

1) Install Mod_Security packages.

yum install mod_security_crs-extras mod_security mod_security_crs

2) Download the base exclusion configuration for Apache, and move to the correct location.

cd /tmp

wget http://assets.nagios.com/downloads/nagiosxi/misc/mod_security_excluded_rules.conf

cp /tmp/mod_security_excluded_rules.conf /etc/httpd/conf.d/

3) Restart Apache and verify Nagios is working properly.

service httpd restart

Browse to your Nagios XI server and verify login and that everything looks normal.

Further documentation and troubleshooting can be found at: Integrating Mod_Security with Nagios XI