High-resolution network monitoring with ping

Future

Measuring network latency with Ping shows that there is still some potential that has amazingly remained unused thus far. Attacks, such as sniffing mobile phone calls by means of intermediate IMSI catchers would thus be easily and unobtrusively detectable, practically free of charge, even if other tools such as traceroute cannot find them. Additionally, you can use pings to perform rough localization or determine cable length. To measure the dependence of RTT on the packet length, a distinction can be made between latency caused by cables or distances and that caused by devices, such as different switches.

In principle, attackers can also manipulate pings by copying and returning them with the desired latency or by filtering out the pong from the target machine to disguise themselves. This makes little sense, however, because copying, computing, and returning requires extra effort, and it is also virtually impossible to manipulate all potential ping types.

If you want to add protection against counterfeiting, you could ping with an encrypted timestamp. On the target machine, you would store the encrypted date and time in the foo.bar file, transmit these values with a ping, such as

time wget ftp://10.45.67.89/tmp/foo.bar

and check to see whether it has been encrypted with the correct key and contains the current time.

Electric Data

Electrical data would be desirable as well; the network admin can often use this to track down passive sniffing or more precisely locate wire breaks. Only a small number of network devices support this, and only a few cards with the Marvell chip can deliver electrical data with the use of special software like the Marvell Virtual Cable Tester; the output is not very detailed, but of the type good (link established), mismatch (impedance mismatch), or wire break in n metres (accurate to about 1 meter).

The 3Com Advanced Server Control Suite for network cards, such as the 3Com 3C996B, gives you more. With the frequency dependence of cable attenuation and return loss, you can demonstrate minor manipulations retroactively, such as swapping a cable for another of the same length, but with different properties.

Comment

Basing monitoring on ping times is without a doubt an original idea, and the idea will probably work – in the laboratory. In practice, though, a few obstacles seem to exist that certainly cannot be easily avoided. What are these?

The fluctuations in the ping round trip time for pinging servers with different load levels can be quite a bit larger than the run-time differences (e.g., which a rogue router would cause). This would lead to false positives – unless the trigger threshold value was set so high that you could not detect any anomalies.

The author suggests computing the average server load, but in a sense, this takes you from the frying pan to the fire: You then subtract another mean value (i.e., the daily mean load curve characteristic) from the artificially smoothed RTT (a kind of mean value). However, each mean value destroys information – in this case, because the variance is also squashed. This results in a highly idealized and far too narrow value corridor that does not accurately reflect the potential manifestations and, with its several decimal digits of timing values, pretends to have an accuracy that is not actually justified.

There is one more thing. The ICMP ping test utility not only reveals whether a network device at a specific address is reachable, but it also allows a kind of fingerprinting, which, for example, allows conclusions to be drawn about the operating system. It thus provides valuable information to potential attackers. Administrators who do not want to reveal this will tend to ban ICMP echo replies with a firewall rule, which would also rule out the kind of monitoring described in this article.

– Jens-Christoph Brendel, Medialinx AG editor

Author's Response

To calculate latencies caused by the CPU load, network load, and perhaps other sources, the subtraction must be done with current values. Therefore, for the 1,000s RTT value, the 1,000s value for additional latency must be used in the subtraction to calculate the net RTT value.

Of course, this is not perfect, but it's a good approximation and gives good accuracy. Pinger is a successful proof of concept and is just the start of high-resolution pinging by software only, without the need for special hardware.

Infos

  1. Linux iputils: http://www.skbuff.net/iputils/
  2. Arping: http://www.habets.pp.se/synscan/programs.php?prog=arping
  3. httping: http://www.vanheusden.com/httping
  4. ipmiping: http://www.gnu.org/software/freeipmi/
  5. Pinger and plotting script: https://sslsites.de/www.true-random.com/homepage/projects/pinger/
  6. MRTG: http://oss.oetiker.ch/mrtg/
  7. "Lokalisierung durch Messung von WLAN-Signallaufzeiten" [Localization by measuring the WiFi signal run times] by Mario Haustein. Linux-Tage 2011, http://chemnitzer.linux-tage.de/2011/vortraege/653 (in German)

The Author

Rolf Freitag is a physicist and computer scientist. He currently works for a small business in Neu-Ulm, Germany.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Security Lessons: Bufferbloat

    An abundance of buffers hides the Internet’s dirty little secret.

  • Programming Snapshot – Go Network Diagnostics

    Why is the WiFi not working? Instead of always typing the same steps to diagnose the problem, Mike Schilli writes a tool in Go that puts the wireless network through its paces and helps isolate the cause.

  • Zing

    Zing is a lightweight, zero-packet network utility similar to ping that provides ping functionality without the payload.

  • Command Line: Network Diagnostic Tools

    Linux has the right tools to track down network errors and open the way for data packets.

  • Charly's Column

    If you do not receive a response to a ping, or if the response is seriously delayed, you might like to take this as a warning. But who wants to ping all day? You need a ping-based monitoring utility like Smokeping.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News