Summary
Further Reading
Books, references, and documentation to go deeper on Linux security.
This foundation is deliberately hands-on and opinionated, which means it leaves a lot out. The sources below are where you go to fill the gaps: the authoritative documentation behind every tool used here, the books that explain the systems underneath, and the places to watch so you learn about a vulnerability before an attacker uses it against you. The habit worth building is going to the primary source (the man page, the vendor doc, the standard) rather than a blog summary, because security details are exactly where second-hand explanations go stale.
Documentation and man pages worth reading end to end
Most man pages are references, but a handful read like well-written guides and repay a cover-to-cover pass.
| Source | Why it is worth it |
|---|---|
man systemd.exec | The definitive list of sandboxing directives behind Systemd Hardening |
man auditctl and man audit.rules | Full rule syntax and field filters for Auditd |
man journalctl and man systemd-journald.service | Every filter and the persistence and forwarding options for System Logs |
man sysctl.conf and the kernel Documentation/admin-guide/sysctl tree | Authoritative meaning of every tunable in Boot & Kernel Hardening |
| Ubuntu Security documentation (help.ubuntu.com and ubuntu.com/security) | Vendor guidance on Livepatch, Ubuntu Pro, and CVE handling |
| Arch Wiki “Security” and “systemd” pages | Distribution-neutral, unusually thorough practical explanations |
| CIS Ubuntu Linux Benchmark (cisecurity.org) | The control-by-control standard behind the CIS Benchmark page |
| NIST SP 800-123 (Guide to General Server Security) and SP 800-92 (Log Management) | The standards framing that ties the whole foundation together |
The CIS benchmark PDF in particular is worth downloading and skimming once end to end, because each control carries a rationale you can reuse when justifying a change to someone else.
Books and long-form resources
- “How Linux Works” by Brian Ward: the best single explanation of the boot chain, systemd, and the kernel interfaces this foundation hardens.
- “The Linux Programming Interface” by Michael Kerrisk: deep coverage of syscalls, capabilities, and namespaces, which is the machinery underneath both systemd sandboxing and auditd.
- “Linux Basics for Hackers” by OccupyTheWeb: an approachable offensive counterpart that shows why the defenses here matter.
- “Practical Linux Forensics” by Bruce Nikkel: turns the logging and auditing group into a full investigative workflow.
A note on reading man pages effectively: use apropos to discover related pages, read the SEE ALSO section at the bottom (it maps the neighborhood of a topic), and prefer the section number when a name collides, for example man 5 sysctl.conf for the file format versus man 8 sysctl for the command. The section numbers themselves are worth memorizing: 1 is user commands, 5 is file formats, and 8 is administration commands, which together cover almost everything in this foundation.
Communities and news sources to stay current
Security is a moving target, so staying current is part of the job, not an extra.
- The Ubuntu Security Notices feed and the Debian Security Advisories list, which tell you when a package you run gets a fix.
- The oss-security mailing list, where many vulnerabilities are first discussed in the open.
- The CVE and NVD databases, for looking up a specific advisory referenced in Patch Management.
- LWN.net, for careful, technical write-ups of kernel and userspace security changes.
- The r/netsec and Hacker News feeds, useful as a firehose as long as you follow links back to primary sources.
Practical Guidance
- Go to the primary source (man page, vendor doc, or standard) before a blog post, since security details are where summaries go out of date.
- Read
man systemd.execand the CIS Ubuntu Benchmark cover to cover once, as both double as structured hardening guides. - Subscribe to the Ubuntu Security Notices feed so you learn about a fix for software you run without having to check manually.
- Keep one deep book (Kerrisk or Ward) on hand to answer the “but why does this work” questions the how-to pages skip.
- Follow news feeds as a firehose but always click through to the CVE, advisory, or commit before acting on anything.
- Revisit these sources periodically, because tools, defaults, and threats all change between readings.