3 nic max

[Luke Whitworth via Argus-info]

Hi Carter,

Cheers for the info, certainly seems to have gotten me closer to the 
goal, but I'm still seeing a couple of things I could do with some 
clarification on:

If I call argus as root it does indeed seem happy (I'm currently 
trialling this on at test box which only has two nics):

[root at server ~]# argus -u root -g root -i eth0\;eth1
     ArgusAlert: 02 Dec 15 10:51:46.603306 started
     ArgusAlert: 02 Dec 15 10:51:46.620610 ArgusGetInterfaceStatus: 
interface eth1 is up
     ArgusAlert: 02 Dec 15 10:51:46.636495 ArgusGetInterfaceStatus: 
interface eth0 is up

However, if I call it using a less privileged account I see:

[root at server ~]# argus -u argus -g argus -i eth0\;eth1
     ArgusAlert: 02 Dec 15 10:52:06.467326 started
     ArgusAlert: 02 Dec 15 10:52:06.486796 ArgusGetInterfaceStatus: 
interface eth1 is up
   ArgusWarning: 02 Dec 15 10:52:06.489183 ArgusOpenInterface eth0: 
socket: Operation not permitted

Guessing it all comes down to permissions, but the end goal is to run 
this as a daemon so having run as a less privileged user is certainly 
preferable.

Additionally when I do run it as root and it works I see the following 
if I list files for the relevant process in /proc/net/pf_ring:

-r--r--r--  1 root root 0 Dec  2 10:52 25007-eth0.352
-r--r--r--  1 root root 0 Dec  2 10:52 25007-eth1.351

Each contains (at the start):

[root at server pf_ring]# cat 25007-eth0.352
Bound Device(s)    : eth0
...

[root at server pf_ring]# cat 25007-eth1.351
Bound Device(s)    : eth1
...

If I cat the equivalent snort process I see:

[root at server ~]# cat 3660-eth0.11
Bound Device(s)    : eth1,eth0
..

So it appears it's being left to argus to aggregate the packets still, 
as opposed to pf_ring doing it as it does in the way Snort is doing it.  
Any suggestions?

Many thanks in advance,

Luke


On 01/12/15 16:20, Carter Bullard wrote:
> Hey Luke,
> The current code supports using ',' and ' ' as separators for interfaces.  If you want to use ';' as a delimiter, in the file ArgusSource.c, in the routine setArgusDevice(), around line 851, you can add ‘;’ to the strtok() parameters.
>
> p4 diff ArgusSource.c
> ==== //depot/argus/argus/argus/ArgusSource.c#133 - /Users/carter/argus/argus/argus/ArgusSource.c ====
> 851c851
> <       while ((tok = strtok(ptr, " ,")) != NULL) {
> ---
>>        while ((tok = strtok(ptr, " ,;")) != NULL) {
> That should do it.  Give it a try, and send an email, if it works, ….,  or not.
>
> Carter
>
> On Dec 1, 2015, at 3:56 AM, Luke Whitworth <luke.whitworth at cranfield.ac.uk> wrote:
>
>> Hi Carter,
>>
>> Many thanks for the quick reply.  I'll try and explain what we're doing but my Linux knowledge only extends to a certain point, so apologies in advance if at any point I have missed something obvious, done something silly, or I'm just being dim!
>>
>> In short the monitoring boxes are a stack of RHEL 6.7, PF_RING, Snort and Argus.  We run Snort using a command similar to /usr/sbin/snort -i "eth0\;eth1\;eth2\;eth3" -D... in order, I'm told by the person who set it up originally, to let PF_Ring handle the aggregation of packets from these ports as opposed to Snort.  We used to have Argus doing the same (using version 3.0.6.1), with the argus.conf showing ARGUS_INTERFACE=eth0;eth1;eth2;eth3, but I've recently had to upgrade PF_RING and Argus to latest versions and this setup no longer plays nicely.
>>
>> To attempt to continue using the previous notation for specifying NICs I edited argus/ArgusSource.c before compile, changing line 4442 to read  if ((strstr(device->name, "dag")) || (strstr(device->name, ";")) || (replacing napa with the semicolon).  This actually appears to be working fine on one of our hosts which only has two NICS, and works on the problem host as long as I only pass any combination of three out of the four NICs, so ARGUS_INTERFACE=eth0;eth1;eth2 works, as does ARGUS_INTERFACE=eth3;eth2;eth0, but the minute I specify all four adapters I see ArgusOpenInterface eth0;eth1;eth2;eth3: No such device exists.  This is what started me down the three interface maximum theory!  I'm getting round it at the moment by using "ARGUS_INTERFACE=bond:eth0,eth1,eth2,eth3" in the conf, so all is not lost, but if possible I'd like to retain the notation that was previously used if possible.  For clarity the Snort instances are still running using the old notation without incident so I don't believe that it's a change in PF_Ring that no longer likes this way of bonding adapters, although I could be way off the mark!
>>
>> Any suggestions you have will be most warmly welcomed.
>>
>> Cheers,
>>
>> Luke
>>
>> On 27/11/15 17:14, Carter Bullard wrote:
>>> Hey Luke,
>>> argus-3.0.8.x should handle up to 64 interface instances, so you should not have any interface limits.
>>> The argus mailing list comment was from 2001, so we’ve come a bit down the path since then.
>>>
>>> Just load the interfaces you want to monitor into your /etc/argus.conf file as ARGUS_INTERFACEs.
>>> BUT, if you do have any issues, send the actual complaint from argus, or its behavior so we can figure out what’s up.
>>> Hope all is most excellent,
>>>
>>> Carter
>>>   
>>>
>>>> On Nov 27, 2015, at 4:47 AM, Luke Whitworth via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
>>>>
>>>> Morning all,
>>>>
>>>> I'm trying to compile Argus so it works with four NICs.  I've found reference to a 3 interface limit by default (http://comments.gmane.org/gmane.network.argus/1611) but can't find where I can manipulate this during compile.  Can anyone point me in the right direction?
>>>>
>>>> Cheers,
>>>>
>>>> Luke
>>>> -- 
>>>> Luke Whitworth
>>>> Business Technologies Specialist, Information Services
>>>> Building 63, Cranfield University, Cranfield, Bedfordshire MK43 0AL
>>>> W:
>>>> www.cranfield.ac.uk  E: luke.whitworth at cranfield.ac.uk
>>>>
>>>> T: +44 (0) 1234 750111 x3556
>>>>   
>>>> This email and any attachments to it may be confidential and are intended only for the named addressee. If you are not the named addressee, please accept our apology, notify the sender immediately and then delete the email. We request that you do not disclose, use, copy or distribute any information within it.
>>>> Any opinions expressed are not necessarily the corporate view of Cranfield University. This email is not intended to be contractually binding unless specifically stated and the sender is an authorised University signatory.
>>>> Whilst we have taken steps to ensure that this email and all attachments are free from any virus, we advise that, in keeping with good computing practice, the recipient should ensure they are actually virus free.
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20151202/6a4f42e7/attachment.html>