directions and TransRefNum

nagendra modadugu nagendra at cs.stanford.edu
Fri Jun 10 17:26:12 EDT 2005


Hi Carter,

Thanks for the clarification, that does clear things up a bit.
Is the 120 second timer programmed into argus or can it be easily
configured?  

Just to make sure, a TCP connection that runs for,
say, 1hr without idling for more than 120s at any time will generate 
records that all have the same TransRefNum?  

What is the upper limit on the number of active TransRefNum's at 
any given time?

So if TransRefNum's are generated every time a TCP connection idles
over 120s, are the corresponding records aggregated based on 
(saddr,daddr, sport, dport) tuple?  Is there any further information
that argus has at it's disposal for aggregating records?

Do TransRefNum's/aggregation work the same for UDP?

Sorry about bombarding you with questions, but we're trying to make
sure we understand argus well enough that we can quantify the situations
under which our data may be inconsistent.  Thanks,

nagendra

* Carter Bullard <carter at qosient.com> [2005-06-10 14:52:07 -0400]:

> Hey Nagendra,
>    Yes your right, argus did flush its cache of the ssh connection,
> because the flow was idle longer than the default TCP idle timer
> (120 seconds).  The "sS" flags are what help ra* programs "know"
> that the direction of the tcp flow is reliable, and so we report
> this state in every flow record that is generated, so a reader can
> process accordingly.
> 
>    When argus flushes its cache, well, it doesn't have any state
> any longer on the flow, so when a packet comes in, it has to start
> tracking the flow without any state, so argus reports the flow
> as "ambiguous", since it doesn't "know" that the tcp was setup
> earlier.
> 
>    If you were to run ragator() using this input, it would merge
> your records into a single argus record with the directions correct.
> 
> Carter
> 
> 
> 
> > From: nagendra modadugu <nagendra at cs.stanford.edu>
> > Date: Thu, 9 Jun 2005 10:10:41 -0700
> > To: <argus-info at lists.andrew.cmu.edu>
> > Subject: [ARGUS] directions and TransRefNum
> > 
> > (Sorry about multiple postings to the newsgroup--my mail
> > settings were a bit messed up).
> > 
> > I'm looking at the following argus traffic from this morning,
> > and can't make sense of flags and direction, hope someone
> > can help:
> > 
> > $ rasort -anzr -r ar-2005-06-09.09 -M saddr - src port 49353 and dst port 22
> > 09 Jun 05 08:03:48  d     tcp    X.X.X.X.49353  ->    Y.Y.Y.Y.ssh   146
> > 108       15170        18233  sSE
> > 09 Jun 05 08:06:02        tcp    X.X.X.X.49353  ->    Y.Y.Y.Y.ssh   24
> > 14        2104         2876   sSE
> > 09 Jun 05 08:19:19        tcp    X.X.X.X.49353  ?>    Y.Y.Y.Y.ssh   5        4
> > 410          1872   E
> > 09 Jun 05 08:40:04        tcp    X.X.X.X.49353  ?>    Y.Y.Y.Y.ssh   5        3
> > 410          1094   E
> > 09 Jun 05 08:41:09        tcp    X.X.X.X.49353  ?>    Y.Y.Y.Y.ssh   39
> > 25        3294         5290   E
> > 
> > (1) Why do the first two records both have 'sSE' flags set even
> >     though pertain to the same connection?  (8:03 is when this
> >     connection was started--there are no previous records for this
> >     connection.)
> > (2) For what reasons would the direction be ambiguous in remaining
> >     records?
> > (3) My understanding is that multiple records from one flow are
> >     linked together by 'TransRefNum' values.  How long are do argus
> >     keep this state around?  Perhaps a new TransRefNum was assigned
> >     to the record in line 3, which would explain it's ambiguous
> >     direction?
> > 
> > 
> 



More information about the argus mailing list