Hello there.
I will try to give my few cents about your question.

• Firewalld. This is important step and only allow needed ports.
• Configure sshd to not accept connection to root. That’s Ok.
• Configure sshd to run on port other than 22. Ok, in my opinion not really needed. If someone wants to break in you server via SSH, he/she will find port. For example, via nmap, you can scan for server open ports and find which one you need. nmap tutorial can you give more insight if you interested in this utility.

However, there are a few other SSH measures you want to take:

• Use public key authentication. Initial Set Up for CentOS - Step 4 covers this step.
• When you’re sure your public key work - disable password authentication.

fail2ban will ban attacker if it fails authentication too many times. How much times and what happens are settings you define. Even with pub-key authentication, I would configure fail2ban. It doesn’t use many resources and it’s good security practice.
It also works with many apps, SSH are one of them you should configure, but if you use WordPress for example, you can configure for it too.
There is fail2ban tutorial which should help you install and understand it.

Well about SELinux… I guess this is a controversial topic. This depends on how much you know about Linux and doing sys admin job. If you are new to Linux/CentOS and all VPS things, I would skip until you learn more about it. If you are experienced, go ahead and try. I would go with permissive mode until you test everything and then potentially go to enforcing.
You can learn more about it in CentOS 7 - SELinux tutorial series. If you think you can manage it, go ahead and try.

Beside that, don’t forget many times repeated things. Keep your server updated, and do regular backups.
Also, thing you can look at if you want better control are advanced logging system and monitoring tools. You can set up audit logging and watch for system logs, there a few great utilities there. Monitoring tools can help watch for server load, if you notice high server load, you can take a look if everything is right.
You can learn more about this topic in DigitalOcean tutorial 7 Security Measures to Protect Your Servers, it could give you few more ideas.

@marmot7

When it comes to properly setting up your firewall, setting up policies that, by default, deny incoming and allow outgoing is pretty standard. Once in place, you’d then define what ports you want to open instead of what ports you want to close (which is a rather lengthy list – hence it’s better to deny all, then allow in as opposed to allow all, then deny).

Once deny/allow policies have been setup, making sure you allow common ports to be accessed is the next step. For example, SSH is 22, HTTP is 80, and HTTPS is 443. You want to allow access to SSH otherwise when the firewall is turned on, you’ll get kicked and will have to revert to the console to log back in and start over. HTTP and HTTPS are what allows standard and secure connections to your site, so these need to be open unless you’re not using this as a public-facing server.

Looking beyond the firewall, a few of the biggest issues I commonly see are:

Logging in as root – Not using sudo users

After your server is up and running, creating a sudo user should be one of the first steps you take so that you don’t need to login as root thereafter. The sudo user, when properly setup, will be able to run root commands by prefixing the command with sudo, i.e.

sudo systemctl restart nginx

Directory and File Permissions

As a general rule of thumb, directories should have a chmod of 755 and files a chmod of 644.

Far too many guides on the internet recommend using a chmod of 777 on directories, but fail to mention that 777 means world read, write, execute.

Beyond basic file permissions, files and directories should be owned by a non-root, non-sudo user (ideally) – as in a basic user that can own files and directories, but has no permission to escalate. You can still give SFTP access to basic users, they could still technically log in via SSH (if you allow it), though they can’t do anything that doesn’t involve accessing their files and directories.

You can take the above a step further and force users in to a chroot, which means they can’t get out of their home directory, though it’s a bit more complex (but ultimately more secure).

Going Beyond

It’s important to keep in mind that security is not a one-time deal – it’s not set and forget, it’s truly on-going. You can’t just setup a firewall, fail2ban, set proper permissions and call it a day.

At the end of the day, there’s not a one-size fits all type of setup. What I may allow on my Droplet with NGINX, PHP-FPM, MariaDB, and ufw may not fit your particular needs. You may need a more restrictive setup, or less.

It’s about knowing the software you’re working with and securing it to prevent any potential breach. That’s not to say, however, that you won’t be breached, but ensuring you know what to look for and where to look will make handling potential attacks far easier.

I think perhaps the most important point you made was nuts and bolts that it’s all too easy to overlook:

As a general rule of thumb, directories should have a chmod of 755 and files a chmod of 644.

Thank you for the answer in general. I’m really impressed with the quality of the answers overall. It actually surprised me. it’s not that I expected bad answers, it’s just that every answer I’ve gotten in this forum has exceeded what I expected!