17 — Hardening — The Baseline Everything Starts From

Level: Intermediate · Time: ~22 min · Prerequisites: Lesson 16 — Defence in Depth and Zero Trust

Why this matters

Architecture decides where your walls are; hardening decides whether each brick is actually locked. Left at their defaults, most systems ship with features nobody needs, protocols from the 1990s, credentials printed in the manual and logging that is either off or uselessly noisy. Every one of those defaults is a documented attack path that takes no cleverness to use. Hardening is also the precondition for detection: you cannot alert on "this changed" until you have defined what normal looks like, which is why this lesson underpins Lessons 22, 23 and 44.

What a baseline is

A baseline is a documented, repeatable known-good configuration for a class of system — "every Windows 11 laptop", "every Ubuntu server", "every switch". Three requirements make it useful:

Requirement	What it means	Why it matters
Documented	written down and versioned, with the reason for each setting	so the next administrator does not "fix" it back to the vendor default
Repeatable	applied by a script, an image or a management tool, never from memory	a baseline applied by hand is applied differently on every machine
Known-good	you decided deliberately what is on and what is off	you cannot detect what you have not defined as normal

That third line is the whole argument for this lesson's position in the course. Detection is a comparison: current state against expected state. Without a baseline, every alert is a guess and every anomaly is arguable.

[!IMPORTANT] Patching and hardening are not the same activity and neither replaces the other. Patching closes a specific known vulnerability; hardening removes whole classes of opportunity — unused services, default credentials, weak protocols, unnecessary privilege — that no patch will ever fix, because the vendor considers them supported features.

Frameworks to lean on: do not invent your own

You are not the first person to harden a Linux server, so spend your effort on verification rather than on authoring.

Framework	What it is	How to use it
CIS Benchmarks	per-OS and per-application hardening guides: Linux distributions, Windows, macOS, browsers, databases, containers, cloud platforms	work through the Level 1 profile first — the settings with low impact on function; treat Level 2 as the aspiration for exposed systems
CIS Critical Security Controls	18 prioritised organisational controls covering inventory, data, access, patching, logging and response	use it as your programme's structure and as the language management understands
Vendor and distribution baselines	Microsoft security baselines and compliance toolkits, distribution-specific hardening guides	adopt, then adapt, and record where you deliberately deviate

Two disciplines when you apply a benchmark: adapt, do not paste — a setting that breaks the payroll application will be reverted and drag the rest of the baseline down with it — and record every exception with an owner and a review date. An undocumented exception is how a hardened estate quietly becomes an unhardened one.

Patching: the highest-value hardening activity

Most successful intrusions use a vulnerability with an available fix. Patching is unglamorous, cheap, and the best return available in this entire course.

Stage	What happens	Common failure
Inventory	know what you run, including firmware and appliances nobody thinks of as computers	the device missing from the list is the one that gets exploited
Assess	know which vulnerabilities affect you; an internet-facing critical beats an internal moderate	sorting by score instead of by exposure
Test	apply to a representative system first	testing on nothing, then discovering the breakage in production
Deploy	staged rollout, with a rollback path	one short window for everything, with no way back
Verify	prove the update landed and the version is now correct	"we sent the policy" is not verification

Asset class	Cadence to aim for
Critical vulnerabilities on internet-facing systems	out of band, as fast as your change process allows — days, not months
Endpoint operating systems and browsers	monthly, with automatic updates where possible
Server operating systems	monthly, in a maintenance window with a rollback plan
Firmware and appliances	quarterly, on a schedule somebody owns
Network devices	on a published schedule that is never skipped, because they guard everything else

Three concepts to keep apart:

