If you have enjoyed ntopng 2.x, we believe you will like 3.0 even more as we have worked for almost one year to this release. We have modified many things, improved security in ntopng (in the cybersecurity days this is the least we could do), added layer 2 visibility, improved metrics calculations, added alerts support (even on the go), improved significantly the Windows version (yes Win 10 is supported out of the box), improved performance, reworked the GUI in many aspects, improved significantly the inline traffic mode, improved FreeBSD support.

As many professional users requested us specific features such as high-speed flow export in databases or improved reports, we have created a new version named ntopng Enterprise that is now part of the ntopng product family (community and professional). You can find all differences in features across the various product editions in the ntopng page. If you are an existing ntopng pro user, you can contact us for upgrade information.

If you are interested to learn more about the 3.0 improvements, below you can find the whole changelog.

Enjoy ntopng!

3.0 Changelog

• New features
  • Layer-2 Devices
    • MAC devices page
    • Implemented MAC last seen tracking in redis
    • Manufacturer filter and sort
  • Host pools (logical groups of hosts)
  • Logstash flow export extension
  • Implemented data anonymization: hosts and top sites
  • Implements CPU load average and memory usage
  • Virtual Interfaces
    • ZMQ: disaggregate based on probeIP or ingress interfaceId
    • Packet: disaggregate on VLANId
  • ElasticSearch and MySQL flow export statistics
  • Tiny Flows
  • Alerts
    • Implements alerts on a per-interface per-vlan basis
    • Global alert thresolds for all local hosts/interfaces/local networks
    • LUA alerts generation
    • Adds hosts stateful syn attacks alerts
    • Visualization/Retrieval of Host Alerts
    • Added the ability to generate alert when ntopng detects traffic produced by malware hosts
    • Slack integration: send alerts to slack
    • Alerts for anomalous flows
    • Host blacklisted alerts
    • Alerts delete by type, older than, by host
    • SSL certificates mismatch alerts generation
  • Implement SSL/TLS handshake detection
  • Integrated MSDN support
  • Implemented DHCP dissection for name resolution
  • Traffic bridging
    • Per host pool, per host pool member policies
    • Per L7 protocol category policies
    • Flashstart categories to block
    • Time and Traffic quotas
    • Support to google Safe Search DNS
    • Ability to set custom DNS
  • Captive portal
    • Limited lifetime users
    • Support for pc, kindle, android, ipad devices
  • SNMP
    • Periodic SNMP device monitoring and polling
    • Historical SNMP timeseries
    • Host-to-SNMP devices mapping
  • Daily/Weekly/Monthly Traffic Report: per host, interface, network
  • Added ability to define host blacklists
  • DNS flow characterization with FlashStart (www.flashstart.it)
  • Flow LUA scripts: on flow creation, protocol detected, expire
  • Periodic MySQL flows aggregation
  • Batched MySQL flows insertions
  • sFlow device/interface counters
  • Implementation of flow devices stats
• Improvements
  • Allows web server binding to system ports for non-privileged users
  • Improved VLAN support
  • Improved IPv6 support
  • Implements a script to add users from the command line
  • View interfaces rework
  • Reported number of Layer-2 devices in ntopng footer
  • Preferences re-organization and search
  • Adds RIPE integration for Autonomous Systems
  • Search host by custom name
  • Move to the UTF-8 encoding
  • Make real-time statics refresh time configurable (footer, dashboard)
  • Adds support for localization (i18n)
  • Traffic bridging: improved stability
  • Traffic profiles: improved stability and data persistence
  • Charts
  • Improved historical graphs
  • Traffic report rework and optimizations
  • Improves the responsiveness and interactivity of historical exploration (ajax)
  • Stacked top hosts
  • Add ZMQ flows/sec graph
  • Profiles graphs
  • Implemented ICMP detailed stats for local hosts
  • ASN graphs: traffic and protocols history
  • ARP requests VS replies sent and received by hosts
  • Implement host TCP flags distribution
  • DNS packets ratio
  • FlashStart category graphs
  • Added ARP protocol in interface statistics
  • SNMP port graphs
• VoIP (nProbe required)
  • Changes and rework for SIP and RTP protocol
  • Adds VoIP SIP to RTP flow search
  • Improves VoIP visualization (RTP)
• Security Fixes
  • Disable TLS 1.0 (vulnerable) in mongoose
  • Disabled insecure cyphers in SSL (when using ntopng over SSL)
  • Hardens the code to prevent SQL injections
  • Enforce POST form CSRF to prevent programmer mistakes
  • Strict GET and POST parameters validation to prevent XSS
  • Prevent HTTP splitting attacks
  • Force default admin password change

Last week the NYC Metrics and Monitoring meetup invited ntop to give a talk. The topic was how to open ntopng so that it can become a gateway for producing network metrics that could be used by popular applications and frameworks such as Snap-io, Prometheus or Influx. The first result of this activity is the integration of ntopng with Grafana that we plan to complete in July.

Here you can see the presentation slides  where you can have an idea of the work we’re doing. If you are interested in using this preliminary work, you can find all details here.

Enjoy!

Fritz!Box routers are popular devices that many people use to connect to the Internet. Inside these routers there is a hidden (i.e. not accessible from the router web admin page, but that you access directly with a web browser by writing the whole URL) URL http://192.168.2.1/html/capture.html (BTW replace the 192.168.2.1 IP address with your Fritz!Box router IP if you have changed it) that can be used to dump router traffic in pcap format.

While pcaps are good for troubleshooting, most people need to know what is happening on their network in realtime, so they can spot for instance bandwidth hogs or high-latency communications. In essence we need to tell ntopng to analyse traffic flowing in our router. This is exactly what the fritzdump.sh script is doing:  connect to your Fritz!Box router, start the packet capture process and spawn ntopng for analyzing the network traffic by reading traffic from a pipe (see the picture below).

This is a great solution for home and small business users that can monitor the network traffic in realtime without having to deploy network probes, taps etc. that are not affordable (in terms of complexity but sometimes also from the price standpoint) on most small networks.

Enjoy!

Using nProbe in combination with ntopng is a common practice. The benefits of this combination are manyfold and include:

• A complete decoupling of monitoring activities (taking place on the nProbe) from visualization tasks (taking place on ntopng);
• The capability of building distributed deployments where multiple (remote) nProbe instances send monitored data towards one or more ntopng instances for visualization;
• A comprehensive support for the collection, harmonization and visualization of heterogeneous flow export protocols and technologies, including NetFlow V5/v9/V10 IPFIX and sFlow;
• Full support for any proprietary technology that sends custom fields over NetFlow V5/v9/V10 with visualization of data;
• Harmonization of diverse physical network interfaces and flow export protocols and technologies into a single, clear, JSON format sent over ZMQ to ntopng.

