How to Use These Pages¶
Every task page on this site has the same parts, and they're in that order for a reason.
| Part | What it's for |
|---|---|
| The opening paragraph | Why this setting matters: what an attacker does when it's wrong |
| Where | The file, dialog, or command that owns the setting |
| The table | Every setting with its value, its benchmark number, and one line on why |
| Apply | One worked example of the change, done the way an administrator does it |
| Verify | The command that reads the value back, with what its output should look like |
| Example | What the problem looks like on a real image and what the fix was |
| Try it | Things to do on a practice image before you move on |
| Build it | A tool worth writing once you've done the task by hand |
Do it by hand first¶
The Apply sections show one change and then point at the table for the rest. That's deliberate. A page that handed you thirty lines to paste would fix the practice image and teach you nothing, and on a competition image you don't know what you pasted or what to do when it doesn't work. Doing each one by hand, and reading each one back, is how the file paths and command shapes become things you know rather than things you copy.
The verify step is the half people skip. Don't. A change that didn't take is worse than one you didn't make, because you think it's done. Every Verify block shows the expected output; if yours doesn't match, that's the lesson.
Then build a tool¶
Once you've done a task by hand two or three times, you'll know exactly what the tool has to do, and writing it takes ten minutes: the same commands, in a file, with the values you already understand. That file is worth more than any script you could download, because you can read it, fix it, and explain it. The Build it section on each page suggests what that tool should be.
Rules for tools that work in a round:
Read before write. The first version of every tool only reports: list the accounts, print the sysctl values, show the sshd settings. Run it, read the output, decide. A tool that changes things before you've looked is how a required service gets removed.
Take the README as input. Hard-coded usernames are how a script written for last month's image deletes this month's authorized user. Put the authorized users in a file the script reads, and change the file, not the script.
Verify at the end. The tool's last step is the same read-back the page's Verify block does. A tool that can't tell you whether it worked isn't finished.
Keep it small. One tool per page-sized task. A single 500-line hardening script is impossible to debug at hour three; twelve 20-line ones aren't.
Reading the tables¶
Level 1 and Level 2 come from the CIS benchmark; Level 2 means check the README before applying because it can break something. STIG rows come from the DoD standard and are sometimes stricter; the table shows both values and says which to use. The item numbers let you find the full rationale in the benchmark itself.
The README always wins. A table says a service should be off; the README says the machine is that server; the service stays on and gets hardened instead.
Practice images¶
You need a machine you're allowed to break. Install Windows 11 or Linux Mint in VMware, snapshot it, and then break it yourself: add a fake user, put them in sudo, set PASS_MAX_DAYS to 99999, open a port with nc -l, plant a cron job. Then fix it using the pages. Breaking it is half the learning; you'll remember where a setting lives much better after you've set it the wrong way on purpose.