Direction issues

Tue Dec 9 19:04:47 EST 2014

No, but this does…the problem is w/ the ‘-d’ flag. For some reason rasqlinsert will not become a daemon properly when piping in from ra. I tried using the ‘-d’ flag on both but that does not work.

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 -m none

> On Dec 9, 2014, at 6:10 PM, Carter Bullard <carter at qosient.com> wrote:
> 
> You may need to move your filter.  Does this work???
> 
> ra -S 127.0.0.1 -w - | rasqlinsert -r -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 - ip 
> 
> Carter
> 
>> On Dec 9, 2014, at 5:17 PM, John T. Myers <myersj0 at gmail.com <mailto:myersj0 at gmail.com>> wrote:
>> 
>> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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/903ce6be/attachment.html>