The previous lesson left Nimbus's code defending itself. But that code runs on something: servers with packages, services, users and permissions, and around forty laptops spread between the Valencia office and the homes of half the staff. That is where the python -m http.server nobody switched off has been alive since 01-04; that is where the unencrypted machines from 04-03's KPI are (92.3 % against a target of 98 %); and that is where the accounts with administrator privileges nobody needs are. This lesson applies 01-04's surface reduction to the operating system and turns "our servers are properly configured" into a baseline that is written down, applied by a machine and verified every week.

1. What hardening is and what a baseline is
2. Reference standards: CIS Benchmarks and STIGs
3. Assess before you touch: lynis and OpenSCAP
4. Hardening the Linux server, step by step
5. Hardened SSH, directive by directive
6. auditd, fail2ban and automatic updates
7. Patch management as a process
8. The employee's endpoint
9. Antivirus versus EDR
10. Device management, BYOD and osquery
11. Automating and verifying the baseline
12. The legacy system that cannot be hardened

Hardening is reducing a system's attack surface: removing what is not used, closing what should not be open, limiting what each account can do and leaving a record of what happens. It is the application to the operating system of the principles from 01-03 — least privilege, secure defaults, defence in depth — and of the surface reduction from 01-04.

A freshly installed system is optimised to work in any scenario, not in yours. It comes with active services you will never use, generous permissions and convenient configurations. Hardening is the difference between the generic and yours.

The idea that holds everything else up is the baseline: a set of security configurations, written down, versioned and automatically applicable, that defines how every Nimbus server and every Nimbus laptop must be. Without a baseline three things happen: every machine ends up different, nobody knows which one is correct, and configuration drift is invisible.

There is no need to invent the baseline: public, detailed catalogues already exist.

How they are really used, which is not how it is usually done. An Ubuntu benchmark has more than 300 controls; applying them all blindly produces, almost certainly, a server that will not boot or an application that stops working. The correct procedure has four steps:

1. Assess first on a real system and see the current distance (§3).
2. Filter by level and by role: all of Level 1; from Level 2, only what adds value in your context. A control about printing services does not apply to an API server.
3. Test in preproduction, in small batches and including a reboot, because many controls only show their effect on restart.
4. Document the exceptions with reason, owner and expiry date, in the register from 04-02. A control not applied and not documented is a silent deviation; documented, it is a decision.

The benchmark is a starting point, not a goal. 100 % conformity with unencrypted personal data and no verified backups is a worse posture than 80 % with the priorities properly chosen.

• lynis --quick does not wait for confirmation between sections: that is what makes it runnable from cron. It gives an indicative score and a prioritised list of suggestions.
• oscap evaluates against a formal profile (here, CIS Level 1 for a server) and produces a machine-readable XML plus a human-readable report. It is the tool that generates auditable evidence; lynis is the one used day to day.

How to read this output without wasting time. The hardening index (58) is not the metric that matters: it is there to measure progress, not to show off. What matters are the three lines marked with ! in the services and SSH sections, because they describe real exposure: the port-8000 http.server is still there 94 days on, root can log in over SSH and passwords are accepted. Those three get fixed today; the 23 suggestions are spread over weeks.

Minimise packages and services. Every active service is a surface and a stream of patches.

The golden rule: if you do not know why it is there, switch it off in preproduction and watch for a week. It is faster and more honest than investigating the origin of every service.

Users and sudo with least privilege. No shared accounts — one named account per person — no passwords for services (system accounts with nologin), and sudo scoped per command where possible instead of ALL. Every use of sudo is logged and that log feeds the detections from 05-02.

Permissions and mounts. Mount options are a cheap and very effective control:

noexec prevents binaries from being run off that partition, nosuid cancels the privilege-escalation bit and nodev blocks device files. noexec on /tmp cuts off at the root the most common pattern after an intrusion: downloading a tool to /tmp and running it.

