Default SNMP configuration issue with Foundry Networks EdgeIron 4802F

[<advisory () prophecy net nz>]

28-02-02 -- advisory () prophecy net nz


"The EdgeIron family of Layer 2 switches is designed to provide wire-speed
performance, superior port density, and complete standard Layer 2 feature
sets at an aggressive price for Enterprise users."


Problem:
--------
Foundry Networks EdgeIron 4802F Fast Ethernet switches have a
default SNMP configuration which allows SNMP requests to the switch with
any community string to have read and write access to the user.
All that is required is IP access to the switch.


Example:
--------
[prophecy@loki ~]$ snmpget 10.1.1.120 public system.sysName
system.sysName.0 =
[prophecy@loki ~]$
[prophecy@loki ~]$ snmpset 10.1.1.120 totallyinvalidcommunitystring
system.sysName s "0wned"
system.sysName.0 = 0wned
[prophecy@loki ~]$

I have tested this both before and AFTER deleting the default SNMP
communities from
the switch.  The default strings are: public (RO), private (RW).


Solution:
---------
It turns out that this is less a problem, and more a 'feature' of these
switches.
The fix from Foundry is to issue the following commands:

EdgeIron(config)#
EdgeIron(config)#snmp-server security
EdgeIron(config)#
EdgeIron(config)#snmp-server user <name> <community-string> <ip-address>

This then allows the specified IP to talk to the switch with that
community string.
Requests from other IP's are ignored and the 'snmp-server security' option
basically
turns on the checking of SNMPv1 community strings.
(Does the RFC say that you can run an SNMPv1 implementation _without_
checking
community strings?).


Conclusion:
-----------
It is misleading that the default config comes with 2 community strings
(public and private),
but the switch will still respond to snmpset requests with any community.
I'm guessing that most people (like myself), will generally change the
default community
strings on a new switch, making them read-only, and then feel somewhat
safer about pulling
SNMP information out of them.  In this case, doing those 2 things does not
stop anyone
from randomly writing to SNMP objects.

-----