Table Of Contents

Configuring the Guard

Activating Guard Services

Configuring Access Control

Configuring Authentication

Configuring Authentication Methods

Configuring Local Authentication

Configuring Authorization

Configuring Local Authorization

Configuring Authorization Methods

Configuring Accounting

Configuring TACACS+ Server Connection

Configuring TACACS+ Server IP Address

Configuring TACACS+ Server Encryption Key

Configuring TACACS+ Search

Configuring TACACS+ Server Connection Timeout

Displaying TACACS+ Server Statistics

Viewing the Guard Configuration

Configuring Date and Time

Synchronizing the Guard Clock with an NTP Server

Managing SSH Keys

Adding SSH Keys

Deleting SSH Keys

Changing the Host Name

Enabling SNMP Traps

Configuring SNMP Community Strings

Guard Self-Protection

Flex Filter Default Configurations

Configuring the Guard

---

This chapter describes how to configure the Cisco Guard (Guard). These configuration procedures lay the foundation for Guard management and diversion related communication.

This chapter includes the following major sections:

•Activating Guard Services

•Configuring Access Control

•Viewing the Guard Configuration

•Configuring Date and Time

•Managing SSH Keys

•Changing the Host Name

•Enabling SNMP Traps

•Configuring SNMP Community Strings

•Guard Self-Protection

•Flex Filter Default Configurations

Activating Guard Services

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

The Guard services include the following:

•ntp—The Network Time Protocol (NTP) service. The Guard provides a time synchronization service. This capability enables to synchronize the Guard with a Time Synchronization Server.

---

Note To enable time synchronization you must configure an NTP server. See the Table 3-8"Synchronizing the Guard Clock with an NTP Server" section for further details.

---

•snmp-server—The Simple Network Management Protocol (SNMP) server service. You can access the Guard using SNMP to retrieve information as defined by the Riverhead Management Information Bases (Riverhead private MIB, MIB2 and UCDavis MIB).

•snmp-trap—The Simple Network Management Protocol (SNMP) trap service. On Activation of the snmp-trap service, the Guard generates snmp traps. See the "Enabling SNMP Traps" section for further details.

•ssh—The Secured Shell service (see the "Changing the Host Name" section for further details)

•wbm—The Web Based Management (WBM) service. The Guard enables the user to control it via the web using a web browser.

To activate a Guard service perform the following steps:

---

Step 1 Enable the Guard service. Enter the following:

service {ntp | snmp-server | snmp-trap | wbm}

---

Note By default, all Guard services, except SSH, are disabled.

---

Step 2 Grant access to the Guard service and enable connectivity. Enter the following:

permit service ip-addr [ip-mask]

Table 3-1 provides the arguments for the permit command.

Table 3-1 Arguments for the permit Command 

Parameter	Description
service	The service to be accessed and operated.
ip-addr	The IP address to permit access from. Use * to permit access from all IP addresses.
ip-mask	(Optional) The IP mask. The default subnet mask is 255.255.255.255

---

---

Caution For security reasons, we do not recommend that you permit access from all IP addresses (*) after initial configuration.

---

For example:

admin@GUARD-conf# service ntp

admin@GUARD-conf# permit ntp 192.168.10.35 

Configuring Access Control

Access control is the way you control who is allowed access to the network server and what services they are allowed to use once they have access. Authentication, Authorization, and Accounting (AAA) network security services provide the primary framework through which you set up access.

•Authentication—The way a user is identified prior to being allowed access the system and system services.

•Authorization—The process of determining what a user is allowed to perform once access to a system is obtained. This is usually done once the user is authenticated and begins to manipulate the system.

•Accounting—The act of recording what a user is performing or has performed. Accounting enables you to track the services users are accessing.

The following sections describe how to configure access control:

•Configuring Authentication

•Configuring Authorization

•Configuring Accounting

•Configuring TACACS+ Server Connection

Configuring Authentication

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

•Local Authentication—Local authentication uses locally configured login and enable passwords for authentication. This is the default authentication method. See the "Configuring Local Authentication" section for further details.

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

You can configure a sequential authentication list. The authentication list defines the authentication methods used to authenticate a user. This enables you to designate one or more methods to be used for authentication. Thus, a backup system for authentication is provided, in case the initial method fails.

