Argus flow direction

tbh tbh1000 at gmail.com
Tue May 9 19:20:58 EDT 2017


RHEL 6, argus-clients 3.0.8.2

So if I run it on the test file (which should contain the flows for this
connection), the -M correct switch works.

racluster -M correct -r
test.gz

         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   16:04:56.830048  M g         tcp            2.3.4.5.64453
->           1.2.3.32.7610         12       1919   RST

 ra -r test.gz
         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   16:04:56.830048  M           tcp            2.3.4.5.64453
->           1.2.3.32.7610          6       1559   CON
   16:18:56.837799  M           tcp            2.3.4.5.64453
<?>           1.2.3.32.7610          2        120   CON
   16:26:39.835133  M           tcp           1.2.3.32.7610
<?>            2.3.4.5.64453         2        120   FIN
   16:31:07.078977  M           tcp            2.3.4.5.64453
<?>           1.2.3.32.7610          2        120   RST

However, if I run it against the all of files for 3/7, it does not seem to
correct the flow.

racluster -M correct -m saddr sport daddr dport dir -r
argus-eth0.20170307*.gz  - ipv4 and proto 6 and  net 1.2.3.32/32 and port
64453
         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   16:26:39.835133  M           tcp           1.2.3.32.7610
<?>            2.3.4.5.64453         2        120   FIN
   16:04:56.830048  M g         tcp            2.3.4.5.64453
->           1.2.3.32.7610         10       1799   RST

 ra -r argus-eth0.20170307*.gz -w - - ipv4 and proto 6 and net 1.2.3.32/32
and port 64453
         StartTime      Flgs  Proto            SrcAddr  Sport
Dir            DstAddr  Dport  TotPkts   TotBytes State
   16:04:56.830048  M           tcp            2.3.4.5.64453
->           1.2.3.32.7610          6       1559   CON
   16:18:56.837799  M           tcp            2.3.4.5.64453
<?>           1.2.3.32.7610          2        120   CON
   16:26:39.835133  M           tcp           1.2.3.32.7610
<?>            2.3.4.5.64453         2        120   FIN
   16:31:07.078977  M           tcp            2.3.4.5.64453
<?>           1.2.3.32.7610          2        120   RST


Thanks!

tbh

On Tue, May 9, 2017 at 4:58 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Tbh,
> Just for sanity sake, I ran this on my Mac OS X Sierra, and got this
> output using Ra Version 3.0.8.3,
>
> apophis:clients carter$ ../bin/racluster -Xr ~/Desktop/test
>         StartTime      Flgs  Proto            SrcAddr  Sport   Dir
>     DstAddr  Dport  TotPkts   TotBytes State
>   17:26:39.835133  M           tcp           1.2.3.32.7610     <?>
>     2.3.4.5.64453         2        120   FIN
>   17:04:56.830048  M g         tcp            2.3.4.5.64453     ->
>    1.2.3.32.7610         10       1799   RST
>
> apophis:clients carter$ ../bin/racluster -Xr ~/Desktop/test -M correct
>         StartTime      Flgs  Proto            SrcAddr  Sport   Dir
>     DstAddr  Dport  TotPkts   TotBytes State
>   17:04:56.830048  M g         tcp            2.3.4.5.64453     ->
>    1.2.3.32.7610         12       1919   RST
>
> So when I used the correct option, I got correct results.  Did you not get
> this ???  What version of racluster, and what platform ???
> Carter
>
>
> > On May 9, 2017, at 5:00 PM, tbh <tbh1000 at gmail.com> wrote:
> >
> > Carter,
> >
> > The "-M correct" option didn't fix it. The srcid for both is 0.0.0.0.
> Perhaps duplicate packets?
> >
> > Attached is a file with the data for this traffic. I appreciate you
> taking the time to take a look!
> >
> > tbh
> >
> > On Tue, May 9, 2017 at 2:52 PM, Carter Bullard <carter at qosient.com>
> wrote:
> > Hey Tbh,
> > racluster.1 does have the ability to ‘correct’ flow records for the
> direction, and I think that should be the default behavior.  Its possible
> that the default is being changed (.rarc ??).  Try racluster with the “-M
> correct” option to see if you can force correction.
> >
> > There are exceptions for correction, especially when you are processing
> flow records from different sources.  Do both of these flow records have
> the same ‘srcid’ ??
> > Try “-M correct”, if that doesn’t work, generate a data file with these
> two records in them, and I’ll take a look …
> >
> > Hope all is most excellent,
> > Carter
> >
> >> On May 9, 2017, at 1:29 PM, tbh <tbh1000 at gmail.com> wrote:
> >>
> >> Greetings to the list...
> >>
> >> I'm trying to understand why I'm seeing a second flow with an ambiguous
> direction for this traffic. Given the saddr, sport, daddr, dport, proto are
> all the same and the start/last times fit within the first line, I would
> have thought it would have been considered part of that connection.
> >>
> >> racluster -m saddr sport daddr dport -r argus-eth0.20170307*.gz -s
> stime ltime proto saddr sport dir daddr dport pkts bytes dur - ipv4 and
> proto 6 and  net 1.2.3.0/24
> >>
> >>               StartTime                 LastTime                 Proto
>   SrcAddr  Sport   Dir        DstAddr  Dport  TotPkts   TotBytes     Dur
> >> 17-03-07 16:04:56.830048 17-03-07 16:31:07.160901      6
>  2.3.4.5.64453     ->         1.2.3.32.7610         10       1799
> 1570.3308*
> >> 17-03-07 16:26:39.835133 17-03-07 16:26:39.835244      6
>  1.2.3.32.7610     <?>       2.3.4.5.64453         2        120     0.000111
> >>
> >> Any insight would be appreciated!
> >>
> >> Thanks!
> >>
> >> tbh
> >
> >
> > <test.gz>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20170509/519a1c3c/attachment.html>


More information about the argus mailing list