Implementing Security Controls via Nagios

In my last post, I gave some inputs about  the implementation of  basic security. It can be increased by following simple rules and procedures. This was purely theoretical. So, I decided to continue on this topic and show you how basic security checks can be implemented without spending too much money! They are two types of control that can be deployed: preventive and detective controls. Their goals are different. Preventive (or proactive) controls attempt to deter or prevent undesirable events from occurring. Example: data loss prevention. Detective controls, on the other hand, attempt to detect undesirable acts. Example: they provide evidence that a loss has occurred but do not prevent a loss from occurring. The first type is more complex to deploy, let’s focus on detective controls.

To achieve this, I’ll use Nagios. This open-source project is described as follows on the website:

“Nagios is a powerful monitoring system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes.“

Nagios is built on a modular and powerful plugins architecture. The core process, based on its configuration files, manages a set of small piece of codes – the plugins. They goal is to collect some information and send it to the core process. This one will take decisions based on the results and format them in convenient reports:

Nagios is able to monitor almost all aspect of your IT infrastructure. I often call this “bits & bytes” monitoring. Examples of checks that can be performed with standard plugins:

• Host availability
• Port availability
• Process running
• CPU, memory, file systems usage
• Connected  users, number of processes
• Standard network services (SMTP, HTTP, FTP, …)
• …

Even if the standard plugins provided with Nagios do not focus on security, let’s see how basic plugins can be used to detect suspicious activities!

In the first examples, let’s focus on websites. The plugin “check_http” performs HTTP requests to a web server to detect if it is running properly. But some interesting command line flags could be used to implement security tests:

The flag “–string” can be used to check if a string is present in the web server answer (the returned HTML code). This could be used to check if a web page has changed or was defaced. Just add a hidden string in your HTML code like “<!– MySecretTag //–>” and search for it:

  $ ./check_http -H www.acme.org  --string "MySecretTag"
  HTTP OK: HTTP/1.1 200 OK - 153480 bytes in 0.747 second response time \
  |time=0.746700s;;;0.000000 size=153480B;;;0
  $ ./check_http -H www.acme.org --string "MySecretTag2"
  HTTP CRITICAL: HTTP/1.1 200 OK - string 'MyScretTag2' not found on 'http://www.acme.org:80/' - \
  134451 bytes in 0.151 second response time |time=0.150900s;;;0.000000 size=153442B;;;0

Another interesting flag: “–onredirect“. It can generate an alert if an HTTP redirect (code 302) is detected:

  $ ./check_http -H www.acme.org -I 192.168.1.1 --onredirect=critical
  HTTP CRITICAL: HTTP/1.1 302 Found - 473 bytes in 0.100 second response time |\
  time=0.099954s;;;0.000000 size=473B;;;0

The “–certificate” flag is helpful to detect expired SSL certificates:

  $ ./check_http -H www.acme.org -I 192.168.1.1 --certificate=120 --ssl
  OK - Certificate will expire on 06/04/2012 16:09.

The following example will test of your URL filtering system works correctly. Prohibited URLs are redirected to a default denied page. By searching for a specific string, we could detect if the proxy is doing its job in the right way:

  $ ./check_http -H www.playboy.com -I proxy.acme.org -p 3128 -u http://www.playboy.com/ \
                 -s "Access Denied"
  HTTP OK HTTP/1.0 200 OK - 0.005 second response time | \
  time=0.004680s;;;0.000000 size=907B;;;0

The next examples are based on “check_dns“. The first one checks if the given FQDN resolves to a correct IP address. This is useful to detect DNS poisoning:

  $ ./check_dns -H www.acme.org -s 192.168.1.1 --expected-address=21.22.23.24
  DNS OK: 0.072 seconds response time. www.acme.org returns 21.22.23.24| \
  time=0.072270s;;;0.000000
  $ ./check_dns -H www.acme.org --expected-address=21.22.23.25
  DNS CRITICAL - expected '21.22.23.25' but got '21.22.23.24'

The “–expect-authority” is useful to detect of the tested DNS server is authoritative or not:

  $ ./check_dns -H www.acme.org -s 192.168.1.1 --expect-authority
  DNS CRITICAL - server  is not authoritative for www.acme.org

DHCP servers can also be tested. A basic check is to expect a DHCP offer from a know server:

  # ./check_dhcp -s 192.168.1.1

In 2008, I wrote a patch for the standard “check_dhcp” plugin to test the received DNS servers:

  # ./check_dhcp -s 192.168.254.1 -n 192.168.254.2
  CRITICAL: Received 1 DHCPOFFER(s),
    1 of 1 requested servers responded,
    ROGUE DNS WAS OFFERED (192.168.254.1),
    max lease time = 43200 sec.

Another one? You can also check if your log management tools are working properly with the “check_file_age” plugin. An alert will be generated if the file has not been updated for a while:

  $ ./check_file_age -w 1800 -c 3600 -f /var/ossec/logs/firewall/firewall.log
  FILE_AGE CRITICAL: /var/ossec/logs/firewall/firewall.log is 3612 seconds old \
  and 194503332 bytes

All those examples are based on standard plugins installed with Nagios. But they are plenty of interesting plugins available on exchange.nagios.org (in the security area) or alternate web sites. Writing your own Nagios plugins is very easy. They’re just some guidelines to follow. Two interesting examples:

• check_iptables – Checks if IPtables firewall rules are correctly loaded.
• check_ssl_faillogin – Checks ssh failure login attempts.

As you can see, it’s easy to implement some security checks using Nagios plugins. It’s certainly not a bullet-proof solution but it can help you in some specific cases! Last but not least, there is no magic behind Nagios. If alerts are generated, they must properly handled! Back to a classic problem…