FAQ---How to identify and to provent a TTL Expiry attack

Publication Date:  2014-11-01 Views:  912 Downloads:  0
Issue Description
Hello everybody,

I am sure that all of you know how an IPv4 header looks like and what is the role of each filed in there but for the sake of conversation I will take the liberty to describe the one field that we are interested in this topic :the TTL field



 
The Time to Live field indicates the maximum time the datagram is allowed to remain in the internet system. The TTL value is filled by the sender and is decreased at each point that the internet headeris processed to reflect the time spent processing the datagram. Even if no local information is available on the time actually spent, the field must be decremented by 1. Actually,every module that processes the datagram specific, decreases the TTL field by 1 since a datagram nowadays is not processed in a full second.
When the field reaches the value zero the datagram is discarded. The intention is to cause undeliverable datagrams to be droped, and to bound the maximum datagram lifetime.”

So, following the logic described above, if a network device (for example, router) detects that the TTL value of a packet is 0, the device discards the packet and s an ICMPv4 Type 11, Code 0 message to the initial sender resulting in a corresponding impact on the CPU.  It was just a matter of time so that a evil mind would think of sending intentionally to a device a large amount of packets with the TTL value less than 1. When receiving these IP packets, the CPUs of the attacked devices become busy processing the packets and sending replies. In this way the CPU usage increases and all the network services are affected.
 
Solution
Now what can we do to discover and to protect this?

An alarm signal should be the appearance of logs that are describing that the CPCAR limit for the ttl-expired packets reached the limit:

Oct 10 2014 08:01:01+01:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[6]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=ttl-expired, CIR/CBS=64/10000, ExceededPacketCount=3594)

Without any special configuration the device will generate these alarms when the CPCAR limit described by the default cpu-defend policy is reached.

After you receive this kind of logs you should check how many packets are sent to the cpu or how many are discarded.  You should also see if the cpu usage is affected by them

Here the display cpu-usage and display cpu-defend statistics commands come in handy. If the cpu-usage is affected and the device is receiving a big number of ttl-expired packets we should consider to take some measures to reduce the impact on the cpu and implicitly on our network.

Huawei_CORE>display cpu-defend statistics all
Statistics on slot 0:
--------------------------------------------------------------------------------
Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte)  Last-dropping-time
ttl-expired                  190434811            61115743  2014-10-10 08:21:01
                           16574498088          6089746250
--------------------------------------------------------------------------------


Solutions :

Another reason of the high cpu usage could be the big number of ttl-expired packets that are reaching the switch. I saw that you have already configured and applide a cpu-defend policy to monitor the ttl-expired packets and to check the source of the attack but you haven’t taken any action against it.
The first step should be to find out the source of the attack. To do this we can configure a cpu-defend policy to use the attack source tracing function to find out the ip source of most of the ttl-expired packets .


        cpu-defend policy p1
auto-defend enable
auto-defend attack-packet sample 4
auto-defend threshold 30//// when the number of packets sent from a source in a specified period is bigger than the threshold the device traces and logs the soure

auto-defend alarm enable // an alarm is generated when the threshold for packets is reached
auto-defend alarm threshold 30
auto-defend trace-type source-mac source-ip source-portvlan // trace the source mac,ip and vlan
auto-defend protocol ttl-expired  // identify ttl-expired packets


When you make this configuration, you should also pay attention to the sampling rate . This can affect the cpu usage as well if it is used for a long time. A small sampling ratio makes the attack source tracing result accurate, but increases CPU usage.

After this configuration is made, you will receive alarm messages to inform you when the threshold is passed and you can also check the source  with the display auto-defend attack-source command .

Example:

Oct 10 2014 08:02:07+01:00 Huawei %%01SECE/4/PORT_ATTACK(l)[4]:Port attack occurred.(Slot=MPU, SourceAttackInterface=XGigabitEthernet0/0/1, OuterVlan/InnerVlan=200/0, AttackProtocol=TTL_EXPIRED, AttackPackets=36 packets per second)



<Huawei>display auto-defend attack-source
  Attack Source User Table (MPU):
  -----------------------------------------------------------------------------
  MacAddress       InterfaceName               Vlan:Outer/Inner    TotalPackets
  -----------------------------------------------------------------------------
  aaaa-bbbb-cccc   XGigabitEthernet0/0/1       200                7696
  -----------------------------------------------------------------------------
  Total: 1

  Attack Source IP Table (MPU):
  -----------------------------
  IPAddress        TotalPackets
  -----------------------------
  100.100.160.91   464
  -----------------------------
  Total: 1


We can see that a lot of the packets come from the aaaa-bbbb-cccc   mac address and I think we can put this mac address into a black list to filter out the packets with that source.


The other thing we can do is to limit the attack is to apply a punishment policy to discard packets from the identified attack  source for a period of time. To do this you have to modify the cpu defend policy and run the auto-defend action deny timer [time] command which will discard packets from the attack source for a period of time .

Thank you.

END