raports results after racluster or ra -w .. of original data files

[Carter Bullard]

Sounds like a bug.  Do you have a data file that I can check to see what's up?
Carter


On Jul 15, 2010, at 7:11 PM, Michael Sanderson wrote:

> On 07/15/10 02:43 PM, Carter Bullard wrote:
>> Hey Michael,
>> I assume that you are using argus-clients-3.0.3.x clients.
> 
> Yes, 3.0.3.15, not sure when this copy was downloaded.
> 
>> Argus doesn't make any determination regarding flow source or
>> destination, this is all done
>> in the clients.
> 
> Understood.
> 
>> If you read data using any of the ra* programs, they have an opportunity to
>> 'correct' a flow record for direction, and we do have some logic for TCP
>> traffic.
>> If we haven't seen the syn or the synack, we test the source and
>> destination ports to
>> see if the src is in the IPPORT_RESERVED range, 1-1024, and the dst port
>> is above it.
>> If so, if the sport is not ftp-data, and there is an entry in the
>> /etc/services file for the sport
>> value, so its an identified service port, we'll reverse the direction of
>> the record.
>> 
>> Does that seem useful, or do you see a problem?
> 
> Yes, this seems useful and was accurate in this case.  The problem is that I don't get the same output when I run raports on data written by 'ra -S ... -w file' and when I run raports on data that has been preprocessed via 'ra -r file -w newfile - host a.b.c.d' or 'racluster -M none -r file -w newfile'.  (See original post for the specifics of how things are run and actual output.)  It appears that it takes the act of writing the records out to a file to get the direction correction to completely take effect, otherwise the different raports runs would show the same results.  Is that accurate?
> 
>    Michael Sanderson
> 
>> Carter
>> 
>> 
>> On Jul 14, 2010, at 4:43 PM, Michael Sanderson wrote:
>> 
>>> I'm experiencing some slight differences in the results of raports,
>>> depending upon how I run it.
>>> 
>>> I rotate my logs every 15 minutes and do some post processing.
>>> 
>>> 1) raports -r data.2010.07.12-00:* - host 10.91.129.8
>>> ...
>>> 10.91.129.8 tcp: (2) 2049, 39813
>>> 10.91.129.8 udp: (3) 769, 789, 824
>>> ...
>>> 
>>> 2) ra -r data.2010.07.12-00:* -w d10.91.129.8 - host 10.91.129.8
>>> raports -r d10.91.129.8
>>> ...
>>> 10.91.129.8 tcp: (1) 2049
>>> 10.91.129.8 udp: (3) 769, 789, 824
>>> ...
>>> 
>>> 3) racluster -r data.2010.07.12-00:* -w clustered.2010.07.12-00
>>> raports -r clustered.2010.07.12-00 - host 10.91.129.8
>>> ...
>>> 10.91.129.8 tcp: (1) 2049
>>> 10.91.129.8 udp: (3) 769, 789, 824
>>> ...
>>> 
>>> raports on the original data files is suggesting that 10.91.129.8 port
>>> 39813 is a destination. raports on processed files is suggesting it is
>>> a source. Looking at the flows from the original data files for
>>> 10.91.129.8 port 39813 shows that direction wasn't determined.
>>> 
>>> 10/07/11 23:49:23 M tcp 10.91.129.8.39813 <?> a.b.c.d.netbio 2 126 CON
>>> 
>>> Looking at the processed files (d10.91.129.8 and
>>> clustered.2010.07.12-00) via ra, they also so that the direction was
>>> not determined.
>>> 
>>> What is happening with the processed files that convinces raports that
>>> 10.91.129.8 port 39813 is a source, not a destination? In this
>>> particular case it is right, but I'm curious how it is getting it right.
>>> 
>>> Michael Sanderson
>>> 
>> 
>> 
>> 
> 
> 

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



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