Today I was interested in the survey whether it is necessary to move SSH to a nonstandard port. The survey is not as interesting as the way the author @zivot_je_cudo to protect SSH from brute-force password: after wrong connection attempts to block new attempts within 20 seconds. The delay apparently chosen empirically on the basis of two opposite requests: to not lock yourself in case of misspelling a long time, and at the same time, make life difficult for the picker. I want to share my way to resist brute-force, which is used for several years. It has two advantages:
- it gives me more attempts to set the correct password
- but at the same time blocks the brute force “forever”.
How can I achieve these two opposite goals?
I use module iptables called hashlimit, which is able to count the number of packets in a certain period of time and after a while to reset the counter.
Everything is done by three rules:
iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m hashlimit –hashlimit 1/hour –hashlimit-burst 2 –hashlimit-mode srcip –hashlimit-name SSH –hashlimit-htable-expire 60000 -j ACCEPT
iptables -A INPUT -p tcp -m tcp –dport 22 –tcp-flags SYN,RST,ACK SYN -j DROP
iptables -A RH-Firewall-1-INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT
What makes the second and the third rule is clear. The most interesting in the first: it allows two connection attempts for an hour. Once you exceed 2 attempts for a specified time, rule with -j ACCEPT stops working, the user instead of this goes into the following rule with -j DROP (exactly the same way you can put TARPIT).
After that, you will not be able to connect, and starts the countdown 60,000 milliseconds, after which information about your attempt to “become rotten” (parameter –hashlimit-htable-expire). That is you really are not come to wait 1 hour, and just only 1 minute. The whole ruse is that if you cannot wait this time and try again to connect, the packet will be killed, and the counter is again reset back to is initial state – 1 minute! Thus, if you are impatient and stupid bruteforcer and will hammer away the port after blocking, you’ll prolong your ban with each attempt! That is, you will ban yourself forever!
Good user on the contrary has multiple connection attempts without waiting between them, before he get into the “bath”.
hashlimit module saves its state in the / proc – initially it’s empty:
# cat /proc/net/ipt_hashlimit/SSH
after the first connection attempt information gets there:
# cat /proc/net/ipt_hashlimit/SSH
55 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 11533000 230400000 115000000
the first number is the number of seconds remaining, you can see how it evenly ticking:
# cat /proc/net/ipt_hashlimit/SSH
20 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 117429000 230400000 115000000
After I did it, I really wanted to check it out. And wow! The ball comes to the player! I immediately began to brute-force by some Chinese. The first four attempts passed, and further he stupidly knocked the closed door within the hour (!). During this entire hour he managed to check only four passwords! Then, apparently, he tired.
Thus solved two problems:
— if the user suddenly sealed, he didn’t have to wait long for new attempts
— bruteforcer themselves driven into an “eternal” ban.
What if you suddenly with a few attempts were not able to enter your password? Do not fuss – wait a minute, and calmly try a few more times.
And if you again failed – it is better to go to sleep, in this state it is better not to go into the console :))
Good luck.
P.S. And yes, I almost forgot — I have SSH on non-standard port 🙂
UPD: A little about setting hashlimit.
UPD2: How to achieve the same with a more recent common module: one, two.
UPD3: Of course the method is suitable not only for protection from password guessing on SSH, but can be used for various other services, where too often the connection indicates something is wrong.
UPD4: The connections limit using the SSHD.
This text is a translation of the article “Защищаем SSH от брутфорса на любом порту” published by Евгений Лисицкий on habrahabr.ru.
About the CleanTalk service
CleanTalk is a cloud service to protect websites from spam bots. CleanTalk uses protection methods that are invisible to the visitors of the website. This allows you to abandon the methods of protection that require the user to prove that he is a human (captcha, question-answer etc.).
Leave a Reply