Devised to prevent unauthorized direct communication to network devices, infrastructure access control lists (iACLs) are one of the most critical security controls that can be implemented in networks. Infrastructure ACLs leverage the idea that nearly all network traffic traverses the network and is not destined to the network itself.
An iACL is constructed and applied to specify connections from hosts or networks that need to be allowed to network devices. Common examples of these types of connections are eBGP, SSH, and SNMP. After the required connections have been permitted, all other traffic to the infrastructure is explicitly denied. All transit traffic that crosses the network and is not destined to infrastructure devices is then explicitly permitted.
The protections provided by iACLs are relevant to both the management and control planes. The implementation of iACLs can be made easier through the use of distinct addressing for network infrastructure devices. Refer to A Security Oriented Approach to IP Addressing for more information on the security implications of IP addressing.
This example iACL configuration illustrates the structure that must be used as a starting point when you begin the iACL implementation process:
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!
permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
permit tcp host <trusted-management-stations> any eq 22
permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any anyOnce created, the iACL must be applied to all interfaces that face non-infrastructure devices. This includes interfaces that connect to other organizations, remote access segments, user segments, and segments in data centers.
The Internet Control Message Protocol (ICMP) is designed as an IP control protocol. As such, the messages it conveys can have far-reaching ramifications to the TCP and IP protocols in general. While the network troubleshooting tools ping and traceroute use ICMP, external ICMP connectivity is rarely needed for the proper operation of a network. Cisco IOS software provides functionality to specifically filter ICMP messages by name or type and code. This example ACL, which must be used with the access control entries (ACEs) from previous examples, allows pings from trusted management stations and NMS servers and blocks all other ICMP packets:
ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!
permit icmp host <trusted-management-stations> any echo
permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!
deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!
permit ip any anyUnicast RPF enables a device to verify that the source address of a forwarded packet can be reached through the interface that received the packet. You must not rely on Unicast RPF as the only protection against spoofing. Spoofed packets could enter the network through a Unicast RPF-enabled interface if an appropriate return route to the source IP address exists. Unicast RPF relies on you to enable Cisco Express Forwarding on each device, and is configured on a per-interface basis.
Unicast RPF can be configured in one of two modes: loose or strict. In cases where there is asymmetric routing, loose mode is preferred because strict mode is known to drop packets in these situations. During configuration of the ip verify interface configuration command, the keyword any configures loose mode while the keyword rx configures strict mode.
This example illustrates configuration of this feature:
!
ip cef
!
interface <interface>
ip verify unicast source reachable-via <mode>
!