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

Disabling Tab Completion of Zone Names

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

Enabling SSL Communication Channels

Regenerating SSL Certificates

Configuring SSH Communication Channels

Enabling an SSH2 Communication Channel

Regenerating SSH2 Communication Channel Keys

Managing SSH Keys

Adding SSH Keys

Deleting SSH Keys

Configuring the Keys for SFTP and SCP Connections

Changing the Hostname

Enabling SNMP Traps

Configuring SNMP Community Strings

Configuring the Login Banner

Configuring the Login Banner from the CLI

Importing the Login Banner

Deleting the Login Banner

Configuring the WBM Logo

Importing the WBM Logo

Deleting the WBM Logo

Configuring the Session Timeout

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

•Managing SSH Keys

•Configuring the Keys for SFTP and SCP Connections

•Changing the Hostname

•Enabling SNMP Traps

•Configuring SNMP Community Strings

•Configuring the Login Banner

•Configuring the WBM Logo

•Configuring the Session Timeout

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. See the "Establishing Communication with the Cisco Traffic Anomaly Detector Module" section for more information.
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	Secure Shell service. The SSH service is always active. See the "Accessing the Guard with SSH" section on page 3-19 and 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. See the "Managing the Guard with a Web-Based Manager" section on page 3-18 for more information.

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 Permit access to the Guard module service and enable connectivity by entering the following command in configuration mode:

permit {internode-comm | snmp-server | snmp-trap | ssh | wbm} 
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 controlling who is allowed to access the Guard module and what services are allowed after access. AAA provides the following features:

•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 establish the initial communication channel 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.

You cannot delete system user accounts.

User definition allows you to divide the Guard module user community into domains and to assign passwords for secure management access. We recommend that you create new user accounts and avoid 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 that 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, use 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 keywords 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 if 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. A 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 Passwords of Other Users

•Deleting a User from the Local User Database

Adding a User

To add a user to the Guard module local database, use 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	Provides access to all operations.
config	Provides access to all operations except for operations relating to user definition, deletion, and modification.
dynamic	Provides access to monitoring and diagnostics operations, protection, and learning-related operations. Users with Dynamic privileges can also configure flex-content filters and dynamic filters.
show	Provides access to monitoring and diagnostic operations.
password	(Optional) A password. Enter a case-sensitive 6- to 24-character 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, use the show running-config or show guard commands.

To display a list of the users currently logged into the CLI, use the show users command.

Changing Your Password

You can change your own password. Administrators can change their own password and the passwords of other users (see the "Changing the Passwords of Other Users" section).

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 Passwords 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 cannot 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, use the no username username command.

The following example shows how to delete a user from the local user database:

user@GUARD-conf# no username Robbin

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 permitted 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 using the copy running-config command permits executing 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.

To configure the Guard module to consider an authentication rejection as final and stop further searching with other TACACS+ servers or the local user database, you can configure the TACACS+ server attributes. See the "Configuring the TACACS+ Server Attributes" section for more information.

This section contains the following topics:

•Configuring Local Authorization

•Configuring Authorization Methods

•Disabling Tab Completion of Zone Names

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

You can set passwords that restrict access to user privilege levels. After you specify the privilege level and the password, you can give the password to the users who need to access this level. You cannot move to another user privilege level before you configure a password for that user privilege level.

To set a local password to control access to a privilege level, use 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: •admin—Provides access to all operations. •config—Provides access to all operations except for operations relating to user definition, deletion, and modification. •dynamic—Provides access to monitoring and diagnostics operations, protection, and learning-related operations. Users with Dynamic privileges can also configure flex-content filters and dynamic filters. •show—Provides access to monitoring and diagnostic operations. The default level is admin.
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:

•admin—Provides access to all operations.

•config—Provides access to all operations except for operations relating to user definition, deletion, and modification.

•dynamic—Provides access to monitoring and diagnostics operations, protection, and learning-related operations. Users with Dynamic privileges can also configure flex-content filters and dynamic filters.

•show—Provides access to monitoring and diagnostic operations.

The default level is admin.

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, use the command for each privilege level authorization required.
level	Defines authorization for the specified privilege level. The level can be one of the following: •admin—Provides access to all operations. •config—Provides access to all operations except for operations relating to user definition, deletion, and modification. •dynamic—Provides access to monitoring and diagnostics operations, protection, and learning-related operations. Users with Dynamic privileges can also configure flex-content filters and dynamic filters.
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 if 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 .*

	}

}

Disabling Tab Completion of Zone Names

To limit access to zone configuration to authorized users only, disable tab completion for the names of the zones. This setting applies to all commands in which you specify the zone name.

