So it sounds like the first approach is acceptable for read-only data.
Are most SNMP savvy customers going to want the added security of
limiting the IP addresses that can access the data, even if it's
read-only? That's what it boils down to, what the customers are going to
want.
Maybe I don't understand the terminology (i.e. what you would call these
2 approaches), but basically here's where my management is coming from -
it would be much easier to set up the configuration mechanism for this:
rocommunity <community string to be entered by user>
than for the more robust (and secure) "community name mapped to security
name mapped to group name mapped to view mapped to access rights"
method. The second method would require the user to enter management
console IP addresses, community strings, maybe even groups (although I
guess we could hardcode one group and add all IP addresses to that
group). But management doesn't want to make the user enter IP addresses
if they don't have to.
Thanks again for the input!
~ Wendy
-----Original Message-----
<snip> Almost anything which supports SNMP supports SNMPv1, and
many don't support anything else. SNMPv2c, on the other hand, is a well
supported myth. For read-only SNMP, a v1 community named "public" is
the de facto standard. You should not support community based writing
unless the customer demands it, as it is insecure.
HTH,
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
