Those of you who are familiar with kernel-bypass drivers like PF_RING ZC know that it is not possible to run multiple applications on top of the same Network interface and capture the same traffic twice. This is the case of Intel and most FPGA adapters. In fact, since the application takes full control of the adapter and configures it to copy packets directly to the application’s memory in hardware, access to the device must be exclusive. This unless the adapter natively support multiple consumers: this is the case of Mellanox/NVIDIA  and Fiberblaze/Silicom adapters.

Last autumn we have introduced the iavf ZC driver, which adds support for a new range of (virtual) adapters from Intel: i40e (X710/XL710) and ice (E810) SR-IOV Virtual Functions. As we announced in the latest PF_RING changelog, this new driver paves the way for new packet capture architectures as it enables traffic duplication on Intel!

You are probable wondering what Virtual Functions have to do with traffic duplication. Well, SR-IOV on X710/XL710 adapters supports a working mode called trust mode which has been introduced to enable promiscuous capture on Virtual Functions, to allow multiple virtual interfaces to see all traffic hitting the physical interface. This means that it is now possible to duplicate (i.e. capture the packet once and resent it multiple times) and capture all traffic hitting a physical (Intel) interface from multiple Virtual Functions, in promiscuous mode, at high speed, using a ZC driver. And, in addition to this, it is possible to optionally filter traffic in hardware based on VLAN or MAC address.

A typical use case for traffic duplication is traffic analysis combined with traffic recording at high speed. In this case you would setup two virtual interfaces (Virtual Functions), each receiving a full copy of the traffic, and you would run nProbe or ntopng on one of them for traffic analysis, and n2disk on the other for traffic recording.

In order to configure the adapter to achieve this, you need to:

1. Enable SR-IOV support

Change the kernel parameters in /etc/default/grub as below.

GRUB_CMDLINE_LINUX_DEFAULT="iommu=1 msi=1 pci=assign-busses intel_iommu=on"

Note: pci=assign-busses is required to fix failures reported in dmesg as below.

i40e 0000:02:00.0 enp2s0f0: SR-IOV enabled with 1 VFs
i40e 0000:02:00.0: can't enable 1 VFs (bus 03 out of range of [bus 02])
i40e 0000:02:00.0: Failed to enable PCI sriov: -12

Apply the changes and reboot.

update-grub && reboot

2. Configure the iavf ZC driver as reported in the guide, similar to any other PF_RING ZC driver.

3. Enable 2 Virtual Functions per interface.

echo '2' > /sys/bus/pci/devices/$(ethtool -i $IF | grep bus-info | cut -d ' ' -f2)/sriov_numvfs

4. Set the trust mode to enable promiscuous capture (and optionally filter traffic based on VLAN ID)

ip link set $IF vf $VF_ID vlan $VLAN_ID
ip link set dev $IF vf $VF_ID trust on

Note: 3. and 4. can be automated by using a pre script as described in the guide

At this point you are ready to run two applications and capture the same traffic from both virtual interfaces using ZC without having to purchase a costly packet broker.

nprobe -i zc:eno0v0 [...]
n2disk -i zc:eno0v1 [...]

Enjoy!

Almost 3 years ago we introduced Active Monitoring support in ntopng. This allows you to monitor the infrastructure and make sure that all systems are operational. In fact ntopng can continuously monitor hosts in your network by periodically running different active measurements including:

• ICMP, which measures the RTT (Round Trip Time).
• Continuous ICMP, which evaluates network reachability and service availability.
• Speedtest, which estimates the Internet bandwidth and latency contacting a speedtest server.
• HTTP(S), which checks the HTTP/HTTPS availability of web servers.
• Throughout, which tests the throughput contacting an HTTP server.

As a result, it is possible to:

1. Monitor the status of the services over time, by looking at the table in the Active Monitoring page which contains all the measurements.
2. Get notified when a measure is failing or the result is not satisfying a threshold, by triggering an alert.
3. React (Automatically) with some custom action, for instance running a script, when a service goes down, to restore it.

Add a new Measurement

As we have seen in a few previous posts, adding a new service to be monitored is easy:

1. Select the System interface from the drop down at the top of each page.
2. Go to the Monitoring -> Active Monitoring page from the sidebar
3. Click on the add button (+)
4. Select the measurement, the host/service to check and a reasonable threshold that should not be exceeded if the service is operational

At this point ntopng will periodically check the measure, and trigger an alert in case of failure. Those alerts are visible under the Alerts -> Explorer -> Active Monitoring page.

Get Notified

If we want to get notified through some of the endpoints (e.g. messaging systems) supported by ntopng, we can go and configure this from the Notifications page.