Kernel parameters. sysctl hardens the network stack and the kernel's behaviour: disabling packet forwarding on machines that are not routers, ignoring ICMP redirects, enabling syncookies against SYN floods, restricting access to dmesg and to kernel traces, and enabling kernel.randomize_va_space=2 for address space randomisation. They are declared in /etc/sysctl.d/60-nimbus.conf and applied with sysctl --system.

AppArmor and SELinux are mandatory access controls: they limit what a process can do even when it runs as root. If the Nginx process is only allowed to read its configuration and write its logs, a compromise of Nginx cannot read /etc/shadow. On Ubuntu, AppArmor comes enabled and with profiles for the usual services; the recommendation for Nimbus is never to disable it — the first thing many people do when something does not work — and to learn to read its denials in the log.

SSH is the administration door and therefore the preferred target.

It is validated with sshd -t before reloading the service and, very importantly, a second session is tested before closing the first: an error in this file leaves the server unreachable.

auditd records system calls and file accesses. It is configured with a few well-chosen rules, because logging everything produces gigabytes of nothing useful:

-w watches a path (-p wa = writes and attribute changes), -k tags the event so it can be searched for, and -e 2 freezes the rules: not even root can modify them without a reboot, which stops an attacker quietly disabling the auditing. These events feed detections D-07 and D-08 from 05-02 directly.

fail2ban reads the logs and temporarily blocks IPs that fail repeatedly. It is useful, but it is worth placing it correctly: with SSH reachable only from the bastion host and with no password authentication, fail2ban is the second line, not the first. Where it does add real value is in front of the API, complementing the rate limiting from 05-05, and it is one of the automatic responses 05-02 classified as safe because they are reversible.

Automatic security updates. On Nimbus's servers unattended-upgrades is enabled for the security repository only, with a night-time window, automatic reboot disabled and e-mail notification. The reasoning: the probability that a security patch breaks something is low; the probability that a server left unpatched for six weeks gets exploited is not. Packages critical to the service (the database) are excluded and patched in a planned window.

Patching is not running apt upgrade: it is a process with an inventory, deadlines and verification, and it rests on the P0-P4 priority policy from 05-01.

The real trade-off is between availability and risk, and it is worth stating honestly: patching may break the service for a few minutes; not patching may cost you the service for days. The way to resolve it is not to pick a side, but to reduce the cost of patching: reproducible environments, zero-downtime deployment, and an automatic smoke test confirming that the application is still alive after the window. When patching costs twenty minutes instead of a whole night, the dilemma disappears.

And the special case: the pending reboot. Nimbus treats it as a finding with an owner and a deadline, not as a nuisance. needrestart shows which services are still using old libraries, and that list is reviewed in every window.

Forty laptops, half of them outside the office. It is asset A-14 and the starting point of most real intrusions.

The account without administrator privileges deserves a paragraph of its own, because it is the control with the best cost/effectiveness ratio in the whole lesson and the one that generates the most resistance. Without privileges, most malware cannot install itself, cannot persist across reboots, cannot disable the antivirus and cannot read the credentials of other accounts on the machine. The usual objection — "developers need to install things" — is almost always solved with user-space package managers, containers and a one-off elevation path with logging. The real objection that remains is cultural, and it is handled by explaining it, not by imposing it.

Why EDR matters, stated without the marketing: the antivirus answers "is this file bad?", and the EDR answers "what has happened on this machine?". When Sara's laptop turns out to be compromised, the antivirus says it quarantined something; the EDR shows that an attachment opened PowerShell, that PowerShell downloaded a file, that the file was copied into the start-up folder and that it opened a connection to a domain registered three days ago. The first closes a ticket; the second lets you respond according to 04-05 and answer the only question that matters: how far did it get?

Recommendation for Nimbus with 18,000 €/year: Microsoft Defender (included) as the antivirus + the Wazuh agent as the visibility and response layer. It covers 80 % of what a commercial EDR gives at zero licence cost, in exchange for hours of Lucía's time. When the budget grows, a managed EDR is the first purchase from this lesson.

