iptrk is a networking monitoring program that will monitor, track, record a set of networks, and alerts an operator whenever abnormal events happen. I developed iptrk for a company I used to work for called Arafura Connect, which was liquidated in April 2003. Arafura Connect was an ISP offering dialup and wireless Internet services. iptrk has been tailor made for the then Arafura Connect to track traffic volumes for billing, detect hackers and viruses, and alert of equipment failure. Just before Arafura Connect was liquidated, iptrk was turned into a GPL project [1].
Here are some of it's features-
**Alerting**
**Reporting**
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 kernel). Following are screen shots of
the "userspace side" of iptrk--
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 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).
.. and this is an "Address Domain" graph. The
203.39.3.140 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.
.. and this is a "Time Domain" graph for 203.39.3.140.
There's a
number of ways iptrk can be configured. It's fairly important to know the
advanges 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.
The 203.39.3.128 and 203.48.12.0 networks it was
monitoring were physical networks, and the main "sabres" router did no
translations. This is the scenerio iptrk was designed for-- to sit in the
corner and eaves-drop. With no segmentation, iptrk gives a perfect account
of your network. With segmentation... things are less accurate, depending
on what's being segmented (this is where you have to be careful when
using switches). This model has a disadvantage-- Packet mangling makes monitoring very
confusing. iptrk hooks packets at a low part of the network stack where
all packets can be seen, but are untranslated (There's nothing I can do
about this without serious kernel modification). There are two
workarounds if accurate volume tracking and intrusion detection are
essential-
Have two seperate iptrk
machines. One monitoring the internal network, and the other
monitoring the external network. The internal iptrk machine will track
traffic volumes, and the external iptrk machine monitors intrusions (a
much more elegant solution !).Monitoring Strategies
Iptrk was developed (and is designed for) linux 2.4. It has been written
in C, with a web and ncurses frontend. Some of the CGI frontend was
written in Perl by Peter Green (my ex-boss).
[1] Parts of Arafura Connect were
purchased by Territory
Technology Solutions after it liquidated. Territory Technology
Solutions uses the names Arafura Connect
and Arafura Internet Services for some
of it's products and services. Territory Technology Solutions hold no
rights to iptrk source code, or any other developments I did at Arafura
Connect, as they were all GPL'ed in Mid-March 2003-- before Arafura
Connect liquidated (In agreement with Peter Green, the Managing Director
of Arafura Connect).