Problems with racluster

[Rafael Barbosa]

Hi Carter,

I do not care much about the first record, as long as the second record
keeps its correct direction. As you said, the second record contains the
3-way handshake necessary to decide the flow direction.

I am not sure if this is important, but my original example is a little
more complicated: I have another pcap file with the rest of the TCP
connection from which the first packet (from the first record in f2.argus)
belongs. The packet that generates the first record f2.argus is a duplicate
for the ACK that completes the teardown of this TCP connection. To make
sure I am clear:

$> ra -r f1.argus
   21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        22       6772   FIN
$> ra -r f2.argus
   21:09:30.971095  e           tcp       172.31.1.100.10500     ?>
172.31.1.102.61722         1         66   CON
   21:11:52.493919  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        23       6838   FIN
$> racluster -r f1.argus f2.argus -f ~/config/racluster.conf
   21:09:30.970830  e *         tcp       172.31.1.102.61722     ->
172.31.1.100.10500        22       6772   FIN
   21:09:30.971095  e *         tcp       172.31.1.100.10500     ->
172.31.1.102.61722        24       6904   FIN

I just assumed the bug is in the second file. But if you think is necessary
I can provide you with the first argus dump as well.

Regarding my racluster.conf, I do not really care about real-time, as I am
using argus to post-process pcap files (I do not have access to the
network, just the dumps). But I have a question, why to you suggest to use
the 5-tuple as a "model" in racluster.conf? Isn't this the default behavior?

And as usual, thanks for the fast reply.

Best regards,
Rafael Barbosa
http://www.ewi.utwente.nl/~barbosarr/



On Wed, Aug 29, 2012 at 8:19 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Rafael,
> Yes, I'll have to fix this bug were the second record is erroneously
> reversed.  The fix, however,
> will end up reversing the first record.  The second record saw the connect
> setup, so it knows
> the correct direction.  The first flow, is just the one packet, without
> any detail, so the direction
> is unknown.  When you try to merge the two flows together, the bug is that
> it only looks at the first
> record for the direction, rather than evaluating both, and choosing the
> one that is a better choice.
>
> Is that cool with your line of thinking?
>
> If you're planning on running argus with 300s status intervals, that will
> eliminate any real-time
> possibilities. But if you're thinking about letting argus generate shorter
> lived status records, then
> run racluster() with a racluster.conf file,  where you set a status timer
> for all flows at 300s:
>
> filter=""   model="saddr daddr proto sport dport"   status=300 idle=300
>
> Hopefully this helps !!!!
>
> Carter
>
> On Aug 29, 2012, at 9:22 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:
>
> Hi all,
>
> I am having some problems with a weird aggregation decision by racluster,
> which inverts the server/client roles (i.e., the direction field). This
> what happens:
>
> $> argus -r f2 -w f2.argus
> $> ra -r f2.argus
>    21:09:30.971095  e           tcp       172.31.1.100.10500     ?>
> 172.31.1.102.61722         1         66   CON
>    21:11:52.493919  e *         tcp       172.31.1.102.61722     ->
> 172.31.1.100.10500        23       6838   FIN
> $> racluster -r f2.argus -f racluster.conf
>    21:09:30.971095  e *         tcp       172.31.1.100.10500     ->
> 172.31.1.102.61722        24       6904   FIN
> $> cat racluster.conf
> filter="" status=0 idle=300
>
> The pcap from which I generated f2.argus is attached to this message. The
> 'f2' pcap file is rather peculiar with duplicated frames and is a fragment
> of a larger capture where TCP ports are re-used in consecutive connections,
> but it is not a "toy" file, it was captured in a real network environment.
>
> My goal is to generate flow records with a 300s timeouts, and label hosts
> as servers and clients. Any thoughts on why this inversion happens, and how
> I can work around it?
>
> Thanks for the help,
> Rafael Barbosa
> http://www.ewi.utwente.nl/~barbosarr/
>
> <f2>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120830/c94c7422/attachment.html>