For instance, let’s assume that we want to receive a message on Telegram on our mobile phone. First of all we should create a new endpoint from the Notifications -> Endpoint page, where we specify the endpoint type (Telegram) and the required parameters.

Then we need to create a recipient for delivering alerts generated by the Active Monitoring support from the Notifications -> Recipient page, where we specify which alerts we want to receive, filtering them by Severity, Category, Entity, and finally the Active Monitoring entries that we want to monitor.

React (Automatically) 

In some case, we can do something better than just getting notified (actionable results), because:

• A manual reaction to the notification may take time
• It may be we are away, busy, or even sleeping and not able to react at all
• It is possible to fix the service with a task which is easy to automate (e.g. a simple service restart)

In ntopng it is possible to automatically react to events like alerts generated by the Active Monitoring and run  custom action. One way for achieving this is, for instance, running a shell script or calling a web-hook.

In order to run a shell script:

1. Create the script (with .sh or .py extension and executable permission) under /usr/share/ntopng/scripts/shell/. In order to get alert information, they are provided to the script as standard input in JSON format.
2. Create a new endpoint from the Notifications -> Endpoint page, specifying Shell Script as endpoint type and by selecting the script from the dropdown.
   
3. Create a recipient from the Notifications -> Recipient page, specifying for which service we want to run the script.
   

This way you can restore a service with an automatic action, or simply notify a peer: just create a script that can perform the action you need.

Enjoy !

ntop tools range from packet capture, traffic analysis and processing, and sometimes it is not easy to keep up on product updates as well master all the tools. This has been the driving force for organising ntop professional training: .

This is to announce that in May we have scheduled the next ntop Professional Training session. It will take place online (Microsoft Teams) on 2nd, 4th, 9th, 11th 16th, 18th of May, 2023 at 3.00 PM CET (9.00 AM EDT). Training will be held in English language and each session lasts 90 minutes.

All registered attendees will receive, as part of the training, a license of ntopng Pro that you can use after the training for improving your skills.

Here, you can read more about all the training topics that will now cover SNMP support in ntopng more in detail. Shall you be interested to join this session, please book your seat. Shall you have questions, please feel free to mail training@ntop.org.

Enjoy !

Traditionally flow-based tools are based on the 5-tuple attributes (source and destination IP, source and destination port and the protocol field). Often they are complemented with additional attributes such as VLAN or Tunnel Id in order to avoid mixing in the same flow packets that belong to different communications. 

The above picture shows the 5-tuple key in the live flows window. Looking at flows using the 5-tuple makes sense if we want to understand what it is happening at the individual flow level, but it makes difficult to understand the big picture and answer to questions such as:

• What are the top client-server conversations?
• What are the flows of the most used application protocols?
• What host has the highest number of incoming flows?
• What are the flows towards weather-data.apple.com ?

In order to answer these questions we have developed a new entry called Live Flows Analysis that you can find in the menubar

Using it you can now select the aggregation criteria for merging reporting flows no longer as 5-tuples, but according to the criteria you selected. This allows you to manipulate flows in an aggregated format and then by clicking on the blue flow icon, show the flows what have been aggregated. For instance suppose you want to count flows that are going towards towards outlook.office365.com. All you need to do is to select Info as criteria (this way you should not worry if outlook.office365.com resolved to different IP addresses as they will all be grouped under the same name) then the flow count column shows that you have 7 flows.

If you want to see such flows, all you need to do is to click on the flow icon of the first column and see all the flows, this time using the 5-tuple

You can do the same with the other criteria currently supported (more will come in the near future): namely aggregate, search, sort and the drill down.

Enjoy !

Many ntop products such as ntopng, nProbe, and PF_RING FT just to name a few are based on network flows. However not all our users know in detail what is a network flow, and how it works in practice. This blog post describes what they are and how they work in practice.

What is a network flow?

A network flow is a set of packets with common properties. They often are identified by a 5-tuple key meaning that all packets of a given flow have the same source and destination IP, source and destination port, and application protocol (e.g. TCP). In practice the flow key also includes at least the VLAN Id and eventually other attributes such as the tunnel Id for encapsulated traffic. A flow is a way to classify traffic by clustering packets with a common key, and it is similar to what you see on computers when you run commands such as netstat -na. Each flows has various counters that keep track of flow packets/bytes and various other attributes such as the flow timers (time of first and last flow packet) , statistics (retransmission, packets out-of-order,…) and security attributes (e.g. the flow risk).

How flows are stored in memory?

Network flows are kept in a data structure named flow cache (often implemented using a hash table) that is constantly fed with incoming packets. The flow cache stores in memory the active flows (i.e. those that are still active as packets belonging to the flow are received). Below you can see how ntopng displays the live flow cache and their 5-tuple key.

