B.1 Security Concepts

The terminal concentrator provides comprehensive security features to protect the concentrator and the network from unauthorized access. These features allow you to choose between host-based security, in which one host on the network functions as a security server with password protection, where passwords are stored on the concentrator. Optionally, local password protection can be used as a backup for the host-based security.

You can configure the following security checkpoints:

• CLI (Command Line Interpreter) security Access to the concentrator by a user at a device attached to a port.
• Port server security Access to a device attached to a port by a user at another host on the network.
• Connection security Access to hosts or networks by a user at a concentrator.
• Virtual CLI security Access to a virtual CLI connection from a host on the network.
• SLIP security Access to a Serial Line Interface Protocol (SLIP) connection.
• PPP security

The concentrator provides protection using an administrative password that controls access to the root (superuser) CLI commands. This password can also protect access to a concentrator through na, a terminal concentrator application. The security system provides audit trails that monitor users and their activities. The concentrator also provides the source code for the Access Control Protocol (ACP) security system, and the flexibility to integrate concentrator security with existing security for a network-wide system.

B.2 Using Security

The terminal concentrator provides a security system that allows you to implement as many security measures as the network requires. You can set up the security subsystem to use host-based security, local password protection, or a combination of the two. In addition to these security mechanisms, the concentrator provides an administrative password that is used to validate access through the administrative tools.

---

Note - If unauthorized users can access your concentrator, we strongly suggest that you enable the security features after loading the host code and booting the unit.

---

Host-based security uses the Access Control Protocol (ACP) of the concentrator and requires that a host function as a security server. You can modify the host-based security policy supplied with the concentrator to implement a security policy that fits the needs of your environment. Host-based security allows you to define:

• User validation on access to and from the concentrator
• Connection protection to other hosts and networks
• User activity logs
• Encryption of security messages between the concentrator and the server

Local password protection can be defined for access to and from individual ports and for virtual CLI access. Local password protection does not provide logging of security events to the security server. If event logging is enabled, user activities can be logged to syslog with local password protection. See the Terminal Concentrator General Reference Guide for more information.

Configuring the concentrator for security involves:

• Enabling security for host-based security, local password protection, or both
• Defining the server if you are using host-based security
• Defining a local virtual CLI password for local password protection
• Defining the administrative password

B.2.1 Enabling Security

To use any security feature, you must enable security for the terminal concentrator by setting the enable_security parameter to Y. This parameter is mandatory if you intend to use any concentrator security mechanisms for access to administrative tools except the administrative password.

B.2.2 Setting Up Host-based Security

Host-based security requires at least one host on the network acting as a security server. The security server maintains files that contain user validation and connection permission information. Also, the security server can encrypt security messages.

B.2.2.1 Specifying the Security Hosts

The pref_secure1_host and pref_secure2_host parameters specify the preferred security hosts. The concentrator first queries the pref_secure1_host for user validation or permission connection requests. If a response is not received within a limited amount of time, the concentrator repeats the query several times. If the concentrator still does not receive a response, it queries the host defined with the pref_secure2_host parameter. If a response is not received from the second security host within a limited time, the concentrator broadcasts. If the broadcast fails, the concentrator denies the user's request.

The network_turnaround parameter specifies the amount of time in seconds in which the concentrator expects a response from the security servers. To reduce the possibility of a retry, the network turnaround time should be sufficient to allow for a network transmission to the security server and transmission back to the concentrator.

B.2.2.2 Disable Broadcasting for Security Servers

The terminal concentrator automatically broadcasts for a security server when the host defined using either the pref_secure1_host or pref_secure2_host parameter does not respond. You can disable broadcasting for a security server by setting the security_broadcast parameter to N.

B.2.2.3 Restricting telnet Access to Certain Ports

The concentrator operational code passes the TCP port number to the ACP when doing a telnet(1) on a port with connect_security enabled. This feature allows restrictions on connections to certain TCP ports. The port number is available in the annex_to_net() parameter in the acp_policy.c file.

B.2.2.4 ACP Virtual CLI Protection

