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) 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 because of misconfiguration.

The SR Linux supports a special Access Control List (ACL) type called a cpm-filter for control plane protection. There are separate Control Processing Module (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 CPM software. There are different types of cpm-filter actions that can be applied and all actions are not relevant at all locations. ACL configuration for control plane protection defines each action and how to configure it.

ACL configuration for control plane protection

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

  • accept - Allows the packet through to the next processing function.

  • 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.

  • log - Extracts information about each matching packet and sends it to the log application.

    Note:

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

  • 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 kb/s and the bucket depth is defined in units of bytes.

  • 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 the 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.

CPM filter rules

CPM filter rules that apply a system-cpu-policer or distributed-policer action do not directly specify the policer parameters. Instead, the rules 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 needed. 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:

  • IPv4 and 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), system ACLs applied globally, and determined to be locally terminating by lookup of the IP destination address

  • IPv4 and 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, and system ACLs applied globally. 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.

Restricting source subnets for incoming traffic using CPM filter

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.

(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
        }
    }

(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
        }
    }