Linux server hardening is the process of deliberately closing every default that ships "open" on a fresh install: root SSH login disabled, unused services stopped, kernel parameters tightened, filesystem mount options locked down, and every privileged action logged through auditd. The fastest, most defensible way to run Linux server hardening is to work from the CIS Benchmarks published by the Center for Internet Security — a free, versioned, machine-scoreable checklist that exists for Ubuntu, RHEL, Debian, Amazon Linux and most distributions Indian businesses actually run in production.
Most Indian SMB and startup infrastructure teams inherit servers that were provisioned fast and never revisited: a cloud image spun up two years ago, SSH still on port 22 with password auth enabled, fail2ban never installed, and nobody who can say what auditd even does. That gap is exactly what attackers scan for first, and it is exactly what a CIS Benchmark walkthrough closes in a single sprint.
Why CIS Benchmarks, specifically
There are dozens of hardening checklists floating around the internet — vendor blog posts, forum threads, AI-generated "top 20 Linux security tips" lists. CIS Benchmarks are different for three reasons that matter to a compliance-conscious business:
- They are versioned and auditable. Every control has an ID (e.g.,
5.2.10), a rationale, a remediation script, and an audit command. You can point to CIS Ubuntu Linux 22.04 LTS Benchmark v3.0.0 and know exactly what was checked and when. - They map to recognised frameworks. Auditors reviewing ISO 27001 or SOC 2 evidence, or assessing DPDP Act 2023 "reasonable security safeguards," recognise CIS control references immediately — it saves you from re-explaining your methodology every audit cycle.
- They are scoreable. CIS-CAT Lite (the free scoring tool from CIS) and OpenSCAP both consume CIS benchmark content and produce a percentage compliance score you can trend over time, which is the difference between "we hardened the server once" and "we can prove the server stayed hardened."
The rollout order that doesn't break production
The single most common failure mode we see in Indian infra teams attempting CIS hardening is applying the full benchmark straight to a production box in one pass. Password complexity rules lock out a service account, a kernel sysctl change breaks an NFS mount, or a firewall default-deny rule cuts off the monitoring agent — and now the "security improvement" is an incident.
Run a baseline scan first, always. CIS-CAT Lite or OpenSCAP against the matching benchmark profile gives you a starting compliance percentage and a diff of exactly which controls fail. From that list, prioritise by risk — SSH and authentication controls first, then filesystem and kernel, then service minimisation, then logging and auditing. Test the changeset on a staging clone that mirrors production traffic patterns before it ever touches a live host, and roll production changes out in phases with a rollback plan for each batch, not as one giant configuration commit.
SSH hardening: the highest-leverage control
SSH is the single most attacked service on any internet-facing Linux box, and it is also the fastest to harden correctly. The core changes, all in /etc/ssh/sshd_config:
PermitRootLogin no— root should never authenticate directly over SSH; usesudofrom a named account instead.PasswordAuthentication no— key-based auth only, so credential-stuffing and brute-force attempts against passwords are structurally impossible.PubkeyAuthentication yeswith keys of at least 4096-bit RSA or ed25519.MaxAuthTries 3andLoginGraceTime 30— cut off slow brute-force attempts quickly.AllowUsersorAllowGroups— an explicit allow-list rather than an implicit allow-all.- Move off port 22 only as a secondary control, not a primary one — port obscurity reduces automated scan noise but is not a substitute for the controls above.
- Pair with
fail2banor an equivalent to auto-block IPs after repeated failed attempts, and rate-limit SSH at the cloud security-group / firewall layer too.
~/.ssh/authorized_keys on every host quarterly. A stale key left behind by a departed contractor is one of the most common initial-access paths we see in incident reviews of Indian SMB environments.Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanKernel and filesystem controls
CIS benchmark sections on kernel parameters (sysctl) and filesystem configuration cover controls that are individually small but collectively close off entire attack classes:
| Control area | What CIS recommends | Why it matters |
|---|---|---|
| IP forwarding | Disable unless the host is a router/gateway | Prevents the box being used to pivot traffic |
ASLR (kernel.randomize_va_space) | Set to 2 (full randomisation) | Makes memory-corruption exploits far harder to weaponise |
| SUID/SGID core dumps | Disable (fs.suid_dumpable=0) | Stops sensitive memory being written to disk after a crash |
/tmp, /var/tmp mounts | noexec,nosuid,nodev | Blocks a very common malware-drop-and-execute pattern |
| ICMP redirects | Disable accepting and sending | Closes a classic man-in-the-middle vector |
| Unused filesystems (cramfs, freevxfs, udf) | Blacklist via modprobe | Reduces kernel attack surface from rarely-audited drivers |
sysctl.conf entries and /etc/fstab mount options, which is exactly why CIS scores them as low-effort, high-value.
nosuid/noexec on /tmp — some legacy application installers and certain database engines write and execute temporary binaries there. Breaking that silently is worse than the vulnerability you were closing.Service minimisation and auditd
Every running service is attack surface, whether or not it is used. A CIS-aligned minimisation pass typically finds:
- Unused package managers' leftover services (rpcbind, telnet, TFTP, NIS) still enabled from a base image.
- Mail transfer agents installed by default but never configured or needed.
- X Window System packages on a headless server.
- Legacy protocols (FTP, rsh, rlogin) that should be replaced with SFTP/SCP and SSH entirely.
auditd, the Linux Audit Daemon, is the control most Indian teams skip because it looks like noise generation rather than defence. It is not — it is the difference between "we think someone accessed that file" and "we have a timestamped, tamper-evident record of exactly which UID read /etc/shadow at what time." CIS benchmark rules for auditd cover watching changes to /etc/passwd, /etc/sudoers, SSH configuration, and kernel module loading, plus ensuring the audit log itself is protected from tampering and rotated before it fills the disk. Under DPDP Act 2023, being able to demonstrate who accessed personal data and when is part of what "reasonable security safeguards" looks like in practice — auditd logs are primary evidence for that.
Patching and automatic updates
A hardened server that isn't patched is a hardened server with a known, unfixed hole. CIS benchmarks include controls for automatic security updates (unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL/Fedora family), and the practical recommendation for most Indian SMB infra is: automate security-only patches, and gate feature/kernel updates through a manual or staged process so a bad upstream release doesn't take down production unattended.
Measuring your benchmark score without breaking anything
The point of a benchmark score is to turn "we hardened the server" into a trend line you can show an auditor or a board. The practical workflow:
- Run CIS-CAT Lite or OpenSCAP against the correct benchmark profile (match OS version and edition exactly — a RHEL 8 profile scored against a RHEL 9 host will produce meaningless results).
- Record the baseline percentage and the specific failing control IDs — not just the headline number.
- Remediate in the risk-priority order above, re-scanning after each phase rather than waiting for a single "big bang" remediation.
- Track score over time in a simple dashboard or spreadsheet; a downward trend after a deployment is your drift signal.
- Re-baseline whenever the OS major version changes, since CIS republishes a new benchmark per release.
Where continuous verification fits
A benchmark score taken once is a snapshot; infrastructure drifts the moment someone SSHes in to "just quickly" install a package or reopen a port for debugging. Continuous vulnerability assessment — automated scanning that re-checks configuration and exposed services on a schedule, not just at audit time — is what keeps a hardened baseline hardened. That is the gap an automated VAPT platform is built to close for Indian businesses that don't have a dedicated infrastructure security team: continuous scanning, drift detection, and DPDP-aligned evidence, delivered with a CERT-In empanelled partner where formal empanelled assessment is required. Dhisattva AI Pvt Ltd built this platform specifically around the reality that most Indian SMB teams need this automated rather than run as a quarterly manual exercise.
If you want to see where your own server fleet stands against a real benchmark baseline, a free VAPT scan will surface the exposed services and configuration gaps a CIS review would also flag — without the multi-day manual engagement. For the compliance side of this, see DPDP compliance and browse the Bachao.AI blog for related hardening and audit guides.