Making rasplit apply interface-name prefixes to output files when reading from a radium instance that is hosting multiple argus sources

Carter Bullard carter at qosient.com
Mon Jun 20 12:42:25 EDT 2011


Hey Kevin,
Second email in this thread.  We had thought about a 4 char srcid id to allow you to pass the interface name along with the flow records from the sensor.
The sensor uses the "srcid" as the unique Identifier for the source, and currently supports a 4 byte fixed buffer for passing the unique id.

Seems that what you really are asking for is an extension to the source id, that allows you to add the interface name to the source id.
We don't have a notion of interface name, as you can see from the argus.conf support for defining how argus will open interfaces
and treat the output, which is specified using the "ARGUS_INTERFACE" variable.  From the argus.conf file:

#  The syntax for specifying this either on the command line or in this file:
#     -i ind:all
#     -i dup:en0,en1/srcid
#     -i bond:en0,en1/srcid
#     -i dup:[bond:en0,en1],en2/srcid
#     -i en0/srcid -i en1/srcid  (equivalent '-i ind:en0/srcid,en1/srcid')
#     -i en0 en1     (equivalent '-i bond:en0,en1')

If you don't provide a srcid on the configuration line, argus uses the "ARGUS_MONITOR_ID" as the srcid.

OK, the message here is that argus may have many interfaces open in order to get the data it needs to form the flows.
So, to strictly say we want to be able to append interface names to source id's, is not a good general solution.

I like the notion that you have a 32-bit unsigned int to pass around unique sensor id's.  And I like the idea that we want
to be able to specify different types of uses for those 32-bits.  We currently have IPv4 addresses and unsigned ints.
So I'll add a 4-byte string to the list of types for srcid's.  The idea is that you specify the string in the argus.conf or
radium.conf by putting double-quotes around the value.

ARGUS_MONITOR_ID=10.2.3.14   // IP Address
ARGUS_MONITOR_ID=15          // int
ARGUS_MONITOR_ID="eth0"      // string

Same strategy for RADIUM_MONITOR_ID.  And we'll print the srcid using the type as specifed.

But I'm also thinking that the real solution is to have a "srcid" to "string" translation mechanism in the ra* client programs.
I'll put that in as well.  Is this useful?

Carter


On Jun 10, 2011, at 2:37 PM, The Branches wrote:

> Carter,
> 
> 4 byte ASCII srcids that rasplit won't convert back into IP addresses when I insert \$srcid into the -w parameter would be just super.   Thanks for your willingness to support this.  Just let me know when you have something you'd like me to test.  And I do like the idea of arbitrary string srcids in 3.0.8.  Argus just keeps getting better and better...
> 
> Kevin
> 
> 
> On 6/10/2011 8:25 AM, Carter Bullard wrote:
>> Hey Kevin,
>> I can add $srcid ->  string conversion no problem, either in radium, through it's labeling functions, or in rasplit().  I will be able to add arbitrary string srcids in 3.0.8 but I can put In 4 byte ASCII srcids now if that would help.
>> 
>> Carter
>> 
>> 
>> On Jun 9, 2011, at 4:48 PM, The Branches<branchbunch at gmail.com>  wrote:
>> 
>>> Carter,
>>> 
>>> On a specific sensor host, I've been running multiple argus instances (one per sniffing interface) and then attaching a separate rasplit instance to each one to store hourly files on the local file system on a per-interface/per-hour basis (like /argus/06/12/eth3-10 for the June 12th 10am file for the eth3 interface).  Due to some sporadic argus data file corruption issues I've been dealing with when attaching rasplit directly to an argus instance, I'm starting to wonder if it would be better to run a single argus instance that a single instance of radium attaches to, and then have a single rasplit instance attach to radium.   I've figured out how to get one argus instance to monitor multiple interfaces and it doesn't look hard to get radium to attach to it.  The part I can't work out so far is how to get a single rasplit instance to prefix output filenames with the interface names.  I can see how to include the source identifier in the output filename by using \$srcid in the -w parameter of rasplit, but it appears that the source id is fundamentally an IP address and can't contain arbitrary text like "eth5".
>>> 
>>> What I'd like to do is something like this, where \$interface would expand to the interface name that argus collects each record on.  I'm not sure interface name data is actually stored in the argus record, though.
>>>    rasplit -S 127.0.0.1:561 -M time 1h -w /argus/%m/%d/\$interface-%H-%M.arg
>>> 
>>> Or perhaps I could specify multiple filter and -w pairs, kind of like this
>>>    rasplit -S 127.0.0.1:561 -M time 1h - "srcid 1.1.1.1" -w /argus/%m/%d/eth1-%H-%M.arg - "srcid 2.2.2.2" -w /argus/%m/%d/eth2-%H-%M.arg  - "srcid 3.3.3.3" -w /argus/%m/%d/eth3-%H-%M.arg
>>> but that gives me a syntax error.
>>> 
>>> If what I am trying to do is not realistic or advisable to do with a single rasplit instance, I can certainly run one rasplit instance per interface, but I thought I'd ask first.  My primary goal is to eliminate argus data file corruption, and after that to keep things as simple as possible.
>>> 
>>> Kevin Branch
>>> 
>>> 
>>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110620/48d2c643/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20110620/48d2c643/attachment.bin>


More information about the argus mailing list