When you enter commands in global or configuration mode, such as the zone command, no zone command, show zone command, and deactivate command, the Guard module no longer displays or completes the zone name. You must enter the complete zone name to configure a zone, change the zone operation mode, or display zone statistics.

The Guard module sends the tab-complete zone-list command to the TACACS+ server when you disable tab completion of zone names. Configure authorization for the tab-complete zone-list command on the TACACS+ server to enable tab completion of zone names to authorized users.

The following example shows how to disable tab completion of zone names for all the zone commands:

user@GUARD-conf# aaa authorization commands zone-completion tacacs+

To enable tab completion of zone names, use the no form of the command.

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 by entering the following command 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.

To configure accounting for more than one privilege level, enter the aaa accounting command for each privilege level for which accounting is required.

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, use 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, use 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

To configure the Guard module to consider an authentication rejection as final and stop further searching with other TACACS+ servers and the local user database, use 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 you have not configured a local authentication method. 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, use 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, use 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, use 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, use the show tacacs statistics command in configuration mode.

To clear the TACACS+ statistics, use 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 Detector module establishes a connection with the Guard module to exchange the keys and certificates that are required to secure the communication channel. The Detector module then closes the connection and establishes the communication channel when it needs to activate the Guard module, synchronize a zone configuration with the Guard module, or poll the Guard module.

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 (called remote Guard lists) of Guard modules that it activates to protect a zone and synchronize zone information with these Guard modules. 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. If you configure an SSL remote Guard list and an SSH remote Guard list, you do not need to establish 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.

This section contains the following topics:

•Enabling SSL Communication Channels

•Regenerating SSL Certificates

Enabling SSL Communication Channels

To enable an SSL communication channel, perform the following steps on both the Guard module and the Detector module:

---

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.

---

---

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 permit 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 permit access to the Guard module.

---

---

Note The identity of the Guard module and the Detector module in the SSL certificates is associated with 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 associated with the IP addresses.

You must regenerate new SSL certificates for the Guard module and the Detector module on both ends of a communication channel when you:

•Change the IP address of one of the devices.

•Replace one of the devices.

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

To display the current SSL certificates, use the show internode-comm certs command.

To regenerate the current SSL certificates, perform the following procedure:

---

Step 1 From the Detector module, delete the SSL certificate of the Guard module by using the following command in configuration mode:

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 From the Guard module, delete the SSL certificate of the Detector module by using the following command in configuration mode:

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.

The following example shows how to delete an SSL certificate:

user@GUARD-conf# cert remove 10.56.36.4

Step 3 If you replace the Guard module, then you must also delete its SSH host key from the Detector module.

From the Detector module, use the following command in configuration mode to delete Guard module SSH host keys:

no host-keys ip-address-general

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

Step 4 To regenerate new SSL certificates, establish a new SSL communication channel between the Guard module and the Detector module. You must perform this action from the Detector module.

---

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.

•Monitor communication with the Guard module and notify you if remote actions fail, such as activating the Guard module to protect the zone.

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.

After you enable the SSH communication channel, you must establish the SSH communication channel from the Detector module.

This section contains the following topics:

•Enabling an SSH2 Communication Channel

•Regenerating SSH2 Communication Channel Keys

Enabling an SSH2 Communication Channel

To enable an SSH2 communication channel between a Guard module and a Detector module, permit access to the SSH service on the Guard module from the Detector module IP address by entering the permit ssh command.

---

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.

---

After you enable the SSH communication channel, you must establish the SSH communication channel from the Detector module.

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 a Guard module device, perform the following steps to regenerate a communication channel:

---

Step 1 Delete the SSH 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, use the show host-keys command.

Step 2 Configure the SSH key on the remote Guard by performing one of the following actions:

•Establish a new SSH2 communication channel from the Detector module.

•Add the Detector module public key Manually to the remote Guard. You can copy the Detector module public SSH key, and paste it into the list of SSH keys that the Guard module maintains.

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

To add the Detector module public SSH key to the list of SSH keys that the Guard module maintains, use the key add command on the Guard module. See the "Adding SSH Keys" section for more information.

---

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 manage 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-9 provides the arguments and keywords for the key add command.

Table 4-9 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, use the following command in configuration mode:

key remove [user-name] key-string

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

Table 4-10 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 Keys for SFTP and SCP Connections

Secure FTP (SFTP), which is layered on top of SSH2, and Secure Copy (SCP), which relies on SSH, provide a secure and authenticated method for copying files. SFTP and SCP use public key authentication and strong data encryption, which prevents login, data, and session information from being intercepted or modified in transit.

