I am sure that you, as a network engineer, already know how communication will start between 2 devices that want to use an application which run on TCP protocol. Some types of those applications are http, https, Telnet, SSH, and so on.

If you can’t recall the 3-way handshake that happens in every TCP session, then I will remind you about that.

In fact, whenever you open a website (for example), then a TCP 3-way handshake will happen in the background (most probably the website run on https application which use the TCP protocol).

This is an illustration about the TCP 3-way handshake:

This 3-way handshake happens every time a sender likes to run an application running TCP protocol before the data starts flowing.

Attackers take profit from the 3-way handshake to run some type of attacks in order to exhaust the receiver with a huge number of TCP SYN. To make it easier for you to understand, let me show it to you in an illustration:

As you see, the attacker has launched many SYN messages to the receiver and the receiver will answer by ACK/SYN to every message. The attacker will never provide an ACK back to have the 3-way handshake completed, however he will keep sending TCP SYN non-stop to exhausted the receiver – this is what we call a SYN flood attack which is a type of DOS.

Now we understand how this attack works, let’s issue the attack on the MikroTik router as a LAB then do the mitigation to protect from it.

LAB: TCP SYN Attack & Prevention

Let’s consider that R1 is a router connected to the internet with a public IP on its interface Ether1, meaning that it can be reachable to its IP from anyone on the internet.

One attacker has done some reconnaissance attack and seen that on R1 there are some applications running on protocol TCP which are open. So, he has decided to run TCP flood attack to bring the router down.

You may say now: how he could find there are some TCP applications running on the router? Well again, Kali Linux can do this for us, let me show you how:

With the aid of NMAP application that I have it running on Kali Linux, I could discover that on this router there are many applications running on TCP protocol (please note that I do not have a public IP on my router, so I am just using a private IP to reach to the router).

Now that the attacker knows that you have TCP based applications open on the router, so why doesn’t he run the TCP flood attack?

Let’s run it and see what we will have as an output:

You need to have “hping3” downloaded and installed on your Kali Linux machine, then you will run the following command to issue the TCP SYN flood attack:

hping3 -c 15000 -d 120 -S -w 64 -p 80 –flood –rand-source 172.80.80.1

In just like 1 second, I could catch this print screen of the router before it kicked me out of the Winbox, and it has showed the CPU going to 100% and received a huge traffic on the interface Ether1 as TCP (mainly the attack is running on http as you see).

Imagine that this is the router that you are running in your company, and it has crashed down, I do not think your boss will be very happy from you, do you agree with me?

So, what shall we do now? How to fix the issue?

Well, there is 2 different ways to make the prevention:

• Using the Firewall filter rules
• Using the Firewall Raw

In this LAB, I will show you how to use the Firewall Filter rules to limit the TCP SYN to your router. In another LAB in this book, after I speak in details about the Firewall Raw, I will show you a LAB how to secure your router from TCP SYN attacks using the Firewall Raw.

So the idea for the mitigation is to detect that there is a TCP SYN attack coming to the router itself (chain input) or the via the MikroTik router going to an internal device in our LAN (chain forward). Once this has been detected, we can make a limit of how many TCP SYN packets we allow to have per second. Here it is up to you to decide how many TCP SYN packets you wish to accept per second depending on what TCP applications you are using. In my case, I will do something like 400 SYN TCP packets per second. Meaning that anything which is like 400 TCP packets per second (or less) coming from a source device then I will let them pass, and anything more then I need the MikroTik router to drop them.

So we understand the logic, let’s apply this to the MikroTik router filter rules.