MDM (device management) is what makes everything above applicable to forty machines without visiting each one. It applies the baseline, enforces encryption and locking, distributes updates, installs agents and — most importantly — allows remote wiping of a lost machine and continuously checks that the policy is still applied. For Nimbus, the realistic option is the MDM included with its identity/office provider, plus the Wazuh agent.

BYOD (personal devices) is where the technical meets the legal and the employment side. Nimbus cannot wipe Sara's personal phone or inspect her photos. The correct approach, aligned with POL-04 (Acceptable Use), is: access to e-mail and corporate tools only from the device's managed work container, with verifiable minimum requirements (PIN lock, encryption, up-to-date system, no root/jailbreak), remote wiping limited to corporate data, and prior written information about what the company can and cannot see and do. (Legal validation note: in Spain, controls over staff devices require prior notice and proportionality; the BYOD policy is best reviewed legally before it is applied. This is developed in 06-03.)

osquery turns the estate into an SQL database you can ask questions of. It is the tool that answers 04-03's metrics with data rather than estimates:

The third query, run against the servers, is the one that would have found the http.server on day one. And all of them, scheduled and shipped to Wazuh, turn "we think 98 % is encrypted" into an exact, dated number, which is precisely what 04-03 requires as evidence.

Why it is not applied by hand. Configuring thirty directives on a server takes two hours, it is done differently the second time, there is no record of what was changed and it cannot be repeated when the server is recreated. The baseline is applied with Ansible (or an equivalent) or baked into a golden image.

Three properties make this file valuable. It is idempotent: it can be run a thousand times and the result is the same, so it serves both to apply the baseline and to correct drift. It is the documentation, because it describes exactly how the fleet is configured, with no way of going out of date. And it is versioned, so every change to the baseline goes through review like any other code.

The natural evolution is immutable infrastructure: instead of modifying servers, you build an already hardened image and the servers are replaced on every deployment. It eliminates drift by definition — no server lives long enough to deviate — and, as an enormous security benefit, it destroys any attacker persistence on every deployment. For Nimbus's containerised API this is already the case, and it is developed in 05-07.

Verifying. The baseline is not applied and forgotten: it is checked.

--check --diff is the gem: it runs the playbook without applying anything and shows what would deviate from the baseline. If the result is not empty, somebody touched something by hand and you need to find out who and why. It is completed with file integrity monitoring (Wazuh FIM) over /etc, /usr/bin and the SSH keys, whose alerts go to the 05-02 channel as one more detection: an unauthorised change to a server's configuration is a sign of compromise, not a curiosity.

There is always one: a server with an application that only works with an old version, a supplier's machine you are not allowed to touch, a device controlling something physical. Denying it does not help; the correct answer is to isolate and compensate:

• Isolate it in its own network zone (05-04), with minimal ingress and egress rules: if it cannot browse, it cannot receive orders or exfiltrate.
• Compensate with controls around it: a reverse proxy with a WAF in front, authentication at the previous layer, exhaustive logging of everything that goes in and out.
• Monitor more, not less: being the most fragile system, it is the one that needs the most sensitive detections.
• A specific backup and recovery plan, because it will be the hardest to rebuild.
• Document it as an accepted risk with an expiry date in the register from 04-01, with a review date and, if possible, a replacement budget.

Nimbus has its own case: A-22, the preproduction environment. It is not that it cannot be hardened; it is that nobody has done it. The correct decision is to apply the same baseline as production — it costs the same, because it is automated — and to settle the inventory's "to be reviewed" classification once and for all.

