Topic 1: System Hardening and Availability
1.3 Limit Access to the Network with Infrastructure ACLs
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 in order 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.
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 any !
Once 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.
ICMP Packet Filtering
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 in order 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 any !
Filter IP Fragments
The filter process for fragmented IP packets can pose a challenge to security devices. This is because the Layer 4 information that is used in order to filter TCP and UDP packets is only present in the initial fragment. Cisco IOS software uses a specific method in order to check non-initial fragments against configured access lists. Cisco IOS software evaluates these non-initial fragments against the ACL and ignores any Layer 4 filtering information. This causes non-initial fragments to be evaluated solely on the Layer 3 portion of any configured ACE.
In this example configuration, if a TCP packet destined to 192.168.1.1 on port 22 is fragmented in transit, the initial fragment is dropped as expected by the second ACE based on the Layer 4 information within the packet. However, all remaining (non-initial) fragments are allowed by the first ACE based completely on the Layer 3 information in the packet and ACE. This scenario is shown in this configuration:
! ip access-list extended ACL-FRAGMENT-EXAMPLE permit tcp any host 192.168.1.1 eq 80 deny tcp any host 192.168.1.1 eq 22 !>
Due to the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by ACLs. Fragmentation is also often used in attempts to evade detection by intrusion detection systems. It is for these reasons that IP fragments are often used in attacks, and why they must be explicitly filtered at the top of any configured iACLs. This example ACL includes comprehensive filtering of IP fragments. The functionality from this example must be used in conjunction with the functionality of the previous examples.
! ip access-list extended ACL-INFRASTRUCTURE-IN ! !--- Deny IP fragments using protocol-specific ACEs to aid in !--- classification of attack traffic ! deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments ! !--- Deny all other IP traffic to any network device ! deny ip any <infrastructure-address-space> <mask> ! !--- Permit transit traffic ! permit ip any any !
ACL Support for Filtering IP Options
Cisco IOS Software Release 12.3(4)T added support for the use of ACLs to filter IP packets based on the IP options that are contained in the packet. IP options present a security challenge for network devices because these options must be processed as exception packets. This requires a level of CPU effort that is not required for typical packets that traverse the network. The presence of IP options within a packet can also indicate an attempt to subvert security controls in the network or otherwise alter the transit characteristics of a packet. It is for these reasons that packets with IP options must be filtered at the edge of the network.
This example must be used with the ACEs from previous examples in order to include complete filtering of IP packets that contain IP options:
! ip access-list extended ACL-INFRASTRUCTURE-IN ! !--- Deny IP packets containing IP options ! deny ip any any option any-options ! !--- Deny all other IP traffic to any network device ! deny ip any <infrastructure-address-space> <mask> ! !--- Permit transit traffic ! permit ip any any !
ACL Support to Filter on TTL Value
Cisco IOS Software Release 12.4(2)T added ACL support to filter IP packets based on the Time to Live (TTL) value. The TTL value of an IP datagram is decremented by each network device as a packet flows from source to destination. Although initial values vary by operating system, when the TTL of a packet reaches zero, the packet must be dropped. The device that decrements the TTL to zero, and therefore drops the packet, is required in order to generate and send an ICMP Time Exceeded message to the source of the packet.
The generation and transmission of these messages is an exception process. Routers can perform this function when the number of IP packets that are due to expire is low, but if the number of packets due to expire is high, generation and transmission of these messages can consume all available CPU resources. This presents a DoS attack vector. It is for this reason that devices need to be hardened against DoS attacks that utilize a high rate of IP packets that are due to expire.
It is recommended that organizations filter IP packets with low TTL values at the edge of the network. Completely filtering packets with TTL values insufficient to traverse the network mitigates the threat of TTL-based attacks.
This example ACL filters packets with TTL values less than six. This provides protection against TTL expiry attacks for networks up to five hops in width.
! ip access-list extended ACL-INFRASTRUCTURE-IN ! !--- Deny IP packets with TTL values insufficient to traverse the network ! deny ip any any ttl lt 6 ! !--- Deny all other IP traffic to any network device ! deny ip any <infrastructure-address-space> <mask> ! !--- Permit transit traffic ! permit ip any any !
Note: Some protocols make legitimate use of packets with low TTL values. eBGP is one such protocol.
Next Topic: Secure Interactive Management Sessions