Table Of Contents

Configuring the Guard Module

Activating Guard Module Services

Configuring Access Control Using AAA

Configuring Authentication

Configuring Authentication Methods

Configuring Local Authentication

Configuring Authorization

Configuring Local Authorization

Configuring Authorization Methods

Configuring Accounting

Configuring the TACACS+ Server Attributes

Configuring a TACACS+ Server IP Address

Configuring the TACACS+ Server Encryption Key

Configuring the TACACS+ Search Method

Configuring the TACACS+ Server Connection Timeout

Displaying TACACS+ Server Statistics

Establishing Communication with the Cisco Traffic Anomaly Detector Module

Configuring SSL Communication Channels

Establishing SSL Communication Channels

Regenerating SSL Certificates

Configuring SSH Communication Channels

Establishing an SSH2 Communication Channel

Regenerating SSH2 Communication Channel Keys

Configuring a Date and a Time

Managing SSH Keys

Adding SSH Keys

Deleting SSH Keys

Configuring the Key for SFTP Connections

Changing the Host Name

Enabling SNMP Traps

Configuring SNMP Community Strings

Configuring the Guard Module

---

This chapter describes how to configure the Cisco Anomaly Guard Module (Guard module) services.

This chapter contains the following sections:

•Activating Guard Module Services

•Configuring Access Control Using AAA

•Establishing Communication with the Cisco Traffic Anomaly Detector Module

•Configuring a Date and a Time

•Managing SSH Keys

•Configuring the Key for SFTP Connections

•Changing the Host Name

•Enabling SNMP Traps

•Configuring SNMP Community Strings

Activating Guard Module Services

You can define which Guard module services are active. The service must be enabled, and access to the service must be permitted to enable proper functionality. You can control the activation of the Guard module services and grant or deny permission from a specific IP address, which will limit the IP addresses from which the Guard module is accessed and controlled.

Table 4-1 describes the Guard module services.

Table 4-1 Guard module Services 

Service	Description
internode-comm	Inter-node communication service. The Guard module uses this service when establishing a communication channel with the Cisco Traffic Anomaly Detector Module.
snmp-server	SNMP server service. You can access the Guard module using SNMP to retrieve information as defined by the Riverhead private MIB, MIB2 and UCDavis MIB. See the MIB file that is released with the software version for information on the MIB definitions. Note The Riverhead MIB contains 64-bit counters. To read the MIB, you must use a browser that supports SNMP version 2.
snmp-trap	SNMP trap service. When you activate the snmp-trap service, the Guard module generates SNMP traps. See the "Enabling SNMP Traps" section for more information.
ssh	Secured Shell service (see the "Managing SSH Keys" section for more information).
wbm	Web-based manager (WBM) service. You can control the Guard module from the web using a web browser.

To activate a Guard module service, perform the following steps:

---

Step 1 Enable the Guard module service by entering the following command in configuration mode:

service {internode-comm | snmp-server | snmp-trap | wbm}

See Table 4-1 for a description of the Guard module services. By default, all Guard module services, except SSH, are disabled.

Step 2 Grant access to the Guard module service and enable connectivity by entering the following command in configuration mode:

permit service ip-address-general [ip-mask]

Table 4-2 provides the arguments for the permit command.

Table 4-2 Arguments for the permit Command 

Parameter	Description
service	The service to be accessed and operated. See Table 4-1 for a description of the Guard module services.
ip-address-general	The IP address from which to permit access. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2). Use an asterisk (*) to permit access from all IP addresses.
ip-mask	(Optional) The IP subnet mask. Enter the subnet mask in dotted-decimal notation (for example, enter 255.255.255.0). The default subnet mask is 255.255.255.255.

---

---

Caution For security reasons, we do not recommend that you permit access to a service from all IP addresses (*).

---

The following example shows how to activate a service:

user@GUARD-conf# service wbm

user@GUARD-conf# permit wbm 192.168.10.35 

Configuring Access Control Using AAA

Authentication, Authorization, and Accounting (AAA) is a method for controling who is allowed to access the Guard module and what services are allowed after access. AAA provides the following:

•Authentication—Identifies a user before the user is allowed access to the system and system services.

•Authorization—Determines what a user is allowed to perform once access to the system is obtained. This process occurs after the user is authenticated.

•Accounting— Records what a user is performing or has performed. Accounting allows you to track the services that users are accessing.

The Guard module is preconfigured with the following system user accounts:

•admin—The admin user account is configured with the administration access rights, allowing access to the Guard module CLI and all its functionality. When connecting to the Guard module CLI for the first time, you are required to set a password for this account. Use the admin user account to configure additional user accounts.

•riverhead—The riverhead user account is configured with dynamic access rights. The Guard module uses this user account to communicate with the Cisco Traffic Anomaly Detector Module. When you connect to the Guard module CLI for the first time, you are required to set a password for this account.

---

Note The Cisco Traffic Anomaly Detector Module uses the riverhead username for remote activation of the Guard module.

---

You cannot delete system user accounts.

User definition enables you to divide the Guard module user community into domains, and to assign passwords as required for secure management access. We recommend that you create new user accounts and refrain from using the system user accounts after initial configuration so that you can monitor user actions.

The following sections describe how to configure access control:

•Configuring Authentication

•Configuring Authorization

•Configuring Accounting