ntopng and nProbe communicate each other via a publish-subscribe mechanism implemented over ZMQ. Exchanged data contains both interface updates (e.g., the number of bytes and packets monitored) as well as network flows, obtained by monitoring physical interfaces (NIC cards) or by processing flow export technologies such as NetFlow.

Since flows sent over ZMQ are only those that active or recently expired, one has to store and archive them systematically for later accesses and analyses. Presently, ntopng offer rich historical flow exploration features when it is instructed to archive flows to MySQL (see part 1 and part 2 of the tutorial “Exploring Historical Data Using ntopng”). However, there are cases where MySQL flow export must be done directly on nProbe. Such cases include, but are not limited to:

• The capability of creating a database column for each nProbe template field — ntopng creates a fixed set of database columns;
• A MySQL database that is closer or more effectively reached from nProbe rather than from ntopng;
• A low-end ntopng device that couldn’t deal with massive/batched database insertions.

In the cases above, it is still desirable to have full access to the ntopng historical flow exploration features. Therefore ntopng must work seamlessly even when operating on top of a database created and used by nProbe for flow export.

Fortunately, this interoperability is accomplished transparently by mean of database table views. Just a couple of things are required. The first thing is to instruct ntopng to connect to the nprobe database using a special mysql-nprobe prefix in the -F option. The second thing is to ensure nProbe will create a minimum set of database columns as required by ntopng by specifying the macro @NTOPNG@ inside nProbe template. This macro will expand to the following set of fields:

%L7_PROTO %IPV4_SRC_ADDR %IPV4_DST_ADDR %L4_SRC_PORT %L4_DST_PORT %IPV6_SRC_ADDR %IPV6_DST_ADDR %IP_PROTOCOL_VERSION %PROTOCOL %IN_BYTES %IN_PKTS %OUT_BYTES %OUT_PKTS %FIRST_SWITCHED %LAST_SWITCHED %SRC_VLAN

Following is a working example that illustrates ntopng and nProbe configurations. Clearly, database connection parameters (host, user and password, schema name, and table name) must be the same on both sides.

./nprobe -i eno1 -T "@NTOPNG@" --mysql="localhost:ntopng:nf:root:root" --zmq tcp://127.0.0.1:5556 --zmq-probe-mode
./ntopng -i tcp://*:5556c -F "mysql-nprobe;localhost;ntopng;nf;root;root"

Note that when ntopng operates in this mode, it won’t export flows (no one want the same flows stored twice in the database). It will just visualize them.

Happy flow hunting!

This is to announce the release of the ntopng Grafana datasource that you can find on the grafana website. Using this plugin you can create a Grafana dashboard that fetches data from ntopng in a matter of clicks.

To set up the datasource visit Grafana Datasources page and select the green button Add a datasource. Select ntopng as the datasource Type in the page that opens.

The HTTP url must point to a running ntopng instance, to the endpoint /lua/modules/grafana. The Access method must be set to Direct. An example of a full HTTP url that assumes there is an ntopng instance running on localhostport 3001 is the following:

http://localhost:3001/lua/modules/grafana

Tick Basic Auth if your ntopng instance has authentication enabled and specify a username-password pair in fields User and Password. The pair must identify an ntopng user. Leave the Basic Auth checkbock unticked if ntopng has no authentication (--disable-login).

Finally, hit the button Save and Test to verify the datasource is working properly. A green message Success: Data souce is working appears to confirm the datasource is properly set up.

Supported metrics

Once the datasource is set up, ntopng metrics can be charted in any Grafana dashboard.

Supported metrics are:

• Interface metrics
• Host metrics

Metrics that identify an interface are prefixed with a interface_ that precedes the actual interface name. Similarly, metrics that identify an host are prefixed with a host_ followed by the actual host ip address.

Interface and host metrics have a suffix that contain the type of metric (i.e., traffic for traffic rates and traffic totals orallprotocols for layer-7 application protocol rates). The type of metric is followed by the unit of measure (i.e., bpsfor bits per second, pps for packets per second, and bytes).

Interface Metrics

Supported interface metrics are:

• Traffic rates, in bits and packets per second
• Traffic totals, both in Bytes and packets
• Application protocol rates, in bits per second

Host Metrics

Supported host metrics are:

• Traffic rate in bits per second
• Traffic total in Bytes
• Application protocol rates in bits per second.

Summary

• Grafana is one of the most widely known platforms for metrics monitoring (and alerting);
• ntopng version 3.1 natively integrates with Grafana thanks to a datasource plugin which is freely available;
• This article explains how to install and configure the ntopng datasource plugin, and how to build a dashboard for the visualization of ntopng-generated metrics.
• A video tutorial is available as well:

Introduction

Grafana is an open platform for analytics and visualization. An extremely-well engineered architecture makes it completely agnostic to the storage where data resides. This means that you can build beautiful dashboards by simultaneously pulling points from data sources such as ntopng, MySQL and Influxdb, just to name a few. Grafana interacts with tens of different data sources by means of datasource plugins. Those plugins provide a standardized way to deliver points to Grafana. ntopng implements one of those datasource plugins, to expose metrics of monitored interfaces and hosts, including throughput (bps and pps) and Layer-7 application protocols 
e.g., (Facebook, Youtube, etc).

Exposed Metrics

ntopng exposes metrics for monitored interfaces as well as for monitored hosts. Each metric is identifiable with a unique, self-explanatory string. In general, interface metrics are prefixed with the string interface_ while host metrics are prefixed with the string host_. Similarly, a suffix indicates the measurement unit. Specifically, _bps and _pps are used for bit and packet rates (i.e., the number of bits and packets per second), whereas _total_bytes and _total_packets are used for the total number of bytes and packets over time, respectively.

Currently, supported metrics carry traffic as well as Layer-7 application protocols metrics.

Traffic metrics exposed are:

• interface_<interface name>_traffic_bps
• interface_<interface name>_traffic_total_bytes
• interface_<interface name>_traffic_pps
• interface_<interface name>_traffic_total_packets
• host_<host ip>_interface_<interface name>_traffic_bps
• host_<host ip>_interface_<interface_name>_traffic_total_bytes

Layer-7 application protocol metrics exposed are:

