| Subcribe via RSS

Nagios: Monitor more with NRPE (Nagios Remote Plugin Executor)

July 13th, 2009 | 3 Comments | Posted in General Site, Nagios, Networking, Security

Previous reading:

Nagios set-up guide #1 – http://vkernel.co.uk/?p=36

Nagios set-up guide #2 - http://vkernel.co.uk/?p=41

Using NRPE – Nagios Remote Plugin Executor, as the name suggests, allows us to remote execute plugins to retrieve data which will be of some use to us in a monitoring capacity.

Normal check_nt! style Nagios commands work well but are pretty primitive. NRPE provides you with the framework to do much much more with your newly created monitoring solution, such as monitoring Microsoft Exchange functions, check the status and completion state of Veritas and Symantec BackupExec products, and lots of other neat little features.

There is very little point me re-iterating how to install NRPE, as i will be only spoon feeding you information from this fantastic guide which i learned from – written by Jonathan Lydard and Tony Reix of bull.net : http://nfsv4.bullopensource.org/doc/admin_tools/latex_doc/installNRPE.pdf

The basic gist of the guide, is to download the NRPE files from http://www.nagios.org/download and do a “tar -zxvf nagiosfilename.tar.gz”.

Then “cd nagios…”. Once inside the nagios directory, do a “./configure”, followed by a “make && make install” command.

Next, run “cp src/nrpe /usr/bin”, “cp src/check_nrpe /usr/local/nagios/libexec” and “cp sample-config/nrpe.cfg /etc”. This copies all the relevant files into directories which will allow it to play nice and integrate with the original Nagios install. Finally, you will need to start the NRPE service as a daemon by running the following command “nrpe -c /etc/nrpe.cfg -d”.

Finally, open up “/usr/local/nagios/etc/objects/commands.cfg” and add the line:

# ’check_nrpe’ command definition define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

This is all you need to do on your server to enable NRPE. Easy eh, and people say Linux is hard (sarcasm). If you have any dependencies make sure you read the error and either google it (people will have the same issue as you), or try “yum install missing-package” or “apt-get install missing-package” for RHEL/CentOS and Ubuntu respectively, where missing-package is the package in the error message – i.e. gcc.

Now, you will need to configure the remote server to listen for NRPE and to respond to it correctly. Firstly, check and make sure that TCP 5666/5667 on the external IP address is being forwarded to the LAN IP of your remote host i.e. your server. This is the port NRPE listens on by default (Nagios listens on 12489 by default). Once we have ensured connectivity, you will need to open up your NSC.ini file (C:/Program Files/NSClient++). Towards the bottom of the file you will see the following lines:

[NRPE Handlers]
;# COMMAND DEFINITIONS
;# Command definitions that this daemon will run.
;# Can be either NRPE syntax:
command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
;# Or simplified syntax:
test=c:\test.bat foo $ARG1$ bar
;check_disk1=/usr/local/nagios/libexec/check_disk -w 5 -c 10
check_cpu=inject checkCPU warn=80 crit=90 5 10 15
...
nrpe_cpu=inject checkCPU warn=80 crit=90 5 10 15

These are the commands that Nagios via NRPE will be running, and the commands we will be specifying in our objects file. In order for the command to be retrievable, you need to uncomment it by deleting the “;” infront of it. Save the file and restart the “NSClient++” service via Services.msc (Start -> Run ->..).

On the Linux machine, you can now check NRPE connectivity to your host by running the commands:

cd /usr/local/nagios/libexec
./check_nrpe -H host.ip.add.ress -p 5666

You need to [c]hange [d]irectory libexec as thats where the check_nrpe executable is (so to speak). The check_nrpe then checks the external ip on port 5666 for NRPE feedback. You can check commands by doing:

./check_nrpe -H host.ip.add.ress -p 5666 -c nrpe_cpu

Which if working will return something like so:

OK CPU Load ok.|'5'=0%;80;90; '10'=0%;80;90; '15'=0%;80;90;

You can now add this NRPE connectivity into your monitoring of the server. If you navigate to “/usr/local/nagios/etc/objects/theserver.cfg” (where theserver is name of server), and add a new service to monitor a newly created NRPE command (in our example nrpe_cpu). You need to format it like so:

define service{
 use                     generic-service
 host_name               External Server on Site 1
 service_description     CPU Performance via NRPE
 check_command           check_nrpe!nrpe_cpu
 }

NOTE: The check_command is a pitfall for many. You need to specify it with “check_nrpe![command_specified_on_remote_server]“. Only an exclamation mark, nothing else. Once you have reloaded Nagios, the NRPE CPU will now be added to the list of items monitored on your server.

You can take this one step further, and monitor lots of other cool things. In this blog, I will talk about how I have setup Nagios to monitor Symantec and Veritas BackupExec scheduled backups.

Monitoring Symantec and Veritas BackupExec (V10 and V12) Backups with Nagios and NRPE

