> From: Meilán García Antonio [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 18, 2007 12:06 PM
> To: Mike Ayers
> The question is that my communities names can be change remotly,
> so you can to get this final configuration
You should not change the *name* of the community, you should change
its *permissions*. By changing the community name, you risk clobbering an
existing community, which results in a nonworking configuration, which is
apparently what you ran into.
If you are asking if you can undo the clobbering with SNMP operations,
the answer is a definite maybe. If the "private" community is your only
security principal with write permission, then there's nothing you can do,
since you no longer have any write access. If you have a security principal
(v1/v2c community or v3 user) with write access, then change the entry in the
snmpCommunityTable that maps the security name "public_sec" to the community
"private", and change the community name back to "public". That should return
"private" to functional status.
Note that each line in your security configuration (com2sec, group,
etc.) represents an entry in a standard MIB table. The "com2sec" lines
configure the snmpCommunityTable, the "group", "view", and "access" lines
configure VACM tables, etc.
> # sec.name source community
> com2sec public_sec default private
> com2sec private_sec default private
>
> # groupName securityModel securityName
> group public_grp v1 public_sec
> group public_grp v2c public_sec
> group private_grp v1 private_sec
> group private_grp v2c private_sec
>
> # name incl/excl subtree mask(optional)
> view rview included system.sysName
> view rwview included system.sysName
>
> # group context sec.model sec.level prefix
> read write notif
> access public_grp "" any noauth exact
> rview none none
> access private_grp "" any noauth exact
> rwview rwview rview
>
> (in the other case I had
> access private_grp "" any noauth exact
> rview rwview rview
> but that does not matter)
I'm confused - both lines are the same.
> I don't know if It is normal that with this configuration you
> can not to set variables, because the agent mix the
> permissions if you try to do a set with 'private'
> (snmpset -v2c -c private host name)
Defaulting to a secure posture is good. Perhaps you can't manage your
machine, but neither can an attacker who messes with your security tables.
> I solvented this preventing that this never happen, if the
> manager try to change for example, 'public' for 'private'
> (both would be 'private') I give a SNMP_ERR_BADVALUE
I'm not sure at what level you made this change, but it might not be a
bad idea. I'd have to review and meditate upon some RFCs before I knew for
sure there wasn't a good reason to put multiple security names on a community.
HTH,
Mike
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
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
