beta.13 (and beta.12) insect

[Neil Long]

Yep - my collectors are running 1.8.mumble and although they grew in size
the scripts (and Russell's watcher script's 'ra' ) suffered from the volume
of flows.

I split the analysis scripts across 2 machines while we had huge inbound and
outbound so that I could see the outbound ones and clobber them (and the
sub-net they resided in) until we can get the traffic back under control. It
is a 3-day weekend here so for breathing space the network admins dropped
all icmp in-out at the border - savage and stuff breaks but then IP is
remarkably resilient - won't be when people start back tomorrow :-)

many thanks Carter, Russell and Peter - Argus+ has done a really great job
here and now all we need is to get all those systems patched.... sigh...

cheers
Neil



> Ironically the 1.8.1 machine that is outside my gateway (and thus
> seeing the ping floods) survived fine (although my perl scripts didn't,
they
> run out of memory trying to process all the data :-)). This 2.0.6 server
is
> inside my net where it doesn't see that traffic. I expect the problem is
that
> I haven't boosted whatever Linux uses for the bpf equivielent buffer and
it
> is overflowing and causing massive packet loss and possibly indeed
overflowing
> the signed int with losses. I'll poke at it more (including adding a
kernel
> patch to boost the BFP equiv buffer size under Linux and see if that
helps).
> I may also put a FreeBSD box in place (where I already know how and how
much
> I can boost the BPF buffer) and see how it does. I've been meaning to
point
> tcpreplay at the linux box and see how it does at load but haven't gotten
to
> it yet :-).
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>
>
> On Mon, Aug 25, 2003 at 05:12:34PM +0100, Neil Long wrote:
> > Just a thought - are you having major icmp floods with these MS-RPC
worms?
> >
> > Until we filtered them my argus collector was dropping vast amounts of
> > packets as reported
> > by tcpdump and friends
> >
> > regards
> > Neil
> >
> > At 15:28 25/08/2003, Carter Bullard wrote:
> > >Hey Peter,
> > >   I'm printing out a %d, rather than a %u.  Its changed
> > >now, but the unsigned int version suggests you dropped a
> > >huge amount of packets.  I've gone over the code that generates
> > >the metric, and it hasn't changed, and it looks good.
> > >
> > >5 x a second, argus fetches the pcap_stats() and accumulates
> > >the values that it returns until a Man record is generated,
> > >but default that is every 300 seconds.  Argus is tallying the
> > >dropped packets on each monitored interface, as a long long, and
> > >then converts that to an unsigned int to package the value in
> > >the status man record.  The byte and packet counts are sent as
> > >long long's.  We're not checking if the drop value is larger
> > >than an unsigned int when we package it, so there is a
> > >potential gotcha, but the error here will be that we
> > >always underreport drops.
> > >
> > >But the code hasn't changed in at least a few years.
> > >
> > >Carter
> > >
> > >
> > >> -----Original Message-----
> > >> From: owner-argus-info at lists.andrew.cmu.edu
> > >> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> > >> Peter Van Epp
> > >> Sent: Monday, August 18, 2003 3:17 PM
> > >> To: argus-info at lists.andrew.cmu.edu
> > >> Subject: beta.13 (and beta.12) insect
> > >>
> > >>
> > >>       Argus-2.0.beta13 (and 12) on RedHat 9.0 looks to have a
> > >> drop problem:
> > >>
> > >> [vanepp at sniffer data]$ ra -r argus.out -n -- man
> > >> 18 Aug 03 12:12:11    man version=2.0     probeid=3848370891
> > >>               STA
> > >> 18 Aug 03 12:57:11    man  pkts   2199227  bytes    913750320
> > >>  drops -124767  CON
> > >> 18 Aug 03 13:02:11    man  pkts   2779115  bytes    922022496
> > >>  drops 172160  CON
> > >>
> > >>       There shouldn't be a negative number of drops (unless
> > >> argus has been
> > >> creating packets of course :-)). Haven't checked the BSDs for
> > >> this one yet.
> > >>
> > >> Peter Van Epp / Operations and Technical Support
> > >>
> >
>