Methods of User EXEC Access

Now that you have a basic understanding of password authentication methods, this section discusses how you can secure your Cisco IOS router. This chapter focuses only on local solutions available on the router. Chapter 5 discusses how to centralize this using a security server, such as the Cisco Secure ACS security server product.

Two levels of access to a Cisco router exist:

• User EXEC? Used for basic troubleshooting processes

• Privileged EXEC? Used for detailed troubleshooting and configuration

Both of these methods support authentication. Within user EXEC access, however, the Cisco IOS differentiates between local and remote access. Local access is done through the console or auxiliary port, where you use the Cisco IOS command-line interface (CLI) to interact with the Cisco IOS and the device. Remote access can be performed in a multitude of ways. This section covers how to secure user EXEC access. Privileged EXEC access is covered in the section "Privileged EXEC Access," later in this chapter.

Cisco IOS Configuration Tips Before I discuss any other commands, I would like to share a few side tips about router configurations. First, to prevent logging messages from showing up in your lines and disrupting your typing flow, use the logging synchronous line-configuration command; this is placed under your console, auxiliary, and VTY lines. This command causes the Cisco IOS to redisplay the information that you typed in after any Cisco IOS output is displayed on the terminal, such as debug output and system event messages, perhaps for when an interface goes up or down. Second, use the no ip domain-lookup command to prevent the router from resolving names (including bad or invalid commands) to IP addresses. I am not the greatest typist in the world, so it's annoying to have to break out of an inadvertent Telnet attempt by the Cisco IOS when you type in a nonexistent command. Third, as of Cisco IOS 12.2(8)T, you can execute EXEC commands from configuration mode. From configuration mode, use the do command followed by the EXEC command that you want to execute, like this: do show running-config. Many people have hoped for this capability for a long time, and Cisco finally has delivered.

Local Access: Console and Auxiliary

To assign a static password to the console line, use the following configuration:

Router(config)# line console 0

Router(config-line)# password password

The password that you enter in the password command is a clear-text password. When you examine the output from the show running-config command, you will see the actual password in the configuration:

line con 0

 password cisco

 logging synchronous

Obviously, this is a problem if someone is looking over your shoulder or if you back up your configuration to a TFTP server with the copy running-config tftp command. Two solutions discussed later remedy this problem: encrypting the clear-text password, and using a secure form of copying your configuration to an external server without having to use TFTP, which lacks any authentication and encryption method.

If your router has an auxiliary line, you can assign it a password with basically the same configuration:

Router(config)# line aux 0

Router(config-line)# password password

Typically, this line is used for remote dial-in access for emergency situations. If you are using this line for dialup, you must implement security for dialup on your router, which is beyond the scope of this book. I recommend that you run PPP on your auxiliary port in this case, using CHAP for authentication and caller ID to restrict unauthorized access.

Password Usage I have been teaching Cisco-related courses, including official Cisco classes, for more than 7 years. In almost all courses, I see Cisco using the passwords of cisco, san-fran or sanfran, and san-jose or sanjose as examples to secure user and privileged EXEC levels of access. You would think that something as obvious as these passwords never would be used in a production environment, but many times I have seen these used as passwords to secure company routers. Basically, the newbie Cisco IOS administrator looked at the examples in Cisco's course material and copied them verbatim. Guess what passwords a hacker first will try when gaining access to your router?

Login Authentication Methods

One main difference between the console line for user EXEC access and the auxiliary and VTY (discussed in the next section) lines is that a password on the console line is optional, whereas it is required on auxiliary and VTY lines. You must enable authentication on these two latter types of lines to allow access. If you do not, the Cisco IOS displays an error message and closes the connection:

Password required, but none set

[Connection to 192.168.1.254 closed by foreign host]

To allow access through the auxiliary or VTY lines, use one of the following two configurations:

Router(config)# line aux 0

Router(config-line)# [no] login [local]

or:

Router(config)# line vty 0 4

Router(config-line)# [no] login [local]

The login command, by itself, specifies the use of authentication. By default, it checks for a password configured with the password line-configuration command. If this does not exist, the user is not allowed access. To disable authentication checking, use the no login command. Note that this never is recommended for any type of connection, whether local or remote access.

Optionally, you can override the use of the password configured on the line and use other methods, such as a local username and password database, by specifying login local (discussed later in this chapter in the "Local Authentication Database" section), or use external authentication using a security server (discussed in Chapter 5). Remember my earlier caution: Use either of these two methods (preferably the latter one, which is preferred for securing line access).

Login Connection Timeouts

