On a continually changing network, it is often difficult to spot issues because of the amount of noise generated by expected network traffic. Even when communications are seemingly quiet, a packet sniffer will display screeds of noisy data. That data might be otherwise unseen broadcast traffic being sent to all hosts willing to listen and respond on a local network.
Make no mistake, noise on a network link can cause all sorts of headaches, because it can be impossible to identify trends quickly, especially if a host or the network itself is under attack. Packet sniffers will clearly display more traffic for the busiest connections, which ultimately obscures the activities of less busy hosts.
You may have come across the excellent nearly real-time networking monitoring tool, iftop, in the past. It uses ncurses via a console to display a variety of highly useful bar graphs and even accommodates regular expressions. An alternative to iftop is a powerful console-based tool called nload. Such network monitoring tools can really save the day if you need to analyze traffic on your networks in a hurry.
Background
In the past when I’ve been tasked with maintaining critical hosts, I’ve left the likes of iftop and nload running in a console throughout my working day. Spotting real-time spikes is essential if you’re struggling for bandwidth capacity or if you suspect that a specific host might be attacked thanks to historical attempts.
Thankfully, with nearly real-time graphical interfaces — even displayed over a standard console — there’s little eyestrain involved either. During times of heightened stress, such as when a host was being attacked, I’ve used these tools in one window alongside other console windows. That way I can simultaneously show the continually changed output of network-sniffing tools in both a text and a graphical form. I find that by running different filters through each tool and changing them periodically as my field of focus evolves means that digging down into the data that is of most interest is much easier. Ultimately, I end up with a clear picture of who is using the network and, most importantly, for what purpose.
Installation
The nload packages can be found in a number of software repositories. On Debian derivatives, you can use this command to trigger your package manager’s installation process:
# apt-get install nload
On Red Hat derivatives, use this command:
# yum install nload
In the same way that iftop uses the “ncurses” package to output “graphics” to your console without the need of a GUI, the flexible nload switched to using ncurses, too, back in 2001. Your package manager should take care of any dependencies in this regard so there’s no extra package installation work involved.
Look And Feel
Once you have a working installation, all you need to do to run the package is use this command:
# nload
The results of such a command is the simple but useful output as shown in Figure 1.
The ability to split a single console window into two parts, one half for ingress (inbound) traffic and the other for egress (outbound) traffic is clearly of significant use. The clarity you immediately gain is invaluable, especially if you’re trying to diagnose an attack of some description. Also shown in Figure 1, at the top, are the adjustable options to alter your display on the fly, without stopping nload in its tracks.
If we only wanted to focus on one specific network interface, then we could run nload as follows:
# nload eth1
You can, however, add more than one network interface to the same console window for a useful comparison. In this case, we would use the following command:
# nload -m eth0 eth1
As you can see in Figure 2, this can give a useful insight into which of our network interfaces are under the highest load and without squinting at the output of a packet sniffing tool.
Now that we’ve got an idea of how malleable nload is, let’s look at some of the configurations options available.
Refresh Frequency
Years ago, I remember debating the effectiveness of making your traffic statistics update faster than the default setting. Tools that use Simple Network Monitoring Protocol (SNMP), such as RRDTool and MRTG (and indeed tools that use the “pcap” library, such as iftop), use averages to populate the display you are presented with. In short, a quicker refresh frequency may lower the accuracy of the output from such tools. If you are interested in the intricacies of such a statement, I encourage you to read more about such matters online.
I mention this for good reason. Before we continue, one caveat is that the “screen refresh” frequency is a different animal altogether to the “averages” used during the collection of statistics. When it comes to nload, however, the two are separated for clarity (unlike with other applications). The clever author keeps things simple, which is very welcome.
From what I can tell from the manual, the “-a” option is for changing the period used for measuring “averages,” which (I am guessing) affects the calculations behind the scenes. The refresh frequency, however, is for “screen display,” in terms of tweaking it to suit your display needs as we’ve just mentioned. Both ultimately relate to how the majority of real-time statistics are collected and then displayed between them. In case it causes confusion with nload, the screen refresh period is referred to as the “refresh interval.”
The manual goes to some length to explain that lowering the refresh interval to less than the default 500ms is not that wise. It states: “Specifying refresh intervals shorter than about 100 milliseconds makes traffic calculation very unprecise.”
This confirms my experience with other traffic collection software, too. The sophisticated nload goes on to reassure us with this additional comment: “nload tries to balance this out by doing extra time measurements, but this may not always succeed.”
I couldn’t confirm what its exact effect is on other settings, but within the Options Window (the box seen at the top of Figure 1), there is a “Smoothness of average” setting, which you may have some success in changing to affect your accuracy. Fear not, following some trial and error, you shouldn’t have too many problems now that you’re armed with the terminology and the difference between the two key adjustable parameters.
Battle Hardening
When I’m learning a new tool, I tend to run a few tests between machines and monitor how the tool reacts at both ends of a connection — to avoid a few headaches. Usually, I would send a small amount of data, stop and start the connection, and then try and saturate the network link (or at least put it under significant levels of stress) and repeat this a few times.
Coupling your new-found knowledge of how a tool will ultimately react to differing scenarios — having tuned the refresh frequency (and potentially the averages used for traffic calculations) to suit your needs — is the best way to battle-harden a tool in my experience.
In the next article, I’ll look at some specific examples of launching nload with various options.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Advance your career in system administration! Check out the Essentials of System Administration course from The Linux Foundation.
