1

This question already has an answer here:

Our system used to get bombarded by bots trying to login to the ssh client on the standard port. After switching to another port number the failed login attempts basically stopped completely. Recently, in the past week there has been a few unknown i.p. addresses attempting to login ( on average about 60 attempts a day) that appear to be on a few different networks coming from the same isp in china.

I have no security experience, other than basic setup of clients and changing passwords etc.

We are using logwatch to gather some information on the login attempts. What is the key information I will need about the attempts to analyze the situation and take action?

What are basic steps to make sure we have not already been breached?

What other actions I should take?

marked as duplicate by TildalWave, Xander, Lucas Kauffman, schroeder, AJ Henderson Sep 2 '14 at 15:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

6
  1. Don't allow SSH login into the root account. Login with a user account with a name which is harder to guess. When you need to do something as root, use su or sudo after you logged in.
  2. Make sure your passwords are long enough to avoid getting brute-forced. The speed an attacker can use to brute-force over the network is severely limited, so an 8-character mixed-case password without any relation to a dictionary word is more than enough.
  3. Even better, use keyfiles for SSH login. That way SSH logins are only possible with the correct keyfile on the client system. Brute-forcing an RSA key (when generated correctly) is very unlikely to be successful before the end of the universe, so nobody will even try.
  4. Install fail2ban. This tool automatically adds firewall rules which block IP addresses which make an unusually large number of failed login attempts. When you followed the previous steps this shouldn't actually be necessary from a security standpoint and it might result in overblocking legitimate users which share an IP with an attacker (carrier-grade NAT, dynamic IP addresses), but it reduces the resource load on the server due to not having to respond to all the login attempts.
2

Another suggestion, thats is actually better than fail2ban, is to firewall off ALL ips EXCEPT for a few permitted ones.

Thus lets say you have a SSH server at home that you access from your vacation home (3G mobile broadband) and your work.

Your work propably have a static IP. Simple to tell the firewall to allow through packets for this IP.

3G mobile broadband Changes each Connection, but you can easly look in WHOIS which is the ISPs assigned series. For example: "123.123.0.0 to 123.123.255.255". Then you tell your firewall to let through 123.123.0.0/16 to port 22 on your server.

Even in this case you have allowed every customer on that 3G mobile operator to authenticate against your SSH server, but STILL its a HUGE security improvement, since instead of allowing the whole World to authenticate against your SSH server, you have instead limited this to only customers having a specific ISP account in one country.

Country locks are also a very good idea if you have multiple users on your SSH server but you know that all users are in a specific country. For example if you sold webhosting to them, but using a payment method that can only be used by Citizens in a specific country. Then its safer to simply lock all countries except for the countries you accept customers from.

Another step you can take is to limit the rate of login using iptables such as this :

iptables -A INPUT-p tcp --dport 22 -m conntrack --ctstate NEW -m limit --limit 3/minute --limit-burst 3 -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

using two firewall rules above limit any login attempts to 3 times a minute. modify accordingly to your needs.

  • Only do this if you're absolutely certain you'll always be connecting from the same IP address or range. It's very easy to lock yourself out of a server this way. – Marcus Downing Feb 4 '15 at 16:28
  • Yes if the server is not physically available. If you fail up and the server is physically accessible, its easy to correct the problem by physically visiting the server console and just resetting the firewall rules. – sebastian nielsen Feb 4 '15 at 17:58

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