When does a network flow start?

A network flow starts as soon as the first flow packet is observed. At startup the flow cache is empty and it is filled up as packets are received. Each incoming packet is decoded and the flow key computed. Such key is searched in the flow cache: if not found a new entry is added to the flow cache, otherwise the existing entry with such key is updated, i.e. the counter for flow packets/bytes and timers are updated. So in essence a flow starts when the first flow packet is observed.

When does a network flow end?

Each flow has two aging timers: idle (it keeps track of how much time is past since the last flow packet has been received) and duration timers (it keeps track of how long the flow is lasting). A flow ends when one of these two aging timers are expired, namely when a flow is idle for too long (e.g. no packets have been received for a while) or when a flow is stored for too long in the flow cache. In nProbe and PF_RING FT. when a flow is expired it is removed from the flow cache and sent to the collector. In ntopng instead, a flow is removed from the flow cache only for idleness, as long-lasting flows are not removed from the cache. The reason is that a flow probe such as nProbe needs to periodically report to the collector (e.g. ntopng) information about the monitored traffic and thus flows are “cut” and sent to the collector. Instead in ntopng there is no need to inform collectors and thus flows stay in memory as long as necessary as configured in preferences.

Flow Keys and Directions

If flows are created when the first flow packet is received, we can expect to see the flow client as the real network client. For instance is client on host 1.2.3.4 SSHs to host 5.6.7.8, the flow for such communication will be 1.2.3.4:X <-> 5.6.7.8:22 (we assume that SSH is running on port 22). Look good right? Well sometimes you see that in the flow cache such flow is reported as 5.6.7.8:22 <-> 1.2.3.4:X. Why this? This can be due to various reasons:

• The application (e.g. ntopng) started after the flow begun, and the first packet observed by ntopng is 5.6.7.8:22 -> 1.2.3.4:X instead of  1.2.3.4:X -> 5.6.7.8:22.
• The flow was stored in the cache with the correct key, but no packet was exchanged for a while (e.g. 2 minutes) and thus the application has declared the flow as expired, removing it from the flow cache. Then if suddenly a new packet is observed, such packet might be sent in the wrong direction (e.g. 5.6.7.8:22 -> 1.2.3.4:X) as this might be a keep-alive packet of the server. In this case the flow is placed in the cache with the reverse (9and thus wrong) direction.

ntopng (via preferences) and nProbe (using the command line with -t and -d) flow timeouts can be configured, hence these issues mitigated (albeit not fully addressed). However timeout tweaking is not enough in particular with UDP flows because contrary to TCP, there are no TCP flags that can be used to guess the real flow direction. For this reason, ntopng implements some heuristic to swap flow directions but this heuristic cannot be too aggressive as we might report invalid information. 

We hope that this post clarified how flow-based network traffic analysis works and why some “unexpected” behaviour is sometimes observed, not because of a bug, but because of the nature of these measurements.

Enjoy !

A VLAN is a method for partitioning a layer two broadcast domain creating virtual networks of homogeneous systems hence promoting network segmentation. A ethernet port with no VLAN tag is called access port, whereas a switch port with VLAN-tagged packets is called tagged or trunk port. End systems are usually connected to access ports meaning that they deal with untagged packets that are then marked by the switch according to the VLAN port configuration. For this reason a end system is not aware of the VLAN id that is used to mark its traffic (if any). Traffic (e.g. using a port mirror or a network tap) on a non-access port is instead VLAN tagged (sometimes VLAN tags are stacked) hence monitoring systems need to properly handle VLAN tagged traffic.

The Problem

Based on the network topology and how traffic is wiretapped, it is not uncommon to observe asymmetric VLAN tags. In the figure below it is shown traffic exchanged by two hosts with two different VLAN IDs: 67 for traffic client to server, and 125 for traffic server to client.

It is worth to remark that:

• The client is attached to an access port and thus the traffic when close to the client port will have the same VLAN Id (that can be 67, 125 or even another VLAN Id) for the RX and TX directions. This is to make sure that the two directions are merged on the same port.
• When the traffic leaves the network and hits the Internet, the VLAN tag is stripped and traffic is sent untagged (i.e. the VLAN Id is a local network concept that is not propagated to the Internet).

This said, in most cases wiretapping VLAN-tagged traffic has symmetric VLAN IDs (in the above case both client-to-server and server-to-client traffic have the same VLAN Id) but in some cases tags are asymmetric (i.e. each direction has a unique VLAN ID) as in the above case. Flow-based applications such as ntopng and nProbe will not classify the above traffic as a single flow, but with two unidirectional flows as the VLAN ID is different. This has also as consequence that nDPI will partially work as only one side of the communication is observed per flow.

