Table Of Contents

Configuring the Detector Module

Activating Detector Module Services

Configuring Access Control

Configuring Authentication

Configuring Authentication Methods

Configuring Local Authentication

Configuring Authorization

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 Detector Module Configuration

Activating Remote Guards

Enabling Activation of Remote Guards

Configuring the Default Remote Guard List

Configuring Remote Guard Activation Connection

Generating SSH Keys

SSH Host Keys

Configuring Date and Time

Managing SSH Keys

Adding SSH Keys

Deleting SSH Keys

Changing the Host Name

Enabling SNMP Traps

Configuring SNMP Community Strings

Configuring the Detector Module

---

This chapter describes how to configure the Cisco Traffic Anomaly Detector Module (Detector module). These configuration procedures lay the foundation for Detector module management and diversion related communication.

This chapter includes the following major sections:

•Activating Detector Module Services

•Configuring Access Control

•Viewing the Detector Module Configuration

•Activating Remote Guards

•Configuring Date and Time

•Managing SSH Keys

•Changing the Host Name

•Enabling SNMP Traps

•Configuring SNMP Community Strings

Activating Detector Module Services

You can define which Detector module 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 Detector module services. You can grant or deny permission from a desired IP address and thus limit the addresses from which the Detector module is accessed and controlled.

The Detector module services include the following:

•snmp-server—The Simple Network Management Protocol (SNMP) server service. You can access the Detector module 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 Detector module 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 Detector module enables the user to control it via the web using a web browser.

To activate a Detector module service perform the following steps:

---

Step 1 Enable the Detector module service. Enter the following:

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

---

Note By default, all Detector module services, except SSH, are disabled.

---

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

permit service ip-addr [ip-mask]

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

Table 4-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@DETECTOR-conf# service ntp

admin@DETECTOR-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 and Authorization 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.

The following sections describe how to configure access control:

•Configuring Authentication

•Configuring Authorization

•Configuring TACACS+ Server Connection

Configuring Authentication

You can configure which authentication method the Detector module uses when a user tries either to log into the Detector module or requests a higher privilege level (using the enable command). The Detector module 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 Detector module uses the first method listed to authenticate users; if that method does not respond, the Detector module selects the second authentication method. Only if both authentication methods are exhausted, the authentication fails.

You can configure a distributed authentication scheme. The Detector module uses the first TACACS+ server to authenticate users. If the authentication returns a rejection, the Detector module 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 Detector module 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 4-2 provides the arguments for the aaa authentication command.

Table 4-2 Keywords for the aaa authentication Command 

Parameter	Description
enable	The Detector module authenticates on entering a higher privilege level.
login	The Detector module authenticates when logging into it.
local	The Detector module 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@DETECTOR-conf# aaa authentication enable tacacs+ local

Configuring Local Authentication

The Detector module initially has a preconfigured user name with administrator privileges, which enable you to create new users. User definition enables you to divide the Detector module 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 Detector module local database, enter the following:

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

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

Table 4-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 3-1 for further details.
password	A password (Optional). Passwords contain up to 24 characters and cannot contain spaces. If you do not enter a password, you will be prompted for it.

For example:

admin@DETECTOR-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 Detector module displays the encrypted password and not the password you enter to log in.

---

To remove a user from the Detector module user list, enter the following:

no username username

---

Tip To view a list of the Detector module users list 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. Passwords contain up to 24 characters and cannot include spaces. The system prompts you to confirm the new password by typing it again.

---

For example:

admin@DETECTOR# 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. Passwords can contain up to 24 characters and cannot include 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@DETECTOR# 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 Detector module verifies the user's profile to verify the user's access rights. The user is granted access to the requested service only if the information in the user's profile allows it. The authorization database is stored locally. It uses configured user profiles for command group access control. Authorization is defined for all commands at the specified privilege level.

Access to Detector services depends on the user privilege level. You can limit the services available to a user. The Detector module 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 3-1 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 4-4 provides the arguments and keywords for the enable password command.

Table 4-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 3-1 for further details. The default level is admin.
password	(Optional) The privilege level's password. The maximum password length is 24 characters and cannot hold 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 3-1 for further details.

