Securing the Pi

For any system you connect to a network, you should be sensitive to security best practices. In the case of the Pi, you want to make a few changes that will lessen the chances your box becomes a cybercriminal casualty. I recommend three actions, but in the interest of focusing on the configuration at hand, I'll not cover them other than to mention them:

1. Harden your SSH configuration with key-based authentication – or even multifactor authentication with YubiKey or other technology – and a strong password.

2. Create firewall rules that only open what you required on both your servers and your network firewall.

3. Set up automated updates.

Obviously, there is no such thing as a secure system other than one that is powered off, disconnected from any network, and encased in a Faraday cage. Nonetheless, you should always do your part to avoid the propagation of malicious code.

Having default users are a bad security practice, so I usually opt either to disable the default accounts or change the username. In this case, I add a new user and put it in the sudo file, so the user can sudo as needed,

sudo adduser sweetpi
sudo adduser sweetpi sudo

and then disallow the default Pi account. Thereafter, I suggest you deny that user any access via your SSH configuration.

Once your system is set up, patched, and ready to go, you can install Icinga and its related applications.

Installing Icinga

Icinga installs easily with:

sudo apt-get install icinga icinga-doc

Be sure to set a secure database and icingaadmin password and make note of them.

I have specifically not set up the IDO2DB utility [11] in this configuration because it imposed too much of a load on my Raspberry Pi. The Icinga Data Out Database is storage for historical data for add-ons and the web interface.

Once everything is installed, you can go to the browser of your choice, visit http://ipaddressofofyourserver/icinga , enter the username icingaadmin , and enter the password you selected during setup.

As you can see in the Tactical Overview window (Figure 3), Icinga monitors the system on which it is installed by default. You will see it is already performing ICMP (ping) checks and displaying system load and disk space.

Figure 3: The Icinga Tactical Overview window.

This tactical view gives you a view of the health of the hosts and services on your network and is an overarching view of your network status. I'll return to this interface later after a few nodes have been added to the configuration.

Configuring Icinga

Out of the box, Icinga does not come configured other than to monitor the node on which it is installed. However, before jumping directly into an explanation of configuration, I will explore the application and its options. All configuration is accomplished via the command line [12]. Like any other Linux/Unix application, Icinga configuration is accomplished via text-based files [13]. Icinga configuration files have .cfg extensions, and they're centrally located in /etc/icinga.

The main configuration file is icinga.cfg [14]. Icinga configuration comprises two main types: resource files and object files.

• Resource files. The resource.cfg file contains user-defined macros that store usernames, passwords, and other items used in command definitions.
• Object configuration files. These files are set in the icinga.cfg file, and the object definitions are found in /etc/icinga/objects/. Objects are defined in simple text files that describe the nodes to be monitored, relevant services, contact information, and even alert modes. All of these objects together define the network monitoring setup.

Several third-party open source projects provide an add-on web interface for configuring Icinga. If that is your need, both NConf [15] and NagiosQL [16] are easy to install and feature rich options.