The Guard uses the first method listed to authenticate users; if that method does not respond, the Guard selects the second authentication method. Only if both authentication methods are exhausted, the authentication fails.

You can configure a distributed authentication scheme. The Guard uses the first TACACS+ server to authenticate users. If the authentication returns a rejection, the Guard scans the TACACS+ server list and the alternative authentication method (local), if one exists. Only if the list is exhausted, the authentication fails. This option is valid only if you do not configure the first-hit option.

---

Caution 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.

---

Configuring Authentication Methods

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

---

Step 1 Configure the TACACS+ server connection if TACACS+ authentication is required. See the "Configuring TACACS+ Server Connection" section for further details.

Step 2 Define the authentication method. Enter the following:

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

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

Table 3-2 Keywords for the aaa authentication Command 

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

---

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:

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

Configuring Local Authentication

The Guard initially has a preconfigured user name with administrator privileges, which enable you to create new users. User definition enables you to divide the Guard user community into domains, and to assign passwords as required for secure management access.

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

Adding a User

To add a user to the Guard local database, enter the following:

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

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

Table 3-3 Arguments and Keywords for the username Command 

Parameter	Description
username	The user name. An alphanumeric string starting with a letter. The string cannot hold spaces, and is limited to a length of 63 characters. The string can contain underscores.
admin | config | dynamic | show	The user's privilege level. See Table 2-4 for further details.
password	A password (Optional). The password must be 6 to 24 characters with no spaces. If you do not enter a password, you will be prompted for it.

For example:

admin@GUARD-conf# username Robbin config 1234

---

Note The running config file displays the username command with the option encrypted:
username Jose config encrypted 840xdMk3

The encrypted option indicates that the password is encrypted and saved. The Guard displays the encrypted password and not the password you enter to log in.

---

To remove a user from the Guard user list, enter the following:

no username username

---

Tip To view a list of the Guard users use the show running-config command. To view a list of the users currently logged-into the CLI, use the show users command.

---

Changing a Password

You can change your own password. An administrator 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:

password

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

Step 3 Enter a new password. The password must be 6 to 24 characters with no spaces. The system prompts you to confirm the new password by typing it again.

---

For example:

admin@GUARD# password 

Old Password: <old-password>

New Password: <new-password>

Retype New Password: <new-password>

An administrator can change the password of other users.

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

---

Step 1 Type the following at the Global prompt:

password username-password

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

Step 2 Enter a new password. The password must be 6 to 24 characters with no spaces. The system prompts you to confirm the new password by typing it again.

---

In this example, the administrator changes the password of the user John.

admin@GUARD# password Jose 

New Password: <new-password>

Retype New Password: <new-password>

Configuring Authorization

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

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

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

Two kinds of TACACS+ authorization are supported: Exec authorization determines a user privilege level when they are authenticated; Command authorization consults a TACACS+ server to get authorization for commands once the user enters them.

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

---

Caution You should grant authorization to the copy running-config ftp command with care.
Authorization to execute it grants authorization to all configuration commands, regardless of whether you authorize each and every command in the configuration file.

---

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

You can configure a sequential authorization list. The authorization list defines the authorization methods used to authorize a user. This enables you to designate one or more methods to be used for authorization. Thus, a backup system for authorization is provided, in case communication to the initial method fails.

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

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

Configuring Local Authorization

Access to Guard services depends on the user privilege level. You can limit the services available to a user. The Guard checks the user's profile to verify the user's access rights. Once authorized, the user is granted access to the requested service only if the information in the user's profile allows it. See Table 2-4 for information on 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:

enable password [level level] [password]

Table 3-4 provides the arguments and keywords for the enable password command.

Table 3-4 Arguments for the enable password Command 

Parameter	Description
level	(Optional) The required privilege level. This can be one of the following: admin, config, dynamic, show. See Table 2-4 for further details. The default level is admin.
password	(Optional) The privilege level's password. The password must be 6 to 24 characters with no spaces. If you do not enter a password, you will be prompted for it.

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:

enable [level]

The argument level specifies the required privilege level. This can be one of the following: admin, config, dynamic. The default level is admin. See Table 2-4 for further details.

Step 2 Enter the privilege level's password.

---

For example:

admin@GUARD> enable admin 

Enter enable admin Password: <password>

