28-02-02 -- advisoryat_private "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. -----
This archive was generated by hypermail 2b30 : Wed Mar 20 2002 - 15:27:32 PST