Nagios is a powerful monitoring software package that basically consists of a web interface, a scheduling and evaluation engine, and various scripts or plug-ins. It is a widely used monitoring tool due to it’s flexibility and stability. I’ve personally seen it being used at numerous operation centers and set it up for countless clients. Until recently I had never used Ubuntu as a nagios host but that has changed and the difference in setup was worth documenting. This

I’ll be starting with a basic install of Ubuntu Server 10.10, specifically the Rackspace Cloud Server image and all commands will be run as root ( sudo su – ) to simplify things. After building it I like to make sure that I’m all patched up before starting.

apt-get update
apt-get upgrade


No Compiling?
If you have ever built a nagios system in the past you have probably had to go to nagios.org, download the source, compile it and install it. Ubuntu keeps nagios in their repository so there is no need for that.

apt-get install nagios3

This will prompt you to install a large number of packages including apache2, php, postfix, samba, and a slew of libraries all used to either present the nagios interface or support the underlying scripts. The install will prompt you to set the postfix ( mail ) settings. Internet Site and your domain name are probably what you want to use there. It will also prompt you for the nagiosadmin password, this is for the htaccess on the website. Once all of the packages are done installing you have a working nagios install. You can verify this by going to the web interface at http://your.server.ip/nagios3 use the username nagiosadmin and the password you set during the install.

Where are the files?
Traditionally nagios installs into /usr/local/nagios as a complete package. The way the ubuntu package installs these files are put into the larger os layout. Below is a rough cheat sheet as to where things ended up.

Purpose ………………. Old ………………………………. New
binary ………………… /usr/local/nagios/bin/nagios … /usr/sbin/nagios3
configuration files … /usr/local/nagios/etc ………….. /etc/nagios3 & /etc/nagios-plugins/config
plugins ………………. /usr/local/nagios/libexec …….. /usr/lib/nagios/plugins
website files ……….. /usr/local/nagios/share ……….. /usr/share/nagios3/htdocs
command file ……… /usr/local/nagios/var ………….. /var/lib/nagios3

One last hurdle.
At this point you have a very basic nagios system that is functioning, almost. If you are in the web interface and try to use any of the links under Service Commands or Host Commands you will see this error:

Sorry, but Nagios is currently not checking for external commands, so your command will not be committed!

Like the error says, external commands are not enabled. To fix this edit /etc/nagios3/nagios.cfg, find the line check_external_commands=0 and change it to check_external_commands=1

If you restart nagios now and try the commands again you will get another error:

Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!
The external command file may be missing, Nagios may not be running, and/or Nagios may not be checking external commands.
An error occurred while attempting to commit your command for processing.

This error is coming up because the apache process does not have the permission to write to the file that nagios checks for the commands you are requesting. The fix for this is to allow the www-data group read and execute permission to the directory where the command file lives and then add the www-data user to the nagios group because the command file gets created with nagios:nagios as the owner:group and 660 as the permissions.

chmod g+rx /var/lib/nagios3/rw
usermod -a -G nagios www-data
/etc/init.d/apache2 restart
/etc/init.d/nagios3 restart

Now the host and service commands will work and you can start configuring the rest of your nagios setup.

Zero day exploits, best explained here, will be coming out daily for the month of January, it seems, due to a security research firm in Russia. No matter what you think about their methods, this does highlight a fact that is sometimes forgotten, every running service presents the potential for an exploit. But without those services a computer is just an overpriced electric heater. So how do we protect ourselves against the unknown and unpatched? By being very careful about what our servers are running, only allowing access to the minimum number of resources required to get the job done, and having a plan for when your monitoring reports the service is down.

     Since linux distributions are varied in their installs I won’t go through each but most of the “friendly” distributions start, by default, a variety of services that may not be required but could potentially have exploits. While most of these don’t have a network component, combined with other exploits they could help open the server to attack. For example, Red Hat starts processes to monitor the software raid and logical volume manager even if you aren’t using them. It also starts processes for handling bluetooth devices, HP printers, and command line mouse support, even if you don’t have them. None of these should cause you any concern but if you don’t need them they don’t need to run at all.

     Most Apache HTTP server installs suffer from the same desire for usability, many modules are made available to the server by default. For example, you probably aren’t using LDAP authentication or WebDAV as part of your server but the modules for them are preloaded on most default installs. Identifying the modules that are required for your web site or application to run and then disabling the ones that are not will reduce your apache httpd footprint and therefore reduce your exposure.

     MySQL server doesn’t have the modular nature of our prior two examples but there are some steps that you can take to reduce your exposure. First off, after doing the install and setting the root password, remove the test user and database. These have no known exploits but aren’t needed. Second, ensure that your users are bound to a host instead of a wild card address, this makes sure that connections are only authorized from known hosts. Finally, if you are running mysql on the same host as your webserver and this is the only server that needs to access it, configure it to only listen on localhost ( There is no place like 127.0.0.1 ), this ensures that remote hosts cannot connect to your database even if your firewall fails.

     While I did focus on some of the more simple things that can be done to a LAMP server, this should give you an idea of what kind of changes can be made that won’t effect your service but will reduce your exposure footprint. Remember that before you make any changes you should do a backup and make copies of the files you are editing. We will see what this month brings as far as unpublished exploits and should also take this time to remember that not all exploits are published or patched, or even discovered yet.