Direction issues

[Carter Bullard]

Hey John,
Without seeing your command line, keep the rasqlinsert options the same,
but change from “-S host” to “-r - “ to read from stdin.
Then have ra connect to the how and pipe its output to rasqlinsert.

   ra -S 127.0.0.1 -w - | rasqlinsert -r - options.you.were.using.except.-S


Carter

> On Dec 9, 2014, at 2:43 PM, John T. Myers <myersj0 at gmail.com> wrote:
> 
> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 

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