We protect SSH from brute force on any port

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

How can these two opposite goals be achieved?


I use the iptables module called hashlimit, which is able to 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 rules clear. 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 enters the next rule with -j DROP (you can also put TARPIT in the same way). After that, you will not be able to connect, and a countdown of 60,000 milliseconds begins, after which the information about your attempt to “faint” (parameter --hashlimit-htable-expire). That is, you really should not wait for 1 hour, but only 1 minute. The whole military trick is that if you do not wait for this time and try to reconnect, the packet will be killed, and the counter will be reset to its initial state - 1 minute! Thus, if you are an impatient brute forcer and stupidly gouging the port after blocking, then with each attempt you will extend your ban! That is, ban yourself forever!
A respectable user has several attempts to connect without waiting between them before falling into the “bath”.
The hashlimit module saves its state in / proc - initially it is empty there:
# cat / proc / net / ipt_hashlimit / ssh
')
after the first connection attempt there gets infa:
# cat / proc / net / ipt_hashlimit / ssh
55XX.XX.XX.XX: 0-> 0.0.0.0 call 11533000 230400000 115000000

The first number - the number of remaining seconds, you can watch how it evenly ticks:
# cat / proc / net / ipt_hashlimit / ssh
20XX.XX.XX.XX: 0-> 0.0.0.0; Voice 117429000 230400000 115000000

After I did this, I really wanted to check. And wow! On the catcher the beast is running! I immediately began to brute force some Chinese. The first 4 attempts passed, and then within an hour (!) He stupidly dug into the closed door. For all this hour he managed to check only 4 passwords! Further, apparently tired.

Thus two problems are solved:
- if the user is suddenly sealed up, he does not need to wait long for new attempts
- bruteforcers drive themselves into the “eternal” ban.

What to do if you suddenly with several attempts could not enter a password? Do not fuss - wait quietly for a minute and try a few more times.
And if they failed again - it is better to go to sleep, in this state it is better not to climb into the console :))

Successes.

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

UPD: A little about setting hashlimit .
UPD2: How to achieve the same with the more common recent module: one , two .
UPD3: It goes without saying that the method is suitable not only to protect against password selection via SSH, but it can also be used for various other services, where connecting too often signals something amiss.
UPD4: Limit connections using SSHD itself .