Direction issues

Tue Dec 9 18:10:36 EST 2014

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> 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/0db6a707/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/20141209/0db6a707/attachment.bin>