TTL Expiry Attack

When a packet expires on a routing platform because its TTL reaches 0, it is required to send an ICMP TTL Exceeded message back to the sender (RFC 17162).

This functionality can, however, be misused. If an attacker sends a flood of packets with the TTL value set such that the packets expire on the switch, the switch is forced to generate a large amount of ICMP TTL Exceeded messages. This causes a high CPU load.

Regarding TTL expiry attacks, what is really troubling is that an attacker can be any number of hops away from the target. As long as the TTL value is set to N-1 (where N is the number of hops to the destination IP address), the packet has TTL=1 when it reaches the switch. The switch sees that the packet has TTL=1, and forwarding it to the destination would result in TTL=0. Therefore, it drops the packet and generates an ICMP TTL Exceeded message to the sender. Figure 13-6 shows an example of a TTL expiry attack.

Figure 13-6 TTL Expiry Attack

Figure 13-6 TTL Expiry Attack

Destination

As Figure 13-6 shows, the TTL expiry attack happens as follows:

1 The attacker sends a flood of TTL=2 packets with a destination IP of a device behind the target.

2 The first router forwards the packets and reduces TTL by one.

3 The target receives the packets and drops them because forwarding them to the destination reduces TTL to 0. It also generates ICMP TTL Exceeded packets back to the sender.

4 If the amount of packets received is high enough, the target becomes busy processing the TTL expired packets and can become Instable.

What happens when you flood a 6500 with crafted TTL values? In the following lab, an attacker is one hop away from the switch, but a router is on the other side of the switch that you use as the destination address of your packets. If you send a packet with TTL=2, it has TTL=1 when it enters the switch. This results in its being dropped, and an ICMP TTL Exceeded packet is generated.

Using hping to generate the attack, first verify that you get an ICMP TTL Exceeded packet back from the 6500 when you set TTL=2:

HPING 10.0.2.6 (eth4 10.0.2.6): NO FLAGS are set, 40 headers + 0 data bytes TTL 0 during transit from ip=10.0.2.2 name=UNKNOWN

Notice that you received the ICMP packet from 10.0.2.2, which is the IP address of the input interface on the 6500.

We now start the flood attack:

Almost immediately, the CPU load on the 6500 goes through the roof, and OSPF starts having issues:

c6500#sh proc cpu

CPU utilization for five seconds: 99%/52%; one minute: 43%; five minutes: 18%

*Jan 15 09:50:02: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on GigabitEthernet2/1

from FULL to DOWN, Neighbor Down: Dead timer expired

A short time later, BGP also starts having issues:

*Jan 15 12:58:13: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down BGP Notification sent *Jan 15 12:58:13: %BGP-3-NOTIFICATION: sent to neighbor 10.10.10.1 4/0 (hold time expired) 0 bytes

When looking at the interface counters, notice that you are receiving about 85,000 pps. Also notice that you are generating about 6700 pps, most of which are ICMP TTL Exceeded packets, as Example 13-13 shows.

Example 13-13 Displaying the Interface Counters c6500#sh int gigabitEthernet 2/1

GigabitEthernet2/1 is up, line protocol is up (connected) Internet address is 10.0.2.2/30 <information removed for clarity>

Example 13-13 Displaying the Interface Counters (Continued)

30 second input rate 42650000 bits/sec, 82825 packets/sec 30 second output rate 3973000 bits/sec, 6710 packets/sec 7383429 packets input, 474779717 bytes, 0 no buffer 618440 packets output, 45768110 bytes, 0 underruns

This type of attack cannot be mitigated using CoPP on the 6500, because it is not possible to match TTL values using ACLs or match commands in class maps.

However, the built-in hardware rate limiters can rate-limit packets that would expire on the switch itself.

You can configure the TTL rate limiter to pass 10 pps to the central CPU:

c6500(config)#mls rate-limit all ttl-failure 10

Immediately, the CPU load on the switch falls to 0 percent:

c6500#sh proc cpu

CPU utilization for five seconds: 0%/0%; one minute: 40%; five minutes: 30%

By looking at the MLS statistics, notice that you are getting a high number of TTL errors. This is consistent with the attack you are generating, as Example 13-14 shows.

Example 13-14 Displaying MLS Statistics

c6500#sh mls statistics

Statistics for Earl in Module 5

L2 Forwarding Engine

Total

packets Switched :

64558040

L3 Forwarding Engine

Total

packets L3 Switched :

42056495 @

228297

PPS

Total

Packets Bridged

24096196

Total

Packets FIB Switched

4091

Total

Packets ACL Routed

0

Total

Packets Netflow Switched

0

Total

Mcast Packets Switched/Routed

219

Total

ip packets with TOS changed

797173

Total

ip packets with COS changed

0

Total

non ip packets COS changed :

0

Total

packets dropped by ACL :

0

Total

packets dropped by Policing :

0

Total

packets exceeding CIR

0

Total

packets exceeding PIR

0

Errors

MAC/IP length inconsistencies

0

Short

IP packets received :

0

IP header checksum errors

0

TTL failures

17949839

MTU failures

0

Total packets L3 Switched by all Modules:

42056495 @

228297

PPS

By looking at the interface counters, you are still receiving a high number of input packets, but the number of packets that the switch generates has been reduced dramatically, as Example 13-15 shows.

Example 13-15 Displaying Interface Counters c6500#sh int gigabitEthernet 2/1

GigabitEthernet2/1 is up, line protocol is up (connected) Internet address is 10.0.2.2/30 <information removed for clarity>

30 second input rate 56264000 bits/sec, 109521 packets/sec 30 second output rate 172000 bits/sec, 292 packets/sec 18178263 packets input, 1169201742 bytes, 0 no buffer 797303 packets output, 59007304 bytes, 0 underruns

Was this article helpful?

+6 -1

Responses

  • Elizabeth
    Is ttl expiring a risk or suspicious?
    3 months ago

Post a comment