Checklist · Security
Linux Server Hardening Checklist
Opens with creditsA Linux server hardening checklist for a VPS or cloud VM that runs your app. It covers user accounts and sudo, SSH, security updates, open ports and the firewall, system settings and permissions, logging, and checking the result against a CIS benchmark, with a command to verify every check.
Written by Tauseef Fayyaz7 chapters, 38 checksAbout 19 minReviewed 13 October 2026What you will learn
7 chapters · about 19 min
1User accounts and sudoChecks that every person has their own account, nobody works as root, and admin rights are limited and traceable.5 checks · 3 min
- 1Every person who logs in has their own named account
- 2Nobody logs in as root; admins use sudo from their own account
- 3sudo rules are edited with visudo and grant only what each role needs
- 4Accounts and keys of people who left are removed the same day
- 5Service accounts have no login shell and own only their own files
5 in this chapterOpen this chapter2SSHChecks on the front door: key-only logins, no root, a tested configuration and as little exposure as possible.7 checks · 4 min
- 1SSH accepts keys only: password and keyboard-interactive logins are off
- 2Root cannot log in over SSH
- 3SSH changes go in a drop-in file and are tested before restart
- 4Only members of a named group can log in over SSH
- 5Admin keys are Ed25519, passphrase protected, and authorized_keys is not writable by others
- 6SSH is reachable only from known networks, or not exposed at all
- 7Unused SSH features such as forwarding and version banners are turned off
7 in this chapterOpen this chapter- Updates and packagesChecks that the system gets security fixes without anyone remembering to, reboots when it must, and runs only software you need.5 checks · 2 minOpens with credits
- Open ports and the firewallChecks that only the services you intend are listening, and that a firewall blocks everything else even if a new service starts by mistake.6 checks · 3 minOpens with credits
- System settings and file permissionsChecks on the operating system itself: mandatory access control, kernel network settings, sensitive file permissions and mount options.6 checks · 3 minOpens with credits
- Logging, time and integrityChecks that the server keeps a trustworthy record of what happened, somewhere an attacker on the box cannot erase it.5 checks · 2 minOpens with credits
- Benchmarks, configuration and recoveryChecks that compare the server against a published baseline, keep its setup reproducible, and make sure you can recover it.4 checks · 2 minOpens with credits
About this checklist
This Linux server hardening checklist is for the server you actually run: a VPS or cloud VM with your app, a database and a reverse proxy on it. Fresh images are not insecure, but they are general purpose. Password logins may still be on, every package you installed for a quick test is still listening, nobody is watching whether security updates apply, and the firewall on Ubuntu starts disabled. Hardening means turning that general-purpose machine into one that does only what you need.
The checks follow the order you would work in on a new server. First, who can log in and with what privileges. Then SSH, which is the front door. Then updates, the network surface (open ports, the host firewall and services bound to the wrong address), system settings and file permissions, and logging. The last chapter checks the whole machine against a CIS benchmark and makes sure you can rebuild it.
Commands are given for Ubuntu and Debian first, with the RHEL equivalent where it differs. The advice follows the Ubuntu Server documentation, the OpenSSH manual, Red Hat's RHEL 10 security hardening guide and the CIS benchmarks. Each check has a severity: must means do it before the server holds real data, should means do it soon, nice means worth doing once the rest is solid.
Common questions
What is Linux server hardening?
It is the process of reducing what a server exposes and allows: removing unneeded software and accounts, locking down SSH, keeping packages patched, closing ports with a firewall, tightening permissions and logging what happens. The goal is a server that only does what your app needs.
What should I do first on a new Ubuntu server?
Create your own user with sudo, add your SSH key, then turn off password and root logins for SSH and test from a second terminal. Enable ufw with SSH, 80 and 443 allowed, confirm unattended-upgrades is running, and check ss -tulpn for anything listening that should not be.
Is changing the SSH port a good security measure?
It reduces log noise from automated scans but does not stop a targeted attacker, who can find the new port quickly. Key-only authentication, no root login and limiting which networks can reach SSH matter far more.
Do I need fail2ban if SSH uses keys only?
It is less important once password logins are off, because guessing cannot succeed. Recent OpenSSH also has PerSourcePenalties on by default, which temporarily refuses sources that keep failing. A firewall that limits SSH to known networks helps more than either.
What is a CIS benchmark?
CIS benchmarks are hardening baselines published by the Center for Internet Security for specific OS releases, such as Ubuntu 24.04 LTS. They list detailed settings with audit and remediation steps. Tools like the Ubuntu Security Guide and OpenSCAP can scan a server against them.
Should my server reboot automatically for updates?
Something has to restart it, or a patched kernel never takes effect. You can set Automatic-Reboot in unattended-upgrades with a fixed time in a quiet window, or schedule reboots yourself. Either way, monitor for /var/run/reboot-required so nothing waits for months.
Sources (7)
Checked against these, last on 13 October 2026.
- CIS Ubuntu Linux Benchmarks, Center for Internet Securitywww.cisecurity.org/benchmark/ubuntu_linux/
- OpenSSH server, Ubuntu Server documentationubuntu.com/server/docs/how-to/security/openssh-server/
- sshd_config(5) manual page, OpenBSDman.openbsd.org/sshd_config
- Automatic updates, Ubuntu Server documentationubuntu.com/server/docs/how-to/software/automatic-updates/
- Firewalls, Ubuntu Server documentationubuntu.com/server/docs/how-to/security/firewalls/
- Security hardening, Red Hat Enterprise Linux 10, Red Hatdocs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/security_hardening/index
- CIS compliance with Ubuntu Security Guide, Canonicalubuntu.com/security/certifications/docs/usg/cis
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Secrets Management Best PracticesKeep API keys, passwords and tokens out of git, logs and browser bundles: secret managers, scanning, rotation, OIDC in CI and leak response.
- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Disaster Recovery ChecklistBackups and DR you can prove: RPO and RTO per system, backup coverage, off-site and immutable copies, restore tests, zone and region choices, runbooks, drills, dependencies and communication.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com