• Applying a whole benchmark blindly. You break the service, lose the team's trust and the hardening project dies in the first week.
• Changing the SSH port and believing it is a control. It reduces noise; it stops nobody. The control is that it is only reachable from the bastion host.
• Reloading sshd without validating and without a second session open. It is the classic way to lock yourself out of a production server.
• Disabling AppArmor or SELinux "because something does not work". You adjust the profile, you do not switch off the control.
• Patching without rebooting. An updated kernel that has not been rebooted is still vulnerable, and the patching metric lies.
• Leaving everybody with local administrator privileges. It is the control that stops the most attacks and the one most often postponed.
• Applying the baseline by hand. It is not repeatable, it leaves no record and it guarantees no machine is like any other.
• Tip: start by measuring. Run lynis on the three servers today: in twenty minutes you will have the prioritised list of what needs doing, for free.
• Tip: a weekly --check --diff in CI. It is the cheapest way to detect configuration drift and unauthorised change.
• Tip: the first osquery query you should run is the disk encryption one. It turns an estimated KPI into an exact number, and it usually holds a surprise.

Lucía runs lynis against api-prod-1 and gets, in addition to the index of 58, these findings:

1. Rank the eight findings by priority, justifying the criterion.
2. State which are fixed today and which require a maintenance window, and why.
3. Which of them is not resolved on this server, but at another layer?

Marta approves a budget to get the 40 laptops in order. Define the workstation baseline:

1. Ten controls with their rationale, ordered by impact.
2. For each one, how it is automatically verified that it is still applied.
3. What you would do with the developer who demands permanent administrator privileges.

The weekly ansible-playbook --check --diff returns this for api-prod-2:

Interpret each difference, state which is most serious and what actions you would take.

Exercise 1

(1) Ranking by priority, applying the criterion from 05-01 — exposure and exploitability first, not nominal severity:

(2) Today versus a window. Fixed today, with no outage: the http.server (kill the process and remove the unit), the SSH directives (reloading sshd does not cut existing sessions, always validating first with sshd -t and with a second session open), auditd, the local firewall — being careful to apply the rule allowing SSH before the default-deny policy — and the umask. Requiring a maintenance window: the 2 kernel updates, because they need a reboot and without it the vulnerability is still alive; and the separate /tmp partition, which means repartitioning the disk. The remaining 12 updates can be applied in working hours if they do not affect active services, although it is best to group them into the Tuesday window.

(3) The finding not resolved here is, strictly speaking, the exposure of port 8000: removing the process is the immediate fix, but the underlying question — why was an unauthorised service reachable from the Internet? — is answered in 05-04, with the security group that should only allow 443 from the load balancer. The complete answer combines two layers: hardening removes the service, and the network stops a future service being reachable. That is exactly the point of the defence in depth from 01-03.

Exercise 2

(1) and (2) Workstation baseline:

Verification is what separates this list from a decorative document: every control has a query that produces a dated number, and that number is the evidence 04-03 asks for and that a customer or an auditor will request in 06-04.

(3) The developer who asks for permanent administrator rights. You do not simply say no, nor simply say yes. First you find out the specific use case — usually installing dependencies, using containers or debugging — because almost all of them are covered without permanent privileges: package managers in user space, Docker with the right group, and pre-approved tools installed by the MDM. For whatever is left, you offer one-off elevation with logging: a route that grants privileges for a limited time, leaves a trace of what was done and does not survive a reboot. It is the same just-in-time model as A-19 applied to the workstation. If an irreducible case still remains, it is documented as an exception with an owner and an expiry date (04-02), compensated with reinforced monitoring on that machine, and reviewed every six months: almost all exceptions of this type stop being necessary before the first review.

Exercise 3

First difference — PasswordAuthentication yes on the server. Somebody disabled a baseline control by hand on a production server. It is the most serious item in the report for three reasons: it reopens password authentication, and with it brute force and credential stuffing; it is exactly what an attacker would do to guarantee a way back after losing their original access; and it is an unauthorised change, that is, an indicator of compromise until proven otherwise. Immediate actions: do not revert it silently. First, check the auditd log (-w /etc/ssh/sshd_config -p wa) to find out who and when; review successful password-based SSH logins since that moment; and only then reapply the baseline. If no legitimate explanation with a ticket turns up, it is treated as an S2 incident under 04-05.

