Security Is Not Optional

Every server I audit has at least three of these issues. They're simple to fix, yet consistently overlooked. A single breach can cost a small business thousands of dollars in downtime, data loss, and reputation damage. Here are the top 5 mistakes and how to fix them.

1. SSH with Password Authentication

If your server accepts SSH passwords, it's being brute-forced right now. Check your /var/log/auth.log — you'll see hundreds of failed login attempts daily from bots around the world.

Fix: Switch to SSH key authentication and disable password login entirely:

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

This single change eliminates 99% of brute-force attacks. It takes 5 minutes.

2. No Firewall Rules

I regularly find servers with all ports open to the internet. Database ports (3306, 5432), Redis (6379), admin panels — all accessible from anywhere.

Fix: Use ufw (Uncomplicated Firewall) to allow only what's needed:

ufw default deny incoming
ufw allow 22/tcp    # SSH
ufw allow 80/tcp    # HTTP
ufw allow 443/tcp   # HTTPS
ufw enable

Everything else should be blocked by default.

3. Unattended Upgrades Disabled

Security patches are released weekly. If your server isn't automatically installing them, you're running known-vulnerable software. The Equifax breach happened because of an unpatched Apache Struts vulnerability — the fix had been available for months.

Fix: Enable automatic security updates on Ubuntu:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

4. Running Services as Root

If your web application runs as root and gets compromised, the attacker has full control of your server. Running services as unprivileged users limits the blast radius of any vulnerability.

Fix: Create dedicated users for each service. Docker helps here — containers run in isolation by default. But even with Docker, don't run containers with --privileged unless absolutely necessary.

5. No Backups (or Untested Backups)

Having backups is step one. Testing them is step two — and most people skip it. I've seen companies discover their backups were corrupted only when they needed to restore. By then, it's too late.

Fix: Automate daily backups to an external location (S3, another server). Set up a monthly restore test. If you can't restore it, it's not a backup — it's a hope.

Take Action Today

These five fixes take less than an hour total and dramatically improve your security posture. If you're not sure about your server's security, I offer comprehensive server audits with a detailed report and remediation plan. Contact me for a security review.