The default ntopng configuration, is suitable for most of our users who deploy it on a home network or small enterprise network (typically a /24 network) with link speed <= 100 Mbit. This does NOT mean that ntopng cannot operate on faster/larger networks, but that it cannot be used without any configuration.

The first thing to modify are the -x/-X settings. You need to set them to double the max size you expect on your network. Example if you expect to have (including both local and remote hosts) at most 35000 active hosts, you need to set -x at no less than 70000. Better to have a larger value than a smaller one: small values mean that you will not be able to see all hosts, and also the performance will be poor as ntopng was not tuned properly. Larger values require ntopng to use more memory, but if you have plenty of RAM it is not a good argument to use extremely large values (e.g. -x  1000000 in the previous example) as you will waste resources for no reason.

Another parameter to setup is -m that specifies the list of local networks. Please make sure you set the real networks you plan to use. Some users are lazy and set it to 0.0.0.0/0: this is not a good idea as ntopng will save stats for all the hosts and thus you will exhaust disk space quickly.

Flow persistency is setup via -F. When flows are saved to MySQL or ElasticSearch, ntopng has to do extra work, and if the database is not fast enough this will introduce a bottleneck. Please pay attention to optimising this aspect in particular if the DB runs on the same ntopng box, where resources are shared.

Packet capture in ntopng has been designed to be as efficient as possible. We decided to have one processing thread per interface configured in ntopng.  Depending on a) the CPU power b) number of hosts/flows, and c) packet capture technology, the number of packets-per-second ntopng can process can change. On a x86 server with PF_RING (non ZC) you can expect to process about 1 Mpps/interface, with PF_RING ZC at least 2/3 Mpps/interface (usually much more but typically not more than 5 Mpps). This means than if you want to monitor a 10 Gbit interface (or even worse a 40 Gbit), you need:

• Use PF_RING ZC to accelerate packet capture.
• Use RSS to virtualise the NIC in virtual queues. For instance you can set RSS=4 to virtualise the 10 Gbit interface into 4 virtual 10G interfaces.
• You need to start ntopng polling packets from all virtual interfaces.

Example suppose you have a 10/40 Gbit interface named eth1, and suppose to use RSS=4 with PF_RING ZC. Then you need to start ntopng as ntopng -i zc:eth1@0  -i zc:eth1@1  -i zc:eth1@2  -i zc:eth1@3

Note that in this case ntopng will try to bind threads on different cores, but as computer architectures can change based on use of NUMA and differences on CPUs, we advise to set -g to the exact cores where you want to bind each interface polling thread. Make sure (only on multi-CPU systems) you use physical cores on the same NUMA node where the network interface has been plugged in. Of course you can use interface views (see the User’s Guide) to merge all the virtual interfaces into a single interface (please understand that if you have million of hosts this might become a bottleneck).

Hope this post will help you to optimise ntopng. If you have questions and suggestions, let’s start a discussion on github.

As we have released 2.4, it is now time to plan for the next release and highlight the list of features we plan to implement so we can start a discussion and get some feedback. The major changes we would like to introduce include:

• Rework interface views to make them more efficient and not an expecting as they are today.
• Add full support for sFlow/NetFlow so that we can keep per interface statistics as many other collectors do.
• Introduce some “enterprise-oriented” features such as per-AuthononousSystem statistics and traffic accounting, qcreate an alarm dashboard with full alarm support open/closed.
• Traffic interpretation: as of today we graph flow x, y, z but flows are still too low level. It would be nice to correlated them into more high-level activities such as user X downloaded a file, Dropbox folder of IP Y has sync etc etc. in essence continue the transition started with packet to flows, towards some meaningful for humans.
• Add full L2 support: keep a list of mac addresses, associate them to users/devices, implement layer-2 features such as ARP/DHCP monitoring.
• Implement per-flow scripting so that we can execute actions in Lua at flow-level (example trigger an alert when event Z happens).
• Time based comparison (e.g. compare today’s traffic with what happened a week ago at the same time/day of the week) and reporting.
• Integrate messager bots to query ntopng from mobile and for distributing alerts to subscribers.

Anything else you would like to see in the next ntopng release? Willing to help? Please contact us if interested in helping with the development.

This is to renew the invitation to meet you next week at the ntop users meeting colocated with Sharkfest Europe. The event is free of charge but seats are limited. More information can be found here.

Hope too see you next week at the workshop!

