I don't think that the SNMPv3 user-based access control
includes source-based filtering. A username with the
correct password is valid, wherever the request comes from.
But I Could Be Wrong.
> group groupRW v1 user1
> group groupRW v2c user1
You'll need another line
group groupRW usm user1
(and similarly for the others) to add the SNMPv3-USM understanding
of "user1" to the RW group. But the view and access lines will
probably stay the same.
(Com2Sec just gets from the community string to the same level as
an SNMPv3 username, or "security name")
Dave
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>> - user1 account from 192.168.1.0 network
>> - user2 account from 192.168.0.0 network
>> - user3 account from rest of the world
Dave> I don't think that the SNMPv3 user-based access control
Dave> includes source-based filtering. A username with the
Dave> correct password is valid, wherever the request comes from.
Dave> But I Could Be Wrong.
You wouldn't be though.
SNMPv3 assumes that the cryptographic strength of the protocol is
sufficient that you don't need IP based filtering like you did with
communities.
--
Wes Hardaker
Network Associates Laboratories
Just covering myself, Wes - as per usual :-)
Wes> SNMPv3 assumes that the cryptographic strength of the protocol is
Wes> sufficient that you don't need IP based filtering like you did with
Wes> communities.
That's what I suspected was probably the reasoning.
It's actually a pity, IMO.
I think it would be quite reasonable to want to guard
against (say) social-engineering type attacks, and say
"Even if someone manages to find out my password, I only
ever do network management from this network. If somebody
comes in from outside claiming to be me - don't believe them!"
Dave
Dave> That's what I suspected was probably the reasoning.
Dave> It's actually a pity, IMO.
I actually agree. I think it would still be beneficial to have
address filtering combined with the USM authentication. It's just not
what the standard MIBs do (you could implement that feature as a
vendor, however, but it wouldn't be configurable in a standard way).
--
Wes Hardaker
Network Associates Laboratories
One more question about SNMP v3 configuration : since net-snmp-config
script is not available in the ucd-snmp distribution (4.2.6), how can I
create the first SNMP v3 user account ? Is there another way to ?
Actually, I tried by directly inserting in the /var/ucd-snmp/snmpd.conf
file a :
create admin MD5 "one password" DES "another password"
rwuser admin
and running snmpd with option -c /var/ucd-snmp/snmpd.conf.
But it simply doesn't work. The user admin is "unknown" (snmpwalk -v 3
-l authNoPriv -u admin -A "one password" localhost sysUpTime.0) probably
because the basic admin account is not created. Is this a Kerberos issue
? Do i have to upgrade my distribution to net-snmp 5.0 ? Or should i do
something before ?
Thanks.
Yves
Close - try "createUser" instead of "create"
> rwuser admin
This belongs in the normal /usr/local/etc/snmpd.conf (or wherever this
is found) - not the /var/ucd-snmp/snmpd.conf file. The 'createUser'
directive is the *ONLY* time you should edit the /var one yourself.
> and running snmpd with option -c /var/ucd-snmp/snmpd.conf.
You don't need to specify this - the agent should pick it up anyway.
> But it simply doesn't work. The user admin is "unknown" (snmpwalk -v 3
> -l authNoPriv -u admin -A "one password" localhost sysUpTime.0) probably
> because the basic admin account is not created.
Let's take this one step at a time.
Stop the agent, and add lines as follows:
/usr/local/etc/snmpd.conf: rwuser admin
/var/ucd-snmp/snmpd.conf: createUser ......
(removing any 'usmUser' or 'createUser' lines that are there already).
Start the agent: snmpd -f -L
and kill it again: ^C
Have a look at the /var/ucd-snmp/snmpd.conf file.
Does it still have the "createUser" line in it,
or has this been replaced by a "usmUser" line?
Or simply deleted altogether?
Dave
> Stop the agent, and add lines as follows:
>
> /usr/local/etc/snmpd.conf: rwuser admin
> /var/ucd-snmp/snmpd.conf: createUser ......
>
> (removing any 'usmUser' or 'createUser' lines that are there already).
>
> Start the agent: snmpd -f -L
> and kill it again: ^C
>
> Have a look at the /var/ucd-snmp/snmpd.conf file.
> Does it still have the "createUser" line in it,
> or has this been replaced by a "usmUser" line?
> Or simply deleted altogether?
1) the following error when running snmpd -f -L
/var/ucd-snmp/snmpd.conf: line 8: Warning: Unknown token: createUser.
UCD-SNMP version 4.2.3
2) Altogether deleted in /var/ucd-snmp/snmpd.conf
Yves
Ah! That's not a good sign :-(
How did you configure the package initially?
I.e. what flags did you give to "configure" ?
Dave