•Configuring the TACACS+ Server Attributes

Configuring Authentication

You can configure which authentication method the Guard module uses when a user tries to log into the Guard module or requests a higher privilege level (using the enable command). The Guard module offers the following authentication options:

•Local authentication—Uses locally configured login and enable passwords for authentication. This authentication method is the default. See the "Configuring Local Authentication" section for more information.

•TACACS+ authentication—Authenticates users through a TACACS+ server or a list of TACACS+ servers.

If you configure a user only on a TACACS+ server, you must also configure authorization on the TACACS+ server for that user, or the user has access to show commands only.

You can configure a sequential authentication list. The authentication list defines the authentication methods used to authenticate a user, enables you to designate one or more methods to be used for authentication, and provides a backup if the initial method fails.

The Guard module uses the first authentication method that is on the sequential authentication list to authenticate users; if that authentication method does not respond, the Guard module selects the second authentication method on the list. Authentication fails only if both authentication methods do not succeed to authenticate the user.

You can configure a distributed authentication scheme and define users in several authentication databases. The Guard module uses the first TACACS+ server to authenticate users. If the authentication returns a rejection, the Guard module scans the TACACS+ server list and the alternative authentication method (local), if one exists. Authentication fails only if all the authentication methods on the list fail. This option is valid only if you do not configure the first-hit option.

---

Note If the user database is distributed between several TACACS+ servers or a TACACS+ server and the local user database, enter the no tacacs-server first-hit command or authentication fails after the first authentication method returns a rejection.

---

This section contains the following topics:

•Configuring Authentication Methods

•Configuring Local Authentication

Configuring Authentication Methods

To configure the authentication method that the Guard module uses, perform the following steps:

---

Step 1 Configure the TACACS+ server connection if TACACS+ authentication is required. See the "Configuring the TACACS+ Server Attributes" section for more information.

Step 2 Define the authentication method by entering the following command in configuration mode:

aaa authentication {enable | login} {local | tacacs+}  
[tacacs+ | local]

Table 4-3 provides the arguments for the aaa authentication command.

Table 4-3 Keywords for the aaa authentication Command 

Parameter	Description
enable	The Guard module authenticates on entering a higher privilege level.
login	The Guard module authenticates when logging into it.
local	The Guard module uses its local database to authenticate the user.
tacacs+	A TACACS+ server authenticates the user.
tacacs+ | local	(Optional) An alternative authentication method is set in case the configured method fails.

If you access the Guard module from a console session, it uses the local user database for authentication regardless of the defined authentication method.

To change the authentication method, reenter the command.

---

The following example shows how to configure authentication on entering a higher privilege level. The primary authentication method is configured to TACACS+, and the secondary authentication method is configured to the local user database.

user@GUARD-conf# aaa authentication enable tacacs+ local

Configuring Local Authentication

The Guard module initially has a preconfigured username with administration privileges, which allows you to create new users. User definition allows you to divide the Guard module user community into domains and to assign passwords for secure management access.

To enable authentication of CLI users with a TACACS+ server, see the "Configuring Authentication" section.

This section contains the following topics:

•Adding a User

•Changing Your Password

•Changing the Password of Other Users

•Deleting a User from the Local User Database

Adding a User

To add a user to the Guard module local database, enter the following command in configuration mode:

username username {admin | config | dynamic | show} [password]

Table 4-4 provides the arguments and keywords for the username command.

Table 4-4 Arguments and Keywords for the username
Command 

Parameter	Description
username	The username. A case-sensitive alphanumeric string from 1 to 63 characters that starts with an alphabetic letter. The string cannot contain spaces but can contain underscores.
admin | config | dynamic | show	The user privilege level. See Table 3-1 for more information.
password	(Optional) A password. Enter a case-sensitive, 6 to 24 characters long, string with no spaces. If you do not enter a password, you are prompted for it.

The following example shows how to configure a new user and set the password:

user@GUARD-conf# username Robbin config 1234

Users enter passwords in clear text but the Guard module configuration file displays passwords in an encrypted manner. This example displays the Guard module configuration file (running-config):

username Richard config encrypted 840xdMk3

The encrypted keyword in the previous example indicates that the password is encrypted.

To display the list of users configured on the Guard module, enter the show running-config or show guard commands. To display a list of the users currently logged-into the CLI, enter the show users command.

Changing Your Password

You can change your own password. Administrators can change their own password and any other user's password.

To change your own password, perform the following steps:

---

Step 1 Enter the following command in global mode:

password

Step 2 Enter your current password. The system prompts you for a new password.

Step 3 Enter a new password.

The password must be an alphanumeric, 6 to 24 character string, with no spaces. The password is case sensitive. The system prompts you to confirm the new password by typing it again.

---

The following example shows how to change your password:

user@GUARD# password 

Old Password: <old-password>

New Password: <new-password>

Retype New Password: <new-password>

Changing the Password of Other Users

You must have administration user privileges to change the password of other users.

To change the password of a user, perform the following steps:

---

Step 1 Enter the following command in global mode:

password username-password

The username-password argument is the user whose password you are changing.

Step 2 Enter a new password.

The password must be an alphanumeric, 6 to 24 character string, with no spaces. The password is case sensitive. The system prompts you to confirm the new password by typing it again.

---

The following example shows that the administrator changes the password of the user Jose.