To configure the keys for SFTP and SCP connections, perform the following actions:

---

Step 1 Display the Guard module public key on the Guard module 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 on the Guard module by entering the key generate command in configuration mode.

If an SSH2 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, use the show public-key command in configuration mode.

Step 3 Copy the public key from the Guard module and paste it into the key file on the network server.

For example, if you are connecting to an network server that is installed on a Linux operating system with the username user account, add the Guard module public key to the /home/username/.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.

---

Note If you do not copy the public key and paste it into the key file on the network server, you cannot configure automatic export functions (such as the export reports command) and you have to enter your password each time you manually connect to the network server.

---

---

Changing the Hostname

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

To change the Guard module hostname, use 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 enable the Guard module to send SNMP traps and notify you 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-11 provides the arguments for the snmp trap-dest command.

Table 4-11 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 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, use 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-12 lists the SNMP traps that the Guard module generates.

Table 4-12 SNMP Traps 

SNMP Trap	Severity	Description
rhExcessiveUtilizationTrap	EMERGENCY	The Guard module cannot add new dynamic filters because more than 150,000 dynamic filters are active concurrently in all the Guard module zones.
rhExcessiveUtilizationTrap	EMERGENCY	The anomaly detection engine memory limit was reached (higher than 90 percent).
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.
rhExcessiveUtilizationTrap	CRITICAL	The Gigabit interface link utilization in bps1 is above 85 percent.
rhExcessiveUtilizationTrap	CRITICAL	The memory utilization is above 85 percent.
rhExcessiveUtilizationTrap	CRITICAL	The accelerator card CPU utilization is above 85 percent.
rhDynamicFilterTrap	ERROR	The number of pending dynamic filters is 1000, and new pending dynamic filters will be discarded.
rhZoneGenericTrap	ERROR	The Guard module failed to synchronize the zone configuration.
rhGeneralTrap	ERROR	The Guard module failed to activate zone protection as follows: •From protect or from learn to protect and learn •From protect and learn to protect or to learn The Guard module deactivates zone protection and the learning process.
rhDynamicFilterTrap	WARNING	The Guard module failed to add dynamic filters. •
rhExcessiveUtilizationTrap	WARNING	The Guard module has more than 135,000 dynamic filters that are active concurrently in all the zones. When the number of active dynamic filters reaches 150,00, the Guard module cannot add new 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.
rhReloadTrap	WARNING	The Guard module has restarted. The trap contains a MIB2 warm-start or cold-start trap and information on what caused the Guard module to restart.
rhReloadTrap	WARNING	The Guard module has shutdown. The trap contains a a MIB2 warm-start or cold-start trap and information on what caused the Guard module to shutdown.
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.

1 bps = bits per second

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, use 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

Configuring the Login Banner

The login banner is the text that appears on screen before user authentication when you open an SSH session, a console port connection, or a WBM session to the Guard module.

You can configure a login banner to warn users against unauthorized access, to describe what is considered the proper use of the system, and to warn users that the system is being monitored to detect improper use and other illicit activity.

The Guard module displays the login banner in the following locations:

•CLI—Before the password login prompt or as a popup (depending on the SSH client that you are using).

•WBM—On the right side of the Guard module login window.

This section contains the following topics:

•Configuring the Login Banner from the CLI

•Importing the Login Banner

•Deleting the Login Banner

Configuring the Login Banner from the CLI

You can create a single or multiple message banner by using the login-banner command. If you enter more than one login banner, the new login banner is appended to the existing login banner as a new line.

To configure the login banner, use the following command in configuration mode:

login-banner banner-str

The banner-str argument specifies the banner text. The maximum string length is 999 characters. If you use spaces in the expression, enclose the expression in quotation marks (" ").

To display the login banner, use the show login-banner command.

The following example shows how to configure and display the login banner:

user@GUARD-conf# login-banner "Welcome to the Cisco Anomaly Guard 
Module"

user@GUARD-conf# login-banner "Unauthorized access is prohibited."

user@GUARD-conf# login-banner "Contact sysadmin@corp.com for access."

user@GUARD-conf# show login banner

Welcome to the Cisco Anomaly Guard Module

Unauthorized access is prohibited.

Contact sysadmin@corp.com for access.

Importing the Login Banner

You can import a text file from a network server to replace the existing login banner by entering one of the following commands in global mode or in configuration mode:

•copy ftp login-banner server full-file-name [login [password]]

•copy {sftp | scp} login-banner server full-file-name login

The maximum length of each line in the file that you import is 999 characters.

