Hi @mash3lan

We, the user community forum, don't have access to see what has happened, but what are you running on the droplet?
Meaning, which web server, database, web-system etc.

There's a chance that a file was placed somewhere on the old droplet, which then gives attacker access to the new droplet, since you might have copied it over.

@mash3lan

When it comes to security, there's more to it than just using SSH keys. You may very well use a 4096 bit RSA key, or an ED25519 key (which some feel is more secure) -- with a passphrase -- and using a total of 1,000-2,000 KDF rounds.

By all means, that's secure in terms of you logging in to the server and it will prevent someone who steals your key from being able to auto-login (as would be the case if you weren't using a passphrase), but that doesn't mean everything else is secure. That said, the security of that key banks on how hard it is to guess your passphrase. A simple passphrase offers zero protection, or, at most, the absolute bare minimum.

A firewall is essential. You block all ports except those you absolutely require open -- which in most cases, is ports 80, 443, and 22 (HTTP, HTTPS, and SSH). While a firewall will keep most common attacks at bay, it won't prevent them all.

A firewall and secure SSH keys are, however, just a bare minimum. You still need to implement ways to secure your stack (i.e. NGINX/Apache, NodeJS, MariaDB/MySQL, PHP, etc) and you need to always keep things up to date -- not just every so often, it's on-going.

Setting up SSH keys, the firewall, and creating a sudo user are just the bare essentials.

Moving beyond the server, you also need to keep your code base up to date and work on securing it where possible.

...

There's really quite a bit that goes in the managing and securing a server and it's all on-going. If you're not able to do it on your own, I would definitely recommend hiring a sysadmin to help you and work with you as needed.

I am a sysadmin and have worked with quite a few people here in the community. What you see in the guides are just basics. Few guides are all-inclusive and comprehensive enough to encompass security as a whole.

You'll get bits and pieces here and there, but ultimately, when you're running your own server, you're responsible for making sure everything is taking care of.

@mash3lan

To provide you with a general example, I'll use WordPress which uses PHP and MySQL/MariaDB. It's the target of a lot of attacks and a lot of sites fail to update core, plugins, and themes.

...

Let's say that you followed a very basic guide on how to setup NGINX, PHP, and MySQL on Ubuntu. That guide didn't tell you how to set things up properly, but you're not familiar with how things should be setup, so you assume to guide is correct.

PHP-FPM, by default, runs as the www-data user, so you're files and directories would be owned by that user and group (which is pretty common). That user and group have read + write permissions otherwise WordPress would fail to work, or you'd have to do a lot of things by hand (not really a bad thing, but it slows things down).

Now, a tool such as wpscan can be used on my end to analyze your website. I'll know exactly what plugins you have installed and if they are vulnerable. If you're running a vulnerable version of a plugin or WordPress itself, I can then see what the attack vector is.

From there, if one of the attack vectors allows me to upload a PHP file to your server without alerting you, I'm in and as long as I can execute that file, you're in trouble.

I could do something quick and easy like simply deleting your files:

<?php
$dir    =   __DIR__;

$cmd    =   shell_exec( "rm -rf $dir" );

All it takes is one execution of that file and boom, files are gone. But most attackers don't want to kill off their chances of doing more, so that most likely wouldn't be the most common incident.

So since I have access to upload files, I could upload something that does more damage to you than just deleting files. I can target your account so it looks like your abusing it.

If I see you're using a mail plugin, bingo. I can download the plugin, see what I need to do in order to interact with it and then mail blast whoever I want. It'll come from your account on both ends, so at the end of the day, all I did was write a little code to cause you some serious trouble (i.e. account suspension, deletion, etc).

I could also write something that would simply redirect traffic off your site and over to another -- perhaps something that looks like your site, and steal your visitors data.

Also keep in mind, if I can read your files using my scripts, I can read wp-config.php which contains your database credentials. That means I know how to connect to your database, so that's probably my next target.

...

All of these are just examples of course -- what someone could do. The thing is, none of these have anything to do with your server other than permissions on your files. So in this case, using the most secure SSH key in the world and 20,000 KDF rounds isn't going to save you. All of these are web based attacks that you're firewall isn't going to pick up.

Now, if you happen to be running PHP-FPM or a service as root and I can get in (which I've seen in many cases, sadly, on web-based apps), there's really no telling what I could do. I could do all the above far easier, upload my own SSH key, etc. At this point, I could sit idle and let you feed me data or I could just keep things moving along and do whatever I want. After all, with root access that works, it's root access, so there's not much you're going to do unless you find out how I got in and fix it.

At that point, with a root-level breach, you're better of identifying on the current server and firing up a new one, making sure you fix what was wrong with the other as you'd be asking for trouble trying to fix a rooted server.