user@GUARD# password Jose 

New Password: <new-password>

Retype New Password: <new-password>

Deleting a User from the Local User Database

When you delete a user from the local user database, the associated user can longer access the Guard module if authentication is performed using the local user database only.

To delete a user from the Guard module local user database, enter the no username username command.

Configuring Authorization

You can limit the services available to a user. When you enable authorization, the Guard module verifies the user profile, which is located either in the local user database or on a TACACS+ security server. The user is granted access to the requested service only if the information in the user profile allows it.

You can configure which authorization method the Guard module uses when a user tries to execute a command. The Guard module offers the following authorization options:

•TACACS+ authorization—Authorizes users through a TACACS+ server. Access to a subsequent server is initiated, if a server is defined, only if communication to a server fails.

Two types of TACACS+ authorization are supported:

–EXEC authorization—Determines the user privilege level once when the user is authenticated upon logging into the Guard module.

–Command authorization—Consults a TACACS+ server to get authorization for each command after the user enters the command.

TACACS+ authorization enables you to specify access rights for each command.

---

Caution We recommend that you limit authorization to the copy running-config command because authorizing the copy running-config command grants authorization to all configuration commands, regardless of whether you actually authorize every command in the configuration file.

---

•Local authorization—Uses locally configured user profiles for command group access control. Authorization is defined for all commands at the specified privilege level. This authorization method is the default.

Guard module local authorization can be performed when communication to the TACACS+ server fails.

You can configure a sequential authorization list that defines the methods for authorizing a user, allows you to designate one or more methods to be used for authorization, and provides a backup if communication to the initial method fails.

The Guard module uses the first method listed to authorize users; if that method does not respond, the Guard module selects the second authorization method. The authorization fails only If both authorization methods do not succeed.

This section contains the following topics:

•Configuring Local Authorization

•Configuring Authorization Methods

Configuring Local Authorization

Access to Guard services depends on the user privilege level. You can limit the services available to a user. The Guard module checks the user profile to verify the user access rights. Once authorized, the user is granted access to the requested service only if the information in the user profile allows it. See Table 3-1 for information on user privilege levels.

This section contains the following topics:

•Assigning Privilege Levels with Passwords

•Moving between User Privilege Levels

Assigning Privilege Levels with Passwords

An administrator can set passwords that restrict access to user privilege levels.

To set a local password to control access to a privilege level, enter the following command in configuration mode:

enable password [level level] [password]

Table 4-5 provides the arguments for the enable password command.

Table 4-5 Arguments for the enable password Command 

Parameter	Description
level level	(Optional) The user privilege level. The level can be one of the following levels: admin, config, dynamic, show. The default level is admin. See Table 3-1 for more information.
password	(Optional) The password for the privilege level. The password must be an alphanumeric, 6 to 24 character string, with no spaces. The password is case-sensitive. If you do not enter a password, you are prompted for it.

The following example shows how to assign a password to the user privilege level admin:

user@GUARD-conf# enable password level admin <password>

Moving between User Privilege Levels

Authorized users can move between user privilege levels.

To move between user privilege levels, perform the following steps:

---

Step 1 Enter the following command in global mode:

enable [level]

The level argument specifies the user privilege level. This level can be one of the following levels: admin, config, dynamic. The default level is admin. See Table 3-1 for more information.

Step 2 Enter the privilege level password.

---

The following example shows how to switch to the admin privilege level:

user@GUARD> enable admin 

Enter enable admin Password: <password>

To return to the lower privilege level (show), use the disable command.

Configuring Authorization Methods

To configure the authorization method, perform the following steps:

---

Step 1 Configure the TACACS+ server connection if TACACS+ authorization is required. See the "Configuring the TACACS+ Server Attributes" section for more information.

Step 2 Define the authorization method by entering one of the following commands in configuration mode:

•aaa authorization exec tacacs+

•aaa authorization commands level {local | tacacs+} [local]

You can configure a sequential list of authorization methods. Enter the aaa authorization command for each method. To remove an authorization method, use the no form of the command.

Table 4-6 provides the arguments and keywords for the aaa authorization command.

Table 4-6 Arguments and Keywords for the aaa authorization Command 

Parameter	Description
exec	Runs authorization to determine if the user is allowed to run an EXEC shell. The Guard module consults the TACACS+ server to determine the privilege level for an authenticated user. Caution You must configure the user on a TACACS+ server before you configure authorization or you may not be able to access the Guard module.
commands	Runs authorization for all commands at the specified privilege level. To configure authorization for more than one privilege level, enter the command for each privilege level authorization required.
level	Defines authorization for the specified privilege level. Valid entries are show, dynamic, config and admin. See Table 3-1 for information on user privilege levels.
local	Verifies the user access rights with the Guard module local database.
tacacs+	Verifies the user access rights with a TACACS+ server.
local	(Optional) Sets an alternative authorization method in case the configured method fails.

We recommend that you do not configure authorization for show privilege level commands because it may affect performance.

---

---

Note No TACACS+ authorization is performed for commands that you enter from console sessions.

---

The following example shows how to configure authorization for commands that require config privilege level. The primary authorization method is configured to TACACS+, and the secondary authorization method is configured to the local user database.

user@GUARD-conf# aaa authorization commands config tacacs+ local

---

