Part 1 locked the doors: updates, SSH, firewall. Part 2 is about the day after — knowing what is running, keeping evidence that survives, and having a plan that does not depend on thinking clearly at 3am.

Inventory what listens, once a month

ss -tulpn
systemd-analyze security sshd    # a scorecard for any service

Anything bound to 0.0.0.0 is visible to the network. If you do not recognize a listener, investigate until you do. The systemd analyzer scores services against common hardening knobs — not a verdict, but a checklist that points at the easy wins.

Logs that the attacker cannot edit

When someone gets root, deleting /var/log is the first thing on their list. Send logs somewhere append-only from day one:

# /etc/rsyslog.d/50-remote.conf
*.* @10.0.0.5:514
systemctl restart rsyslog

Keep 90 days minimum. An incident found three weeks late needs evidence going back further than a week.

The written plan

Decide now, on paper: how you get back in if SSH breaks (console, out-of-band), how you reinstall from scratch, who you call. Store it off the server. Then decide your incident reflex: disconnect the box, preserve the disk, snapshot the logs, investigate on copies.

# when it happens, in this order
1. pull the network cable or block the port
2. snapshot the disk and the logs
3. copy the evidence somewhere safe
4. investigate on the copies, not the live box

Hardening is a habit, and incident response is a habit too. The box that survives is the one where the boring decisions were made before they were needed.