"Robert D. Hughes" wrote: > > To reiterate: > Use a long and complex mixed case alpha-numeric community string for > both gets and sets (if sets are needed. CiscoWorks requires the > ability to do both gets and sets, as do many management applications > in a distributed environment. Also, SNMP is case sensitive, FYI) and > *never* *ever* used the default strings > Limit SNMP to the internal network if at all possible, though the > risks are often overstated when it comes to running it on the > external networks > If SNMP is required on devices on an external or partner network, set > an allowed manager(s) and only accept SNMP to/from this host(s) > Push your vendor to migrate to SNMP V3 if they haven't already done > so, then implement it along with all the benefits it brings > If sets are not required, disable them at the device. Do not depend > on an application proxy to protect you. > Do not allow SNMP or SNMP-TRAPs into your network from an untrusted > network (just as you shouldn't allow any packets originating from > untrusted networks into yours except to servers running publicly > accessible applications)
The only solution that will stand up to a threat model that includes the possibility of sniffing SNMP traffic is proper use of SNMPv3. SNMP uses UDP, so if I can sniff traffic to obtain community strings I can EASILY spoof the address of the allowed manager station and do GETs or SETs. I do not believe that the risks are overstated when talking about running SNMP on untrusted external networks where there is no assurance that sniffers don't exist. -paul
