CCNP Security FIREWALL 642-618 Official Cert Guide (2012)

---

The test aaa-server command is the other principal method of verifying AAA functionality. Due to the importance of verifying successful authentication prior to configuring command authorization, this command was discussed and demonstrated earlier in this chapter.

Configuring Monitoring Using SNMP

The Cisco ASA supports network monitoring using SNMP versions 1, 2c, and 3 (not supported prior to OS version 8.2), and supports any combination of those being used simultaneously (that is, different monitoring platforms using different versions). As stated earlier, the ASA supports SNMP read-only access through the use of SNMP GET requests. SNMP write access is not allowed, so using SNMP SET requests or attempting to modify the configuration in any way using SNMP is not permitted.

The ASA can be configured to send SNMP traps, which are unsolicited messages from the managed device to a network management system (NMS) for certain events (event notifications). You can also use an NMS to browse the Management Information Bases (MIB) on the ASA. A MIB is a collection of information definitions, and the ASA maintains a database of values for each definition. Browsing a MIB requires using an NMS to determine values by issuing a series of GET-NEXT and/or GET-BULK requests of the MIB tree.

SNMP on the ASA requires client authentication. With SNMP version 1 or 2c, this is done by the NMS sending the proper community string (a password, sent in clear text) with its request. Such community strings can be set either as a default or uniquely per NMS IP address. SNMP version 3 can use strong, cryptographic protection for its information exchanges, and/or a combination of username and key for authentication.

To configure the ASA to permit NMS polling or sending of SNMP traps to an NMS, navigate to Configuration > Device Management > Management Access > SNMP to open the SNMP configuration window, shown in Figure 5-34.

Figure 5-34. SNMP Configuration Window

If the Community String (Default) field is left blank, this ASA will be configured with specific community strings on a per-IP-address basis. Contact and location information is entered only once, if completed, because this information refers to the ASA itself and does not change on a per-management-station basis. This ASA will listen on the default SNMP polling port of UDP 161, unless changed.

To add an NMS definition, click the Add button in the SNMP Management Stations area. This opens the Add SNMP Host Access Entry dialog box. If you are editing or deleting existing configured NMS definitions, use the Edit or Delete key. When adding or editing, configure the NMS definition according to the settings in your network. In Figure 5-34, the OOB management network attached to interface management is selected. The NMS IP address of 192.168.1.14 is defined. The default SNMP trap port of UDP 162 is left unaltered, a unique community string is defined for this NMS host, and the SNMP version is selected as version 2c.

Note that you can configure an SNMP host to perform polling, receive traps, or both by checking the appropriate box in this dialog box. Both choices are checked by default, as shown in Figure 5-34. Complete the NMS definition by clicking OK. If you select an interface other than “inside” for the sending of SNMP traps, you receive a warning message that this might be insecure. Acknowledge the message and complete the configuration by clicking Apply.

The CLI commands generated by the changes made are as follows:

snmp-server location 123 Any Street, 2nd Floor, Somewhere, USA
snmp-server contact Joe Admin (123) 555-1212
snmp-server host management 192.168.1.14 community SNMP1234 version 2c

If you are configuring the ASA from the CLI, you can enter these commands directly in global configuration mode.

The ASA can be configured to send several types of SNMP traps. If your local policy dictates, click the Configure Traps button in the SNMP configuration window to open the SNMP Trap Configuration dialog box, shown in Figure 5-35.

Figure 5-35. IDS and IPS Operational Differences

In Figure 5-35, in addition to the four standard SNMP traps (which are enabled by default), traps are enabled for IPsec Start and Stop and for Remote Access Session Threshold Exceeded. Complete the traps configuration by clicking OK and then clicking Apply. If you want to send SNMP traps as syslog messages, in addition to enabling syslog traps within the SNMP Trap Configuration screen, you need to configure a logging filter and destination in order to send traps (as syslog messages) to a configured syslog server. Configuration of logging is covered in Chapter 6, “Recording ASA Activity.”

The CLI commands generated by the changes made are as follows:

snmp-server enable traps ipsec start
snmp-server enable traps ipsec stop
snmp-server enable traps remote-access session-threshold-exceeded

If you are configuring the ASA from the CLI, you can enter these commands directly in global configuration mode.