To switch back 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 TACACS+ Server Connection" section for further details.

Step 2 Define the authorization method. Enter the following:

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

You can configure a sequential list of authorization methods. Enter the aaa authorization command for each method.

Table 3-5 provides the arguments and keywords for the aaa authorization command.

Table 3-5 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 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.
commands	Runs authorization for all commands at the specified privilege level. To configure authorization for more than one privilege level, issue the command for each privilege level authorization required.
level	Define authorization for the specified privilege level. Valid entries are show, dynamic, config and admin. See Table 2-4 for information on user privilege levels.
local	The Guard uses its local database for authorization.
tacacs+	A TACACS+ server verifies the user access rights.
local	This sets an alternative authorization method in case the configured method fails (Optional).

---

---

Note No TACACS+ authorization is performed for commands entered 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.

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

---

Note You must grant access to the user privilege level of dynamic 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.

For example:

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 usage of Guard resources. You can track the services users are accessing and save the accounting information on a TACACS+ server.

To configure the accounting, perform the following steps:

---

Step 1 Configure the TACACS+ server connection. See the "Configuring TACACS+ Server Connection" section for further details.

Step 2 To configure accounting for more than one privilege level, issue the command for each privilege level accounting required. Enter the following:

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

Table 3-6 provides the arguments and keywords for the aaa accounting command.

Table 3-6 Keywords for the aaa accounting Command 

Parameter	Description
show | dynamic | config | admin	Define accounting for the specified privilege level. See Table 2-4 for information on user privilege levels.
stop-only	Sends a stop accounting notice at the end of the requested user process.
tacacs+	A TACACS+ server database is used for accounting.
local	Accounting information is not saved.

---

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

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

Configuring TACACS+ Server Connection

You must configure the TACACS+ server parameters prior to applying the TACACS+ authentication method. The TACACS+ server configuration includes the following:

•Server address (or addresses)—See the "Configuring TACACS+ Server IP Address" section

•Server encryption key—See the "Configuring TACACS+ Server Encryption Key" section

•Search—See the "Configuring TACACS+ Search" section

•Server access timeout—See the "Configuring TACACS+ Server Connection Timeout" section

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

•admin = 15

•config = 10

•dynamic = 5

•show = 0

Configuring TACACS+ Server IP Address

You can configure a sequential list of TACACS+ servers used for AAA. The Guard uses the TACACS+ server listed to authenticate users; if that server does not respond, the Guard selects the second server. Only if all servers listed are exhausted, AAA fails.

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

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

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

tacacs-server host ip-address

The argument ip-address 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 up to nine servers to the list.

For example:

admin@GUARD-conf# tacacs-server host 192.168.33.45

Configuring TACACS+ Server Encryption Key

You must configure the encryption key to access a TACACS+ server. The key entered as part of the command must match the key on the TACACS+ servers. The key can not contain spaces.

To configure the server encryption access key, enter the following:

tacacs-server key tacacs-key

The argument tacacs-key is an alphanumeric string.

---

Note Only one encryption key can be defined when using several TACACS+ servers. This key is used to encrypt communication with all TACACS+ servers.

---

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

admin@GUARD-conf# tacacs-server key MyTacacsKey

Configuring TACACS+ Search

You can configure the Guard to regard an authentication rejection as final and stop further search with other TACACS+ servers or the local authentication method. The Guard, in this case, does not fall back to the local authentication method, and does not move on to the next configured TACACS+ server (if one exists).

TACACS+ search method is applicable only for authentication.

To configure the Guard to use only the first TACACS+ server on the list to authenticate users, enter the following:

tacacs-server first-hit

For example:

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

---

Note If you do not configure the TACACS+ search method to first-hit, the Guard, by default, tries all TACACS+ servers in its list to authenticate a user.

---

Configuring TACACS+ Server Connection Timeout

You can configure the timeout for the Guard to wait for the TACACS+ server's reply. When the timeout ends, the Guard either attempts to establish a connection with the next TACACS+ server (if such a server was configured) or falls back to local AAA (if such 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:

tacacs-server timeout timeout

The argument timeout specifies the timeout in seconds.

For example:

admin@GUARD-conf# tacacs-server timeout 600

---

