Server Security Checklist: Baseline by Layer

Why a checklist

A public server starts being scanned within the first minute online. Most compromises come not from sophisticated attacks but from unchanged defaults, missing patches and loose permissions. This article turns DMIT cloud server security into a checkable baseline — use it together with SSH Hardening.

System layer

✅ Install security patches: apt update && apt upgrade -y, enable unattended-upgrades
✅ Minimal footprint: disable unused services (systemctl disable --now name)
✅ Correct timezone and NTP sync so log timestamps are trustworthy
✅ Schedule reboots: kernel updates need one to take effect

Accounts and permissions

✅ Disable root password login; use a normal user + sudo daily
✅ SSH key-only auth (see SSH Hardening)
✅ Audit accounts: awk -F: '$3==0{print $1}' /etc/passwd should list only root
✅ Tighten permissions: no 777 web dirs, no plaintext secrets in configs

Network layer

✅ Firewall denies inbound by default; allow only SSH/80/443
✅ Databases, Redis, object storage listen on 127.0.0.1 or private nets only
✅ Redis: set requirepass, disable dangerous commands (CONFIG/FLUSHALL)
✅ Audit outbound traffic too — compromised hosts often call out on odd ports

# UFW baseline
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Application layer

✅ Keep apps and plugins updated (WordPress backup policy in the deploy guide)
✅ HTTPS everywhere + HSTS (see HTTPS Setup)
✅ Restrict admin panels (IP allowlist or VPN)
✅ Suppress verbose errors that leak paths and versions

Detection and audit

# fail2ban auto-bans brute-force IPs
apt install fail2ban -y
systemctl enable --now fail2ban
fail2ban-client status sshd

# routine inspection
last -20              # recent logins
sudo lastb | head     # failed logins
ss -tunlp             # verify listening ports
journalctl -u ssh --since "24 hours ago" | grep -c Failed

Backups and recovery drills

✅ Implement 3-2-1 backups (see Monitoring & Backup)
✅ Run a restore drill quarterly — an unverified backup is not a backup
✅ Keep one offline copy so ransomware cannot encrypt it too

Quick self-check script

Save as security-check.sh, run weekly, review the output manually:

#!/bin/bash
echo "== reboot required =="; ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs
echo "== root-equivalent accounts =="; awk -F: '$3==0{print $1}' /etc/passwd
echo "== external listeners =="; ss -tunlp | grep -v 127.0.0.1
echo "== recent failed logins =="; sudo lastb | head -5
echo "== fail2ban =="; sudo fail2ban-client status sshd 2>/dev/null | grep "Banned"

SSH Hardening, Monitoring & Backup, Troubleshooting Guide.

Data checked: 2026-08-18. Follow your distribution's official docs for specifics.