A vulnerability is a weakness that exists; an exploit is a way to use it; the patch-available window is the period when the fix is public and some systems are still not updated — historically the most dangerous period of a vulnerability's life, because the fix itself announces where to look.
End-of-life software is unpatched by definition. No future security fix exists, so a management system that never sees it reports it as "up to date" while it is permanently vulnerable. Track end-of-life dates in your inventory.
When you cannot patch, decide in writing. The options are compensating controls (isolation on its own VLAN, strict access rules, allowlisting, monitoring), removal of the asset, or accepting the risk with a named owner and a date. What you must never accept is the undocumented version, which is the one that surprises you during an incident.

Secure configuration principles that apply to every system

Change every default credential, and then hunt for the ones you missed — management interfaces, appliances, printers, hypervisors, and the accounts the installer created.
Remove or disable what you do not use: services, sample applications, protocols, accounts, shares, extensions.
Disable obsolete and weak protocols on purpose, by name: SMBv1, TLS 1.0 and 1.1, Telnet, SNMPv1/v2c, plain FTP, and legacy authentication to mail services.
Enable logging and tune it. A default audit policy logs almost nothing that matters, and noisy logging with no central collection helps nobody (Lesson 22).
Restrict who can log in, and from where. Named accounts, no shared logins, no interactive logon for service accounts, source restrictions on administrative interfaces.
Turn on automatic updates where the risk of a bad update is smaller than the risk of a missing one — true for most endpoints, rarely true for production servers.
Remove or protect unnecessary local administrative rights. Most malware needs an administrator to install a service or write to system locations.

Quick wins: the checklists

Linux

# 1. SSH: keys only. Edit /etc/ssh/sshd_config, then: sudo systemctl reload ssh
#    PasswordAuthentication no
#    PermitRootLogin prohibit-password
#    AllowUsers admin ops        # only accounts that need remote access
#    MaxAuthTries 3

# 2. Host firewall, default deny inbound
sudo ufw default deny incoming && sudo ufw default allow outgoing && sudo ufw enable

# 3. Automatic security updates (Debian/Ubuntu)
sudo apt install unattended-upgrades && sudo dpkg-reconfigure --priority=low unattended-upgrades

# 4. Remove what you do not need; question every enabled service
sudo apt purge telnet vsftpd rsh-server
systemctl list-unit-files --state=enabled

# 5. Integrity monitoring and privileged-command auditing
sudo apt install aide auditd && sudo aideinit
sudo auditctl -w /etc/passwd -p wa -k identity_changes

# 6. Setuid binaries and scheduled work: know why each exists
find / -perm -4000 -type f 2>/dev/null
crontab -l; sudo ls /etc/cron.*; systemctl list-timers

# 7. Password quality, lockout, and full-disk encryption at install time (LUKS)
sudo apt install libpam-pwquality && sudo pam-auth-update

Windows

# 1. Built-in firewall on for every profile
Get-NetFirewallProfile | Select-Object Name, Enabled

# 2. Defender enabled, with attack surface reduction rules in block mode
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

# 3. BitLocker with keys escrowed, so recovery does not depend on one laptop
Get-BitLockerVolume | Select-Object MountPoint, ProtectionStatus, EncryptionPercentage

# 4. SMBv1 off; LLMNR and NetBIOS off where possible
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

# 5. Restrict local admin, log PowerShell, apply an allowlisting policy
Get-LocalGroupMember -Group Administrators
#   Group Policy: Windows PowerShell > "Turn on PowerShell Script Block Logging" = Enabled

# 6. Account lockout and password policy; review the audit policy
net accounts
auditpol /get /category:*

Beyond the commands: enforce BitLocker with escrowed keys, remove unnecessary software and browser extensions, apply the CIS baseline with a tool rather than by hand, keep firmware and drivers current, and audit local group membership on a schedule — membership drift is how an attacker keeps access after you think the incident is closed.

Network devices