Tip You can increase the timeout value if you have network problems or if TACACS+ servers are slow to respond, causing persistent timeouts when a lower timeout value is used.

---

Displaying TACACS+ Server Statistics

You can display statistical information related to the TACACS+ servers. Statistical data is provided for each server and includes the following fields:

•PASS—The number of times the service accessed the TACACS+ server successfully and was granted access

•FAIL—The number of times the service accessed the TACACS+ server successfully and was denied access

•ERROR—The number of times the service could not access the TACACS+ server

To display TACACS+ related statistics, use the show tacacs statistics command.

To clear the TACACS+ statistics, use the clear tacacs statistics command.

Viewing the Guard Configuration

You can display the Guard configuration file. This file includes information relating to the Guard configuration such as: interface addresses, the Guard proxy address, default Gateway address, etc.

To display the Guard configuration file, enter the following:

show running-config [all | Guard | interfaces interface-name | router | self-protection | zones]]

Table 3-7 provides the arguments and keywords for the show running-config command.

Table 3-7 Arguments and Keywords for the show running-config Command 

Parameter	Description
all	Displays configuration files of all Guard modules (Guard, zones, interfaces, router and self-protection)
Guard	Displays Guard configuration file
interfaces	Displays the configuration file of the Guard interfaces. Enter the interface name.
router	Displays the router configuration
self-protection	Displays Guard self-protection configuration
zones	Displays the configuration files of all zones

For example:

admin@GUARD# show running-config guard

The configuration file consists of the commands that are executed to configure the Guard with the current settings. You can export the Guard configuration file to a remote FTP server for backup purposes, or to enable implementing the Guard configuration parameters on another Guard. See the "Displaying the Log-file" section for further details.

Configuring Date and Time

To set the time and the date, enter the following:

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

Table 3-8 provides the arguments and keywords for the date command.

Table 3-8 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.
YY	(Optional) The last two digits of the year.
.ss	(Optional) The seconds. The period 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.

admin@GUARD-conf# date 1008171003.17

Wed Oct  8 17:10:17 EDT 2003

Synchronizing the Guard Clock with an NTP Server

You can also configure the Guard's system clock to synchronize with a time server. To configure the Guard clock to synchronize with an NTP server, perform the following steps:

---

Step 1 Configure the date and time locally. Enter the following:

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

See the "Configuring Date and Time" section for further details.

Step 2 Configure the Guard system time zone. Enter the following:

timezone timezone-name

The argument timezone-name specifies the name of the desired time zone. The name is composed of continent /city:

The continent options are:

•Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia, Europe, Indian, Pacific

•Etc—A wild card for a desired timezone

---

Tip The time zone name is case sensitive. Type the desired continent name and press TAB twice for a list of relevant cities.

---

Step 3 Enable the NTP service. Enter the following:

service ntp

Step 4 Grant access to the NTP service from a network address. Enter the following:

permit ntp ip-address

Step 5 Configure the IP address of the desired NTP server. Enter the following:

ntp server ip-address

The argument ip-address specifies the NTP server IP address.

You must reload the Guard configuration.

---

For example:

admin@GUARD-conf# date 1008171003.17

admin@GUARD-conf# timezone Africa/Timbuktu 

admin@GUARD-conf# service ntp

admin@GUARD-conf# permit ntp 192.165.200.224

admin@GUARD-conf# ntp server 192.165.200.224 

Managing SSH Keys

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

•Adding SSH Keys

•Deleting SSH Keys

Adding SSH Keys

To enable SSH connection without the need to enter a login and password, add the remote connection SSH public key to the Guard SSH key list.

Enter the following:

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

Table 3-9 provides the arguments and keywords for the key add command.

Table 3-9 Arguments and Keywords for the key add Command 

Parameter	Description
user-name	(Optional) Add 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 | ssh-rsa	SSH key type. The Guard supports SSH2-DSA and SSH2-RSA.
key-string	The Public SSH key that was created on the Detector 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 the Detector generates is root@DETECTOR.

For example:

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

Deleting SSH Keys

You can remove an SSH key from the list. If you remove the SSH key, you will have to authenticate the next time you establish an SSH session with the Guard.

To remove an SSH key from the Guard, enter the following:

key remove [user-name] key-string

Table 3-10 provides the arguments and keywords for the key remove command.

Table 3-10 Arguments for the key remove Command 

