Security audit
Read-only first. Sweep a host (or all hosts) for common exposure, report findings
ranked by risk, then propose hardening for the user to approve. Everything runs
through hh run <alias> "<command>". Change nothing without an explicit go-ahead -
this is diagnosis.
Checks (per host)
Patching:
apt-get -s upgrade 2>/dev/null | grep -c ^Inst # Debian/Ubuntu/Proxmox: count apt list --upgradable 2>/dev/null | tail -n +2 # what, specifically # TrueNAS: midclt call update.check_available
Listening services / exposure (the highest-signal check):
ss -tulpn # what listens, on which IPs # Flag anything bound to 0.0.0.0 / :: that should be LAN- or localhost-only.
SSH hardening:
sshd -T 2>/dev/null | grep -Ei \ 'permitrootlogin|passwordauthentication|pubkeyauthentication|permitemptypasswords' # Want: PermitRootLogin no|prohibit-password, PasswordAuthentication no, # PubkeyAuthentication yes, PermitEmptyPasswords no.
Accounts and privilege:
awk -F: '$3==0{print $1}' /etc/passwd # UID-0 accounts (expect only root) getent passwd | awk -F: '$7 ~ /(bash|sh|zsh)$/{print $1}' # login shells awk -F: '($2==""){print $1}' /etc/shadow # empty passwords (should be none) cat /etc/sudoers /etc/sudoers.d/* 2>/dev/null | grep -v '^#' # broad NOPASSWD?
Intrusion signals:
lastb 2>/dev/null | head # failed logins grep -iE 'fail|invalid user' /var/log/auth.log 2>/dev/null | tail
Firewall (is anything actually filtering?):
nft list ruleset 2>/dev/null || iptables -S 2>/dev/null || ufw status
Platform specifics
- Proxmox: web UI on 8006 - who can reach it?
pveum user list, is 2FA on, is the Datacenter/Node firewall enabled? - TrueNAS: exposed shares (SMB/NFS/iSCSI) and the UI on 443;
midclt call user.queryfor accounts; is root login disabled and 2FA on? Use the truenas-middleware skill for method details. - Docker hosts: containers publishing to 0.0.0.0, running as root, or
--privileged:docker psthendocker inspectthe suspicious ones.
Report, then propose
- Rank findings by severity - service exposed on 0.0.0.0 or password SSH = high; missing updates or broad sudo = medium; cosmetic = low - and cite the evidence (the command output) for each.
- Propose specific, minimal fixes; for each say what it changes and the risk of applying it.
- Change nothing until the user approves. Then apply, re-check, and if it was a real remediation, add a runbook entry.
Note: the HomelabHero control plane has its own deliberate posture (the privilege-separated broker, the vault, the narrow sudoers rule). Auditing it is fine, but do not "fix" a finding by weakening the vault, broker, or sudoers - that separation is intentional.
Read CLAUDE.md for why, and in particular the section on how strongly each
integration is fenced: the three tiers are not the same, and a finding that
looks like "this one is less locked down than that one" is usually describing a
difference that is deliberate. The capability catalogs carry the per-platform
detail. (The repository README covers the same ground for a reader on GitHub,
but it is not installed here - only ops/ is - so do not send anyone to it from
this box.)


