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 TipsBefore 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. |
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.
NOTE
Most passwords that you configure on your router can be from 1 to 25 characters, and the first character cannot be a number. You can have leading spaces before the password, but they are ignored. However, any trailing spaces after the password become a part of the password. You can include a ? in a password by first using the Ctrl-V sequence and then typing in the ?, like this: alphaCtrl-V?987. This creates a password of alpha?987.
CAUTION
Remember that the password Line Configuration mode command does not encrypt passwords by default; it stores them in clear text. I highly recommend that you not use the password command as your authentication method because all administrators who access the line must use the same password. This makes accountability difficult. Typically, this is used as a last resort. I recommend either a local user and password database, discussed in the "Local Authentication Database" section later in this chapter, or a security server, discussed in Chapter 5.
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 UsageI 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? |
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.
NOTE
Even if the Cisco IOS does not check a password for user EXEC access, a password still must be configured for privileged EXEC access for remote-access connections. Otherwise, the user is not allowed access to user and privileged EXEC mode. This process is not true concerning the console line.
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).
TIP
Always put some method of authentication on all your lines, even ones that you are not using, such as the auxiliary line. This ensures that later someone does not set up a new line connection inadvertently and forget to secure it.
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.
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.
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.
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.
CAUTION
Now that you know how to set this up on your router, I recommend that you never use it. Why? Because Telnet sends user information across the network in clear text. Remember that if you are using this router as part of a firewall system, you want to keep it as secure as possible. You could get around the Telnet password issue by using token cards and a token card server, but all other information that you type in the Telnet router session is sent in clear text. I recommend that you use either SSH, discussed in the "Secure Shell" section later in this chapter, or a VPN, discussed in Part VIII, "Virtual Private Networks," when gaining user and privileged EXEC CLI 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.
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.
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.
NOTE
Remember that the access-class command applies to VTY sessions. Telnet is not the only type of connection that uses a VTY: So does SSH. This Cisco IOS feature helps you limit which devices can establish a VTY connection, reducing the likelihood of an access attack.
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.
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.
TIP
Many SSH commercial client packages are available on the market. One of my favorites is Teraterm, with the TTSSH extension. Actually, Teraterm is my preferred terminal software (it's free) for console and Telnet connections as well. To download Teraterm and the TTSSH extension, visit http://www.zip.com.au/~roca/ttssh.html. I have experienced some problems with Teraterm's SSH client with certain versions of the Cisco IOS. If you experience these problems, try PenguiNet SSH, a fully functional shareware client that I have had great success with. It is free to try and less than $30 to buy. You can download it from www.siliconcircus.com.
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:
Router(config)# hostname router_name
Router(config)# ip domain-name DNS_domain_name
Router(config)# crypto key generate rsa
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
Router(config)# ip ssh {[timeout seconds] | [authentication-retries integer]}
Router# show ssh Router# show ip ssh
TIP
I highly recommend that you use the VTY access-class line configuration command to restrict SSH access to your router. Note that after you set up SSH, devices still can Telnet to the router, even with the configuration of the access-class command. Therefore, use the transport command to limit remote access to SSH. You also can create an ACL to filter unwanted remote-access traffic to the router. This is discussed in Chapter 7.
Also, SSH client connections connect to TCP port 22 on an SSH server, so you need to allow this port through your filter, if one exists.
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.
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.
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.
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.
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.
bullmastiff# ssh -l richard 192.168.1.254 Password: cisco bullmastiff>
CAUTION
Many versions of the Cisco IOS, up through 12.2, are vulnerable to a specific kind of SSH DoS attack in which a hacker can affect greatly the performance of a Cisco IOS device. A complete description of this attack is available at http://www.cisco.com/warp/public/707/SSH-multiple-pub.html. For software updates to limit the effect of this kind of attack, visit http://www.cisco.com/warp/public/707/SSH-scanning.shtml#Software.
Also, SSH 1.5 is less secure than SSH 2.0. Information about security issues with SSH v1 (and Cisco 1.5) can be seen at http://lwn.net/2001/0322/a/ssh-analysis.php3. Because of some of the security issues that have cropped up lately with SSH, I recommend that this be used only for internal connections if you are using an older version of the Cisco IOS. The best approach is to upgrade your Cisco IOS to a version that supports SSH 2.0. For connections across a public network, I recommend using a remote-access VPN connection, discussed in Part VIII.
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.
NOTE
Even though the GUI interface of a web browser presents a user-friendly front end to the router's Cisco IOS, you cannot perform all configuration and management options from a web browser. Therefore, in many cases, you still need to access the Cisco IOS CLI to perform configuration and management tasks.
By default, the HTTP server function on the router is disabled. To configure HTTP access, use the following steps:
Router(config)# ip http server
Router(config)# ip http authentication {aaa | enable | local}
Router(config)# ip http access-class standard_ACL_#
Router(config)# ip http port port_#
Router(config)# ip http path URL_location
Router(config)# ip http max-connections #_of_connections
Router(config)# ip http timeout policy idle seconds life seconds requests number
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.
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.
CAUTION
Some security issues arise when using HTTP access to manage your router. First, any usernames and passwords are sent across the wire in clear text, along with any operations or commands executed. This presents a serious problem if a hacker is implementing an eavesdropping attack. You could get around the HTTP password issue by using token cards and a token card server, but all other information that you enter in the HTTP router session is sent in clear text. Therefore, never use HTTP across a public network to manage your router. On internal networks, make sure that you use authentication and filtering to restrict HTTP access to the router itself.
Second, because of many of the issues with HTTP itself, as well as the first item, I recommend that if you want to use a web browser for management purposes, either use HTTPS (discussed in the next section) or protect the HTTP connection with a VPN (discussed in Part VIII).
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.
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.
TIP
If you are concerned about the amount of administration but still want to use a CA for an additional level of protection, you can purchase CA services from companies such as Verisign (see http://www.verisign.com).
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 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.
NOTE
HTTP with SSL uses TCP port 443. If you are filtering traffic as it comes into your router, you need to allow this port connection.
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:
Router(config)# no ip http server
Router(config)# hostname router_name Router(config)# ip domain-name domain_name
Router(config)# ip http server-secure
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.
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.
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.
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:
Router(config)# clock timezone name offset Router(config)# exit Router# clock set hh:mm:ss day month year
Router(config)# hostname router_name Router(config)# ip domain-name domain_name
Router(config)# crypto key generate rsa
Router(config)# ip host CA_server's_name CA_server's_IP_address
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_#
Router(config)# crypto ca authenticate CA_server's_name
Router(config)# crypto ca enroll CA_server's_name
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:
Router(config)# no ip http server
Router(config)# ip http secure-server
Router(config)# ip http secure-client-auth
Router(config)# ip http secure-trustpoint CA_server's_name
When you are finished, open a web browser connection to your router, using this syntax in the web browser's URL address bar: