You want to assign individual (or group) user IDs and passwords to network staff.

Use the following set of configuration commands to enable locally administered user IDs:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#username ijbrown password oreilly
Router1(config)#username kdooley password cookbook
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default local
Router1(config)#end
Router1#

The username command also allows you to create usernames without passwords by specifying the nopassword keyword:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#username weak nopassword
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default local
Router1(config)#end
Router1#

However, we strongly recommend against doing this because it can severely weaken the router’s security.

Enabling locally administered usernames overrides the default VTY password-based authentication system. When you enable the aaa new-model command, as shown in this recipe, the router immediately begins to prompt for usernames and passwords. Assigning unique usernames to individuals or groups provides accountability, as we will show later. The following example shows the login prompt for a router using local authentication:

Freebsd%telnet Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.

User Access Verification

Username: ijbrown
Password: <password>

Router1>

The router prompts for the username as well as the password. Compare this to how the router behaves by default:

Freebsd%telnet Router2
Trying 172.25.1.6...
Connected to Router2.
Escape character is '^]'.

User Access Verification

Password: <password>

Router2>

Locally administered usernames work well in a small environment with a limited number of administrators. However, this method does not scale well to a large network with many administrators. Keeping usernames synchronized across an entire network can become quite daunting. Fortunately, Cisco also supports a centralized authentication system, which we discuss in Chapter 4.

When you configure locally administered usernames, the router prompts for user-names on all lines, including the console and AUX ports, as well as the VTY ports used for Telnet sessions. To avoid locking yourself out of the router, you should always configure a username command before entering the AAA commands. It is also a good idea to use another session terminal to test the new authentication system before logging out of your original session. If you do accidentally lock yourself out of the router, you will need to follow the normal password-recovery procedures for your router type.

Enabling username support causes the router to associate certain functions with usernames. This provides accountability for each username by showing exactly who is doing what. For instance, the output of the show users command includes active usernames:

Router1>show users
  Line       User       Host(s)        Idle      Location
  66 vty 0     ijbrown    idle         00:36:21  freebsd.oreilly.com
  67 vty 1     ikdooley   idle         00:00:24  server1.oreilly.com
* 68 vty 2     weak       idle         00:00:00  freebsd.oreilly.com

  Interface      User        Mode              Idle     Peer Address

Router1>

More importantly, log messages will capture the username of the individual who invoked certain high-profile commands such as configuration changes, the clearing of counters, and reloads. For example:

Jun 27 12:58:26: %SYS-5-CONFIG_I: Configured from console by ijbrown on vty2
 (172.25.1.1)
Jun 27 13:02:22: %CLEAR-5-COUNTERS: Clear counter on all interfaces by weak on vty2
 (172.25.1.1)
Jun 27 14:00:14: %SYS-5-RELOAD: Reload requested by kdooley on vty0
 (172.25.1.1).

Note that these log messages now include the username associated with each action. So, instead of just knowing that somebody changed the configuration or reloaded the router, you can see exactly who did it.

In addition, the router captures the username of the last person to modify its configuration or save the configuration to NVRAM. To see this information, use the show running-config command:

Router1#show running-config
Building configuration...

Current configuration : 4285 bytes
!
! Last configuration change at 12:58:26 EDT Fri Jun 27 2003 by ijbrown
! NVRAM config last updated at 13:01:45 EDT Fri Jun 27 2003 by kdooley
!
version 12.2

The username command also has an autocommand keyword, which you can use to assign an EXEC-level command to a particular username. This is useful when you want to provide limited access to a particular command while restricting access to everything else on the router. For example, you might want to set up a special username that anybody could use to run a single router command and then terminate the session:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default local
Router1(config)#aaa authorization exec default local
Router1(config)#username run nopassword noescape
Router1(config)#username run autocommand show ip interface brief
Router1(config)#end
Router1#

In this example, we defined the username run without a password and assigned it an autocommand of show ip interface brief. When you log in to the router with this username, the router will not prompt for a password. It just automatically executes the command and then terminates the session:

Freebsd% telnet Router1
Trying 172.22.1.4...
Connected to Router1.
Escape character is '^]'.

User Access Verification
Username: run
Interface                  IP-Address    OK? Method Status                Protocol
BRI0/0                     unassigned    YES NVRAM  administratively down down
Ethernet0/0                172.25.1.8    YES NVRAM  administratively down down
BRI0/0:1                   unassigned    YES unset  administratively down down
BRI0/0:2                   unassigned    YES unset  administratively down down
FastEthernet1/0            172.22.1.4    YES NVRAM  up                    up
Loopback0                  192.168.20.1  YES NVRAM  up                    up
Connection closed by foreign host.
Freebsd%

Note that the router issued the command and then terminated the session without providing an opportunity to issue another command.

The noescape keyword prevents the user from issuing an escape sequence to access the router EXEC. We strongly recommend using this keyword whenever you use autocommands.

Recipe 3.2; Recipe 3.4; Recipe 3.19; Recipe 3.22; Chapter 4

You want to encrypt passwords so that they do not appear in plain-text in the router configuration file.

To enable password encryption on a router, use the service password-encryption configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#enable password oreilly
Router1(config)#line vty 0 4
Router1(config-line)#password cookbook
Router1(config-line)#line con 0
Router1(config-line)#password cookbook
Router1(config-line)#line aux 0
Router1(config-line)#password cookbook
Router1(config-line)#exit
Router1(config)#service password-encryption
Router1(config)#end
Router1#

This command uses a weak, reversible encryption method to encipher VTY and enable passwords. See Recipe 3.5 for more details.

By default, the router stores all passwords in clear-text and presents them in a human-readable format when you look at the router’s configuration. The service password-encryption command encrypts the passwords using the Vigenere encryption algorithm. Unfortunately, as we illustrate in Recipe 3.5, the Vigenere encryption method is cryptographically weak and trivial to reverse.

However, this functionality is still quite useful to prevent nosy neighbors from viewing passwords over your shoulder. As such, encrypting your passwords is still highly recommended in spite of the known weaknesses. You should be aware of the inherent weaknesses of this encryption scheme when storing or forwarding router configuration files though. Recipe 3.4 provides a small utility to strip your router configuration files of all passwords (encrypted or not) to keep stored and forwarded configuration files safe from prying eyes.

A configuration file with password encryption enabled looks like this:

Router1#show running-config
Building configuration...

Current configuration : 4385 bytes
!
! Last configuration change at 13:08:35 EDT Thu Jun 27 2002 by weak
! NVRAM config last updated at 13:01:45 EDT Thu Jun 27 2002 by kdooley
!
version 12.2
service password-encryption

!
hostname Router
!
enable password 7 06091D2445420500
!
username ijbrown password 7 045802150C2E
username kdooley password 7 070C285F4D06
!
line con 0
 password 7 0605002E474C06160E
line aux 0
 password 7 151104030F28242B23
line vty 0 4
 password 7 110A160A1C1004030F
 !
end

Note that the router now encrypts all passwords and no longer displays them in a human-readable format.

Recipe 3.3; Recipe 3.4; Recipe 3.5

You want to assign a privileged password using a stronger encryption standard than Cisco’s trivial default encryption.

To enable strong, nonreversible encryption of the privileged password, use the enable secret configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#enable secret ORAbooks
Router1(config)#end
Router1#

Cisco introduced enable secret to improve the security of the enable password command. This command uses the cryptographically strong MD5 algorithm to encrypt passwords. There are no known methods for reversing this algorithm. When you configure the router with an enable secret password, it encrypts your enable password whether you have the service password-encryption command or not. The service password-encryption command has no effect on the enable secret password.

