What To do about SNMP-3-AUTHFAIL Messages

Last Updated on May 17, 2015 by Daniele Besana

Have you secured your router with an ACL for SNMP access but are still seeing pages of SNMP-3-AUTHFAIL messages in your logs? In this article we will be dig into this issue and find out exactly what’s going and and why an SNMP-3-AUTHFAIL message might showing up in your logs and also why this message might be misleading.

A Tale of SNMP-3-AUTHFAIL

So here’s the scenario, you have a router within your network that you feel  has been configured to be secured from the bad guys of the world.  You have disabled telnet access, have access control lists (ACLs) in place for SSH to only allow for secured terminal access from a jump-host or known network range.  And finally, since this device needs to be monitored, you enabled SNMP version 3 (v3 is better right?) and established an ACL to block unwanted attempts as well.  All is good.  You’ve done your job and  feel confident that this device is safe .

But what do you do when you review the logs of this device the next day (or next week or month), and find the logs full of SNMP3-AUTHFAIL messages?  You DID put that ACL in place right?  …Of course you did!  So what’s going on?

Per Cisco the SNMP-3-AUTHFAIL  messages indicates:

%SNMP-3-AUTHFAIL : Authentication failure for SNMP req from host [dec].[dec].[dec].[dec]

Explanation    An SNMP request was sent by the host at the address [dec].[dec].[dec].[dec], but the request PDU was not properly authenticated.

Recommended Action    Make sure that the community and user name that are used in the SNMP request from the remote host have been configured on the router

At first this would seem to indicate that the snmp attempts are getting through the ACL and making it to the SNMP engine only to be denied due to an incorrect community string.  Seems logical but first lets review the configuration for SNMP.

Router Configuration for SNMP

Before you configure your router for SNMP access:  Remember that using SNMP is just like any other protocol you would use for access, i.e., telnet, ssh, etc.

With this in mind NEVER use community strings like “PUBLIC”, “PRIVATE”, “CISCO”, “PASSWORD”, etc… you get the point. Brute force attacks will use these obvious words to try to gain access.  Also NEVER use a read-write string unless you absolutely need your management device to change the configuration.

!
snmp-server location work-address
snmp-server contact yourname
!
! begin ACL
!
snmp-server community public RO 5
snmp-server community private RW 6
!
! log incorrect SNMP Communities
!
logging snmp-authfail
!
! access-list for RO
!
access-list 5 permit 10.1.1.100
access-list 5 permit 10.1.1.101
!
! access-list for RW
!
access-list 6 permit 10.1.1.101
!

Notice in the config above we have enabled SNMP Auth Fail. We want this on so that attempts are written to the logs which will let us KNOW when someone or something is attempting access.

Now that we have verified a known good config, lets get back to the issue at hand and that’s all of those log messages.

Testing SNMP Failures.

The best way to the root of a problem is to test.  Make two separate tests to see what gets entered into the logs.

First test – incorrect community string.

Test access to your device using an incorrect community string.  You should see something like the following in your logs:

Jul 23 20:18:43.254 UTC: %SNMP-3-AUTHFAIL: Authentication failure for SNMP request from host 10.1.1.101

Next test with the correct community string but change the ACL to block your test machine. You should see the following in the logs:

Jul 23 20:18:43.254 UTC: %SNMP-3-AUTHFAIL: Authentication failure for SNMP request from host 10.1.1.101

Notice something interesting?? It’s the SAME log message!!!

Both the community string AND the ACL have to match before access to the SNMP engine is granted.  If either is incorrect the router will through an SNMP-3-AUTHFAIL message to the logs.

But here’s the big questions – which comes first the community string or the ACL? (It’s a bit like the old chicken-and-the-egg story).

This is “unverified” but… it seems that the ACL is only referenced *after* the authentication (ie the community string match) is completed.  So, you’ll get authentication failed messages in the logs regardless if the ACL otherwise prohibits the host from accessing the snmp process.  A followup with Cisco TAC should confirm this.

The good news, at least from our limited testing, that the SNMP is working as intended and the router is same and sound. Now if we can just clear up those log messages.. It’s awfully noisy in there!