raservices crashes when processing

[Dave Edelman]

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/20130515/da516047/attachment.html>