Configuring a nonreversible enable password provides greater security than the traditional enable password command. It is useful in environments that store or transfer configuration files across the network. The enable secret password takes precedence over the enable password—if you have both types of enable passwords configured, the router uses only the secret version. We highly recommend using the enable secret password on all routers.

The following command shows what the enable secret command looks like in the router’s configuration file:

Router1#show running-config | include secret
enable secret 5 $1$Ahxf$4OivEQn0n0JneSObfRdSw0
Router1#

The following is a list of enable secret password restrictions:

You should never use the same password for the enable password and enable secret commands. The router warns you against doing this, but will accept it:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#enable password cisco
Router1(config)#enable secret cisco
The enable secret you have chosen is the same as your enable password.
This is not recommended.  Re-enter the enable secret.

Router1(config)#end
Router1#

Setting the same password for both commands defeats the purpose of using the enable secret command in the first place by rendering its strong encryption useless. Avoid this problem by choosing a different password or removing the enable password altogether.

Recipe 3.4; Recipe 3.22

You want to remove sensitive information from a router configuration file.

The following Perl script removes sensitive information such as passwords and SNMP community strings from configuration files. The script takes the name of the file containing the router’s configuration as its only command-line argument.

Here’s some example output:

Freebsd% strip.pl Router1-confg

version 12.2
service password-encryption
!
hostname Router1
!
aaa new-model
aaa authentication login default local
enable secret <removed>
enable password <removed>
!
username ijbrown password <removed>
username kdooley password <removed>
!
!Lines removed for brevity
!
!
snmp-server community <removed> RO
snmp-server community <removed> RW
!
line con 0
 password <removed>
line aux 0
 password <removed>
line vty 0 4
 password <removed>
 end
Freebsd%

Example 3-1 contains the Perl script.

#!/usr/local/bin/perl
#
#       strip.pl   -- a script to remove sensitive information
#                     from a router configuration file.
#
#
my $configf;
undef $/;
#
$configf = shift(@ARGV);
if (open (CNFG, $configf ) ){
          $config=<CNFG>;
          close (CNFG);
          $config =~ s/password .*/password <removed>/gi;
          $config =~ s/secret .*/secret <removed>/gi;
          $config =~ s/community [^ ]+/community <removed>/gi;
          print $config;
} else {
        print STDERR "Failed to open config file "$configf"
";
        }

This script strips sensitive information from router configuration files. You can safely store or forward the resulting “stripped” configuration files to others, including vendors, partners, or colleagues. Recipe 3.5 shows how trivial the default password-encryption method is, which highlights why stripping a configuration file like this is so important.

This script should require no modifications to work in most environments. Because the script sends its output to the screen, you will have to direct the standard output into a file if you want to save a copy of the “stripped” configuration file:

Freebsd% strip.pl Router1-confg > /tmp/Router1-stripped

This example runs the script and sends the output to a file called Router1-stripped in the directory /. Of course, you can direct the output of the script to any file you wish.

In earlier recipes, we mentioned that the enable secret password was encrypted using a strong method, MD5, and that no known method of reversing it exists. However, you may still be vulnerable to brute force attacks in which an attacker systematically encrypts likely sequences of letters, numbers, and characters in an attempt to find an encrypted match. Although these types of attacks are time-consuming, there are a number of freely available software packages that offer efficient password cracking capabilities. In short, it is better to be safe than sorry.

You can easily modify the script to strip other sensitive configuration commands (such as TACACS keys, routing keys, etc.) by simply adding more substitution lines. For instance, to strip TACACS keys, add the following line of code near the other lines that begin with $config =~:

$config =~ s/tacacs-server key .*/tacacs-server key <removed>/gi;

Recipe 3.2; Recipe 3.3; Recipe 3.5

You want to reverse the weak Cisco password encryption algorithm to recover forgotten passwords.

To recover a lost router password from a configuration file, use the following Perl script to decipher weakly encrypted passwords. This script expects to read router configuration commands via STDIN. It then prints the same commands to standard STDOUT with the passwords decrypted.

Here is an example of the program’s output:

Freebsd% cpwcrk.pl < Router1-confg

version 12.2

service password-encryption
!
hostname Router1
!
enable secret 5 $1$4y6Q$bcGReJ3kGgmlpfr7/lT64.
enable password 7 06150E2F4A5C0817 (decrypted: sanfran)
!
username ijbrown password 7 121A0C041104 (decrypted: cisco)
username kdooley password 7 1306181D000E0B2520 (decrypted: cookbook)
!
<Lines removed for brevity>
!
line con 0
 password 7 06120A22445E1E1D (decrypted: techpwd)
line aux 0
 password 7 0212015803161825 (decrypted: techpwd)
line vty 0 4
 password 7 070033494705151C (decrypted: oreilly)
 login
!
end

Example 3-2 contains the Perl script.

#!/usr/local/bin/perl
#
#  cpwcrk.pl  -- a small script to crack Cisco's Type 7 password
#                encryption
#
#
$k='dsfd;kfoA,.iyewrkldJKDHSUB';
for($i=0; $i<length($k); $i++) { $ks[$i] = ord(substr($k, $i, 1)); }

while (<STDIN>) {
   if(/ord 7 [01]/) {
      chop; $w=$_; s/.* //g; $C = $_;
      printf "$w (decrypted: ";

      $o=substr($C, 0, 2);
      for ($i=0; $i < (length($C)-1)/2; $i++) { $cs[$i]=hex(substr($C,2*$i,2)); }

      for ($j=1; $j < $i; $j++) { printf("%c", $ks[$o+$j-1] ^ $cs[$j]); }
      printf ")
";
   } else {
     printf $_;
   }
}

Note that this script will not decrypt enable secret passwords, because they are encrypted using strong MD5 encryption.

This little Perl script is deliberately written to be small and fast, which, unfortunately, makes it somewhat difficult to read. Here’s a brief explanation of how it works.

The first thing it does is to take the standard key string, “$k”, and translate it into an array of hexadecimal numbers, “$ks”, to make it easier to work with. Then it reads the input configuration file one line at a time, looking for any lines including “password 7”. To make the search slightly quicker, the script looks only for the string “ord 7”, followed by a space and either the number 0 or 1. It stores the encrypted password string in the variable “$C”.

The first two characters in the encrypted string are used for an offset, so the script stores them in the string “$o”. It then goes through the crypt string, two characters at a time, and converts the result into hexadecimal numbers, which it stores in the array “$cs”.

The script then does all of the actual decryption work in a loop that simply calculates an XOR (exclusive OR) operation between the offset original key and the elements of the “$cs” array.

The encryption algorithm is nothing more than a bitwise XOR between the password string and a known key offset by a random amount. This random offset is encoded into the first two characters of the result, so it is easy to uniquely reverse the cipher.

Cisco chose to use such a simple algorithm because the router must be able to uniquely decrypt passwords for some applications, such as CHAP authentication. This is different from most password applications in which the device can take an incoming password string, encrypt it with a one-way algorithm, and compare the resulting encrypted version with the encrypted version of the locally stored password. In those applications, it is sufficient to work only with the encrypted versions of the passwords.

Recipe 3.2; Recipe 3.3; Recipe 3.4

You want to find out who else is logged into a router.

To see which users are currently logged into the router and on which line, use the show users EXEC command:

Router1#show users

Use the keyword all to view all lines, including those that are inactive:

Router1#show users all

The EXEC command who gives the same output as the show users command:

Router1#who

To remotely view which users are logged into a router, use the finger command from your management server:

Freebsd% finger @Router1

This last command works only if the finger service is enabled on the router.

The router provides a number of different methods to view active users. The output from all of these commands is nearly identical. Many administrators like to know which users are accessing the router for security purposes, operational reasons, or just out of curiosity.