Caution You must grant access to the dynamic user privilege level or specify access rights to the configure command to enable access to the configuration command mode.

---

TACACS+ Server Sample Configuration

You can specify authorization for each command in the TACACS+ server database.

The following example shows you how to configure authorization on a TACACS+ server for the user Zoe:

user=Zoe {

	cmd = protect {

		permit .*

	}

	cmd = "no protect" {

		permit .*

	}

	cmd = learning {

		deny policy*

	}

	cmd = "no learning" {

		deny .*

	}

	cmd = dynamic-filter {

		permit .*

	}

	cmd = "no dynamic-filter" {

		permit .*

	}

	cmd = flex-filter {

		deny .*

	}

	cmd = "no flex-filter" {

		deny .*

	}

}

Configuring Accounting

Accounting management allows you to track the services that users are accessing and save the accounting information on a TACACS+ server. You can enable accounting of requested services for billing, reporting, or security purposes. By default, the Guard module is configured with accounting management disabled.

To configure accounting, perform the following steps:

---

Step 1 Configure the TACACS+ server connection. See the "Configuring the TACACS+ Server Attributes" section for more information.

Step 2 Configure accounting for more than one privilege level by entering the command for each privilege level accounting required in configuration mode:

aaa accounting commands {show | dynamic | config | admin} stop-only 
{local | tacacs+} 

Table 4-7 provides the keywords for the aaa accounting command.

Table 4-7 Keywords for the aaa accounting Command 

Parameter	Description
show | dynamic | config | admin	Defines accounting for the specified privilege level (see Table 3-1 for information on user privilege levels).
stop-only	Records the action when the command execution terminates.
tacacs+	Uses a TACACS+ server database to record accounting information.
local	Does not save accounting information.

We recommend that you enable accounting management only for the config user privilege level because it may affect performance.

Use the no form of the command to remove the accounting management for a privilege level.

---

The example shows how to configure accounting for commands that require config privilege level on a TACACS+ server.

user@GUARD-conf# aaa accounting commands config stop-only tacacs+ 

Configuring the TACACS+ Server Attributes

You must configure the TACACS+ server attributes to enable authentication, authorization, or accounting with a TACACS+ server.

---

Caution You must configure the TACACS+ server attributes before you apply the TACACS+ authentication method or you may not be able to access the Guard module.

---

To configure the TACACS+ server attributes, perform the following steps:

---

Step 1 Configure the IP address of the TACACS+ server by entering the tacacs-server host ip-address command.

See the "Configuring a TACACS+ Server IP Address" section for more information.

Step 2 Configure the encryption key that the Guard module uses to access the TACACS+ server by entering the tacacs-server key tacacs-key command.

See the "Configuring the TACACS+ Server Encryption Key" section for more information.

Step 3 (Optional) Configure the search method that the Guard module uses for authentications by entering the tacacs-server first-hit command.

See the "Configuring the TACACS+ Search Method" section for more information.

Step 4 (Optional) Configure the TACACS+ server connection timeout by entering the tacacs-server timeout timeout command.

See the "Configuring the TACACS+ Server Connection Timeout" section for more information.

Step 5 Display the TACACS+ server connection statistics by entering the show tacacs statistics command.

See the "Displaying TACACS+ Server Statistics" section for more information.

---

The Guard module user privilege levels relate to the TACACS+ privilege numeration as follows:

•admin = 15

•config = 10

•dynamic = 5

•show = 0

Configuring a TACACS+ Server IP Address

You can configure the Guard module to use a sequential list of TACACS+ servers for authentication, authorization, and accounting. The Guard module uses the TACACS+ server listed to authenticate or authorize users or send an accounting event; if that server does not respond, the Guard module selects the second server. Authentication or authorization fails only if all servers listed do not respond.

Alternatively, you can configure the Guard module to use only the first TACACS+ server on the list to authenticate users (see the "Configuring the TACACS+ Search Method" section for more information).

You must define the IP address of each TACACS+ server on the list. You can define a maximum of nine TACACS+ servers.

To add a TACACS+ server to the list and assign its IP address, enter the following command in configuration mode:

tacacs-server host ip-address

The ip-address argument specifies the IP address of the TACACS+ server.

The TACACS+ servers are added to the list in the order in which you enter them. You can add a maximum of nine servers to the list.

The following example shows how to add a server to the TACACS+ server list:

user@GUARD-conf# tacacs-server host 192.168.33.45

Configuring the TACACS+ Server Encryption Key

You must configure the encryption key to access a TACACS+ server. The key must match the key on the TACACS+ servers. The key cannot contain spaces.

To configure the server encryption access key, enter the following command in configuration mode:

tacacs-server key tacacs-key

The argument tacacs-key is an alphanumeric string.

---

Note You can define only one encryption key. When using several TACACS+ servers, the Guard module uses the same key to encrypt communication with all TACACS+ servers.

---

The following example shows how to set the TACACS+ server encryption key to MyKey.

user@GUARD-conf# tacacs-server key MyKey

Configuring the TACACS+ Search Method

You can configure the Guard module to regard an authentication rejection as final and stop further searching with other TACACS+ servers or the local authentication method by entering the tacacs-server first-hit command. The Guard module performs user authentication using only the first TACACS+ server on the server list to respond. If the first TACACS+ server does not respond, the Guard module selects the next server on the list. The Guard module regards the first user authentication approval or rejection received as final and stops attempting to authenticate the user with other TACACS+ servers or with the local user database.

