2

Is it still considered a 'port scan' to have scripts trying to SSH in with a list of common account names or trying multiple passwords for 'root' or 'mail' (or similar)? I'm hoping to find a way to block these but I'm at a loss as to what to search for.

When I imagine the term port scan I think of using NMAP (or equivalent) to find what's open in iptables. Just curious if this falls under the same category.

Some of my systems are logging several thousand per day. It's annoying.

Systems are all CentOS / RHEL.

EDIT: iptables 'limiting' looks v promising. In the end I may have to setup a VPN for all the valid traffic and use something like 'fail2ban' on my public servers.

ethrbunny
  • 2,327
  • 4
  • 36
  • 72

4 Answers4

10

The search term you need here is probably something like "block failed ssh login attempts" or "block brute force ssh" or even "stop malicious ssh logins".

A very popular tool to stop these is fail2ban. It can watch your logs for failed SSH login attempts and block the offending IP after a number of failures for a certain amount of time.


Some other tips to beef up your SSH security:

  1. Disable direct root login if you haven't already. This is one of the essentials which you should really do if you want to consider your server at all secure.
  2. Disable password authentication and use public key authentication instead. Another essential. It doesn't matter how much guesses they do for a valid password if passwords get you nowhere. Besides, using a key pair for logging in is very convenient if you use a key manager on the client side.
  3. Use a non-standard port. You could use something like 2222 or preferably something even less obvious. This causes the number of failed logins to drop dramatically in my experience. Although as other people pointed out in the comments you should keep in mind that open ports are still easily revealed with a port scan and it can be inconvenient for legitimate users to log in.
  4. Block failed attempts using fail2ban. I would advise you to have some sort of plan B in case you accidentally block yourself. If you are able to try again from a different IP you can unblock yourself.
  5. Implement port knocking. This is probably overkill but if implemented it can bring your failed login attempts down to essentially zero. This can be VERY inconvenient for legitimate users wanting to log in. You have to go through the song and dance of performing the secret knock every time you want to log in. Forget about logging in with your smartphone.
Kenny Rasschaert
  • 8,925
  • 3
  • 41
  • 58
  • 1
    Using a non-standard port is more hassle for legitimate users than for miscreant's botnet. Port knoking even worse. Use decent passwords, no password for ssh connections. That adds security overall (where it is needed, the idiots doing SSH brute force are just a nuisance). – vonbrand Mar 22 '13 at 14:12
  • 2
    Not to mention that your non-standard port can be found with... a port scan. Which takes about three seconds. – Michael Hampton Mar 22 '13 at 16:04
  • 1
    Changing the default SSH port will make the connect attempts looking automatically suspicious. Legitimate users should know the correct port. Attacker will not know it and will have to guess, reveiling himself. – Danubian Sailor Mar 22 '13 at 16:08
  • 1
    I would consider the first 2 steps not to be "beefing up" the security of ssh. They are minimum requirements as far as I am concerned. – dunxd Mar 26 '13 at 12:04
  • 1
    @MichaelHampton, sure, a good port scan will find the non-standard port, but in my experience, this eliminates near 100% of the drive-by/non-targeted bot attacks. – 89c3b1b8-b1ae-11e6-b842-48d705 Mar 26 '13 at 12:04
  • @dunxd I agree wholeheartedly, I'll update the answer. – Kenny Rasschaert Mar 26 '13 at 12:05
  • @lechlukasz Actually, legitimate users _don't_ always know the correct port. For instance, Windows Azure maps ssh to a _completely random_ port every time you create a virtual machine, and you have to (1) remember that it does this, and (2) go look up what it did if you want to get into the VM you just started. – Michael Hampton Mar 26 '13 at 12:19
2

It'd fall under the category of a brute force attack.

It's possible to prevent these with iptables using the --seconds and --hitcount flags to effectively rate limit the amount of attempts per second. The only downside to this is the attacker could adjust the rate of the attack to not trigger the rules but usually the attacks aren't really monitored that well.

You should also disable root login and be using SSH keys, if you haven't / aren't already. That basically makes the attacks pointless.

Jake Stubbs
  • 176
  • 3
  • The biggest real problems they cause is log file growth and using up bandwidth. Both are nicely handled by throttling their tries. – vonbrand Mar 22 '13 at 14:15
1

Your likely candidate for a search term is "ssh brute force attempts."

While changing your SSH port will not enhance the security of your network, it will alert you to a malicious user targeting your machine with a little more focus than the lazy "try root:root on port 22" scripts. I personally use this approach on my servers to keep my logs relatively quiet.

0

No, trying to connect to an account, moreover actively trying random passwords, is way beyond just checking if there is somebody listening at a particular port. Even connecting to get a banner of e.g. the web server might be considered more than a "port scan".

vonbrand
  • 1,153
  • 2
  • 8
  • 16