Two questions

[Carter Bullard]

Hey Craig,
The address based approach for specifying direction is not a bad strategy, L2 is more reliable than L3 identifiers.
The problem with using L4 identifiers (port numbers) to make direction decisions, is that it you can get fooled really easy, and tricked even worse.

If we can't make a definitive statement as to the originator, the record we generate reflects the behavior on the wire, which has some truth to it, at least.

All programs like racluster (all the aggregators) know how to deal with status records that are uncertain, and correct the direction when it can.
Such as a persistent but idle TCP connection.   When you aggregate over the complete time of the connection, racluster() will get the direction correctly.

So, when there is ambiguity, the direction reflects the direction of the first packet seen, that is very important information.  Your analytic should be aware that the ' ? ' is an important indicator, and adjust for it.  If I provide port based direction overrides, I'll also have to indicate in the record that the direction was unknown, and it was changed from wire behavior.  We can do that, but it does start to get even more complicated.

To filter the flows with ' ? ', use  " tcp and (not syn or not synack)".

Carter


On Jan 31, 2013, at 9:25 PM, Craig Merchant <cmerchant at responsys.com> wrote:

> Thanks, Carter.  Looks like your example had an additional \ before the ).  This is what worked for me:
>  
> [root at ids-manager01-dc1 ~]# ralabel -S 192.168.1.40:561 -s +label:200 -f /usr/local/argus/ralabel.conf -w - | ra -r - -s +label:200 –M -label="(?\!whitelisted)"
>  
> We turned Argus on a couple days ago and setup a few security searches, such as looking for unusual outbound SSH traffic.  There were several instances of high port to high port connections where Argus was confused about the direction.  It would definitely simplify that kind of analysis if Argus could be told that a list of IPs, protocols, and ports should always be the destination of a flow.
>  
> Thanks for being responsive to the community!
>  
> Craig
>  
> From: Carter Bullard [mailto:carter at qosient.com] 
> Sent: Thursday, January 31, 2013 12:49 PM
> To: Craig Merchant
> Cc: Argus (argus-info at lists.andrew.cmu.edu)
> Subject: Re: [ARGUS] Two questions
>  
> Hey Craig,
> The bash shell is getting in the way, and is trying to convert your " !whitelisted " into a history
> command.  " ! " is a special character, so escape the ! using a backslash.  This should work:
>  
>    label="(?\!whitelisted\)"
>  
> We have in argus-clients-3.0.7.4, which is on the development server, the ability for you
> to suggest which should be the source and destination when it can't be determined from
> the traffic.  You specify local addresses, and then you can say you want the local on the
> left of right, when there is a " ? ".  Works pretty good, but its all address based, not service
> based.  We can add that if that is something you think would be useful.
>  
> Carter
>  
> On Jan 31, 2013, at 2:23 PM, Craig Merchant <cmerchant at responsys.com> wrote:
> 
> 
> Is it possible to do a negative regex match on flow labels?  I tried doing a negative lookahead –M label=”(?!whitelisted)”, but got an error:
>  
> -bash: !whitelisted: event not found
>  
> I can do a reverse match using egrep if I have to.  But negative label matching would be a nice feature. 
>  
> Second question…  When an ra* client connects to argusd or radium and sees a flow that was established before it connected, what is the logic that the client uses to guess the direction of the flow?  And is there any way to influence it or control it?  It would be great if Argus could use something like an iana label file or NMAP scan so that known open ports on a server would be given precedence as the destination.
>  
> Thanks Carter and the rest of the community for all the help!
>  
> Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130201/b71765c5/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/20130201/b71765c5/attachment.bin>