Unicast Reverse Path Forwarding
Unicast Reverse Path Forwarding (Unicast RPF) is a feature used to prevent problems caused by packets with forged IP sources addresses passing through a router. Unicast RPF helps to prevent denial−of−ser− vice (DoS) attacks based on source IP address spoofing. Unicast RPF requires the CEF switching mechanism to be enabled globally on the router. The router does not have to have each input interface configured for CEF switching because Unicast RPF searches through the FIB using the packet’s source IP address. As long as CEF is running globally on the router, each individual interface can be configured to use other switching modes. The effect of Unicast RPF is that packets with forged source IP addresses will be dropped by the router and will not be forwarded beyond the router’s ingress interface.
Note Cisco Express Forwarding must be enabled for Unicast Reverse Path Forwarding to operate.
When Unicast RPF is enabled on an interface, the router will verify that all packets received from that interface have a verifiable source address, which is reachable via that same interface or the best return path to the source of the packet via the ingress interface. The backward lookup ability used by Unicast RPF is available only when CEF is enabled on the router because the lookup relies on the presence of the FIB. If there is a reverse path route in the FIB, the packet is forwarded as normal. If there is no reverse path route via the interface from which the packet was received, the router may interpret that packet as being forged, meaning that the source address was modified. If Unicast RPF does not find a reverse path for the packet, the packet is dropped or forwarded, depending on whether an access control list is specified in the configuration. If an access list is specified in the command, then when a packet fails the Unicast RPF check, the access list is checked to see if the packet should be dropped or forwarded. The decision is made based on the presence of a permit or deny statement within the access list. Unicast RPF events can also be logged by specifying the logging option within the ACL entries used by the Unicast RPF command. The log information can be used to gather information about an attack.
Unicast RPF can be used in any enterprise environment that is single− homed to the Internet service provider (ISP), where there is only one access point out of the network; that is, one upstream connection. This would provide ingress filtering to protect the enterprise from receiving forged packets from the Internet. Networks having one entrance and exit point provide symmetric routing, which means that the interface where a packet enters the network is also the interface the return packet takes to the source of the packet. Unicast RPF is best used at the network perimeter for Internet connections. It will also work in environments in which customers are multihomed to separate ISPs, where the enterprise has multiple access points out of the network. With Unicast RPF configured on the enterprise’s perimeter router, all equal−cost return paths are considered valid.
Unicast RPF’s advantage, when used for IP address spoof prevention, is that it dynamically adapts to changes in the routing tables, including static routes. Unicast RPF has minimal CPU overhead and has a far lower performance impact as an antispoofing tool compared to the traditional access list configuration approach. Unicast RPF should not be used on interfaces that are internal to the network because these interfaces are likely to have routing asymmetry.
Management’s major misconception is that the firewall is the first, and in many cases the last, line of defense for security−related issues. In fact the external perimeter router should provide the first line of defense for external security−related issues from the enterprises perspective.
Note The enterprise should develop a positive working relationship with its ISP. If this relationship is established, the enterprise can request that the ISP provide many of the first−line defense mechanisms.
TCP Intercept is a software feature designed to combat the denial−of− service (DoS) attack known as SYN flooding. The TCP protocol uses a three−way handshake to set up an end−to−end connection before data is allowed to flow. This handshake is detailed in Figure 3.1.
Figure 3.1: ICP three−way handshake.
Referring to Figure 3.1, assume that Host B would like to open a connection to Host A. The connection must take place via Router C. Host B sends a SYN packet (a TCP packet with the SYN bit set) to Host A, requesting a connection. Host A then replies with a SYN/ACK packet with both the SYN and ACK bits set, allowing Host B to complete the three−way handshake with a TCP ACK packet. At this point, a connection is established and data is permitted to flow.
A TCP SYN attack occurs when an attacker exploits the buffer space a networked device uses during a TCP session initialization handshake. The attacker sends a large amount of packets with the SYN bit set to the target host, and the target host’s in−process queue buffers the request and responds to it with a packet that has the SYN and ACK bits set within it. However, because these packets have an invalid return address, the connections can never be established and remain in a state known as half−open. As these half−open requests begin to build, buffer space is exhausted, which causes the machine to deny service for valid requests because all resources are exhausted waiting for a response. The target host eventually times out while waiting for the proper response.
Many TCP implementations are able to handle only a small number of outstanding connections per port; therefore, the ports become unavailable until the half−open connections time out. Additionally, this attack may also cause the server to exhaust its memory or waste processor cycles in maintaining state information for these connections.
TCP Intercept is designed to prevent a SYN flooding DoS attack by tracking, intercepting, and validating TCP connection requests. Intercept can run in one of two configurable modes: intercept mode and watch mode. In intercept mode, the software actively intercepts each incoming (SYN) request, responds on behalf of the server with a SYN/ ACK, and then waits for an ACK from the client. When that ACK is received, the original SYN is sent to the server and the software performs a three−way handshake with the server. When this is complete, the two connections are joined by the router in a source−destination session.
In watch mode, connection requests are allowed to pass through the router to the server but are watched passively until they become established. If they fail to become established within 30 seconds or a software configurable timeout, the software sends a reset packet to the server to clear the in−process buffer, allowing the server to reallocate the buffer to legitimate requests.
After a device comes under attack from SYN floods, TCP Intercept will transition to a mode known as aggressive mode. Aggressive mode is triggered if the number of incomplete connections exceeds 1,100 or the number of connections arriving in one minute exceeds 1,100; after aggressive mode has triggered, each new arriving connection causes the oldest half− open connection to be deleted. TCP Intercept will also lower its initial retransmission timeout of 1 second by half, to 0.5 seconds. This allows the router to cut in half the time allotted to establish a connection.
When TCP Intercept is in aggressive mode, the following occurs:
Each newest connection request causes the oldest half−open connection to be deleted.
The initial retransmission timeout is reduced by half, to 0.5 seconds.
If TCP Intercept is configured for watch mode, the watch timeout is reduced by half.