• interface_<interface_name>_allprotocols_bps
• host_<host ip>_interface_<interface_name>_allprotocols_bps

To be able to use the aforementioned metrics inside Grafana dashboards, the ntopng datasource plugin must be installed and configured as explained below.

Configuring the ntopng Datasource

Prerequisites

• A running instance of Grafana version 4 or above;
• A running instance of ntopng version 3.1 or above.

Grafana and ntopng run on Linux and Windows, either on physical, virtualized or containerized environments. For Grafana installation instructions see Installing Grafana. ntopng can either be built from source, or installed as a package.

Installing the ntopng Datasource Plugin

Installing the ntopng Datasource plugin is as easy as

$ grafana-cli plugins install ntop-ntopng-datasource

Upon successful installation, you will receive a confimation message and you will have to restart Grafana

installing ntop-ntopng-datasource @ x.y.z
from url: https://grafana.com/api/plugins/ntop-ntopng-datasource/versions/x.y.z/download

Installed ntop-ntopng-datasource successfully

Restart grafana after installing plugins .

After restarting Grafana, you can connect to its web User Interface (UI) and visit the Plugins page. ntopng will be listed under the datasources tab.

Configuring the ntopng Datasource

A new datasource with type ntopng will be available once the ntopng datasource plugin is installed. Multiple ntopng datasources can be created to connect to several running ntopng instances. The list of configured datasources is available at the Grafana ‘Data Sources’ page. The following image shows two ntopng datasource configured with the aim of connecting to two different ntopng instances running on separate machines.

Adding a new ntopng datasource is a breeze. Just hit the ‘+ Add datasource’ button inside the Grafana ‘Data Sources’ page. This will open an ‘Edit Data Source’ page that can be used to specify ntopng connection parameters.

To configure the ntopng datasource select ntopng as the datasource Type and give it a mnemonic Name that will help you identifying the datasource connection. The Url in the HTTP settings must point to a running ntopng instance, to the endpoint /lua/modules/grafana. For example, to connect to an ntopng running on host devel on port 3001, you have to use url http://devel:3001/lua/modules/grafana.

The Access method must be set to direct. Tick Basic Auth if your ntopng instance has authentication enabled and specify a username-password pair in fields User and Password. The pair must identify an ntopng user. Leave the Basic Auth checkbock unticked if ntopng has no authentication (--disable-login).

Finally, hit the button Save and Test to verify the datasource is working properly. A green message Success: Data source is working will appear to confirm the datasource is properly set up.

The following screenshot highlights the connection to an ntopng instance running on host devel on port 3001.

Building a Dashboard

Once the datasource is properly set up, you can visualize ntopng timeseries in any of your Grafana dashboards. Dashboards are flexible ensembles of panels. Each panel is meant to visualize a single timeseries. Panels are added in any dashboard by clicking on the ‘Add Row’ button that will allow you to choose among the available panel types.

Currently, ntopng provides timeseries that can be used effectively to build ‘Chart’ and ‘Singlestat’ panels.

Adding an Interface Speed Panel

To add an interface speed panel, select ‘Graph’ in the available panel types. A graph panel with random data will be automatically added to the dashboard. Click on the ‘Panel Title’ and select ‘Edit’. A configuration page as the following will appear:

There is a ‘Test data: random walk’ timeseries with random data by default. Drop it by clicking on the bin. To add ntopng metrics select one of the ntopng datasources configured from the ‘Panel Data Source’ dropdown. In the following image, an ntopng datasource named lab-monitor is selected:

Once the datasource is selected, you can click the ‘Add query’ button and start type a metric name. Autocompletion will automatically show all the available metrics matching the typed text. In the image above, interface eno1 bps is picked among all timeseries available. As soon as the metric is chosen, a chart will be populated. However, as shown below, the chart is sill pretty basic and some extra work is needed to configure the axis unit of measure as well as the title.

To change the chart title select tab ‘General’ and input the title:

More important, to set the unit of measure of the y-axis select tab ‘Axes’ and pick ‘bits/sec‘ from the ‘Unit’ dropdown.

The final result is shown in the picture below

Adding an Interface Layer-7 Application Protocols Panel

To add an interface application protocols panel the above instructions apply. Just make sure select the interface metric ending in _allprotocols_bps. In addition, as this metric carry more than one timeseries (one per application protocol), it is recommended to stack them by ticking the ‘Stack’ checkbox under the ‘Display’ tab.

The final result will appear similar to the following image

Adding the Interface Average Speed Panel

Using a ‘Singlestat’ panel it is possible to crunch a metric using an aggregation function. To visualize the average speed, you can add a ‘Singlestat’ panel, select the interface traffic timeseries, and configure avg as ‘Stat’ in the ‘Options’ tab, as well as bits/sec in the ‘Unit’.

A Full ntopng Grafana Dashboard

By putting together all the panels introduced above, you can build a complete dashboard as the one shown here

Remember that you can combine panels created with ntopng with panes created from other datasources (e.g., MySQL or InfluxDb). There is no limit on how you can combine panels to create dashboards!

Conclusion

ntopng features an handy datasource plugin that exposes monitored metrics to Grafana. Visualizing ntopng metrics in Grafana will allow you to show ntopng data inside the beautiful Grafana UI, and will give you enough flexibility to mix and match ntopng data with other data sources.

Today we are glad to announce the new 3.2 stable release of ntopng. Among the most important new features available in this release, there is without any doubt an advanced network devices discovery functionality. Historically, ntopng has always been a fully passive monitoring tool. This release aims at complementing the information gathered from a purely passive packet capture with precious extra bits of data obtained by actively searching for devices. Network devices discovery glues together multiple techniques and heuristics, including ARP pinging, SNMP querying, SSDP discovery and MDNS names resolution. By opportunely combining the pieces of information obtained by actively probing network devices, ntopng is not only to discover them, but also to understand the services they provide as well as the operating system they run.

This is what the outcome of a active network device discovery looks like in ntopng.

For a detailed explanation of all the techniques and heuristics implemented, we refer the interested reader to this article.

ntopng release 3.2 is also incredibly more efficient when it comes to handling big traffic volumes. Indeed, I/O operations have been reduced to a great extent, thus alleviating the pressure on disks and, at the same time, making the software running faster. In addition, all the periodic activities that crunch hosts and interfaces traffic into time series data are now run by a thread pool that orchestrates their execution in parallel to fully leverage any modern multi-core system. The benefits of reduced I/O and parallel periodic activities execution together make ntopng sensibly more responsive also when browsing the web user interface.