By default, console, auxiliary, and Telnet (VTY) sessions time out after 10 minutes of idling. You can override this with the exec-timeout command, shown here:

Router(config)# line type #

Router(config-line)# exec-timeout minutes seconds

You must specify the minutes and seconds for the timeout. Optionally, you can specify 0 and 0 for the minutes and seconds, specifying an infinite timeout. I never recommend this for a production router, but only for lab situations, such as practicing for the CCIE Router and Switch or Security lab exam.

This simple example sets the timeout to 5 minutes for Telnet sessions:

Router(config)# line vty 0 4

Router(config-line)# exec-timeout 5 0

To view your timeouts, use the show line command. Based on my previous configuration, Example 3-1 shows the partial output of this command.

Example 3-1. Example Line Configuration

Router# show line vty 0

   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int

     6 VTY              -    -      -    -    -      2       0     0/0       -



Line 6, Location: "", Type: ""

Length: 24 lines, Width: 80 columns

Baud rate (TX/RX) is 9600/9600

Status: Ready, No Exit Banner

Capabilities: none

Modem state: Ready

Special Chars: Escape  Hold  Stop  Start  Disconnect  Activation

                ^^x    none   -     -       none

Timeouts:      Idle EXEC    Idle Session   Modem Answer  Session   Dispatch

               00:05:00        never                        none     not set

                            Idle Session Disconnect Warning

                              never

                            Login-sequence User Response

                             00:00:30

                            Autoselect Initial Wait

                              not set

output omitted

In Example 3-1, you can see that the idle timeout, below the Idle EXEC column, was set to 5 minutes. This is a common setting for Telnet sessions.

Remote Access

Compared to local access, in which you can access user EXEC mode only through the console or auxiliary line, you can access your router remotely in quite a few ways. These methods include Telnet, RSH, SSH, HTTP and HTTPS, and SNMP. The following sections cover the configurations and issues with these approaches.

VTY (Telnet)

Cisco uses VTY lines to handle incoming and outgoing Telnet connections. VTYs are basically logical lines: The Cisco IOS treats them as a physical line from a configuration and operation perspective, but they are not something that you physically can touch with your hands.

You already know how to set up basic authentication on a VTY. Here is a simple example:

Router(config)# line vty 0 4

Router(config-line)# password cisco

Router(config-line)# login

This sets up basic Telnet access to your router.

Given this previous caution, however, you want to configure one thing on your VTYs, whether the access method is Telnet, SSH, or a VPN. Way back in Cisco IOS 10.0, Cisco built in the capability to filter sessions that use the VTY lines. This is accomplished by creating a standard access control list (ACL), which specifies which source address or addresses are allowed access; then the standard ACL is applied to the VTY lines. Chapter 7, "Basic Access Lists," discusses the details of standard ACLs. Figure 3-2 shows a simple example illustrating the usefulness of this feature. Here, a router is being used as a perimeter firewall. In this network, only two administrators should be allowed remote SSH access to the router. This is accomplished by setting up a standard ACL and applying it to the VTYs, as shown in Example 3-2.

Figure 3-2. Restricting VTY Access

[View full size image]

In this example, applying the standard ACL requires the use of the access-class command. This command requires that you specify the number of the standard ACL (1) and the direction of restriction (in or out). Using the in parameter restricts inbound VTY sessions; out restricts outbound VTY sessions. When using the out parameter, the addresses listed in the standard ACL are viewed as destination, not source, addresses. One note on Cisco ACLs applies: If you do not explicitly permit traffic in an ACL, it is implicitly denied.

Example 3-2. Restricting VTY Access

Router(config)# access-list 1 permit 172.16.3.10

Router(config)# access-list 1 permit 172.16.3.11

Router(config)# line vty 0 4

Router(config-line)# transport input ssh

Router(config-line)# transport output ssh

Router(config-line)# access-class 1 in

The syntax of the access-class command is as follows:

Router(config)# line vty beginning_# ending_#

Router(config-line)# access-class standard_ACL_# in | out

It is important to point out that you should apply the access-class command to all VTYs. For a router that has five VTYs, the beginning and ending numbers are 0 and 4. If you are not sure how many VTYs you have, use the show running-config or show lines commands.

The main problem of the Cisco IOS VTYs is that they allow many different types of remote access, such as Telnet, rlogin, SSH, and others. The transport input ssh command limits access to the VTYs to SSH access only, whereas the transport output ssh command restricts remote access to other devices to SSH. The syntax of the transport command is as follows:

Router(config)# line vty beginning_# ending_#

Router(config-line)# transport {input | output} {all | none |

  pad | rlogin | ssh | telnet | udptm}