The format of the output is as follows: the absolute line number, the VTY line number, the username, a listing of connected hosts, the inactivity timer, and the source address of the session. Note that one line of the output has an asterisk (*) in the left margin, indicating your current session.

The show users command displays the current active users and their associated line information:

Router1#show users
    Line       User        Host(s)         Idle      Location
    66 vty 0   ijbrown     idle            00:56:15  freebsd.oreilly.com
    67 vty 1   kdooley     idle            00:17:52  freebsd.oreilly.com
 *  68 vty 2   weak        idle            00:00:00  freebsd.oreilly.com
    Interface  User        Mode            Idle      Peer Address

Router1#

If you add the keyword all to this command, the router displays all of its lines, active and inactive:

Router1#show users all
    Line      User         Host(s)        Idle       Location
    0 con 0                               00:00:00
    65 aux 0                              00:00:00
    66 vty 0  ijbrown      idle           00:56:24   freebsd.oreilly.com
    67 vty 1  kdooley      idle           00:18:01   freebsd.oreilly.com
  * 68 vty 2  weak         idle           00:00:00   freebsd.oreilly.com
    69 vty 3                              00:00:00
    70 vty 4                              00:00:00

 Interface    User         Mode           Idle       Peer Address

Router1#

The who command is named after the popular Unix program, which displays active users. The router’s version of who displays exactly the same information as the show users command:

Router1#who
    Line      User      Host(s)        Idle       Location
    66 vty 0  ijbrown   idle           00:56:58   freebsd.oreilly.com
    67 vty 1  kdooley   idle           00:18:36   freebsd.oreilly.com
  * 68 vty 2  weak      idle           00:00:00   freebsd.oreilly.com

  Interface   User      Mode           Idle       Peer Address

Router1#

The finger command is another popular Unix program that displays the active users of a remote system using a simple open IP’based protocol. The router responds to any finger request with output similar to that of the show users command. In the following example, we use finger from a Unix server to see which users are logged into a particular router:

Freebsd% finger @Router1
[Router1]

    Line      User     Host(s)        Idle       Location
  * 66 vty 0           idle           00:00:00   freebsd.oreilly.com
    67 vty 1  ijbrown  idle           00:01:48   freebsd.oreilly.com
    69 vty 3  ijbrown  idle           00:59:04   freebsd.oreilly.com

   Interface  User     Mode           Idle       Peer Address
Freebsd%

Notice that we were able to remotely extract the active user list without even logging into the router. For security purposes, we recommend that you disable the finger service to prevent illegitimate use of the protocol. For example, somebody could use this command to discover a valid username as well as a remote workstation that is allowed to log into the router. This can be a dangerous amount of information to give away freely.

You can disable the finger service on a router with the following configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#no ip finger
Router1(config)#end
Router1#

Recipe 2.6; Recipe 3.1; Recipe 3.7; Chapter 4

You want to send a message to another user logged into the same router.

To send a text message to all active users logged into a router, use the send EXEC command. You must have administrator privileges to use this command:

Router1#send *

To send a private message to a user logged onto a specific line, use the send command with the line number:

Router1#send 66

To send a private message to a user on the AUX port:

Router1#send aux 0

To send a private message to a user on the console port:

Router1#send console 0

To send a private message to a user on a specific VTY port:

Router1#send vty 2

Sending messages to other users on a router is quite useful. You might want to use this ability to warn other users that you are about to reload or make changes to the router. This is a particularly valuable feature when remote users are located in different geographical areas. You can exchange messages with other users immediately without having to track down individuals via phone, pager, or cell phone.

We often use this feature while troubleshooting network problems. It is particularly useful for communicating with an onsite technician connected to the router’s console, especially if you have no other means to reach them. This is a great way to coordinate everybody’s efforts when there are no telephones near the router, and cell phones won’t work in an electrically noisy equipment room.

To view all of the active users on the router, use the show users EXEC command:

Router1#show users
    Line       User       Host(s)        Idle       Location
    66 vty 0   ijbrown    idle           01:08:46   freebsd.oreilly.com
    67 vty 1   kdooley    idle           00:05:34   freebsd.oreilly.com
  * 68 vty 2   weak       idle           00:00:00   freebsd.oreilly.com

    Interface  User       Mode           Idle       Peer Address

Router1#

In this example, we send a message to user kdooley, who is connected to VTY1:

Router1#send vty 1
Enter message, end with CTRL/Z; abort with CTRL/C:
Kev,

I need to reload this router to clear a fragmented memory problem.
Please save your work and log off, ASAP...  Thanks

IJ
^Z
Send message? [confirm]
Router1#

Once you submit the send command, the router enters a text editor mode. At this point, you can enter any text. To exit the text editor mode, type Ctrl-Z. The router then prompts you for a confirmation and, if you confirm, it sends a message that might look something like this:

Router1#

***
***
*** Message from tty68 to tty67:
***
Kev,

I need to reload this router to clear a fragmented memory problem.
Please save your work and log off, ASAP...

IJ
Router1#

Recipe 3.6

You want to increase or decrease the number of users who can simultaneously telnet to the router.

If you want to increase the number of VTY ports available on the router for remote access, you just need to create a reference to the additional lines in the configuration as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 9
Router1(config-line)#end
Router1#

This command defines the characteristics for a range of VTY ports from 0 to 9. Since ports 0 to 4 exist by default, this has the effect of creating ports 5 through 9.

By default, most Cisco routers provide five VTYs for remote access. However, the default number of VTYs is often insufficient, and increasing the number can be quite useful. This is particularly true in lab or training environments that require a large number of concurrent sessions on a particular router. In addition, organizations that disable EXEC timeouts (as shown in Recipe 3.9) often require a larger number of VTYs to prevent locking administrators out of their routers.

The router can support up to 181 virtual terminals. However, it is extremely rare to actually need more than about 20. Keep in mind that additional virtual terminals will utilize system resources, so don’t go overboard. You must explicitly configure all of the new VTY lines with passwords, access classes, EXEC timeouts, transport protocols, and so forth.

To view the newly created VTY terminals, use the show users all EXEC command:

Router1#show users all
    Line       User      Host(s)      Idle       Location
   0 con 0                          00:00:00
  65 aux 0                          00:00:00
  66 vty 0     ijbrown   idle         01:15:29 freebsd.oreilly.com
  67 vty 1     kdooley   idle         00:12:17 freebsd.oreilly.com
* 68 vty 2     weak      idle         00:00:00 freebsd.oreilly.com
  69 vty 3                          00:00:00
  70 vty 4                          00:00:00
  71 vty 5                          00:00:00
  72 vty 6                          00:00:00
  73 vty 7                          00:00:00
  74 vty 8                          00:00:00
  75 vty 9                          00:00:00

  Interface     User       Mode            Idle     Peer Address

Router1#

Five new VTY lines are now available on this router (ports 5 through 9).

To remove the newly created VTY lines, use the no version of the command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#no line vty 5
Router1(config)#end
Router1#show users all
    Line       User       Host(s)         Idle       Location
   0 con 0                                00:00:00
  65 aux 0                                00:00:00
* 66 vty 0     ijbrown    idle            00:00:00 freebsd.oreilly.com
  67 vty 1                                00:00:00
  68 vty 2                                00:00:00
  69 vty 3                                00:00:00
  70 vty 4                                00:00:00

  Interface       User       Mode                Idle     Peer Address

Router1#

You cannot create or delete VTY lines out of order. Adding VTY line 20 automatically creates lines numbered from 5 to 20. Similarly, removing VTY line 5 implicitly removes all lines above line 5 (as illustrated in the previous example).