Second difference — support-tmp in AllowUsers. A temporary account — the name gives it away — with SSH access to production, which outlived the reason that created it. It is the same family of problems as A-19's exception with no expiry and as the http.server: the temporary thing that stays. You check who uses it, when it was created, whether it has a key associated and what it did; you delete the account and not just the AllowUsers line; and you check whether equivalent accounts exist on the other servers.

Third difference — auditd rules absent. The file does not exist on api-prod-2. It is less alarming than the previous two because it may simply be that the machine was created before the rule entered the baseline, but it has a serious consequence for this very exercise: without auditd, the investigation of the first point may have no data, which is why you should check first whether the file ever existed. Action: apply the complete baseline and verify that it is present on the other servers.

Cross-cutting conclusion of the exercise. All three findings appeared because there was an automated baseline and a weekly check. Without --check --diff, the PasswordAuthentication yes would have stayed invisible until the next pentest or until somebody used it. That is the whole argument of the lesson: hardening is not applying configurations, it is keeping a difference equal to zero.

You have applied to the operating system the surface reduction that module 1 set out in the abstract. You know what hardening is and, above all, what a baseline is: a set of configurations written down, versioned and applicable by a machine, without which every server ends up different, nobody knows which one is correct and drift is invisible. You know the CIS Benchmarks and the STIGs, and the honest procedure for using them — assess, filter by level and role, test in preproduction and document exceptions — along with the warning that avoids the most common failure: applying 300 controls blindly breaks the service and kills the project in the first week. You know how to assess before you touch with lynis and OpenSCAP, and to read their output looking for real exposure rather than showing off an index.

You have the complete hardening of the Linux server: minimising services — where the python -m http.server from 01-04 finally dies, by removing the unit and not just killing the process — named accounts and scoped sudo, mounts with noexec, nosuid and nodev that cut off at the root the download-and-run pattern from /tmp, kernel parameters, and AppArmor/SELinux with the rule of tuning them rather than switching them off. You have a command of sshd_config directive by directive, with PermitRootLogin no, no passwords, Ed25519 keys only, AllowUsers as an allowlist, idle timeouts, LogLevel VERBOSE to record the fingerprint of the key used, and the warning that changing the port is not a control: what is a control is being reachable only from the bastion host. You know how to configure auditd with a few well-chosen rules and -e 2 to freeze them, where to place fail2ban as the second line, and how to enable automatic security updates with judgement.

You can handle patch management as a process — inventory, intake, P0-P4 prioritisation, testing, window, reboot and verification — with the key that dissolves the availability-versus-risk dilemma: reducing the cost of patching until it takes twenty minutes. You have the endpoint baseline with its eight controls, headed by the one that stops the most attacks and generates the most resistance — the account without administrator privileges — and you can distinguish antivirus from EDR by the question each one answers: "is this file bad?" versus "how far did it get?". You know what MDM contributes, how to approach BYOD in a way compatible with POL-04 and with the law, and how to use osquery to turn estimates into dated numbers, including the query that would have found the http.server on day one. And you take away what makes all of the above sustainable: automating with Ansible in an idempotent, versioned, self-documenting way, the evolution towards immutable infrastructure that destroys any persistence on every deployment, and the weekly verification with --check --diff, because hardening is not applying configurations but keeping a difference equal to zero. With the legacy system, the answer is to isolate, compensate, monitor more and document the risk with an expiry date.

Notice the last idea, because it is the bridge. Immutable infrastructure, golden images and the API's containers have been appearing throughout the lesson as the best way to apply a baseline, and yet classic hardening does not cover them: a container is not a virtual machine, it is not patched, it is rebuilt; and the cloud account that runs it has a surface of its own that no lynis looks at. That is where most breaches happen today, and not through an exploit but through a configuration error: a public bucket, a permission policy that is too broad, backups living in the same account as production. In Cloud and Container Security (05-07) we close the course's technical plan: shared responsibility on the technical side, identity as the new perimeter, bucket A-02 properly configured at last, network and backups isolated by account, cloud logging and alerting, automated posture with prowler and checkov, secure images with their Dockerfile before and after, signing with cosign, running with minimal capabilities and runtime detection with Falco.