If you do not configure the TACACS+ search method to regard an authentication rejection as final by entering the tacacs-server first-hit command, the Guard module, by default, tries all TACACS+ servers in its list to authenticate a user. When you enable the first-hit search method for user authentication by entering the no tacacs-server first-hit command, the Guard module uses the first TACACS+ server listed to authenticate the user. If the first server does not respond or fails to authenticate the user, the Guard module selects the next server on the list. User authentication fails if all the TACACS+ servers on the list either do not respond or fail to authenticate the user and a local authentication method is not configured.

---

Note The TACACS+ search method is applicable for authentication only and does not affect authorization or accounting.

---

To configure the Guard module to use only the first TACACS+ server on the list to authenticate users, enter the tacacs-server first-hit command in configuration mode.

To disable the first-hit search method and enable the Guard module to try all TACACS+ servers in its list to authenticate a user, enter the no tacacs-server first-hit command in configuration mode.

The following example shows how to configure the TACACS+ search method so that the Guard module uses only the first TACACS+ server on the list to authenticate users:

user@GUARD-conf# tacacs-server first-hit

Configuring the TACACS+ Server Connection Timeout

You can configure the amount of time that the Guard module waits for a reply from the TACACS+ server. When the timeout ends, the Guard module either attempts to establish a connection with the next TACACS+ server (if a server was configured) or falls back to local AAA (if a fallback was configured). Authentication and authorization fail if no fallback method is configured.

---

Note The same server timeout is used for communication with all TACACS+ servers.

---

To configure the TACACS+ server connection timeout, enter the following command in configuration mode:

tacacs-server timeout timeout

The timeout argument specifies the amount of time (in seconds) that the Guard module waits for a TACACS+ server to reply. The default timeout is 0.

The following example shows how to configure the TACACS+ server connection timeout to 600 seconds:

user@GUARD-conf# tacacs-server timeout 600

---

Tip You may want to increase the timeout value if you have network problems or if the TACACS+ servers are slow to respond and cause persistent time-outs.

---

Displaying TACACS+ Server Statistics

You can display statistical information for the TACACS+ servers. The Guard module provides statistical data for each server.

To display TACACS+ related statistics, enter the show tacacs statistics command in configuration mode.

To clear the TACACS+ statistics, enter the clear tacacs statistics command in configuration mode.

Table 4-8 displays the fields in the show tacacs statistics command output.

Table 4-8 Field Descriptions in the show tacacs statistics Command Output 

Field	Description
PASS	The number of times that the Guard module accessed the TACACS+ server successfully and was granted access.
FAIL	The number of times that the Guard module accessed the TACACS+ server successfully and was denied access.
ERROR	The number of times that the Guard module could not access the TACACS+ server.

Establishing Communication with the Cisco Traffic Anomaly Detector Module

You can establish a secure communication channel between the Guard module and a Cisco Traffic Anomaly Detector Module (Detector module) to enable the following tasks:

•Remote activation of zone protection—When the Detector module detects a zone traffic anomaly, it uses the communication channel to activate a Guard module to protect the zone.

•Synchronization of zone configuration information—The Detector module and Guard module exchange zone configuration information over the communication channel.

The Guard module supports two types of communication channels:

•Secure Sockets Layer (SSL)—Enables remote activation of zone protection and Synchronization of zone configuration information.

•Secure Shell 2 (SSH2)—Enables remote activation of zone protection only.

The Detector module keeps a list of Guard modules that it activates to protect a zone and synchronize zone information with, which are called remote Guard lists. The Detector module establishes a communication channel with each of the Guard modules configured in the remote Guard lists.

The Detector module establishes an SSH2 communication channel with each Guard module, before establishing an SSL communication channel. Therefore, if you configure an SSL remote Guard list and an SSH remote Guard list, you do not need to configure the SSH2 communication channel because the SSL communication channel configures the SSH2 communication channel.

This section contains the following topics:

•Configuring SSL Communication Channels

•Configuring SSH Communication Channels

Configuring SSL Communication Channels

The Guard module and Detector module use a Secure Sockets Layer (SSL) connection for the communication channel. SSL provides secure connections through a combination of authentication and data encryption and relies upon digital certificates, private-public key exchange pairs, and Diffie-Hellman key agreement parameters for this level of security. SSL encrypts the data so that only the intended recipient can decipher the data.

Each Guard module and Detector module authenticates the device attempting to communicate with it over the communication channel using a digital certificate and other device-specific information, such as the device IP address.

To ensure a secure connection, the Detector module generates a private-public key pair and distributes its public key to the Guard modules listed in the remote Guard lists.

After you enable the communication channel service on the Guard module, you establish the communication channel from the Detector module. The Detector module first establishes an SSH2 communication channel with the user riverhead on the Guard module. The Detector module then uses the secure SSH2 communication channel to exchange the SSL connection keys. See the "Establishing Communication with the Cisco Traffic Anomaly Detector Module" section for more information.

This section contains the following topics:

•Establishing SSL Communication Channels

•Regenerating SSL Certificates

Establishing SSL Communication Channels

To establish an SSL communication channel between a Guard module and a Detector module, perform the following tasks:

1. Enable the communication channel service on both the Guard module and the Detector module.

