Home page logo

bugtraq logo 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:


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.


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

snmp-server community <community> [ro|rw]


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


(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"


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
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?

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]