Merging Infrastructure and Traffic Monitoring: Integrating ntopng with Icinga

Posted · Add Comment

Icinga2 is an open source monitoring system which checks the availability of hosts and services, notifies users of outages and generates performance data for reporting. Thanks to its scalability and extensibility, it has become very popular (as Nagios successor) and suitable to monitor complex environments, even across multiple locations.

Although popular, it falls short when it comes to monitor how the network is being used by certain host. There are several plugins for network monitoring available both in the Icinga Template Library and in the Icinga Exchange, however, they only provide very limited checks such as interfaces throughput, errors, or up-or-down status. Other plugins are available to monitor the status of services such as HTTP/HTTPS web servers or DNS servers, but again they don’t tell anything really valuable apart from a simple green-or-red/working-or-not-working flag.

We have the experience and the technology to tell additional, valuable information on how a particular host or service is being used, network-wise. For example, we can tell if a particular host is undergoing a SYN flood attack, if a certain webserver is being accessed by a blacklisted or malware IP address, or if a DNS server is being abused. This technology is ready and comes with one of our most popular tools ntopng. So the point was, how to deliver this extra knowledge from ntopng straight into Icinga2? Well, writing an Icinga2 plugin could have done the trick.

The basic idea behind writing a plugin is that, given any Icinga2 monitored host with IP address a.b.c.d, it is possible to leverage the plugin to connect to ntopng and extract a.b.c.d network status and health, returning such information to Icinga2 which, in turn, can use it to decide on the status of the host and its services.

ntopng Icinga2 Plugin

The Icinga2 plugin we have decided to write connects to the ntopng REST API to query for host alerts. Specifically, it queries:

  • Host Engaged Alerts to capture ongoing host network issues (for example, the host is a victim of a SYN flood attack)
  • Host Flow Alerts to capture suspicious or malicious flows involving a particular host (for example, the host has been contacted by a blacklisted IP).

The plugin code is available at https://github.com/ntop/ntopng/tree/dev/tools/icinga2 along with other files necessary for Icinga2 to properly interface with the plugin.

Setting Up the ntopng Icinga2 Plugin

To set up the plugin, assuming you’ve already an Icinga2 instance up and running, perform the following steps:

Download the plugin file check_ntopng.py into the PluginContribDir directory. The path to this directory can be found inside Icinga2 constants.conf file, which is typically located under /etc/icinga2/ under Linux.

cat /etc/icinga2/constants.conf | grep PluginContribDir

const PluginContribDir = "/usr/lib/nagios/plugins"

In this example, the PluginContribDir is /usr/lib/nagios/plugins.

Once the plugin is in place, it is necessary to download file check_ntopng_command.conf in /etc/icinga2/conf.d/ or in any other directory which is read by Icinga2 upon startup. The file contains the definition of a CheckCommand object, necessary to tell Icinga2 how to interface with the plugin.

Then, download and place file check_ntopng_service.conf in /etc/icinga2/conf.d/ or in any other directory which Icinga2 is aware of. This file contains the definition of two Service objects, one to check for host engaged alerts ("ntopng-icinga-host-health") and another one to check for host flow alerts ("ntopng-icinga-host-flows-health"). Those two files will automatically apply the services to all the Icinga2 monitored hosts.

Finally, a bunch of constants should be configured to tell Icinga2 how to properly reach and authenticate to the ntopng REST API. Such constants go inside file constants.conf, the same file used above to locate the PluginContribDir directory.

Constants are the following

# cat /etc/icinga2/constants.conf | grep Ntopng
/* Ntopng */
const NtopngHost = "127.0.0.1"
const NtopngPort = 3000
const NtopngInterfaceId = 0
const NtopngUser = "admin"
const NtopngPassword = "admin1"
const NtopngUseSsl = false
const NtopngUnsecureSsl = false

NtopngHost and NtopngPort tell Icinga2 how to connect to the ntopng REST API and NtopngUseSsl whether SSL has to be used for the connection (NtopngUnsecureSsl set to true prevents the plugin from checking SSL certificates validity). When the ntopng authentication is enabled, NtopngUser and NtopngPassword are necessary to indicate a user/password pair which will be used by Icinga2 to authenticate to the REST API. Finally, NtopngInterfaceId is used to tell Icinga2 the id of the ntopng interface which is responsible for the monitoring of traffic.

Running Plugin Checks

Let’s see now how this plugin works and what we can expect from it. Let’s assume Icinga2 monitored host with address 192.168.2.222 is trying to contact a malware host, maybe because it has been infected.

Before the contact, service "ntopng-icinga-host-flows-health" is OK

But as soon as 192.168.2.222 contacts a malware host (contact which has been simulated by pinging one of the hosts in blacklist for the sake of this example), the service becomes CRITICAL and all the necessary notifications will be sent by Icinga2

At this point, to have additional information, one can jump into the ntopng web user interface to find this malware flow among the host flow alerts

Similarly, let’s assume 192.168.2.222 has been configured, in ntopng, to be considered a victim of a SYN flood when it receives more than 10 SYN per second for three consecutive seconds.

Before the SYN flood, service "ntopng-icinga-host-health" is OK

But as soon as 192.168.2.222 becomes a victim of the SYN flood (the SYN flood has been simulated, for the sake of this example, with nmap -sS 192.168.2.222), the service becomes CRITICAL

Again, to have additional information, one can jump into the ntopng web user interface where this alert will show up among the host engaged alerts

Conclusion

We believe this plugin is the first step towards making Icinga2 not just a tool which checks the availability of hosts and services, but also a tool which gives extended information on how such hosts and services are being used from a network perspective.

Feel free to try the plugin and give us feedback!