Most hardening guides are enormous and assume a security team. This one is ordered by value per minute, for teams where the person securing the server also has other jobs.
First hour
Patch everything. Unpatched known vulnerabilities remain the most common way in.
sudo apt update && sudo apt upgrade # Debian/Ubuntu
sudo dnf upgrade --refresh # RHEL family
Enable automatic security updates. Manual patching does not survive a busy month.
Lock down SSH. Keys only, no root login, explicit user allowlist.
Turn on a firewall with a default-deny inbound policy.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
Close what you are not using.
sudo ss -tulpn | grep LISTEN
Every listener is attack surface. If you cannot explain why it is there, investigate it.
First day
Create non-root users with sudo, one per human. Shared accounts destroy accountability.
Install fail2ban.
sudo apt install fail2ban -y
Set up log retention long enough to investigate something you notice a month late.
Configure off-server backups and test a restore. An untested backup is a hope, not a backup.
First week
Enable auditd for a record of privileged activity.
Set up file integrity monitoring on /etc, system binaries, and your web root.
Document what normal looks like - expected processes, listeners, users, cron jobs. You cannot spot abnormal without this.
Review user accounts and keys. Old contractor access is a classic finding.
Ongoing, and this is the part that gets skipped
Hardening is a point-in-time action; servers drift. Packages update, someone opens a port for a demo, a config gets changed during an incident and never reverted.
What matters over time is noticing change: has a config file changed, is there a new listener, a new user, an unexpected outbound connection, a package with a newly published CVE.
Doing that manually across even a handful of servers does not survive a busy quarter. It has to be automated, and the automation has to be quiet enough that people keep paying attention to it.
That is the problem SecAI is built for: continuous monitoring of exactly these signals, with an AI pipeline that reviews findings so you get a short list of things that matter rather than a firehose. See it alongside the rest of the detection stack.