Direction issues

[John T. Myers]

This piping does not appear to work, here is my command line:

ra -S 127.0.0.1 -w - | rasqlinsert -r - ip -w mysql://username:password@192.168.1.1/db_name/table_name <mysql://username:password@192.168.1.1/db_name/table_name> -s autoid stime saddr daddr -s -record -d -m none

I get the rasqlinsert[PID]: Timestamp started message, however no data is inserted into the database. The schema is created, however.

If I run just: ra -S 127.0.0.1 -w - I can see all the binary output to the terminal.

John

> On Dec 9, 2014, at 2:48 PM, Carter Bullard <carter at qosient.com> wrote:
> 
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20141209/9f8d8e0d/attachment.html>