If you want to use only SSH for remote access, use the transport commands displayed in Example 3-2.

Secure Shell

In the old days of UNIX when no real need existed for a secure environment, many administrators used the rexec and rsh tools to execute commands on remote systems without having to log into them. However, in today's world, these tools offer no real security: They send information across the network in clear text, which is easy to eavesdrop on, and their authentication is based on the user's source IP address, which is easy to spoof. Two versions of SSH are available: version 1 and version 2. In most Cisco IOS versions, Cisco supports an enhanced version of version 1, called 1.5; however, starting in Cisco IOS 12.3T and later versions of 12.1E, Cisco also supports SSHv2.

Two components are required for SSH to function:

• Server

• Client

The SSH server provides a secure connection, which is encrypted, to the Cisco IOS CLI. This connection is similar to an encrypted Telnet connection. The SSH client runs the SSH protocol to connect to an SSH server, and it must support the Data Encryption Standard (DES) or 3DES as well as password authentication. DES and 3DES are discussed in more depth in Chapter 19, "IPSec Site-to-Site Connections." Authentication is performed in a normal fashion: Users can be authenticated using local mechanisms or by using an external security server. Cisco routers support both server and client connections. However, SSH on Cisco IOS routers has the following restrictions:

• You cannot use RSA authentication (discussed in Chapter 19).

• You must use a Cisco IOS image that supports DES or 3DES.

SSH Server Configuration

Before setting up SSH, you must install a Cisco IOS image that supports DES or 3DES (this requires the image to support IPSec). For both router client and server functions to work, you need at least Cisco IOS 12.1(3)T.

When you have installed the appropriate Cisco IOS software, you can begin your Cisco IOS configuration. You should perform these six steps:

Step 1. Assign a name to the router (required).

Router(config)# hostname router_name

Step 2. Assign a domain name to the router (required).

Router(config)# ip domain-name DNS_domain_name

Step 3. Generate your encryption keys (required).

Router(config)# crypto key generate rsa

You must assign a router and domain name before executing this command; otherwise, you will get an error message. Cisco recommends that you use a key size of at least 1024 bits. When you execute this command, it does not appear in the running or saved configuration. Also, if you need to generate a new key pair, first use the crypto key zeroize rsa command.

Step 4. Set up your VTY access for SSH (optional, but recommended):

Router(config)# username name secret password

Router(config)# line vty 0 4

Router(config-line)# transport input ssh

Router(config-line)# transport input ssh

Router(config-line) login local

For SSH access, you must use a username and password by setting up either a local authentication database (discussed later in the "Local Authentication Database" section) or an authentication server (see Chapter 5). The username and login local commands set up local authentication. This is true of most SSH clients that I have dealt with.

Step 5. Tune the SSH server (optional).

Router(config)# ip ssh {[timeout seconds] | [authentication-retries integer]}

Optionally, you can specify a timeout, in seconds, for initiating an SSH connection. If the connection cannot be established in this time period, the connection fails. You also can limit the number of authentication retries for a connection upon an invalid authentication attempt (the default is 3). Other parameters exist for this command, but these are the two most common ones. If you cannot execute this command, it is because you have not generated your encryption keys with the crypto key generate rsa command. After the user has authenticated and established an SSH connection to the router, the Cisco IOS uses the VTY idle timeout (exec-timeout command) to monitor the session.

Step 6. Verify SSH server operation (optional).

Router# show ssh

Router# show ip ssh

SSH Server Example

To help illustrate how to set up an SSH server on a Cisco IOS router, this example uses the perimeter router shown previously in Figure 3-2. Example 3-3 shows the configuration.

Example 3-3. SSH Server Configuration Example

Router(config)# hostname bullmastiff

bullmastiff(config)# ip domain-name quizware.com

bullmastiff(config)# crypto key generate rsa

The name for the keys will be: bullmastiff.quizware.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 1024 bit RSA keys ...[OK]

00:02:25: %SSH-5-ENABLED: SSH 1.5 has been enabled

bullmastiff(config)# username richard secret bigXdogYlover

bullmastiff(config)# username natalie secret BIGxDOGyLOVER

bullmastiff(config)# access-list 1 permit 172.16.3.10

bullmastiff(config)# access-list 1 permit 172.16.3.11

bullmastiff(config)# line vty 0 4

bullmastiff(config-line)# login local

bullmastiff(config-line)# access-class 1 in

bullmastiff(config-line)# transport input ssh

bullmastiff(config-line)# transport output ssh

bullmastiff(config-line)# end

