[H-GEN] IP Traffic Monitoring

[Russell Stuart]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Wed, 2003-09-10 at 14:08, Tony Nugent wrote:
> > The General Interface Statistics screen of iptraf says that approx 50%
> 
> (iptraf?  you really trust what iptraf says?  It may be prudent to
> confirm its conclusions before going off on a wild goose-chase :)

No, not really.  That is why I asked later on if there was a way of
confirming this later on.  Are there, for example, counters kept by the
kernel that log tcp retries, bad checksums, and so on?  If so how do you
print them out?

> > layer 3/4 errors.  Is there some other way to confirm there are IP
> > checksum errors?
> oh, you have :)  ok, these packets must be getting rejected/dropped
> at the kernel level[2] - but perhaps you are not looking at the
> right things?  For example, icmp or arp (or other) packets being
> might be useful as symptoms to diagnose the problem (indeed, an
> over-generation of such traffic may *be* the problem).

Its a bit hard to miss icmp and arp requests as tcpdump prints them
out.  Actually almost all of out legitimate traffic is ssh.  So this
command:

  tcpdump -nl -i ippp0 not port 22

should log just the garbage.  In actual fact the BadIp packet counts go
up in iptraf, and this tcpdump command prints nothing.  This leaves
three possibilities:

(a) The packets with bad checksums are ssh packets.
(b) The packets do not really have bad checksums.
(c) The packets with bad checksums are dropped by the kernel before
    they get to tcpdump's packet filter.

I don't believe it is (a).  There are no "hangs" on the ssh sessions
indicative of TCP retries, and ping never drops packets.  (b) is a
possibility, but I have never seen iptraf do that before.  This leaves
(c).

> Also, you should be able to gather "real" (crude raw) statistics
> from the relevant /proc/ files (eg "watch cat /proc/net/dev" and
> other similar spells).  You might also need to look at doing some
> tweaking to the kernel settings in /proc/sys/net/ipv4/*[2].

There was nothing obvious under /proc.

> Finally, who is your idsn provider?  Do they have technical staff
> who can help, or web management pages that allow you to check on
> things like your network statistics?  (Telstra does, on both
> counts... once you finally reach them, I have generally found their
> tech guys very helpful).

Telstra is our provider, and I did contact them.  They were fairly
certain were were being DOS'ed by one or more Windows worms.  They were
able to fix most of the problem by blocking the packets upstream.  That
means I don't really have an urgent problem any more.  But according to
iptraf, roughly 50% of all incoming packets _still_ have bad checksums. 
I am still curious about where they are coming from.  My current theory
is that they are bad packets generated by the worms using a raw socket.

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/