[unisog] Cisco netflow and argus (was registering servers)

Peter Van Epp vanepp at sfu.ca
Mon Jul 31 15:20:13 GMT 2006

On Mon, Jul 31, 2006 at 07:42:43AM -0400, H. Morrow Long wrote:
> On Jul 30, 2006, at 9:38 PM, Rudolph Pereira wrote:
> > .... For the record we're using nfsen/nfdump
> > with reasonable success, but I have no way to tell whether the flow
> > information coming from the routers is correct or complete (even to  
> > 90%
> > probability).  ...
> The % of netflow traffiic being dropped can be calculated
> by measuring the gaps in the sequence #s of the netflow records:
> This slide is from a talk by Eoghan Casey in 2003 at the SecureIT conf
> ( http://www.secureitconf.com/OLD/2003/docs/Eoghan_Casey.ppt )
>    "Forensic Computer Analysis" :
> Netflow Losses
>      * Sequence numbers show gaps
> % flow-header < ft-v05.2002-04-15.183000-0400
> # mode:                 normal
> # capture hostname:     flow
> # exporter IP address:
> # capture start:        Mon Apr 15 18:30:00 2002
> # capture end:          Mon Apr 15 18:45:00 2002
> # capture period:       900 seconds
> # compress:             on
> # byte order:           big
> # stream version:       3
> # export version:       5
> # lost flows:           179520
> # corrupt packets:      0
> # sequencer resets:     1
> # capture flows:        206760
> "flow-header" is one of the OSU netflow tools.
> Cisco netflow records are transmitted to collectors via UDP
> which does not provide guaranteed delivery.
> Many factors can contribute to dropped records or packets
> in both Netflow and Argus.  Casey notes in the above PPT talk
> that NIC and other devices as well as libpcap can all have losses.
> It would seem to me that in such an uncertain environment you
> would not use Argus nor Netflow records to definitely prove that
> someone did 'not' transmit particular traffic if there is no record
> of it (e.g. you cannot find it) but you could take it as a possible
> data point that they did if you find evidence of it -- taking into
> account internal spoofing.
> That is, the presence of data may be used to build a proof (and
> investigate further) but the absence of data does not necessarily
> 'prove' anything.
> -- H. Morrow Long
>     University Information Security Officer
>     Director - Information Security Officer
>     Yale University, ITS
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> http://lists.dshield.org/mailman/listinfo/unisog

	As well as this good advise, the traffic counters on your router 
interface are probaby a good bet as well. If the netflow/argus isn't showing
all the traffic your counters are then you are probably losing packets. 
Depending on your kernel there may also be interface counters which will 
indicate packet loss at the interface/OS buffer level. Libpcap will report 
overruns of the kernel/user space buffer (but the as noted the packets can
also be invisibly to pcap lost at a lower level already) this is the packet
loss indication in argus man reoords but as noted doesn't indicate all the 
possible loss sources.. 
	A test bed with your capture system a line speed sniffer, a switch with
known good traffic counters and something like tcpreplay to create known 
traffic at (if possible :-)) line rate so you know what will happen at high
loads are all good things to do to tune a capture system (and to discover its

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

More information about the unisog mailing list