Friday, December 25, 2009

Securing IOS local authentication logins

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.1Trying 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.1Trying 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-listsExtended 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.


source:packetlife.net

No comments:

Post a Comment