[14287] in bugtraq
Re: snmp problems still alive...
daemon@ATHENA.MIT.EDU (monti)
Wed Mar 15 00:25:54 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSF.3.96.1000313221509.24971D-100000@mournblade>
Date: Mon, 13 Mar 2000 22:49:37 -0600
Reply-To: monti <monti@USHOST.COM>
From: monti <monti@USHOST.COM>
X-To: Damir Rajnovic <drajnovi@CISCO.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <4.2.0.58.20000310181304.00cdf790@amsterdam.cisco.com>
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?
>