As usual, ntopng installation instruction can be found at packages.ntop.org.

The complete list of changes introduced in this release is the following:

New features

• Support for the official ntopng Grafana datasource plugin
  • Plugin available at: https://grafana.com/plugins/ntop-ntopng-datasource
• Newtork devices discovery
  • Discovery of smartphones, laptops, IoT devices, routers, smart TVs, etc
  • Device type and operating system detection
  • ARP scan, SSDP dissection, Multicast DNS (MDNS) resolution
  • DHCP fingerprinting
• Adds an active flows page to the AS details
• Bridge mode
  • Enforcement of global per-pool time and byte quotas
  • Support of per-host traffic shapers
  • Added support for banned sites detection with informative splash screen
  • Implement per-host/mac/pool flow drop count
• nDPI traffic categories and RRDs
• Implements MySQL database interoperability between ntopng and nProbe

Improvements

• Flows sent by nProbe over ZMQ
  • Batched, compressed ZMQ flow format to optimize data exchange
  • Use of post-nat src/dst addresses and ports
  • Handles multiple balanced ZMQ endpoints
• Periodic tasks performed by a thread-pool to optimize cores utilization
• Hosts and devices are walked in batches to greatly reduce Lua VM memory
• Full systemd support for Debian, Ubuntu, Centos, and Raspbian
• Extended sFlow support to include sample packet drops and counter stats in interface views
• Stacked applications and categories charts for ASes, Networks, etc

Security Fixes

• More restrictive permissions for created files and directories
• Fix of a possible dissectHTTP reads beyond end of payload

The first important step to start with network monitoring is to analyze what we want to monitor and how to deploy the monitoring solution in the existing network.

Here are some important questions to ask ourselves before starting the actual monitoring:

• Do we need to monitor the entire network or just a specific segment?
• Do we already have network appliances with network flow export capabilities (e.g. NetFlow/sFlow devices)?
• Can we use port mirroring of a switch or a network TAP?
• Where are we deploying our network monitoring appliances to get visibility on the traffic of interest?
• Do we have a NAT/routers which possibly hides IP/MAC addresses? Can we place our monitor appliance before the actual NAT/router?
• Do we need full L7 application traffic analysis capabilities or we can go with a simpler port based approach?

In this article we will see how to deploy ntopng and optionally nProbe to fulfill some common network analysis requirements.

nProbe is a powerful network probe. It supports many standard flow formats as Netflow sFlow and IPFIX. nProbe itself does not provide a Graphical User Interface (GUI). When coupled with ntopng, however, it allows us to monitor traffic and display it on the ntopng GUI.

ntopng is a full-featured network monitoring tool. It provides a web GUI to access accurate monitoring data. It provides detailed views on active hosts, flows, IP addresses, Mac addresses, Autonomous systems. It cam be used to monitor and report live throughput, network and application latencies, Round Trip Time (RTT), TCP statistics (retransmissions, out of order packets, packet lost), and bytes and packets transmitted.

Let’s now review some of the most common network monitoring use cases with ntopng.

Monitoring Netflow/sFlow Traffic

If our network appliances supports the Netflow/sFlow flow export, we can send flows data to a remote server running ntopng. This setup is not appropriate if we need detailed L7 application dissection or per-packet realtime analysis. We will need to set up nProbe as an intermediate flow collector, which in turn will send flows to ntopng. The ntopng dashboard visualization will not be “real-time” actually as there are some export timeouts (both into nProbe and into the NetFlow appliance) involved.

In this example we have a Netflow capable router. We have to configure the router to export flows to nprobe. From the router admin interface (typically a web GUI), we configure Netflow export to our nProbe running server by specifying its IP address as well as a port, say 2055.

Now we have to configure nProbe to receive the Netflow data. We do this by creating the file /etc/nprobe/nprobe-none.conf on the nProbe host:

--zmq="tcp://*:5556"
-i=none
-n=none
--collector-port=2055

We are also telling nProbe to send the flows to ntopng. This intermediate step is needed as ntopng does not know talk Netflow so nProbe acts like a translator.

Now we have to set up ntopng. Let’s install ntopng and configure it to receive flows from nProbe. Let’s modify /etc/ntopng/ntopng.conf:

-i="tcp://127.0.0.1:5556"
--local-networks="172.16.1.0/24,172.16.2.0/24"

We are also telling ntopng which are the local networks to monitor, in this example 172.16.1.0/24 and 172.16.2.0/24. ntopng will mark hosts belonging to that networks as “local” and this will enable their historical data to be saved to disk.

After setting up the configuration files, we have to enable and start the system services:

systemctl enable ntopng
systemctl enable nprobe@none
systemctl restart ntopng
systemctl restart nprobe@none

If we have many Netflow appliances we can direct all of the to exports flows to our single nprobe instance. In ntopng, we can then split the incoming traffic by using the Dynamic Interfaces Disaggregation from the ntopng preferences.

Monitoring a Port Mirror/TAP

In this example we have an appliance which mirrors the packets using a SPAN port. With this setup we can perform full L7 packet analysis and get a realtime view of the traffic.

We only need to set up ntopng to listen from the network interface connected to the SPAN port. Ideally the network interface should not have an IP address as it should only be used to receive the mirrored traffic.

The ntopng setup is really simple: we only need to tell it to monitor the -interface connected to the span port. Supposing the interface is eth1, the correspondent /etc/ntopng/ntopng.conf file will be:

-i=eth1
--local-networks="192.168.1.0/24"

Remember to restart the ntopng service after applying the changes.

Monitoring Multiple Locations

We may need to deploy multiple probes in our network to capture traffic at different points. We can use a single ntopng to gather all the information from the probes. Let’s assume we have two nProbe instances running on two different hosts, one at IP 192.168.10.10 and the other on 192.168.20.20. ntopng runs on a separate host with IP address 1.2.3.4. We assume that the probes read traffic from local SPAN ports, connected on the interface eth0 of each probe.

The first nprobe configuration (/etc/nprobe/nprobe-eth0.conf on host 192.168.10.10) is:

--zmq="tcp://1.2.3.4:5556"
-i=eth0

The second nprobe configuration (/etc/nprobe/nprobe-eth0.conf on host 192.168.20.20) is:

--zmq="tcp://1.2.3.4:5557"
-i=eth0

The ntopng configuration file /etc/ntopng/ntopng.conf will contain:

-i="tcp://*:5556c"
-i="tcp://*:5557c"
--local-networks="192.168.10.0/24,192.168.20.0/24"

