Configuring Authentication

Refer to the following sections to configure authentication:

Configuring Authorization

Refer to the following sections to configure authorization.

Configuring Accounting

Refer to the following sections to configure accounting.

Configuring Management Access Filters

Creating and implementing management access filters is optional. Management access filters are software-based filters that control all traffic going in to the CPM, including all routing protocols. They apply to packets from all ports. The filters can be used to restrict management of the 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. These filters also apply to the management Ethernet port.

The OS implementation exits the filter when the first match is found and execute the actions according to the specified action. For this reason, entries must be sequenced correctly from most to least explicit. When both mac-filter and ip-filter/ipv6-filter are to be applied to a given traffic, mac-filter is applied first.

An entry may not have any match criteria defined (in which case, everything matches) but must have at least an action keyword specified CPM to be considered active complete. Entries without the action keyword are considered incomplete and will be rendered inactive. Management Access Filter must have at least one active entry defined for the filter to be active.

The following CLI commands are an example of how to configure a management access filter on the 7450 ESS. This example only accepts packets matching the criteria specified in entries 1 and 2. Non-matching packets are denied.

The following is an example of a management access filter configuration that accepts packets matching the criteria specified in IP, IPv6 and MAC entries. Non-matching packets are denied for IPv4 filter and permitted for IPv6 and MAC filters.

The following displays a management access filter configuration example:

Configuring IP CPM Filters Policy

The following displays a CPM filter configuration example:

Configuring MAC CPM Filters

CPM filters and queues control all traffic going in to the CPM, 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 and queuing is performed by network processor hardware using no resources on the main CPUs. CPM filters and queues are not configurable on one-slot chassis.

The following displays a MAC CPM filter configuration example:

Configuring IPv6 CPM Filters

Use the following CLI commands to configure an IPv6 CPM filter.

The following example displays an IPv6 CPM filter configuration:

Configuring CPM Queues

Use the following CLI commands to configure a CPM queue.

CPM queues can be used to provide rate limit capabilities for traffic destined to CPM as described in an earlier section of this document.

The following example displays a CPM queue configuration:

IPSec Certificates Parameters

The following is an example to importing a certificate from a pem format:

The following is an example for exporting a certificate to pem format:

The following displays an example of profile output:

The following displays an example of an ike-policy with cert-auth output:

The following displays an example of a static lan-to-lan configuration using cert-auth:

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 sixteen user profiles can be defined. A user can participate in up to sixteen profiles. Depending on the authorization requirements, passwords are configured locally or on the RADIUS server.

The following example displays a user profile output:

Parameters

Matching in authorization profiles allows the use of parameters and optional parameters. A set of angle brackets <...> indicates matching on a parameter and/or optional parameter.

The following rules govern parameter matching in the CLI:

Rule 1

Any parameter and/or optional parameter can be present in the match string.

Rule 2

When a parameter and/or optional parameter is present in the user-profile match string, all parameters or optional parameters to its left must also be stated/present.

Rule 3

The user can either specifically state or completely omit unnamed parameters in the match string, as required. However, all unnamed parameter in the CLI command must be present in the match string when matching on an unnamed parameter is used.

For example, consider the OSPF command:

*A:SwSim14# configure router ospf

- no ospf [<ospf-instance>]

- ospf [<ospf-instance>] [<router-id>]

<ospf-instance> : [0..31]

<router-id> : <ip-address>

In this case, the user can match on OSPF to allow or deny the command per user-profile, as follows:

Match “configure router ospf” action deny

Or the user can decide to only allow a certain OSPF instance for a user, as follows:

Match “configure router ospf <ospf-instance-value> <router-id-value>”

Note: Although the user’s matching is based on <ospf-instance-value> that is “an unnamed value”, all other unnamed values in the OSPF command (such as the <router-id-value>) must also be present in the match string.

Rule 4

When multiple unnamed parameters are present in the match string, the parameters must be provided in the correct order as described in the command help to generate the correct match behavior. For example, using the order of parameters described in the OSPF command usage in Rule 3 above, use the following statement for a user-profile match:

match “configure router ospf <ospf-instance-value> <router-id-value>

The desired match behavior might not be achieved if the unnamed parameters <ospf-instance-value> and <router-id-value> are out of order with respect to the help screen.

The following displays a parameter matching output:

config>system>security>profile# info

entry 10

match "show router <22> route-table "

action permit

exit

entry 20

match "configure service vprn <22>"

action read-only

exit

entry 30

match "show service id <22>"

action permit

exit

entry 40

match "configure router interface <system>"

action deny

exit

Wildcards

In addition, parameter configuration is facilitated by the availability of wildcards (.*) in the OAM subtree and for commands such as “ping”, “trace-route” and “m-trace”. For example, consider the following command:

ping <ip-address> router 10

Instead of listing all the permitted IP addresses in the policy, as shown in the following example,

Match ping <10.0.0.1> router <10>

Action permit

Match ping <10.0.0.2> router <10>

Action permit

The wildcard<ip-address> parameter allows a a simpler search criterion. In the following example, the use of <.*> wildcard enables you to ping any address in the router 10 context, that is, any address in VRF 10:

Match ping <.*> router <10>

Action permit

Note: While wildcards are available and allowed for all parameters in the OAM subtree, Alcatel-Lucent recommends that you must exercise caution when using wildcards and limit their use to commands such as ‘ping’, ‘trace-route’ and ‘m-trace’. The use of wildcards in certain formats may be a security concern and result in making the IP addresses in the VRF, including the base routing table, unreachable. Or it could allow the customer to ping any IP address in the VRF, including the base routing table. This may be a potential security concern and should be avoided.