2. Permit access to the communication channel service on both the Guard module and the Detector module.

3. Establish the communication channel from the Detector module.

The Detector module first establishes an SSH2 communication channel with the user riverhead on the Guard module. The Detector module then uses the secure SSH2 communication channel to exchange the SSL connection keys.

---

Caution If the Guard module is authenticating users using TACACS+ authentication, you must define the user riverhead on the TACACS+ server to enable the Detector module to establish the SSH2 communication channel.

---

To enable the communication channel on the Guard module, perform the following steps on the Guard module:

---

Note Use the same commands on the Detector module to enable the communication channel on the Detector module.

---

---

Step 1 Permit access to the SSH service on the Guard module from the Detector module IP address by entering the permit ssh ip-address-general [ip-mask] in configuration mode.

The arguments ip-address-general and ip-mask define the IP address of the Detector modules that you want to grant access to the Guard module.

---

Note You do not need to enable the SSH service because it is always enabled.

---

Step 2 Enable the communication channel service by entering the service internode-comm command in configuration mode.

Step 3 Permit access to the communication channel service from the Detector module IP address by entering the permit internode-comm ip-address-general [ip-mask] command in configuration mode.

The arguments ip-address-general and ip-mask define the IP address of the Detector modules that you want to grant access to the Guard module.

---

---

Note The identity of the Guard module and the Detector module in the SSL certificates is tied to the IP address. If you modify the IP address of the Guard module or of the Detector module at either end of the communication channel, you must regenerate the SSL certificates. See the "Regenerating SSL Certificates" section for more information.

---

Regenerating SSL Certificates

The key that identifies the Guard module and the Detector module in the SSL certificates is tied to the IP addresses.

You must generate new SSL certificates for the Guard module and the Detector module on both ends of a communication channel when you make one of the following changes:

•Change the IP address of one of the devices

•Replace (swap out) one of the devices

Before you can generate new SSL certificates, you must delete the current certificates on both devices.

To delete the current SSL certificates, perform the following steps:

---

Note You must perform this procedure on both the Guard module and the Detector module.

---

---

Step 1 Delete the SSL certificate of the Guard module from the Detector module by entering the following configuration mode command on the Detector module:

cert remove cert-host-ip

The cert-host-ip argument specifies the IP address of the Guard module. Enter an asterisk (*) to delete the SSL certificates of all Guard modules.

Step 2 Delete the SSL certificate of the Detector module from the Guard module by entering the following configuration mode command on the Guard module:

cert remove cert-host-ip

The cert-host-ip argument specifies the IP address of the Detector module. Enter an asterisk (*) to delete the SSL certificates of all Detector modules that have established communication channels with the Guard module.

Step 3 If you replace (swap out) the Guard module device, you must delete the Guard module SSH host key from the Detector module.

To delete SSH host keys listed on the Detector module, enter the following configuration mode command on the Detector module:

no host-keys ip-address-general

The ip-address-general argument specifies the IP address of the remote device.

Step 4 Establish a new SSL communication channel between a Guard module and a Detector module. See the "Establishing SSL Communication Channels" section for more information.

---

The following example shows how to delete an SSL certificate:

user@GUARD-conf# cert remove 10.56.36.4

Configuring SSH Communication Channels

When detecting traffic anomalies, the Detector module either logs the event, or activates a Guard module to protect the zone using an SSH communication channel. When using an SSH communication channel, the Detector module cannot perform the following tasks:

•Synchronize zone configuration.

•Monitor the Guard module to identify that an attack on the zone has ended. If you enable anomaly detection and the learning process, the Detector module cannot identify that an attack on the zone has ended and does not continue to learn the zone traffic after activating a remote Guard.

To ensure a secure SSH2 communication channel, the Detector module generates a private-public SSH key pair and distributes the public SSH key to the Guard modules listed in the remote Guard lists.

This section contains the following topics:

•Establishing an SSH2 Communication Channel

•Regenerating SSH2 Communication Channel Keys

Establishing an SSH2 Communication Channel

To establish an SSH2 communication channel between a Guard module and a Detector module, you must perform the following tasks:

1. Permit access to the SSH service on the Guard module from the Detector module IP address by entering the permit ssh command.

2. Establish the SSH communication channel from the Detector module.

---

Caution If the Guard is authenticating users using TACACS+ authentication, you must define the user riverhead on the TACACS+ server to enable the Detector module to establish the SSH2 communication channel.

---

If you replace (swap out) a Guard module device, you must regenerate the SSH2 communication channel. See the "Regenerating SSH2 Communication Channel Keys" section.

Regenerating SSH2 Communication Channel Keys

If you replace (swap out) a Guard module device, perform the following steps to establish a new SSH2 communication channel:

---

Step 1 Delete the SSH2 host key from the Detector module by entering the no host-keys ip-address-general configuration mode command on the Detector module.

The ip-address-general argument specifies the IP address of the remote device.

To display the host keys listed on the Guard module, enter the show host-keys command.

Step 2 Perform one of the following actions:

•Establish a new SSH communication channel from the Detector module (see the "Establishing an SSH2 Communication Channel" section)

OR

•Manually add the Detector module public key to the remote Guard.

To display the Detector module public SSH key, enter the show public-key command on the Detector module.

To configure the Detector module public SSH key, enter the key add command on the Guard module.

