180 Chapter 4: IP Data Plane Security
and default gateways typically do not exchange routing protocol information and because ICMP Redirects are generated only if the source of the original packet is directly connected. An IP host’s statically or DHCP assigned default gateway may not provide the best path to a remote destination. In these scenarios, the default gateway forwards the packet but also generates an ICMP Redirect to the source IP host. Therefore, the logical place to apply the no ip redirects command to mitigate the risk of ICMP Redirect attacks is on router interfaces that do not provide default gateway services via a shared LAN. Disabling ICMP redirects on shared LAN default gateway router interfaces is also an option and is often considered a best practice to prevent the generation of ICMP redirect messages from impacting the IOS process level. Example 4-13 illustrates the Cisco IOS CLI used to disable the generation of ICMP Redirect messages on an Ethernet interface.
Example 4-13 Conﬁguration for no ip redirects Interface Command
interface Ethernet 0 no ip redirects
Note More information on the generation of ICMP Redirect messages may be found in the Cisco.com document “When Are ICMP Redirects Sent?” (see the “Further Reading” section).
• IP packet with parameter problem: Per RFC 792, if an IP router receives a packet with an IP header problem and discards the packet, it must generate an ICMP Parameter Problem (Type 12) message. These are only sent if the IP packet is discarded. The default behavior within IOS is to generate such ICMP Parameter Problem messages, and there is no CLI to disable this behavior. CoPP may be used to limit the impact of DoS attacks using IP packets with parameter problems. (For further information on CoPP, refer to Chapter 5.) Note that such attacks generally apply only to ﬁrst-hop (default gateway) routers, because they would ﬁrst encounter and discard such malformed packets rather than forward them downstream. Hence, default gateway routers are most susceptible to this speciﬁc attack.
• IP packet with expired TTL: Per RFC 792, if an IP router receives a packet with a TTL value of 1 or 0, the packet must be discarded and an ICMP Time Exceeded (Type 11) message must be generated and sent to the original source. The default behavior within IOS is to generate such ICMP Time Exceeded messages, and there is no CLI available to disable it. However, other techniques are available to mitigate the risk of TTL expiry–based DoS attacks, including:
— ACL ﬁltering of IP TTL. For further information, refer to the “Interface ACL Techniques” section earlier in the chapter.
— CoPP. For further information, refer to Chapter 5.
— Disabling IP TTL to MPLS TTL propagation within MPLS networks. For further information, refer to Chapter 7.
Disabling IP Directed Broadcasts 181
Because ICMP packets often bridge the data plane and control plane, you should put extra effort into understanding their use and misuse and methods to control their generation. As described previously, both data plane and control plane security techniques are often used for these purposes. Techniques to mitigate the risk of attacks using ICMP protocol packets are discussed in Chapter 5.
Disabling IP Directed Broadcasts
An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for an IP subnet (or network) that is one or more router hops from the source address. Intermediate routers that are not directly connected to the destination subnet forward IP directed broadcasts in the same way as unicast IP packets. However, when a directed broadcast packet reaches the ultimate hop router that is directly connected to the destination subnet, it is broadcast to every IP device attached to that subnet using the Layer 2 link-layer broadcast address. This is consistent with the IP broadcast address 255.255.255.255/32, however, IP directed broadcasts allow IP broadcasts to be remotely transmitted versus remaining local to the directly connected network. Each IP router (and device) listens for the IP broadcast address of its own subnet and handles such packets as a CEF receive adjacency.
IP directed broadcasts, and speciﬁcally ICMP directed broadcasts, have been used to launch DoS attacks (see, for example, “CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks,” at http://www.cert.org/advisories/CA-1998-01.html). As a result, and given the limited legitimate uses of IP directed broadcasts, IOS changed the default interface conﬁguration to no ip directed-broadcast, which disables IP directed broadcasting. When disabled for an interface, directed broadcasts destined for the associated IP subnet to which that interface is attached will be discarded, rather than being broadcast. This command only affects the ﬁnal transmission of the directed broadcast on the egress interface of the ultimate hop router. It does not affect the transit unicast routing of IP directed broadcasts along the forwarding path to the ultimate hop router. Alternatively, an ACL may be conﬁgured to ﬁlter unauthorized directed broadcasts. In this way, only directed broadcasts that are permitted by the ACL will be forwarded; all other directed broadcasts will be discarded.
For those IP networks or speciﬁc subnets that may require IP directed broadcasts, it may be enabled by applying the ip directed-broadcast command within IOS interface conﬁguration mode. When enabled, ACLs are recommended to limit the scope of IP directed broadcasts. For example, only devices associated with trusted (or internal) IP subnets may be permitted to transmit IP directed broadcasts. Conversely, IP directed broadcasts sourced from untrusted (or external) IP subnets should be ﬁltered. Antispooﬁng techniques, including ACLs and uRPF, may be used to mitigate the risk of spoofed IP directed broadcasts. If IP directed broadcast support has been enabled and you want to disable this functionality, use the no ip directed-broadcast IOS interface conﬁguration command.
182 Chapter 4: IP Data Plane Security
IP Sanity Checks
IP routers perform integrity checks on received packets, including veriﬁcation of the IP checksum and the IP header format, including options ﬁelds. If a router discards a packet due to a header parameter problem, the router may signal that to the packet source via an ICMP Parameter Problem message (Type 12) indicating the error condition. Within the control plane, routers also perform integrity checks to validate routing protocol advertisements received. Such integrity checks are often speciﬁed within the IETF protocol speciﬁcations and state machines. OSPF advertisements received, for example, are not accepted at the IP process level per Section 8.2 of RFC 2328 until a variety of integrity checks are performed against both the IP and OSPF packet headers. Other control plane protocols have their own distinct integrity checks, given the inherent differences among them, including transport layer protocol checks. TCP-based protocols, for example, verify packet sequence numbers before accepting packets associated with established sessions. Conversely, Generalized TTL Security Mechanism (GTSM) is an IP integrity check that is protocol independent and helps to reduce the risk of spoofed attacks. For more information on GTSM, refer to Chapter 5.
To reduce the risk of spoofed and broadcast attacks, high-end Cisco routers have integrated additional IP sanity checks within the data plane to ﬁlter illegal packets having
• IP source address equal to IANA reserved IP multicast address 126.96.36.199/4
• IP source address equal to the IANA reserved host loopback address 127.0.0.0/8 • IP source address equal to the all 1s broadcast address 255.255.255.255/32
• IP destination address equal to the all 0s network address 0.0.0.0/32
The preceding packet types are illegal and are discarded with no ICMP messages generated. Although support is limited to high-end Cisco routers such as the Cisco 12000 series, it is recommended that you add similar checks to interface ACL policies as illustrated in the Example 4-14 conﬁguration.
Example 4-14 IP Sanity Check Access List Illustration
interface pos1/1 access-group 100 in
access-list 100 deny ip 188.8.131.52 184.108.40.206 any access-list 100 deny ip 127.0.0.0 0.255.255.255 any access-list 100 deny ip 255.255.255.255 0.0.0.0 any access-list 100 deny ip any 0.0.0.0 0.0.0.0
access-list 100 permit ip any any
You should consider ﬁltering other illegal IP address combinations within your ACL policies as deﬁned within RFC 3330.
BGP Policy Enforcement Using QPPB 183
BGP Policy Enforcement Using QPPB
As outlined within the “Interface ACL Techniques” section earlier in the chapter, interface ACLs provide static policies within the data plane to ﬁlter IP trafﬁc ﬂows. Hence, ACLs work well when trafﬁc ﬁltering policies are generally static. For those applications where trafﬁc ﬁltering policies change frequently, ACLs are often too difﬁcult and costly to manually maintain. Enforcement of Internet peering agreements is one such application where SPs often consider the cost of manually maintaining ingress ACL policies to be too signiﬁcant compared to the risk of Internet peers violating established agreements. As a result, many SPs simply rely upon control plane techniques to enforce peering agreements. Control plane–based techniques, however, only affect routing protocol policies and do not mitigate the risk of an Internet peer using IP routing tricks to bypass control plane techniques and, thereby, steal bandwidth in violation of peering agreements. Consider the network topology illustrated in Figure 4-9.
Figure 4-9 Internet Peering Policy Violation
Peers cannot use one another as transit to other peers
Internet Peers (10.0.0.0/8) Internet Peers
SP-2 eBGP 172.16.0.0/16
SP-2 and SP-3 are both Internet peers of SP-1. As a result, SP-1 and SP-2 exchange only their customer IP preﬁxes with one another via eBGP, as do SP-1 and SP-3. Because
SP-2 and SP-3 only peer with SP-1 (either settlement-free or settlement-based) and do not purchase Internet transit services from SP-1, from the perspective of SP-1, there should be
184 Chapter 4: IP Data Plane Security
no IP reachability between SP-2 and SP-3. That is, SP-2 and SP-3 should not be using SP-1 as transit to reach each other’s preﬁxes.
In general, Internet peering between SPs provides IP reachability to each other’s customer preﬁxes (not downstream peer preﬁxes). Per Figure 4-9, trafﬁc between 172.16.0.0/16 and 192.168.0.0/16 networks should not transit SP-1. Otherwise, such trafﬁc ﬂows between SP-2 and SP-3 would effectively be stealing bandwidth from SP-1. Conversely, SP-1 customer preﬁxes (for example, 220.127.116.11/27) have full IP reachability to and from both SP-2 and SP-3 preﬁxes because SP-1 has established peering agreements with both SP-2 and SP-3. If SP-2 desires IP reachability to SP-3 preﬁxes, and vice versa, SP-2
and SP-3 should either peer with one another directly or purchase Internet transit services from SP-1. Although the beneﬁt for SP-1 in peering with both SP-2 and SP-3 is IP reachability to their respective customer preﬁxes, in general, there is no beneﬁt for SP-1 in providing free transit services between SP-2 and SP-3. If SP-2 and SP-3 do not purchase SP-1 transit services and remain SP-1 peers, any transit trafﬁc transferred between SP-2 and SP-3 via SP-1 is considered to be in violation of the SP-1 peering agreements. Although this may be considered a business dispute between Internet peers, such trafﬁc may adversely affect (paying) transit customers of SP-1 in terms of packet delay, loss, and jitter. Hence, SP-1 needs to protect its (paying) transit customers and well-behaved (conforming) peers and mitigate the risk of Internet peers stealing bandwidth in violation of established peering agreements.
Typically, SP-1 prevents IP reachability between SP-2 and SP-3 solely through BGP routing policies (in other words, control plane). BGP route maps and preﬁx ﬁlters control route advertisements and prevent the propagation of SP-2 and SP-3 customer preﬁxes between one another. In this way, SP-2 does not learn SP-3 customer preﬁxes via eBGP, and vice versa. If, however, SP-2 or SP-3 plays routing tricks to bypass these control plane policies, such as using SP-1 as a default route, then SP-1 may forward unauthorized transit trafﬁc between SP-2 and SP-3, because the BGP techniques just outlined do not apply within the IP data plane. Hence, SP-1 is at risk of an Internet peer using IP routing tricks to circumvent BGP peering policies and, thereby, steal bandwidth in violation of established peering agreements. For more information on the BGP security techniques, refer to Chapter 5.
SPs are able to monitor peering policy violations through NetFlow and BGP policy accounting. However, these techniques do not ﬁlter trafﬁc ﬂows that violate policies. They only allow the SP to detect peering violations, not mitigate them. Data plane techniques are required to ﬁlter trafﬁc ﬂows that bypass BGP routing policies. For more information on NetFlow and BGP policy accounting, see Chapter 6.
As mentioned, ACLs may be used by SP-1 to prevent IP reachability between SP-2 and SP-3. Such an ACL would be applied, for example, on SP-1’s external interfaces to SP-2 and SP-3 and would ﬁlter any trafﬁc not destined to an SP-1 transit customer preﬁx. This
nguon tai.lieu . vn