ntopng uses partitioned MySQL tables when storing flows. As MySQL needs a file handle for each partition and its index, it is important to make sure that the open_files_limit is large enough to allow the process to keep all these files open. Typically, open_files_limit  default value works out-of-the-box but there are some packages/distributions that keeps this number pretty low.

When the current value is too low, ntopng can show errors such as

[MySQLDB.cpp:55] ERROR: MySQL error: Out of resources when opening file './ntopng/flowsv6#P#p23.MYD' (Errcode: 24 - Too many open files) [rc=-1]

The current value can be checked from a MySQL shell

mysql> SHOW VARIABLES LIKE 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 256   |
+------------------+-------+
1 row in set (0.02 sec)

mysql>

In order to increase the open_files_limit it can be necessary to tweak the MySQL configuration file — and, sometimes, also the kernel — to increase it.

To increase that value it is necessary to change the MySQL configuration file adding an entry under [mysqld]

[mysqld]
open_files_limit = 1024

Editing the configuration file may not be sufficient. Depending on the OS/platform it can also be necessary to tune the system-wide resources limits using ulimit.

VoIP applications usually limit theirs monitoring capabilities to the generation of CDR (Call Data Records) that are used for the generation of billing/consumption data. In essence you know how many calls a certain user/number has made, the duration etc. While this information can be enough for basic monitoring, it is not enough for guaranteeing reliable call quality as these systems are essentially blind with respect to call quality. Wireshark can analyse both call signalling and voice, but it is a troubleshooting tool meaning that it cannot be used for permanent monitoring but just for analysing specific situations when there is a specific problem to analyse.

Fortunately you can complement CDR with realtime VoIP traffic monitoring and voice quality analysis using nProbe Pro (with VoIP plugin) and ntopng. All you need is to send nProbe (usually via a span port or network tap) the VoIP traffic (or if you want all your network traffic including VoIP) for analysis. Via redis, nProbe is able to analyse SIP, RTP, RTCP and to correlate SIP with RTP, so that you know for each RTP stream what is the call it belongs to.

Supposing that the traffic to monitor is received on eth1 all you need to do is to start the following applications (in the example below thay have been started on the same machine but via ZMQ flows can be sent remotely over the network in an encrypted format)

# nprobe -i eth1 -T "%IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_NEXT_HOP %INPUT_SNMP %OUTPUT_SNMP %IN_PKTS %IN_BYTES %FIRST_SWITCHED %LAST_SWITCHED %L4_SRC_PORT %L4_DST_PORT %TCP_FLAGS %PROTOCOL %L7_PROTO @SIP@ @RTP@" --redis localhost --zmq tcp://127.0.0.1:1234

$ ntopng -i tcp://127.0.0.1:1234

In essence nProbe analyses the traffic and sends ntopng flows via ZMQ. ntopng collects the flows and display them on the user interface. Inside the nProbe template there are two special information elements @SIP@ and @RTP@: they represent a wildcard for various information elements such as SIP caller/called or RTP codecs. This way users can forget about VoIP details and focus on monitoring traffic

As you can see, ntopng interprets the VoIP information and represents it in a user-friendly way. It reports not just about CDRs, but it can analyse voice quality by computing pseudo-MOS. This enables network administrators to spot calls with bad quality and try to find a solution to the problem. If you enable in ntopng the export to ElasticSearch and/or MySQL, you can dump call information persistently on a database or use Kibana to create a dashboard about VoIP calls.

# StartTime[epoch]	EndTime[epoch]	SIP_Server[ascii:32]	ClientIP[ascii:32]	CallId[ascii:64]	CallingParty[ascii:64]	CalledParty[ascii:64]	RTPInfo[ascii:64]	SIPFailureCode[uint]	ReasonCause[uint]	Packets[uint]	CallState[ascii:64]	StateMachine[ascii]
#
1481205353	1481205353	212.13.205.165	10.96.5.59	b654d999b6321def238939c5d48ce777@10.37.129.2	brix <sip:brix@testyourvoip.net>	<sip:tyv@212.13.205.165>	10.37.129.2:50070,212.13.205.165:50422	200	0	12105	CALL_COMPLETED	INVITE=1481205353,TRYING=0,RINGING=1481205353,INV_RSP=1481205353,BYE=1481205353,CANCEL=0
1481205353	1481205353	10.96.5.59	212.13.205.165	400ad5a7a28e421f355369a9fc8910ee@192.168.1.101	brix <sip:brix@testyourvoip.net>	<sip:tyv@212.13.205.165>	212.13.205.165:50390,0.0.0.0:0	200	0	5	CALL_IN_PROGRESS	INVITE=0,TRYING=0,RINGING=1481205353,INV_RSP=1481205353,BYE=0,CANCEL=0

