Observe and back up

Notice unexpected change

Establish a baseline for users, services, listeners, packages, scheduled jobs, files, and resource use so suspicious drift becomes visible.

You cannot recognize unusual server behavior without a picture of normal behavior. Keep the baseline small enough to review.

Capture the baseline

Watch new accounts, authorized keys, sudo rules, enabled units, listeners, packages, cron jobs, application files, CPU, disk, and outbound traffic. Save the stable parts as plain text you can diff later:

{
  getent passwd | awk -F: '$3 >= 1000'
  sudo sha256sum /home/*/.ssh/authorized_keys
  sudo ls /etc/sudoers.d/
  systemctl list-unit-files --state=enabled
  sudo ss -lntu
  ls /etc/cron.d/ /etc/cron.daily/
} > baseline-2026-08-03.txt

Store the file off the server, next to your threat-model notes. A baseline stored on the host can be edited by the same attacker it is supposed to expose.

Compare on a schedule

Weeks later, run the same capture into a new file and diff the two:

diff baseline-2026-08-03.txt baseline-2026-09-01.txt
# > 99-deploy-tmp

One new file in /etc/sudoers.d/ you cannot explain — that single line is exactly the needle this habit exists to find.

A new cron job may be a deployment change or attacker persistence. A reviewed baseline provides the evidence needed to distinguish expected work from drift. Configuration management and deployment manifests make unexpected differences easier to see: when the server is built from a script, the script itself is the baseline.

Keep the noise out

Exclude expected volatile data such as temporary files and counters. A smaller, deliberate baseline makes a changed key or unit visible instead of burying it in harmless differences.

The failure mode is a diff of 400 lines of routine package bumps every week. You stop reading it, and that is how the one real change slips through. Drop version numbers from noisy sections, or split packages into their own report reviewed less often.

Save a small baseline of users, keys, sudo rules, listeners, units, packages, and scheduled jobs. Add one harmless unauthorized change and prove the comparison names it without flooding the report with normal log growth.

Lesson completed

Take this course offline

Get every free book, course edition, and software download.

Get the download library →