For example, the following usage is not advised:

Match ping <.*> router <.*>

Action permit

CLI Session Resource Management

SR OS has the capability to manage telnet/ssh sessions per user and at a higher level per system. At the system level, the user can configure a cli-session-group for different customer priorities. The cli-session-group is a container that sets the maximum number of CLI sessions for a class of customers, with a unique session limit for each customer. For example, as depicted in Figure 7, “Gold” category customers can have a cli-session-group that allows them more telnet/ssh sessions compared to “Silver” category customers.

Figure 7:  cli-session-group for Customer Classes 

The configured cli-session-group can be assigned to user-profiles. At the user profile level, each profile can be configured with its own max ssh/telnet session and it will be policed/restricted by the higher order cli-session-group that is assigned to it.

As depicted in Figure 8, the final picture is a hierarchical configuration with top-level cli-session-groups that control each customer’s total number of ssh/telnet sessions and the user-profile for each user for that customer.

Figure 8:  Hierarchy of cli-session-group Profiles  

Every profile will subtract one from it’s corresponding max-session when a TELNET or SSH session is established in the following cases:

1. where multiple profiles are configured under a user
2. where multiple profiles arrive from different AAA servers (Local Profile, Radius Profile or Tacacs Profile)

The first profile to run out of corresponding max-session will limit future TELNET or SSH sessions. In other words, while each profile for the user can have its independent max-session, only the lowest one will be honored. If the profile with the lowest max-session is removed, the next lower profile max-session will be honored and so on. All profiles for a user are updated when a TELNET or SSH session is established.

For information about login control, see Configuring Login Controls on page 81.

Use the following CLI commands to configure CLI session resources:

CLI Syntax:

config>system>security>profile <name>

[no] ssh-max-sessions session-limit

[no] telnet-max-sessions session-limit

[no]combined-max-session session-limit

[no] cli-session-group session-group-name

Configuring Users

Configure access parameters for individual users. For user, define the login name for the user and, optionally, information that identifies the user.

The following displays a user configuration example:

Configuring Keychains

The following displays a keychain configuration.

Copying and Overwriting Users and Profiles

You can copy a profile or user. You can copy a profile or user or overwrite an existing profile or user. The overwrite option must be specified or an error occurs if the destination profile or user name already exists.

User

CLI Syntax:

config>system>security# copy {user source-user | profile source-profile} to destination [overwrite]

Example:

config>system>security# copy user testuser to testuserA

MINOR: CLI User "testuserA" already exists - use overwrite flag.

config>system>security#

config>system>security# copy user testuser to testuserA overwrite

config>system>security#

The following output displays the copied user configurations:

A:ALA-12>config>system>security# info

----------------------------------------------

...

user "testuser"

password "$2y$10$pFoehOg/tCbBMPDJ/kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"

access snmp

snmp

authentication hash md5 e14672e71d3e96e7a1e19472527ee969 privacy none

group "testgroup"

exit

exit

user "testuserA"

password ""

access snmp

console

new-password-at-login

exit

snmp

authentication hash md5 e14672e71d3e96e7a1e19472527ee969 privacy none

group "testgroup"

exit

exit

...

----------------------------------------------

A:ALA-12>config>system>security# info

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.

A:ALA-12>config>system>security>user# info

----------------------------------------------

password "$2y$10$pFoehOg/tCbBMPDJ/kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"

access snmp

console

cannot-change-password

exit

snmp

authentication hash md5 e14672e71d3e96e7a1e19472527ee969 privacy none

group "testgroup"

exit

----------------------------------------------

A:ALA-12>config>system>security>user# exit

A:ALA-12>config>system>security# user testuserA

A:ALA-12>config>system>security>user# info

----------------------------------------------

password ""

access snmp

console

new-password-at-login

exit

snmp

authentication hash md5 e14672e71d3e96e7a1e19472527ee969 privacy none

group "testgroup"

exit

----------------------------------------------

A:ALA-12>config>system>security>user#

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.

Also, the system IP address must be configured in order for the RADIUS client to work. See Configuring a System Interface of the Router Configuration Guide.

The other commands are optional. 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.

On the local router, use the following CLI commands to configure RADIUS authentication:

The following displays a RADIUS authentication configuration example:

Configuring RADIUS Authorization

In order for RADIUS authorization to function, RADIUS authentication must be enabled first. See Configuring RADIUS Authentication on page 76.

In addition to the local configuration requirements, VSAs must be configured on the RADIUS server. See Vendor-Specific Attributes (VSAs) on page 43.

On the local router, use the following CLI commands to configure RADIUS authorization:

The following displays a RADIUS authorization configuration example:

Configuring RADIUS Accounting

On the local router, use the following CLI commands to configure RADIUS accounting:

The following displays RADIUS accounting configuration example:

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 profiles:

The following displays a TACACS+ authentication configuration example:

Configuring TACACS+ Authorization

In order for TACACS+ authorization to function, TACACS+ authentication must be enabled first. See Enabling TACACS+ Authentication on page 78.

On the local router, use the following CLI commands to configure RADIUS authorization:

The following displays a TACACS+ authorization configuration example:

Configuring TACACS+ Accounting

On the local router, use the following CLI commands to configure TACACS+ accounting:

The following displays a TACACS+ accounting configuration example:

Enabling SSH

Use the SSH command to configure the SSH server as SSH1, SSH2 or both. The default is SSH2 (SSH version 2). This command should only be enabled or disabled when the SSH server is disabled. This setting should not be changed while the SSH server is running since the actual change only takes place after SSH is disabled or enabled.

The following displays a SSH server configuration as both SSH and SSH2 using a host-key: