* Never use a password that can be found in a dictionary.
* Never use a password related to the hostname, domain name,
or anything else that can be found with whois.
* Never use a password related to your hobbies, pets, relatives,
or date of birth.
* Use characters other than letters and numbers.
An old joke goes like this: "I was told that I should not choose the name of my cat as a root password, but I was too arrogant to listen and now all my servers are gone! I am so sad, oh my, dear fluffy %⁁3″£#P$j&F*|!" You have probably heard a variation of this joke and all the recommendations above many times. Unfortunately, some people haven't heard or simply ignore them. To curtail that, a few features in the recent IOS versions allow some control over the device password selection. One such feature is the security passwords min-length length command that prevents administrators from choosing short passwords (at least eight characters are recommended). Also, when the auto secure command is run, it checks that the login and enable passwords are not the same. This is vital, since on many routers with default or easily guessable passwords, a single insecure password is used for both privileged and unprivileged users.
The auto secure and security passwords min-length length commands appeared first in IOS version 12.3(1), got fully integrated into 12.2(18)S, and were enhanced in 12.3(8)T.
Then set the local authentication method like so:
- cisco(config)# aaa new-model
- cisco(config)# aaa authentication login telnet-auth local
- cisco(config)# line vty 0 4
- cisco(config-line)# login authentication telnet-auth
In addition, if you can afford it, use a centralized access control means, such as TACACS+, RADIUS, or Kerberos. To set up TACACS+ based login authentication, a typical set of commands would look like this:
- cisco(config)# aaa new-model
- cisco(config)# aaa authentication login telnet-auth grp tacacs+ local
- cisco(config)# tacacs-server host
key - cisco(config)# tacacs-server host
key - cisco(config)# tacacs-server timeout 5
- ! This simply shows the default timeout in seconds
- cisco(config)# line vty 0 4
- cisco(config-line)# login authentication telnet-auth
Configuring RADIUS-based login authentication is similar:
- cisco(config)# aaa new-model
- cisco(config)# aaa authentication login telnet-auth grp radius local
- cisco(config)# radius-server host
key - cisco(config)# radius-server host
key - cisco(config)# radius-server retransmit 3
- ! This simply shows the default amount of retransmits
- cisco(config)# radius-server timeout 5
- ! This simply shows the default timeout in seconds
- cisco(config)# radius-server dead-criteria tries 3
- cisco(config)# radius-server challenge-noecho
- cisco(config)# line vty 0 4
- cisco(config-line)# login authentication telnet-auth
This configuration will use RADIUS authentication/accounting ports 1645/1646. This is fine for a Cisco Secure Server that still employs these ports. For other RADIUS servers, you would probably need to change both ports to 1812 and 1813 with this command:
radius-server host insert hostname or IP of the server here auth-port
1812 acct-port 1813
A frequently overlooked detail is setting a proper clipping level. By clipping level, we mean the amount of "guessing logins" allowed before the connection is dropped. Three is a good and universally accepted clipping level number. A legitimate user can make an error when typing a password once or even twice, but every attempt beyond three looks highly suspicious. Centralized authentication with RADIUS and TACACS+ provides us with a flexible clipping level setting via the amount of retransmits. Without it, auto secure, or Cisco IOS Login Enhancements, you are limited to the default clipping level of three. This is reasonable, but you might want to modify it in some cases. When the auto secure feature is available, the security authentication failure-ratethreshold-rate log command can be employed to set the number of allowable unsuccessful login attempts (the default is 10). When this number is exceeded, a 15-second delay occurs and a syslog message is generated. Another parameter that makes sense to modify is the amount of sessions, set by a (config-line)#session-limit sessions number. This helps against bruteforcing tools capable of launching simultaneous connects to the Cisco telnetd. One is a safe number of accepted sessions; you shouldn't need more than one Telnet session to configure a router.
Cisco IOS Login Enhancements (ILE) is a reasonably recent security feature that was first introduced in IOS 12.3(4)T and integrated into 12.2(25)S. It allows better control and logging of login-related events for Telnet, SSH, and web interface connections to the supporting host. For instance, ILE introduces management of delay between successive login attempts, login blocking when an attack is detected, and a variety of additional logging messages. Setting up a custom delay between successive logins is done via a login delay seconds command, which is optional. The "main" ILE command (main configuration mode) looks like this:
login block-for seconds attempts amount of tries within seconds
You can verify all the ILE parameters by entering show login and check unsuccessful login attempts via show login failures. The latter will list the amount of failures, usernames tried, and offending IPs with a timestamp added to each unlucky attempt.
In addition, a mundane recommendation sometimes offered is to restrict Telnet access to a selected host or network range. This is easy to accomplish with a standard access list; here's an example:
- cisco(config)# access-list 1 permit host 192.168.77.5 log
- cisco(config)# line vty 0 4
- cisco(config-line)# access-class 1 in
Surely, such restrictions are easy to bypass with casual IP or ARP spoofing and should not be considered a reliable countermeasure.
[*] Hacking Exposed - Cisco
biOos
No comments:
Post a Comment