My server is constantly being attacked

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 [] 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=  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 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 [] 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=  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from port 41562 ssh2

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

Asked By: SivaDotRender


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…

Answered By: Fabby

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:


# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
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.

Answered By: pawel7318

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. 🙂

Answered By: mike3996

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 is the host you ssh from, then on the server type:

sudo iptables -A INPUT -p tcp --dport ssh -s -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save
Answered By: cff

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.

Answered By: person

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.
Answered By: moriab

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 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask --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).

Answered By: xryl669
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.