---

Configuring a Date and a Time

To set the time and the date, enter the following command in configuration mode:

date MMDDhhmm[[CC]YY][.ss]

Table 4-9 provides the arguments and keywords for the date command.

Table 4-9 Arguments for the date Command 

Parameter	Description
MM	The month in numeric figures.
DD	The day of the month.
hh	The hour in a 24 hour clock.
mm	The minutes.
CC	(Optional) The first two digits of the year (for example, 2005).
YY	(Optional) The last two digits of the year (for example, 2005).
.ss	(Optional) The seconds (the decimal point must be present).

The following example shows how to configure the date to October 8 of the year 
2003, and the time to 5:10 pm (1710) and 17 seconds:

user@GUARD-conf# date 1008171003.17

Wed Oct  8 17:10:17 EDT 2003

Managing SSH Keys

The Guard module supports SSH for secure remote login. You can add a list of SSH keys to enable secure communication from a remote device to the Guard module without entering a login and password.

The following sections describe how you can manipulate the Guard module SSH key list:

•Adding SSH Keys

•Deleting SSH Keys

Adding SSH Keys

To enable an SSH connection without entering a login and password, add the remote connection SSH public key to the Guard module SSH key list.

Enter the following command in configuration mode:

key add [user-name] {ssh-dsa | ssh-rsa} key-string comment

Table 4-10 provides the arguments and keywords for the key add command.

Table 4-10 Arguments and Keywords for the key add
Command 

Parameter	Description
user-name	(Optional) Adds the SSH key for the specified user. Only an administrator can add an SSH key for other users. The default is to add the SSH key for the current user.
ssh-dsa	SSH2-DSA key type.
ssh-rsa	SSH2-RSA key type.
key-string	The public SSH key that was created on a Cisco Traffic Anomaly Detector Module or remote terminal. The key string is limited to 8192 bits. You must copy the complete key excluding the key type identification (ssh-rsa or ssh-dsa).
comment	The device description. The comment format is usually in the format of user@hostname for the user and machine used to generate the key. For example, the default comment used for the SSH public keys that the Cisco Traffic Anomaly Detector Module generates is root@DETECTOR.

The following example shows how to add an SSH RSA key:

user@GUARD-conf# key add ssh-rsa 14513797528175730. . .user@Guard 
module.com

Deleting SSH Keys

You can remove an SSH key from the list. If you remove the SSH key, you must authenticate the next time that you establish an SSH session with the Guard module.

To remove an SSH key from the Guard module, enter the following command in configuration mode:

key remove [user-name] key-string

Table 4-11 provides the arguments for the key remove command.

Table 4-11 Arguments for the key remove Command 

Parameter	Description
user-name	(Optional) Removes SSH keys for the specific user. Only an administrator can delete an SSH key for other users. The default is to delete the SSH key for the current user.
key-string	The public SSH key to delete. Paste the SSH public key onto the prompt. Paste only the key, without the identification field (ssh-rsa or ssh-dsa).

The following example shows how to view a user key so that it can be cut and pasted into the key remove command:

user@GUARD-conf# show keys Lilac

ssh-rsa 2352345234523456... user@Guard module.com

user@GUARD-conf# key remove Lilac 2352345234523456...

Configuring the Key for SFTP Connections

The Guard module supports Secure FTP (SFTP) layered on top of SSH2. SFTP uses public key authentication and strong data encryption, which prevents login, data, and session information from being intercepted or modified in transit.

To configure the public key on the SFTP server, perform the following actions on the Guard module:

---

Step 1 Display the Guard module public key by entering the show public-key command in configuration mode.

If the key exists, skip Step 2 and proceed to Step 3.

If no key exists, proceed to Step 2.

Step 2 Generate a private-public key pair be entering the key generate command in configuration mode.

If an SSH key pair already exists, the following message appears:

/root/.ssh/id_rsa already exists.

Overwrite (y/n)? 

Type y to regenerate the key.

The Guard module creates the public-private key pair. To display the Guard module public key, enter the show public-key command in configuration mode.

Step 3 Copy the public key and paste it into the key file on the SFTP server.

For example, if you are connecting to an SFTP server that is installed on a Linux operating system with user root, add the Guard module public key to the /root/.ssh/authorized_keys2 file.

Make sure that the key is copied as a single line. If the key is copied as two lines, delete the new line character at the end of the first line.

---

Changing the Host Name

You can change hostname of the Guard module. The change takes effect immediately, and the new host name is automatically integrated into the CLI prompt string.

To change the Guard module hostname, enter the following command in configuration mode:

hostname name

The name argument specifies the new hostname.

The following example shows how to change the hostname of the Guard module:

user@GUARD-conf# hostname CiscoGuard

admin@CiscoGuard-conf# 

Enabling SNMP Traps

You can configure the Guard module to send SNMP traps and notify the manager of significant events that occur on the Guard module. In addition, you can configure the Guard module SNMP trap generator parameters and define the scope of the SNMP trap information that the Guard module reports.

A trap is logged in the Guard module event log and displayed in the event monitor when a trap condition occurs, regardless of whether the SNMP agent sends the trap.

To configure the Guard module to send SNMP traps, perform the following steps:

---

Step 1 Enable the SNMP trap generator service by entering the following command in configuration mode:

service snmp-trap