Solution

In order to harmonise the traffic reconciling the two traffic directions into a single flow, ntop applications have the ability to “ignore” the VLAN tag Id in the flow key (i.e. the traffic is handled as untagged traffic with no VLAN tag at all).

ntopng

In ntopng there is a command line option “–ignore-vlans” for ignoring at all VLAN tags in traffic.
Example: ntopng -i eth1 –ignore-vlans

nProbe

In nProbe there is even more flexibility for ignoring specific fields and not just the VLAN Id. Please note that in nProbe it is possible to selectively ignore the inner and outer (in case of IEEE 802.1 ad) VLAN tags.

[--aggregation|-p] <aggregation>    | It specifies the flow aggregation level:
                                    | <OuterVLAN>.<InnerVLAN>/<proto>/<IP>/<port>/<TOS>/<SCTPStreamId>/<exporterIP>/<ICMP>
                                    | where each element can be set to 0=ignore
                                    | or 1=take care.

Example: nprobe -i eth1 -p 0.0/1/1/1/1/1/1/1

Conclusion

Asymmetric VLAN-tagged traffic is not uncommon on large networks. If not properly handled, network measurements are not correct as flows are asymmetric with partial DPI. In this article we have shown how to configure both ntopng and nProbe to ignore VLAN tags and thus reconcile monitored traffic.

Enjoy !

Supporting 64 bit ARM platforms is important because there is now a plethora of inexpensive boards based on this architecture. Thanks to the use of docker containers, several manufacturers allow their devices to take advantage of this technology to run third-party software on devices that used to be not extensible. Here you can read how to run ARM64 containers on Mikrotik devices (soon we’ll publish a separate post on this subject).

For this reason starting this month, we’ll publish weekly updates of ARM64 docker images that you can run on Raspberry with PiOS 64 bit or other devices. Below you can find the URLs to Docker Hub containers for:

• ntopng
• nProbe

Enjoy !

In short

Continuous network traffic recorders are applications (or appliances) that write network traffic on disk. In case of issues (e.g. security breach or network outage) they enable network and security analysts to go back in time and see how a problem originated. The main limitation of this practice is that a lot of data it is written to disk even when there is nothing special happening on the network. Similar to the evolution of surveillance cameras that implemented “motion detection” to trigger recording when some meaningful even happen, this is to introduce a similar concept for network packet recording. Namely, we now enable (this is a configuration option) the ability to record network traffic only if relevant activities are detected (call it “network motion detection” if you wish): less disk space used, more data recorded, faster data access as non relevant data is discarded. IMPORTANT: contrary to “motion detection” where recording starts the a motion is detected, in smart packet recording we have implemented a mechanism (through a technique called “extract on recording“) that allows us to start recording before the security event is triggered, and so give people the ability to see how everything started and not when the problem is already in place. Below we show how nDPI/ntopng (and Suricata via ntopng) trigger smart recording, but soon we want to extend this facility to other third party security applications that can trigger recording in n2disk.

Continue reading this article if you want to know how smart recording works in detail.

The Whole Story

In one of our Webinars last year we introduced the idea of implementing a smart way of recording PCAP data. This was based on the necessity of going back in time and get the raw traffic matching an event that our system (e.g. ntopng) detected. In fact, the recording window (data retention) for PCAP data, that depends on the size of the storage system, may not be large enough to contain (and let us download) the data for the event we are analysing, especially at high traffic rates (a 10 Gbit link can produce more than 100 Terabytes per day!).

Those who are running ntopng for security or troubleshooting, in most cases are using it in combination with n2disk for enabling Continuous Traffic Recording. When ntopng triggers an alert, in case of a security event or a Network issue, this allows them to drill down and download the raw packets, providing full evidence of the event. But it happens that at the time the manual analysis is conducted, the PCAP data is no longer on disk, as n2disk already deleted it to make room for new data.

n2disk implements several techniques for improving the data retention and enlarge the recording window. This includes:

• Packet slicing, to strip the packet payload
• Layer 2/3/4 filtering based on optimized BPF filters, to discard traffic based on packet headers
• Layer-7 filtering, to discard or shunt unwanted traffic based on the application protocol
• Traffic compression

However all the filtering techniques described above have some limitation: they are not able to predict which traffic is really important (i.e. packets matching Network events) and keep keep using disk space for traffic which is not really relevant for our analysis.

This is why we introduced the concept of Smart Recording, which is a new technique that allows us prioritise selected traffic (e.g. based on security events generated by ntopng or third party tools), by deleting the rest of the traffic first, when it’s time to make room for new data on disk.