Above you can find an excerpt of a call sample. The whole list of SIP

%SIP_CALL_ID               	SIP call-id
%SIP_CALLING_PARTY         	SIP Call initiator
%SIP_CALLED_PARTY          	SIP Called party
%SIP_RTP_CODECS            	SIP RTP codecs
%SIP_INVITE_TIME           	SIP time (epoch) of INVITE
%SIP_TRYING_TIME           	SIP time (epoch) of Trying
%SIP_RINGING_TIME          	SIP time (epoch) of RINGING
%SIP_INVITE_OK_TIME        	SIP time (epoch) of INVITE OK
%SIP_INVITE_FAILURE_TIME   	SIP time (epoch) of INVITE FAILURE
%SIP_BYE_TIME              	SIP time (epoch) of BYE
%SIP_BYE_OK_TIME           	SIP time (epoch) of BYE OK
%SIP_CANCEL_TIME           	SIP time (epoch) of CANCEL
%SIP_CANCEL_OK_TIME        	SIP time (epoch) of CANCEL OK
%SIP_RTP_IPV4_SRC_ADDR     	SIP RTP stream source IP
%SIP_RTP_L4_SRC_PORT       	SIP RTP stream source port
%SIP_RTP_IPV4_DST_ADDR     	SIP RTP stream dest IP
%SIP_RTP_L4_DST_PORT       	SIP RTP stream dest port
%SIP_RESPONSE_CODE         	SIP failure response code
%SIP_REASON_CAUSE          	SIP Cancel/Bye/Failure reason cause
%SIP_C_IP                  	SIP C IP adresses
%SIP_CALL_STATE            	SIP Call State

and RTP

%RTP_SSRC                       RTP Sync Source ID
%RTP_FIRST_SEQ             	First flow RTP Seq Number
%RTP_FIRST_TS              	First flow RTP timestamp
%RTP_LAST_SEQ              	Last flow RTP Seq Number
%RTP_LAST_TS               	Last flow RTP timestamp
%RTP_IN_JITTER             	RTP jitter (ms * 1000)
%RTP_OUT_JITTER            	RTP jitter (ms * 1000)
%RTP_IN_PKT_LOST           	Packet lost in stream (src->dst)
%RTP_OUT_PKT_LOST          	Packet lost in stream (dst->src)
%RTP_IN_PKT_DROP           	Packet discarded by Jitter Buffer (src->dst)
%RTP_OUT_PKT_DROP          	Packet discarded by Jitter Buffer (dst->src)
%RTP_IN_PAYLOAD_TYPE       	RTP payload type
%RTP_OUT_PAYLOAD_TYPE      	RTP payload type
%RTP_IN_MAX_DELTA          	Max delta (ms*100) between consecutive pkts (src->dst)
%RTP_OUT_MAX_DELTA         	Max delta (ms*100) between consecutive pkts (dst->src)
%RTP_SIP_CALL_ID           	SIP call-id corresponding to this RTP stream
%RTP_MOS                   	RTP pseudo-MOS (value * 100) (average both directions)
%RTP_IN_MOS                	RTP pseudo-MOS (value * 100) (src->dst)
%RTP_OUT_MOS               	RTP pseudo-MOS (value * 100) (dst->src)
%RTP_R_FACTOR              	RTP pseudo-R_FACTOR (value * 100) (average both directions)
%RTP_IN_R_FACTOR           	RTP pseudo-R_FACTOR (value * 100) (src->dst)
%RTP_OUT_R_FACTOR          	RTP pseudo-R_FACTOR (value * 100) (dst->src)
%RTP_IN_TRANSIT            	RTP Transit (value * 100) (src->dst)
%RTP_OUT_TRANSIT           	RTP Transit (value * 100) (dst->src)
%RTP_RTT                   	RTP Round Trip Time (ms)
%RTP_DTMF_TONES            	DTMF tones sent (if any) during the call

information elements are reported above.

Thanks to PF_RING, using nProbe it is possible to monitor large VoIP networks using a low-cost x86-based server with tent of thousand concurrent calls. Advanced users can instruct nProbe also to create call logs (you need to add –sip-dump-dir <dump dir> to the nProbe command line) in addition to exporting data to ntopng.

