Last week when I was trying to read data from packets, I came across a lot of garbled or unreadable data. I thought I could be unpacking the packets wrong, but I verified that I wasn’t. I realised that that data was just encrypted data and thus, unless I had the session keys as well, I won’t be able to read that data. I was able to verify this after looking at the packets in wireshark, as wireshark can tell us whether the packet was HTTPS or HTTP.
This week, I spent some time reading about an open source tool called ntopng. It is a network monitoring tool with a beautiful web-ui. It took me some time to set it up in the lab, but after setting it up, understanding the interface was easy and fairly straightforward.
I did not configure ntopng as it was mentioned in their docs, but rather configured it to suit the setup in the lab. ntopng requires nprobe, another plugin offered by ntopng, to collect data (packets). It is essentially active service discovery. After collecting the data from nprobe, ntopng analyses the data and updates its web interface. But, instead of using nprobe to collect data, I used the already existing setup of port mirroring (SPAN) on the cisco switch described in a previous entry. So, ntopng is made to listen on interface eth0 instead of a TCP port.
From what I understood about ntopng, it actually deviates from what I have been trying to do by quite a margin. In this project, I am aiming to discover the service itself apart from the protocol being used by the service(s). But, what ntopng does is, it only gives application protocol being used by some host, and not the application itself! This is fairly useless for a sysadmin wanting to perform service discovery in a network.
Although it deviates from what I am trying to accomplish, nonetheless I can understand how it analyses the packets, and I have shortlisted a few pages of code in ntopng to study for the next week.
Things to see in ntop code:
page=ndpi
This is under lua/host_details.lua
Leave a Reply