Protecting the Infrastructure Using ACLs

In an effort to protect switches and routers from various risks—both accidental and malicious—infrastructure-protection ACLs need to be deployed at network ingress points. These ACLs deny access from external sources to all infrastructure addresses, such as router interfaces. At the same time, these ACLs permit legitimate transit traffic to flow uninterrupted through the infrastructure. A common set of ACLs consists of filtering addresses that have no business entering the network. Those are, for example, addresses defined in RFC 1918 and RFC 3330.

Data received by a router can be divided into two broad categories:

• Traffic that passes through the switch or router

• Traffic destined to the switch or router

In normal operations, the vast majority of traffic flows through the infrastructure to reach its ultimate destination. However, several cases exist where the router processor or switch processor (RP/SP) must directly handle data, most notably routing protocols, remote router access (such as Secure Shell [SSH]), and network management traffic (such as Simple Network Management Protocol [SNMP]). In addition, protocols such as ICMP and IP options can require direct processing by the RP/SP. Most often, direct access to the infrastructure should be permitted only when it's initiated from internal sources. There are a few notable exceptions, such as Border Gateway Protocol (BGP) peering; protocols that terminate on the RP/SP, such as generic routing encapsulation [GRE]; and potentially limited ICMP packets for connectivity testing, such as echo-request or ICMP unreachables and Time to Live (TTL) expired messages for proper traceroute operation.

NOTE ICMP is often used for simple DoS attacks; it should only be permitted from external sources, if necessary.

Although the data plane of most switches can handle millions and millions of packets per second, the same does not hold true as far as the control plane is concerned. The data plane is usually made up of ASICs built to switch packets from one port to another as fast as possible. The control plane, on the other hand, is often comprised of generic all-purpose processors. Excessive traffic destined to the control plane can easily overwhelm the switch, which causes high CPU usage that ultimately results in undesired and unpredictable behavior. By filtering access to infrastructure equipment from external sources, many external risks associated with a direct switch or router attack are mitigated. Externally sourced attacks can no longer access infrastructure equipment. Example 16-1 shows a common ingress perimeter filtering ACL.

Example 16-1 IPv4 Infrastructure Protection ACL

!— Anti-spoofing entries first

!— Deny special-use address sources.

!— Refer to RFC 3330 for additional special use addresses.

access-list

100

deny

ip host 0.0.0.0 any

access-list

100

deny

ip 127.0.0.0 0.255.255.255 any

access-list

100

deny

ip 192.0.2.0 0.0.0.255 any

access-list

100

deny

ip 224.0.0.0 31.255.255.255 any

!— Filter

RFC

1918

space.

access-list

100

deny

ip 10.0.0.0 0.255.255.255 any

access-list

100

deny

ip 172.16.0.0 0.15.255.255 any

access-list

100

deny

ip 192.168.0.0 0.0.255.255 any

!— Deny your IP space as source from entering your network.

access-list

100

deny

ip YOUR_IP_RANGE any

! — Permit

BGP

access-list

100

permit tcp host bgp_peer host router_ip eq bgp

access-list

100

permit tcp host bgp_peer eq bgp host router_ip

!— Deny access to internal infrastructure addresses.

access-list

100

deny

ip any INTERNAL_INFRASTRUCTURE_ADDRESSES

! — Permit

transit traffic.

access-list

100

permit ip any any

The ACL in Example 16-1 provides a good starting template for infrastructure protection. Naturally, customize it to fit your network environment. For more information on applying ingress ACLs, see RFC 2267.

Continue reading here: Racl Vacl and PACL Many Types of ACLs

Was this article helpful?

0 0