After the RSA encryption keys were generated, notice that the Cisco IOS displayed a message that SSH 1.5 has been enabled: The SSH server function is operating. Also, I used a standard ACL and the access-class statement to limit the devices that can access the router's VTYs.

To verify that the SSH server is operating, as well as to verify its configuration, use the show ip ssh command, as shown in Example 3-4.

Example 3-4. Verifying Your SSH Configuration

bullmastiff# show ip ssh

SSH Enabled - version 1.5

Authentication timeout: 120 secs; Authentication retries: 3

To see the SSH client connections, use the show ssh command, as shown in Example 3-5.

Example 3-5. Viewing Your SSH Client Connections

bullmastiff# show ssh

Connection      Version Encryption      State                   Username

 0              1.5     3DES            Session started         richard

In this example, you can see that someone logged into the richard account and that 3DES is being used for encryption.

SSH Client Connections

Besides functioning as a server, the Cisco IOS supports an SSH client. However, this option is available only after you have set the Cisco IOS as an SSH server (performed Steps 1 through 3 from the previous section). When you have completed these steps, you can initiate SSH client connections from your router. This is accomplished using the following EXEC command:

Router# ssh [-l username] [-c {des | 3des}] [-o numberofpasswdprompts #]

  [-p port_#] {IP_Address | hostname} [command]

The ssh command has many parameters. When accessing a remote resource, you might be required to give a username for authentication; this is true if you used a local authentication database or an external security server. Use the ?l option to specify the username. You also can specify the encryption algorithm to use with the ?c option. To change the number of password prompts, use the ?o numberofpasswordprompts option. SSH uses port 22 by default, but you can change it with the ?p option. The one required parameter is the address or name of the destination SSH server. Following this are optional commands that you might want to have executed (this feature is not supported if you are logging into a Cisco IOS router).

Example 3-6 shows a sample of testing the connection by establishing an SSH client connection from a router to itself, using the code configuration shown in Example 3-6.

Example 3-6. SSH Client Connection Example

bullmastiff# ssh -l richard 192.168.1.254

Password: cisco

bullmastiff>

Web Browser

Cisco supports the use of a web browser to access and manage a Cisco router. This is a nice feature for administrators who find the Cisco IOS CLI intimidating. This section discusses how to set up your router as an HTTP server and details some issues with using HTTP.

By default, the HTTP server function on the router is disabled. To configure HTTP access, use the following steps:

Step 1. Enable the HTTP server (required).

Router(config)# ip http server

The ip http server command enables the HTTP server function on the router. This is the only required command to enable the server function; however, you will want to implement the security features in Steps 2 and 3. If you are using HTTPS (discussed in the next section), you should disable the standard HTTP server with no ip http server.

Step 2. Define an authentication method (highly recommended).

Router(config)# ip http authentication {aaa | enable | local}

Most people use three basic methods to perform authentication with HTTP. The aaa parameter specifies that AAA should be used (AAA is discussed in Chapter 5). The enable parameter specifies that the privileged EXEC password is used to authenticate HTTP access (this is discussed in the later section "Privileged EXEC Access"). The local parameter specifies that the local authentication database of usernames and passwords should be used for authentication (this is discussed in the later section "Local Authentication Database"). Note that the user needs level 15 access, which is privileged EXEC level. Of the three methods, I don't recommend the privileged EXEC password, and recommend either the local username database or an AAA server.

Step 3. Restrict access through HTTP (highly recommended).

Router(config)# ip http access-class standard_ACL_#

This command enables you to restrict, based on the source IP address of the client, which devices are allowed HTTP or HTTPS access to the router. The function of this command is the same as that described previously with VTY restrictions and the access-class command. With the ip http access-class command, you need to specify a standard ACL number or name that contains a list of permitted source addresses.

Step 4. Change the HTTP port number (optional).

Router(config)# ip http port port_#

By default, the Cisco IOS uses port 80 for HTTP connections; however, you can change this port to a different number with the ip http port command. By changing the port number to a nonstandard one, you make it more difficult for a hacker to determine that you are running a web server on the router. Most inept hackers never would figure out that you changed the HTTP port number; however, a smart hacker would scan all TCP ports to determine this, so changing the port number provides only a limited form of protection.

Step 5. Change the location of HTML files (optional).

Router(config)# ip http path URL_location

Typically, you will not use this command: It sets the base HTTP location path for HTML files on the router. By default, these files are located in Flash, but you can move them to a different location, such as a PCMCIA card, if you do not have enough space in Flash for your Cisco IOS. Here is a simple example of doing this: ip http path slot0:.

Step 6. Restrict the number of HTTP connections (recommended).

Router(config)# ip http max-connections #_of_connections

This command enables you to limit the maximum number of HTTP management connections to the HTTP server on the router. The default value is 5.

Step 7. Change the idle timeout for HTTP connections (optional).

Router(config)# ip http timeout policy idle seconds life seconds requests number

This command enables you to define how long an HTTP server connection to the router should remain open. The idle parameter specifies the maximum allowed idle time for an HTTP connection before it is torn down. The default is 180 seconds. The life parameter specifies the maximum amount of time that the connection is allowed to be established (busy or idle) before it is torn down. The default is 180 seconds, but this can be increased up to 86,400 (24 hours). The requests parameter restricts the maximum number of persistent requests (for the same information) before the connection is closed. This defaults to 1. Note that if the router's HTTP server is busy, it can terminate HTTP client connections to free up resources.

When you have the HTTP server set up, from a web browser, access your router by using the following URL in the address bar:

http://router's_IP_address

Now that you have a basic understanding of the setup of an HTTP server on a Cisco IOS router, take a look at a simple example, using the network shown previously in Figure 3-2. In this example, only the two administrator devices should be allowed HTTP access to the router. Example 3-7 shows the basic configuration to accomplish this.

Example 3-7. HTTP Server Configuration

Router(config)# access-list 1 permit 172.16.3.10

Router(config)# access-list 1 permit 172.16.3.11

Router(config)# username richard privilege 15 secret bigXdogYlover

Router(config)# username natalie privilege 15 secret BIGxDOGyLOVER

Router(config)# ip http server

Router(config)# ip http authentication local

Router(config)# ip http access-class 1

In this example, only two devices are allowed HTTP access to the router: 172.16.3.10 and 172.16.3.11. Both administrators have accounts set up, and the router uses the local authentication database (username commands) to perform the authentication. One interesting thing to point out about the username commands is the privilege 15 reference. Remember that you need privileged EXEC access for HTTP server connections to the router. This command is discussed in much more depth in the later section "Local Authentication Database."

Use the show ip http client all command to list all client connections on your router. Use the show ip http server all command to list all HTTP server functions on your router, including past client connections.

HTTP with SSL

Because HTTP is susceptible to eavesdropping attacks, it is not a recommended tool for remote access management. Instead of using HTTP, you can use HTTPS, which is HTTP with Secure Socket Layer (SSL) support. Cisco supports SSL 3.0 for its router HTTP server functions. This feature is new in Cisco IOS 12.2(15)T, and it requires a Cisco IOS image that supports SSL.

RSA authentication is used to validate the identity of devices and uses certificates. The Cisco IOS image needs SSL support to sign these certificates digitally. Certificates are used for authentication purposes and, to my knowledge, never have been spoofed.

As you recall from the last section, you can use the ip http access-class command to restrict access to an HTTP server. However, the main limitation of this command is that because filtering is done on Layer 3 IP addresses, an ingenious hacker could spoof these and bypass the filter. Certificates are discussed in more depth in Part VIII.

HTTPS Components

Three main components play a role in an HTTPS connection:

• Server and client devices

• Cipher suites

• Certificate authority (commonly called a trustpoint)

With server and clients, HTTPS ensures that before any data is sent across the wire, it is protected through encryption and packet signing (commonly called packet authentication or integrity). This prevents all eavesdropping and session-hijacking attacks.

A cipher suite defines how the connection should be protected. Cisco commonly calls this a transform set. Minimally, an encryption algorithm is used to protect the confidentiality of the information being transmitted. Supported encryption algorithms include DES, RC4, and 3DES on Cisco routers. Each packet sent is signed digitally using a hashing function. The digital signature is used by the remote end of the connection to determine whether the encrypted packet contents were tampered with. Cisco supports MD5 and SHA to protect the integrity of packets and detect packet tampering.

A certificate authority (CA) is used to issue and manage certificates. CAs provide a trusted third-party solution to prevent repudiation attacks and to identify the parties in the transaction. HTTPS uses certificates and a CA to perform these functions. Cisco routers support two options in this regard: They can use an external CA to authenticate certificates, or they can function as the CA themselves (only for HTTPS connections, though). The first method is preferred because it is more secure. However, for small networks, setting up and maintaining a CA can be expensive and burdensome; therefore, using a router as the CA for HTTPS connections is a cost-effective solution.

Note that the details of protected connections are covered in more depth in Part VIII, which includes encryption algorithms, hash functions, and certificate authorities.

HTTPS Operation

HTTPS is based on a client/server model. When clients establish an HTTPS connection to a server, such as a Cisco router, they use TCP on port 443. To establish the connection, the client uses the following syntax in a web browser's URL address bar:

https://IP_address_of_server

When the connection is established, the server (router) sends its own certificate to the client. The server has two keys that are used by this certificate: public and private. The public key encrypts data, and only the private key decrypts it (this process is discussed in more depth in Chapter 19). The private key is kept local on the router, and no one sees it. The public key is included on the certificate. Upon receipt of the certificate, the client generates an encryption key. It uses the server's public key to encrypt it and sends this key to the server. Only the server's private key can decode this encryption. At this point, only the client and the server know about the key that the client generated: This is the key used to encrypt data between the client and the server.

HTTPS Configuration: No CA

As I mentioned in the section on HTTPS components, you can implement an HTTPS server function on your router in two ways: Have the router itself generate its own certificate information (less secure), or have the router use a CA and obtain a certificate from it (much more secure). This section covers how you configure the first method: The router generates its own certificate.

The configuration is straightforward and uses some of the commands discussed previously in the "Web Browser" section. Here are the steps:

Step 1. Disable the HTTP server (highly recommended).

Router(config)# no ip http server

You do not want your router accepting both HTTP and HTTPS connections; therefore, disable the HTTP function on the router.

Step 2. Assign a host name and a domain name.

Router(config)# hostname router_name

Router(config)# ip domain-name domain_name

To generate certificate information, your router needs a host name and a domain name.

Step 3. Enable the HTTPS server.

Router(config)# ip http server-secure

The ip http server-secure command enables HTTP with SSL 3.0.

Here are some optional items that I highly recommend you use:

• Set up user authentication with the ip http authentication command. For local authentication, create a list of usernames and passwords with the username command, specifying privileged EXEC access with the privilege 15 parameter.

• Restrict HTTPS access to the router with the ip http access-class command, listing only the allowed IP addresses of administrator devices.

The following items enable you to tune your HTTPS server. The ip http secure-port command specifies which port clients will use for HTTPS:

Router(config)# ip http secure-port port_#

By default, the port number is 443.

You also can change which cipher suite(s) the router will use to protect the connection:

Router(config)# ip http secure-ciphersuite {[3des-ede-cbc-sha] [rc4-128-md5]

  [rc4-128-sha] [des-cbc-sha]}

