Technical Tip: FortiGate - UDP Flooding Attack is blocked but amount of traffic does not decrease

[mricardez]

Description
This article explains why the traffic does not decrease when an UDP Flooding Attack is blocked. Fortigate DoS protection identifies traffic that has the potential to cause a DoS attack by looking for specific traffic anomalies. Traffic anomalies that can cause DoS attacks include TCP syn floods, UDP and ICMP floods, TCP port scans, TCP, UDP, and ICMP session attacks, and ICMP sweep attacks. When the anomalous traffic is identified, FortiOS can block the traffic when it reaches a configured threshold. Only the traffic identified as part of a DoS attack is blocked; connections from legitimate users are identified and processed normally.

When a TCP, UDP or ICMP flood attack is received by a FortiGate, the attack is detected by FortiGate and blocked, but this blocked traffic will still be received on the WAN interface, it will just be prevented from being forwarded to another internal interface of the FortiGate.

For example, if an ICMP flood is received on the fortinet-mkz interface, targeting the IP on the WAN interface, and a DoS policy has been previously enabled on that interface, then when FortiGate detects this traffic, it will block it and prevent its transmission to the WAN interface. But this blockage does not mean that the fortigate-mkz interface will not receive the attack, it just means that this attack will not be forwarded to the WAN interface.

If the ICMP attack involve a large amount of traffic, and your fortinet-mkz interface support less bandwidth than the attack, then your service will be affected, because the bandwidth on the interface will be saturated and legitimate traffic will be affected.

When the amount of traffic of a flood is really high, the only option to stop it is to request your ISP or ask the administrator of the upstream router, to configure a black-hole router to the IP attacked that will prevent the transfer of this traffic to the FortiGate interface.

This article aims to demonstrate that, even if FortiGate detects and blocks an ICMP flood attack, it will continue to receive the traffic on the source interface.



Scope

FortiGate, v4.5.2 and earlier.

Solution
1) Create a DoS policy on the fortinet-mkz source interface.

# config firewall DoS-policy
edit 1
set interface "fortinet-mkz"
set srcaddr "all"
set dstaddr "all"
set service "ALL"
config anomaly

edit "icmp_flood"
set status enable
set log enable
set action block
set threshold 10
next
edit "icmp_sweep"
set status enable
set log enable
set threshold 50
next

2) If the traffic is not an ICMP flood attack, the traffic should be processed normally by the FortiGate.

- Normal Ping to IP 10.0.66.125 on Internet:

ping 10.0.66.125                                                                                            <-- Normal Ping
PING 10.0.66.125 (10.0.66.125) 56(84) bytes of data.
64 bytes from 10.0.66.125: icmp_seq=1 ttl=57 time=3.98 ms
64 bytes from 10.0.66.125: icmp_seq=2 ttl=57 time=9.47 ms
64 bytes from 10.0.66.125: icmp_seq=3 ttl=57 time=5.61 ms

- Traffic is received on the fortinet-mkz interface and forwarded to the wan1 interface:

# diagnose sniffer packet any 'host 10.0.66.125' 4
interfaces=[any]
filters=[host 10.0.66.125]
1.430369 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
1.430468 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
1.433480 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
1.433508 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply

- For the IPS engine, this traffic is not anomalous and is therefore not flagged as a threat:

# diagnose ips anomaly list                                                                                 <-- IPS don’t detects the attack
list nids meter:
id=icmp_flood ip=10.0.2.1 dos_id=1 exp=925 pps=1 freq=1
total # of nids meters: 1.

3) When traffic goes from normal to flooded, FortiGate detects the attack and blocks it, but traffic will continue to arrive on the source interface.


- The Normal Ping change to a Flood Ping:

ping -f 10.0.66.125                                                                                         <-- Flood Ping
PING 10.0.66.125 (10.0.66.125) 56(84) bytes of data.
..........................................................................................................................................^C
--- 10.0.66.125 ping statistics ---
313 packets transmitted, 10 received, 96% packet loss, time 3818ms
rtt min/avg/max/mdev = 3.397/5.248/8.711/1.726 ms, ipg/ewma 12.239/5.291 ms

- The IPS detects the attack, blocks it and flags it as anomalous:

# diagnose ips anomaly list
list nids meter:
id=icmp_flood ip=10.0.2.1 dos_id=1 exp=967 pps=0 freq=1
id=icmp_flood ip=10.0.66.125 dos_id=1 exp=999 pps=26 freq=82                                                <-- IPS flags this traffic as anomalous and stops it
id=icmp_sweep ip=192.168.100.2 dos_id=1 exp=867 pps=1 freq=1
total # of nids meters: 3.

- Traffic is not forwarded to the wan1 interface, but it keeps arriving on the fortinet-mkz interface:

# diagnose sniffer packet any 'host 10.0.66.125' 4
interfaces=[any]
filters=[host 10.0.66.125]
16.690731 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.691085 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.693971 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.694024 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.697226 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.697316 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.701217 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.701254 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.704971 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.705044 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.708836 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.708863 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.710846 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.710935 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.712585 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.712616 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.713966 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.714039 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.716082 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.716099 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.717341 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.717423 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.719580 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.719600 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.720837 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.720912 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.723827 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.723849 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.725961 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.726044 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.728232 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.728252 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.734709 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.734793 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.738069 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.738091 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.739328 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.739412 wan1 out 192.168.157.102 -> 10.0.66.125: icmp: echo request
16.741817 wan1 in 10.0.66.125 -> 192.168.157.102: icmp: echo reply
16.741839 fortinet-mkz out 10.0.66.125 -> 192.168.100.2: icmp: echo reply
16.743700 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request                                  <-- Attack will still be received by the interface
16.766189 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.778306 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.795423 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.804292 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.815537 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.826152 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.838150 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.850268 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.862386 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.874254 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.886121 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.898122 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.909857 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.922225 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.935345 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.946212 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.958081 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.970199 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
16.981941 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
17.232540 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
17.232581 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
17.232676 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request
17.232800 fortinet-mkz in 192.168.100.2 -> 10.0.66.125: icmp: echo request