Happy VoIP traffic monitoring!

In computer networks, devices are identified by an IP and a MAC. The IP can be dynamically assigned (so it might not be persistent), whereas the MAC is (in theory) unique and persistent for identifying a device. Non-technical users, do not know these low-level details, and in general it makes sense to cluster devices using other criteria. VLANs are a way to logically group devices belonging to the same administrative domain, but this is still a low-level network-level properly.

When administering a network, we have have realised that we need a way to cluster devices onto logical groups, that have nothing to do with network-level properties such as IP address. In order to address this need, in ntopng (development version only at the moment, but soon also in the stable release) we have implemented what we have called Host Pool. They are logical group of devices, that can identified by IP address and/or MAC. In order to define a host pool you need to select the interface view and click on the host pool icon.

There you can define a pool by setting its name, and on the membership tab you can see what are the devices belonging to the pool. Remember that you can set both the MAC and the IP address (or network).

At this point in the host view you can see the pool associated with a host that is depicted on the green badge next to the IP address/network it belong to.

It is worth to remark that host pools are a logical cluster of devices that do not have to belong to the same network. Example you can group all printers of your company, all mobile phones etc. In essence this is a way to cluster devices and to easily spot those that are unknown and thus suspicious (e.g. a new MAC we have not listed and thus that can hide a device that should not have been connected) or simply ungrouped. You can list all active devices belonging to a pool by clicking on the pool badge. Example, if you want to list all local devices that do not belong to any pool, just click on the pool badge of a host not belonging to any pool, then from the “Filter Hosts” menu select local hosts only and you will see the host list.

We plan to further expand the host pool concept before the next stable ntopng release, by easing the association of hosts to pools, multi-pool support (e.g. my smartphone should belong both to “Luca’s Devices” and to “Smartphone” pools), and applying actions to pools (e.g. execute Lua script action.lua when a new device belonging to pool MyPool appears on the network). In a future blog post, we’ll discuss how host pools are used by ntopng in bridge mode with the captive portal, to automatically bind network devices to users.

Stay tuned, and report us suggestions or enhancements you would like to see by opening a ticket on github.

Logstash comes in very handy when it is necessary to manipulate or augment data before the actual consolidation. Typical examples of augmentation include IP address to customer ID mappings and geolocation, just to name a few.

ntopng natively supports network flows export to Logstash. The following video tutorial demonstrates this feature.

Most security-oriented traffic analysts rely on IDSs such as Bro or Suricata for network security. While we believe that they are good solutions, we have a different opinion on this subject. In fact we believe that it is possible to use network traffic monitoring tools like ntopng to spot many security issues that would make and IDS too complex/heavy to use (if possible at all). What many of our users are asking, is the ability to highlight possible scenarios where there is a potential security issue to be analysed more in details using more-security oriented tools. This while using a lightweight approach that an IDS cannot offer because it can be very verbose and information oriented, rather than providing an overall picture of the network status and help understanding real issues. For instance is a ping to a host a real problem? We don’t think so, but most IDSs would mark this as a warning for “information disclosure”. At the end you will have your hard drive filled up by many security logs like these that probably won’t make your network more secure, but for sure generate many security alerts that will often be ignored.

These presentation slides give you an idea of what you can expect today using ntopng from the security view point. This is just the beginning, it’s a revamp of old concepts we prototyped years ago, and that have a new life in the current ntopng. However this is not all, as in the coming months we plan to make ntopng more powerful and able to go beyond this initial step.

Stay tuned!

Summary

• SNMP is widely used for network monitoring.
• Being able to remotely monitor network devices is fundamental to have a clear picture of present and past network health.
• ntopng systematically interacts with SNMP devices to provide historical and real-time insights on the network.

ntopng SNMP support

Simple Network Management Protocol (SNMP) is one of the de-facto standards used to remotely monitor network devices such as routers, switches and servers, just to name a few. With ntopng Pro it is possible to consistently and programmatically interact with those devices to have a real-time view of their status, as well as to build historical record for future investigations and trouble shootings.

Overview of configured SNMP devices

ntopng represent an effective way to have a clear, centralized view of multiple devices. Indeed, a dedicated SNMP menu provides instantaneous access to all the configured devices, and allow the administrator to add/remove devices from the pool.

