[SNMP4J] Remove entry in snmpCommunityTable does not actually remove the entry?

Frank Fock fock at agentpp.com
Sun Jan 8 23:37:43 CET 2012


Hi,

What agent are you using (i.e., SampleAgent)?
 From the output you quoted, I cannot see
1. that a "secrect" community existed and
2. that it was removed successfully and
3. that it does still work after that.

Have you set the CoexistenceProvider of the BaseAgent
to your CommunityMIB instance?

Although keep in mind, that the access restrictions are
handled by the VACM. The Community MIB only provides
mapping (coexistance) information. If the Community
MIB implementation is not set as coexistance information
provider, the community name is directly used as security
name by SNMP4J-Agent.

Best regards,
Frank


Am 06.01.2012 01:05, schrieb Binh Le:
> Hi all,
>
> I have an entry in snmpCommunityTable with snmpCommunityName "secret".
> After removing the entry by setting the corresponding
> snmpCommunityStatus to 'destroy', it's expect that I should not be
> able to mibwalk using the community string "secret" any more. However,
> it still works as seen below:
>
> lpbinh$ snmpwalk -v 2c -c secret 10.175.53.15 snmpCommunityTable
>
> SNMP-COMMUNITY-MIB::snmpCommunityName.'abcd' = STRING: "abcdef"
> SNMP-COMMUNITY-MIB::snmpCommunitySecurityName.'abcd' = STRING: abcdef
> SNMP-COMMUNITY-MIB::snmpCommunityContextEngineID.'abcd' = Hex-STRING:
> 80 00 93 FE 43 6F 72 61 69 64
> SNMP-COMMUNITY-MIB::snmpCommunityContextName.'abcd' = STRING:
> SNMP-COMMUNITY-MIB::snmpCommunityTransportTag.'abcd' = STRING:
> SNMP-COMMUNITY-MIB::snmpCommunityStorageType.'abcd' = INTEGER: volatile(2)
> SNMP-COMMUNITY-MIB::snmpCommunityStatus.'abcd' = INTEGER: active(1)
> SNMP-COMMUNITY-MIB::snmpCommunityStatus.'abcd' = No more variables
> left in this MIB View (It is past the end of the MIB tree)
>
> lpbinh$ lpbinh$ snmpwalk -v 2c -c secret 10.175.53.15 1 | grep secret
> lpbinh$
>
> Same behavior when I remove the entry via
> communityMIB.removeSnmpCommunityString(index) .
>
> Any comment/suggestion for the pure delete? Otherwise, this may be
> considered as a security hole.
>
> Thanks,
> Binh.
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231




More information about the SNMP4J mailing list