Re: argus-*-rc.30 on the server

Re: argus-*-rc.30 on the server

On Mon, Oct 02, 2006 at 12:30:42PM -0400, Carter Bullard wrote:
> Hey Peter,
> Hmmmm, OK, so argus-3.0 is currently reporting the libpcap reported  
> on-the-wire
> bytes, and argus-2.x is reporting the corrected bytes, adjusted by  
> calculating
> the difference between the length reported in the ip header and the  
> remainder
> of the packet length after parsing the encapsulation header.
> 
> So which is right?  Its clear that libpcap reports larger packets  
> than are
> actually written by the sender.  If I pick out one of your tcp  
> connections,
> say the one with source port 40669, the last packet in your trace is an
> IPv4 based TCP ACK packet over ethernet, yet libpcap sez that the on-
> the-wire packet length is 60 bytes.  That packet should be 54 bytes, 14
> ethernet hdr + 20 IP header + 20 TCP header.
> 
> I think this is a known problem with libpcap, so ...., I took out the
> 'correction' code in argus-3.0 thinking that we should not be sensitive
> to packet contents for stating what the packet length is (since this can
> be faked).   Although libpcap is incorrect, should we stay with it or  
> should
> we correct the length?
> 
> Opinions?
> 
> Carter
> 

	Ah! our friend ethernet padding! I think for most things the libpcap value is probably better. Whats
happening is there 
is a minimum packet size of 60 bytes on the wire and the ethernet cards will pad an underlength packet out to 60
bytes. For
rate calculations this is the count we would like to use, because it is actual bytes on the wire and indicates
how long the
packet really was on the wire for utilization purposes so I'd vote for leaving the value at the libpcap
value. 

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

Re: argus-*-rc.30 on the server

Re: argus-*-rc.30 on the server

On Mon, Oct 02, 2006 at 01:14:55PM -0400, Carter Bullard wrote:
> Then we're good to go.  I've fixed the OpenBSD define.  Anything else?
> Carter
> 

	Note that I know of. I'll see about rounding the 2.0.6 counts less than 60 bytes up to 60 bytes and see if they
then 
match the 3.0 counts and try it on all the systems I have. I now have a dual CPU dual core G5 machine running Mac
OS 10.4 as 
well and it will be interesting to see who is faster my IBM Power5 or the Mac  (I expect the Power5 but we will
see ). 

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

Connection Bytes

Re: Connection Bytes

On Wed, Oct 04, 2006 at 01:58:29PM +0800, CS Lee wrote:
> Hi all,
> 
> Normally when we perform analysis using argus, we will have entry like this
> 
> 17:19:46.623049 6 222.64.79.60.3493 -> 1.2.3.4.80 4 3 *536 780* CON
> 17:19:53.598808 6 222.64.79.60.3493 -> 1.2.3.4.80 2 1 *420 668* CON
> 
> The bold numbers are the sbytes and dbytes, which is actually includes the
> header and i consider it as frame bytes, is it possible to only show the
> payload(application bytes) instead of the whole frame bytes?
> 
> By the way, I vote for libpcap base too :)
> 
> Cheers
> 
> 
> 
> 
> 
> -- 
> Best Regards,
> 
> CS Lee<geekooL[at]gmail.com>

	 Yep, if you add -s +sappbytes +dappbytes to the ra command you will get the payload only counts (in a quick
look I didn't
see this in the ra man page though it may be there and I'm blind ). Adding -s -sbytes -s -dbytes will supress
the payload
counts. Comparing the application and payload count ratios is a good way to find hosts with high error rate
connections (a good
connection will be %5 or %10 different, I've seen ones with %50 difference because of something screwball
in the machine's
stack, and that leaps out at you). 

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

Re: Argus-info Digest, Vol 14, Issue 3

ra.1 patch against clients.rc.30

	Since its trivial, here is a patch against the clients.rc.30 ra.1 man page to add appbytes (since I thought
to check the
latest man page since I'm behind the times ): 

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

*** man/man1/ra.1.orig	Wed Oct  4 10:48:06 2006
--- man/man1/ra.1	Wed Oct  4 10:53:38 2006
***************
*** 115,122 ****
     mindur, maxdur, saddr, daddr, proto, sport, dport, 
     stos, dtos, sdsb, ddsb, sttl, dttl, sipid, dipid,
     smpls, dmpls, stos, dtos, sttl, dttl, [s|d]pkts,
!    [s|d]bytes, [s|d]load, [s|d]loss, [s|d]ploss, [s|d]rate, 
!    ind, smac, dmac, dir, [s|d]intpkt, [s|d]jit, status,
     suser, duser, swin, dwin, trans, svlan, dvlan, svid, dvid,
     svpri, dvpri, srng, drng, stcpb, dtcpb, tcprtt, inode

--- 115,122 ----
     mindur, maxdur, saddr, daddr, proto, sport, dport, 
     stos, dtos, sdsb, ddsb, sttl, dttl, sipid, dipid,
     smpls, dmpls, stos, dtos, sttl, dttl, [s|d]pkts,
!    [s|d]bytes, [s|d]appbytes, [s|d]load, [s|d]loss, [s|d]ploss, 
!    [s|d]rate, ind, smac, dmac, dir, [s|d]intpkt, [s|d]jit, status,
     suser, duser, swin, dwin, trans, svlan, dvlan, svid, dvid,
     svpri, dvpri, srng, drng, stcpb, dtcpb, tcprtt, inode

Ratemplate

Flow aggregation..

Hi,

long time listener (well user), first time caller.. :)

i've recently been looking at argus 3 to see what is going on and to
attempt to plan an upgrade path..

great work in general with argus.. much kudos to all concerned.. and
awfully good to see ipv6 support arrive :) i can now use argus at home
:)

