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.
[mepr-show rules=”319″ unauth=”message”]
To make it easy, I will apply the script directly to the router terminal so the rules will be created:
/ip firewall filter
add action=jump chain=forward comment=”SYN Flood protect ” connection-state=\
new in-interface=ether1 jump-target=syn-attack protocol=tcp tcp-flags=syn
add action=jump chain=input connection-state=new in-interface=ether1 \
jump-target=syn-attack protocol=tcp tcp-flags=syn
add action=accept chain=syn-attack connection-state=new limit=400,5:packet \
protocol=tcp tcp-flags=syn
add action=drop chain=syn-attack connection-state=new protocol=tcp tcp-flags=\
syn
Now that I have them copied to the router Terminal, the rules will show up on Winbox. Let’s understand each line by line:
The 1st line (rule 0) says, if a TCP Syn is being detected passing via the router and going to an internal device, then send it to a new chain which I called it “syn-attack” chain and there some treatment will happen to that traffic.
Let’s check it more in details:
Here I am saying that any TCP traffic coming to Ether1 and passing via router.
Over here, I have put the TCP Flags to be “syn”, so meaning now that any TCP traffic which is syn passing via the router on Ether1, then let’s see with the upcoming picture what would be the action:
The action is to jump to a custom chain that I have created and give it a name “syn-attack”. When you make a custom chain, that means that the packet will go to that custom chain to be checked, meaning that in that custom chain I will have to define what is allowed and what is disallowed.
This is rule 0.
Rule 1 (2nd line in the filter rule) is exactly the same, but instead of using “forward” chain, I am going to use “input” chain. This means that the router will check if there are any TCP syn packets coming to the router itself on Ether1 interface, and if so then it will send it to the custom chain “syn-attack”.
Let’s check now rule 2 (3rd line in the filter rules).
On the 2nd rule we have created the custom chain “syn-attack” and on the general tab it says: If the packet is a TCP with a new connection state, meaning just a new connection. The rule be continued:
I have added on the Advanced tab to have the TCP flag as syn. So, the result we have up to now is:
Any new connection which is TCP and has a flag as syn – now let’s see the upcoming picture for this rule:
On the Extra tab I have mentioned that the limit is 400 packets per second, which is can up to 405 as maximum (this what is means by burst 5).
In a result, the rule is saying up to now the following:
Any new connection which is TCP and has a flag as syn and has 400 packet per second (max 405), now let’s see the action what would be:
The action is to accept.
So finally, I can understand that this custom chain “syn-attack” is saying that:
Any new connection which is TCP and has a flag as syn and has 400 packet per second (max 405) or less, then accept it.
Wow, we had to go through many explanations here. But if we keep it like this, then the firewall rule will allow any TCP syn even if they are more than 405 packets per second, because the firewall works on sequence, meaning if the router sees for example 450 packets per second, then it will not match the last rule that we have created (maximum 405 packets) and it will go to the rule which comes after it, and in our case we do not have any rule set yet which is after it, then it will be accepted because the MikroTik Firewall does not have (like Cisco) an implicit deny rule at the end. Meaning, we should have a rule to drop anything else, and that’s what I have done on rule number 4. Let me show you that:
As you see, I am matching new connection having protocol TCP and flag as syn without mentioning how many packets per second and I am saying the action is to drop. Meaning that if the rule behind was not matched and the TCP syn packets were more than 405 packets, then this rule will drop them.
Having now the filter rules ready, let’s run the TCP syn flood attack and see the result now:
I just run again the attack. Let’s see if the rules are dropping the TCP syn:
Look how many packets have been dropped directly.
You may see that even with those rules, the CPU jumped to 100% when the attack has happened and you may say what is the point of those rules if the CPU goes to 100% again. Well, in some way you are right, because our router is not functional anymore when it hits 100%. The filter rules are too heavy on the MikroTik router’s CPU. So what I would advise is to have a big MikroTik router with many core CPU acting only as your firewall, preferably even a CHR image or RouterOS image running on a server blade, then this way it would be able to carry all those traffic and block them without having a major impact on your router resources.
To end with this LAB, in case you are going to have filter rules after the ones that we have created for the SYN flood, then I advise to make final rule which is to quit the custom chain that we have created which is “syn-attack”. Let me show you how you can do that:
By doing return on the custom chain, then it will quit the custom chain “syn-attack”.
The last step for this LAB is to enable “TCP SynCookies”. Syncookies is a technique used to resist SYN flood attacks. I refer you to the article written on MikroTik website to have more information about “TCP SynCookies” here:
https://en.wikipedia.org/wiki/SYN_cookies
On MikroTik, it is just 1 click to check it, and this (may) help with TCP SYN attack.
Let me show you how to enable it:
This is all what I wanted to show you about the TCP SYN attack and prevention.
[/mepr-show]
0 Comments