pcr and

[Carter Bullard]

Hey Frank,
The PCR requires that you have ARGUS_GENERATE_APPBYTE_METRIC set in argus.  The PCR is based on the values of sappbytes and dappbytes, so as a sanity check, print these fields using ra to see if the metric is being generated.

So not sure what you’re wanting to achieve in 2.  The 5-tuple aggregation is the default, as that is the “basic” way of forming flows.  Its always better if you include the command line that you are using, so we can see whats up.

But, why use such a large ARGUS_FLOW_STATUS_INTERVAL, I use either 5 or 1, and never go much higher.  This is the definition of your “quantum" of observation. With a 3 hour interval, man, do you have to wait a long time before anything comes out if your monitoring live traffic.  Biggest problem is that your going to see a lot of port reuse in 3 hours, so flows will collide, and you’ll get large flow duration times.  If you use default aggregation, then the mean, stddev, max and min are calculated using the ‘due’ field of each record.  So it looks like it is working.

Use a small ARGUS_FLOW_STATUS_INTERVAL, and then use aggregation to build up the long lived flows.

So, #3 is a ‘gotcha’ of sorts.  “tcp” and “udp” are really shortcut aliases, tcp means “ip proto tcp”, so you're generating filter errors by accident ???  Because tcp and udp and icmp are used so often, they are aliased, seems that all the other protocols (i.e udplite) need the ip proto.

So this works…
   
   ra -b - not udp
   ra -b - not \(ip proto 17\)

So quoting them makes them a string, rather than the keyword, and we then lookup them up, rather than assign the value.  Sorry for that inconvenience.  

Carter

> On Apr 20, 2018, at 6:39 AM, Frank <argus-mailinglist-1524134246 at f-block.org> wrote:
> 
> Hi,
> 
> i'm new to the list and to argus, so i hope i don't repeat already asked
> questions.
> First of all: i really like the workflow of argus and its functionality.
> But i encountered some obstacles that however might also be caused by my
> misunderstanding.
> 
> Argus server and client version: 3.0.8.2
> 
> 
> 1. Is it possible that the PCR functionality is broken? I always get a
> PCR of -0
> 
> ra -r argus.out -s sbytes dbytes pcr | head
> SrcBytes  DstBytes  PCRatio
> 83        126       -0.000000
> 1644    4213      -0.000000
> 83        126       -0.000000
> 194       0         -0.000000
> 194       0         -0.000000
> 73        89        -0.000000
> 73        101       -0.000000
> 74        60        -0.000000
> 3351      4025      -0.000000
> 
> 
> 2. Did i see right that it is not possible to aggregate on the argus
> sequence number, or did i overlook something? The main reason i'd
> want/need this is for an accurate mean duration time. The best i was
> able to accomplish was an aggregation (via racluster) over proto src/dst
> addr/port, but this does e.g. not work with ntp queries.
> I've set ARGUS_FLOW_STATUS_INTERVAL=1800 , and when i look for long
> connections and aggregate with '-m proto saddr sport daddr dport' , i
> get a maximum mean time of 1800, as each status message seems to be
> treated as a separate flow (at least it looks that way to me). When i
> also use -M norep, it works for all connections where the selected
> features are unique for the connection, but, as mentioned before, does
> not work with ntp connections, or for chatty hosts that use the same
> source port for a destination host twice or more.
> 
> 
> 3. Another issue that i encounter is a weird filtering behaviour.
> For example:
> 
> ra -r argus.out -- 'not (ip proto udp)'
> ra[26153]: 1524219408.776398 filter syntax error: 'not (ip proto udp)'
> 
> ra -r argus.out -- 'not (ip proto tcp)'
> ra[26219]: 12:19:04.157946 filter syntax error: 'not (ip proto tcp)'
> 
> ra -r argus.out -- 'not (ip proto udp or tcp)'
> ra[26233]: 12:19:31.355346 filter syntax error: 'not (ip proto udp or ...'
> 
> But this works:
> ra -r argus.out -- 'not (ip proto "udp")'
> ra -r argus.out -- 'not (ip proto 17 or tcp)'
> ra -r argus.out -- 'not (ip proto "udp" or tcp)'
> ra -r argus.out -- 'not udp and not tcp'
> 
> 
> Thanks in advance and regards,
> Frank
> 
> 
> 

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