92
ShellBot Uses Hex IPs to Evade Detection in Attacks on Linux SSH Servers
(thehackernews.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 12 Oct 2023
92 points (97.9% liked)
Linux
48074 readers
783 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I think is better to not use an standard port and using fail2ban at the same time to avoid automated attacks. If you manage to implent what you are looking for, you are potentially telling an stacker which accounts exist and which not, allowing him to do an easier brute force attack. A typical attacker using a botnet will not be stopped by a single IP being baned, and as son as an IP is banned he will know that this account doesn't exists. Another option is enabling port knocking.
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.