1

I've updated my sshd_config to be more strict against bots. namely:

  • only keys are allowed, except for a few specified users on specific ips
  • MaxAuthTries = 1
  • no root login

This has been both good and bad. While it locks down the box more, after testing I've noticed that even with VERBOSE logging, clients that are not permitted will not see their attempts logged to /var/log/auth.log .

for example

ssh baduser@example.com

would not appear in the logfiles because the client did not try to auth.

I'd like to ensure these events are logged, as the hosts can be considered "evil".

0

I'm not a huge fan of fail2ban, as it's only effective against attackers who don't have hundreds / thousands of IP addresses to use in a distributed brute-force attack. So it only catches the attackers who do all of their brute-forcing from a single IP address.

Are the hosts caught by it evil? Well, they're at least infected by bot code so that they can be used in attacks.

Over the past decade, I've found it more profitable to focus on the things that you've already done, and move my energy to preventing other avenues of attack. I find it better to take a whitelist approach to security, rather then a retroactive / reactionary blacklist approach.

Required for securing SSH:

  • Disallowing "root" account login
  • Using public-key authentication for accounts
  • Limiting password-based accounts to specific IP ranges (I still consider this very risky)

Extremely helpful:

  • Limiting access to the server and/or port to specific parts of the world using a firewall box.
  • Moving the SSH port off of the default, which will greatly reduce the amount of log file cruft that you have to sift through (automated or by hand).

I realize this is not the technical answer that you're looking for.

  • Thanks. The password-based accounts are only allowed for a few specific IPs, not ranges. It's an emergency access so a few select team members can get into a machine without their private-key. I've had issues before where this was needed (someone is traveling, on-call person admin can't handle an issue, etc). – Jonathan Vanasco Apr 30 '16 at 1:50
  • I look at the bot hosts differently than you. In my experience, smaller botnets tend to synchronize from consolidated ip ranges and the attempts via ssh might happen as they try other vectors to upload a password, and are checking to see if it worked. I'd like to log each of these ssh attempts and ban the IP, because there is a decent chance that same machine is trying to compromise another service. – Jonathan Vanasco Apr 30 '16 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.