directions and TransRefNum

[Mark Poepping]

Nagendra,

I'd be interested to hear what/where you're using argus for data.  I've been
helping some CS folks here with using argus data for some time, and we use
it for security forensics, but I'd like to get a better handle on the how
and where people use it, partly because I'm also 'connected' to the Abilene
(and NLR) folks and it might be possible to get argus a little more on their
radar (if others find it as incrementally useful as I do - vv netflow)..

Mark.


> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu [mailto:owner-argus-
> info at lists.andrew.cmu.edu] On Behalf Of nagendra modadugu
> Sent: Friday, June 10, 2005 5:26 PM
> To: Carter Bullard
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: Re: [ARGUS] directions and TransRefNum
> 
> 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?
> > >
> > >
> >