Bruteforce attack through our server


Recently I’ve received an email from Digital Ocean(DO) that someone claimed a hack attack from our IP. The day before, we received a Brute force attack abuse from DO that our IP/Server has attacked another server.

I have scanned the server for any suspicious malware/virus, also I did a security upgrade at our wordpress sites, but I have not found anything suspicious yet. I haven’t either been able to find any suspicious outgoing traffic from our server, so it’s quiet strange.

I am curious what your steps are to find the cause of an bruteforce attack/hack attack? There is nothing alarming in our logs as far as I can see :/

Regards, Simon

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.


If you’re using port 55242 for SSH instead of the default port 22, those messages are simply telling you that a session was initiated for root and then rather quickly closed out.

If you’re not using 55242 for SSH, then that very well may be a cause for concern and you’d need to investigate further.

When it comes to being compromised, it’s often best to begin looking at migration options and then, setting up a more secure environment. During the migration, you’d evaluate your code, database, etc to ensure that there’s not something that would allow a would-be attacker to get back in.

What I would recommend, on a new server is:

1). Deploy with SSH Keys – this disables password authentication with DigitalOcean.

2). Setup a sudo user with their own SSH Key, confirm it works (i.e. you can run commands), then lock the root user. This ensures no-one can login with or attempt to login with the root user. All root-level commands are then executed by the sudo user.

3). Setup firewall rules that deny incoming and allow outgoing by default policy, then only open the ports that you absolutely need open such as SSH (22), HTTP (80), and HTTPS (443). Unless you’re running an e-mail or DNS server, or have some very specific requirement, that’s generally all you need to open as when it comes to NodeJS, Python, etc – you’d be proxying locally or proxying over the private network. Make sure the firewall is active.

4). When it comes to SSH and Port 22, it’s best to restrict by IP. If you don’t have a static IP, this can be a problem as your IP can change at any time. In such a case, I’d recommend setting up a VPN, then restricting access to the VPN IP since it will be static. You’ll have to be connected to the VPN to get in but it’s far more secure.

5). Don’t use sudo users for access when it comes to your sites. Use normal, un-privileged users that can’t login to a shell. Allowing SFTP access to these users is fine, but they should be prevented from logging in to any form of SSH unless it’s absolutely required.

6). Use individual users for each site. You can use www-data for your first site, but create a new user and a new home directory for each site after, even if you use www-data2, www-data3 etc. This will prevent one user from accessing files of another as long as permissions are setup correctly.

7). Make sure you’re not exposing information that shouldn’t be exposed. For example, with PHP, using phpinfo() will provide you with a lot of useful information about your setup, but you don’t want that all exposed to the public.

Beyond the above, the previous information still applies.


At the server level, I would first look over the contents of /var/log/auth.log.

tail -50 /var/log/auth.log

That’ll give you an idea of who has logged in, or attempted to, and whether it was successful or not. If you don’t recognize one of the users, see if they exist.

cat /etc/passwd

One a clean (freshly deployed) Ubuntu 16.04 Droplet, where no additional users have been added, the above file looks like:

list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false

If you see someone you don’t recognize and you’re sure it’s not a user that’s associated with your site or services you’re running, you can remove them using userdel. Be careful there as if you delete a user that is associated with a service, it will fail.

userdel username

Beyond the basics of checking logs and the current system users, run a root kit check using either rkhunter or chrootkit. Using DenyHosts is also a pretty good option to block certain attempts at logging in, though as with any tool that can deny access, you need to be careful not to block and lock yourself out.

If you’re not already, use SSH Keys over plain-text password authentication when accessing SSH. An RSA key with a bit size of 4096 bits or even 8192 is ideal, though you can also use ed25519 as well. You’d generate the key(s), download the private key (if you can’t generate them locally) and make sure the public key is in your users authorized_keys file.

SSH Keys are the preferred way to login, though I would also advise making sure your key has a valid passphrase protecting it, otherwise key-based login can be as insecure as password-based login since there’s no valid protection preventing someone from using your key(s) if they get ahold of them.

Once you have SSH Keys setup, completely disable password-based login.

Also server side, check permissions on files and directories. If any directories or files are using a chmod of 777, fix it now. There’s no reason to give such higher level access. Files should be at best using a chmod of 644 and directories a chmod of 755 (some may get by with 750).

On the WordPress side, check out WordFence:

Also check your theme files, plugins, etc – make sure they are 100% up to date as well.