You can set up security for virtual CLI connections where users must provide a valid user name and password before they are granted access to a virtual CLI. You can define security on the virtual CLI connections of the terminal concentrator using the vcli_security parameter. To set up virtual CLI protection with host-based security:

1. Enable security by setting the enable_security parameter to Y.

2. Enable virtual CLI security by setting the vcli_security parameter to Y, then create a password file on the security server (see the Annex Network Administrator's Guide).

B.2.2.5 Encrypting Security Messages

With host-based security, passwords are continuously sent across the network. To prevent unwanted access to these passwords, you can request encryption of messages between the terminal concentrator and the security server.

The acp_key parameter specifies the encryption key the concentrator uses to exchange messages with the security server. The security server maintains the encryption key for the concentrator in the acp_keys file (see the Annex Network Administrator's Guide).

The encryption key also validates the security host. In this case the host must know the ACP key of the concentrator for the concentrator to consider the host valid. Without the appropriate key, the concentrator denies the user's request.

---

Note - The show annex command does not display the value of the acp_key parameter. Instead, it displays <set> or <unset>.

---

B.2.3 Local Virtual CLI Password

Local password security allows you to assign a password that a user must enter before accessing the terminal concentrator. Since this password is stored locally on the concentrator, it does not require a remote security server. Local password security can be used as a back-up security mechanism in case the host-based security servers are unavailable.

Local password security can be implemented for the concentrator in one of two ways: upon virtual CLI connection and upon access through administrative utilities. The vcli_password parameter allows you to define a local password for virtual CLI connections. With this security mechanism, the user enters only the password stored on the concentrator, not a user name and password. To configure the concentrator for a local virtual CLI password:

1. Enable security by setting the enable_security parameter to Y.

2. Disable virtual CLI security by setting the vcli_security parameter to N.

3. Define a password using the vcli_password parameter.

You can also use the vcli_password as a backup to host-based security. When this local virtual CLI password is used as a backup, the concentrator first accesses the security server to validate a CLI connection request. If no response is received from a security server, the concentrator requests the local virtual CLI password. The user can enter either the virtual CLI password or the concentrator administrative password. To set up the local virtual CLI password for backup security:

1. Enable security by setting the enable_security parameter to Y.

2. Enable virtual CLI security by setting the vcli_security parameter to Y.

3. Define a password with the vcli_password parameter.

4. Create a password file on the security server (see the Annex Network Administrator's Guide for instructions).

---

Note - The show annex command does not display the value of the vcli_password parameter. Instead, it displays <set> or <unset>.

---

B.2.4 Concentrator Administrative Password

The administrative password of the terminal concentrator always validates access to superuser CLI commands; it can also validate na program access to the concentrator if the enable_security parameter is set to Y.

The password parameter modifies the administrative password of the concentrator. The default password is the Internet address of the concentrator.

---

Warning - The administrative password never displays. If you forget the modified password, you can reset it only by erasing all of the nonvolatile memory in the concentrator by using the ROM Monitor.

---

The administrative password is required to access the superuser CLI commands. When you enter the su command at the CLI prompt, you are asked for a password. If you have not modified the administrative password, enter the Internet address of the concentrator.

The administrative password validates access to the concentrator through na only when security is enabled and the password is defined. When issuing the annex command or specifying the concentrator using na, you must enter this password. The password also encrypts messages between the concentrator and na. The administrative password can be used as the virtual CLI password and to override the password assigned using the CLI lock command.

B.3 Setting Port Security

The concentrator provides a security system allowing you to configure security on a per-port basis. You can use host-based security, local password protection, or a combination of the two.

Host-based security provides access validation for the following access requests:

• From the device, a terminal or modem, attached to the port
• From a user on the network connecting to the port
• From a device attached to the port connecting to a host or a network

Local password protection can be used as a stand-alone security mechanism or as a backup to host-based security. It validates port access from either the device or the network. Local password protection supports CLI, slave, and adaptive ports.

Host-based security also allows you to mask out CLI commands. When a command is masked, it is not displayed with the help command; if entered, CLI displays an error message. You can customize the security policy to meet your individual security requirements. The local password protection policy cannot be altered (see the Annex Network Administrator's Guide for more information).

---

Note - For any security mechanism, you must enable security for the concentrator by setting the enable_security parameter to Y.

---

B.4 Port Server and CLI Security

The port server security provides the option of configuring host-based security, local password protection, or both. The host-based security for the port server normally requires a user name and password. Local password protection on the port server requires only a password.

As with security on CLI connections, the local password protection can be used as the sole security mechanism or as a backup to host-based security for those occasions when the security servers are not available.

With port server security, the port server invokes the security mechanism when the user requests access to a specific port or rotary at the port server prompt. User validation occurs before the user is connected to the port to ensure that the user is authorized to connect to the selected port. If the user is not authorized, the port server notifies the user and prompts for another port. The following example is an example of the supplied user validation for port server security.

annex: telnet annex01 Trying... Connected to annex01. Escape character is "^]". Rotaries Defined: modem_1200 1-3,5 modem_2400 4,7 cli - Enter concentrator port name or number: modem_1200 Annex username: kate Annex password: Permission granted Attached to port 1.

For camp-on, user validation occurs when a port becomes available. If the name or password is incorrect, the user is returned to the port identification prompt.

To use host-based security with the port server:

1. Set the concentrator parameter enable_security to Y.

2. Set the port parameter port_server_security to Y.

3. Create a password file (acp_passwd) on the security server(s) (see the Annex Network Administrator's Guide for more details).

4. For local password protection with the port server, define a password for the port_password parameter.

---

Note - The port parameter port_password is applicable to both CLI and port server connections.

---

B.5 Security on Virtual CLI Connections

The concentrator establishes security on virtual CLI (VCLI) connections using host-based security, local password protection, or both. Host-based security validates the user name and user password.

The virtual CLI security mechanism is similar to the port server security mechanism in that user validation is invoked after the user has requested access to the VCLI at the port server prompt. This ensures that the user is authorized to access the VCLI.

To set up host-based security on virtual CLI connections:

1. Set the enable_security concentrator parameter to Y.

2. Set the vcli_security concentrator parameter to Y.

3. Create a password file (acp_passwd) on the security server(s) (see the Annex Network Administrator's Guide for more information).

Local password protection requires only a password for validation. To set up this protection for the concentrator:

1. Set the concentrator parameter enable_security to Y.

2. Set the concentrator parameter vcli_security to N.

3. Define a password for all virtual CLI connections for the concentrator using the vcli_password parameter.

Local password protection can function as a backup to host-based security:

1. Set up host-based security for the virtual CLI connection.

2. Define a virtual CLI connection password using the concentrator parameter vcli_password. Virtual CLI connections must adhere to any connect security defined for the concentrator.

B.6 PPP Security

The optional PPP phase occurs after the LCP negotiations are complete. Each half of the connection can require security. The terminal concentrator first tries to use ACP and then falls back to local security; if neither are available, the concentrator closes the link.

To start authentication, the peer sends a PPP Authenticate message to the concentrator. The concentrator sends an ACP ppp_security_protocol() call to verify the peer's user name/password. The concentrator allows three attempts before closing the link. If ACP vouches for the user, the concentrator sends a PPP Authenticate-Ack message and continues NCP negotiations. The concentrator uses local security when ACP is unavailable and the port_password parameter is set; local security ignores the user name and checks the password against port_password.

B.7 Host-based Security

The Access Control Protocol (ACP) provides the following host-based security options:

• User validation for connecting to a CLI
• User validation for access to the port server
• Validation for host connections
• Logging security events
• User validation for access to a PPP port
• User validation for access to dial-up address connections
• Encryption key protection for concentrator access to the security server, and optionally, for access to a concentrator through na

ACP requires that at least one host is a security server and that security is enabled on the concentrator. All files that maintain access validation reside on the security server. Using host-based security, the concentrator logs messages to the security server when security events occur and when the concentrator is booted. You can modify this supplied policy to:

• Disable user name and password validation
• Change the name of the password file
• Disable CLI commands

Using the concentrator distribution's library calls, and any library calls available on your system, you can modify the code to provide your own prompts and encoded validation.

B.7.1 Defining a Security Server

The ACP security server software is provided as part of the expedited remote procedure call daemon (erpcd) supplied with the file server software. Included with the software is the services file that has two entries: one for the block file server (bfs) and one for Access Control Protocol (ACP).

The ACP security server software has the ACP service commented out, as follows:

#erpc remote programs # # prog no. verlo verhi name # # 1 0 99 bfs # 3 0 99 acp

To define a security server, you must install the file server software on a host and delete the # symbol in front of the ACP entry. For example:

#erpc remote programs # # prog no. verlo verhi name # # 1 0 99 bfs 3 0 99 acp

You can use the same host to be both file server and security server, or move the servers to two separate hosts. You can put the security server on more than one host. However, you must define one host as a first preferred security server. Optionally, you can define a second host as a second preferred security server. Additional security servers respond to broadcast requests if the preferred servers are unavailable and security_broadcast is set to Y.

---

Note - The contents of the files acp_passwd, acp_restrict, and acp_keys should match on all servers.

---

B.7.2 Creating the acp_dialup File

The acp_dialup file resides in the install directory. Any ACP dial-up address request that comes from the concentrator has a username and an Internet address which is used as keys in this file. Once the keys are matched, the corresponding dial-up addresses are returned to the caller on the concentrator. If no match is found, the concentrator uses the port's remote_address and local_address.

You can specify the concentrator by name, Internet address, or wild card (*); the wild card means that any incoming address request with that user name will match. Also, you can specify a range of ports. The file format allows one entry per line; the concentrator ignores any data following the comment character (#); a new line character terminates an entry.

The acp_dialup file displays the following fields: User, Annex, Remote Address, and Local Address (optional). If a local address is not specified, the local address sent back to the concentrator is that address of the concentrator. Table B-1 shows an example.

Table B-1 acp_dialup

User Name	Concentrator/Port_set	Remote Address	Local Address (Optional)
smith	4,5,6-9@100.30.200.39	100.30.200.45	100.30.200.46
green	*	100.30.200.48
cody	3,7,20-25@jupiter	100.30.200.47
harris	mars	100.30.200.55

In the preceding example:

• User smith can make a dial-up address request from concentrator 100.30.200.39 on ports 4, 5, and 6 through 9. The remote address is 100.30.200.45; the local address is 100.30.200.46.
• User green can make a dial-up address request from any concentrator on any port. The remote address is 100.30.200.48; the local address is the address of green's concentrator.
• User cody can make a dial-up address request from concentrator jupiter on ports 3, 7, and 20-25. The remote address is 100.30.200.47; the local address is the address of cody's concentrator.
• User harris can make a dial-up address request from concentrator mars on any port. The remote address is 100.30.200.55; the local address 100.30.200.40.

B.7.3 Creating User Password Files

CLI ports are configured for user validation with the cli_security port parameter. Virtual CLI connection user validation is enabled with the vcli_security concentrator parameter. User validation on accessing ports through the port server is provided with the port_server_security port parameter.

---

Note - User validation is available only if host-based security is enabled at the concentrator using the enable_security concentrator parameter.

---

For user validation with the supplied security policy, the concentrator sends a request to the security server to compare a user name and password against entries in a password file. If a match is found, the user is granted access to the CLI; otherwise, the user is denied access to the CLI. For example:

Annex Command Line Interpreter * Copyright 1990 Xylogics, Inc. Checking authorization, Please wait... Annex username: kate Annex password: Permission granted annex:

The supplied policy expects the password file to be the acp_passwd file. This file uses the same format as the /etc/passwd file. The easiest way to create this file is to copy the /etc/passwd file to acp_passwd. One advantage for creating the acp_passwd file this way is that you can merge /etc/passwd files from different hosts into one file on the security server. This allows you to create a network-wide password file.

Under Solaris 2.x the passwords reside in the /etc/shadow file.

B.7.4 Setting Up Connection Security

ACP provides connection security, which authorizes connection requests to hosts using the CLI connection commands telnet and rlogin(1). The connection security mechanism uses a host-resident file that lists the hosts to which connections are restricted.

Connection security is enabled for individual ports by setting the concentrator parameter enable_security and the port parameter connect_security. Setting the concentrator parameter vcli_security enables connection security for all virtual CLI connections. When a user issues a connection command, the concentrator checks a restrict file for permission to connect to that host. The supplied policy expects the restrict file to be acp_restrict, which is an ASCII file that you create with any text editor. Table B-2 describes the arguments in each entry. The entry format is:

concentrator: restricted host, restricted host, ... concentrator~ unrestricted host, unrestricted host, ...

Table B-2 acp_restrict

Argument	Description
annex	The name or Internet address of the concentrator for which connection security is enabled
: (colon)	Indicates the hosts listed in the same entry are restricted.

Table B-2 acp_restrict

Argument	Description
~ (tilde)	Indicates the hosts are unrestricted.
restricted host	The name or Internet address of a restricted host (including concentrators). The list of restricted hosts is separated by commas.
unrestricted host	The name or Internet address of an unrestricted host (including concentrators). The list of unrestricted hosts is separated by commas.

You can use an asterisk (*) as a wild card in place of a host name or the host part of an Internet address. Following is an example of two restricted-host entries:

annex01: hosta, hostb, hostf,132.245.6.23 annex02: hostc, 312.245.6.15,hostf, 132.245.6.23,hosth,annex01

The first entry prevents users in which connection security is enforced on annex01 from accessing hosta, hostb, hostf, and the Internet address 132.245.6.23. The second entry prevents users on annex02 from accessing five hosts and one concentrator. Connection security is enforced on all virtual CLI connections at annex01 and annex02.

Hosts that are not listed in the file are considered unrestricted. Since ACP searches the acp_restrict file sequentially, the order of placement in the file is important. The search stops when it finds a host that matches. You can use unrestricted host entries to prevent users on one network from accessing hosts on any other network.

In the following example, the policy finds the unrestricted definition for concentrators and hosts on network 192.17.5 and grants access. It finds the restricted definition for hosts on any other network and does not grant access.

The next example illustrates wild cards. A publichost is defined as accessible from all concentrators and a securehost is inaccessible from any concentrator.

192.17.5.*~ 192.17.5.* 192.17.5.*: *

*~ publichost
*: securehost

If permission is granted to a connection security request, the user follows the normal login procedure. If the request is denied, the message

Permission denied

is displayed and the session (job) is aborted.

B.7.5 Creating the ACP Encryption Keys File

The host-based security can encrypt messages between a concentrator and the security server. Encryption of messages is based on the ACP key, which is set using the concentrator parameter acp_key. This option is available when host-based security is enabled for the concentrator by setting the concentrator parameter enable_security to Y.

When ACP encryption is enabled, the supplied policy expects a file called acp_keys, which maintains a list of concentrators and their respective encryption key. When the security server receives an encrypted message from a concentrator, the server tries to match that key against the key assigned to the concentrator in the file. If no match exists, the concentrator and the server cannot communicate.

Each entry in the encryption keys file contains a list of concentrator names or Internet addresses separated by commas and an encryption key for those concentrators. The concentrator or the list of concentrators and the key are separated by a colon. The order of placement in the file is important, as the file is sequentially read. Syntax rules for the acp_keys file are:

Any part of an Internet address in the list can be specified with an asterisk (*).

• A backslash (\) is used to escape a new line.
• Any ASCII character except spaces and tabs are valid encryption keys.
• Each key can contain a maximum of fifteen characters.

Typically, concentrators that do not expect encryption do not need to be included in the file. However, if a concentrator falls into a group of multiple concentrators that were specified with an * as part of the Internet address and it is not expecting encryption, that concentrator must be included in the file with the key left blank.

In the following example, the first three entries specify insomniac-1 as the key for the concentrator whose Internet address is 132.245.6.15, no encryption for the concentrator whose Internet address in 132.245.6.75, and Piano as the key for all other concentrator on the same network. The last entry specifies gl12ch as the key for annex01, annex02, and annex03. Each acp_key parameter for the concentrators listed in the example must be identical to the key included in the acp_keys file.

132.245.6.15:insomniac-1 132.245.6.75: 132.245.6.*:Piano annex01,annex02,annex03,gl12ch

Changing the value of the acp_key parameter on any concentrator requires the same change to the acp_keys file on the security server. The recommended order for changing the ACP encryption key on a concentrator is:

1. Edit the acp_keys file on all security server hosts.

2. Use na to change the value of the acp_key parameter for all affected concentrators.

3. Update the cache by sending the erpcd on all security server hosts a HUP signal with kill.

4. Reset the security subsystem for all affected concentrators using the na command reset concentrator security.

B.7.6 Logging Security Events

Host-based security provides the ability to generate audit trails of user activity. Each time the security server grants or denies a request for user access, the security server logs it. Each event is logged as a message to a file defined as acp_logfile (see the Annex Network Administrator's Guide). You can change acp_logfile in the file /annex_root/src/erpcd/acp_policy.h to any suitable pathname including /dev/null, /etc/console, etc.

Each logged message contains the Internet address of the concentrator, a sequence number, the port number, the date and time, the event, and other information that is protocol dependent. The fields in the file are separated by colons and can be used by UNIX utilities that sort, merge, select, or filter streams.

B.7.7 Modifying the Supplied Security Application

You can modify the supplied security policy to create a security scheme that meets the needs of your network. Some simple modifications involve changing system definitions in the file /annex_root/src/erpcd/acp_policy.h. More elaborate security policies may require modifying or replacing functions in the file /annex_root/src/erpcd/acp_policy.c.

---

Note - Do not change the function declarations or the description of the interface; these are fixed by the calls made into this library. Before making even the smallest change, save the base version of the file requiring modification.

---

If you modify the default policy, you must recompile erpcd, kill(1M) the current version, and start the new version. Instructions for doing this are provided later in this section.

B.7.7.1 Disabling User Name and Password Validation

When security is enabled, users are requested to provide a user name and password. You can disable this policy by modifying the /annex_root/src/erpcd/acp_policy.h file to change the line that defines user validation from:

#define USER_VALIDATION 1

to:

#define USER_VALIDATION 0

Messages are logged to the security server host when users access the CLI, but the message does not include a user name.

B.7.7.2 Changing the Expected Names of Files Used by ACP

The supplied policy uses names for various files, such as acp_passwd, acp_keys, acp_restrict, and acp_logfile. You can change the names of any of these files in the /annex_root/src/erpcd/acp_policy.h file. If you decide to use either an existing system or a network-wide password file instead of acp_passwd file, change the following lines in the file /annex_root/src/erpcd/acp_policy.h:

#define ACP_PASSWD (str) \ sprintf(str, "%s/acp_passwd",INSTALL_DIR) #define ACP_PTMP (str) \ sprintf(str, "%s/acp_ptmp",INSTALL_DIR)

To change only the filename:

#define ACP_PASSWD (str) \ sprintf(str, "%s/new_filename",INSTALL_DIR) #define ACP_PTMP (str) \ sprintf(str, "%s/new_filename",INSTALL_DIR)

To change the full pathname:

#define ACP_PASSWD (str) \ sprintf(str, "new_path/new_filename") #define ACP_PTMP (str) \ sprintf(str, "new_path/new_tmpfile")

The new_filename is the name of the new password file, and the new_tempfile is a temporary file used by the ch_passwd command. Because you do not need the temporary file if you are using an existing system file, comment out the line for the temporary file.

---

Note - INSTALL_DIR is defined in the file /annex_root/src/make.config with the leading quote supplied by the makefile. Because the trailing quote is required by the two strings, double quote the names for the new password and temporary files.

---

B.7.7.3 Disabling CLI Commands

When the security subsystem is enabled, you can mask user access to specific CLI commands by changing the following line, which defines user commands as not masked, in the /annex_root/src/erpcd/acp_policy.h file:

#define CLI_MASK(unsigned log 0)

To mask the hosts, netstat, and stats commands, modify that line to read:

#define CLI_MASK (MASK_HOSTS | MASK_NETSTAT | MASK_STATS)

If the user enters the masked command, CLI displays an error message. The superuser CLI commands cannot be masked individually. They can all be disabled by masking the su(1M) command.

B.7.7.4 Modifying the Code

You can create a more elaborate security policy application by modifying the code in the files /annex_root/src/erpcd/acp_policy.c and /annex_root/src/erpcd/acp_policy.h. The program that executes ACP forks itself each time a security request is received from a concentrator. A call is made to an ACP remote procedure, which makes calls to functions in the ACP library to prompt for user names and passwords. When ACP gathers the information required to perform the authorization algorithm, it again calls functions in the library to grant or deny the request. The program then exits.

The distribution policy file /annex_root/src/erpcd/acp_policy.c is documented in the form of C programming language comments. The /annex_root/src/erpcd/policy.doc file provides a complete description of the available library functions.

B.7.7.5 Recompiling erpcd

You must recompile erpcd if you modify the supplied policy and the ch_passwd utility if you changed the name of the ACP password file from acp_passwd. The source files are in /annex_root/src/erpcd, where annex_root is the directory to which the source code of the concentrator was copied. To recompile:

1. cd to /annex_root/src/erpcd.

2. To recompile only erpcd, enter the command:

# make -f ../make.config -f Makefile erpcd

3. To recompile both erpcd and ch_passwd, enter the command:

# make -f ../make.config -f Makefile all

4. To install, enter the command:

# make -f ../make.config -f Makefile install

This command saves the old version of erpcd as OLDerpcd in the installation directory.

5. Kill the current erpcd and start the new one.

B.8 Securing the Network

The concentrator security system provides a full set of features that allow you to establish any security policy required by the network. You can choose between host-based and local password protection on the concentrator, or you can use local password protection as a backup for host-based security.

B.8.1 The Concentrator Administrative Password

The concentrator administrative password protects the administrative tools; the default administrative password is the Internet address of the concentrator. When the show annex command displays the password as <unset>, use the default administrative password for:

• Access to superuser CLI commands
• Access to ports locked with the CLI lock command
• Access to a virtual CLI connection through local password protection

Modifying the assigned administrative password enables:

• Password protection on access to concentrators through na
• Encryption of messages between a concentrator and na

---

Note - If you lose your administrative password, your only option is to erase the non-volatile memory of the concentrator by using the ROM Monitor erase command, and re-enter all parameters.

---

B.8.2 Protecting Ports from Unauthorized Access

When terminals are connected to a network, they provide users with the potential for unauthorized access to hosts and resources. In addition to the available security schemes, the concentrator provides timers that can reset a port. The cli_inactivity port parameter sets the CLI inactivity timer: when the last session is completed, the concentrator resets the port after the amount of time specified in this parameter has elapsed.

Users can protect their login sessions using the CLI lock command if they do not want to log out when leaving the terminal unattended.

B.8.3 Protecting the Superuser CLI

A concentrator administrative password is required for access to the superuser CLI using the su command. The default password is the Internet address of the concentrator. There are two ways to change the password:

• Using the superuser CLI passwd command
• Changing the password parameter using na

Using either method, the new password takes effect immediately for access to the superuser CLI. Reset the password to the Internet address of the concentrator by:

• Using na to set the password parameter to the null string. For example:

command: set annex password ""

• Using the superuser CLI passwd command and pressing Return in response to the prompt for a new password.
• Erasing all parameters using the ROM monitor erase command.

B.8.4 Preventing Unauthorized Access to na

When using na, users can access concentrator parameters and obtain useful information, or reconfigure and reboot concentrators. Protecting na involves UNIX superuser protection and the concentrator administrative password.

Upon installation, the na utility is owned by root and executable by all. Only a superuser can execute the set, reset, broadcast, dumpboot, boot, read, and copy commands.