We enable and start the nprobe@eth0 service on both probes, then enable and start the ntopng service. The ntopng GUI will show two network interfaces, each one represents one remote probe and its related traffic.

For advanced nProbe and ntopng communication see https://www.ntop.org/nprobe/advanced-flow-collection-with-ntopng-and-nprobe/ .

Traditionally all ntop tools have manuals and user interface in English. As sometimes our users are not really familiar with it, we have decided to introduce user interface translation of the user interface so that we can make those users more comfortable when using ntopng. As the moment we have added support for Italian and German, but we might consider adding further languages in the future. When you first login to ntopng after installation you will notice that there is a new menu that allows you to set the language used by the admin user.

Inside the GUI you can also change the language by selecting in the menu settings (the one with the wheel icon) the entry “Manage Users” and setting the language in preferences.

 You can have a different language per user, and ntopng will honour this setting. Below you can see an example of the interface when set in Italian.

Multi-Language support is implemented in the Pro and Enterprise ntopng edition.

We’re happy to announce the release of ntopng 3.2.2 that introduces several enhancements and new features, some of which will be finalised in 3.4 due later this year. This version consolidates several months of work and paves the way to more radical changes planned for the next release. In particular beta features present in this version include support for InfluxDB and Prometheus so that you can use ntopng for exporting traffic data towards time-series databases (you can read about influx and prometheus). We have also revamped the alert implementation and introduced initial ntopng monitoring before we extend this code to include also host monitoring (we’re currently prototyping with eBPF, hoping it will serve all our host monitoring needs, including VM an container visibility). SNMP support has also been greatly enhanced including support of many new device types.

We encourage you to play with it, and join the development team. The whole changeling is listed below.

Enjoy!

Changelog

New features

• Improved alerts generation
  • Send alerts via email
  • SNMP alerts on port status change
  • Alerts at ntopng startup/shutdown
  • ARP/IP re-assignments alerts
  • Beta support for InfluxDB and Prometheus
• Multi-language support
  • English
  • Italian
  • German
• “hide-from-top” to selectively hide hosts from top stats

Improvements

• Discovery with SSH scan and MDNS dissection
• SNMP devices support
• HTML documentation with ReadTheDocs
• ERSPAN Type 2 detunneling
• per-AS network latency stats
• TCP KeepAlive stats
• Redis connection via Unix domain socket

Security Fixes

• Disables CGI support in mongoose
• Hardened options parsing

Fixes

• Fixes memory leaks with SNMP
• Fixes possible out-of-bounds reads with SSDP dissection

As you ntopng users know, out of the Elastic toolset ntopng supports both ElasticSearch and LogStash. You can use them using the -F flag:

--dump-flows|-F] <mode>  | Dump expired flows. Mode:
                         | es            Dump in ElasticSearch database
                         |   Format:
                         |   es;<mapping type>;<idx name>;<es URL>;<http auth>
                         |   Example:
                         |   es;ntopng;ntopng-%Y.%m.%d;http://localhost:9200/_bulk;
                         |   Notes:
                         |   The <idx name> accepts the strftime() format.
                         |   <mapping type>s have been removed starting at
                         |   ElasticSearch version 6. <mapping type>
                         |   values whill therefore be ignored when using
                         |   versions greater than or equal to 6.
                         |
                         | logstash      Dump in LogStash engine
                         |   Format:
                         |   logstash;<host>;<proto>;<port>
                         |   Example:
                         |   logstash;localhost;tcp;5510

With ElasticSearch being one of the most widely used downstream stores for information, it was time for the ntop team to add ElasticSearch version 6 support to ntopng.

Many users were eager to take advantage of the new ElasticSearch 6 features that include:

• More scalable searches across shards;
• Index-time sorting;
• Faster restarts and shard recoveries.

However, new features almost always come with breaking changes and ElasticSearch 6 is not an exception. Among the breaking changes it is worth mentioning the removal of multiple index mapping types. There is an interesting discussion that motivates the choice of removing multiple mapping types. Mapping types were initially supposed to be the equivalent of tables in SQL databases but actually that was just a bad analogy as database tables are independent(*) each other whereas in ElasticSearch different mapping types are backed by the same Lucene field internally. Having multiple mapping types was causing issues for example when creating the same field with different types in the same index. Other issues were determining the creation of sparse data that, in turn, was negatively affecting the Lucene compression abilities.

We believe that the removal of multiple mapping types is actually a good choice as it allows for a greater flexibility that is typical of noSQL databases. However, that costed us some effort to adapt the ntopng code and to create a new ElasticSearch template specific for version 6. Today we are happy to announce that the latest ntopng version 3.5 has support for ElasticSearch 6. And for those of you that are still using version 5? No worries, both versions are transparently supported. ntopng queries ElasticSearch to obtain its version and behaves accordingly.

So what’s next? If you want to try the latest ntopng 3.5 just install (or upgrade) a nightly build or build it from source. Happy indexing!

(*) OK, there are foreign keys that create tights among tables but in general columns in one table have no bearing on columns with the same name in another table.

Today the General Data Protection Regulation (GDPR) (EU) 2016/679 is effective in the European Union. GDPR is designed to protect personal data and thus preserve privacy in particular as specified in articles 13 to 22, and 34. As we manufacture tools for traffic monitoring, we’ve to make sure that our tools can be used in compliancy with GDPR. In particular we’ve implemented a couple of features that can be useful:

• If you go select “Preferences” from the ntopng menu, and click on the “Misc” pane you can access the preference for masking addresses.
  In essence you can configure ntopng to hide from the screen non local host information (or vice-versa). This prevents network administrators from being able to visualise the remote hosts a local host is talking with. This hides sensitive information such as the site being contacted or the URL but it allows you to keep an eye on the local network activities (i.e. those that are under your administrative domain).
• Right to erasure: GDPR requires that at any time a user can ask to delete from the database any information stored about such user. This facility has been already implemented in ntopng, so that network administrators can delete at any time information about specific hosts or MAC addresses. You can do that by selecting “Manage Data” from the preferences menu that will bring you to the following formthat implements the GDPR “Right to be Forgotten”.

In the near future we will implement pseudonymization features that hides from network data sensitive information. These features are still in progress and will probably be extended to other components such as nDPI and PF_RING. Stay tuned for details!

A couple of days ago InfluxData hosted a ntop webinar about how we have integrated InfluxDB into ntopng. Those who have not attended it can give a look at the presentation slides as well watch the webinar.