Step 2 Configure the SNMP trap generator parameters (the trap destination IP address and the trap information scope) by entering the following command:

snmp trap-dest ip-address [community-string [min-severity]]

Table 4-12 provides the arguments for the snmp trap-dest command.

Table 4-12 Arguments for the snmp trap-dest Command 

Parameter	Description
ip-address	The destination host IP address.
community-string	(Optional) The community string that is sent with the trap. This string must match the community string defined for the destination host. The default community string is public. Enter an alphanumeric string from 1 to 15 characters. The string cannot contain spaces.
min-severity	(Optional) The trap information scope. Define the scope by stating the minimum severity level coverage. The trap then displays all specified severity level events and above. For example, if you specify severity level Warnings, the trap displays all severity level events from Warnings to Emergencies. The following list states the severity level options: •Emergencies—System is unusable (severity=0). •Alerts—Immediate action needed (severity=1). •Critical—Critical conditions (severity=2). •Errors—Error conditions (severity=3). •Warnings—Warning conditions (severity=4). •Notifications—Normal but significant conditions (severity=5). •Informational—Informational messages (severity=6). •Debugging—Debugging messages (severity=7). By default, the report displays all severity level events.

---

To delete SNMP trap generator parameters, enter the no snmp trap-dest command. Enter an asterisk (*) to remove all SNMP trap destination parameters.

The following example shows that traps with a severity level equal to or higher than errors are sent to the destination IP address 192.168.100.52 with the SNMP community string of tempo:

user@GUARD-conf# snmp trap-dest 192.168.100.52 tempo errors 

Table 4-13 lists the SNMP traps that the Guard module generates.

Table 4-13 SNMP Traps 

SNMP Trap	Severity	Description
rhGeneralTrap	EMERGENCY	The Guard module failed to activate zone protection by using the packet activation method, and will send subsequent traps with an ALERT severity level.
rhGeneralTrap	EMERGENCY	The Guard module failed to activate diversion.
rhGeneralTrap	EMERGENCY	The Guard module restored diversion.
rhGeneralTrap	ALERT	The Guard module failed to activate zone protection by using the packet activation method, and a trap with an EMERGENCY severity level was already generated.
rhGeneralTrap	ALERT	The disk space is 80 percent.
rhZoneGenericTrap	ERROR	The Guard module failed to synchronize the zone configuration.
rhGeneralTrap	ERROR	The Guard module failed to activate zone protection.
rhDynamicFilterTrap	WARNING	The Guard module failed to add dynamic filters.
rhGeneralTrap	WARNING	The disk space is 75 percent.
rhPolicyConstructionTrap	WARNING	The policy construction phase of the learning process has failed.
rhProtectionTrap	WARNING	The Guard module failed to start zone protection.
rhThresholdTuningTrap	WARNING	The threshold tuning phase of the learning process has failed.
rhAttackTrap	NOTIFICATIONS	An attack has started.
rhAttackTrap	NOTIFICATIONS	An attack has ended.
rhPolicyConstructionTrap	NOTIFICATIONS	The policy construction phase of the learning process has been started.
rhPolicyConstructionTrap	NOTIFICATIONS	The policy construction phase of the learning process has been accepted.
rhPolicyConstructionTrap	NOTIFICATIONS	The policy construction phase of the learning process has been stopped.
rhProtectionTrap	NOTIFICATIONS	The zone protection has started.
rhProtectionTrap	NOTIFICATIONS	The zone protection has ended.
rhThresholdTuningTrap	NOTIFICATIONS	The threshold tuning phase of the learning process has been started.
rhThresholdTuningTrap	NOTIFICATIONS	The threshold tuning phase of the learning process has been accepted.
rhThresholdTuningTrap	NOTIFICATIONS	The threshold tuning phase of the learning process has been stopped.
rhZoneGenericTrap	NOTIFICATIONS	The Guard module has started to synchronize the zone configuration.
rhZoneTrap	NOTIFICATIONS	A new zone has been created.
rhZoneTrap	NOTIFICATIONS	A zone has been deleted.
rhDynamicFilterControlTrap	INFO	The number of attack-detection events that the Guard module did not send for a specific policy.
rhDynamicFilterControlTrap	INFO	The Guard module has more than 1000 active dynamic filters, and will not send traps for dynamic filters that it deletes.
rhDynamicFilterTrap	INFO	A dynamic filter has been added.
rhDynamicFilterTrap	INFO	A dynamic filter has been deleted.
rhDynamicFilterTrap	INFO	A pending dynamic filter has been added.

Configuring SNMP Community Strings

You can access the Guard module SNMP server and retrieve information as defined by the Management Information Base 2 (MIB2) and the Cisco Riverhead proprietary MIB. The community string acts like a password and permits read access from the Guard module SNMP agent. You can configure the Guard module SNMP community string and enable access to the SNMP agent from clients in different organizational units and with different community strings.

To add an SNMP community string, enter the following command in configuration mode:

snmp community community-string

The community-string argument specifies the desired Guard module community string. Enter an alphanumeric string from 1 to 15 characters. The string cannot contain spaces. The Guard module default community string is riverhead. You can specify as many community names as you want. To delete a community string, use the no community string command. Enter an asterisk (*) to remove all SNMP community strings.

The following example shows how to configure the SNMP community string:

user@GUARD-conf# snmp community tempo