Parameter	Description
user-name	(Optional) Remove 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 KEY prompt. Paste only the key, without the identification field.

For example:

admin@GUARD-conf# show keys Lilac

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

admin@GUARD-conf# key remove Lilac ssh-rsa 2352345234523456...

Changing the Host Name

You can change the Guard's host name. This change takes effect immediately, and the new host name is automatically integrated into the prompt string.

The change also effects the CLI prompt.

To change the Guard's host name, enter the following:

hostname name

The argument name specifies the new host name.

For example:

admin@GUARD-conf# hostname CiscoGuard

admin@CiscoGuard-conf# 

Enabling SNMP Traps

You can configure the Guard to send SNMP traps and notify the manager of significant events that occur on the Guard. You can configure the Guard's SNMP Trap Generator and define the trap information scope.

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

---

Step 1 Enable the SNMP trap generator service. Enter the following:

service snmp-trap

Step 2 Configure the SNMP Trap Generator parameters—The trap destination address and the trap information scope. Enter the following:

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

Table 3-11 provides the arguments for the snmp trap-dest command.

Table 3-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.
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.

The following example shows that traps with a severity level higher than errors will be sent to the destination IP address 192.168.100.52 with the SNMP community string of tempo.

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

---

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

---

Configuring SNMP Community Strings

You can configure the Guard's SNMP community string and thus enable access to the SNMP agent from clients in different organizational units and with different community strings on each client.

To add an SNMP community string, enter the following:

snmp community community-string

The argument community-string specifies the desired Guard community string. The string can have a maximum length of 15 alphanumeric characters and cannot contain spaces.

---

Note The Guard's default community string is riverhead.

---

Guard Self-Protection

The Guard, as a network element having an independent IP address, is exposed to potential DDoS attacks. The default configuration provides protection against such attacks. You can access the self-defense protection configuration and modify it.

---

Caution We strongly advise against changing the Guard's self-defense protection default configurations. Unnecessary configurations may result in seriously compromising the Guard self-protection ability!

---

To change the Guard's self-defense protection configuration, enter the self-protection configuration mode. Enter the following:

self-protection

The set of commands available for the Guard's self-defense protection is identical to that of an ordinary zone. See "Configuring Zones", "Configuring Zone Filters", "Configuring Policy Templates and Policies" and "Interactive Recommendations Mode" for further details on zone configuration.

To display the Guard self-protection configuration file, use the show running-config command. See "Viewing the Guard Configuration" for further details.

Flex Filter Default Configurations

The Guard's Flex filter is configured, by default, to block (drop) all traffic flows, unless explicitly specified. Table 3-12 displays the Flex filter default configuration to enable communication required for proper Guard functionality.

Table 3-12 Flex Filter Default Configuration 

SERVICE	IP-PROTO	SRC-PORT	DST-PORT	ALLOW-SYN
bgp	6	179	*	no
telnet	6	23	*	no
ftp-control	6	21	*	no
ftp-data	6	20	*	yes
tacacs	6	49	*	yes
ssh	6	22	*	no
ssh	6	*	22	yes
https	6	*	443	yes
icmp	1	*	*	—
snmp	17	*	161	—
ntp	17	*	123	—
ntp	17	123	*	—
ospf	89	*	*	—
rip	17	520	*	—
rip	17	*	520	—
gre	47	*	*	—

The Flex filter default configuration consists the following:

•Enable BGP communication, initiated by the Guard, on port 179, but block incoming SYN packets with source port 179. This enables BGP connection initiated by the Guard to the Divert-From router.

•Enable telnet communication, initiated by the Guard, on port 23, but block incoming SYN packets with source port 23. This enables telnet connections initiated by the Guard to the Divert-From router.

•Enable FTP communication, initiated by the Guard, with an FTP server, but block incoming FTP control SYN packets with source port 21.

•Enable TACACS communication with a TACACS+ server, but block incoming SYN packets from source port 49. This enables communication with TACACS+ servers for authentication, authorization and accounting.

•Enable incoming and outgoing SSH communication.

•Enable incoming HTTPS communication.

•Enable ICMP communication.

•Enable SNMP communication.

•Enable NTP communication.

•Enable OSPF communication.

•Enable RIP communication.

•Enable GRE communication.