It is recommended that you allow the client and server to negotiate which suite to use for protection. However, if you are paranoid about protection, you can specify only the most secure suite (3des-ede-cbc-sha) to secure your HTTPS connection.

Now take a look at a simple configuration example to illustrate how to set up HTTPS on your router without a CA, using Figure 3-2 for the network. Example 3-8 shows the configuration.

Example 3-8. HTTPS Server Configuration with an Internal CA Function

Router(config)# hostname Bullmastiff

Bullmastiff(config)# ip domain-name quizware.com

Bullmastiff(config)# access-list 1 permit 172.16.3.10

Bullmastiff(config)# access-list 1 permit 172.16.3.11

Bullmastiff(config)# username richard privilege 15 secret bigXdogYlover

Bullmastiff(config)# username natalie privilege 15 secret BIGxDOGyLOVER

Bullmastiff(config)# no ip http server

Bullmastiff(config)# ip http secure-server

Bullmastiff(config)# ip http authentication local

Bullmastiff(config)# ip http access-class 1

When you are finished, access the router through a web browser using HTTPS. When you do this for the first time, the router automatically generates keying information for its certificate. Here is an example of the Cisco IOS message from the CLI:

00:49:41: %CRYPTO-6-AUTOGEN: Generated new 768 bit key pair

