Ops security

You just plugged a brand-new server into the public internet—surely nobody knows it's there yet? In reality, within minutes, automated scanners will find it. They sweep the entire IPv4 address space around the clock, trying weak SSH passwords and probing for known-vulnerable ports. You don't need any heroic hardening; just doing the few things below correctly blocks about 99% of automated attacks—the targeted stuff most projects will never see.

Every section below gives you copy-pasteable commands (for Ubuntu / Debian). Work through them in order.

Harden SSH

SSH is an attacker's favorite door, and the first one you should lock. There are really just two ideas: don't log in as root directly, and don't log in with a password (use a key instead).

# Run as root after logging in (replace deploy with your username)
adduser deploy
usermod -aG sudo deploy

# On your own computer
ssh-keygen -t ed25519 -C "your_email@example.com"

# On your own computer
ssh-copy-id deploy@your-server-ip

# On the server, as the deploy user
mkdir -p ~/.ssh && chmod 700 ~/.ssh
# Paste the contents of your local ~/.ssh/id_ed25519.pub into this file
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

sudo nano /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

sudo systemctl restart ssh

Firewall (ufw)

By default a server may have a bunch of ports open that you aren't even using. Use ufw (Uncomplicated Firewall) to allow only what you actually need—SSH, HTTP, HTTPS—and deny the rest.

# Allow SSH (use the OpenSSH preset so you don't lock yourself out)
sudo ufw allow OpenSSH

# Allow HTTP and HTTPS for your website
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall (it warns SSH may drop—type y; OpenSSH is allowed above, so you're safe)
sudo ufw enable

# Check the current rules
sudo ufw status verbose

Automatic security updates

Patches need to be applied promptly, but you can't babysit the server every day. unattended-upgrades makes the system install security updates automatically.

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

That last command opens a dialog—choose Yes to enable automatic security updates. Once set up, security patches install in the background and you stop worrying about most known vulnerabilities.

fail2ban

Even with password login disabled, attackers will keep hammering SSH. fail2ban watches the logs, and when an IP fails to log in repeatedly, it automatically bans that IP for a while, shutting brute-force attempts down for good.

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

# Check banned IPs and SSH protection status
sudo fail2ban-client status sshd

It protects SSH out of the box with almost no configuration. To tweak ban duration or the failure threshold, edit /etc/fail2ban/jail.local.

Least privilege

A plain but extremely important principle: give everything only the minimum privileges it needs to do its job.

• Don't run your app as root. Create a dedicated non-root user for the app, so that if it's ever compromised, the attacker only gets that restricted user—not full control of the whole machine.

# Create a non-login system user dedicated to running the app
sudo adduser --system --group --no-create-home appuser

• Tighten file permissions. Make the app code and data directories owned by this dedicated user, and don't make them world-writable:

# Change ownership of the app directory to the dedicated user
sudo chown -R appuser:appuser /opt/yourapp
# Directories 755, files 644—avoid wide-open 777 permissions
sudo find /opt/yourapp -type d -exec chmod 755 {} \;
sudo find /opt/yourapp -type f -exec chmod 644 {} \;

• When running the service with systemd, set User=appuser in the unit file so the process runs as the dedicated user. A ready-made systemd template is in Templates & checklist.

Secrets & env

Leaking secrets is one of the most common and most damaging beginner mistakes. The moment a database password or API key lands in a public repo, it can be scanned and abused within minutes.

• Never commit a .env file or keys to Git. Add a .gitignore to your repo:

# .gitignore
.env
.env.*
*.pem
*.key
id_rsa

• Restrict permissions on secret files so only the owner can read them:

chmod 600 .env
chmod 600 ~/.ssh/id_ed25519

• If a secret leaks, rotate it immediately. Don't assume "deleting it from Git is enough"—it already lives in history and in everyone's clones. The correct fix is to revoke the old key and generate a new one on the relevant platform, and change the database password right away too.

Don't expose your database

This is one of the most-exploited misconfigurations: a database listening on 0.0.0.0, reachable from the entire internet. Postgres, MySQL, Redis, and MongoDB have all been hit (some even ransomed and wiped).

• Bind to the loopback address so only apps on the same server can connect.

Postgres (postgresql.conf):

listen_addresses = 'localhost'

MySQL (my.cnf):

bind-address = 127.0.0.1

Redis (redis.conf):

bind 127.0.0.1

• Back it up with the firewall: make sure the database ports (Postgres 5432, MySQL 3306, Redis 6379) are not opened to the public by ufw. Earlier we only allowed 22/80/443, so the database ports are denied by default—exactly what you want.
• Always use strong passwords, never default credentials. For things like Redis that ship with no password, be sure to set requirepass.
• If the app and database are on different machines, don't take the lazy route of exposing the public internet—use a private network / VPC, or add TLS.

Backups

Servers crash, disks fail, and fingers slip. Backups are not optional.

• Automate backups of both the database and files—don't rely on remembering to run them by hand. Use cron:

# Back up a Postgres database every day at 3 AM (put this in crontab -e)
0 3 * * * pg_dump yourdb | gzip > /backups/yourdb-$(date +\%F).sql.gz

• Store them offsite. Backups sitting on the same server vanish with the machine. Sync them to object storage (S3, Cloudflare R2, Backblaze B2):

# Example: use rclone to sync backups to object storage
rclone copy /backups remote:my-backups

• Give backups a retention policy (e.g. keep the last 30 days) so old backups don't fill the disk.

Monitoring & alerts

When something goes wrong, you want to be the first to know—not to hear about it when users start complaining.

• Uptime monitor: use UptimeRobot or healthchecks.io to probe your site on a schedule and alert you by email / push the moment it goes down. The free tier is usually plenty.
• Error logging: collect application errors (something like Sentry) so exceptions don't quietly rot in a log nobody reads.
• Disk / CPU alerts: a full disk will take your database down instantly. Set a threshold alert, or at minimum check df -h regularly.
• Auto-restart the process: if the app crashes, it should come back on its own. Use systemd (Restart=always) or PM2, which is common for Node projects. A systemd service template is in Templates & checklist.

# systemd unit snippet: auto-restart after the process exits
[Service]
User=appuser
Restart=always
RestartSec=5

Grab ready-made configs

The sshd_config, systemd service files, ufw rules, and backup scripts mentioned above all have copy-paste-ready versions in Templates & checklist. Related reading: Publish to the internet, Buying a server, and Set up Cloudflare (Cloudflare adds another layer of DDoS and WAF protection).