Lion Cipher Lab
Ship privileged-session recordings off the box so root can't erase the evidence — sudo_logsrvd (a Part 2)
- Identity & Access Management
- Intermediate
- 60-75 minutes
- Free · no account required
Why it matters
Part 1 ended on an uncomfortable admission: a session recording that lives on the same machine as the person it is recording is only as trustworthy as that person's restraint, because anyone who reaches real root can delete it. That is the exact gap a real auditor will poke at first. This lab closes it with sudo's own answer — sudo_logsrvd — so the recording is written to a machine the administrator being recorded does not control. That single architectural change is the difference between 'we recorded it' and 'we still have it', and it is what lets you honestly call sudo a Privileged Access…
What you'll learn
- running sudo_logsrvd, sudo's central event and I/O log server
- streaming sudo session recordings off-box with the log_servers sudoers setting
- connecting two Docker containers on a user-defined network so one can log to the other
- proving an audit trail survives deletion of the host it was recorded on
- replaying a remotely-collected session with sudoreplay -d
- recognising that plaintext log shipping exposes keystrokes and output on the wire
- planning a TLS-protected sudo_logsrvd deployment (tls_cert / tls_key / log_server_verify)
- articulating why centralised session logging turns sudo into an auditable PAM control
Steps in this lab
- Where Part 1 left you, and the one wall it hit
- Build two throwaway machines and a private wire between them
- Stand up the collector: run sudo_logsrvd
- Point the client at the collector
- Prove it: run a command on the client, find the recording on the collector
- The whole point: destroy the evidence on the client, watch it survive on the collector
- Do it better: wrap the wire in TLS
- Tear it down, and take the instinct with you