Re: [SNMP4J] Remove entry in snmpCommunityTable does not actually remove the entry?
Hi Binh, Can you reproduce the same behavior with the unmodified SampleAgent? If not, then you have missed a necessary configuration for your setup. You are right, that the AgentConfigManager should setup the community MIB correctly, but that also depends on a couple of other prerequisites. Regarding 3.: The quoted log does not show the result of the SNMP query because you grep for secretwhich must not be in the output anyway. Best regards, Frank Am 12.01.2012 08:40, schrieb 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 Fockf...@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@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@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@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
Re: [SNMP4J] Remove entry in snmpCommunityTable does not actually remove the entry?
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 f...@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@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@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j ___ SNMP4J mailing list SNMP4J@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
Re: [SNMP4J] Remove entry in snmpCommunityTable does not actually remove the entry?
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@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@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
Re: [SNMP4J] Remove entry in snmpCommunityTable does not actually remove the entry?
Frank, can you help with this question? I am running the Agent 1.4 by the way. Thanks, Binh On Thu, Jan 5, 2012 at 4:05 PM, Binh Le lpb...@gmail.com wrote: 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@agentpp.org http://lists.agentpp.org/mailman/listinfo/snmp4j
