The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

Securing IOS local authentication logins

By stretch | Monday, July 27, 2009 at 2:32 a.m. UTC

By default, the local authentication provided by IOS is fairly simple. However, there are a number of enhancements which can be enabled to greatly improve its resiliency against dictionary and brute-force login attacks.

A derivation of the login command can be used to enforce a temporary block, or "quiet period," against login attempts after a specified number of failed attempts have been made within a given time frame. For example, a router can be configured to disable inbound terminal connections for five minutes (300 seconds) after encountering five failed login attempts within 60 seconds:

Router(config)# login block-for 300 attempts 5 within 60

Issuing this command creates an access list named sl_def_acl as we'll see shortly. We can observe what happens when five failed login attempts are made within 60 seconds:

Host# telnet 10.0.0.1
Trying 10.0.0.1 ... Open

User Access Verification

Username: attempt1
Password:

% Authentication failed

Username: attempt2
Password:

% Authentication failed

Username: attempt3
Password:

% Authentication failed

[Connection to 10.0.0.1 closed by foreign host]
Host# telnet 10.0.0.1
Trying 10.0.0.1 ... Open

User Access Verification

Username: attempt4
Password:

% Authentication failed

Username: attempt5
Password:

% Authentication failed

[Connection to 10.0.0.1 closed by foreign host]
Host# telnet 10.0.0.1
Trying 10.0.0.1 ... 
% Connection refused by remote host

Notice that we never received a sixth authentication prompt. On the router, we see that this log message was generated as soon as the fifth login attempt failed:

%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 33 secs, [user: ]
 [Source: 10.0.0.2] [localport: 23] [Reason: Login Authentication Failed] [ACL: sl_def_acl]
 at 15:39:25 UTC Sun Jul 26 2009

The router automatically activated the ACL sl_def_acl to deny all inbound terminal and HTTP connections for the duration of the quiet period. This ACL does not appear in the running configuration, but is visible using show ip access-lists:

Router# show ip access-lists
Extended IP access list sl_def_acl
 10 deny tcp any any eq telnet log
 20 deny tcp any any eq www log
 30 deny tcp any any eq 22 log
 40 permit tcp any any eq 22 log

Our last connection attempt above triggers a match and subsequent deny on the ACL as you would expect:

%SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 10.0.0.2(16167) -> 0.0.0.0(23), 1 packet

After the quiet period has expired, a log message appears letting us know that the router is ready to accept connections again (this message appears exactly 300 seconds after the QUIET_MODE_ON alert):

%SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 15:44:25
 UTC Sun Jul 26 2009

Of course, disabling all connection attempts during the quiet period likely does more harm than good, as legitimate administrators are affected as well. Alternatively, a custom quiet period ACL can be supplied to exempt certain source addresses.

Router(config)# login quiet-mode access-class TRUSTED_HOSTS

It's worth mentioning that, if you've properly secured remote terminal access to begin with, this command should be unnecessary.

Other login options include:

  • delay - Configure a delay between 1 and 10 seconds to wait between login attempts.
  • on-failure - Log individual login failures.
  • on-success - Log individual successful logins.

Posted in Security

Comments


Tacack
July 27, 2009 at 4:25 a.m. UTC

Great Blog Stretch! I knew this command but i didnt know that the time-range based ACL was behind it. Do you think we'll also be able to see the time-range which is being used by the ACL for blocking??


phil
August 1, 2009 at 2:13 a.m. UTC

man i really do like this site.

don't you think that the example is a little conservative. if you set a strong password it is next to impossible to crack a password in five tries within five minutes. on a remote router, you could easily DoS it by using several automated tools. but then i guess that's what ACL's are for. Also, curious about your opinion on Vyatta. I've been using it now for a while and really really like it.


Vishwanath
September 2, 2010 at 6:03 a.m. UTC

This Sites is nice goods to every one who is in Network Feild solution of every networking thing thank to Jeremy Stretch


sumitskj
April 15, 2012 at 5:53 p.m. UTC

I have an iball baton router how do i get this feature???

Comments have closed for this article due to its age.