Step 2 Enter the privilege level's password.

---

For example:

admin@DETECTOR> enable admin 

Enter enable admin Password: <password>

To switch back to the lower privilege level (show) use the disable command.

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 Detector module 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 authentication. The Detector module uses the TACACS+ server listed to authenticate users; if that server does not respond, the Detector module selects the second server. Only if all servers listed are exhausted, authentication fails.

Alternatively, you can configure the Detector module 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@DETECTOR-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@DETECTOR-conf# tacacs-server key MyTacacsKey

Configuring TACACS+ Search

You can configure the Detector module to regard an authentication rejection as final and stop further search with other TACACS+ servers or the local authentication method. The Detector module, 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 Detector module to use only the first TACACS+ server on the list to authenticate users, enter the following:

tacacs-server first-hit

For example:

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

---

Note If you do not configure the TACACS+ search method to first-hit, the Detector module, 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 Detector module to wait for the TACACS+ server's reply. When the timeout ends, the Detector module either attempts to establish a connection with the next TACACS+ server (if such a server was configured) or falls back to local authentication (if such fallback was configured). Authentication fails 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@DETECTOR-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 Detector Module Configuration

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

To display the Detector module configuration file, enter the following:

show running-config [all | Detector module | interfaces interface-name | self-protection | zones]]

Table 4-5 provides the arguments and keywords for the show running-config command.

Table 4-5 Arguments and Keywords for the show running-config Command 

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

For example:

admin@DETECTOR# show running-config detector 

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

Activating Remote Guards

When the Detector detects a zone traffic abnormality it logs the event (an action known as notify) or activates remote Guards that initialize actions to protect the zone.

The following sections describe how to activate and configure remote Guards:

•Enabling Activation of Remote Guards

•Configuring the Default Remote Guard List

•Configuring Remote Guard Activation Connection

Enabling Activation of Remote Guards

To enable activation of remote Guards, you must perform the following:

1. Configure the zone on both the Guard and the Detector

---

Note The zone name must be identical.

---

We recommend that you configure the zone Guard-protection forms (protect-ip-state) to determine the type of activation. See the "Configuring Guard-Protection Activation Forms" section for further details.

2. Configure the remote Guard lists

3. Configure the Guard activation connection (see the "Configuring Remote Guard Activation Connection" section for further details)

You can configure the following lists of remote Guards:

•Zone-specific remote Guard list—A list of remote Guards that are activated to protect the zone. See the "Configuring the Zone Remote Guard List" section for further details.

•Detector default list—The default list of remote Guards. The Detector activates these Guards if the zone-specific remote Guard list is empty. See the "Configuring the Default Remote Guard List" for further details.

Configuring the Default Remote Guard List

The Detector activates the default remote Guard list if the zone-specific remote Guard list is empty. The default list should contain at least one value in case no Guards are defined in the zone-specific remote Guard list.

---

Note You should verify that the Detector has at least one remote Guard in either the default remote Guard list or in the zone-specific remote Guard list (see the "Configuring the Zone Remote Guard List" section) to activate remotely. If no remote Guards are defined in either lists, the Detector records the event in its log-file.

---

To add a Guard to the default remote Guard list, enter the following:

remote-guard remote-guard-address [description]

Table 4-6 provides the keywords for the remote-guard command.

Table 4-6 Arguments for the remote-guard Command 

Parameter	Description
remote-guard-address	The remote Guard IP address.
description	(Optional) The remote Guard description. The description can have a maximum of 63 characters.

---

Caution If you change the remote Guard lists you must either regenerate the Detector public SSH key or manually add the existing key to the remote Guards. See section "Managing SSH Keys" for further details.

---

To view the default list of remote Guards, use the show detector command.

Configuring Remote Guard Activation Connection

When detecting traffic abnormality the Detector either logs the event, or remotely activates the relevant Guards using an SSH connection. To ensure a secure SSH connection, the Detector generates a private-public SSH key pair and distributes its public SSH key to the Guards listed in the remote Guard lists.

•Generating SSH Keys

•SSH Host Keys

Generating SSH Keys

