Cisco released a new set of features relating to the login/logout process with IOS 12.3(4)T (technically it was available all the way back to 12.2(33)SRA, but most of us run GA images unless absolutely necessary). These features allow you granular control over how the IOS reacts to login attempts. You can tell the device to block future login attempts if so many failed attempts have occurred within a certain amount of time, log successful and failed login attempts (not only to syslog, but show a message on your console screen).
NOTE: If you’re using a virtual terminal (eg. telnet, ssh, etc.), don’t forget that you can view what’s being sent to the console with the term mon command. This copies what’s being sent to the console to your terminal session. Beware though, as sometimes you can become inundated with messages (especially if some debug commands are entered). You might check to see if any debug commands are entered by issuing the show debug command.
To see Cisco’s article on these new features, go to http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_4/gt_login.htm. When I recently underwent configuring the new “IOS Login Enhancements” on a 2811 running IOS 12.4(13a), I ran into some nuances that I didn’t find documented, so I figured I’d share them.
As is my usual style, this isn’t meant to be a one-stop reference on this subject, simply some tidbits of hopefully useful information. Read the above URL or better yet, the documentation for your particular IOS version to see a description of all of the commands and what they really do.
What I found is that you can configure failed and/or successful login attempt logging, but without the blocking mechanism configured, it didn’t do anything. Here’s an example config:
! the rest of the router's config above... ! login delay 1 login on-failure log login on-success log ! ! rest of router's config follows below...
This results absolutely nothing in my testing. But, if the following command is entered:
login block-for 1 attempts 3 within 5
I receive the alerts (logged entries) as I wanted. The login delay command isn’t necessary to log the messages, but the login block-for is certainly required! The example command above is just that — an example. You can adjust to your organization’s security policy(s) relating to logins. Most OSs have had this type of functionality for some time (and if you’ve been using a RADIUS/TACACS+ server, you’ve probably already been enjoying these features, but they’ve been provided by the server itself, not by the IOS device).
Here’s what the finished, working config looks like on my router:
! the rest of the router's config above... ! login block-for 1 attempts 3 within 5 login delay 1 login on-failure log login on-success log ! ! rest of router's config follows below...
Once you have the settings configured properly for your device, expect to see some of the following messages:
- Successful console connection:
*May 21 21:08:53.439 UTC: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ] [Source: 0.0.0.0] [localport: 0] at 14:08:53 PDT Mon May 21 2007
- Successful virtual login:
*May 21 21:12:14.155 UTC: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: cisco] [Source: 10.10.10.1] [localport: 22] at 14:12:14 PDT Mon May 21 2007
- Failed virtual login:*May 21 21:13:23.063 UTC: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: cisco] [Source: 10.10.10.1] [localport: 22] [Reason: Login Authentication Failed] at 14:13:23 PDT Mon May 21 2007
Keep in mind that these messages are logged. Not just to your console screen, but also to any syslog servers you have defined (unless you’re filtering these messages from being sent to your syslog server). I imagine that these can be used as another event in the Cisco Embedded Event Manager — if you’ve had any experience with the EEM and these login enhancements, I’d like to hear about it!