00:49:45: %CRYPTO-6-AUTOGEN: Generated new 768 bit key pair

00:49:46: %SSH-5-ENABLED: SSH 1.5 has been enabled

Notice that because RSA keys were generated, SSH can be used. If you want a more secure connection, use the crypto key generate rsa command and specify a longer number of bits than 768, such as 1024.

Also, your web browser client is presented with a pop-up window about the router's certificate. You must click the Yes button to accept the certificate.

You can see the web server's status with the show ip http server all command, discussed in the "Web Browser" section. You can limit the output to just HTTPS information with the command displayed in Example 3-9, taken from the previous configuration.

Example 3-9. Examining the Status of the Router's HTTPS Server

Bullmastiff# show ip http server secure status

HTTP secure server status: Enabled

HTTP secure server port: 443

HTTP secure server ciphersuite: 3des-ede-cbc-sha des-cbc-sha rc4-128-md5

  rc4-128-sha

HTTP secure server client authentication: Disabled

HTTP secure server trustpoint:

In this example, you can see that HTTPS is enabled, and you can see the cipher suite that it is using to protect the web browser connections.

HTTPS Configuration: CA

The configuration of HTTPS using a CA server is much more complicated than what was done in the previous section. The configuration is broken into two parts: setting up access to the CA to obtain your certificate, and setting up the HTTPS server function.

