Another type of attack that I would like to explore about it, is called ICMP Smurf attack.

What happens in this attack is that the attacker will send a large amount of Internet Control Message Protocol (ICMP ping request) to the broadcast address of the network, and he will spoof the IP address of the victim showing that those pings are coming from the victim IP address.

As you know, if you send ping to a broadcast address, then all network devices which are in that network will receive the ping and will do the ping reply. In our case, the ping reply will go to the spoofed IP address which in our case will be the MikroTik router.

The hacker has used the IP address of R1 to be the source IP of the ping and he has sent it as a broadcast destination, this way all PCs will get it and answer back by a ping reply to R1 causing a type of DOS attack and the router to not be functional anymore.

Now we know the theory behind it, let’s apply it in a LAB to do the attack then we do the mitigation.

LAB: ICMP Smurf Attack & Prevention

I still have the same scenario as before. Let’s say that the attacker could in a way discover your LAN network address, and he could reach your WAN public IP over the internet (considering there is a LAN network connected to R1).

Let’s see how the attacker can run the ICMP Smurf attack:

The command on Kali Linux is as following:

hping3 –icmp –flood –rand-source -c 20000 –spoof 172.80.80.1 172.80.80.255

The command means that I am issuing an ICMP flood attack coming from random sources, but the reply has to go to the victim which has the IP address 172.80.80.1 (that’s the spoofed IP) and the ICMP flood goes to the destination broadcast network 172.80.80.255.

Doing so, all devices in the LAN will receive the massive number of ICMP and will do a ping reply to the victim device which is R1.

Let see what has happened to the router once we launched the attack:

Here you can see a huge number of ICMP echo request being sent to the broadcast network 172.80.80.255

What about the connections that were opened on the router when the attack was happening?

You can see, a huge number of connections were opened on the router that he should keep track of them, and all are ICMP connections.

Finally, let’s check the CPU usage on the router when the attack is still running:

No doubt, the CPU is 100% ☹

How to solve the issue with ICMP Smurf attack?

[mepr-show rules=”319″ unauth=”message”]

Actually, we have to do 2 different things to secure our router from such type of attacks:

1. We must configure the router to not respond to ping requests coming from the outside.
2. We must configure the router to not forward or accept packets directed to a broadcast address.

Let’s do the 1^st point which is to drop ICMP requests coming from our outside to our router:

This rule now will drop any ICMP packet trying to come from my WAN to the router itself.

The 2^nd rule that I need to create is to drop any ICMP packet destined to a destination broadcast address. Let’s do that:

Excellent! Now I have the 2 rules available to protect from the ICMP Smurf attack:

Let’s issue the ICMP Smurf attack again and see what we shall get:

Here the ICMP Smurf attack has started. By logic, we shall see that this attack will be dropped by the 1^st rule of the ICMP Smurf that we have created on the firewall (drop any ICMP packet coming to the Ether1).

Indeed, I see the bytes and packets are being increased on that rule, while the 2^nd rule after it is sitting idle.

When I look to the CPU, I see that it has been dropped to 60% (remember I am using a small router HAP AC lite) which is a very good indication:

Let’s check if the ICMP connections will appear on the Firewall connection tracking as it appeared before we did the filter rules:

I see nothing ???? – this will help that the router won’t be exhausted by keeping track of all those ICMP connections that were opened before we did the mitigation.

Just for curiosity, I want to see if the 2^nd rule is also working (which is to block ICMP going to a destination broadcast address). To check that, we must disable the 1^st rule that we have created, then we launch the attack and see what would happen.

Now I will disable the 1^st ICMP Smurf rule:

This has been disabled. When I launch the ICMP Smurf attack, the ICMP traffic will enter Ether1 and will ask to be sent to the broadcast address 172.80.80.255 – the 2^nd rule should drop the ICMP packets to be forwarded to the broadcast address. If you look now at the bytes and packets, you see they have a value of 0. Let’s run the attack and see what would happen:

I see that this rule is working, and it is blocking the ICMP packets to go to the destination broadcast address. I can know this by seeing the bytes and packets being increased.

What about the CPU and the connections? Let’s see:

The CPU is again around 50% and I do not see any ICMP connections open ????

That’s all about the ICMP Smurf attack and prevention, I still need to provide you with the command line so you can make the same filter rules to protect from ICMP Smurf attacks:

/ip firewall filter

add action=drop chain=input comment=”ICMP Smurf” in-interface=ether1 protocol=icmp

add action=drop chain=input dst-address-type=broadcast protocol=icmp

[/mepr-show]