Re: General security usage question

On 14/01/2008, McGowen, Wendy <wendym@pivot3.com> wrote:
> We'll be allowing the user to configure the SNMP security through our UI
> (which does NOT use SNMP), so we're hoping to keep it as simple as possib=
le.
> I've been testing with what I guess is called "v2" security =96 where you=
have
> to list IP addresses of clients, put them in groups with specific access,
> etc. (I haven't even attempted the "v3" stuff yet). But management is
> wondering if we could make it even simpler for the customer, and step back
> to "v1", which I guess is nothing more than a community string and either
> "read" or "read/write" access.


Can I suggest that you avoid referring to these as "v1" and "v2" security.
It would be all-too-easy to assume that this refers to SNMP versions.

SNMPv1 and SNMPv2c both use exactly the same authorization
mechanism (namely the community string), and there is effectively
no difference between them from an administrative point of view.
The security is the same in both cases (i.e. very little!)
The advantages of SNMPv2c are purely in the protocol behaviour
(especially improved error reporting).




> So my question is, is it "okay" to use the simplest security model (and t=
he
> least secure) if you're going to have view only data? Or are most SNMP
> customers going to want a more secure model?

They're your customers - you probably know more about them than we do!

Anyone with a serious interest in security would want to use SNMPv3.
The two community-based versions aren't really secure at all - a simple
network sniffing attack would be sufficient to break them.

Source-based filtering is by no means foolproof, but it *is* a useful
technique. I would expect a number of your customers would like
to have this as an option.


> Are most SNMP savvy customers going to want the added security of
> limiting the IP addresses that can access the data... That's what it
> boils down to, what the customers are going to want.

I don't know about "most", but there are probably going to be sufficient
interested in this to make it worth doing. Maybe as an "advanced"
configuration setting. You can always default to global access.



> 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.

But that's exactly what "rocommunity" does.
It's just that all the processing is handled under the hood - you don't see
the details unless you actually look at the VACM tables.

So what you really need to support are the two formats:

rocommunity <string>
and
rocommunity <string> <source>

That would give you the two styles of access control that you've
mentioned, without having to worry about the complexity of the
full com2sec/group/view/access mechanism.

Dave

PS: No - I haven't forgotten about the MIB review I promised.
It's just been a busy couple of weeks!

-------------------------------------------------------------------------
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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users