33

I am fairly new to the system administration world. I've been working on an application recently and when I check my application server logs, I constantly get various IP addresses trying to ssh into my server by brute force. Here is an example of my server log: 

Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2

Is this something that is fairly normal, or should I be worried/doing something about it?

4
  • 3
    Try changing the port number and see if it persists. If they're not targeting you specifically, it probably won't.
    – goldilocks
    Feb 14, 2015 at 10:25
  • 14
    The best solution is to disable password authentication on SSH, as that will certainly stop brute force attacks!
    – Willem
    Feb 14, 2015 at 12:13
  • 2
    possible duplicate of What are the pros/cons of the various methods to block brute force SSH attacks?
    – Martin Schröder
    Feb 14, 2015 at 13:12
  • 3
    @Willem - no, disabling password authentication will NOT stop the attacks. It will only render them unsuccessful (the attackers will not realize that password authentication has been disabled, and will continue trying).
    – Martin Vegter
    Feb 17, 2015 at 15:00

7 Answers 7

Reset to default
60

Welcome to the wonderful world of the Internet... Have you:

But the real answer is: Yes, this is normal: the BotNet Maffia can always use a few extra badly protected servers...

2
  • 1
    I prefer to not have SSH in the wild, wild Internet. +1
    – Rui F Ribeiro
    Sep 15, 2018 at 18:06
  • 2
    Beside changing default port for ssh we also have port knocking.
    – Pablo A
    Oct 25, 2018 at 1:48
15

It is fairly normal to have login tryouts enough to make a flooding log.

Changing SSH ports is more of a 'security by obscurity' type of solution, but it helps with the flood. I stress it's not very elegant; there are de-facto ports for services for a reason.

As it should be on by default, but ensure you cannot SSH into your server as root. It's the username that's fairly consistent among servers and thus the prime target for password brute force login attempts. Enforce the setting with the following line in sshd_config:

PermitRootLogin no

Also look into fail2ban that monitors sshd logs for repeat offenders. For instance, 5 failed logins in 3 minutes from a certain IP would get that IP blocked for 10 minutes. I increased that ban time to 24 hours to further reduce the log spam -- successfully. :)

2
  • 1
    apt-get install fail2ban will get you basically covered
    – Willem
    Feb 14, 2015 at 12:13
  • 8
    "I increased that ban time to 24 hours to further reduce the log spam" Trust me. Unless you have physical access to the server, one day you will deeply regret that. ;)
    – Daniel
    Feb 17, 2015 at 9:27
8

I would suggest you to do a few things:

  1. Change the port ssh is listening at (to something far above 1024) and make sure you use no version 1 of the protocol:

/etc/ssh/sshd_config

# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

  1. Instal fail2ban - it monitors log files and temporarily or persistently bans failure-prone addresses by updating existing firewall rules (iptables).

  2. Make sure you white-listed your trusted locations.

7

Yes, be worried. You may never get burnt, but you should be following IT best practice. Better safe than sorry.

I'm a network admin at a hospital. It is always a bad idea to connect a box directly to the internet. What you're seeing is all the thousands of automated scanners that scan for vulnerability on the internet. I see these and all sorts of things (port scans, various known vulnerability tests) for all kinds software (ssh, telnet, ftp, etc) show up on our ids box
Your machine should be behind a firewall/NAT solution and you should only port-forward the required ports to the internet (80, 443 etc). It's relatively easy to do.
Having something you can use for managemnt (SSH telnet) is a bad idea to have facing the internet because if — for whatever reason — there is a bug in the SSH/telnet software on that server, the automated bot will detect it in a heartbeat and you'll be screwed. Bugs in software happen all the time and it can take a while for a patch to be released or for you to remember to patch it.

If you need to remotely manage, look into setting up something like a VPN solution or if you use Windows, set up terminal services gateway for remote desktop. I know you can use a separate Linux or Windows box with 2 NICs to set up routing and remote access for VPN and NAT if you're just a small shop. Otherwise, vendors like Cisco have hardware firewall/NAT solutions (Cisco ASA).