The first thing that you need to do is to set up your connection to the CA server and obtain a certificate. Follow these steps to accomplish this:

Step 1. Set the correct time and date on your router (recommended).

Router(config)# clock timezone name offset

Router(config)# exit

Router# clock set hh:mm:ss day month year

The clock timezone command specifies the time zone that your router is in. The name specifies the name of the time zone, such as EDT for Eastern Daylight Saving Time. The offset specifies the number of hours, plus or minus, from UTC time?for EDT, it would be ?5. The privileged EXEC clock set command sets the time?the day of the month is a number from 1 to 31; the month is a name, such as June; and the year is a four-digit year, such as 2003. I discuss the use of the Network Time Protocol, which I recommend over the clock set command, in Chapter 18, "Logging Events." Other clocking configurations are discussed here as well.

Step 2. Assign a host name and a domain name (required).

Router(config)# hostname router_name

Router(config)# ip domain-name domain_name

To generate certificate information, your router needs a host name and a domain name.

Step 3. Generate your RSA keys (optional).

Router(config)# crypto key generate rsa

This command generates your RSA keys for your router's certificate. This is optional because the router does this when acquiring a certificate; using this command simply enables you to control how long the keys are.

Step 4. If you are not using DNS resolution, define a static DNS resolution entry for the CA server (recommended).

Router(config)# ip host CA_server's_name CA_server's_IP_address

Your router needs to know how to reach the CA to obtain and authenticate certificate information. This can be done through DNS or a static host entry with the ip host command. Remember that DNS is susceptible to DNS spoofing, so I recommend using static DNS resolution with the ip host command.

Step 5. Set up access to the CA server (required).

Router(config)# crypto ca trustpoint CA_server's_name

Router(config-trustpoint)# enrollment url URL_location

Router(config-trustpoint)# primary

Router(config-trustpoint)# enrollment http-proxy

  HTTP_server's_name port_#

The crypto ca trustpoint command defines the name of the CA (what you defined in the ip host command) and takes you into a subconfiguration mode for further configuration. Before 12.2.8(T), you used the crypto ca identity command instead of the crypto ca trustpoint command?both do the same thing. The enrollment url command specifies the URL to use to access the certificate information on the CA. For example, Microsoft's CA product for Windows Server 2000 uses http://CA_server's_name/certsrv/mscep/mscep.dll. You need to contact the administrator of the CA to determine what URL to use. If you are specifying more than one CA server, use the primary command to specify which one has precedence. If you are using a proxy server to access the CA, the enrollment http-proxy command specifies the name or IP address of the proxy server, along with the port number. Note that the only two required commands are the first two in the previous code listing: crypto ca trustpoint and enrollment url.

Step 6. Obtain the CA's personal certificate (required).

Router(config)# crypto ca authenticate CA_server's_name

This command obtains the CA's certificate from the CA. When your router receives the certificate, it asks you whether you want to accept the certificate. Before accepting it, call the CA administrator to verify the fingerprint message that was sent to the router. If a man-in-the-middle attack occurred, validating the fingerprint can determine this.

Step 7. Obtain the router's personal certificate (required).

Router(config)# crypto ca enroll CA_server's_name

After obtaining the CA's certificate, use the crypto ca enroll command to have the CA generate a certificate for the router itself. You are prompted for a few pieces of information. First, you must enter a challenge password; this is used if you ever need to revoke your certificate on the CA because the CA administrator will ask for it. Next, you are prompted for what information you want to include in the certificate, such as the router's serial number and its IP addresses. After answering these questions, you are asked to obtain a certificate from the CA. The Cisco IOS displays a message with the appropriate success status. When obtaining a certificate, a delay (in seconds, minutes, or hours, depending upon how the CA is configured to respond) might occur before the router obtains its certificate.

Upon completion, save your configuration: This saves your certificate information as well as your commands. Part VIII discusses certificates and their setup in much more depth.

Now that you have configured access to the CA, you need to prepare your router as an HTTPS server. This is similar to what I described in the previous section. Here are the steps to follow:

Step 1. Disable the HTTP server (highly recommended).

Router(config)# no ip http server

You want to ensure that only the HTTPS server function is operating on your router.

Step 2. Enable the HTTPS server (required).

Router(config)# ip http secure-server

