Linux Incident Response and Hardening: Investigation Workflow & Baseline Controls
Every earlier chapter in this module taught a skill in isolation: reading accounts, parsing logs, spotting persistence, reading process and network state, catching shell tradecraft, securing containers. This closing chapter pulls all of it into one repeatable investigation workflow, then covers the baseline hardening that prevents a repeat.
Linux Live Response
The Digital Forensics, Chapter 1 order of volatility applies to a live Linux host the same way it applies to any system: capture what decays fastest first. On a suspected-compromised host that is still running, that ordering shapes exactly what to pull before anything else changes state.
| Priority | What To Collect |
|---|---|
| 1 (highest volatility) | Running process list and process tree, so parent/child relationships aren't lost when a short-lived process exits. |
| 2 | A full memory (RAM) image, if the investigation can support it. It is lost entirely at power-off and captures process, network, and injected-code state as a single point-in-time snapshot, matching where memory sits in the Digital Forensics module's order of volatility. |
| 3 | Active network connections, since a live C2 socket or exfil connection disappears the moment it closes. |
| 4 | Currently logged-in users and their sessions, before a session ends and that context is gone. |
| 5 | Loaded kernel modules, to catch a rootkit module before a reboot unloads it. |
| 6 (lowest volatility) | Disk-resident evidence: logs and persistence locations, both covered in earlier chapters of this module, which survive a reboot. |
A live-response collection script or tool automates this capture in one pass, so the order is enforced consistently instead of depending on an analyst remembering it under pressure.
Linux Incident Response Workflow
A live-response capture on its own is not an investigation. It feeds into a workflow that decides whether the host is actually compromised and what happens next.
Common Linux Incident Patterns
Recognizing the pattern points straight at which chapter's skillset to apply first, instead of starting the analysis from scratch every time.
| Pattern | Where To Look |
|---|---|
| Web shell dropped on a server | Persistence locations from chapter 4, plus unexpected child processes of the web server from chapter 5. |
| SSH brute-force or compromised credentials | Auth events from chapter 3, plus account changes from chapter 2. |
| Cryptomining malware | Unusual sustained CPU use visible in process state from chapter 5. |
| Container escape | Container and Docker security controls from chapter 7. |
A web server spawning a shell it never should, or CPU pegged at 100% with no obvious cause, are both starting points, not conclusions. They tell the analyst exactly which earlier chapter's technique to reach for next.
Hardening Baseline
Hardening is what turns a one-time recovery into a durable fix. Each control below closes a specific gap this module already covered.
| Control | What It Does |
|---|---|
| SSH hardening | Key-based authentication and disabling direct root login, cutting off the most common brute-force and credential-stuffing path. |
| Least-privilege sudo rules | Narrows chapter 2's sudo risk down to only the specific commands a role actually needs. |
| Mandatory access control (SELinux or AppArmor) | Confines what even a compromised process is allowed to do, beyond what standard file permissions restrict. |
| auditd configured for execve and file-access monitoring | Closes the shell-history-tampering gap from chapter 6 by logging execution independent of any shell's own history file. |
| Timely security updates | Closes known kernel and package vulnerabilities before chapter 7's escape techniques can use them. |
How This Module Fits Together
Every chapter in this module builds toward the same outcome: a Linux investigation that's actually defensible, not a guess backed by a single log line.
No single chapter's skillset catches everything on its own. An attacker who covers their tracks in the shell history from chapter 6 still leaves auth events in chapter 3's logs and a persistence mechanism from chapter 4. The layered approach, account discipline, logging, persistence awareness, process and network visibility, shell tradecraft, container isolation, and a repeatable IR workflow, is what makes a Linux investigation stand up to scrutiny instead of resting on one lucky find.
Key Takeaways
- Live response on a Linux host follows order of volatility: process list and tree, network connections, logged-in sessions, kernel modules, then disk-resident logs and persistence artifacts.
- The IR workflow runs triage, containment (network isolation, not necessarily power-off), collection, analysis, and recovery and hardening.
- Common incident patterns, a web shell, SSH compromise, cryptomining, or container escape, each point to a specific earlier chapter's skillset.
- Hardening controls include SSH hardening, least-privilege sudo, a mandatory access control framework like SELinux or AppArmor, auditd execve and file monitoring, and timely security updates.
- SELinux and AppArmor add a policy layer beyond standard discretionary permissions, confining what a compromised process can do even as its own user.
- No single chapter in this module catches every incident alone; the combination of accounts, logging, persistence, process/network visibility, shell tradecraft, and container security is what makes an investigation defensible.
Knowledge Check
Click an answer to reveal the explanation.
During live response on a running Linux host, which of these should generally be collected first, and why?
What does a mandatory access control framework like SELinux or AppArmor add beyond standard Linux file permissions?
An analyst finds a web server spawning an unexpected child process. Which chapters' skillsets does this incident pattern point to first?