nTop now uses the nDPI (network deep packet inspection) library to classify packets within network traffic for those protocols that either do not use a standard port (defined as well known ports like https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers and https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) or that are dynamically assigned.
In any case the need to classify not only the packet header but also the transport protocol has led to the need for a more detailed classification of network traffic. For example note that years ago not everything was transported over TCP/80 port, which was typically used just for HTTP and related web resources. Today this is no longer the case, as for example with Skype and other peer-to-peer applications whose traffic is transported over HTTP or HTTPS precisely for the purpose of being able to function even in environments with the presence of packet filtering and firewalling. Other examples include social networks, geographic maps, video streaming services, in other words, the TCP/80=web equation is no longer valid.
Motivated by these needs, this is where a library such as nDPI enables nTop to recognize many of the most popular applications used today. Here are some examples:
But in the case of a network we are currently analyzing, there were still some applications defined as Unknown:
Here is where the nDPI library with the right instructions allows us, as in this case, to define the classification of the 1.37GB of traffic that in this case is not identified.
This requires adding the following directive to nTop:
-p=/var/lib/ntopng/protos.txt
via the configuration file found at the path:
/neteye/shared/ntopng/conf/ntopng.conf
Where the protos.txt file must adhere to the following structure:
# Format: | |
# <tcp|udp>:<port>,<tcp|udp>:<port>,…..@<proto> | |
tcp:81,tcp:8181@HTTP | |
udp:5061-5062@SIP | |
tcp:860,udp:860,tcp:3260,udp:3260@iSCSI | |
tcp:3000@ntop |
Here you can see for example we are indicating to nTop that on our network TCP/81 traffic should still be classified as HTTP traffic.
And so it becomes a sorting and recognition task for how we can distribute the daemon sockets listening on the systems of our serving hosts. For example once for security reasons I had to configure an SSH daemon in order to make it listen on TCP/2222 port instead of TCP/22. This will surely help us classify the network traffic analyzed by nTop in a detailed way.
Did you read this article because you’re knowledgeable about networking? Do you have the skills necessary to manage networks? We’re currently hiring for roles like this as well as other roles here at Würth Phoenix.