If you are using SNMP version 3, you will need to configure SNMPv3 users and groups. This is the major difference between SNMPv3 and earlier versions. Groups define the protection model used for communication between the ASA and the NMS. The definition of groups and users allows for highly granular control over access to the SNMP agent and MIB objects.

Three SNMPv3 group definitions are supported by the ASA:

• No Authentication, No Encryption: Cleartext communication between the ASA and NMS

• Authentication Only: Communication is authenticated but unencrypted

• Authentication and Encryption: Authentication and full encryption for communication between the ASA and NMS

To use authenticated and/or encrypted communication, you need to configure the cryptographic keys and choose algorithms to authenticate and/or encrypt SNMP packets. These are symmetric keys and must be defined on both the ASA and the NMS.

To configure new SNMPv3 user information, from the SNMP configuration window, click Add in the SNMPv3 Users area to open the Add SNMP User Entry dialog box, shown in Figure 5-36. If you are editing or deleting existing configured users, use the Edit or Delete button.

Figure 5-36. Adding SNMPv3 User Information

In this case, an SNMPv3 group name of Authentication and Encryption is selected. The remote username is configured, and Clear Text is selected for Password Type. If Encrypted is selected here, both password fields must be completed with hexadecimal strings, in the format xx:xx:xx:.... Because Clear Text is selected, a plaintext password is entered for the password to be used with the selected Authentication Algorithm (you should prefer SHA over MD5). If AES is selected as the Encryption Algorithm, you must also select the size of the AES key, either 128-, 192-, or 256-bit (AES or 3DES is recommended). The encryption password is then entered, either in plaintext or hexadecimal format, once again depending on the Password Type selected. A maximum of 64 characters is allowed for either password. Complete the addition of the new user by clicking OKand then clicking Apply.

The CLI commands generated by the changes made are as follows:

snmp-server group Authentication&Encryption v3 priv
snmp-server user JoeAdmin Authentication&Encryption v3 auth B!u3V1c3r0y priv AES
128 H@nd$h@k3

If you are configuring the ASA from the CLI, you can enter these commands directly in global configuration mode.

The full syntax and options of the snmp-servers group command are as follows:

snmp-server group group-name {v3 {auth | noauth | priv }}

• auth: Specifies packet authentication without encryption.

• group-name: Defines the name of the group.

• noauth: Specifies no packet authentication or encryption.

• priv: Specifies both packet authentication and encryption.

• v3: Specifies the group is using the SNMP v3 security model, which is the most secure of the supported security models. This version allows you to explicitly configure authentication characteristics.

The full syntax and options of the snmp-server user command are as follows:

snmp-server user username group-name {v3 [encrypted] [auth { md5 | sha} auth-pass
word]} [priv {des | 3des | aes {128 | 192 | 256}} priv-password ]

• 128 | 192 | 256: Specifies the number of bits used by the AES algorithm for encryption.

• auth: Specifies which authentication algorithm should be used, when using authentication.

• auth-password: Specifies the string that enables the agent to receive packets from the ASA. The maximum length is 64 characters. You can specify a plaintext password or localized digest. The digest must be formatted as xx:xx:xx..., where xx are hexadecimal values. The digest should be exactly 16 octets in length.

• des | 3des | aes: Specifies encryption algorithm.

• encrypted: Specifies that the passwords appear in digest format, rather than plaintext.

• group-name: Specifies the name of the group to which the user belongs.

• md5 | sha: Specifies the authentication algorithm.

• priv-password: Specifies a string as the privacy user password. The maximum length is 64 characters. You can specify a plaintext password or a localized digest. The digest must be formatted as xx:xx:xx..., where xx are hexadecimal values. The digest should be exactly 16 octets in length.

• username: Specifies the name of the user on the host that connects to the agent.

• v3: Specifies that the SNMP Version 3 security model should be used. Allows the use of the encrypted, priv, and auth keywords.

Troubleshooting Remote Management Access

Most issues with remote management access appear in the ASA system log (or remote syslog server) depending on the severity level. Use the show logging command, use the ASDM real-time log viewer, or examine your centralized log files for such messages.

Some examples follow:

%ASA-3-710003: TCP access denied by ACL from 10.10.5.12/6724 to
inside:10.0.0.1/22

The preceding message indicates that management access rules do not permit the management session.

%ASA-3-315004: Fail to establish SSH session because RSA host key retrieval failed.
%ASA-3-315011: SSH session from 192.168.1.8 on interface management for user ""
disconnected by SSH server, reason: "Internal error" (0x00)

