3.6. Configuring Security with CLI
This section provides information to configure security using the command line interface. Topics in this section include:
3.7. Setting Up Security Attributes
Table 4 depicts the capabilities of authentication, authorization, and accounting configurations. For example, authentication can be enabled locally and on RADIUS and TACACS+ servers. Authorization can be executed locally, on a RADIUS server, or on a TACACS+ server. Accounting can be performed on a RADIUS or TACACS+ server.
Table 4: Security Configuration Requirements
Authentication | Authorization | Accounting |
Local | Local | None |
RADIUS | Local and RADIUS | RADIUS |
TACACS+ | Local and TACACS+ | TACACS+ |
3.7.1. Configuring Authentication
Refer to the following sections to configure authentication:
- Local authentication
- RADIUS authentication (with local authorization)By default, authentication is enabled locally. Perform the following tasks to configure security on each participating 7705 SAR router:
- RADIUS authentication (with RADIUS authorization)To implement RADIUS authentication with authorization, perform the following tasks on each participating 7705 SAR router:
- TACACS+ authenticationTo implement TACACS+ authentication, perform the following tasks on each participating 7705 SAR router:
3.7.2. Configuring Authorization
Refer to the following sections to configure authorization:
- Local authorizationFor local authorization, configure these tasks on each participating 7705 SAR router:
- RADIUS authorization with authenticationFor RADIUS authorization with authentication, configure these tasks on each participating 7705 SAR router:
- For RADIUS authorization, VSAs must be configured on the RADIUS server. See Vendor-Specific Attributes (VSAs).
- TACACS+ authorization (only)For TACACS+ authorization without authentication, configure these tasks on each participating 7705 SAR router:
- TACACS+ authorizationFor TACACS+ authorization with authentication, configure these tasks on each participating 7705 SAR router:
3.7.3. Configuring Accounting
Refer to the following sections to configure accounting.
- Local accounting is not implemented. For information about configuring accounting policies, refer to Configuring Logging with CLI.
3.8. Security Configurations
This section provides information on configuring security and examples of configuration tasks.
To implement security features, configure the following components:
- management access filters
- CPM (CSM) filters
- profiles
- user access parameters
- password management parameters
- RADIUS and/or TACACS+
- enable one to five RADIUS and/or TACACS+ servers
- configure RADIUS and/or TACACS+ parameters
The following example displays default values for security parameters.
3.9. Security Configuration Procedures
3.9.1. Configuring IPv4 or IPv6 Management Access Filters
Creating and implementing management access filters is optional. Management access filters control all traffic going in to the CSM, including all routing protocols. They apply to packets from all ports. The filters can be used to restrict management of the 7705 SAR router by other nodes outside either specific (sub)networks or through designated ports. By default, there are no filters associated with security options. The management access filter and entries must be explicitly created on each router.
Management access filters apply to the management Ethernet port, which supports both IPv4 and IPv6 filters.
The 7705 SAR exits the filter when the first match is found and executes the actions according to the specified action. For this reason, entries must be sequenced correctly from most to least explicit.
An entry may not have any match criteria defined (in which case, everything matches) but must have at least the keyword action to be considered complete. Entries without the action keyword are considered incomplete and will be rendered inactive.
Use the following CLI commands to configure an IPv4 management access filter.
Use the following CLI commands to configure an IPv6 management access filter.
The following example displays an IPv4 management access filter configuration. This example only accepts packets matching the criteria specified in entries 1 and 2. Non-matching packets are denied.
The following example displays the management access filter configuration.
 | Note: If configuring management access filters via a Telnet session, ensure that data from the host IP address is permitted before setting the default action to deny; otherwise, the session will be dropped. To do this, set the default action to permit, configure an entry with the src-ip address of the host as a permitted match criterion, then set the default action back to deny. Alternatively, use a direct console connection to the node for configuration; in this case, the order of filter configuration does not matter. |
