4. Security hardening using CPM filters

Protecting the control and management plane of each routing switch in the data center fabric (access leaf, border leaf, spine, etc.) from unauthorized or out-of-profile sources of traffic is important. Without control plane protection policies, routers are vulnerable to attacks on the data center infrastructure and performance degradation can occur due to misconfiguration.

The SR Linux supports a special Access Control List (ACL) type called a cpm-filter for control plane protection. There are separate cpm-filters for IPv4 traffic and for IPv6 traffic. The entries of each cpm-filter are installed on each line card and in the Control Processing Module (CPM) software. There are different types of cpm-filter actions that can be applied and all actions are not relevant at all locations. Section 4.2 defines each action and how to configure.

4.1. Applicability

The information and configuration in this chapter are based on SR Linux Release 19.11 and later.

4.2. Configuring ACL for control plane protection

ACLs support primary and secondary actions. There are two mutually exclusive primary actions:

  1. accept - Allows the packet through to the next processing function.
  2. drop - Discards the packet without Internet Control Message Protocol (ICMP) generation.

There are three optional secondary actions that are supported in any combination. Secondary actions extend the primary action with additional packet handling operations.

  1. log - Extracts information about each matching packet and sends it to the log application.
    Note:

    The accept+log action is not supported 7220 IXR-D1, D2, and D3 systems. Only the action drop+log true is supported.

  2. distributed-policer - Sends the packet to a policer instance implemented in the forwarding ASIC of the ingress line card. This policer sends the packet to the CPM only if the policer token bucket does not go into the exceed/violate state. The rate of a distributed-policer is defined in units of Kbps and the bucket depth is defined in units of bytes.
  3. system-cpu-policer - Sends the packet to a policer instance implemented by CPM software when the packet reaches the CPM from any line card as source. This policer admits the packet to its owner application only if the policer token bucket does not go into exceed/violate state. The rate of a system-cpu-policer is defined in units of packets-per-second and the bucket depth is defined in units of packets.

4.2.1. CPM filter rules

CPM filter rules that apply a system-cpu-policer and/or distributed-policer action do not directly specify the policer parameters. Instead, they refer to a generically defined policer under the ACL configuration tree. This allows different CPM filter entries, even across multiple ACLs, to use the same policer if desired. Optionally, each policer can be configured as entry-specific. This means that a different policer instance is used by each referring filter entry, even if they are part of the same ACL.

CPM-filter ACL actions are applied to the following traffic flows:

  1. IPv4 and/or IPv6 traffic flows originating by external systems, arriving on any line card port, accepted by the interface ACLs applied to the ingress subinterface (if any), and determined to be locally terminating by lookup of the IP destination address
  2. IPv4 and/or IPv6 traffic flows originating by external systems, arriving on the Out-of-Band (OOB) management port and accepted by the interface ACLs applied to ingress traffic on the OOB port subinterface. If the CPM-filter policy has distributed-policer actions, these are ignored for inbound traffic on the OOB management port.

The startup configuration of a new SR Linux router includes a default IPv4 cpm-filter policy and a default IPv6 cpm-filter policy. These default policies block packets associated with any protocol that is not supported by the SR Linux operating system. However, they do not limit the sending sources or enforce any rate limits aside from ICMPv4/ICMPv6 traffic, which is subject to an aggregate rate limit of 1000 pps. The default policies should be modified to add these additional restrictions, and to allow protocols associated with NetOps Development Kit (NDK) applications, if applicable.

4.2.2. CPM filter configuration examples

The following examples define how to restrict the source subnets for incoming SSH traffic associated with remotely originated TCP connections to a specified IP address.

Example 1 (IPv4 address of 192.0.2.0/24)

--{ candidate shared default }--[ acl cpm-filter ipv4-filter ]--
# entry 100 match
--{ candidate shared default }--[ acl cpm-filter ipv4-filter entry 100 match ]--
# source-address 192.0.2.0/24       
--{ * candidate shared default }--[ acl cpm-filter ipv4-filter entry 100 match ]--
# protocol tcp destination-port value ssh
--{ * candidate shared default }--[ acl cpm-filter ipv4-filter entry 100 ]--
A:srlinux# action drop
-{ * candidate shared default }--[ acl cpm-filter ipv4-filter entry 100 ]--
# info
    description "Restrict the source subets 192.0.2.0/24 for incoming SSH Traffic"
    action {
        drop {
        }
    }
    match {
        protocol tcp
        source-address 192.0.2.0/24
        destination-port {
            operator eq
            value ssh
        }
    } 

Example 2 (IPv6 address of 2001:db8:3200/48)

--{ candidate shared default }--[ acl cpm-filter ipv6-filter entry 140 ]--
A:srlinux# match next-header tcp destination-port value ssh
--{ * candidate shared default }--[ acl cpm-filter ipv6-filter entry 140 ]--
A:srlinux# match source-address 2001:db8:32::/48
--{ * candidate shared default }--[ acl cpm-filter ipv6-filter entry 140 ]--
A:srlinux# action drop
-{ candidate shared default }--[ acl cpm-filter ipv6-filter entry 140 ]--
A:srlinux# info
 description "Restrict the source subets 2001:db8:32::/
 48 for incoming SSH Traffic"
    action {
        drop {
        }
    }
    match {
        next-header tcp
        source-address 2001:db8:32::/48
        destination-port {
            operator eq
            value ssh
        }
    } 

4.3. References

All ACL-related CLI commands can be found in the SR Linux Data Model Reference.