security-audit

The rule that outranks the checklist

Inspection is read-only and runs freely. Every change is explained first — including how it could lock you out — and waits for a person, because the mistakes here are the ones that end your own access: a firewall default-deny before the SSH rule is in, PasswordAuthentication no before a key is proven to work, a permission change on /etc that breaks sudo. Use ask_human for the change itself, not for the reading.

Everything below runs through run_command (visible, exit code returned) or the dedicated tools. There is no quiet path and you should not want one — an audit whose steps are not on the record is not an audit.

Read first — this whole block is safe and needs no confirmation

• Who has access: run_command "getent passwd | awk -F: '$3>=1000'", then the sudoers: read_file /etc/sudoers and list_directory /etc/sudoers.d.
• SSH posture: read_file /etc/ssh/sshd_config — look for PermitRootLogin, PasswordAuthentication, PermitEmptyPasswords, X11Forwarding. Read ~/.ssh/authorized_keys for every human account.
• What is listening: run_command "ss -tulpn". Every listening port is a question: what is it, does it need to face the network, is it meant to be there. Cross-check with list_processes.
• Firewall state: run_command "ufw status verbose" or run_command "nft list ruleset".
• Pending updates: search_packages / run_command "apt list --upgradable", and whether unattended-upgrades is on.
• SUID/SGID surface: run_command "find / -perm -4000 -type f 2>/dev/null" — a long read, so run it as a job if it drags.
• World-writable and unowned files in sensitive trees; ~/.ssh perms (700, keys 600); /etc/shadow is 640 root:shadow.

Summarize what you found and flag concerns before proposing a single change.

The change half — explain the lock-out, then ask

Order matters and each ordering is a way people lock themselves out:

• Firewall: add the allow rules (SSH first) before setting default-deny. State the port you are keeping open and confirm you can still reach it.
• SSH hardening: prove key auth works in a second session before disabling passwords or root login. Never both in one step.
• Updates: a kernel or libc upgrade may need a reboot the person did not plan for — say so. Prefer a job (job_start) and read the result.
• fail2ban / firewall daemons: install via install_packages, enable via service_control, then read the status back and prove the rules loaded.

After any change, re-run the matching read step and show the before/after. A hardening that returned ok and did not take is the worst outcome — the box looks secured and is not.

Scope

Audit and harden the machine you are on, and machines you were explicitly asked to reach (ssh_*). Do not scan or probe hosts nobody named. The trace protects you here: everything you ran is on the action log, which is exactly what makes an authorized audit defensible and an unrequested scan indefensible.