i have one main concern with argus 3 however.. the distinct lack of
ragator(1).. in its place there seems to be racluster(1) which seems to
be less flexible in some ways than ragator(1).... ragator aggregating
until it hit 2^32 and spitting multiple entries so you then had to
aggregate the aggregate was a bit annoying but you will always hit some
ceiling where this will have to be done anyway i guess.. :/

i would use ragator, the friendly dragon, to aggregate flows based on
subnets of a larger address space by applying a netmask to the addresses
in the ragator flow config file.. this functionality seems to be missing
from (the more boringly named ;)) racluster.. some very rough / simple
examples..

flow 100 ip  192.168.0.0/16	0.0.0.0/0		*	*
*	200	x y
flow 101 ip	 0.0.0.0/0		192.168.0.0/16	*	*
*	201	x y

model 200 ip 255.255.255.0	0.0.0.0		yes	no	yes
model 201 ip 0.0.0.0		255.255.255.0	yes	no	yes

would match all flows on the local /16 network but aggregate them into
their sub /24 ranges..  for locally and remotely originated
connections.. which is useful when suballocating a larger address space
to subordinate networks that need to be accounted for individually in a
simple auto generatable ragator flow config :)

from what i can tell with racluster(1) this would have to be 256
flow/model lines or am i missing something obvious as there seems to be
no way to apply a mask to the match?

another useful thing i have attempted to match in the past (i suspect
this failed due to a bug / assumption made in the application of the
mask in 2.x tho i never really followed it up as wasn't that concerned
at the time) was using a noncontiguous netmask.. for example in the case
here say a set of dns servers on distinct network legs through an
infrastructure say each leg has a /24 (for simplicity) all dns servers
exist on .53 of each leg... you want to aggregate all connections
inbound and outbound based on protocol and service (dport) across all
dns servers.. bung a noncontiguous netmask in to match the servers
across all networks.. ie a 255.255.0.255 netmask in this case..

ala:

flow 100 ip 192.168.0.53	0.0.0.0/0		*	*
*	200	x y
flow 101 ip 0.0.0.0		192.168.0.53	*	*	*
200	x y

model 200 ip 255.255.0.255	0.0.0.0		yes	no	yes
model 201 ip 0.0.0.0		255.255.0.255	yes	no	yes

you would probably want to handle different services etc and possibly
explicitly separate 53 out with a 'no' on the protocol match in the
corresponding model to aggregate all (udp/tcp) dns traffic into one
aggregate etc etc.... for brevity and the purpose of the example.. will
just aggregate on 'dns servers' and proto/service triplet..

ragator (the friendly dragon) was an awfully useful/powerful tool once
you grok it's nuances ;)

it would be of great use in this environment to be able to easily auto
generate flow/model ragator configs to easily create protocol breakdowns
of traffic flows based on subnets of a larger range.. ie to be able to
pull assigned subordinate network ranges aggregate on those networks and
do so splitting on port or proto/port to be able to automate the process
of providing totals aswell as proto breakdown aggregates for the purpose
of accounting the traffic..

further usefulness here comes from having a real network instead of a
cidr as occasionally in the case of applying masks for the purposes of
aggregation (and for other bizaar circumstances) to be able to apply non
contiguous masks to easily achieve these sorts of outcomes for
example...

i see that the introduction of ipv6 would have seriously hindered
ragator and suspect that is why the newer (and more simplistic) matching
of racluster(1) was introduced.. which is fair enough..

real netmasks on ipv6 (rarely ever seen over prefix length style) would
also apply very usefully but would be a bugger to process as dealing
with the 128 bit values and masking would get a little tedious but would
be an awfully nice feature..

of course the above example with the dns servers split over multiple
legs should probably have a layer 4 switch on at least the public side
of it and if the argus probe was in front of that then a lot of the
problem would be alleviated as you would only ever see the one address
anyway.. but then internally if you wanted to track the data inside the
infrastructure you want visibility of the individual servers also and if
you sat it inside the layer 4 and could aggregate as above you could
have the best of both worlds...

to this end it saddens me to see the untimely death of ragator, the
friendly dragon :(