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

Monitoring AKCP sensorProbe2 with Nagios XI Using SNMP

The sensorProbe2, sensorProbe4, sensorProbe8 and Probe8-X20 are intelligent devices for monitoring environmental variables, power, physical threads and security. Various AKCP intelligent sensors can be connected via the RJ45 connectors to the sensorProbe devices.

AKCP sensorProbe2 Web Interface

I would like to show you how easy it is to monitor a Dual Temperature/Humidity AKCP Sensor in Nagios XI via SNMP active checks and SNMP traps.

Continue reading ‘Monitoring AKCP sensorProbe2 with Nagios XI Using SNMP’

Meet Our Team: Jake Omann – Developer

Meet Jake Omann – one of our top notch developers here at Nagios Enterprises.  Jake is a key developer of many of our commercial-grade Nagios solutions, including Nagios XI, Nagios Network Analyzer, and Nagios Fusion.  His ability to patch bugs and crank out new cool features is nearly unrivaled!  Learn more about Jake, his role at Nagios, and plans for future projects in this week’s “Meet Our Team Interview.”

How to Passively Monitor Linux Machines with NRDS & Nagios XI

When active agent-based monitoring is not an option (because of a firewall, or security restriction), passive monitoring can provide the solution necessary to maintain network security and health. Today we will be discussing Nagios Remote Data Sender (NRDS) and how it can monitor Linux machines using passive check results. Passive results are sent to the Nagios Remote Data Processor (NRDP) server and processed in Nagios XI.

The NRDS client configuration can be managed centrally via the NRDS Config Manager Component in Nagios XI. Updated configuration files on the NRDS server are automatically picked up by all clients. The NRDS client runs on a cron job at a specified interval. Each time it runs, it will do the following:

  • Run all of the commands, specified in the config file
  • Send the results back to the Nagios XI server
  • Check if there is a new version of the configuration file on the Nagios XI server, and if there is one, it will download it
  • Download all of the plugins it needs from the server and install them on the client

In this article, I will show you how you can start monitoring a Linux host passively in three easy steps.

Step 1  - Adding Configuration

Go to Admin -> Monitoring Config -> NRDS Config Manager, click on Create Config, and select Linux from the Operating System drop-down menu.

Create NRDS Config

Continue reading ‘How to Passively Monitor Linux Machines with NRDS & Nagios XI’