In essence:

• ntopng is based on RRD for timeseries
• As networks grow, ntopng needs to store more time series more granular.
• RRD is file based, that is a good things as configuration is minimal, but it does not scale on mid/large networks.
• We need an alternative, and found InfluxDB to be the best option available.
• We’re now coding a thin time series layer that allows people to decide what time series-engine to use, either RRD or Influx (and in the future other technologies)
• This presentation describes the problems we had to tackle with time series, and how we did integrate Influx.

Enjoy!

After a fresh install, ntopng will run using a default, basic configuration. Such configuration is meant to provide an up-and-running ntopng but does not try to secure it. Therefore, the default configuration should only be used for testing purposes in non-production environments.

Several things are required to secure ntopng and make it enterprise-proof. Those things include, but are not limited to, enabling an encrypted web access, restricting the web server access, and protecting the Redis server used by ntopng as a cache.

Here is the list of things required to secure ntopng.

Encrypted Web Access

By default, ntopng runs an HTTP server on port 3000. In production, it is recommended to disable HTTP and only leave HTTPS. To disable HTTP and enable HTTPS on port 443 the following options suffice:

--http-port=0
--https-port=443

Enabling HTTPS ntopng requires ntopng to be able to use a certificate and a private key for the encryption. Generation instruction are available in README.SSL.

Restrict Web Server Listening Address

ntopng embedded web server listens on any address by default. This means that anyone who has IP-reachability of the ntopng host can be served with web contents by the server. That does not imply anyone can access the ntopng web GUI — login credentials are required for the GUI — but it is never a good idea to leave a remote web server exposed also to those that should not be entitled to have access to ntopng.

The listening address can be changed from any to another custom address that can be an IP address of an host interface, or just the loopback address 127.0.0.1.

Listening address changes are indicated using a couple of ntopng configuration options, namely --http-port for HTTP and --https-port for HTTPS. For example to change the HTTP server listening address to only 127.0.0.1 and the listening address of the HTTPS server to 192.168.2.222, the following options can be used:

--http-port=:3000
--https-port=192.168.2.222:3001

The listening addresses can easily be verified with netstat on unix. The any address is indicated with 0.0.0.0. This is the netstat output when the HTTP and the HTTPS servers are listening on the any addresses.

simone@devel:~$ sudo netstat -polenta | grep 300
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 65534 67324991 5480/ntopng off (0.00/0/0)
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN 65534 67324992 5480/ntopng off (0.00/0/0)

This is the netstat output after the changes highlighted in the example above. The any address is no longer listed.

simone@devel:~$ sudo netstat -polenta | grep 300
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 65534 67323743 5808/ntopng off (0.00/0/0)
tcp 0 0 192.168.2.222:3001 0.0.0.0:* LISTEN 65534 67323744 5808/ntopng off (0.00/0/0)

Protected Redis Server Access

Password-Protected Redis Server

ntopng uses Redis as a cache for DNS names and other values. The Redis server by default listens only on the loopback address 127.0.0.1 but it is accessible without passwords.

To secure the Redis server with a password, uncommend the requirepass line of the Redis configuration file and specify a secure (very long) password here.

simone@devel:~/ntopng$ sudo cat /etc/redis/redis.conf | grep requirepass
requirepass verylongredispassword

Once the password is set and the Redis server service has been restarted, the ntopng --redis option can be used to specify the password. To use the verylongredispassword in ntopng it suffices to use the following option:

--redis=127.0.0.1:6379:verylongredispassword

Redis Server Access via Local Unix Socket Files

Another way to secure the Redis server is to configure it to only accept connections via a local unix socket file, rather than on any TCP socket.

The relevant part of the Redis configuration to use just a local unix socket file is the following:

# 0 = Redis will not listen on a TCP socket
port 0

# Create a unix domain socket to listen on
unixsocket /var/run/redis/redis.sock

To tell ntopng to use the Redis unix socket file the same --redis option can be used as:

--redis=/var/run/redis/redis.sock

ntopng User with Limited Privileges

ntopng runs with user nobody by default. That user is meant to represent the user with the least permissions on the system. It is recommended to create another user ntopng to run ntopng with so that even if there are other daemons running as nobody, none of them will ever be able to access files and data created by ntopng.

To run ntopng with another user just use option --user. For example to run ntopng with user ntopng specify:

--user=ntopng

Final Remarks

We do our best to develop code that is both efficient and safe from the security standpoint. However we’re humans and thus might be we make mistakes that need to be fixed. In case of security, we take these problems seriously and expedite their fixes. Please contact us promptly whenever you feel there is a security issue we need to tackle and we’ll come back to you ASAP.

Enjoy ntopng!

ntopng is open source, that means you can read its code and modify it according to the GPL license. The current ntopng architecture is based on three layers where the top one is written in Lua and it is used to render the web interface as well to execute periodic activities. In essence the C++/Lua API is a clean way to interact and extend ntopng without having to code in C++.

So far we have used this API inside the ntop team without documenting it. This has been a mistake as it has made life difficult for developers as hey had to do and explore the developed code to figure out how the API worked.

We have now fixed all this, and written documentation developers can use and that is available at this URL. You can look at it and learn more about ntopng. Shall you have questions, please send us comments on the ntop mailing list or send us pull requests on github.

One of the main concern of our users is the ability to scale ntopng with a large number of hosts/protocols and hence how to scale time series. As already discussed, RRD has many limitations with the increase of number of time series, hence it was time to start exploring new paths. We decided to abstract the ntopng engine from RRD and thus open up the engine to new time series databases. This has enabled us to use InfluxDB to store time series instead of RRD, that (as already discussed) enabled ntopng to scale both in number of time series and speed. While our work is still ongoing, this post will explain you how to move to InfluxDB and to the new time series reports (they work with both RRD and InfluxDB, seamlessly, thank to the engine abstraction).

Suppose that you have installed InfluxDB and created a database named ntopng as described in this readme (soon the database creation will be automated and this step won’t be necessary). You need to tell in ntopng preferences to use InfluxDB.

At this point you moved ntopng to InfluxDB and all the new time series will be stored in Influx. Note that currently we do not provide a way to migrate old RRD data to Influx. You can switch back to RRD at any time using the same procedure. Now regardless of the backend used for time series you can enjoy the new time series charts that we’re developing in the ntopng 3.5.x.

The major changes are (we’re developing new features daily so the list will grow in the coming weeks):