3.9.2. Configuring IPv4 or IPv6 CPM (CSM) Filters
CPM filters control all traffic going in to the CSM, including all routing protocols. They apply to packets from all network and access ports, but not to packets from a management Ethernet port. CPM packet filtering is performed by network processor hardware using no resources on the main CPUs.
Use the following CLI commands to configure an IPv4 CPM filter.
Use the following CLI commands to configure an IPv6 CPM filter.
The following displays an IPv4 CPM filter configuration example:
3.9.3. Configuring Password Management Parameters
Configuring password management parameters consists of defining aging, the authentication order and authentication methods, password length and complexity, as well as the number of attempts a user can make to enter a password.
Depending on the authentication requirements, password parameters are configured locally or on the RADIUS or TACACS+ server.
Use the following CLI commands to configure password support:
The following displays an example of the password command usage.
The following example displays the password configuration:
3.9.4. IPSec Certificate Parameters
The following is an example of importing a certificate from a pem format:
The following is an example of exporting a certificate to a pem format:
The following example displays a profile output:
The following example displays an ike-policy with cert-auth output:
The following example displays a static LAN-to-LAN configuration using cert-auth:
3.9.5. Configuring Profiles
Profiles are used to deny or permit access to a hierarchical branch or specific commands. Profiles are referenced in a user configuration. A maximum of 16 user profiles can be defined. A user can participate in up to 16 profiles. Depending on the authorization requirements, passwords are configured locally or on the RADIUS server.
Use the following CLI commands to configure user profiles:
The following displays an example of the user profile command usage.
The following example displays the user profile output:
3.9.6. Configuring Users
Access parameters are configured for individual users. For each user, the login name and, optionally, information that identifies the user is defined. Use the following CLI syntax to configure access parameters for users. The snmp authentication des-key keyword is not available if the 7705 SAR node is running in FIPS-140-2 mode).
The following displays an example of the command usage.
The following example displays the user configuration:
3.9.7. Copying and Overwriting Users and Profiles
You can copy a profile or user or overwrite an existing profile or user. The overwrite option must be specified; otherwise, an error occurs if the destination profile or user name already exists.
3.9.7.1. Copying a User
The following output displays the copied user configurations:
| Note: The cannot-change-password flag is not replicated when a copy user command is performed. A new-password-at-login flag is created instead. |
3.9.7.2. Copying a Profile
The following output displays the copied profiles:
3.9.8. Configuring SSH
Use the ssh command to configure the SSH server as SSH1, SSH2 or both. The default is SSH2. This command should only be enabled or disabled when the SSH server is disabled. This setting cannot be changed while the SSH server is running.
The following example displays the SSH server configuration as both SSH1 and SSH2 using a host-key:
3.9.9. Configuring SSH Cipher Lists
Use the ssh command to configure SSH1 or SSH2 cipher lists. Client cipher lists are used if the 7705 SAR is acting as an SSH client, and server cipher lists are used if the 7705 SAR is acting as an SSH server.
| Note: If a 7705 SAR node is running in FIPS-140-2 mode:
|
The following example displays both SSH1 and SSH2 client and server cipher list configurations:
3.9.10. Configuring SSH KEX Algorithm Lists
Use the ssh command to configure SSH2 client and server KEX algorithm lists. Client KEX algorithm lists are used if the 7705 SAR is acting as an SSH client, and server KEX algorithm lists are used if the 7705 SAR is acting as an SSH server.
| Note: If a 7705 SAR node is running in FIPS-140-2 mode:
|
The following example displays SSH2 client and server KEX list configurations:
3.9.11. Configuring SSH MAC Algorithm Lists
Use the ssh command to configure SSH2 client and server MAC algorithm lists. Client MAC algorithm lists are used if the 7705 SAR is acting as an SSH client, and server MAC algorithm lists are used if the 7705 SAR is acting as an SSH server.
| Note: If a 7705 SAR node is running in FIPS-140-2 mode:
|
The following example displays client and server MAC list configurations:
3.9.12. Configuring Login Controls
Use the login-control context to configure parameters for console, FTP, SSH, and Telnet sessions.
The following example displays the login control configuration:
The following example displays the login control configuration:
3.9.13. RADIUS Configurations
3.9.13.1. Configuring RADIUS Authentication
RADIUS is disabled by default and must be explicitly enabled. The mandatory commands to enable RADIUS on the local router are radius and server server-index address ip-address secret key. The server command adds a RADIUS server and configures the RADIUS server’s IP address, index, and key values. The index determines the sequence in which the servers are queried for authentication requests.
Also, the system IP address must be configured in order for the RADIUS client to work. See “Configuring a System Interface” in the 7705 SAR Router Configuration Guide.
The other commands are optional.
On the local router, use the following CLI commands to configure RADIUS authentication:
The following example displays the CLI syntax usage:
The following example displays the RADIUS authentication configuration:
3.9.13.2. Configuring RADIUS Authorization
In order for RADIUS authorization to function, RADIUS authentication must be enabled first. See Configuring RADIUS Authentication.
In addition to the local configuration requirements, VSAs must be configured on the RADIUS server. See Vendor-Specific Attributes (VSAs).
On the local router, use the following CLI commands to configure RADIUS authorization:
The following example displays the CLI syntax usage:
The following example displays the RADIUS authorization configuration:
3.9.13.3. Configuring RADIUS Accounting
On the local router, use the following CLI commands to configure RADIUS accounting:
The following example displays the CLI syntax usage:
The following example displays the RADIUS accounting configuration:
3.9.13.4. Configuring 802.1x RADIUS Policies
Use the following CLI commands to configure generic authentication parameters for clients using 802.1x EAPOL. Additional parameters are configured on Ethernet ports. Refer to the 7705 SAR Interface Configuration Guide, “Configuration Command Reference”, for more information on configuring 802.1x parameters on Ethernet ports.
To configure generic parameters for 802.1x authentication, enter the following CLI syntax:
The following example displays the CLI syntax usage:
The following example displays an 802.1x configuration:
3.9.14. TACACS+ Configurations
3.9.14.1. Enabling TACACS+ Authentication
To use TACACS+ authentication on the router, configure one or more TACACS+ servers on the network.
Use the following CLI commands to configure TACACS+ authentication:
The following example is configured in the config>system context:
The following example displays the TACACS+ authentication configuration:
3.9.14.2. Configuring TACACS+ Authorization
In order for TACACS+ authorization to function, TACACS+ authentication must be enabled first. See Enabling TACACS+ Authentication.
On the local router, use the following CLI commands to configure TACACS+ authorization:
The following example displays the CLI syntax usage:
The following example displays the TACACS+ authorization configuration:
3.9.14.3. Configuring TACACS+ Accounting
On the local router, use the following CLI commands to configure TACACS+ accounting:
The following example displays the CLI syntax usage:
The following example displays the TACACS+ accounting configuration:
3.9.15. Configuring Keychains
The keychain mechanism allows for the creation of keys used to authenticate protocol communications. Each keychain entry defines the authentication attributes to be used in authenticating protocol messages from remote peers or neighbors; the keychain must include at least one key entry to be valid.
Each key within a keychain must include the following attributes for the authentication of protocol messages:
- key identifier
- authentication algorithm
- authentication key
- direction
- begin time
Optionally, each key can include an end time and tolerance.
Use the following CLI commands to configure a keychain:
The following example displays a keychain configuration:
In the above example, two separate keychains are created, “ospf-md5” and “rsvp-md5”, each with two possible keys.
For ospf-md5:
- entry 0 is valid starting at midnight (UTC) on 2016/06/01
- entry 1 will become valid at midnight (UTC) on 2016/06/09 and will replace entry 0
- there is an overlap (tolerance) period of 600 seconds in which packets with either key (entry 0 or entry 1) will be accepted
For rsvp-md5:
- for transmitted packets:
- send key entry 0 is valid starting at midnight (UTC) on 2016/06/01
- send key entry 1 will become valid at midnight (UTC) on 2016/06/09 and will replace entry 0
- for received packets:
- receive key entry 0 is valid starting at midnight (UTC) on 2016/06/01
- receive key entry 1 will become valid at midnight (UTC) on 2016/06/09 and will replace entry 0
- there is an overlap (tolerance) period of 600 seconds in which receive packets with either key (entry 0 or entry 1) will be accepted