Monitoring Authentication Attempts on Cisco Routers with Syslog

One of great things about the syslog logging standard is the capability to collect system notifications from a variety of network hosts and direct them to a central store for analysis. In this demo I will configure a Cisco router to log system messages using syslog to a central Linux server. Specifically I am interested in logging authentication attempts to the router.

My preferred syslog daemon that I will be running on my Linux syslog server is rsyslog. There are also many syslog servers available for Windows if you choose to go that route. Kiwi is one with a nice interface but the full featured version is payware. Your choice of a syslog server to collect your messages should be immaterial to this discussion as the configuration steps should be the same on a Cisco router.

Configure Syslog Server to Accept Messages

To start, we’ll make sure that the syslog server is configured to accept messages from the IP address of your router. This should be the IP of the interface on the router that is closest to the syslog server. For example, suppose the router has an external and an internal interface. Our syslog server is on the same LAN that the internal interface is connected to. The syslog server should be configured to accept messages from the IP address of the internal interface. We also have the option to manually configure the interface the syslog messages are sourced from.

The syslog standard sends log messages identified with a certain facility and severity. Generally the facility is used to identify the message as coming from a particular program or service. This has more use when the source of the syslog messages is a full blown computer server. In the case of Cisco routers by default syslog messages are sent marked as coming from the “local7″ facility, so we need to make sure that the syslog server accepts messages from this facility. The source facility can be changed if you so desire.

In addition, syslog messages have a severity attached which gives information on the priority or urgency of the message. If you are familiar with syslog you know that higher numbers represent lower severity levels. Here is a list of the minimum severity levels that a Cisco router can be configured with which to send messages to the syslog server.

Router(config)#logging trap ?
<0-7>          Logging severity level
alerts         Immediate action needed           (severity=1)
critical       Critical conditions               (severity=2)
debugging      Debugging messages                (severity=7)
emergencies    System is unusable                (severity=0)
errors         Error conditions                  (severity=3)
informational  Informational messages            (severity=6)
notifications  Normal but significant conditions (severity=5)
warnings       Warning conditions                (severity=4)

Configure Cisco Router with Secret Passwords

First let’s enter global config mode.

Router#conf t

Now we need to make sure that we have a secret password set to enter enable mode. I’ll use the “enable secret” command to encrypt the password using the type 5 MD5 hash algorithm which is much more secure than the older type 7 encryption.

Router(config)#enable secret EnablePassword

Now we’ll set up username authentication. This needs to be turned on or our authentication attempts will not be logged. Logging of authentication does not appear to work if you only use passwords set directly on the virtual telnet/ssh terminal lines.

Router(config)#username aaron secret MyPassword

We need to configure our telnet/ssh terminal lines to use local username authentication.

Router(config)#line vty 0 4
Router(config-line)#login local
Router(config-line)#exit

Configure Logging Options

Now we’ll set the router to direct messages to be logged to the IP address or hostname of our syslog server host.

Router(config)#logging 192.168.10.51

We can set the minimum severity level that log messages need to be if they are logged to the syslog server. The minimum level for logging failed authentication attempts is warning (4) and for successful authentications is notifications (5). To capture both I will configure the minimum level to be notifications. Dial this back to warnings and above if there are too many messages being forwarded to your server, but remember that the successful logins will no longer be logged.

Router(config)#logging trap notifications

I’ll choose to activate login checking for both successful and failed login attempts. Specifying “log” will generate the syslog messages. Optionally we can have the router generate a log after a certain number of attempts, but in this case I’ll log them all.

Router(config)#login on-success log
Router(config)#login on-failure log

We also need to set up a quiet mode time period. Logging of failed logins will not work without this. The “login block-for” command will create an ACL for a certain period of time that will as the name suggests block logins after a certain number of failed attempts. In this case logins will be disabled for 120 seconds if there are 3 failed attempts within a 60 second time span. This will also work well for deterring a brute force attack on the router.

Router(config)#login block-for 120 attempts 3 within 60

Optional Logging Parameters

As I mentioned at the beginning by default the syslog messages sent by the router will appear as coming from the interface closest to the syslog server. If you want to change this behavior you can manually specify the interface the messages appear to come from.

Router(config)#logging source-interface FastEthernet0/0

We can also activate a delay which will slow login attempts. In this case there will be a 5 second delay between when a bad username/password combo is entered and when the next login prompt is presented.

Router(config)#login delay 5

That should do it. You can now test a successful or failed login attempt and the messages should show up on the syslog server!