4-4. Managing Administrative Sessions Administrators and firewall users can open interactive sessions with a firewall using any of the following methods: The following sections provide information about the configuration and use of these methods. Console Connection Most Cisco firewall and security appliances have a physical console connection that can be used to access a user interface. The console port is an asynchronous serial interface operating at 9600 baud. Because of its relatively slow speed, the console should be used only to initially configure the firewall or to access it over an out-of-band connection as a last resort. Because the FWSM is integrated into a Catalyst 6500 or 7600 switch chassis, it doesn't have a readily accessible console port. It does have an emulated console connection you can reach from the switch user interface by specifying the FWSM module number in the following command: Switch# session module
The console port is always active and cannot be disabled. When a user connects to the console port with a terminal emulator, the firewall immediately begins at the unprivileged or user EXEC level. To use any type of administrative or configuration commands, the console user must move into privileged EXEC or enable mode. Best practice dictates having the firewall close any user session that has been idle for a period of time. By default, console connections never idle out. You can change this behavior with the following configuration command: FWSM 2.x | | PIX 6.x | Firewall(config)# console timeout minutes | PIX 7.x | Firewall(config)# console timeout minutes |
Here, minutes is the idle time value from 0 (no idle timeout; the default) to 60 minutes. You can also configure various methods to authenticate users who connect to the console port. Chapter 5, "Managing Firewall Users," covers these methods in greater detail. Telnet Sessions Remote administrators can connect to the firewall using Telnet. Telnet sessions use TCP port 23 and provide the standard firewall command-line interface. Accessing the firewall through Telnet has the following characteristics: Up to five different Telnet sessions can be open to the firewall concurrently. Telnet access is much more efficient than the firewall's console port. Large amounts of output can be displayed without imposing a heavy load on the firewall CPU. Information sent over a Telnet connection is not secure. No data encryption or authentication is used. (SSH is a more secure alternative.) Telnet access is permitted on "internal" firewall interfaces if the firewall is configured to do so. The firewall does not permit inbound Telnet connections on its outside interface unless IPSec is configured on that interface for a secure VPN connection.
To configure Telnet operation, use the following configuration steps: 1. | Allow incoming Telnet connections on an interface:
FWSM 2.x | Firewall(config)# telnet ip_address netmask if_name | PIX 6.x | Firewall(config)# telnet ip_address [netmask] [if_name] | PIX 7.x | Firewall(config)# telnet ip_address netmask if_name |
By default, no Telnet connections are permitted. This command permits inbound Telnet connections from the source addresses defined by ip_address and netmask. The inbound firewall interface is specified as if_name (inside or dmz, for example). You can repeat this command to define multiple Telnet sources.
PIX 6.x allows these parameters to be optional. If no interface name is given, the firewall allows Telnet connections from the source address on all its interfaces except the outside. PIX 7.x, however, is more specific and requires all the options to be given with the command.
For example, the following command permits inbound Telnet from a host at 192.168.4.13 and the subnet 192.168.177.0/24 on the inside interface:
Firewall(config)# telnet 192.168.4.13 255.255.255.255 inside Firewall(config)# telnet 192.168.177.0 255.255.255.0 inside
| 2. | (Optional) Set the Telnet idle timeout:
FWSM 2.x | Firewall(config)# telnet timeout minutes | PIX 6.x | Firewall(config)# telnet timeout minutes | PIX 7.x | Firewall(config)# telnet timeout minutes |
By default, Telnet sessions are automatically closed if they have been idle for 5 minutes. You can change the idle timeout period to minutes (PIX 7.x and FWSM 2.x: 1 to 1440 minutes, or 24 hours; PIX 6.x: 1 to 60 minutes).
|
SSH Sessions Remote administrators can also connect to the firewall using SSH. SSH sessions use TCP port 22 and provide the standard firewall CLI. Accessing the firewall through SSH has the following characteristics: Up to five different SSH sessions can be open to the firewall concurrently. An SSH session offers a Telnet look and feel while offering a high level of security. SSH can be permitted on any firewall interface, including the outside. A firewall can support two versions of SSH: SSHv1 (PIX 6.x, PIX 7.x, and FWSM 2.x) and SSHv2 (PIX 7.x only). SSHv2 offers data integrity and encryption that is superior to SSHv1.
TIP SSH sessions always require a username and password for authentication. If no specific authentication method is configured other than a basic password, or if the configured AAA authentication servers are unreachable, you can use username pix and the normal EXEC-level password set with the passwd command.
To configure SSH operation, use the following configuration steps: 1. | Generate an RSA key pair.
An RSA key pair is needed as a part of the SSH security mechanisms. By default, no RSA keys exist in a firewall, so they must be created and saved.
Define a domain name for the firewall: FWSM 2.x | Firewall(config)# domain-name name | PIX 6.x | Firewall(config)# domain-name name | PIX 7.x | Firewall(config)# domain-name name |
The domain name is given as name (a text string up to 63 characters). This is usually the domain name of the organization or enterprise where the firewall is located, although you can use any arbitrary name. Because the domain name is included in the RSA key pair computation, you should try to use a name that will be stable over time. Otherwise, the RSA keys must be rebuilt with any new domain name configured later. Compute the RSA key pair: FWSM 2.x | Firewall(config)# ca generate rsa key [modulus] | PIX 6.x | Firewall(config)# ca generate rsa key [modulus] | PIX 7.x | Firewall(config)# crypto key generate rsa general-keys [modulus modulus] |
A general-purpose RSA key pair is computed with a modulus or length of modulus bits (512, 768, 1024, or 2048; the default is 768). Generally, a greater modulus provides more security because it makes reversing the key operations more difficult. Longer keys also take longer to generate, requiring more firewall CPU resources. This isn't a critical issue, however, because RSA keys are generated only once or only after long periods of time. As a compromise, the current industry best practice recommends a modulus of 1024 bits. If you don't define a domain name before using this command, a default domain name (ciscofwsm.com on an FWSM or ciscopix.com on a PIX or ASA) is used. Save the RSA key information: FWSM 2.x | Firewall(config)# ca save all | PIX 6.x | Firewall(config)# ca save all | PIX 7.x | |
The contents of the RSA key pair are not saved as a part of the firewall configuration. Instead, they must be saved into a private Flash memory area. In PIX 7.x, the RSA keys are automatically saved each time they are generated.
TIP You can display the public portion of an RSA key pair with the following commands: FWSM 2.x | Firewall# show ca mypubkey rsa | PIX 6.x | Firewall# show ca mypubkey rsa | PIX 7.x | Firewall# show crypto key mypubkey rsa |
If the firewall's domain name ever changes, the RSA key pair must be cleared and rebuilt. You can use the following commands to clear the stored key pair: FWSM 2.x | Firewall# ca zeroize rsa | PIX 6.x | Firewall# ca zeroize rsa | PIX 7.x | Firewall# crypto key zeroize rsa default |
Repeat Steps 1a through 1c to regenerate a new key pair based on the new domain name. | 2. | Allow incoming SSH connections on an interface:
FWSM 2.x | Firewall(config)# ssh ip_address netmask if_name | PIX 6.x | Firewall(config)# ssh ip_address [netmask] [if_name] | PIX 7.x | Firewall(config)# ssh ip_address netmask if_name |
By default, no SSH connections are permitted. This command permits inbound SSH connections from the source address given by ip_address and netmask on the firewall interface named if_name (inside or outside, for example).
In PIX 6.x, if the netmask is omitted, a host mask of 255.255.255.255 is assumed. If the if_name is omitted, the firewall automatically duplicates this command for each of its active interfaces.
You can repeat this command to define multiple SSH sources and source interfaces.
| 3. | (Optional) Specify the supported SSH versions:
FWSM 2.x | | PIX 6.x | | PIX 7.x | Firewall(config)# [no] ssh version {1 | 2} |
In releases before PIX 7.0, SSHv1 is the only version that is supported. Beginning with PIX 7.0, both versions 1 and 2 are supported by default.
This command can be used to restrict SSH support to only a single version, either version 1 or 2. To return to the default where both versions are allowed, use the no ssh version command with no other arguments.
You can see what SSH versions are currently allowed by using the show ssh command. In the following example, SSH support starts with only version 1. The firewall is configured back to the default for versions 1 and 2. Then only version 2 is configured.
Firewall# show ssh Timeout: 30 minutes Versions allowed: 1 172.21.4.0 255.255.255.0 outside 172.21.6.0 255.255.255.0 outside Firewall# configure terminal Firewall(config)# no ssh version Firewall(config)# Firewall# show ssh Timeout: 30 minutes Versions allowed: 1 and 2 172.21.4.0 255.255.255.0 outside 172.21.6.0 255.255.255.0 outside Firewall# configure terminal Firewall(config)# ssh version 2 Firewall(config)# Firewall# show ssh Timeout: 30 minutes Version allowed: 2 172.21.4.0 255.255.255.0 outside 172.21.6.0 255.255.255.0 outside Firewall#
| 4. | (Optional) Set the SSH idle timeout:
FWSM 2.x | Firewall(config)# ssh timeout minutes | PIX 6.x | Firewall(config)# ssh timeout minutes | PIX 7.x | Firewall(config)# ssh timeout minutes |
|
SSH sessions idle out after 5 minutes by default. You can change the idle timeout to minutes (1 to 60). PDM/ASDM Sessions You can also manage, configure, and monitor a firewall through a web-based application. PDM and ASDM are two of the supported applications. Each one runs from an image stored on the firewall itself which was made available through an embedded web server. The web-based management application is named differently for the various firewall platforms: PDM 3 (PIX 500 series running PIX 6.3), PDM 4 (FWSM), and ASDM 5.0 (PIX and ASA platforms running PIX 7.0). You can use the following steps to configure and prepare a firewall for PDM or ASDM use: 1. | Identify the PDM/ASDM image to use:
FWSM 2.x | | PIX 6.x | | PIX 7.x | Firewall(config)# asdm image device:/path |
In releases before PIX 7.0, the ASDM image is always stored in a fixed location in Flash memory. For example, PIX 6.3 uses Flash file 3. Beginning with PIX 7.0, you can specify the Flash device (flash:/, disk0:/, or disk1:/) and path to the ASDM image file. If the firewall is in multiple-context security mode, you can use this command only from the system execution space.
In the following example, the ASDM image file is stored as flash:/asdm.bin (flash:/ is also disk0:/ on this platform):
Firewall# dir flash:/ Directory of disk0:/ 10 -rw- 8688476 06:25:20 Dec 21 2004 asdm.bin 11 -rw- 5031936 06:12:14 Dec 21 2004 image.bin 62881792 bytes total (44142592 bytes free) Firewall# configure terminal Firewall(config)# asdm image disk0:/asdm.bin
| 2. | Install the PDM/ASDM image file.
You can copy a PDM or ASDM image file into a firewall's Flash memory with the following commands:
FWSM 2.x | Firewall# copy tftp[:[[//location][/pathname]]] flash:pdm | PIX 6.x | Firewall# copy tftp[:[[//location][/pathname]]] flash:pdm | PIX 7.x | Firewall# copy url device:/path |
Before PIX 7.0, the PDM image file was automatically stored in the correct location. Therefore, only the flash:pdm destination was needed.
Beginning with PIX 7.0, the ASDM image file can be stored anywhere in Flash memory and can have an arbitrary filename. You can have one or more ASDM image files stored in Flash at any time, provided that there is sufficient storage space, but only one of them may be used to run the application.
The source url can be one of the following:
ftp://[user[:password]@]server[:port]/[path/]filename[;type=xy] tftp://[user[:password]@]server[:port]/[path/]filename http[s]://[user[:password]@]server[:port]/[path/]filename
If the server requires user authentication, you can specify the user ID and password in the user:password@ format. Section 4-2, "Managing the Flash File System," provides more details about copying files into Flash memory.
The destination must be a local Flash device: (flash:/, disk0:/, or disk1:/). The ASDM image can be stored in a specific path name, given by /path, or in the location defined in Step 1, given by the pdm keyword. Using the pdm keyword is easier, because the ASDM image file always is written to the current location and overwrites an existing file if one is present.
| 3. | Permit incoming access.
PDM and ASDM are web-based applications. Therefore, clients must connect to an HTTP server that is embedded in the firewall.
Identify client locations: FWSM 2.x | Firewall# http ip_address subnet_mask if_name | PIX 6.x | Firewall# http ip_address [subnet_mask] [if_name] | PIX 7.x | Firewall# http ip_address subnet_mask if_name |
Only source or client addresses that fall within the address range given by ip_address and subnet_mask and are located on the firewall interface named if_name (outside, for example) are allowed to connect to the firewall's HTTP server. Beginning with PIX 7.0, all the arguments are required and must be given in the command. Prior releases allow optional arguments. For example, if the subnet mask is omitted, a host mask of 255.255.255.255 is assumed. If the interface name if_name (outside, for example) is omitted, the inside interface is assumed. NOTE After you have configured access to the HTTP server, you don't also have to add anything to any of the firewall's access lists. Inbound HTTP access to the firewall itself is permitted on the appropriate interface(s) automatically. Enable the embedded HTTP server: FWSM 2.x | Firewall# http server enable | PIX 6.x | Firewall# http server enable | PIX 7.x | Firewall# http server enable |
|
Starting the PDM or ASDM Application from a Web Browser To run PDM or ASDM from a web browser, point your web browser to the following URL: https://ip_address[/admin]
The ip_address is the address (or host name) of the firewall interface that is configured to allow HTTP server connections. The /admin portion of the URL is applicable only to firewalls running PIX 7.0 or later. If the WebVPN feature is also enabled, the security appliance's default web page (https://ip_address) is devoted to WebVPN services rather than ASDM. In this case, you can differentiate between the services by using a more specific URL: NOTE Your browser must allow popups from the firewall's address, because PDM/ASDM is automatically started in a new browser window. As well, PDM/ASDM runs as a Java applet that is downloaded from the firewall. Your browser must support Java so that the applet can be run.
As PDM or ASDM begins, you need to authenticate as an administrative user. The firewall can have an authentication method that is specific to HTTP connections, configured with the aaa authentication http console command. Depending on the configuration, you need to use one of the following credentials: Default authentication No usernames are defined or used. Therefore, leave the username field blank and enter the enable password. Local authentication Usernames are used and are defined locally on the firewall with the username command. Enter a valid username that can use privilege level 15 (enable or privileged EXEC mode) and the appropriate password. AAA authentication Usernames are used and are defined on external AAA servers. Enter a valid username that can use privilege level 15 (enable or privileged EXEC mode) and the appropriate password.
TIP When the PDM or ASDM application connection is initiated, the firewall sends its self-signed SSL certificate to your web browser. Sometimes a browser cannot verify the certificate because the firewall is not known as a trusted certificate authority. If this happens, you likely will see a message from the web browser. You can choose to accept the certificate temporarily or permanently if you are comfortable that you are connecting to the correct firewall. You can check the firewall's identity by viewing the certificate; the Common Name (CN) attribute is made up of the firewall's host name and domain name. You might also see an error regarding a domain name mismatch. If the firewall's interface IP address is not registered in a DNS, the browser cannot confirm that its IP address and certificate CN (fully qualified domain name) correlate. If you are comfortable with the mismatch, you can choose to continue.
Starting ASDM from a Local Application Beginning with PIX 7.0, you can run ASDM from a web browser or from a "launcher" application that has been downloaded directly to your PC. The first time you use ASDM, you should point your web browser to the following URL: https://ip-address/admin
This brings up a web page where you can choose the ASDM access method. Figure 4-8 shows an example of this opening page. Figure 4-8. Initial ASDM Launch Page 
Running ASDM as a local application is usually better because you can use one common program on your PC to access one or more firewalls running PIX 7.x. The application also maintains a drop-down list of firewall addresses where you have connected in the past, making it easy to select a target firewall without having to use browser bookmarks or enter URLs. When the local application is installed, an installer file is downloaded, as shown in Figure 4-9. The installer runs automatically. Figure 4-9. Local ASDM Application Installation 
To run the ASDM launcher application, start the local Cisco ASDM Launcher program. On a Windows PC, it can be found on the Start menu under Programs > Cisco ASDM Launcher. When the launcher starts, it displays a drop-down list of firewall addresses it knows about. Select an address from the list and enter your authentication credentials. Figure 4-10 shows an example of the launcher application. Figure 4-10. Local ASDM Launcher Application 
After you have authenticated, the firewall downloads the most current ASDM application code to your PC via the launcher application. This means the local application rarely needs to be updated. Instead, the PC is always kept current with the actual ASDM software that is contained in the firewall's ASDM image. As soon as ASDM launches, it looks like the window shown in Figure 4-11. Figure 4-11. Sample ASDM Session 
User Session Banners You can configure a banner of text that the firewall will display to any administrative users. You can use the following three types of banners: Message of the Day (MOTD) An informational message that is shown before the login prompt in a Telnet, SSH, or console session. This might include network news, access policy information, or legal warnings to be presented to potential users. Login A message that is shown after the MOTD prompt and just before the firewall login prompt. This might be useful to show a name, location, or other access parameters. Exec A message that is shown just after a user successfully logs in and reaches EXEC mode. This might be useful if you need to present some final words of caution or a warning to the user who has just logged in and is about to view or change something on the firewall. To configure one of these banners, use the following configuration command:
Firewall(config)# banner {exec | login | motd} text
Here, the banner is created one line of text at a time. Don't enclose the text in quotation marks; the text begins after the banner type keyword and ends at the end of the line. Repeat this command for subsequent lines of the banner. You can't edit a banner; you have to delete the entire banner with the no banner {exec | login | motd} command and re-enter it. To delete banners of all types, you can use the clear banner (PIX 6.x and FWSM 2.x) or clear configure banner (PIX 7.x) command. You can also customize the banner's appearance by including the firewall's host name or domain name. This is done automatically by inserting the token strings $(hostname) and $(domain) within the banner text. The firewall substitutes the current values configured by the hostname and domain-name commands. TIP If you decide to use banners on your firewall, be careful what information you include. Remember that the MOTD and login banners are displayed as soon as a Telnet or SSH session connection is opened to the firewallwhether someone can log in or not. That means if someone can initiate a Telnet session and see the login prompt, he can also see any detailed banner information that might reveal the firewall's location, model, software version, and so on. Also be careful when you craft a banner message. Most security and legal experts advise against using any type of "Welcome" or "Greetings" message, because this might be used against you. Malicious users might try to suggest that you welcomed them into your firewall! For some best-practice recommendations, refer to http://www.cisco.com/warp/public/707/21.html#warning.
Monitoring Administrative Sessions Having a console interface and network access, a firewall can allow several people to be connected at any time. You can monitor all the active Telnet sessions on a firewall with the EXEC command who, which provides a list of Telnet session numbers along with the originating IP address, as in the following example: Firewall# who 1: 172.21.4.16 Firewall#
If you need to close a Telnet session that is either hung or unwanted, use the who command to find the session's index number. Then use the kill telnet_id privileged EXEC command, where telnet_id is the session index, to terminate that session immediately and without warning. For example, the following commands could be used to end the Telnet session coming from IP address 10.6.6.6: Firewall# who 0: From 10.10.10.71 1: From 192.168.199.4 2: From 10.6.6.6 Firewall# kill 2
You can also monitor active SSH sessions with this EXEC command: Firewall# show ssh sessions
For example, a generic user ("pix") has several SSH sessions open. Notice that SSH version 1 is actually shown as version 1.5. Version 1.5 is commonly used with Cisco IOS software and has several security fixes beyond that of version 1.0. Firewall# show ssh sessions SID Client IP Version Mode Encryption Hmac State Username 0 172.21.4.14 1.5 - 3DES - SessionStarted pix 1 172.21.4.14 2.0 IN aes256-cbc sha1 SessionStarted pix OUT aes256-cbc sha1 SessionStarted pix 2 172.21.4.14 1.5 - 3DES - SessionStarted pix 3 172.21.4.14 1.5 - 3DES - SessionStarted pix 4 172.21.4.14 1.5 - 3DES - SessionStarted pix
You can disconnect an active or hung SSH session with the following command: Firewall# ssh disconnect session-id
To display the active PDM or ASDM management application sessions, you can use the following command: Firewall# show pdm sessions
You can disconnect an active PDM session with the following command: Firewall# pdm disconnect session-id
TIP A firewall can also generate an audit trail that shows user activity. To do this, logging must be enabled on the firewall. See Chapter 9, "Firewall Logging," for logging configuration details. User authentication messages are generated at Syslog severity 6 (Informational). This also includes SSH and PDM sessions. User privilege level event messages are generated at Syslog severity 5 (Notification). Firewall commands executed by users are logged at Syslog severity 5 (Notification), and show commands executed are logged at Syslog severity 7 (Debugging).
|