The Smart Recording has been implemented as a new service which is running on the box, which is processing events published by the analysis tools, and it is archiving PCAP data matching those events to a secondary storage (this can be on a dedicated or the same volume). In short n2disk is using:

• a 1st level storage to implement Continuous Recording with a short data retention
• a 2nd level storage to archive traffic for Network events with a longer data retention

This architecture is already supported by ntopng 5.7 (available in ntopng Enterprise XL) and can be enabled from the Traffic Recording page in the ntopng GUI. This requires n2disk to be installed as described in the documentation, and can be enabled in the same page used to manage Traffic Recording:

1. Toggle Smart Traffic Recording
2. Configure the desired Max Smart Disk Space which is the disk space to be used for the second level storage (events traffic)
3. Save the configuration and enable Smart Recording with the Save Settings button

At this point everything is up and running: n2disk is continuously recording PCAP traffic up to the configured Max Disk Space, and the Smart Recording service is processing events and moving event’s data to the secondary storage up to Max Smart Disk Space. When traffic extraction is requested, from one of the charts in the ntopng GUI, or when downloading PCAP traffic for a specific alert or flow, traffic is extracted from the first-level storage if it falls inside the first-level recording window, or from the second-level storage otherwise (only traffic matching network events will be available in the latter case).

Enjoy!

We have created nDPI to label network traffic and extract metadata such as the URL or TLS certificate information. nDPI is the layer on top of which ntop applications are sitting. This time we do not want to talk about nDPI internals but rather use it to monitor Internet traffic. For this reason we have taken traffic from an Italian broadband (no mobile) ISP, and used ntopng + nDPI to monitor the Internet traffic produced by residential and business users. Below you can find the results for social networks and streaming services.

We believe these numbers will change according to the country and customer types, but we present them here because:

• Not everyone knows that nDPI is a first class DPI toolkit that includes all modern application protocols ranging from business protocols, to social, streaming, IoT and peer-to-peer.
• nDPI is able to classify not just the main protocol (e.g. Facebook) but also sub-protocols (e.g. Facebook Reels, Stories, chat and images).
• nDPI can detect both plain Internet and mobile network encapsulated traffic (GTP).
• The nDPI maintainers and contributors are very active and basically every day contribute to make nDPI better.
• We have implemented various techniques including fuzzing to make sure nDPI is robust and ready for business environments.

1. Social Networks

2. Streaming

3. Messaging

Enjoy !

This year ntop will turn 25. Our call for speakers for the ntop conference 2023 (Pisa, Sept 21-22) is now open. Deadline is June 30th. We want to hear you voice, experience, projects based on ntop tools and anything that can be of interest to our community.

Pisa is the conference location that we have selected. It is the ntop hometown, and it can be easily reached with low-cost flights from many international locations. 

No excuse for not submitting a talk proposal. Read more and submit your talk at this page.  

Looking forward meeting you at ntopConf 2023.

Recently, we have introduced Smart Recording in n2disk to combine Cybersecurity with Packet-to-Disk. In this previous post (and in the documentation) we described the idea behind it and described how to enable it in a few simple steps. 

For those of you who prefer a video resource, and want to learn more about the technology and how to get the most out of it,  here’s the step-by-step video tutorial.

Enjoy!

What is OT, ICS, SCADA ?

Operational Technology (OT) refers to computing systems that are used to manage industrial operations or process operations, like water treatment, electrical power distribution or wrapping a chocolate in foil. ntopng supports some Industrial control systems (ICS) protocol often managed via a Supervisory Control and Data Acquisition (SCADA) systems. Via nDPI it can detect protocols such as Modbus, IEC 60780 or BACnet. In addition to this, ntopng has extensive detection and monitor capabilitiesfor some protocols OT protocols/

ntopng “Generic” Monitoring

ntopng is a monitoring tool able to detect “generic” and behavioural issues that can disrupt an OT network. They include (but are not limited to):

• New device detection and invalid MAC/IP combinations
• Device traffic behavioural analysis (e.e. traffic misbehaving, peaks in traffic)
• New protocols and services: detect when a devices changes in provided services (i.e. a HTTPS server is spawn) or a new protocol s used as client

In addition to the above services, specific protocols are supported in detail.

IEC 60870-5-104

IEC 60870-5-104 is a protocol used mostly in electrical engineering and power system automation. This protocol is detected by ntopng and dissected overtime by detecting changes in behaviour for each network flow.

For each IEC flow, ntopng dissects flow communications

 

and reports in realtime traffic statistics. In addition to this, ntopng learns the protocol transitions as configured in preferences, this as each IEC flow has different peculiarities and transitions for which a model is created.

For the specified duration, ntopng builds a model for each flow in order to understand how it behaves overtime. When the learning period for a flow is over, ntopng matches the traffic agains the model and triggers an alert whenever

• An unexpected transition is detected
• The transitions number is invalid (C-C > 10 and M-M/M-C/C-< == 0).

You can read more about this in the ntopConf 2022 presentation.

Maybe not all of you know that ntopng powers in some popular monitoring systems such as CheckMK and Centreon. The integration is made possible through the ntopng REST API (REST stands for REpresentational State Transfer) that allows developers to manipulate ntopng configuration and query monitored information including hosts, flows, alerts and historical data.

Recently we have integrated the ntopng API specified according to OpenAPI into ntopng by using the swagger open-source tool. All you need to do is to update your ntopng (dev) copy and access the embedded REST API client from the developers menu (if hidden, you can enable it in the ntopng preferences).

After selecting the REST API entry, ntopng shows you all the available endpoints that are divided in three main categories: Interface, Host and Alert.

Clicking on a REST endpoint you can immediately test it inside ntopng without the need to use third party software. All you need to do is to fill the required parameters and click on the Execute button.

Immediately the REST API response is returned and displayed in the browser as shown in the picture below.

Enjoy !

Overview

Those of you who have some experience with IDS or IPS systems, like Zeek and Suricata, are probably aware of how CPU intensive and memory consuming those applications are due to the nature of the activities they carry on (e.g. signatures matching). This leads to high system load and packet loss when the packet rate becomes high (10+ Gbi+) making these IDSs unlikely to be to deployed on high-speed networks. As nProbe Cento can analyse networks up to 100 Gbit while using nDPI for ETA (Encrypted Traffic Analysis), ntopng can act as a Cento collector to receive and consolidate flow information as well identify attackers and victims hosts. This blog post shows you how using ntop tools it is possible to enable Zeek and Suricata “on demand”, i.e. limited to those attackers or host victims. This means that:

• nProbe Cento is started to poll all network traffic on top of a network adapter able to support hardware filters such as nVidia Connect-X.
• Zeek and/or Suricata are started with a hardware filter that does not send them any traffic.
• As soon as ntopng detects an attacker/victim host, it writes its IP in a redis queue that is polled by PF_RING.
• As soon as PF_RING detects an IP to ban/unban it adds a hardware filtering rule on the “on demand” connection, so such IP traffic is sent to Zeek/Suricata

Going Deep

The PF_RING framework has demonstrated to play a key role in the acceleration of those tools, by delivering features like:

• packet capture acceleration, to deliver line-rate capture speed and make more CPU cycles available to the tools  (if interested please read the IDS/IPS Integration section of the PF_RING documentation)
• filtering, to reduce the input by (statically) defining filtering policies from Layer 2 up to Layer 7, dramatically improving the performance of the tools (please read the PF_RING FT acceleration section).

Recently, a new technique has been introduced in PF_RING and ntopng for accelerating IDS systems, whose idea is similar to the Smart Recording acceleration used by n2disk and described in a previous post and video tutorial. In fact, in order to save resources (that can be  disk space in case of n2disk, or CPU cycles in case of an IDS), the best approach is to run the tools on-demand on interesting traffic only.

How to do this? ntopng implements Behavioural checks that can detect when a host is misbehaving (as well as classic attacks such as port scans, brute force or invalid protocol requests) , and can be configured to push information about those hosts to external tools for further analysing their traffic.

PF_RING 8.5 (or later) includes native support for runtime filtering, which is the ability to add filtering rules while the application is running. Filtering rules are automatically converted into hardware rules and offloaded to the adapter, to be evaluated in hardware and add zero overhead (available on adapters supporting hardware filtering like the NVIDIA ConnectX). This allows you to run an IDS and receive only selected traffic (only packets matching hosts that require attention), according to rules which are dynamically built and pushed to the capture engine. Please note that unlike other adapter families (e.g. Intel), with nVidia multiple applications can simultaneously open the same network adapter and apply hardware filtering rules selectively (i.e. adding a filter on a connection does not discard packets on the other connections as hardware filters are per connection and not per NIC).

Let’s see how this works under the hood.

Filters are pushed to the capture engine by means of a Redis queue. Host filters can be added and removed by means of commands like “add host” or “remove host”.

This can be configured in ntopng from the Interface > Details > Settings menu, where it is possible to toggle the Push Alerted Hosts to PF_RING flag.

With this setting enabled, ntopng notifies hosts for which there is an engaged alert to PF_RING, triggering the diversion of the traffic matching those hosts to the IDS (or any other application running on top of PF_RING), which is otherwise discarded by default.

