Problems with racluster

[Carter Bullard]

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/20120829/b4f0aeda/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120829/b4f0aeda/attachment.bin>