== A Linux promiscuous IPv4 packet tracker for networks (R17) ==
(Dec 2000 - Feb 2005)

iptrk is a networking monitoring program that will monitor a set of networks and alert an operator whenever something abnormal occurs. I developed iptrk while working at Arafura Connect. Arafura Connect was an ISP offering dialup and wireless Internet services. iptrk was tailor made for Arafura Connect to track traffic volumes for billing, detect hackers and viruses, and alert of equipment failure. Arafura Connect was liquidated in April 2003. Just before Arafura Connect was liquidated, iptrk was turned into a GPL project.

(Screenshots are from R14. Latest revision is R17)

Here are some of iptrk's features:



Screen Shots

iptrk isn't a packet sniffer. Unlike normal packet sniffers (which sample the kernels "hot lists"), iptrk tracks every single packet that hits the network interfaces. iptrk does this by queuing IP packet information into it's own queue (which is patched into the Linux V2.x.x kernel). Following are screen shots of the "userspace side" of iptrk:

This is iptrk running in streaming mode. It simply displays IP packet info as they hit the network interface(s). The immediate information you can see in the bottom part of the screen shots is updated every second producing BPS (bytes per second) amounts. These are further broken down into in/out/internal/martian volumes, and what type of services they are.

This screen produces a sorted list of IP numbers in our networks (networks that belong to us). The above screen shot for example shows you a list of the highest receivers of traffic (there is also a highest senders screen). The volumes in these lists are broken down further into Total, UDP, TCP and OTHER. These two screens are invaluable for us, because when we get a phone call from a customer informing us why something is slow or not working, we can instantly see at a glance what machines are being hit the most (and who is doing it).

This screen (and following) is the web interface. It provides attack detection, and information to do billing.

This screen (and following) is the graphing facility. They will produce address domain histograms. When iptrk emails you telling you somebody is hammering the network, or that your network is getting DoSA'ed, then you can jump in here and see at a glance who is the culprit (this is iptrk's most powerful and most used facility).

This is an "Address Domain" graph. The address was one of our Web Cache servers at Arafura Connect. The RED bit of the bar tells you the amount of traffic that has come in from the Internet (come in from outside our network(s)), The BLUE bit tells you the amount of traffic that has gone out to the Internet, The GREY bit tells you the amount of traffic this machine has received from internal machines (within our network), and the GREEN bit tells you the amount of traffic that this machine has sent to internal machines (within our network).

Nb/ Data is broken up in this fashion because the Arafura Connect networks were segmented. Internal traffic tally's were often meaningless, but also relevant. Also, Arafura Connect used to charge different rates for Internal and External traffic. Here is the "time domain" graphing facility--

Here we set the address and time range.

This is a "Time Domain" graph for

Monitoring Strategies

There's a number of ways iptrk can be configured. It's fairly important to know the advantages and limitations. There's only three possible ways (I can think of) of configuring iptrk on a network-- Internal monitoring, Untranslated Gateway Monitoring, and Translated Gateway Monitoring.

Iptrk supports both the 2.4.x and 2.6.x kernels. It has been written in C, with a web and ncurses frontend. Some of the CGI frontend was written in Perl by Peter Green (Arafura Connect's ex-Director/Manager).