argus 3 - direction determination algorithm

[Carter Bullard]

Hey John,
I've uploaded a new argus-clients-3.0.3.6.tar.gz to the developers site
that fixes your direction problem.  The clients make all the "override"
decisions on direction, and I added some more tests for the TCP syn/synAck
decisions.  I also added better weights for the destination port number when
there is no Syn or SynAck, and at least one of the ports is IPPORT_RESERVED,
< 1024.

Give this a run, and if you're having problems, holler!!!!

Carter

On Apr 6, 2010, at 4:40 PM, Carter Bullard wrote:

> Hey John,
> The reset is probably negating some other logic, so let me take a look, and
> check it out.
> 
> All the logic is already in the client library, so you don't have to do anything,
> at least that is the design ;o)
> 
> Carter
> 
> On Apr 6, 2010, at 4:11 PM, John Gerth wrote:
> 
>> On 4/6/2010 12:58 PM, Carter Bullard wrote:
>>> Hey John,
>>> In argus-3.0, we removed most of the direction logic out of argus, and moved
>>> it into the clients, just for this very situation.  argus-2.x would declare that the
>>> originator of a SYN_ACK packet was the destination, regardless of what was
>>> going on, and we put a lot of complex logic in the clients to try to deal with
>>> that when it was a A.SYN_ACK / B.RESET volley.
>>> 
>>> You should be getting that A is the source, now, and that B is the destination.
>>> If that is not correct, then, could you send some flow records that demonstrate
>>> the problem, so I can debug?  Better yet, if you had a packet capture, then
>>> I can debug the whole flow thread.  I'll look around for a packet trace, maybe
>>> on 
>>> 
>> Attached is an extract done with:
>>     ra -r ar-2010-04-06.12 -w ~/win/synack.argus - host 69.16.172.40 and port 6667
>> It shows that most of the S/A are src'ed remotely but whenever there's an R, ra
>> shows it the other way.  It's conceivable that this is our fault if somehow the
>> span ports are dumping things down incorrectly (I don't have bi-directional timing
>> turned on), but this seems oddly consistent.
>> 
>> I do not have a pcap as I found this out afterwards and we normally just record flows.
>> 
>> If clients are supposed to do the direction determination, I guess I should plan
>> on fixing mine up and will want to know what rules you normally use in your clients.
>> 
>> -- 
>> John Gerth      gerth at cs.stanford.edu  Gates 378   (650) 725-3273  fax 723-0033
>> <synack.argus.gz>
> 
> 
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100406/f5fd612f/attachment.bin>