Direction issues

Wed Dec 10 13:35:08 EST 2014

When you use the -d option, like all unix daemons, ra* will close stdin, stdout and stderr.
So, yep that won’t work.  Seems like of all the ra* programs, you’re interested in the one that
doesn’t use the complete set of client functions, so its doesn’t use the routine ArgusProcessDirection().
Let me look at seeing where you can add this function to rasqlinsert, so you won’t
have to do all this stuff.

Carter

> On Dec 9, 2014, at 7:04 PM, John T. Myers <myersj0 at gmail.com> wrote:
> 
> 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 <mailto: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/20141210/b82e0394/attachment.html>
-------------- 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/20141210/b82e0394/attachment.bin>