How to secure your new VPS: a step-by-step guide

opinions on the suggested fail2ban and ufw?

ufw yes, fail2ban doesn't necessarily do much for you if you have disabled password authentication.

fail2ban is a critical piece of security software, as is some firewall. for those new to linux, you might as well use the one that is super-easy to install.

The opposite is true about fail2ban: it's cargo-cult security, and people shouldn't be running it. It never made any sense, but it especially makes no sense if you're going to (sensibly) disable password authentication.

Honestly, for somebody running a personal server, ufw/iptables/etc tend to not be relevant for any direct security. Basically nobody is doing anything for outbound rules other than ACCEPT, and for inbound... people can only connect to services you're running on your public interface. So for most people, they'd just be setting up ufw/iptables/etc to allow traffic to the set of services they're running (ssh, a web server, etc) anyways.

That said, I do think there's some value in understanding what your server is running and what it's exposing to the network, and setting up firewall rules is one of many ways to build familiarity with that.

fail2ban is just junk, and shouldn't be running on any modern system.

I agree for ssh - but I use it on a couple servers that have WordPress for the sole purpose of blocking IPs that engage in brute force attempts.

It has a real and dramatic impact on a few things - I got CPU warnings from one server a couple weeks back because I'd inadvertently broken logging and fail2ban stopped working and someone was doing a persistent brute force at high volume for 8 hours.

After I fixed fail2ban it dropped off immediately. I know some WordPress plugins will do this but I've not had much success with them compared to fail2ban so it's still my default for this purpose.

Are there better system-level approaches than fail2ban in this case? Or is your comment mostly directed towards those using it for ssh blocking?

Just SSH.

You're talking about it as if it only handles SSH authentication.

It's no substitute for proper security, but it's a great mechanism for quickly dropping naughty traffic. Even people who practice good security have online systems that are occasionally vulnerable to zero days, or have password forms on webapps. Dropping traffic while it's still in discovery mode is a great way to frustrate automated attacks.

Use fail2ban if you use popular online web apps like Wordpress, cpanel, Drupal, etc.

It won't protect you from a direct attack, and it's no substitute for good system security, but it can quickly block attackers who "scan" your system to see what's running, to see what they can attack. It won't stop a determined attacker who will be able to attack from many locations, but that doesn't make it useless.

You can also use it actively to block people who do things like hammering a password form.

Honestly I have never used it. That and OSSEC can lock people out when they are using the wrong keys or wrong passwords if passwords are enabled there are legit use cases for passwords.

Begin Disclaimer: The following comment is not for security, but only to reduce log noise :: I use a high port for non public SFTP servers to avoid noise. :: End Dislclaimer. It's not like the bots are getting in but I don't want the log noise. Not security through obscurity, just noise reduction. This is just for my bastion nodes. All other nodes require specific IP addresses or Tinc VPN to reach that high port.

To avoid 99% of the bots I use IPTables MSS rules to drop anything outside of the MSS any of my clients will show up with. I also personally drop anything with a TCP SYN packet TTL greater than 64 since all my clients are Linux. Windows is 128 and cell phones / LTE devices most of the bots are greater than 128. Don't do this in a corporate environment and instead require people use a corporate VPN. The following IPTables rules can be modified to include or exclude any ports or ranges of ports.

    # (raw table for public bastion, using default port 22 as an example)
    -A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d ${WAN_IP} --syn -m tcpmss ! --mss 1460 -j DROP
    -A PREROUTING -i eth0 -p tcp -m tcp --dport 22 -d ${WAN_IP} --syn -m ttl --ttl-gt 64 -j DROP

People can alter their TCP TTL but in reality they do not. FWIW a bot has never reached any of my sshd daemons in 25+ years on nodes that I do not expect random IP's to connect.

sshd can also be told to only listen on IPv4 or IPv6 whichever you prefer. e.g. addressfamily inet for IPv4 only.