• Ability to zoom in (drill down) with the mouse by selecting the new time period on the graph.
• Data point have been smoothed for better visualisation.
• Ability to compare data with the past (time shift). On the above graph you can see (dotted grey line) the same graph on the previous period (as we’re visualising one hour, it will be the previous hour). Soon we will enable alert generation in case graphs do not overlap too much with respect to the past.
• For spiky charts as the one above depicted it is not simple to understand the trend. For this reason we have created a trend line based on this work, that allows to better understand where is the traffic trend.
• Average and percentile lines are now placed on top of the graph and animated.
• Colors for multi-chart graphs are based on pastel colours for better visualisation.

This is not all on charts and time series, but we believe it is enough for pushing you to test the new ntopng version before the stable release, and report us suggestions and bugs.

Enjoy!

nProbe is both a probe and a NetFlow/sFlow collector. Recently, we’ve also added added the ability to collect flows with proprietary information elements. This greatly improves nProbe flexibility as any custon, vendor-proprietary information element can be understood, correctly parsed, and exported downstream.

Adding proprietary information elements to nProbe is a breeze. Indeed, it suffices to use a plain-text file with the elements description. That’s all. Once the fields have been loaded from the plain-text file, they can be treated as if they were regular fields. So for example they can be added to the nProbe template -T to have them exported to Kafka, ntopng, text files, or any other supported downstream store.

We maintain and make publicly available several plain-text files that contain elements descriptions for several vendors, including Cisco, Gigamon and Sonicwall. Those files can be fetched at https://github.com/ntop/nProbe/tree/master/custom_fields.

In this article we show how to properly configure nProbe to collect Sonicwall flows. However, the methodology described here is general and can be applied, mutatis mutandis, to any other vendor. It is also shown how the collected data can be visualized with ntopng.

Configuring nProbe

As anticipated above, nProbe needs a plain-text file with the elements description to understand Sonicwall proprietary fields. This file is available at https://github.com/ntop/nProbe/blob/master/custom_fields/Sonicwall/sonicwall_custom_fields.txt. Download the file somewhere in the filesystem (make sure to download it using the “raw” link) as you’ll have to feed it to nProbe using option --load-custom-fields.

Now, for the sake of example, let’s assume:

• One or more Sonicwall devices are exporting IPFIX with Extensions to the host running nProbe on port 2055.
• Collected IPFIX with Extensions flows have to be sent to ntopng for the visualization via ZMQ on port 5556.
• The file sonicwall_custom_fields.txt has been downloaded to  /etc/nprobe/.

According to the assumptions above, the configuration file for nProbe can be the following

--collector-port=2055
-n=none
-i=none
--load-custom-fields="/etc/nprobe/sonicwall_custom_fields.txt"
--zmq="tcp://127.0.0.1:5556"
--zmq-probe-mode=
-T="@NTOPNG@ %FLOW_TO_APPLICATION_ID %FLOW_TO_USER_ID %FLOW_TO_IPS_ID %IF_STAT_IF_NAME %IF_STAT_IF_TYPE %IF_STAT_IF_SPEED"

In the example, only a limited number of information elements (those listed in the template) is actually exported to ntopng. As you can see, they are treated as if they were regular fields.

That’s pretty much all for nProbe. Everything is set up for the collection of Sonicwall flows. Let’s now have a look at ntopng for the visualization as there’s a juicy bonus here, that is, the ability to visualize pie charts of proprietary Sonicwall application ids and signatures.

Data Visualization with ntopng

In terms of configuration, nothing changes on the ntopng side. To collect flows coming from nProbe on port 5556, the minimum configuration needed for ntopng is a one-liner

--interface="tcp://127.0.0.1:5556c"

Start ntopng to have Sonicwall flows beautifully shown inside ntopng, along with their custom fields defined in the template.

There is also a pie chart with proprietary Sonicwall applications available both at the level of interface as well as for every host. This extra pie chart will automatically appear on the top of the Protocols page.

In addition, all the custom fields will appear in every flow details page. For example, the UDP flow below has been detected as General DNS by Sonicwall. ntopng augments this information by telling you that that is a Google flow, but is also show the Sonicwall-detected application untouched inside the Additional Flow Elements.

As you know ntopng web interface supports both HTTP (default) and HTTPS. The reason why ntopng does not default to HTTPS is because we provide self-signed certificates that web browsers dislike. Fortunately today you can create a free SSL certificate recognised by all browsers by using Let’s Encrypt open certificate authority (CA). This article describes how you can do this in a few simple steps: for simplicity we limit our scope to Ubuntu/Debian but on other distro’s the procedure is similar.

1. Install certbot as described in this article
2. Suppose that you want to run ntopng on a server named myntopng.ntop.org. Note that this host must have a public IP address and a web server installed such as Apache (with HTTP of course as we’re creating the certificate for HTTPS).
3. Then type (as root) “certbot –apache -d myntopng.ntop.org” as shown in the example below

   root@myntopng:/home/deri/ntopng # certbot --apache  -d myntopng.ntop.org
   Saving debug log to /var/log/letsencrypt/letsencrypt.log
   Plugins selected: Authenticator apache, Installer apache
   Obtaining a new certificate
   Performing the following challenges:
   http-01 challenge for myntopng.ntop.org
   Waiting for verification...
   Cleaning up challenges
   Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
   Enabled Apache socache_shmcb module
   Enabled Apache ssl module
   Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
   Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf
   
   Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   1: No redirect - Make no further changes to the webserver configuration.
   2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
   new sites, or if you're confident your site works on HTTPS. You can undo this
   change by editing your web server's configuration.
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
   
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Congratulations! You have successfully enabled https://myntopng.ntop.org
   
   You should test your configuration at:
   https://www.ssllabs.com/ssltest/analyze.html?d=myntopng.ntop.org
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

4. At this point Let’s Encrypt has created the certificate and modified the Apache configuration adding the path of the generated certificates

   SSLCertificateFile /etc/letsencrypt/live/myntopng.ntop.org/fullchain.pem
   SSLCertificateKeyFile /etc/letsencrypt/live/myntopng.ntop.org/privkey.pem
   

5. Now you need to concatenate the private and public keys and place them into the httpdocs/ssl directory of the ntopng installation

   root@myntopng:/home/deri/ntopng # cat /etc/letsencrypt/live/myntopng.ntop.org/privkey.pem /etc/letsencrypt/live/myntopng.ntop.org/fullchain.pem > ./httpdocs/ssl/ntopng-cert.pem