The name of the Redis queue is pfring.ID.filter.host.queue and it’s reported by the GUI (more details about this queue and how it works are available in the PF_RING Runtime Filtering section of the PF_RING user’s guide=.

In order to run the application on top of PF_RING, and enable Runtime Filtering, the PF_RING_RUNTIME_MANAGER environment variable should be set, using as value the name of the Redis queue used by ntopng to push the filtering commands.

Example with Suricata on top of a NVIDIA/Mellanox adapter:

PF_RING_RUNTIME_MANAGER="pfring.6.filter.host.queue" suricata --pfring-int=mlx:mlx5_0 -c /etc/suricata/suricata.yaml

Obviously, Suricata should be compiled with PF_RING support, please refer to the IDS/IPS Integration section of the PF_RING user’s guide for instructions.

As of Zeek you need to compile it using the libpcap library part of PF_RING as explained in the user’s guide and it will work as Suricata.

Final Remarks

Thanks to the above solution, it is now possible to enable IDSs on demand as soon as an issue is detected by nDPI/nProbe Cento/ntopng. This solution allows Suricata/Zeek to scale at 40/100 Gbit speeds that otherwise would be too high for such tools. We are aware that this solution relies on the ability of ntopng to detect attacks whereas it would have been desirable to run Suricata/Zeek on all network traffic. This can be achieved at a high cost (e.g. partitioning ingress traffic across multiple hosts that run such IDSs) also generating a lot of logs that would probably be too much to handle. We believe that the above solution is a reasonable compromise between speed, costs, and detection accuracy.

Do not forget that using the architecture described above it is possible to selectively enable from the command line (e.g. ‘redis-cli lpush “+1.2.3.4/32” pfring.6.filter.host.queue’) traffic analysis of selected hosts. This can also be a great solution for discarding in hardware all traffic except the one for critical hosts that instead need to be monitored permanently with an IDS regarded them being under attack or not.

Enjoy!

Modbus is an industrial protocol used to communicate with automation devices. The initial protocol version was implemented over a serial layer, whereas the current version named ModbusTCP is a variant of the original protocol running over TCP/IP.

This blog post describes how ntopng monitors ModbusTCP traffic: it detects Modbus flows via nDPI and dissects them building an internal flow representation. For each flow, ntopng keeps track of the function codes uses, exceptions and registers accessed. 

It also reports the transitions between function Ids and depicts them graphically: the more transitions the ticker is the line of the graph.

ntopng’s behavioural checks have been extended in order to supervise Modbus communication and detect anomalies.

These checks trigger an alert when a flow:

• Reports too many (configurable) exceptions that usually indicate issues.
• Requests an unexpected function code. The network administrator can list the allowed function codes, triggering an alert for other function codes that have been observed but not configured.
• An unexpected function code transition is reported.

As with IEC 60870-5-104, in ntopng preferences it is possible to specify for how long traditions of a ModbusTCP flows are observed.

During the learning period, ntop keeps track of the transitions and stores them internally. Past the specified learning time, ntopng triggers an alert whenever an invalid transition is observed.

Modbus support is currently implemented in the ntopng (dev) version and it will be included in the next stable version. You can refer to the ntopng user’s guide for details.

Enjoy !

As traffic rate increases, it is important to tune packet processing in order to avoid drops and thus educe visibility. This post will show you a few tricks for improving the overall performance and better exploit modern multicore systems.

The Problem

ntopng packet processing performance depends on the number of ingress pps (packets per second) as well the number of flows/hosts being monitored and number of enabled behavioural checks. With ntopng you can expect to process (your mileage varies according to the CPU/system you are using) a few (< 5) Mpps (million pps). So if you need to enable more traffic what can you do? Read below.

Maximising ntopng Packet Processing

In order to improve the processing performance it is necessary to configure multiple ntopng network interfaces thus partitioning the workload across multiple interfaces. The easiest way to split ingress packets across network interfaces is by means of RSS (Receive Side Scaling) that can be configured as explained here. In essence RSS enables hardware-based ingress traffic balancing across multiple virtual network queues. Basically enabling RSS with a value of 4, the (physical) network adapter is partitioned into 4 (logical) virtual network adapters, each receiving a (coherent, i.e. the RX and TX directions of a flow are sent to the same virtual adapter) subset of the traffic. PF_RING identifies RSS queues with <network interface>@<RSS queueId>, so ntopng needs to be configured as follows:

• ntopng -i -i eth0@1 -i eth0@2 -i eth0@3 -i view:all

The view interface allows you too see from a single interface the traffic that is processed by the individual sub-interfaces. Using this technique you can almost scale linearly… as long as you have enough cores available. Note that a faster version of the above example is based on ZC, and in this case you need to change the command line into:

• ntopng -i zc:eth0@0 -i zc:eth0@1 -i zc:eth0@2 -i zc:eth0@3 -i view:all

Maximising ntopng Flow Collection

Now that you have learnt the trick we can do the same with flow collection, by enabling multiple ntopng collection interfaces. Collecting flows is necessary if flows are generated by a flow-based devices such as a sFlow-enabled switch or NetFlow-based router. Instead using flow as an intermediate format is required for using nProbe/nProbe Cento as packet preprocessor, this to maximise the performance. You can expect nProbe to process about 10 Mpps (using RSS) and nProbe Cento to go above 100 Mpps (or 100 Gbit line rate).

nProbe

• ntopng -i tcp://127.0.0.1:1234 -i tcp://127.0.0.1:1235 -i tcp://127.0.0.1:1236 -i tcp://127.0.0.1:1237 -i view:all
• nprobe -i mlx:mlx5_0@0 –zmq tcp://127.0.0.1:1234
• nprobe -i mlx:mlx5_0@1 –zmq tcp://127.0.0.1:1235
• nprobe -i mlx:mlx5_0@2 –zmq tcp://127.0.0.1:1236
• nprobe -i mlx:mlx5_0@3 –zmq tcp://127.0.0.1:1237

nProbe Cento

• ntopng -i tcp://127.0.0.1:5556c
• cento -i mlx:mlx5_0@[0-3] –zmq tcp://127.0.0.1:5556

if you want to read more about the topic of this post, please see the following posts about:

• ntopng
• nProbe
• nProbe Cento

Enjoy !

This is to invite you to the latest ntop webinar before the summer break. The major webinar topic will include

• n2disk smart packet recorder
• Latest OT/SCADA Developments; IEC 104 and ModbusTCP
• Suricata/Zeek IDS Acceleration at 40/100 Gbit
• New ntopng charts and tables
• Traffic Rules
• Inactive Host Monitoring
• and ,,,,

You can register for the webinar at this page: the registration link will be include the instructions for joining the webinar.

Hope to see you online !

Months ago we have talked how ntopng identifies ad monitors Zoom calls quality. Today we show how call monitoring has been now seamlessly extended to Microsoft Teams.

Thanks to nDPI, ntopng is now able to detect Teams calls and to label them according to the stream type:

• Video
• Audio
• Screen Sharing.

For each call it is possible to visualise the stream type as well as the flow statistics.

If ntopng collects RTP flows from nProbe it also reports the call quality as exported by nProbe.

Both Zoom and Microsoft Teams monitoring is part of all ntopng versions and currently available in the dev branch (as well in the next ntopng stable release).

Enjoy !

Those who missed our June 2023 webinar can watch the webinar recording as well glance through the presentation slides.

The Problem

Let’s assume that you have a Network where local hosts generate a constant amount of traffic. How do you find if they are misbehaving? It happens that some local host starts behaving strangely, by having an abnormal amount of traffic (sent or received) with respect to their recent past: how can you spot these situations and report them with an alert.

This is why we have created the Local Traffic Rules page: users can now define custom Volume/Throughput threshold for some (or all) local hosts. You can also set thresholds on score and application protocols 9e.g. WhatsApp).

