Skip to content
Kovant
FRSign in

Server hardening: where to start (CIS, ANSSI)

Hardening means shrinking the attack surface, in the right order

A server hardening service comes down to closing everything that has no reason to be open: unused services, over-broad access, permissive defaults. The principle is simple — what you close can’t be exploited — but doing it takes method. Diving into a 200-line checklist with no plan is the surest way to break a production application.

Two reference frameworks set the bar: the CIS benchmarks (Center for Internet Security) and the ANSSI recommendations (the French national cybersecurity agency). Here’s where to start, in the order that maximises security while minimising the risk of breakage.

Step 0: capture a baseline before touching anything

Before the first change, photograph the server’s current state: listening services, accounts, scheduled tasks, firewall rules, package versions. Without that baseline you won’t know what you changed or how to roll back. It’s also what lets you, later, detect configuration drift.

Step 1: access — SSH and accounts

This is the front door. In order:

  • SSH by key only, with password authentication and direct root login disabled.
  • Account review: remove unused accounts, apply least privilege, log sudo.
  • fail2ban or CrowdSec to block brute-force attempts.

Test your key-based access before you turn off passwords — the classic mistake is locking yourself out.

Step 2: the network — firewall and exposure

  • Default-deny firewall (nftables): only the ports you genuinely need are opened.
  • Service minimisation: any daemon listening for no reason is stopped and disabled. An honest ss -tulpn often turns up surprises.

Step 3: the kernel and the system

  • Hardened sysctl (network protections, ASLR, ptrace restrictions).
  • Security updates automated and governed — a server hardened once and never patched is vulnerable again within weeks.
  • auditd enabled to log sensitive events, ideally paired with session recording (tlog) for traceability.

Step 4: containers, if you run them

The Docker daemon is an often-forgotten surface: exposed socket, containers running as root, over-broad capabilities. Hardening the host without hardening Docker leaves a gaping hole.

Step 5: hold the baseline over time

Hardening is not a one-shot. Configuration drifts: a patch, a new service, a forgotten manual change. That’s why you monitor the gap against the baseline and remediate as you go. Hardening applied once and then forgotten for six months is worth very little.

FAQ

CIS or ANSSI, which should I pick? They’re complementary. Apply the CIS benchmarks and the ANSSI recommendations to your context, and document every accepted exception.

Could hardening break my applications? That’s the risk, which is why you test in staging and keep a rollback. The goal is to reduce the surface, not to take your services down.

How is this different from antivirus or an EDR? Hardening is prevention (reducing the surface); an EDR does detection and response. They complement each other, they don’t replace each other.

In short

Start by capturing a baseline, secure access, close the network, harden the kernel and containers, then monitor drift. In that order, you gain the most security for the least risk. If you’d rather hand the pass and the follow-up to a team — tested in staging, with a before/after report — our CIS/ANSSI server hardening service does it at a fixed fee per server, with a frozen baseline and drift monitoring included.