Because Secure FTP (SFTP) and Secure Copy (SCP) rely on SSH for secure communication, if you do not configure the key that the Guard module uses before you enter the copy command with the sftp or scp option, the Guard module prompts you for the password. See the "Configuring the Keys for SFTP and SCP Connections" section for more information on how to configure the key that the Guard module uses for secure communication.

Table 4-13 provides the arguments and keywords for the copy login-banner command.

Table 4-13 Arguments and Keywords for the copy login-banner
Command 

Parameter	Description
ftp	The Guard module imports the login banner file from an FTP network server.
sftp	The Guard module imports the login banner file from an SFTP network server.
scp	The Guard module imports the login banner file from an SCP network server.
server	The IP address of the network server. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2).
full-file-name	The complete name of the file. If you do not specify a path, the server copies the file from your home directory.
login	The server login name. The login argument is optional when you define an FTP server. When you do not enter a login name, the FTP server assumes an anonymous login and does not prompt you for a password.
password	(Optional) The password for the remote FTP server. If you do not enter the password, the Guard module prompts you for it.

The following example shows how to import the login banner from an FTP server:

user@GUARD-conf# copy ftp login-banner 10.0.0.191 /root/login-banner 
<user> <password> 

Deleting the Login Banner

If you no longer want to display a message before user authentication, delete the login banner.

To delete the login banner, use the no login-banner command in configuration mode.

The following example shows how to delete the login banner:

user@GUARD-conf# no login-banner

Configuring the WBM Logo

To customize your end-user interface, you can add a company logo (or any customized logo) to the WBM web pages.

The new logo appears in the following places:

•On the Guard module login page, under the Cisco Systems logo.

•On all WBM pages, except for the Guard module login page, on the right side of the Cisco Systems logo.

The new logo must be in GIF format. We recommend that the size of the new logo is as follows: width = 87 and height = 41 pixels.

This section contains the following topics:

•Importing the WBM Logo

•Deleting the WBM Logo

Importing the WBM Logo

To import a new logo from a network server, use the following command in global mode or in configuration mode:

•copy ftp wbm-logo server full-file-name [login [password]]

•copy {sftp | scp} wbm-logo server full-file-name login

Because Secure FTP (SFTP) and Secure Copy (SCP) rely on SSH for secure communication, if you do not configure the key that the Guard module uses before you enter the copy command with the sftp or scp option, the Guard module prompts you for a password. See the "Configuring the Keys for SFTP and SCP Connections" section for more information on how to configure the key that the Guard module uses for secure communication.

Table 4-14 provides the arguments and keywords for the copy wbm-logo command.

Table 4-14 Arguments and Keywords for the copy wbm-logo
Command 

Parameter	Description
ftp	The Guard module imports the WBM logo file from an FTP network server.
sftp	The Guard module imports the WBM logo file from an SFTP network server.
scp	The Guard module imports the WBM logo file from an SCP network server.
server	The IP address of the network server. Enter the IP address in dotted-decimal notation (for example, enter 192.168.10.2).
full-file-name	The complete name of the file including the GIF file extension. If you do not specify a path, the server copies the file from your home directory.
login	The server login name. The login argument is optional when you define an FTP server. When you do not enter a login name, the FTP server assumes an anonymous login and does not prompt you for a password.
password	(Optional) The password for the remote FTP server. If you do not enter the password, the Guard module prompts you for it.

The following example shows how to import the WBM logo file from an FTP server:

user@GUARD-conf# copy ftp wbm-logo 10.0.0.191 /root/WBMlogo.gif <user> 
<password> 

Deleting the WBM Logo

To delete the WBM logo, use the no wbm-logo command in configuration mode.

The following example shows how to delete the login banner:

user@GUARD-conf# no wbm-logo

Configuring the Session Timeout

The session timeout is the amount of time that a session remains active when there is no activity. If there is no activity for the configured time, a timeout occurs, and then you must log in again. The session timeout is disabled by default.

The session timeout applies to the CLI only and does not apply to the WBM.

You can configure the number of minutes until the Guard module disconnects an idle session automatically by entering the following command in configuration mode:

session-timeout timeout-val

The timeout-val argument specifies the number of minutes until the Guard module disconnects an idle session automatically. Valid values are from 1 to 1440 minutes (one day).

The following example shows how to configure the Guard module to disconnect an idle session after 10 minutes:

user@GUARD-conf# session-timeout 10

To prevent the Guard module from disconnecting idle sessions automatically, use the no session-timeout command.

To display the value of the session timeout, use the show session-timeout command.