Recently, news emerged about a 'vulnerability' in Nagios's NRPE 'agent' - http://1337day.com/exploit/22156
Essentially, you can use it to write files or items to /tmp (or any 'write all' directly ('777')) as below:nagios@nagios-server:/usr/local/nagios/libexec# /usr/local/nagios/libexec/check_nrpe -H myServer -c check_users -a "`echo -e "\x0a touch /tmp/vulntest "` #" 4 root@nagios-server:/usr/local/nagios/libexec#
Then if you look on your 'monitored server', you'll see:root@myServer:/proc# cd /tmp/ root@myServer:/tmp# ls -la total 24 drwxrwxrwt 4 root root 4096 Apr 20 20:24 . drwxr-xr-x 22 root root 4096 Apr 18 10:30 .. -rw-r--r-- 1 nagios nagios 0 Apr 20 20:25 vulntest root@myServer:/tmp#
This isnt best - as, has been seen, some pretty bad people can use this to put all kinds of bitcoin mining rubbish on there, amongst other things. Now, this only works because /tmp is writable to everyone (even on my test server, see below):root@server:/# ls -la | grep tmp drwxrwxrwt 4 root root 4096 Apr 20 20:24 tmp root@server:/#
So - answer number 1 - secure it! Now, if your savvy and use a config management tool like Puppet, Chef, Ansible etc then you can do this en-masse. For me, ive only got the one test server, so i just edited /etc/fstab:/dev/sda7 /tmp ext3 nosuid,noexec,nodev,rw 0 0
This stops executables running from /tmp, neither any suid programs (more information here): http://www.techrepublic.com/blog/linux-and-open-source/secure-temporary-files-in-linux/171/#.
Next step - answer number 2 - secure your boxes with a firewall. NRPE agents should ONLY be accessible from the Nagios monitoring server. The simplest way is to use iptables on the box:iptables -I INPUT 2 -s 192.168.200.201 -p tcp --dport 5666 -j ACCEPT
And reject NRPE from any other server. This means, only your Nagios server can access the box via 5666 - so, unless your monitoring server gets compromised - you should be in good shape.
So - /tmp isnt writable, and no-one can run check_nrpe against the box except your monitoring server.
Finally - look at SELinux if your using RHEL/Centos and the likes, and also look at this guide here: http://nagios.sourceforge.net/docs/3_0/security.html
At the end of the day, your network is only as secure as you make it - therefore i'd recommend a review of who can access your internal networks, HOW they got access (Firewalls, NAT, etc) and a review of your IPS/IDS if you are experiencing this issue.
Also - this may be of interest in the future - check_by_ssh - http://www.techrepublic.com/blog/linux-and-open-source/remotely-monitor-servers-with-the-nagios-check-by-ssh-plugin/.
We are currently looking at a patch for this issue in the coming days, so stay tuned to Twitter/Opsview forums for more on this issue.