# Router / switch / firewall, on devices you own:
#  1. Change default credentials; no vendor default admin login survives week one.
#  2. Disable remote management from the WAN side; manage from the inside only.
#  3. Disable UPnP and WPS. UPnP lets software open inbound holes; WPS is broken.
#  4. Update firmware on a schedule.
#  5. Disable Telnet; use SSH and HTTPS for the management interface.
#  6. Restrict the management interface to a management VLAN or a specific source network.
#  7. Send logs to a central collector, not just the device's own memory.
#  8. Review every port-forwarding rule; delete the ones nobody can justify.

line vty 0 4
 transport input ssh          ! one management path, encrypted
 no ip http server            ! plaintext web admin off

Verifying hardening, and how the work gets undone

Verifying rather than assuming

A baseline you have not measured is a belief. The pattern is: assess the configuration, scan the vulnerabilities, fix, re-assess — and keep the output as evidence.

Method	Tool examples	What it tells you
Configuration assessment against a benchmark	OpenSCAP (`oscap xccdf eval --profile <profile-id> --results results.xml <datastream>`), CIS-CAT style scanners, vendor compliance toolkits	how far this host is from the baseline, with the failing items listed
Independent host audit	Lynis (`sudo lynis audit system`)	a hardening score with suggestions and warnings, including things benchmarks do not cover
Vulnerability scanning	the open-source scanners covered in Lesson 30	which known-vulnerable versions are actually running

Scan a sample of every asset class monthly, and always after a major upgrade — upgrades re-enable services, revert configuration files and reinstate default credentials more often than anyone expects.

Common ways hardening work gets undone

Failure	What it looks like six months later
No owner for the baseline	nobody knows the current version, so nobody applies it to new systems
Silent exceptions	a setting disabled for one application in 2023 is still off everywhere, and no one remembers why
Applied once, never re-checked	an upgrade restored the defaults and the monitoring was never told
Hardening without recovery	the backups were never restore-tested, so the hardening works and the business still cannot recover
Verified by policy rather than by host	a console says the settings are applied, while some hosts never checked in

Attack it / Defend it

The attack	How it works	The control that stops it
Default credentials	a login printed in the manual, unchanged since install	change every default credential; audit for the ones you missed
Exploiting a known vulnerability	the patch existed and was not applied	inventory, patch cadence, prioritisation by exposure
Legacy protocol abuse	SMBv1, Telnet or NTLM used because it was still enabled	disable obsolete protocols by name, and test what depends on them
Unused service exposed	a service nobody uses is found by a scanner and exploited	remove or disable what you do not need; scan your own hosts
Living off the land after entry	built-in tools used because there is no allowlisting and no logging	application allowlisting, script-block logging, tuned audit policy
Persistence via scheduled task or cron	a small scheduled job nobody notices	baseline review of cron, timers and scheduled tasks; file integrity monitoring
Local admin rights abused	the user's own account can install services and drivers	remove local admin, separate admin accounts, just-in-time elevation
End-of-life system or appliance	no fix will ever exist, so the vulnerability is permanent	isolate with compensating controls, or replace on a dated plan

Key takeaways

A baseline is a decision written down and applied repeatedly. You cannot detect what you have not defined as normal.
Use CIS Benchmarks and the CIS Critical Security Controls rather than inventing your own; start at Level 1, adapt, and document every exception with an owner.
Patching is the highest-value hardening there is — most intrusions use a known vulnerability with an available fix, and the patch-available window is the most dangerous period.
Defaults are attacks. Unused services, weak protocols and default credentials are not vulnerabilities to be discovered, they are invitations.
Hardening is verified, not assumed — and never harden without testing recovery, because a secure system that cannot be restored is still an outage.

Check yourself

Why can you not build good detections before defining a baseline, and which later lessons depend on this?
A critical vulnerability affects an internal server and an internet-facing one. Which do you patch first tonight, and why is the score alone not decisive?
Name four defaults you would change on a newly installed Linux server, and what each removes.
Your file server runs an application that only supports SMBv1. What are your three legitimate options, and which one requires a written risk acceptance?
Which tools would you use to prove a hardened Ubuntu host is still hardened, and what would you compare the output against?