Hi,
I am trying to reduce ssh brute force attacks. I have implemented well known set of ipchain rules putting the attacker IP on blacklist, however it seems that mikrotik OS does not allow to set the number of login attempts for one single tcp session, resulting in many attempts until the IP is blocked. I would like to reduce it to 3 attempts per established tcp session.
Any idea?
thanks.
You use these rules who are on the link below
This solution is not working, because it is just limiting number of connection attempts from an IP. The problem is that attacker creates just single connection and using this he is using brute-force. I am using the mentioned solution, but still I see this - see screnshot.
Is it possible to limit number of login attempts per connection?
Don’t believe so… why not actually secure your router and use VPN etc to connect. It is generally a bad idea to leave services open like that. Or use port knocking, etc.
Yes, it is possible to solve it this way, but the question is: Is it possible to limit login attempts in one session? I thought RouterOS closes connection after a bad login, but it is obviously not.
Hence the first part of my answer. I don’t actually think you can control any of those aspects of the SSH server on routeros.
Well, what do the others think? Should Mikrotik change this behaviour? (disconnect after bad password) Or is it perfectly normal? I can write to Mikrotik support and ask them, but I’d like to know some opinions first 
Just restrict the service… That’s what most people do. It’s not advisable to have services like that publicly exposed.
Sent from my SCH-I545 using Tapatalk
My suggestions are:
Change SSH port to one random like from 10.000 to 20.000 like 19273
Add on “available from” field the networks you aspect to connect from,
or make a script like if you knock on port 18453, 17263 and 13897 within 10 sec, scripts add that ip on “available from” filed and/or modify firewall filter for “accept”
zervan, I don’t believe you are correct. The Bruteforce page explains how the IP will be added to blacklist for several wrong attempts. He can’t “bruteforce from single connection”, if password is incorrect, the users is disconnected. Make sure you have correctly implemented the rules from the wiki
Well, maybe I have some mistake and maybe somebody will find it, here is it:
/ip firewall filter
add chain=input connection-state=established
add chain=input connection-state=related
add action=drop chain=input connection-state=invalid
add action=tarpit chain=input protocol=tcp src-address-list=blocked-addr
add action=drop chain=input src-address-list=blocked-addr
add action=jump chain=input comment=“SSH” dst-port=2222 jump-target=input-ssh protocol=tcp
add action=log chain=input-ssh log-prefix=“SSH brute-force” src-address-list=ssh-faza3
add action=add-src-to-address-list address-list=blocked-addr address-list-timeout=15m chain=input-ssh src-address-list=ssh-faza3
add action=add-src-to-address-list address-list=ssh-faza3 address-list-timeout=1m chain=input-ssh src-address-list=ssh-faza2
add action=add-src-to-address-list address-list=ssh-faza2 address-list-timeout=1m chain=input-ssh src-address-list=ssh-faza1
add action=add-src-to-address-list address-list=ssh-faza1 address-list-timeout=1m chain=input-ssh
add action=return chain=input-ssh- it is just a piece of more complex tests (not only SSH, but also scanning, number of connections, etc)
Oh, sorry, I was wrong. I have two systems with this solution and I showed log from the first and firewall rules from the other. The problem is that I have misclicked on the first one - used add-dsc-to-address-list instead of add-src-to-address-list 
I’m sorry. I will check it again (normally I have SSH disabled on firewall, I am going to enable it and see…)
good to hear you found the issue. let us know if it works now
Despite my mistake it seems that this protection is not working as expected. Simple test: start Putty, try to connect to SSH using wrong password. RouterOS allows to guess password 6 times in one connection! So there are 6 log records about it and protection rules will mark it only as first attempt. This is why I wrote it is not working - if there are 3 phases, it allows 18 login attempts.
I know this one has been stale a while; but I thought I’d add my 2 cents.
I was also looking for a solution to this and I found out the max login attempts as well as this article.
I do have a solution that I thought up that could reduce the amount of connects; so the attacker doesn’t get 18 tries.
Alter the script and reduce the number of stages. 6 login attempts is more than enough, period (or at least I think so). I’d remove stage 2 and 3. Stage 1 is 60 seconds. I say that during this time any further connection attempts should be dropped and added to the blacklist. If you genuinely forget your password after 6 tries, well 60 seconds might have gone by, or make sure to wait. Doing this should only allow an attacker 6 tries and then he gets banned.
This is an alternate solution.
add chain=input protocol=tcp dst-port=22 src-address-list=ssh_blacklist action=drop
comment=“drop ssh brute forcers” disabled=no
add chain=input protocol=tcp dst-port=22 connection-state=new
src-address-list=ssh_stage1 action=add-src-to-address-list address-list=ssh_blacklist
address-list-timeout=10d comment=“Added to blacklist because you tried to connect again after your first connection” disabled=no
add chain=input protocol=tcp dst-port=22 src-address-list=ssh_stage1 action=drop
comment=“Drop if you try again during the first 60 seconds” disabled=no
add chain=input protocol=tcp dst-port=22 connection-state=new action=add-src-to-address-list
address-list=ssh_stage1 address-list-timeout=1m comment=“First 60 second chance” disabled=no
If you can do not drop, tarpit or reply with network unreachable…