Configured devices are listed along with their address, description, location, and other information. The rightmost column gives access to device-specific actions.

Adding a new SNMP device

An “Add New Device” link is available at the bottom of the “SNMP Devices” page. The addition of a new SNMP is straightforward as it only requires to specify device IP address and SNMP community. Upon successful addition, the device will appear in the list of devices.

Real-time inspection of an SNMP device

A details page is available for every SNMP device configured simply by clicking on the “Device IP” hyperlink. The access to the details page triggers a series of SNMP queries aimed at retrieving the health and status of the device of interest. Retrieved information include, but is not limited to, device description, contact, and uptime, along with its interfaces, connected MAC addresses and transferred bytes. An handy warning is shown when a non-trunk port has multiple mac addresses seen, or when slow devices are attached to high-speed ports.

Historical inspection of an SNMP device

Historical SNMP data is accessible by clicking the “Chart” icon that is available for any SNMP device as well as for every of its interfaces. Chart icon may not be visible. In that case, historical SNMP timeseries have to be enabled from ntopng preferences.

The chart above shows a stacked view of all the device interfaces. Single devices interfaces can be selected as well. In this case, a breakdown between ingress and egress traffic is visualized.

Mapping an host to SNMP devices

Another useful feature provided by ntopng is the ability to probe SNMP devices with the aim of detecting on which devices and interfaces a particular host has been seen. This lookup is automatically performed when accessing every host details page, provided that there is at least one SNMP device configured.

In the image above, host 192.168.2.222 has been found to be connected to interface 3 of the SNMP device 192.168.2.169.

Conclusion

This post demonstrates how ntopng can be used to systematically interact with SNMP devices to monitor their health and status. Data is visualized in real-time but also recorded for historical analyses. Currently both SNMP v1 and v2c are supported. In the near future we will add the ability to trigger alerts based on SNMP (e.g. when a port changes status), and we’ll add support for proprietary MIBs out of the box so that you can use ntopng alerts to be notified when a paper is running out of paper, or the router CPU is too heavily loaded.

These days many people are talking about ransomware and in particular of the problems created by WannaCry. Some ntop users contacted us asking if they could use our tools for detecting and stopping ransomware. While the best solution to these issues is to properly implement network security (that is a process, not a product in our opinion) by designing the network properly and keeping hosts updated,  it is usually possible to use ntopng to detect infections, block most of them, and have a list of hosts that might have been compromised. If you run ntopng in passive mode (i.e. you send ntopng traffic from a span port or a tap) you can be notified about suspicious or blacklist host contacting (for being contacted) by local hosts either looking at the ntopng alert dashboard or on the go through the slack integration (see menu Preferences > External Alerts Report > Slack Integration inside ntopng or read this document for details).

In the latest ntopng 2.5.x series we have implemented (see menu Preferences > Alerts >Security Alerts > Enable Hosts Malware Blacklists)

the ability for ntopng to nightly download a list of blacklisted hosts that are used for detecting potential security issues, or if using noting in inline mode, to automatically block this traffic and thus avoid infections.

If you go in the historical data explorer menu, you can browse past flows and see flow details. As you can see in DNS flows you have the query name. This can help you finding out for instance what are the hosts that are querying WannaCry  hosts.

If you are using ntopng in inline mode, you can also use ntopng to force using specified DNS servers (i.e. ntopng captures the DNS query, reforges the packet so that the DNS query is sent to the DNS set in the preferences, and masks the response back to the DNS client that is then unable to figure out that the response has been served by another DNS server)

This way you can prevent local host from contacting potential malware site by sampling setting as default a DNS such as Norton ConnectSafe (note that we’re not affiliated with Norton, this is just an example) so that whenever a DNS query for a potential dangerous name is performed, instead of sending back in the response the requested host IP, the IP of a landing page is returned and thus your host is unable to talk with the infected site.

These are just a few examples of what you can do with ntopng to secure your network and monitor security infections. If interested we have written a tutorial that describes all this more in detail.

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.

Since its introduction in 1998, ntop(ng) has been a pure (well beside DNS address resolution if enabled) passive network monitoring tool. Recently we have complemented it with active device discovery in order to find out if there are silent devices in our network, and what services/OS our devices are featuring. In this article we will analyze how active discovery works, leaving to a future article the analysis of passive discovery.

Active discovery can be started on demand from the menu

or from the network preferences to enable periodic discovery

