raservices crashes when processing

Carter Bullard carter at qosient.com
Thu May 16 11:13:35 EDT 2013


Hey Dave,
Of course, everything in the clients has a constant defined somewhere.
Change the value of ARGUSMAXSIGFILE in ./include/argus_client.h to
something like this:

==== //depot/argus/clients/include/argus_client.h#64 - /Volumes/Users/carter/argus/clients/include/argus_client.h ====
142c142
< #define ARGUSMAXSIGFILE		2048
---
> #define ARGUSMAXSIGFILE		0x80000


Carter

On May 16, 2013, at 8:51 AM, "Dave Edelman" <dedelman at iname.com> wrote:

> The std.sig is fine but it is 435 lines long.
> If I use rauserdata to create a filter file which is longer than 2048 lines (including empty lines) raservices segfaults. If I take the first middle or last 2048 lines of my filter file, raservices is fine. If I remove all of the blank lines from my filter file I can still use any 2048 lines with no problem but raservices segfaults on 2049 lines in the filter file.
>  
> --Dave
>  
> From: Carter Bullard [mailto:carter at qosient.com] 
> Sent: Thursday, May 16, 2013 8:37 AM
> To: Dave Edelman
> Cc: Matt Brown; <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] raservices crashes when processing
>  
> Hey Dave,
> Not sure that I follow your situation.  So you're having problems with the provided sig.std or one you created?
>  
> Carter
> 
> On May 15, 2013, at 8:59 PM, "Dave Edelman" <dedelman at iname.com> wrote:
> 
> I had the same results so I looked at an example in the argus-client distribution. /support/Config/std.sig has this header:
>  
> #  Services fingerprint file, generated by:
> #      rauserdata -d16 -e encode32
> #
> #  with modifications.
> #
>  
> The –e option is for regular expression pattern matching so I replaced it with  -M printer=’encode32’ and I didn’t use a –d parameter and the output looked much closer to the sample. I can now get raservices to core dump reliably with a segfault.
>  
> When I use the sample signature file and I tell raservices to output the label by using the –s +label:50 I do get a bunch of labels with the value srv=xxxxxx
>  
> My data is already the output of a day’s worth of flows run through racluster.
>  
> raservices -r argusTestData_2013_05_09  -f std.sig -s +label:50
>  
> 2013-05-09-01:28:18.230  *U          udp          10.1.1.50 61266     ->          10.1.1.10 disca*        1        0         148            0              INT
>             srv=ndmp
> 2013-05-09-16:10:32.206  *U          udp          10.1.1.50 61389     ->          10.1.1.10 disca*        1        0         148            0              INT
>             srv=ndmp
>  
> So I took the first 500 lines of my filter file and attempted to use that rather than the full file
> head -500 userdata.out > smallUesrData
> raservices -r argusTestData_2013_05_09  -f smallUesrData  -s +label:50  | head -30
>               StartTime      Flgs  Proto            SrcAddr  Sport   Dir            DstAddr  Dport  SrcPkts  DstPkts     SrcBytes    DstBytes            State
>                Label
> 2013-05-09-23:00:03.294              man                  0      0                        0      0        0        0            0            0              STA
> 2013-05-09-00:00:01.993  * d         tcp          10.1.1.45 50899    <?>          10.1.1.10 micro*  9075967 13492977   1560166894  15748525452              CON
>     srv=microsoft-ds
> 2013-05-09-00:00:28.890  * &         tcp          10.1.1.50 iad3     <?>          10.1.1.10 micro*  2034770 2870198    349463675   3595651910              CON
>     srv=microsoft-ds
>  
> Now for the  binary search J  my filter file has 4316 lines.  If I use the first 2048 I am fine, 2049 ends us with a segfault. I delete the first 100 lines of the original file and the first 2048 still works and 2049 still dies. This could be a clue.
>  
> --Dave
>  
>  
>  
>  
>  
>  
> From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On Behalf Of Matt Brown
> Sent: Wednesday, May 15, 2013 5:56 PM
> To: argus-info at lists.andrew.cmu.edu
> Subject: [ARGUS] raservices crashes when processing
>  
> Hello all,
>  
> I took a day's worth of argus data and, as suggested on http://thread.gmane.org/gmane.network.argus/6228/focus=6234, I analyzed it with rauserdata as follows:
>  
> #racluster -r * -w day.cache
> #rauserdata -r day.cache > /tmp/raservices.conf
>  
>  
> I then inspected /tmp/raservices.conf and it's messy (lots of single lines with arbirary ports, likely sport maybe rpc?), but I figured why not give raservices a shot:
>  
> #racluster -r * -w - | raservices -f raservices.conf
>  
> I receive the following error:
> raservices[21315]: 16:51:00.727719 RaCreateSrvEntry: format error Service: http
>  
>  
> I straced the process, and I see no occurances of "http" in the output (other than the writev()); the data appears to be read correctly until a blank line is read [read(3, "", 4096)                       = 0]:
>  
> read(3, "\"  \n\nService: 48956             "..., 4096) = 4096
> read(3, "...xxxxxx"  dst ="..., 4096) = 4096
> read(3, "xxxx"..., 4096) = 689
> read(3, "", 4096)                       = 0
> close(3)                                = 0
> munmap(0xb766e000, 4096)                = 0
> gettimeofday({1368651683, 272271}, NULL) = 0
> time(NULL)                              = 1368651683
> writev(2, [{"raservices[21523]: 17:01:23.2722"..., 79}, {"\n", 1}], 2raservices[21523]: 17:01:23.272271 RaCreateSrvEntry: format error Service: http
> ) = 80
>  
>  
> Any idea on why this would be?  Is my data processing flow incorrect?
>  
>  
> Both clients are 3.0.7.8.
>  
>  
> Thanks,
>  
> Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130516/6f5a1262/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/20130516/6f5a1262/attachment.bin>


More information about the argus mailing list