Couple things...

[David Edelman]

Craig,
 
I'll respond to the question about -M rmon option. When you specify this
option, you basically tell the argus client to operate on each of the
unidirectional half-flows rather than the bidirectional full flow. The
client effectively takes the flow and handles it twice with the original
source and destination addresses each being used as a source address and all
of the other adjustments that go along with making the output meaningful
(this is a great opportunity to use "mm" and let everyone Google it :) )
 
Carter provided an example that I use all of the time where I am keeping an
inventory of the IP and associated MAC addresses that I see on my network.
In this instance source and destination just gets in the way since I want to
use the IP or MAC address as an index without having to specify source or
destination  (and I have another rasqlinsert that does deal with the matrix
of source / destination as a pair.)
 
I have argus running on a capture machine and this is what I have running on
the machine that collects, labels, and stores the flow data from the
collector.
 
# ps ax | grep [a]rgus
28339 ?        Ssl    0:01 /usr/local/bin/radium -f
/usr/local/argus/SNKradium.conf -d
28372 ?        Ssl    0:00 /usr/local/bin/rastream -S localhost:9603 -f
/usr/local/argus/SNKstream.sh -M time 1h -B 15 -w
/data/argus/%Y/%m/%d/argus.%Y.%m.%d.%H -d
28378 ?        Ssl    0:00 /usr/local/bin/rasqlinsert -M time 1d -M cache -S
localhost:9603 -w mysql://argus@localhost/argus/macAddrs_%Y_%m_%d -m srcid
saddr smac -s stime ltime srcid saddr smac -M rmon -d - ipv4
28382 ?        Ssl    0:00 /usr/local/bin/rasqlinsert -M time 1d -M cache -S
localhost:9603 -w mysql://argus@localhost/argus/matrix_%Y_%m_%d -m srcid
matrix proto -s ltime dur srcid saddr daddr proto bytes -d
 
 
--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 Craig Merchant
Sent: Wednesday, September 18, 2013 3:34 PM
To: Argus (argus-info at lists.andrew.cmu.edu)
Subject: [ARGUS] Couple things...
 
Hey, Carter.
 
Just wanted to start off by saying the latest release has been awesome.
Everything has been super stable and all our label issues have been solved.
Thanks for all your hard work!
 
We've also been experimenting with the ABR and an anomaly detection tool for
Splunk from a company called Prelert.  I configured one of my servers to SSH
into a remote host and run a script that does a recursive ls and then sleeps
for a couple minutes.  I then periodically SCP'd 100 MB of files up to that
remote host.  With around 2.5 million events over a couple days for that
subnet, I got this:
 

 
Each one of those spikes when I drilled down represented one of the large
SCP uploads.  So, the signal-to-noise ratio for the ABR seems really good
(at least for my simplistic test example).
 
Couple questions for you.  
 
We're using rastream and racluster to aggregate our flows every five
minutes.  My understanding and from what I've seen in the data is that if a
flow lasts for 15 minutes, I'll only get a single record when the flow
closes.  Am I incorrect?  When I look at the aggregated argus records for
the test flow in the example above, where the SSH session stayed open for
days, I'm not seeing one event every five minutes.  So, if somebody asked me
"how much bandwidth are we using right now?", it would be tricky to divide
bytes by duration and project that backwards in time.
 
Is there any way to make racluster write a summary record for flows that are
longer than the aggregation interval that shows the summary statistics for
that flow only in that window?
 
Also.  I've seen you use "-M RMON" in several examples on the mailing list.
What is the value of using RMON stats for analysis?
 
Thanks.

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130918/c705b310/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 15943 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130918/c705b310/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6283 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130918/c705b310/attachment.bin>