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

[Binh Le]

Hi Frank,

Thanks a lot for getting back to my question. I was using an Agent
derived from AgentConfigManager - and configure
snmpCommunityTable/vacm tables via snmpset command line from NetSNMP,
nothing special, no code involve..So I would assume that the
co-existence between snmpCommunityTable and other VACM tables are
handled in AgentConfigManager already.

To answer your questions:

1. The "secret" snmpCommunityName had been existed before, with
corresponding mapping to vacmSecurityToGroup and other related tables,
with full read-write access to the whole SNMP tree starting from 1.  I
removed the entry as you don't see it in the quoted MIBwalk result of
snmpCommunityTable in my first email. Another MIBwalk from top with a
grepping of "secret" show that there is no any existence of "secret"
in the whole MIB tree.
2. So it was removed successfully - see (1) above.
3. Yes, it still works after that.  I issue snmpwalk using the
community string "secret" in the example.

Any suggestion where I should look at and/or check?

Thanks,
Binh


On Sun, Jan 8, 2012 at 2:37 PM, Frank Fock <fock at agentpp.com> wrote:
> 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
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j