The result of network discovery is stored in redis and kept for future use. It allows to figure out the device type (is it a printer, a router or a tablet?) and their OS/features and advertised network services.

Above you can see a scan of a small home network. As you can see ntopng has recognised the router, and for my iMac detected the network services as well the exact computer model and type.

If you are wondering how active discovery works in ntopng, unless you want to read the its source code, below you can have a brief summary.

1. The first thing ntopng does is a “ARP ping” to all local subnet hosts to identify the active assets. ntopng reads the IP subnet/mask from the network internet interface (if the interface has no subnet, for instance when you have a span port, active discovery won’t work) and starts pinging all devices. We do this via ARP as it’s a reliable method contrary to ICMP ping that might be disabled for some hosts. At the end of this process we have a list of active hosts that is compared against the list of devices that you see under Devices -> Layer 2. If there is a device that answers ARP ping that was not listed under L2 we mark it as ghost device (i.e. a device that is active on our local subnet but that is silent/ghost)
2. We do a SSDP discovery so that devices (not all devices will answer to SSDP) can tell us the services they advertise. This works by sending a message to a multicast address and waiting for responses. Note that we might receive answers from hosts that do NOT belong to our subnet as they have seen the SSDP request: this is a good way to figure out it our local LAN is serving multiple networks or if somebody has created a private network (without permission?). So if you do that, make sure your devices are silent (note that ARP messages are sent in broadcast so even without SSDP you will be discovered by the network administrators), otherwise your secret network overlay will be detected. Also note that via SSDP is possible to learn the device capabilities as well the icon that is eventually stored inside the network device and that is shown by ntopng next to the IP address.
3. In the meantime while SSDP responses are being received, for all active hosts discovered via ARP, ntopng sends a SNMP request to learn more about the device. As the standard “public” community is used, we might discover only a part of the devices. SNMP helps detecting features of devices such as printers or access points/routers.
4. As small networks do not usually have a DNS, we use MDNS to resolve names (see for instance fritx.box) for local hosts when DNS is not available. Via MDNS it is also possible to know (in particular for Apple devices/phones) the advertised services and the device model/type. Recent OSX versions are much more verbose than old releases.
5. Done all this we merge the information so far collected and produce discovery information as you can see on the above screen. The discovery information is kept on redis so it survives across ntopng restarts.

In summary

• If you have “hidden” devices on your network using a different subnet other than the one that you are supposed to use, make sure that devices are really hidden. But in all cases ARP will be broadcasted, so you will be caught soon or later.
• If you have installed in your network a NAT router that hides your private devices, ntopng will figure this out. For instance looking at User-Agent in HTTP headers that report OS and not just browser. Beware of this or always use SSL that is unlikely as your OS is sending many spontaneous requests so you will be caught too.
• SSDP/MDNS are very verbose protocols and advertise more information that you might think. Consider this when planning network security.

Finally we need your help! In our networks there are not so many different device types. Please send us reports form discovery in your network so we can improve the discovery process, or if you can send us a pull request with enhancements. Thank you!

Most security-oriented traffic analysts rely on IDSs such as Bro or Suricata for network security. While we believe that they are good solutions, we have a different opinion on this subject. In fact we believe that it is possible to use network traffic monitoring tools like ntopng to spot many security issues that would make and IDS too complex/heavy to use (if possible at all). What many of our users are asking, is the ability to highlight possible scenarios where there is a potential security issue to be analysed more in details using more-security oriented tools. This while using a lightweight approach that an IDS cannot offer because it can be very verbose and information oriented, rather than providing an overall picture of the network status and help understanding real issues. For instance is a ping to a host a real problem? We don’t think so, but most IDSs would mark this as a warning for “information disclosure”. At the end you will have your hard drive filled up by many security logs like these that probably won’t make your network more secure, but for sure generate many security alerts that will often be ignored.

These presentation slides give you an idea of what you can expect today using ntopng from the security view point. This is just the beginning, it’s a revamp of old concepts we prototyped years ago, and that have a new life in the current ntopng. However this is not all, as in the coming months we plan to make ntopng more powerful and able to go beyond this initial step.

Stay tuned!

Summary

• SNMP is widely used for network monitoring.
• Being able to remotely monitor network devices is fundamental to have a clear picture of present and past network health.
• ntopng systematically interacts with SNMP devices to provide historical and real-time insights on the network.

ntopng SNMP support

