System hardening

Configuring a system so that fewer things can go wrong on purpose: remove what isn’t needed, restrict what is, and log what happens. It’s the layer of defensive-security that runs before any attacker shows up, and it’s mostly unglamorous configuration — trimstray’s guide is a long list of settings with reasons attached.

The shape of the work

The guide’s chapter structure is the practice in miniature: rationale → solution → comments → resources. Each control names the threat it addresses before it names the setting, which is the part that distinguishes hardening from cargo-culting a config file. A control you can’t justify is a control you’ll revert the first time it breaks something.

Typical surfaces: boot and kernel parameters, filesystem mount options, package and service minimization, account and authentication policy, network stack and firewall defaults, logging and audit configuration, and integrity checking. The guide targets RHEL 7 / CentOS 7, which dates it — but the categories outlive any distribution version.

Why it’s benchmark-shaped

Hardening is where security meets audit, so the controls get published as benchmarks (CIS, STIG) and checked by tooling (OpenSCAP) rather than argued case by case. That’s a real strength — a documented baseline you can measure drift against — and a real weakness: a system can be fully compliant and still trivially compromised through the application running on it, which no host benchmark inspects.

The automation seam

A written guide tells a human what to change; a configuration framework makes it repeatable. The guide points at the DevSec Hardening Framework (dev-sec.io) for that, which is where hardening stops being a document and becomes code — and where it acquires the ordinary problems of infrastructure code: drift, exceptions, and settings nobody remembers enabling.

Related

security-benchmark · practical-linux-hardening-guide · defensive-security · security-operations-center