The router will not allow you to remove the original five virtual terminals. If you do attempt to delete them, the router produces the following warning message:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#no line vty 4
% Can't delete last 5 VTY lines
Router1(config)#end
Router1#

Recipe 3.9; Recipe 3.10; Recipe 3.16

You want to prevent your Telnet session from timing out.

To prevent Telnet (or SSH) sessions from timing out, use the following command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#exec-timeout 0 0
Router1(config-line)#end
Router1#

You can use this same command to simply increase the EXEC timeout to a large value, such as 4 hours:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#exec-timeout 240 0
Router1(config-line)#end
Router1#

By default, the router terminates an EXEC session after 10 minutes of inactivity. Administrators often find that 10 minute inactivity timers are a nuisance and dislike having to log into a router several times throughout the day. So Cisco provides a way to modify or disable the inactivity timer. It is important to note that this affects only timeouts due to inactivity. In Recipe 3.11 we discuss a way to disconnect sessions after a specified length of time, whether they are active or not.

The exec-timeout command has two arguments:

Router1(config-line)#exec-timeout 240 0

The first argument is the length of time in minutes, and the second argument is time in seconds. This allows you to specify a timeout period as short as 1 second, or as long as 35,791 minutes (which is over 24 days).

The first example shows how to disable the inactivity timer altogether, by setting the timeout values to zero. There are a few drawbacks to disabling the EXEC timeout that you should bear in mind. First, since the router only provides five VTYs for remote access by default, forgotten sessions can easily block available VTYs until service is completely blocked. Second, sessions that do not terminate correctly (for example, when a workstation crashes) can cause VTY sessions to remain active indefinitely.

To prevent dead sessions from needlessly occupying VTY ports, use the service tcpkeepalives configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#service tcp-keepalives-in
Router1(config)#end
Router1#

TCP keepalives will ensure that the far end is up and active. Otherwise, it will terminate the session regardless of the inactivity timer. We strongly recommend using the TCP keepalive command if you choose to disable the inactivity timer.

You can see your current session’s inactivity timer with the show terminal EXEC command:

Router1#show terminal
Line 68, Location: "", Type: "VT100"
Length: 43 lines, Width: 95 columns
Baud rate (TX/RX) is 9600/9600
Status: PSI Enabled, Ready, Active, No Exit Banner, Automore On
Capabilities: none
Modem state: Ready
Group codes:    0
Special Chars: Escape  Hold  Stop  Start  Disconnect  Activation
                ^^x    none   -     -     none
Timeouts:      Idle EXEC     Idle Session   Modem Answer  Session Dispatch
               never        never                         none    not set

The second example sets the inactivity timer to 4 hours. This tends to be safer than completely disabling the timer because it will eventually terminate all sessions. However, please check your local security policies to ensure that your inactivity timers are set within your organizational guidelines. Many organizations mandate a 15-minute inactivity timer for all types of electronic access to ensure that you do not leave authenticated sessions available to intruders. The NSA recommends an inactivity timer of no more than 5 minutes.

Recipe 3.11; Recipe 3.14

You want to restrict what protocols can be used to access the router’s VTY ports.

To restrict what protocols that you can use to access the router’s VTY ports, use the transport input configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#transport input telnet
Router1(config-line)#end
Router1#

Most administrators do not realize that, by default, Cisco routers allow VTY access via protocols other than Telnet. In some instances, intruders can bypass security measures that you have in place for Telnet and access your VTYs directly. To be safe, we recommend disabling all unused protocols from accessing your VTYs. This prevents unauthorized VTY access through one of these other protocols.

Our example shows how to restrict VTY access to Telnet only. Of course, your organization may require the inclusion of other protocols, such as SSH. Recipe 3.20 discusses how to enable the SSH protocol and prevent all other forms of nonsecure access.

Table 3-1 lists the valid protocols supported by Cisco router VTYs.

Use the show terminal EXEC command to view the permitted protocol types for the active line. A router with the default configuration returns a long list of allowed protocols:

Router1#show terminal | include input
Allowed input transports are lat pad v120 lapb-ta telnet rlogin ssh.
Router1#

After we restrict the VTY access to Telnet only, the output looks like this:

Router1#show terminal | include input
Allowed input transports are telnet.
Router1#

Recipe 3.9; Recipe 3.14; Recipe 3.16

You want to enable absolute timeouts on your VTY lines.

To enable absolute VTY timeouts, use the following set of configuration commands:

Router1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#absolute-timeout 5
Router1(config-line)#logout-warning 30
Router1(config-line)#end
Router1#

To prevent users from indefinitely tying up valuable router VTY lines, you can implement absolute timers. Absolute timers differ from the inactivity timers discussed in Recipe 3.9 because they will terminate a session whether it is active or not. Although absolute timers are rarely enabled, there are times when they can be quite useful. For example, in classroom and lab situations, the absolute timeout can help to ensure that nobody uses more than their fair share of login time.

The prospect of having a session terminated in the middle of troubleshooting a problem in a production network is not appealing to most administrators. So, if you do choose to implement an absolute timer, we recommend setting the timer to a reasonable amount of time (no less than 10 minutes). In addition, you should enable a logout warning to ensure that the user has plenty of notice to save their work. The following is an example of a logout warning banner:

Router1>
*
*
* Line timeout expired
*
*
Router1>Connection closed by foreign host.
Freebsd%

Note that the argument for the absolute-timeout command is a time value in minutes whereas the logout-warning command uses seconds. In the example, we set the absolute timeout to 5 minutes and the warning message to 30 seconds. A 30-second warning may be too aggressive in a production environment.

Recipe 3.9

You want to implement a banner message to display a security warning.

The following commands configure various types of banners on a router:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#banner exec  # This is an exec banner #
Router1(config)#banner login # This is a login banner #
Router1(config)#banner motd  $ This is a motd banner $
Router1(config)#end
Router1#