Step 3. Specify the HTTPS port and cipher suite to use (optional). This is accomplished with the ip http secure-port and ip http secure-ciphersuite commands, which were discussed in the last section.

Step 4. Configure verification of client's certificate (highly recommended).

Router(config)# ip http secure-client-auth

This command has the server request the client's certificate and validate the client's identity. Use this option only if you know that your PCs have SSL certificates installed; otherwise, the router will prevent HTTPS access. I highly recommend this option because it adds more security to the connection, verifying both endpoints of the connection: client and server.

Step 5. Specify the CA server to use for HTTPS (required).

Router(config)# ip http secure-trustpoint CA_server's_name

This command specifies who the CA server is. Enter the same name that you used with the crypto ca trustpoint command.

Step 6. Authenticate and restrict access to the HTTP server (highly recommended). Use the ip http authentication and ip http access-class commands to accomplish these tasks. These commands were discussed earlier in the "Web Browser" section.

Step 7. Configure other optional HTTP server commands, such as ip http path, ip http max-connections, and ip http timeout-policy. These commands were discussed earlier in the "Web Browser" section.

When you are finished, open a web browser connection to your router, using this syntax in the web browser's URL address bar:

Part I: Security Overview and Firewalls Chapter 1. Security Threats Planning for Security Causes of Security Problems Types of Security Threats Categories of Threats Security Solutions Summary Chapter 2. Introduction to Firewalls Firewall Overview Controlling Traffic and the OSI Reference Model Firewall Categories Firewall Design Cisco IOS Security Summary Part II: Managing Access to Routers Chapter 3. Accessing a Router Types of Authentication Methods of User EXEC Access Privileged EXEC Access Other Access Items Example Configuration Summary Chapter 4. Disabling Unnecessary Services Disabling Global Services Disabling Interface Services Manual Configuration Example of Disabling Services on a Perimeter Router AutoSecure Summary Chapter 5. Authentication, Authorization, and Accounting AAA Overview Authentication Authorization Accounting Secure Copy Summary Part III: Nonstateful Filtering Technologies Chapter 6. Access List Introduction Access List Overview Basic ACL Configuration Wildcard Masks Summary Chapter 7. Basic Access Lists Types of ACLs Additional ACL Features Protection Against Attacks Blocking Unnecessary Services Summary Part IV: Stateful and Advanced Filtering Technologies Chapter 8. Reflexive Access Lists Overview of Reflexive ACLs Configuring Reflexive ACLs Reflexive ACL Examples Summary Chapter 9. Context-Based Access Control Cisco IOS Firewall Features CBAC Functions Operation of CBAC Supported Protocols for CBAC CBAC Performance CBAC Limitations CBAC Configuration CBAC Examples Summary Chapter 10. Filtering Web and Application Traffic Java Applets URL Filtering Network-Based Application Recognition Summary Part V: Address Translation and Firewalls Chapter 11. Address Translation Address Translation Overview How Address Translation Works Address Translation Configuration NAT and CBAC Example Summary Chapter 12. Address Translation Issues Embedded Addressing Information Controlling Address Translation Address Translation and Redundancy Traffic Distribution with Server Load Balancing Summary Part VI: Managing Access Through Routers Chapter 13. Lock-and-Key Access Lists Lock-and-Key Overview Lock-and-Key Configuration Lock-and-Key Example Summary Chapter 14. Authentication Proxy Introduction to AP AP Configuration Verifying and Troubleshooting AP AP Examples Summary Chapter 15. Routing Protocol Protection Static and Black Hole Routing Interior Gateway Protocol Security BGP Security Reverse-Path Forwarding (Unicast Traffic) Summary Part VII: Detecting and Preventing Attacks Chapter 16. Intrusion-Detection System IDS Introduction IDS Signatures Cisco Router IDS Solution IDS Configuration IDS Example Summary Chapter 17. DoS Protection Detecting DoS Attacks CEF Switching TCP Intercept CBAC and DoS Attacks Rate Limiting Summary Chapter 18. Logging Events Basic Logging Time and Date and the Cisco IOS Embedded Syslog Manager Additional Logging Information Summary Part VIII: Virtual Private Networks Chapter 19. IPSec Site-to-Site Connections IPSec Preparation IKE Phase 1: Management Connection IKE Phase 1 Peer Authentication IKE Phase 2: Data Connection IPSec Connection Troubleshooting L2L Example Summary Chapter 20. IPSec Remote-Access Connections Remote Access Overview IPSec Remote-Access Connection Process IPSec Remote-Access EVS Setup IPSec Remote Access Example Summary Part IX: Case Study Chapter 21. Case Study Company Profile Proposal Case Study Configuration Summary