First of all, you need to navigate to the page http://exchange.nagios.org/directory/Plugins/Backup-and-Recovery/BackupExec/Symantec-BackupExec-job-check/details on the server where BackupExec is installed. You need to download the check_be.exe program and save it on C:/ root drive, i.e. the full path of check_be will be C:/check_be.exe (this is for simplicity). Secondly, you now need to go back into NSC.ini and where above we uncommented the default commands, add the command:

check_be=check_be.exe "C:\Program Files\Veritas\Backup Exec\Data" "Job Name" -w1 -c3

In this example we are using Veritas BackupExec, with a scheduled backup with a job name of “Job Name”. It is IMPERATIVE that this is correct, along with the C:/Progr… location. The location you need to put in here is the “..\Data\” folder within Symantec/Veritas\Backup Exec where all the .xml files are stored. Save the file, and restart the NSClient++ service via services.msc.

Now, on the “/usr/local/nagios/etc/objects/theserver.cfg” file (where theserver is your monitored server), we need to specify how we are going to monitor. We do this by the following entry:

define service{
host_name Server 1 on External Site
use generic-service
service_description BackupExec Job Check
check_command check_nrpe!check_be
normal_check_interval 60
retry_check_interval 30
register 0
}

This service will go off and check your backup status, and will return a warning for a failed backup or a green light for a successful backup. Save your .cfg and reload Nagios and go to your web interface to see your hard work in action. Next up I will go through advanced monitoring of Exchange 2003/2007 and mail servers in general.

Sam

Tags: , , ,

SPF – Sender Policy Framework

January 27th, 2009 | No Comments | Posted in Networking, Security

SPF can be used to allows software to identify messages that are or are not authorized to use the domain name in the SMTP HELO and MAIL FROM Return-Path commands, based on information published in a sender policy of the domain owner. Forged return paths are common in spam and result in backscatter. SPF is defined in RFC 4408. SPF is useful as it prevents spam as the email is not coming from an authorised domain, resulting in CIDR error returns to the sending party.

Shameless pull from Wikipedia on how to Implement SPF:

Implementation

Compliance with SPF consists of three loosely related tasks:

Publish a policy 
Domains identify the machines authorized to send e-mail on their behalf. Domains do this by adding additional records to their existing DNS information: every domain name that has an A record or MX record deserves a TXT record specifying the policy if it is used either in an email address or as HELO/EHLO argument.
Check and use SPF information 
Receivers use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.
Revise mail forwarding
Plain mail forwarding is not allowed by SPF. The alternatives are

  • remailing, i.e. replacing the original sender with one belonging to the local domain,
  • refusing, i.e. answering 551 User not local; please try <user@example.com>,
  • whitelisting on the target server, so that it will not refuse a forwarded message, and
  • Sender Rewriting Scheme, a more complicated mechanism that handles forwarding back-scatter back.

Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records are laid out like this (in typical DNS-syntax):

example.org. IN TXT "v=spf1 a mx -all"

“v=” defines the version of SPF used. The following words provide mechanisms to use to determine if a domain is eligible to send mail. The “a” and “mx” specify the systems permitted to send messages for the given domain. The “-all” at the end specifies that, if the previous mechanisms did not match, the message should be rejected.

 

 

Tags: , ,

Matt on Root CA Spoofing

January 10th, 2009 | No Comments | Posted in Security

A proof of concept attack has been presented at 25C3 (http://events.ccc.de/congress/2008/) showing that it is possible to use the well known MD5 hash collision insecurity to create your own ‘Certificate Authority’ (CA) signing certificate which is already accepted as trusted by most of the major browsers.

This allows an attacker with this root CA key to sign any other certificates he wishes, and all of these will be trusted by client browsers.

Scenario: In the past, if you went to your online banking website and a certificate error appeared, you would suspect something was up, possably you were being Man-in-the-middled and you were being proxied through a malicious machine, or alternativley your DNS had been poisoned and the site you were looking at was not the real bank’s site. You knew this BECAUSE of the certificate error and the attacker could do nothing about it because he was not able to get the private key of the bank’s certificate, or have his own bank certificate pair signed by a signing authority. The attacker just had to hope the user just clicked ‘Continue anyway’ etc.

However now, the attacker basically has the public and private key for a root CA certificate installed in your browser, he can sign any certificate pair he wants, and it will be trusted. How do you differentiate now? when both the real bank and attacker bank site come up with a rosy green SSL bill of health?

Creation of such a certificate only works against certificate authorities that still use MD5 (RapidSSL was used in this particular exploit) and with the release of this information, I should hope that the number of CA’s using this == 0 in a very short while :)

This has been a very crude and technically lacking explanation, however I suggest you read the following link for a much more indepth step by step process on how this was carried out;

http://www.win.tue.nl/hashclash/rogue-ca/

//Matt

Tags: , ,