On DigitalOcean, skip
swap. On solid-state hard drives it can actually cause more harm than good. Instead of
swap, you need to more effectively manage your RAM usage (if it’s an issue) or upgrade RAM.
On a LEMP Stack (NGINX, MySQL/MariaDB, and PHP-FPM), the majority of your RAM is going to be consumed by MySQL/MariaDB, so that’s where I’d look first unless you’re not caching anything, then you may also see PHP consuming quite a bit (in medium-high traffic scenarios). NGINX doesn’t use RAM like Apache does as NGINX is effectively offloading the processing to PHP-FPM using FastCGI.
In terms of security, start with SSL and make sure it covers your site from endpoint to endpoint. Make sure requests on port 80 are redirected to 443, thus ensuring SSL is used in all instances.
There’s two main types of passwords that should be used – completely random or phrases.
The degree of randomness is only limited to what you’re application accepts. While most will accept special characters, some won’t. For example, a good random password, in my eyes, would look like:
Compliments of https://www.grc.com/passwords.htm
Now, unless you use a Password Manager, those passwords are going to be impossible to remember. If you use one of those for a
root password and forget it, you’ll be loading from recovery or starting from scratch, so be careful.
On the flip side, random phrases are easier to remember and provide relatively high security, when used correctly.
For example, we could use a phrase such as:
This was randomly generated compliments of https://xkpasswd.net. Now, that is a little easier to remember in terms of remembering words instead of completely random characters.
It’s your choice which to use, but at minimum, I’d recommend 4-6 words on the phrases and at least 32-64 characters on random passwords. Switching case (upper and lower) is advised. Adding in extra characters where you feel is needed is also advised (i.e. I would use
-_- so that the phrase isn’t using the same separator each time).
The biggest issue here is making sure that your users are doing the same, especially those who may have any sort of elevated rights, whether server or application. If they aren’t, they are now the weakest link in your security chain.
Always use a firewall. Since you’re using Ubuntu, I’d recommend setting up default deny policies and then only allowing the ports you want to allow access on in.
For example, let’s make sure
ufw is disabled (i.e. off).
Now let’s reset it (delete all existing rules):
Now let’s set default policies – don’t worry, they won’t take effect until you turn
ufw back on, so you won’t be blocked by running these commands.
ufw default deny incoming
ufw default allow outgoing
Now let’s allow in ports that we know we need to allow access on. For you, we need SSH, HTTP, and HTTPS.
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
Now you can connect over SSH using Port 22 (default port) and accept both HTTP and HTTPS requests. So let’s turn
ufw back on.
Confirm you want to enable
ufw and boom, that part is done. You now have a working firewall that will allow outgoing connections (which are needed to update/upgrade software from repos) and will only allow incoming connections on 22, 80, and 443.
Beyond the firewall, software such as Fail2Ban can be helpful, but it can be a pain to setup and also manage. It’s definitely not a bad solution though, just make sure you read over how to set it up and how to use it. If you don’t make use of it and “just let it run” without monitoring, it’s useless (as is the case with most things).
Beyond a firewall and similar solutions, keep things up to date. When a new version of NGINX, PHP, MySQL/MariaDB is released and the intent is to patch flaws in the software, make sure you update. A firewall and similar won’t protect you from issues that can be exploited from the web.
Likewise, keep WordPress updated, update your plugins when new releases are made, and keep your theme updated. If there’s a security hole that can accessed from the web via one of those, and it can be exploited, assume that it will be and make sure you’re doing your due diligence to prevent it.
There’s a lot that goes in to security. Simple things like the above are easy to manage, but you should also be checking your logs, checking failed logins, checking for software updates/upgrades, patching, etc. A lot happens very quickly in software development and when it comes to managing servers, it’s all part of keeping up with it.