6. Then you need to restart ntopng with -W flag that allows you to specify the SSL port on which ntpng will be listening. In case you specify both -w (for HTTP) and -W (for HTTPS), whenever you connect to the HTTP port, ntopng will redirect you to the HTTPS port. If you want to disable HTTP at all you need to specify “-w 0”.

Now that you know how to secure ntopng with HTTPS you have no excuse for using the insecure HTTP protocol.

Enjoy!

Often we receive emails asking question like: “how many protocols nDPI supports?”, “how do you position nDPI against commercial DPI toolkit A, B, C?”. Although these questions are reasonable, they do not grasp the significance of DPI. For years commercial toolkits have run the race for protocols: I have 200 protocols, I have 1000 protocols, I have 500. Then asking that is the meaning with the term “protocol” people list traffic from to sites like cnn.com or bbc.co.uk. But BBC is not a protocol but rather some traffic (for instance HTTP, or DNS) traffic going towards *.bbc.co.uk hosts. So today comparing DPI toolkits based on the number of (so called) protocols is a bad idea as these are all but protocols.

Actually having many protocols is a pain. Computer scientists know what protocols are about, but if you ask a non-tech person to list what are the peer-to-peer protocols I am not sure you will receive a correct answer. In addition having too many protocols is bad: do you prefer to say “block all the social networks traffic” or “block Facebook, Twitter….”? Which one is more error prone? This not to mention that as soon as a new social network becomes popular you have to review all the settings of your app, whereas letting the DPI toolkit to take care of this, is a transparent and thus a better solution. Finally supposing that you want to block all advertisement sites, and daily update their list via an Internet feed. This would be a nightmare to maintain when mapping a site to a protocol, instead of mapping it to a category.

To make this long story short, nDPI has introduced categories in the latest release and this has enabled is to make ntopng and nEdge better and more configurable. The problems that we are going to tackle include:

• I want to block all advertisement sites (nEdge)
• I want to trigger an alert whenever my employees access a malware site (ntopng, whereas in nEdge you have the bonus also to block this traffic)
• I run a grocery shop which provides free WiFi to customers, and I want to prevent them from accessing with the WiFi sites of competitors as they are using them for comparing prices (nEdge)

While in nDPI you can manipulate categories through the API, in ntopng you can do that using the web interface. Going o the Protocol entry in the preferences menu you can access all the application known application protocols and bind them to categories (or modify the default category provided by nDPI).

You can also edit the categories by adding new hosts or IPs, accessing the Categories menu entry in the Preferences

and adding custom hosts

In addition this, you can do that easily looking at flows. Suppose that you are watching a video and you see advertisements or tracking on your screen, you can block selected sites by listing flows, then accessing the flow info of those flows that from the host name look like suspicious. As you can see from the picture below

we have added a + icon that allows you to add it to a selected category by clicking on it

This is a simple procedure that should enable everyone to manipulate categories with the mouse rather than using the keyboard.

We hope that the introduction of this new feature will enable people to better categorise their traffic and see what really happens on the network. Remember that ntopng produces reports like the one below, so you can see host-by-host or network-by-network what is flowing on the network.

Enjoy!

sFlow, short for sampled Flow, is a sampling technology designed to export network devices information, namely:

• Interface counters (à la SNMP MIB-II);
• Traffic packets (à la ERSPAN).

sFlow agents run on switches, routers, firewalls and other devices, and periodically export interface counters and traffic packets via UDP towards one or more sFlow collectors. sFlow, relying on sampling processes to periodically counters and packets, is scalable and ultra-lightweight and has been embedded into network devices by tens of vendors and manufacturers.

Contrary to NetFlow (please note that in sFlow parlance the word ‘flow’ has a totally different meaning with respect to what ‘flow’ means in NetFlow), which requires a stateful representation of all the network flows packets to operate, sFlow merely sample packets and counters and thus its impact on network devices memory and CPU is much lower. For this reason, is should be the technology of choice when carrying out certain network monitoring tasks. ntop team members have discussed in detail this technology during a couple of SharkFest conferences (SharkFest Europe, SharkFest US). The interested reader can download the presentation slides to gain a deeper understanding of sFlow, or even watch the youtube video of the presentation:

ntop software tightly integrates with sFlow:

• nProbe acts as an sFlow collector and can collect sFlow from tens or even hundreds of network devices, simultaneously;
• ntopng receives collected sFlow data from nProbe and is in charge of providing visualizations and actionable insights from this data.

Hence, using ntop software nProbe and ntopng, it is possible to easily and quickly setup a monitoring architecture for multiple sFlow-capable network devices in minutes.

Let’s see an example. Let’s say there are sFlow agents exporting sFlow on port 6343 of an host running nProbe. Let’s also say and ntopng running on the same host is used for the visualization and analysis. Configuring nProbe and ntopng is a breeze and it merely boils down to:

nprobe -i none -n none --collector-port 6343 --zmq tcp://127.0.0.1:5556
ntopng -i tcp://127.0.0.1:5556

Commands above have the following meaning:

• nprobe is neither collecting from a physical interface (-i none) nor exporting flows towards a downstream NetFlow collector (-n none); it’s just collecting incoming sFlow on port 6343 (--collector-port 6343). Collected data is then exported to an ntopng running on localhost port 5556 via ZMQ (--zmq tcp://127.0.0.1:5556).
• ntopng is listening on port 5556 for incoming collected sFlow data (-i tcp://127.0.0.1:5556).

The ntopng web dashboard will shortly populate with collected data, including top senders and top destinations, as well as the top layer-7 application protocols detected from the traffic. Similarly, all the other ntopng pages will populate with rich data. For example, one can visualize the top layer-7 application protocols by visiting the interface page:

Nevertheless, ntopng not only provides visibility on the traffic that is traversing the network devices, it also provides visibility into the devices per se. To access the list of sFlow devices that are currently actively exporting sFlow, select the “sFlow Exporters” entry from the “Devices” dropdown.

The devices list will be shown, along with a chart link as well as data obtained via SNMP (when available). SNMP data shows up automatically when SNMP monitoring is configured in ntopng and there is a match between the IP address of the SNMP and the sFlow device.

The address of every device listed can be clicked to access a summary of all the device interfaces, including their status and total traffic:

Similarly, the chart link provides visibility into the traffic of every interface of the selected network device. An handy stacked view will provide a useful summary of the interfaces activity:

For example, from the chart above, it is clear that interface with id 8 is accounting for most of the device traffic over the 6-hour time interval selected.

Happy sFlow collection!