Normally when an ssh login fails, it does so after the password attempt so no clue is given about which step failed. I would assume any type of RBL blocking would do the same, along with any available plugins that would ban based on a given username attempt?
One good thing though… I just realized fail2ban actually has a rule for blocking based on invalid user names, so I need to update my settings to make use of that filter. That will likely take care of the large number of attempts I’m seeing since I do see a number of IPs being used over and over.
Eh, those attempts are just noise anyway. Use proper pubkey auth instead of normal passwords and you’ll be fine. Any key size is probably enough to prevent successful bruteforce attacks. Anything above 2048 and there’s basically no chance for them to guess right within several years of constant trying. Most bots move along quickly as well, they try their predefined list of (common usernames) x (common passwords) and that’s it.
Install endlessh, an ssh tar pit, if you want to make their lives a little more annoying. Use a non-standard port if your OCD can’t stand the slowly filling auth attempt logs.
Yeah they’re not getting in with my current setup anyway, I just prefer to also boot the failed attempts so I’m not relying on a single layer of protection – you never know what future security leak might rear its ugly head. I did get one issue with fail2ban fixed though so it is once again properly dropping what it can, but this bot seems to be really persistent and has quite a long list of available IPs to work from.
If I’m bruteforcing a server and each time that I try an username/password my IP gets banned but suddenly one combination allows me to do 4-5 test ( any bigger number than previously) you are potentially telling me that this user is different (it exists) than the previous ones. Therefore you are doing the attack easier for me because now I know which users actually exist in the machine. It doesn’t matter if you are locking the attacker after the password was given.
As others told you, using public key auth, non standard ports or even port knocking will be much more useful.
Normally when an ssh login fails, it does so after the password attempt so no clue is given about which step failed. I would assume any type of RBL blocking would do the same, along with any available plugins that would ban based on a given username attempt?
One good thing though… I just realized fail2ban actually has a rule for blocking based on invalid user names, so I need to update my settings to make use of that filter. That will likely take care of the large number of attempts I’m seeing since I do see a number of IPs being used over and over.
Eh, those attempts are just noise anyway. Use proper pubkey auth instead of normal passwords and you’ll be fine. Any key size is probably enough to prevent successful bruteforce attacks. Anything above 2048 and there’s basically no chance for them to guess right within several years of constant trying. Most bots move along quickly as well, they try their predefined list of (common usernames) x (common passwords) and that’s it.
Install endlessh, an ssh tar pit, if you want to make their lives a little more annoying. Use a non-standard port if your OCD can’t stand the slowly filling auth attempt logs.
Yeah they’re not getting in with my current setup anyway, I just prefer to also boot the failed attempts so I’m not relying on a single layer of protection – you never know what future security leak might rear its ugly head. I did get one issue with fail2ban fixed though so it is once again properly dropping what it can, but this bot seems to be really persistent and has quite a long list of available IPs to work from.
If I’m bruteforcing a server and each time that I try an username/password my IP gets banned but suddenly one combination allows me to do 4-5 test ( any bigger number than previously) you are potentially telling me that this user is different (it exists) than the previous ones. Therefore you are doing the attack easier for me because now I know which users actually exist in the machine. It doesn’t matter if you are locking the attacker after the password was given.
As others told you, using public key auth, non standard ports or even port knocking will be much more useful.