Login failed through SNMPv1/v2c

[NetGuy]

I periodically see these entries in my logs:

SNMP.Master: Slot-1: Login failed through SNMPv1/v2c - bad community name (x.x.x.x)

This isn’t an Extreme issue - that’s just where I am seeing the messages.  SNMP is configured correctly and the devices that SHOULD be using SNMP are not having a problem.  It just seems that periodically devices on my network are attempting an SNMP connection to my Extreme switches and I just wondered if anyone knew why that might be?  This is my core switch, so the devices are seeing it as the ‘gateway’.

The attempts are almost always in groups of four and as far as I can tell they are always from Windows clients.  We have a large-ish network so getting access to the physical clients is tricky but I can gather some information remotely.  And while there are repeat offenders, it’s usually different clients.

It’s as if they are polling their gateway for some reason.  Is it malicious?  What are they trying to accomplish?  Is it the public, or private community?  (If private, that might seem malicious...)  If they gained access, what would they be trying to do?

Again, I know it’s not an Extreme issue, but I hoped the community might have seen this before and be able to shed some light.

[Kawawa]

With a packet capture, you can get some answers.  If you do not have easy access to the hosts that the failed authentication was logged against, you could create an ACL that captures any SNMP traffic that comes from the group of hosts that should not be sending SNMP traffic. Say your client subnet is 172.16.0.0/16, and your switch logging the error is 192.168.1.254, you could do something like this:

Create a mirror ( you could use a remote-mirror configuration if you want, otherwise, if you have a free port on the switch, you could do a local mirror)

create mirror snmp_mirror to port <pc port>
enable mirror snmp_mirror

Then you add the following ACL to the interface that you’ve configured for your SNMP (if using in-band-management) otherwise, you can configure it to the client facing ports:

entry mirror_snmp {

    if { protocol udp ; destination-port 161 ; destination-address 192.168.1.254/32 ; }

    then { mirror snmp_mirror ; count rogue_snmp ; }

}

Apply the ACL to either a VLAN or a range of ports

configure access-list mirror_snmp vlan <name> ingress

OR

configure acecss-list mirror_snmp ports <range> ingress

What will happen is that each time an SNMP packet ingresses the VLAN or port from the client subnet with the specific switch IP as destination-address, it will copy the packet and send it to the monitor port.  You can then check the capture to see what the SNMP payload contains ( a] the credentials being used, b] the specific OID being polled).

Some recommendations:

1. You can configure an SNMP access-profile and add legitimate SNMP sources
2. You could also do (1) by modifying the ACL I included above and replacing the mirror snmp_mirror with deny
3. Because SNMPv1v2c is transmitted in plain text, even when you do change the community names, you might want to consider configuring SNMPv3 and disabling SNMPv1v2c in your network, especially if you have write communities enabled on your devices that could push SNMP sets

I hope this helps