Protect SSH from brute force on any port

Today I was interested in the poll whether SSH should be outweighed on a non-standard port . The survey itself is not so interesting as the author’s way of zivot_je_cudo to protect SSH from password guessing : after an incorrect connection attempt, block new attempts for 20 seconds. The delay, apparently, was chosen empirically, on the basis of their two opposite wishes: in order not to block themselves in the event of a typo for a long time, and at the same time complicate the life of the picker. I want to share my way of counteracting brute force, which I have been using for several years. It has two advantages:
- it gives me more attempts to set the correct password
- but at the same time it blocks the brute forcers “forever”.

How can these two opposing goals be achieved?


I use the iptables module called hashlimit, which can count the number of packets in a certain period of time and reset the counter after a while.
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 third rule understandable. All the most interesting in the first: it allows 2 connection attempts within an hour. As soon as you exceed 2 attempts in the specified time, the rule with -j ACCEPT stops working, the user instead gets into the next rule with -j DROP (you can also set TARPIT in the same way). After that, you will not be able to connect, and the countdown of 60,000 milliseconds begins, after which the information about your attempt "goes bad" (parameter --hashlimit-htable-expire). That is, you really have to wait until 1 hour, but only 1 minute. The whole military trick is that if you do not wait for this time and try to connect again, the packet will be killed and the counter will be reset to its initial state - 1 minute! Thus, if you are an impatient brute force and stupidly hammer the port after blocking, then with each attempt you will renew your ban! That is, ban yourself forever!
A respectable user, however, dials several attempts to connect without waiting between them before entering the “bathhouse”.
The hashlimit module saves its state in / proc - at first it is empty:
# cat / proc / net / ipt_hashlimit / SSH

after the first attempt to connect, the info gets there:
# cat / proc / net / ipt_hashlimit / SSH
55 ХХ.ХХ.ХХ.ХХ: 0-> 0.0.0.0:07 11533000 230400000 115000000 the

first number is the number of remaining seconds, you can watch it ticking evenly:
# cat / proc / net / ipt_hashlimit / SSH
20 ХХ.ХХ.ХХ.ХХ: 0-> 0.0 .0.0: 0 117429000 230400000 115000000

After I did this, I really wanted to check. And it is necessary! The beast runs to the catcher! Some Chinese started to brute-force me right away. The first 4 attempts passed, and then for an hour (!) He stupidly hollowed at the closed door. For all this hour, he managed to verify only 4 passwords! Further, apparently tired.

Two problems were thus resolved:
- if the user suddenly sealed up, he did not need to wait long for new attempts
- the brute forcers drive themselves into an “eternal” ban.

What to do if you suddenly couldn’t enter the password with several attempts? Do not fuss - wait calmly a minute and try a few more times.
And if they couldn’t succeed again, then it’s better to go to sleep, in this state it’s better not to climb into the console :))

Good luck.

PS And yes, I almost forgot - I have SSH on a non-standard port :)

UPD: A little about configuring hashlimit .
UPD2: How to achieve the same with the more common recent module: one , two .
UPD3: By itself, the method is suitable not only for protection against password guessing via SSH, but can also be used for various other services where too frequent connection signals something wrong.
UPD4: Limiting connections using SSHD itself .