Small Server Hardening: SSH, fail2ban and BBR Checklist

A small cloud VM — a Lightsail or Flexus instance with 1–2 vCPUs and 1–2 GB of RAM — is attacked within hours of going online, because bots scan the whole internet for open port 22. Hardening it does not need expensive tooling. The checklist below is what I actually run on a fresh low-cost server, in order, and it keeps the machine usable while cutting the noise dramatically.

1. Start with the account and SSH, not the firewall

Create a normal user, give it sudo, and disable direct root login. In /etc/ssh/sshd_config set PermitRootLogin no and PasswordAuthentication no once key login works, then restart sshd. Test the new login in a second terminal window before closing the old session — locking yourself out of a cheap VM is the most common self-inflicted outage.

Also change the habit, not just the port: moving SSH off port 22 reduces log spam, but it is obscurity, not security. Keep key-only authentication as the real control, and keep the key itself protected with a passphrase.

2. Add fail2ban as a cheap second layer

Install fail2ban and enable the sshd jail. The default settings already ban an address after a handful of failed logins for a short period, which is enough to stop most password-spraying bots. Check it with sudo fail2ban-client status sshd after a day: if the banned list is long and you have had no lockouts, it is working.

Two practical notes. First, do not set very long ban times at first — a typo storm from your own IP can lock you out. Second, if you log in from a fixed home or office IP, whitelist it in the jail configuration so a mistyped passphrase never becomes an outage.

3. Keep the firewall small and explicit

On a single-purpose VM, the firewall should allow only what the service needs: SSH (or its custom port), plus 80/443 if it serves a website, and nothing else inbound. Cloud security groups and the on-host firewall should agree; I have seen servers where the cloud group was tight but the host firewall was wide open, and vice versa. Audit both after every new service is added.

4. Enable BBR for throughput, with realistic expectations

BBR is a TCP congestion control algorithm, not a bandwidth upgrade. On a small VM serving content over a long or lossy path, it often improves throughput and reduces latency spikes compared with the default Cubic, because it models the bottleneck instead of reacting only to packet loss. Enable it with sysctl:

net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr

Apply with sysctl -p, then verify with sysctl net.ipv4.tcp_congestion_control. If the kernel is too old to support BBR, update the system first rather than forcing it — an unpatched kernel is a bigger risk than a suboptimal congestion algorithm.

5. Updates, backups and a rollback habit

Enable automatic security updates or run them on a schedule, and reboot when the kernel update requires it. A hardened server that never reboots after a kernel patch is only half patched. Before changing sshd or firewall rules, back up the config file (cp sshd_config sshd_config.bak) so a bad edit is a one-command revert, not a rescue session.

The 15-minute checklist

1. Create a sudo user and disable root SSH login.
2. Switch to key-only authentication and test it in a second session.
3. Install and enable fail2ban for sshd, and check its status the next day.
4. Allow only the ports the service actually needs, in both the cloud security group and the host firewall.
5. Enable BBR, verify it, and keep the system updated.

None of these steps costs anything beyond the VM itself, and together they turn a noisy, exposed little server into one that is boring to attack — which is exactly what you want.