Direction issues

[John T. Myers]

Yes, 3.0.8. 

It looks like an issue with rasqlinsert()

I ran a: ra -S 127.0.0.1 port 445 saddr sport daddr dport proto dir

The flows look like they correct themselves on the ra output, but are still being inserted into MySQL incorrectly, I can confirm this by comparing the ‘stime’ fields as they are the same.

So to correct this into rasqlinsert should I take all of the options I’m currently feeding into rasqlinsert, such as the “-s” fields and use them with ra instead? And then pipe that output into rasqlinsert?

> On Dec 9, 2014, at 2:25 PM, Carter Bullard <carter at qosient.com> wrote:
> 
> Hey John,
> All the ra* programs are based on the same libraries, so they
> all read streams and files the same, process the same etc …
> up to the point of their specific function.
> 
> Use ra, racluster, and tools like ratop, to see how the clients
> process the file that you’re having problems with.
> 
> You should be able to use ra to read the file with and without
> the .rarc file to see how the options are affecting the traffic.
> 
>   ra -r file.with.a.problem - host whatever and port 443
> 
> and see if the direction is corrected.  If it is, but other ra*
> program behave differently, it maybe that you need to pipe the
> flow records to get the desired corrections.
> 
>   ra -r file -w - | rasqlinsert ….
> 
> Which may be needed to get the correction propagated into the database.
> You’re using argus-clients-3.0.8 ????
> 
> Carter
> 
>> On Dec 9, 2014, at 2:16 PM, John T. Myers <myersj0 at gmail.com> wrote:
>> 
>> Carter,
>> 
>> I’ve created a .rarc file in the home directory of the user running rasqlinsert and this problem still persists. How can I confirm that the file is being parsed and being used by the ra* client?
>> 
>> Thanks,
>> John
>>> On Dec 8, 2014, at 7:02 PM, Carter Bullard <carter at qosient.com> wrote:
>>> 
>>> Hey John,
>>> This is the result of the flow going idle for longer than the flow idle time.
>>> Argus has discarded the flow cache, and when the first packet is observed,
>>> its not part of connection establishment (neither SYN nor SYNACK), so we
>>> don’t know what direction the flow was in.  The direction that is observed
>>> is based on the first packet seen.
>>> 
>>> For TCP traffic, the default is like 60 seconds, this can be configured in your
>>> argus.conf file.
>>> 
>>> The fix is to use the argus-3.0.8 clients feature to correct the direction of
>>> flows when there is this ambiguity.  To use the feature, set this variable in 
>>> your .rarc file.
>>> 
>>> RA_PORT_DIRECTION="services,wellknown”
>>> 
>>> The client will set the flows such that the 445 port (services) will
>>> be the destination port.  These rules only apply when the dir is “<?>”
>>> and should fix this specific issue.
>>> 
>>> Carter
>>> 
>>>> On Dec 8, 2014, at 4:42 PM, John T. Myers <myersj0 at gmail.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I’m having trouble with flows where direction is unable to be determined. In this sample session, http://pastebin.com/LK0xhgdP, the latter parts of the session have the <?> string as the direction. Aggregating these flows ends up in creating 2 separate sessions, when it was really one.
>>>> 
>>>> Is there a way to troubleshoot why the direction is unable to be determined? There is no NATing, etc on the network I was testing on.
>>>> 
>>>> Thanks!
>>>> John
>>>> 
>>>> 
>>> 
>> 
>> 
>