23

By coincidence I looked at my servers ssh log (/var/log/auth.log) and I noticed that someone is constantly trying to gain access: 

Sep  7 13:03:45 virt01 sshd[14674]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.31.116.42  user=root
Sep  7 13:03:48 virt01 sshd[14674]: Failed password for root from 116.31.116.42 port 13423 ssh2
Sep  7 13:03:52 virt01 sshd[14674]: message repeated 2 times: [ Failed password for root from 116.31.116.42 port 13423 ssh2]
Sep  7 13:03:52 virt01 sshd[14674]: Received disconnect from 116.31.116.42: 11:  [preauth]

This happens a few times every minute, and has been going on for a long time without me knowing about it.

Question Should I be concerned about this, if yes: What should I do about it?

Vingtoft
  • 1,467
  • 3
  • 15
  • 16
  • 4
    Yeah, you should be worried. Close the port if you don't need it open. If you need it open, you can use iptables to block IP blocks for geographic locations you'll never log in from. Specfically block the source of these attacks. Also consider changing the listening port of your SSH service. – Jeremy Dover Sep 07 '16 at 11:19
  • 2
    related : http://security.stackexchange.com/questions/110706/am-i-experiencing-a-brute-force-attack – Walfrat Sep 07 '16 at 11:32
  • 4
    Why are you even allowing password authentication? Use keys and disable password auth completely. – André Borie Sep 07 '16 at 12:12
  • 16
    Just one person? That's pretty lucky. – HopelessN00b Sep 07 '16 at 12:56
  • 3
    Possible duplicate of [Securing SSH server against bruteforcing](http://serverfault.com/questions/174951/securing-ssh-server-against-bruteforcing) and http://serverfault.com/questions/4188/preventing-brute-force-attacks-against-ssh and http://askubuntu.com/questions/32246/how-to-secure-ubuntu-server-from-bruteforce-ssh-attacks and http://superuser.com/questions/491636/how-to-prevent-brute-force-attack-on-ssh and http://serverfault.com/questions/594746/how-to-stop-prevent-ssh-bruteforce – TessellatingHeckler Sep 07 '16 at 17:48
  • With 3 seconds gaps? How sweet. People from China and India try to get into my raspi (which is connected to a private internet connection with dynamic IP address) all the time, so I'd expect quite a bit more for a server. So far, none of them even guessed a username other than `root` correctly and `root` can't even log in. – UTF-8 Sep 07 '16 at 17:51
  • 2
    Disable password auth, use key-based auth. To stop script-kiddies run sshd on a different port (not more secure but it "hides" from the bulk of random attacks) – Ex Umbris Sep 07 '16 at 18:22
  • 1
    I have at least fifteen different servers running on a multitude of ports - this type of traffic is not uncommon and I see service scanners hitting my net all the time. Granted, I run a pfSense with Snort configured on the edge of the network so the brute forgets are caught before the traffic descends into my network, but trust me this is infinitely common, on at least fifty different ports on my network. Disable password auth, enable key-only auth, and you will help prevent those brute force attempts. (You can change the port if you wish but that's not usually necessary.) – Thomas Ward Sep 08 '16 at 02:03

4 Answers4

64

Unfortuntately, this is absolutely normal and something every SSH server experiences. Welcome to the internet.

As long as you properly secure your server (e.g. keep it updated, allow only key-based login, disable root SSH access), this shouldn't be a problem, but you can limit this even further with something like fail2ban and other approaches like IP whitelisting, changing ports and stuff like that where possible and appropriate.

Sven
  • 97,248
  • 13
  • 177
  • 225
  • 5
    Yes, it's business-as-usual. The best thing I've found to limit this spam in my logs is changing the SSH port. Other measures are probably helpful for security, like ensuring that root SSH logins are disabled, minimizing the number of people who can log into the server, and ensuring they choose good passwords. If it's just you, and you choose good passwords, then you're fine: they typically just try common username/password combos. Ideally, though, disable password auth and just use ssh keys. Then the spam will stop completely. – Dewi Morgan Sep 07 '16 at 14:34
  • 2
    I was truly surprised how much brute-forcing I got on my Raspberry Pi after I set it up with a DDNS and forwarded a port to it... It's like every single person on a busy street trying to see if their key works on your car. – Captain Man Sep 07 '16 at 19:14
  • 1
    fail2ban is an essential tool for any server you have with a public or natted IP address. My network has also been targeted recently by this address, and after a couple days, I began to see other traffic, so I used iptables to block the entire /24. You can do the same with iptables -A INPUT -s 116.31.116.0/24 -j REJECT – Rache Sep 07 '16 at 20:39
  • 1
    log-based banning packages have the downside that any service that can log to syslog or use /dev/log can block anyone from using SSH. Using something like Suricata or Snort might be overkill for just 1 server, but if you have a network to protect, an IDS/IPS system isn't exactly just a luxury. – John Keates Sep 07 '16 at 21:55
22
  1. Block the IP using your firewall (iptables or whatever your service provides). Yes, they might change IPs, but make them do the work
  2. If you have an external firewall (i.e. AWS console lets you set access rules via a web page) consider limiting port 22 to JUST your IP. No need to fiddle with fail2ban in this case
  3. As mentioned in the comments, switch to key-based authentication and turn off password authentication

  4. Disable root logins. Add this to /etc/ssh/sshd_config

    PermitRootLogin no

    Just let them hammer away at root all they want. They'll never get in that way then.

Community
  • 1
Machavity
  • 834
  • 10
  • 26
  • 1
    "make them do the work". But you're doing just as much work as them in this scenario and possibly more. This is a losing scenario. –  Sep 07 '16 at 16:31
  • @DoritoStyle So... don't block someone who's hammering your server with requests? That makes no sense. I've had several low-key attacks executed from a single IP. Won't save you from DDOS but that's outside the scope here – Machavity Sep 07 '16 at 16:55
  • 1
    If you get more than a dozen attacks from unique IPs throughout the day you'll quickly end up spending a major chunk of each day blocking IPs. Something like fail2ban does this automatically and and is much better (That would be an excellent edit to your answer). Also, if it's only a few SSH requests then it shouldn't affect performance unless it escalates to DDOS levels. In any case, i'm happy to start a chatroom for further discussion. –  Sep 07 '16 at 19:06
10

In addition to securing server as Sven points out, one of the best things to do (especially if ssh is therej ust for you, the admin) is just change sshd port away from default 22.

Not only is it simple (especially when you put new port in your ~/.ssh/config so you don't have to type it everytime) and it will stop 99% of those automated scans so you won't even see them, but it will also help somewhat even if some 0-day ssh vulnerability is discovered to give you more time, or you key is leaked etc.

Matija Nalis
  • 2,409
  • 23
  • 37
  • 3
    Security through obscurity isn't. All you accomplish is forcing people who have a legitimate need to connect to your server via SSH/SFTP to use a non-standard port, which may require them to ask their InfoSec team to approve a firewall rule allowing that connection. Stop making my job more difficult to create the false illusion of improved security. – Monty Harder Sep 07 '16 at 15:23
  • 10
    @MontyHarder Wikipedia defines *security through obscurity* as *"the reliance on the secrecy of the design or implementation as the main method of providing security."*. In contrast this method actually uses the port as a small **additional** secret. Obviously this has costs (inconvenience) versus little benefit assuming a secure ssh server. However, I do follow the argument of a critical 0-day ssh vulnerability. There are many much less effective, more annoying snake-oil solutions widely accepted... – Zulan Sep 07 '16 at 15:37
  • 1
    Change the ports and you'll get extra port scans instead of SSH login attempts. – Dmitry Grigoryev Sep 07 '16 at 15:56
  • 2
    @MontyHarder It's not even about "security through obscurity". If I run my server on a non-standard port I simply reduce the script-kiddie noise which makes it easier to see *real* targeted attacks. – Martin Tournoij Sep 07 '16 at 18:09
  • @MontyHarder if their InfoSec has blanket rule allowing access to `0.0.0.0/0:22` (assuming IPv4 for simplicity sake), they shouldn't even bother with firewalling outgoing traffic, really - it adds much less security than nondefault port, as anything (and anyone) could be at port `22` somewhere in the world. And if they do add exceptions as specific `a.b.c.d/32:x` on demonstrated need only, it should be same effort no matter what port `x` happens to be. And please don't abuse *security through obscurity* phrase. Those 16 extra bits of port info are worth more than extra 16 bits of password. – Matija Nalis Sep 08 '16 at 20:58
  • 1
    @DmitryGrigoryev if you are targeted specifically, yes. But **99% are automated probes**, who won't bother (they can try tens of thousands other servers instead of focusing on your ONE - it is just not cost effective). And if they have to resort to port scanning, you can autodetect and autoblock them so much easier before they have a chance to attack ssh or other nondefault-port service (via `portsentry` and friends). – Matija Nalis Sep 08 '16 at 21:52
7

This pretty normal behavior. I get several thousand of those each day, and I assume even that is minuscule compared to what large companies face.

But do you need to worry?

  • Have you installed fail2ban?
  • Have you disabled root ssh login?
  • Have you blocked the user www-data from ssh login?
  • (optional) Have you disabled password based login in favor of public key login?
  • (optional) Have you changed the SSH Port from 22 to something else?
  • (optional) Have you added a TOTP pam module for login?

If yes, then you don't need to worry. Those attacks are usually dictionary based attacks on common unix user names. For example, I frequently see those "users" try to login:

  • root
  • www-data
  • test
  • admin

I really recommend installing fail2ban, as it will rate-limit any user trying to log in based on their ip, that alone should filter out most of the malicious traffic. Contrary to what others say, I am not a proponent of ip based blocking. That seems like a very coarse solution to a very fine problem. Also, those attackers usually control multiple ips, so even if you block several (or even several ip blocks), there is no guarantee you'll block them all. Fail2ban however is very flexible for those scenarios.

Martin Tournoij
  • 131
  • 8
RemusKaos
  • 128
  • 1
  • 5