Hardening a Linux Host
With the surface inventoried and the escalation paths understood, hardening is the concrete configuration that locks a host down: SSH done right, kernel and account settings, filesystem permissions, auditd logging, and a mandatory-access-control layer like SELinux or AppArmor. This turns the CIS-style baseline into specific settings on a Meridian production host.
These are the durable controls that make a foothold small and loud rather than total and silent — and they only work if they are enforced continuously, not applied once and left to drift.
SSH Hardening
SSH is the most-targeted administrative service, so getting it right closes the most common remote-access abuse: key-only authentication with passwords disabled, no root login, a restricted set of allowed users, and modern ciphers. Password SSH with permitted root login is the combination behind countless brute-force compromises; removing both closes that door outright.
Kernel and Filesystem Settings
The baseline flips dozens of kernel and network settings from open to safe — disabling source routing, enabling reverse-path filtering, keeping address-space layout randomization on — and applies least-privilege file permissions with noexec and nosuid mount options on writable filesystems. Individually small, together they remove a long tail of openings that a default install leaves in place.
Mandatory Access Control
SELinux or AppArmor confines a process to what it is supposed to do, so even a compromised service cannot step outside its profile — defense in depth that contains an exploit the application-level controls missed. Disabling it "to make something work," instead of writing a proper profile, throws away a whole containment layer; the right move is to fix the profile and keep it enforcing.
Auditing and Baseline Enforcement
auditd records security-relevant events for Chapter 10's detection, and a configuration-management tool re-applies the whole baseline so hosts stay hardened. Hardening once and letting it drift is the failure mode — configuration erodes as changes accumulate, so the baseline has to be self-healing, and the audit log has to be shipped off-host so an attacker cannot erase it.
SELinux — label-based and extremely granular, but steep to write policy for. Default on RHEL and Fedora.
AppArmor — path-based with simpler profiles, easier to author and audit. Default on Ubuntu and SUSE. Either is far better than none; pick the one your distro defaults to and keep it in enforcing mode.
- Password SSH authentication and permitted root login — the combination behind countless brute-force compromises.
- Setting a hardening baseline once and never enforcing it, so configuration drifts back to open as changes accumulate.
- Disabling SELinux or AppArmor "to make something work" instead of writing a proper profile, removing a whole containment layer.
- Hardening the host but not enabling
auditdor off-host logging, so a compromise leaves no trace for detection or forensics. - Leaving writable filesystems mounted with exec and suid enabled where they are not needed.
- Enforce key-only SSH, no root login, restricted users, and modern crypto; treat SSH as the primary remote-attack target.
- Apply the full sysctl, kernel, and filesystem baseline via configuration management so it is consistent and self-healing.
- Keep SELinux or AppArmor in enforcing mode with proper profiles rather than disabling it.
- Enable
auditdand ship logs off-host for detection and forensics, and re-apply the baseline continuously. - Mount writable filesystems
noexec/nosuidwhere possible to limit what a foothold can run.
Knowledge Check
What SSH configuration closes the most common remote brute-force compromises?
- Key-only auth, with passwords and root login disabled
- Moving the SSH daemon to a high, non-standard port number
- Permitting root login but requiring a much longer password
- Enabling password authentication for every user account
What does a mandatory-access-control layer like SELinux or AppArmor add?
- It confines each process to its profile, containing a compromise
- It fully replaces the need to harden the SSH service on the host
- It transparently encrypts every single file stored on the host disk
- It automatically finds and patches vulnerable software packages
Why must a hardening baseline be enforced continuously, not applied once?
- Configuration drifts back open as changes accumulate
- Hardening baselines are designed to expire after 24 hours
- A one-time baseline permanently locks down all host configuration
- Continuous enforcement is only needed on internet-facing hosts
You got correct