We are still discussing different types of attacks that we may encounter on our MikroTik router, and another attack that I would like to discuss about it is called: Password Brute Force Attack.
The goal of this attack is to obtain credentials information such as a password from the device that the attacker is attacking (in our case the MikroTik router). As you know, to login to the MikroTik router we always require putting a username and a password whether on Winbox, Telnet, SSH, Console, etc….
If the attacker can guess the admin password that we have on our router, then he will gain full control of the router and exploit many techniques to profit from having access to that router.
Brute force attack is an automated software that generates a large number of consecutive guesses and combination of letters, numbers, symbols, characters in order to guess the password of the device that is trying to find its password.
For this reason, I highly advise you to always change the username of the router (other than “admin”) and make a very complex password to make it hard for the attacker to guess it.
Let’s do now a LAB to see how the Brute force attack happens and how to mitigate it.
LAB: Password Brute Force Attack and Prevention
Still on the same LAB scenario, R1 is connected to the internet and has SSH enabled so the administrator can login to the router via SSH remotely.
The hacker will profit from this by running a brute force attack on the SSH port 22, in order to be able to guess the password.
At this moment, the username and password on my router are:
Username: admin
Password: 123456
Let me show you, in case you are using a simple password, how easy it is for the attacker to guess your password.
I will go to Kali Linux and run Hydra graphical to run the brute force attack against R1:
I have said to Hydra that I want to run the attack on the router which has the IP 172.80.80.1 and on the protocol ssh.
Now I should mention how to guess the username and password:
For the username, I want that all tries to use the username “admin” because I believe that most of network engineers leave the username the same on the MikroTik router, and for the password I want to use the different combination of password that are available in the file list called “rockyou.txt.gz” (this file comes inside Kali Linux and contains thousands of passwords that hydra can use for the brute force attack).
Now that I am ready, let’s start the attack:
The attack has started, and now I see in front of me that hydra could, in less than 5 seconds, guess the router password which is “123456”:
Oh my God! Imagine with just simple steps we could guess the router password. When I look to the router log, I see that it took him 5 tries to guess the password:
Now you know how the attack happens, let’s see how we can protect our MikroTik router from such types of attacks.
Before we speak about the filter rules, you should do some settings on the router to make things harder for the attacker to guess your credentials. I will list some of them:
- Always use a very complex password and change the admin username to something else.
- Periodically change your password.
- Disable protocol that you never use them to log into the router (like Telnet, http, FTP, etc…..).
- Change the default ports of the protocols used to login to the router. For example, change the ssh port from port 22 to another port like 2222.
- Deploy port knocking (we will speak about it later in this book).
- Apply filter rules to limit the number of times a user can unsuccessfully attempt to log in and lock the users who exceed the specified number of failed login attempts.
Now let’s do the mitigation – I will start creating the filter rules to protect from Brute force attacks.
[mepr-show rules=”319″ unauth=”message”]
The 1st rule that I need to create is to say that in case the router sees an ssh connection coming inside on Ether1 to the router itself, then the packet of that connection will be sent to a custom chain that I will name it “Black List (SSH) Chain” and there it will be treated. Let me show you how to do that:
In this LAB, I will focus only on SSH. But you can do the same for Telnet and Winbox.
With this rule, once an SSH connection is coming to the router on Ether1, it will be sent to the custom chain called “Black List (SSH) Chain”.
In the 2nd rule, I have to create the custom chain and say that if it is an SSH connection (which surely it is), then put it in an address list “Black List (SSH) Stage 1” for 1 minute. Why for 1 minute? Because in the upcoming rule I have to say that if the same source IP has tried within 1 minute to re-do an SSH connection again, then an action will be taken (will see it in the new rule).
Very good, so now the IP will wait for 1 minute in the Stage 1 address list.
The next rule will be that in case an IP, which is in Stage 1 address list, has tried again to do SSH to the router, then put is in another address list called “Black List (SSH) Stage 2” also for 1 minute.
As a result, in case the same source has tried 2 times to try access ssh to the router within 1 minute, he will end up in the Stage 2 address list (please note that you can make it less or more than 1 minute timeout, it is up to you).
The next command will say that if the same source IP, that is in now in stage 2 address list, has tried to do again ssh to the router, then leave its IP for 30 days in a new address list called “Black List (SSH)”:
This way, the IP will end up in the “Black List (SSH)” address list.
The upcoming rule will be to issue a drop for all IPs which are inside the Black List (SSH)” address list.
This way, you drop the IP from the source which has passed through all this process.
Finally, do not forget to make the final rule to quit from the custom chain and return to the normal firewall rules:
Excellent! Now that I have all the rules set, let’s issue again the Brute force attack and see what the result will be. Before I do that, I will make the password on my MikroTik router very complex to guess so the Brute force attack will keep running for long.
You can see clearly that the packets have been increased on those rules after I have launched again the Brute Force attack, meaning that the SSH connections coming from Kali Linux were detected and the IP of Kali Linux machine should be blacklisted and blocked as being the source IP.
Let’s see the address lists:
You can see, Kali Linux IP tried many times to guess the password, it went to Stage 1, then Stage 2 and finally to “Black list (SSH)” address list which is dropped by the last rule of this custom chain.
I can also see that Hydra is not able to connect to the router via SSH because the IP of the Kali Linux is now dropped:
Wow! This technique is really working for us.
Last thing in this LAB is to share to you the command line of the filter rules for the Brute force attack prevention:
/ip firewall filter
add action=jump chain=input comment=”Block Brute Force Attack SSH” dst-port=22 in-interface=ether1 jump-target=”Black List (SSH) Chain” protocol=tcp
add action=add-src-to-address-list address-list=”Black List (SSH) Stage 1″ address-list-timeout=1m chain=”Black List (SSH) Chain” comment=\
“Add initial attempt to Black List (SSH) Stage 1” dst-port=22 in-interface=ether1 protocol=tcp
add action=add-src-to-address-list address-list=”Black List (SSH) Stage 2″ address-list-timeout=1m chain=”Black List (SSH) Chain” comment=\
“Add Successive attempts to Black List (SSH) Stage 2″ dst-port=22 in-interface=ether1 protocol=tcp src-address-list=”Black List (SSH) Stage 1”
add action=add-src-to-address-list address-list=”Black List (SSH)” address-list-timeout=4w2d chain=”Black List (SSH) Chain” comment=\
“Transfer repeated attempts from Black List (SSH) Stage 3 to Black List (SSH)” dst-port=22 in-interface=ether1 protocol=tcp src-address-list=\
“Black List (SSH) Stage 2”
add action=drop chain=input comment=”Drop anyone in Black List (SSH)” in-interface=ether1 src-address-list=”Black List (SSH)”
add action=return chain=”Black List (SSH) Chain” comment=”Return from Black List (SSH) chain”
This is all about the Brute force attack and the way to be protected from it. Let’s continue the discussion and speak about Port Scan attack in the upcoming topic.
[/mepr-show]
0 Comments