In summary, put your machine behind NAT. Only port forward the ports required to run the purpose of the service. Don't port forward services used for management to the internet, instead look into VPN for remote management.

P.S. Changing SSH ports may help with the log volume but it doesn't actually prevent access to SSH. Any one of the thousands of automated vulnerability finders can and will do port scans to see what ports are listening for what services. You can do it yourself with a tool called nmap.

3
  • 8
    Actually, a VPN solution is not more or less secure than a SSH server. They both rely on the cryptographic protocols being correctly implemented and the services properly configured. Through different means I would say they provide exactly the same level of security. Then, if I understand you well, you put a SSH behind a VPN, then yes that's one level more secure.
    – lgeorget
    Feb 14, 2015 at 21:42
  • Yes you are correct that is what i meant, use vpn to get passed the firewall/nat then ssh into the server
    – person
    Feb 14, 2015 at 22:45
  • 1
    fwiw most VPN setups go through several layers of client authentication as well as provide a single point external traffic can reach the internal network. Versus having many nodes. VPN concentrators are also not usually interesting targets in and of themselves, versus the server that's probably housing the sshd instance. An ssh jumpbox can be as secure as most VPN configurations, but in general, that's not how it works.
    – Bratchley
    Feb 15, 2015 at 4:30
5

You could configure the internal firewall of the kernel by iptables. So that only a few machines could ssh to your server and let other IP packages drop. See man iptables for more information.

For example, if 192.168.1.67 is the host you ssh from, then on the server type:

sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save
1
  • 2
    Do note you'll get severely screwed if remote management is your only option. Most IP are only semi-permanent. Change the hardware and you'll be burned.
    – Mast
    Feb 15, 2015 at 23:14
3

Do you really need your server on the internet? If you really want to have it on the internet then make sure it is secure before you put it there.

Changing the port is just security through obscurity. If your attacker is more sophisticated than just running scripts it won't help.

A few things already mentioned that I recommend also:

  1. I agree with Fail2Ban, and properly configured will keep the scripts and most sophisticated hackers at bay.
  2. Setting PermitRootLogin to no is a must.
  3. Configure a firewall. I usually simply edit the iptables rules, but something like UFW or firehol will work too.

I just joined this community because there is two things that I don't think have been adequately addressed.

  • In the firewall config block/disable absolutely everything that isn't completely necessary. Before you open any ports ask yourself, "Do I really need this service from the internet?" Every port/service that you open becomes another potential vector that someone may be able to exploit. If there is a bug in that service that allows them to gain root access to the server they might be able to access everything on it. Your security is only as strong as the weakest link.
  • Now for the last thing and arguably the most important. The scripts you have seen trying to access ssh might be able to guess your password over time. Fail2Ban will slow them down a lot, but they could still potentially guess it. If they do, you want 2 factor authentication on the accessible services. For that I recommend a free account with Duo Security. https://www.duosecurity.com/docs/duounix
2
  • 2
    Changing the port has the advantage of cleaning up the log files: since script kiddies mostly don't attack non-default ports, you know that any log entry represents a serious threat.
    – Mark
    Feb 16, 2015 at 4:29
  • Changing the port also isn't quite zero use against a real threat. A speed bump isn't much of a wall, but it's still a speed bump, and there are ways you can make this one into a somewhat bigger speed bump. Also, while 2 factor authentication is certainly a good idea to use whenever possible, and should almost always be possible, there are edge cases. If there's a specific minimum amount of time you can be pretty sure Fail2Ban will delay them for, then simply changing your password more often than that will force them to start over repeatedly and never finish.
    – Matthew Najmon
    Feb 16, 2015 at 14:07
2

Another example to @cff answer, if you intend to ban any successive "tries" on your SSH server:

sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save

This one 'tags' connection attempts and if more than 4 happens in 600s (10mn), then the origin is 'banned'. Use this instead of @cff solution because it's more safe (if you lock yourself out, wait 10mn and retry).

Not the answer you're looking for? Browse other questions tagged .