Note that the router will accept almost any delimiter character as long as the start and end delimiters are identical. These delimiters allow you to make your banner message several lines long. Our first two examples use the pound symbol (#), while the last example uses the dollar sign ($) as a delimiter. Be careful—if the delimiter character appears within the banner message itself, the router will only accept part of the message.

Cisco routers support three main types of banners and display them in a strict order. The message of the day (motd) is followed by the login banner before the login prompt, and the router prints the EXEC banner after a successful authentication:

Freebsd% telnet Router1
Trying 172.22.1.4...
Connected to Router1.
Escape character is '^]'.
 This is a motd banner
 This is a login banner

User Access Verification

Username: ijbrown
Password: <xxxxxxxxx>
 This is an exec banner
Router1>

Login banners are mainly used to display a warning message for security purposes; we will discuss this in a moment. The motd banner derives from the Unix banner bearing the same name. The motd banner is of little use in production environments and is rarely required. The EXEC banner, on the other hand, is useful for displaying administrator messages because it is only presented to authenticated users (much like the Unix motd banner).

Banners are an important and often overlooked part of a good security policy. Although a banner alone will not repel the crafty hacker, it provides a certain level of legal protection. In fact, a well-designed warning message may indeed repel a would-be hacker: the mere threat of legal action can be a wonderful deterrent. If unauthorized users suspect that your organization is serious about legal action, they are less likely to target your devices. We highly recommend implementing login banners on all production routers.

A good login banner should meet the following objectives:

Login banners can simplify the prosecution of hackers who unlawfully access your system by explicitly notifying unauthorized users that their actions are indeed unauthorized. Think of the banner as the electronic equivalent of a sign saying, “trespassers will be prosecuted.” Without this sign, somebody could theoretically claim that they didn’t know it was a private system. It may not hold up in court, but why take the risk? Laws governing legal notification vary significantly between jurisdictions and situational purpose. We recommend that you clear all proposed banners with your legal department before implementation.

The following banner message show a particularly well-written legal notice that meets all of requirements mentioned earlier. The FBI’s Atlanta computer crime squad provided this example banner. Again, please check with your local authorities before creating a warning banner to ensure that it meets your local legal requirements:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#banner login #
Enter TEXT message.  End with the character '#'.
+--------------------------------------------------------------------+
|                              WARNING                               |
|                              -------                               |
| This system is solely for the use of authorized users for official |
| purposes.  You have no expectation of privacy in its use and to    |
| ensure that the system is functioning properly, individuals using  |
| this computer system are subject to having all of their activities |
| monitored and recorded by system personnel. Use of this system     |
| evidences an express consent to such monitoring and agreement that |
| if such monitoring reveals evidence of possible abuse or criminal  |
| activity, system personnel may provide the results of such         |
| monitoring to appropriate officials.                               |
+--------------------------------------------------------------------+
#
Router1(config)#end
Router1#

Starting with Version 12.0(3)T of IOS, Cisco routers began to support banner token functionality. Tokens are variables (listed in Table 3-2) that are embedded within a banner message and serve as substitutes for things such as hostnames and domain names.

Tokens allow you to distribute a single banner message throughout your network by using variable substitution to make it look slightly different on each device. This ensures that any local differences in the information are always accurate. The banner message can dynamically adapt to changes in hostname or line number, for instance.

Although all banner types support tokens, we recommend using them only in EXEC banners. Since tokens surrender information about the router, it is inappropriate to use them within login or motd banners, which are visible before the user supplies a valid username or password. EXEC banners, on the other hand, are visible only to authenticated users. The following example shows how to configure an EXEC banner with tokens:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#banner exec #
Enter TEXT message.  End with the character '#'.
Welcome, you have connected to router $(hostname).$(domain):
on line $(line) ($(line-desc)).
#
Router1(config)#line vty 0 4
Router1(config-line)#location 999 Queen Street West
Router1(config)#end
Router1#exit
Connection closed by foreign host.
Freebsd% telnet Router1
Trying 172.25.1.7...
Connected to Router1.
Escape character is '^]'.


User Access Verification

Password: <vtypassword>
Welcome, you have connected to router Router1.oreilly.com:
on line 5 (999 Queen Street West).

Router1>

Note that the router substitutes the appropriate router information where the tokens were. For example, it replaces the hostname token, $(hostname), with the hostname, Router1. The domain token, $(domain), is derived from the ip domain-name command. The line token, $(line), is replaced with the active line number. Finally, the line description token, $(line-desc), is derived from the information configured with the location command for this line.

Recipe 3.13

You want to disable the banner on a particular port to prevent it from confusing an attached device such as a modem.

To disable banners on particular lines, use the following commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line aux 0
Router1(config-line)#no motd-banner
Router1(config-line)#no exec-banner
Router1(config-line)#end
Router1#

By default, the router displays the configured banner messages on all of its lines. However, there are circumstances when these banner messages can confuse directly attached devices. For instance, modems connected to terminal server or AUX lines can react erratically to banner messages (particularly motd and login banners). In these situations, you will need to disable the banner on the associated line.

Note that you cannot disable the login banner on a line-by-line basis. So, if you find that you need to do this, you should use the motd banner instead of the login banner to display the warning message. The motd and the login banners are nearly identical, so this shouldn’t cause any problems.

Recipe 3.12

You want to disable your router’s AUX port to help prevent unauthorized access.

To completely disable access via the router’s AUX port, use the following set of commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line aux 0
Router1(config-line)#transport input none
Router1(config-line)#no exec
Router1(config-line)#exec-timeout 0 1
Router1(config-line)#no password
Router1(config-line)#end
Router1#

You can also disable access to the router through the VTY lines:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 98 deny any log
Router1(config)#line vty 0 4
Router1(config-line)#transport input none
Router1(config-line)#exec-timeout 0 1
Router1(config-line)#no exec
Router1(config-line)#access-class 98 in
Router1(config-line)#end
Router1#

It is extremely important to secure access to your routers. The most effective way to secure router ports is to simply disable them if they aren’t needed. For instance, network administrators rarely use the router’s AUX port, so they should consider disabling it. If your routers are physically close to the administrators and remote access is not necessary, you might even want to disable the VTY ports to provide greater security.

Our first example shows a somewhat paranoid method of disabling a router’s AUX port. We say paranoid because it involves using several different techniques, each of which should be sufficient alone, strung together for added protection. The transport input none command prevents reverse Telnet access from the network (see Recipe 3.10). The no exec command prevents the AUX port from running an EXEC session. Without an EXEC process, no response is given when you connect a terminal to the port. The exec-timeout command sets the EXEC timeout to one second (see Recipe 3.9). This effectively limits the ability to submit commands, just in case an attacker somehow manages to start an EXEC process. Finally, the no password clears the line password, so there is no way to authenticate if somebody is able to connect.

The way we disable the VTY ports is also paranoid but effective. The example we gave illustrates several different methods to disable connectivity. In reality, any one of these methods would work, but we recommend including at least one secondary method as a safety measure. It is important to note that these extra precautions don’t cost anything. They don’t increase the router’s CPU load or memory consumption appreciably. So, for the extra level of safety, you might as well string together several methods as we have shown.

To disable the VTY interfaces we first set the transport input to none (see Recipe 3.10) to disable all inbound transport methods. We also set the exec-timeout to one second (see Recipe 3.9). We then disable the EXEC process on this line, rendering the VTY port useless. Finally, we implement an input access-class that prevents all IP addresses from accessing the VTY ports (see Recipe 3.16).

If you try to connect to a VTY line that is disabled (as shown in this recipe), the router refuses the connection:

Freebsd% telnet Router1
Trying 172.22.1.4...
telnet: connect to address 172.22.1.4: Connection refused
telnet: Unable to connect to remote host
Freebsd%

The console port is the most important access line your router has. It is the last place you can still connect to when everything else goes wrong, so we do not recommend disabling it. However, we do recommend increasing the security of your console port to provide maximum protection. By default, the console port will not prompt for a login or password. This means that unauthorized users can easily gain access to your router’s EXEC without effort. Of course, the router is always vulnerable to console access via the password recovery process, which highlights why physical security is important. You should always house routers in restricted rooms or closets to ensure physical security.

To increase the security of a router’s console port, use the following set of configuration commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line con 0
Router1(config-line)#exec-timeout 5 0
Router1(config-line)#password ora22bkz
Router1(config-line)#login
Router1(config-line)#end
Router1#

This example enables a login prompt by configuring the login and password commands, and reduces the exec-timeout to five minutes to ensure that console sessions will disconnect themselves if somebody walks away from the terminal. Note however that login and password commands become unnecessary if you configure your router to use local authentication or AAA. The stronger authentication method overrides the configurations of all of the lines, including those of the console port.

Recipe 3.1; Recipe 3.9; Recipe 3.10; Recipe 3.16; Chapter 4

You want to prevent other people from using up all of your VTY lines, effectively locking you out of the router.

You can ensure that at least one VTY port is available to you for access at all times with the following commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 9 permit 172.25.1.1
Router1(config)#line vty 4
Router1(config-line)#access-class 9 in
Router1(config-line)#end
Router1#

Receiving the dreaded “Connection refused” message from one of your routers can be quite distressing, particularly if you’re trying to troubleshoot a serious problem. Generally, it means that other sessions have control of all of your router’s limited number of VTY lines. However, it can also mean that someone has launched a Denial of Service (DoS) attack. DoS attacks against router VTYs are simple to launch. Just sitting at a login prompt is enough to tie up a VTY line. This means that you don’t need a username or a password to use up all of the VTY lines, thus locking out all of the legitimate administrators.

Whether the lockout is caused by legitimate sessions or not, this is what it looks like:

Freebsd% telnet Router1
Trying 172.22.1.4...
telnet: connect to address 172.22.1.4: Connection refused
telnet: Unable to connect to remote host
Freebsd%

You can implement a safeguard to ensure that this never happens. Enabling a restrictive access class on the last accessible VTY ensures that the administrator will retain access at all times. The key is to ensure that your access list is as restrictive as possible (i.e., an administrator’s IP address).To view the VTY access statistics, use the show line command:

Router1#show line vty 0 4
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*   66 VTY              -    -      -    -    -     10       0     0/0       -
*   67 VTY              -    -      -    -    -     10       0     0/0       -
*   68 VTY              -    -      -    -    -      2       0     0/0       -
*   69 VTY              -    -      -    -    -      1       0     0/0       -
*   70 VTY              -    -      -    -    9      1       0     0/0       -

Router1#

Note that access class 9 was assigned to the last VTY session (the “AccI” column) and has been accessed only once (“Uses”).

Recipe 3.16; Recipe 3.17

You want to restrict Telnet access to the router to allow only particular workstations.

You can restrict which IP addresses can access the router:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 99 permit 172.25.1.0 0.0.0.255
Router1(config)#access-list 99 deny any log
Router1(config)#line vty 0 4
Router1(config-line)#access-class 99 in
Router1(config-line)#end
Router1#

This example uses a standard access-list command. You can also use extended access lists in an access-class statement. But, because you already know the TCP port numbers, as well as the destination IP addresses, extended access lists don’t provide much extra functionality.

Telnet is an inherently insecure protocol because it sends passwords over the network in clear-text. We highly recommend using access-class statements to help ensure that only authorized users can access router VTYs. These access-class statements do not secure the Telnet protocol itself, but they will help to prevent unauthorized users from receiving a router login prompt. Even if someone manages to sniff your router passwords, this will make them virtually useless.

For increased security, limit the permitted hosts to a few network management servers. This will force legitimate users to follow a two-stage authentication process to access your routers. They will need to authenticate their session on a central device such as the network management server before they can log into the router. The logic is that it is much easier to secure a single server than a dozen workstations.

This feature provides a similar functionality to the Unix TCPWrapper tool set, which can restrict daemon access to a limited number of IP addresses. And, just like TCPWrapper, we can log the IP addresses of refused users by using the keyword log in the access list definition. This creates a log message for every unauthorized Telnet attempt, such as the following:

Router1#show logging | include list 99
Jun 27 14:14:25: %SEC-6-IPACCESSLOGS: list 99 denied 172.22.1.3 1 packet
Router1#

In the example, we have added an explicit deny any command to allow the router to count refused sessions:

Router1#show access-lists 99
Standard IP access list 99
    permit 172.25.1.0, wildcard bits 0.0.0.255 (4 matches)
    deny   any log (1 match)
Router1#

This command shows you the running total of permitted and refused Telnet sessions. In this example, the access list has denied a single Telnet session from accessing a router VTY. A large number of access attempts might indicate that someone is trying to access your routers without authorization. The log messages capture the IP source address of each denied attempt, making it easy to investigate.

Recipe 3.15; Recipe 3.17

You want to log every Telnet session to the router.

To log every Telnet session to the router, use the followings set of commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 90 permit any log
Router1(config)#line vty 0 4
Router1(config-line)#access-class 90 in
Router1(config-line)#end
Router1#

Keeping detailed log records of every Telnet session your router accepts can be useful for security purposes. Configuring an access class ACL to log every session causes the router to capture which IP source addresses attempt to access the Telnet port.

Note, however, that this method captures both successful and unsuccessful Telnet attempts, which is an invaluable capability.

Of course, you can combine this functionality with the other access classes that we discussed in Recipe 3.15 and Recipe 3.16. This recipe doesn’t introduce any new features; it’s just a different way to use the same commands.

To view all captured Telnet attempts, use the following EXEC command:

Router1# show logging | include list 90
Jun 27 14:44:45: %SEC-6-IPACCESSLOGS: list 90 permitted 172.25.1.1 1 packet
Router1#

Note that the logged messages will always show “permitted,” even if the session authentication was unsuccessful.

Recipe 3.15; Recipe 3.16

You want to force your router to use a particular IP source address when making outbound Telnet connections.

To configure a single common IP source address for all outbound Telnet sessions, use the following configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip telnet source-interface loopback0
Router1(config)#end
Router1#

You can also set the IP source address for individual outbound Telnet sessions on the command line:

Router1#telnet 172.25.1.5 /source-interface
 loopback0

By default, the router uses the IP address of the closest interface to the destination as the source address when it makes an outbound Telnet session. However, network administrators frequently want to use an address other than the one closest to the destination. For instance, access lists or route filters may block packets with the default source address. Selecting a particular source IP address for a Telnet session can also help in troubleshooting network problems.

Cisco provides two methods for setting the source IP address of Telnet sessions: global and session-specific. The global configuration example forces all Telnet sessions to use the IP address of the configured interface as the source address. However, if the configured interface has no IP address, or is operationally down, the router will resort to its default behavior of using the closest interface IP address.

The session-specific method allows the administrator to manually select an appropriate IP source address on a per-session basis. Again, if the configured interface has no IP address or is operationally down, the router will resort to its default behavior. Note that the individual method of setting the Telnet source address supersedes the global setting.

You want to automate the process of logging into a router, so you don’t have to type usernames, passwords, and common commands.

The following script automates the process of logging into the router using a scripting language called Expect. Expect can be used to automate interactive sessions (see Appendix A for more details). This script takes a router name or IP address as a command-line argument. It then performs an automated login sequence before returning the session back to you for a normal interactive session.

Here’s an example of the output:

Freebsd% tel Router1
spawn telnet Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.

User Access Verification

Username: ijbrown
Password:

Router1>
Router1 - vty login ok
enable
Password:
Router1#
Router1 - enable login ok

Router1#term mon
Router1#

Example 3-3 contains the Expect code.

#!/usr/local/bin/expect
#
#           tel -- a script to perform automated login onto a Cisco
#                  router using either a hostname or IP address.
#
#
# Set behaviour
set userid ijbrown
set vtypasswd oreilly
set enablepwd cookbook
#
#
set timeout 10
set rtr [lindex $argv 0]
spawn telnet $rtr
expect {
         {Username}   { send "$userid
"
                        expect {
                                  {*Password*} { send "$vtypasswd
" }
                               }
                      }
         {telnet>}    { send_user "$rtr - telnet failed
"
                       exit
                      }
         {Password}   { send "$vtypasswd
" }
       }
expect {
         {Password}   { send_user "
$rtr - vty login failed
"
                        exit
                      }
         {Username}   { send_user "
$rtr - vty login failed
"
                        exit
                      }
         {>}          { send_user "
$rtr - vty login ok
" }
      }

 send "enable
"
 expect "Password"
 send "$enablepwd
"
#
 expect {
          {*#}       { send_user "
$rtr - enable login ok
" }

          {*>}       { send_user "
$rtr - enable login failed
"
                       exit
                     }
          {Password} { send_user "
$rtr - enable login failed
"
                       exit
                    }
        }
 #
send "
"
expect "*#*"
send "term mon
"
#
interact

This script is intended to save you time when you have to repeatedly log into routers. The tel script connects to the VTY and sends the login sequence before returning the session back to you. The script can login to routers that use local usernames, AAA authentication, or the default VTY/enable passwords. You can also use it to submit router commands before returning control to the end user. Since the script can respond immediately to the various router prompts, the entire login sequence is much faster than what a human can type.

This script also notifies the user when it experiences problems in the login sequence and it displays the entire sequence so that you can follow its progress on the screen. If the script experiences a problem, it will usually terminate with an appropriate error message, if possible. It also includes a global timeout variable to ensure that problems do not hang the user session. The default global timeout is 10 seconds.

This script requires Expect to be on the server and located in the /usr/local/bin directory. You will also need to set a few variables. First, the userid variable must be set to your router username, which is either the locally administered username or your AAA username. If your router does not prompt for usernames, the script ignores this variable. Second, the variable vtypasswd must be set to the password associated with your username. If your router is not configured to use usernames, use the VTY password. Third, the variable enablepwd must be set to the router’s enable password.

You should store this script in your home directory with read, write, and execute privileges restricted to yourself. This ensures that unauthorized users cannot view your ID and password (which are stored in clear-text) or use the script to log into a device using your credentials:

 Freebsd% chmod 700 tel

The final step in the script login sequence is to submit useful commands before returning the session back to the user. This time-saving step automatically submits commands that you use regularly. By default, the script will send the terminal monitor command before terminating; however, you can easily add other commands. You can also modify the script to send a standard set of commands and then exit from the router without needing to turn over control.

The tel script has proven to be an invaluable tool during the writing of this book. We have used it literally thousands of times to save countless keystrokes in the process. Think of it as a preventative measure to avoid carpal tunnel syndrome.

Recipe 3.1; Recipe 3.3; Chapter 4

You want to use SSH to give more secure encrypted remote access to your router.

You can configure your router to run an SSH Version 1 server for VTY access:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#hostname Router1
Router1(config)#ip domain-name oreilly.com
Router1(config)#crypto key generate rsa
The name for the keys will be: Router1.oreilly.com
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.

How many bits in the modulus [512]: 1024
Generating RSA keys ...
[OK]

Router1(config)#
Jun 27 15:04:15: %SSH-5-ENABLED: SSH 1.5 has been enabled
Router1(config)#ip ssh time-out 120
Router1(config)#ip ssh authentication-retries 4
Router1(config)#end
Router1#

SSH became available in Cisco’s IOS starting with Release 12.1(1)T. However, only versions of IOS that support IPSec (DES or 3DES) encryption include SSH support.

Note that there are severe restrictions on exporting any software that includes 3DES outside of the U.S. and Canada.

SSH provides a secure method of communication between network entities by means of transparent encryption. It is a protocol that encrypts all traffic, including passwords, between a client and a server. This makes it an excellent replacement for the Telnet and Rlogin protocols. Cisco’s IOS currently supports only a subset of the standard SSH tools. In particular, Cisco routers do not support the newer SSH Version 2, which includes a number of important enhancements.

The main reason to consider replacing Telnet with SSH is security. The entire Telnet session, including passwords, is transmitted in clear-text. Anybody using a protocol analyzer between the Telnet client and server can easily see all of the data sent by both ends of the conversation—including usernames and passwords. SSH, on the other hand, uses strong encryption algorithms to ensure that the entire session is unintelligible to anybody except for the intended party. This allows for secure communication through the Internet or any other public network.

The transparent encryption scheme used by SSH ensures that, except for initial configuration, SSH behaves similarly to Telnet.

Configuring SSH requires the following steps:

Generating a set of SSH keys automatically enables the SSH protocol. As soon as you have created the keys, the router can start accepting SSH sessions. The first time you attempt to access an SSH-enabled device, your SSH client software will prompt you to store the device host key. This prevents other devices from masquerading as a legitimate device:

Freebsd% ssh -l ijbrown Router1
The authenticity of host 'Router1 (172.25.1.5)' can't be established.
RSA1 key fingerprint is 7a:97:99:2a:ef:08:40:fb:c3:dd:c4:8c:29:fc:2f:4d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'Router1' (RSA1) to the list of known hosts.
ijbrown@Router's password: xxxxxxxxxx

Router1>exit
Connection to Router1 closed.

SSH passes the current username to the SSH server, which in turn prompts for the password of the current user. However, with the Unix version of SSH, you can override this behavior by specifying the -l option, followed by an alternate username. In the previous example, we explicitly specified a particular username (ijbrown). The default behavior looks like this:

Freebsd% ssh Router1
ijbrown@Router1's password: xxxxxxxxx

Router1>

Because we don’t specify a username in this example, the router assumes that it should use the current Unix username, ijbrown.

If you decide to use SSH as your transport protocol for administrative access to your routers, we recommend that you disable all other forms of VTY access by using the transport input configuration command. Running insecure protocols defeats the purpose of implementing SSH in the first place. For more information on disabling transport protocols on virtual terminals, see Recipe 3.10. The following example illustrates how to disable all inbound protocols except SSH:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line vty 0 4
Router1(config-line)#transport input ssh
Router1(config-line)#end
Router1#

Starting with Version 12.1(3)T, Cisco’s IOS began to support SSH client functionality as well. SSH clients allow you to access other SSH servers, including SSH-enabled routers. In the following example, we initiate an SSH session from our router to an SSH-enabled Unix server:

Router1#ssh -l ijbrown server
Trying server.oreilly.com (172.25.1.3)... Open
Password: xxxxxxxxxxx
FreeBSD 4.6-STABLE (IJB)

Welcome to FreeBSD!

You have new mail.
Freebsd%

Many SSH clients and servers are readily available for most popular operating systems. There are also several free SSH packages available on the Internet, including OpenSSH and PuTTY (see Appendix A for more details).

The show ssh EXEC command displays the active SSH sessions and their attributes, such as VTY number, SSH version, encryption type, session state, and username:

Router1#show ssh
Connection      Version Encryption      State                   Username
 0              1.5     3DES            Session started         ijbrown
 3              1.5     3DES            Session started         morewood

The command show ip ssh displays the SSH server configuration status, including the SSH version, authentication timeout, and number of retries:

Router1#show ip ssh
SSH Enabled - version 1.5
Authentication timeout: 120 secs; Authentication retries: 4
Router1#

Recipe 3.1; Chapter 4

You want to change the privilege level of specific IOS commands.

To reduce the privilege level of an enable command from 15 to 1, use the following command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#privilege exec level 1 show startup-config
Router1(config)#end
Router1#

You can also increase the privilege level of a level 1 command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#privilege exec level 15 show ip route
Router1(config)#privilege exec level 1 show ip
Router1(config)#privilege exec level 1 show
Router1(config)#end
Router1#

Note that raising the privilege level of the show ip route command also increased the level of the show ip set of commands and all of the other show commands. In this example, we lowered the show ip and show commands back to privilege 1 to ensure that all of the other show commands operated normally.

Cisco routers support 16 privilege levels ranging from 0 to 15. By default, Cisco assigns commands to only three of these privilege levels: zero, user, and enable. There are five commands with privilege level zero: disable, enable, exit, help, and logout. The user level (privilege level 1) has a wide variety of commands available that cannot alter the router’s configuration. Enable mode (privilege level 15), by contrast, allows complete access to all router commands.

In practical terms, only levels 1 and 15 are normally used. When you first access the router using your VTY password (or local authentication), the router assigns privilege level 1 to your session. In order to access privilege level 15, you must use the enable EXEC command:

Router1>show privilege
Current privilege level is 1
Router1>enable 15
Password:
Router1#show privilege
Current privilege level is 15
Router1#

You can specify any valid privilege level with the enable command, but the default is level 15. You can also reduce the privilege level of your current session with the disable command:

Router1#show privilege
Current privilege level is 15
Router1#disable 1
Router1>show privilege
Current privilege level is 1
Router1>

The disable command will default to privilege level 1 if you don’t specify a target privilege level.

By default, Cisco assigns a subset of commands to privilege 1 and the full set of commands to privilege 15. However, the default commands for each privilege level may not be appropriate for your organization. Many organizations find it useful to modify the default command privileges.

The first example in this recipe shows how to change the privilege level of the show start-config from its default privilege value of 15, giving it a new value of 1. This allows normal unprivileged users to see the router’s startup configuration without having to give them full enable access in the process. People usually use this feature to reduce the privilege of certain key commands. By allowing normal users to access the few commands that they need, this feature allows you to keep tighter restrictions on the commands that change the router’s configuration.

Although you can change the privilege mode of any router command, the show running-config command does not function correctly at levels below 15:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#privilege exec level 1 show running-config
Router1(config)#end
Router1#disable
Router1>show running-config
Building configuration...

Current configuration : 85 bytes
!
! Last configuration change at 22:02:36 EDT Sun Jul 7 2002 by ijbrown
!
!
!
!
end

Router1>

Although the router permits the command to execute, the output is unusable.

The second recipe example shows how to increase the privilege level of a command (show ip route) from 1 to 15. This will prevent user-level staff from viewing the routing table. The NSA guide to Cisco security recommends that administrators increase the privilege level of the connect, rlogin, telnet, show ip access-lists, show access-lists, and show logging commands from 1 to 15:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#privilege exec level 15 connect
Router1(config)#privilege exec level 15 rlogin
Router1(config)#privilege exec level 15 telnet
Router1(config)#privilege exec level 15 show ip access-lists
Router1(config)#privilege exec level 15 show access-lists
Router1(config)#privilege exec level 15 show logging
Router1(config)#privilege exec level 1 show
Router1(config)#privilege exec level 1 show ip
Router1(config)#end
Router1#

Note that changing the privilege level of the show ip route command from 1 to 15 also increases the privilege level of all show ip and show commands to 15. So, in this example, we have explicitly reduced the privilege of these commands back to level 1 so that we don’t lose access to all of the other show commands.

Recipe 3.22; Recipe 3.23

You want to set different privilege levels for different users.

To assign a particular privilege level to a user, use the following set of commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default local
Router1(config)#aaa authorization exec default local
Router1(config)#username slowell privilege 10 password maceng#1
Router1(config)#privilege exec level 10 show ip route
Router1(config)#privilege exec level 1 show ip
Router1(config)#privilege exec level 1 show
Router1(config)#end
Router1#

You can also create several global privilege levels that any user can access with the appropriate password:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#enable secret level 10 lvl10passwd
Router1(config)#privilege exec level 10 show ip route
Router1(config)#privilege exec level 1 show ip
Router1(config)#privilege exec level 1 show
Router1(config)#end
Router1#

Sometimes having two privilege level groups doesn’t provide fine enough granularity. For example, you might want to have three levels of administrators: user-level staff, mid-level staff, and high-level engineers. You don’t want user-level staff members to see the router’s routing table; the mid-level staff should be able to see the routing table, but not make configuration changes; and the highest-level engineers need to have access to everything.

You could set up these three groups by using either method shown in the recipe example. For example, you could create user accounts for the staff members and assign the appropriate privilege level to each user or group of users. Or you could create user accounts for all of the users, and then define a series of different global enable levels. Either approach would work.

Our first example uses the username command, discussed in Recipe 3.1, to assign a particular privilege level to a username. We have assigned user slowell the privilege level 10 and increased the privilege level of the command show ip route to 10. Without the aaa authorization command, you cannot change the default privilege level. Essentially, we have created a new privilege level, 10, and assigned it a single command. It will also inherit the commands from all of the lower the privilege levels:

Freebsd% telnet Router1
Trying 172.22.1.4...
Connected to Router1.
Escape character is '^]'.


User Access Verification

Username: slowell
Password: <maneng#1>
Router1#show privilege
Current privilege level is 10
Router1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.22.1.3 to network 0.0.0.0

     172.16.0.0/24 is subnetted, 1 subnets

C       172.22.1.0 is directly connected, FastEthernet1/0
O*E1 0.0.0.0/0 [110/3] via 172.22.1.3, 00:15:56, FastEthernet1/0
Router1#disable 1
Router1>show ip route

% Invalid input detected at '^' marker.

Notice that when this user logs in, he automatically gets the increased privilege level without having to issue an enable command. He then executes the show ip route command, which works normally because we have assigned it to level 10. If he then reduces his level to 1 and tries the same command again, it won’t work.

You could assign a username to privilege level 15 (enable level), but we do not recommend doing this. The extra layer of password protection and the strong encryption used by the enable secret command outweighs the convenience of assigning a user privilege level 15.

The second example defines a new privilege level using the enable secret command. You can also use the enable password command to define per-level usernames, but the enable secret command gives much better encryption, as we showed in Recipe 3.5.

The second method has two distinct advantages over the first example. First, the enable secret command uses strong MD5 encryption to store its passwords in the configuration. Second, it ensures that the new privilege level is available to all user-level staff, not just the single username we assigned earlier.

You can then use the command enable 10, which has its own password, to reach this new level:

Router1>enable 10
Password: <lvl10passwd>
Router1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.22.1.3 to network 0.0.0.0

C       172.22.1.0 is directly connected, FastEthernet1/0
O*E1 0.0.0.0/0 [110/3] via 172.22.1.3, 1w2d, FastEthernet1/0
Router1#disable 1
Router1>show ip route
              ^
% Invalid input detected at '^' marker.

Router1>

To access the new privilege level, this user used the enable command with the optional privilege level keyword 10. The router then prompted her for the level 10 password; after entering it correctly she was allowed to use the show ip route command. Finally, she reduced her privilege level back to default user-level (privilege level 1), where the show ip route command no longer works.

Recipe 3.1; Recipe 3.2; Recipe 3.21; Recipe 3.23

You want to set the privilege level according to which port you use to access the router.

To configure the privilege level of a particular line, use the following configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line aux 0
Router1(config-line)#privilege level 5
Router1(config-line)#exit
Router1(config)#privilege exec level 5 show ip route
Router1(config)#privilege exec level 1 show ip
Router1(config)#privilege exec level 1 show
Router1(config)#end
Router1#

By default, every access line has a privilege level of 1. You can change the privilege level assigned to a particular line with the privilege level command. The following example shows what happens when we connect to an AUX port that is configured with privilege level 5:

Press RETURN to get started.

Router1#show privilege
Current privilege level is 5
Router1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.22.1.3 to network 0.0.0.0

C       172.22.1.0 is directly connected, FastEthernet1/0
O*E1 0.0.0.0/0 [110/3] via 172.22.1.3, 1w2d, FastEthernet1/0
Router1#disable
Router1>show ip route
                ^
% Invalid input detected at '^' marker.
Router1>

Note that no username or password is needed to log in, and the privilege level defaults to 5. This permits us to issue a show ip route command. We have raised the privilege of this command to the same level, so it works. When we use the disable command to set the privilege level back to 1 and attempt to issue the show ip route command again, it fails.

Although we have just shown how to increase the privilege level of a router port, this command is more commonly used to lower the level to 0. Lowering the privilege level provides greater security on insecure lines as well as greater flexibility in restricting commands. For instance, you can use this method to restrict the commands available to a user connected on a particular port down to just telnet, preventing all other commands. You can accomplish this by configuring a port to privilege level 0 and lowering the privilege level of the telnet command to the same level. This is useful when the router is acting as a terminal server.

Recipe 3.21; Recipe 3.22