You must generate the Detector's SSH private-public key pair to enable remote activation of Guards. The Detector initializes an SSH session and distributes its public SSH key to the relevant Guards.

---

Note The SSH public key can be added manually to the remote Guards if no remote Guard is configured in the remote Guard lists or no network connectivity currently exists between the Detector and the Guard.

---

To generate the SSH keys perform the following steps:

---

Step 1 Type the following at the Configuration prompt:

key generate

---

Note If the Guard is authenticating users using TACACS+ authentication, you must define the user riverhead on the TACACS+ server for the key generate command to work.

---

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

/root/.ssh/id_rsa already exists.

Overwrite (y/n)? 

Type the desired option.

Step 3 If this is the first SSH connection initiated from the Detector to a Guard, the following message appears:

The authenticity of host 'Remote-Guard' can't

be established.

RSA key fingerprint is

de:cb:ac:36:9a:fe:33:f9:6a:d8:7b:98:a9:51:75:54.

Are you sure you want to continue connecting (yes/no)?

Type yes.

See "SSH Host Keys" for further details.

Step 4 The following prompt appears:

riverhead@remote-Guard-IP-address's password:

Type in the password configured on the Guard for the user riverhead.

---

The Detector repeats Step 4 for each of the Guards in the zone remote-Guard lists and Detector default remote-Guard list.

For example:

admin@DETECTOR-conf# key generate

/root/.ssh/id_rsa already exists.

Overwrite (y/n)? y

The authenticity of host '192.168.100.33 (192.168.100.33)' can't be

established.

RSA key fingerprint is

de:cb:ac:36:9a:fe:33:f9:6a:d8:7b:98:a9:51:75:54.

Are you sure you want to continue connecting (yes/no)? yes

riverhead@192.168.100.33's password: <password>

admin@DETECTOR-conf# 

To display the SSH public key, use the show detector-key command.

SSH Host Keys

To prevent a man-in-the-middle attack, SSH2 uses host keys to verify the remote host's authenticity. When initiating an SSH connection to a remote host for the first time, the remote host sends its public key. The Detector displays the following message:

The authenticity of host '<remote-host name> (<remote-host IP

address>)' can't be established.

RSA key fingerprint is <RSA key fingerprint> 

Are you sure you want to continue connecting (yes/no)?

You must determine the authenticity of the remote host. Once you have verified the remote host's (Guard) key, enter yes.

This process occurs during initial connection from the Detector to a remote-Guard.

If a remote Guard machine was changed, you must delete the remote Guard's host key. You can then either:

•Regenerate the Detector's public key by issuing the key generate command

OR

•Manually add the Detector's public key to the Guard by issuing the key add command

---

Note To display the host keys listed on the Detector, use the show host-keys command. To delete host keys listed on the Detector, use the no host-keys command.

---

Configuring Date and Time

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

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

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

Table 4-7 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@DETECTOR-conf# date 1008171003.17

Wed Oct  8 17:10:17 EDT 2003

Managing SSH Keys

The following sections describe how you can manipulate the Detector module 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 Detector module SSH key list.

Enter the following:

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

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

Table 4-8 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 Detector module 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@DETECTOR-conf# key add ssh-rsa 14513797528175730. . 
.user@Detector module.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 Detector module.

To remove an SSH key from the Detector module, enter the following:

key remove [user-name] key-string

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

Table 4-9 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@DETECTOR-conf# show keys Lilac

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

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

Changing the Host Name

You can change the Detector module'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 Detector module's host name, enter the following:

hostname name

The argument name specifies the new host name.

For example:

admin@DETECTOR-conf# hostname CiscoDetector

admin@CiscoDetector-conf# 

Enabling SNMP Traps

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

To configure the Detector module 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 4-10 provides the arguments for the snmp trap-dest command.

Table 4-10 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@DETECTOR-conf# snmp trap-dest 192.168.100.52 tempo errors 

---

Note A trap is logged in the Detector module 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 Detector module'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 Detector module community string. The string can have a maximum length of 15 alphanumeric characters and cannot contain spaces.

---

Note The Detector module's default community string is riverhead.

---