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