Simple Network Management Protocol (SNMP) is one of the de-facto standards used to remotely monitor network devices such as routers, switches and servers, just to name a few. With ntopng Enterprise it is possible to consistently and programmatically interact with those devices to have a real-time view of their status, as well as to build historical record for future investigations and trouble shootings.

Overview of configured SNMP devices

ntopng represent an effective way to have a clear, centralized view of multiple devices. Indeed, a dedicated SNMP menu provides instantaneous access to all the configured devices, and allow the administrator to add/remove devices from the pool.

Configured devices are listed along with their address, description, location, and other information. The rightmost column gives access to device-specific actions.

Adding a new SNMP device

An “Add New Device” link is available at the bottom of the “SNMP Devices” page. The addition of a new SNMP is straightforward as it only requires to specify device IP address and SNMP community. Upon successful addition, the device will appear in the list of devices.

Real-time inspection of an SNMP device

A details page is available for every SNMP device configured simply by clicking on the “Device IP” hyperlink. The access to the details page triggers a series of SNMP queries aimed at retrieving the health and status of the device of interest. Retrieved information include, but is not limited to, device description, contact, and uptime, along with its interfaces, connected MAC addresses and transferred bytes. An handy warning is shown when a non-trunk port has multiple mac addresses seen, or when slow devices are attached to high-speed ports.

Historical inspection of an SNMP device

Historical SNMP data is accessible by clicking the “Chart” icon that is available for any SNMP device as well as for every of its interfaces. Chart icon may not be visible. In that case, historical SNMP timeseries have to be enabled from ntopng preferences.

The chart above shows a stacked view of all the device interfaces. Single devices interfaces can be selected as well. In this case, a breakdown between ingress and egress traffic is visualized.

Mapping an host to SNMP devices

Another useful feature provided by ntopng is the ability to probe SNMP devices with the aim of detecting on which devices and interfaces a particular host has been seen. This lookup is automatically performed when accessing every host details page, provided that there is at least one SNMP device configured.

In the image above, host 192.168.2.222 has been found to be connected to interface 3 of the SNMP device 192.168.2.169.

Conclusion

This post demonstrates how ntopng can be used to systematically interact with SNMP devices to monitor their health and status. Data is visualized in real-time but also recorded for historical analyses. Currently both SNMP v1 and v2c are supported. In the near future we will add the ability to trigger alerts based on SNMP (e.g. when a port changes status), and we’ll add support for proprietary MIBs out of the box so that you can use ntopng alerts to be notified when a paper is running out of paper, or the router CPU is too heavily loaded.

These days many people are talking about ransomware and in particular of the problems created by WannaCry. Some ntop users contacted us asking if they could use our tools for detecting and stopping ransomware. While the best solution to these issues is to properly implement network security (that is a process, not a product in our opinion) by designing the network properly and keeping hosts updated,  it is usually possible to use ntopng to detect infections, block most of them, and have a list of hosts that might have been compromised. If you run ntopng in passive mode (i.e. you send ntopng traffic from a span port or a tap) you can be notified about suspicious or blacklist host contacting (for being contacted) by local hosts either looking at the ntopng alert dashboard or on the go through the slack integration (see menu Preferences > External Alerts Report > Slack Integration inside ntopng or read this document for details).

In the latest ntopng 2.5.x series we have implemented (see menu Preferences > Alerts >Security Alerts > Enable Hosts Malware Blacklists)

the ability for ntopng to nightly download a list of blacklisted hosts that are used for detecting potential security issues, or if using noting in inline mode, to automatically block this traffic and thus avoid infections.

If you go in the historical data explorer menu, you can browse past flows and see flow details. As you can see in DNS flows you have the query name. This can help you finding out for instance what are the hosts that are querying WannaCry  hosts.

If you are using ntopng in inline mode, you can also use ntopng to force using specified DNS servers (i.e. ntopng captures the DNS query, reforges the packet so that the DNS query is sent to the DNS set in the preferences, and masks the response back to the DNS client that is then unable to figure out that the response has been served by another DNS server)

This way you can prevent local host from contacting potential malware site by sampling setting as default a DNS such as Norton ConnectSafe (note that we’re not affiliated with Norton, this is just an example) so that whenever a DNS query for a potential dangerous name is performed, instead of sending back in the response the requested host IP, the IP of a landing page is returned and thus your host is unable to talk with the infected site.

These are just a few examples of what you can do with ntopng to secure your network and monitor security infections. If interested we have written a tutorial that describes all this more in detail.