For instance, if a DNS server is available in the network, a check for that host regarding the DNS traffic could be added: alert me if the DNS traffic for a host exceeds 1 GB/day.

How Thresholds Work

The Local Traffic Rules page can be found under the Hosts menù.

Here it is possible to set up the rules you like, for every Local Host or Interface you want.

The rule is composed by:

• Target (who is monitored)
• Type (Host or Interface)
• Metric (what is monitored)
• Check Frequency (how often it is monitored)
• Threshold (the threshold not be exceeded up/own)

(In the action column instead, it is possible to edit/delete the rule)

By clicking the ‘+’ icon next to the search bar of the table, it’s possible to add a new rule

Here it is possible to :

• Set the type of rule.
• Add the Target (what we are monitoring)
• Select the monitored metric: Traffic, Score, and all the Application Protocols (e.g. DNS, HTTP, SMTP, …)
• Set the check frequency: every five minutes, every hour, or once per day
• Specify the threshold, which can be measured in volume (e.g. 1 GB), throughput (e.g. 1 Gbps), or percentage (e.g. + 20%, meaning that the current value has not to exceed by more than 20% the value of the metric during the previous check).

So now it’s time for you to monitor your Hosts and Interfaces and be sure they do not misbehave.

Enjoy this new feature, and send us your feedback