Bugtraq mailing list archives
Re: snmp problems still alive...
From: monti () USHOST COM (monti)
Date: Mon, 13 Mar 2000 22:49:37 -0600
Correct me if I'm wrong... but my impression was that a community string was *always* required for snmp to work on IOS. That is, *if* you have the snmp-server enabled, you must assign a community. (If i'm wrong, then what did it default to... "" null? Thats frightening.) The problem I've seen is that things like 'setup' and other front-ends have been known to create a default of 'public'/'private' (not to mention network administrators have come to belive that this is just a matter of convention and mimic it, although I dont know if Cisco can be blamed for that). I dont know if 'setup' still does this, since I havent used it in a long time, but it used to. The Cisco PIX (disturbingly enough) apparently *requires* a community string. But, based on what I can tell, in a bad way. The existence/use of the snmp server appears to hinge on the community. You cannot issue a 'no snmp-server' or 'no snmp-server community'. As such, it seems that snmp cannot be completely disabled. Furthermore, it does literally default to 'public'. (This is up to 4.4(4), I havent tried 5.x yet) The good news (not really all that good, but for the sake of argument) is that at least snmp queries are only allowed on the 'inside' interface. I have tried looking through the PIX documentation for a way to completely disable the SNMP agent and haven't found anything. If anyone knows of an equivalent to 'no snmp-server' for PIX, please share! I'm unaware of a way to completely disable snmp, and have had to live with simply assigning very very long random strings for the community in many implementations. Eric Monti Denmac Systems ericm () denmac com monti () ushost com On Fri, 10 Mar 2000, Damir Rajnovic wrote:
Hello, Not so long ago there was discussion on this list regarding problems with SNMP and this is our contribution to it. With this I will fulfill a request of the customer who brought this to our attention. Cheers, Gaus --------- Simple Network Management Protocol Version 3 (SNMPv3) is an interoperable standards-based protocol for network management. This version is first introduced in Cisco IOS 12.0(3)T. In all images which implement the new SNMPv3 engine (12.0(3)T and above and images based on this), the new SNMP engine now requires that a community string be defined (if used). Example: If user enters this command: snmp-server host <ip-address> foonly then the community string must be defined first with the command: snmp-server community <community> [ro|rw] e.g. snmp-server community foonly ro If this required line is not present, then it will be inserted automatically, using the password defined in snmp-server host command. The automatically generated snmp-server community line can not be erased from configuration file. It will be automatically generated every time. This requirement was not well documented, but it is indeed a requirement of the new engine and it is intended behavior. The updated documentation can be found at http://www.cisco.com/univercd/cc/td/doc/product/software/ ios120/120newft/120t/120t3/snmp3.htm (URL is wrapped) In the case where the customer wishes to use a unique community string with the "snmp-server host" command but does NOT want that string to be valid for SNMP polling, simply define that community string with an access-list which specifies "deny any" e.g. snmp-server community foonly ro 10 snmp-server host <ip-address> foonly access-list 10 deny any If the administrator is not aware of this and if the configuration is not carefully inspected after every change, this may lead to using a weak password for the community string. When snmptrap daemons do not require a community string, the administrator may be tempted to use easily guessable passwords. ============== Damir Rajnovic <psirt () cisco com>, PSIRT Incident Manager, Cisco Systems <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> Phone: +44 7715 546 033 4 The Square, Stockley Park, Uxbridge, MIDDLESEX UB11 1BN, GB ============== There is no insolvable problems. Question remains: can you accept the solution?
Current thread:
- Re: snmp problems still alive... Damir Rajnovic (Mar 10)
- Re: snmp problems still alive... monti (Mar 13)
- Re: snmp problems still alive... Damir Rajnovic (Mar 13)
- Unexpected and dangerous AIX 4.X linker behavior Gregory Neil Shapiro (Mar 14)
- Administrivia Elias Levy (Mar 14)
- Sojourn Search Engine exposes files Cerberus Security Team (Mar 14)
- abuse.man (webmanager kit) Guido Bakker (Mar 15)
- FreeBSD Security Advisory: FreeBSD-SA-00:07.mh FreeBSD Security Officer (Mar 15)
- FreeBSD Security Advisory: FreeBSD-SA-00:08.lynx FreeBSD Security Officer (Mar 15)
- FreeBSD Security Advisory: FreeBSD-SA-00:09.mtr FreeBSD Security Officer (Mar 15)
- FreeBSD Security Advisory: FreeBSD-SA-00:10.orville-write FreeBSD Security Officer (Mar 15)
- Re: snmp problems still alive... monti (Mar 13)