This message pair indicates that the local RSA key pair has not been generated, as required for the ASA SSH server.

If system log messages do not pinpoint the issue, consider debugging management protocols on the ASA, such as the following (note that some of these commands support different levels of debugging):

• debug ssh: Debugs the SSH daemon to determine low-level protocol failures, such as algorithm or version incompatibility

• debug http: Debugs HTTP exchanges to determine problems with the ASDM image

• debug snmp: Debugs SNMP exchanges to help determine problems with SNMP authentication and OIDs

To troubleshoot AAA for management access, you have to troubleshoot activity on both the ASA and, in the case of remote AAA, the AAA server.

The recommended troubleshooting task flow when troubleshooting local or remote AAA is as follows:

Step 1. For remote AAA, verify mutual reachability between the ASA and the server using ping, traceroute, show aaa-server, or similar tools. Also, verify that symmetrical session keys (shared secret) are used in the AAA protocol association.

Step 2. Verify the status of AAA authentication requests. Use show logging, debug aaa authentication, debug tacacs, and debug radius on the ASA. On the remote server, view failure reports and check for locked user accounts.

Step 3. Verify the AAA authorization process. In addition to the previously mentioned commands, use debug aaa authorization. Check the failure reports and verify user or group privileges on remote AAA servers.

Step 4. Verify that AAA accounting messages are properly being sent by the ASA, using the debug aaa accounting command, and received on the AAA server, by viewing its accounting reports.

The ASA logs many system messages related to the AAA subsystem. By using the show logging command, using the ASDM real-time log viewer, or examining logs in a centralized logging or management system, you may be able to pinpoint the cause of AAA issues.

Some examples follow:

%ASA-6-113015: AAA user authentication Rejected : reason = Invalid password :
local database : user = Administrator

The preceding message indicates that authentication failed due to bad credentials.

%ASA-6-113014: AAA authentication server not accessible : server = 192.168.1.5 :
user = Dave
%ASA-2-113022: AAA Marking TACACS+ server 192.168.1.5 in aaa-server group CP-
TACACS as FAILED

This message pair indicates that user authentication failed due to server communication failure.

%ASA-6-113004: AAA user authentication Successful : server = 192.168.1.5 :
user = Dave
%ASA-6-113005: AAA user authorization Rejected : reason = User was not found :
user = Dave

This message pair indicates that the user was not found in the authorization database (note that remote AAA was used for authentication, but authorization is checked against the local database).

Finally, you can debug protocol-level details to troubleshoot possible compatibility issues between your ASA and a remote AAA server by using the debug tacacs or debug radius commands. You can specify conditional debugging (such as limiting to a single username) to avoid excessive output and performance issues. Because much of the output uses terms that are unique to TACACS+ (“verbs”) and RADIUS (“attributes”), knowledge of these terms are necessary to properly interpret the debug output.

Unlocking Locked and Disabled User Accounts

A user account is normally locked when a configurable threshold of successive and unsuccessful login attempts have been made using that account.

If a local database user account becomes locked, and you need to unlock it, within ASDM, navigate to Monitor > Properties > Device Access > AAA Local Locked Out Users, as shown in Figure 5-37.

Figure 5-37. Unlocking Local User Accounts

If any local user accounts appear in the list of locked accounts, you may either select one account name and click the Clear Selected Lockout button to unlock a single account, or simply click the Clear All Lockouts button to remove the lock from all accounts.

Cisco ASA Password Recovery

If you lose the ability to gain management access to the ASA, either due to loss of necessary passwords or due to accidental lockout from the incorrect application of AAA functions, you can regain access to the ASA using a special procedure that can be performed only through the Serial console. Although this procedure is referred to as password recovery, it is not actually possible to “recover” lost passwords. Instead, you replace previously set passwords with new ones of your choosing.

Performing Password Recovery

To perform password recovery, connect to the serial console port of the ASA. Power cycle the ASA and watch the messages during boot. Two messages will appear, as follows:

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.

A 10-second countdown appears directly below these messages. Press the Esc key to interrupt the boot process and enter ROM Monitor (ROMMON) mode. From ROMMON mode, you set the configuration register value to instruct the ASA to bypass its startup configuration file (where passwords and AAA commands are stored), and reboot it. Example 5-13 shows the full procedure.

Example 5-13. Performing Password Recovery