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 27 08:17:41 EDT 2011
Hey Kevin,
I think you need to 'escape' the double-quotes in order to get them to work on the command line?
This should work:
argus -i tru/\"tru\",dmz/\"dmz\",wir/\"wir\" -P 561 -d
Carter
On Jun 24, 2011, at 6:24 PM, The Branches wrote:
> Carter,
>
> I would indeed find it useful to be able to specify an arbitrary textual srcid, even with a 4 character limit. All the interface names that I want to represent in the srcid attribute happen to be 4 characters or less anyway.
>
> I tried to start argus-3.0.5.4 like this:
> argus -i tru/"tru",dmz/"dmz",wir/"wir" -P 561 -d
> so that argus would sniff interfaces tru, dmz, and wir and tag them with a textual srcid the same as the interface name. It fails with "srcid tru unknown". However I was able to specify the srcid assignments I wanted by putting this in argus.conf
> ARGUS_INTERFACE=ind:tru/"tru",dmz/"dmz",wir/"wir"
> Then I was able to run a single instance of rasplit like this:
> rasplit -S 127.0.0.1:561 -M time 1h -w /argus/%m/%d/\$srcid-%H-%M.arg
> and split out the flow records across my /argus file system by month/day, with the interface name and numeric hour in the file name.
>
> It would be nice to support the specifying of quoted text srcid values at the command line (-i) as well as in argus.conf (ARGUS_INTERFACE), but even as it stands I am thrilled with this functionality and am eager to switch over from running handfuls of argus and raplit instances on the same sensor. Thanks Carter!
>
> A "srcid" to "string" translation mechanism in the ra* client programs would be more elegant in that larger strings could be associated with the srcid values, but I'd vote for that as separate additional functionality rather than a replacement of a 4-character string native srcid type. That way those who only need small strings can skip over the translation stuff.
>
> Thanks again!
> Kevin
>
>
> On 6/20/2011 12:42 PM, Carter Bullard wrote:
>>
>> 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/20110627/8118fa1f/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/20110627/8118fa1f/attachment.bin>
More information about the argus
mailing list