VPS & Server audit fixes

Logging & Monitoring: fixing all 3 checks

The logging and monitoring audit checks whether this host blocks repeated login failures and keeps the evidence, covering brute-force protection, log rotation and failed SSH logins in the auth log.

All three checks are marked as needing root and two of them genuinely skip without it: Brute-Force Protection can see that fail2ban is running but cannot list its jails, and Failed SSH Logins cannot open /var/log/auth.log, /var/log/secure or the journal. System Log Rotation never skips, and a host with no logrotate binary at all warns rather than skipping.

3
checks in this audit
0
rated high severity
3
need root or sudo
~9s
automated run time

Transcribed from the vps-security-logging-monitoring audit script. For what the audit covers rather than how to fix it, see the Logging & Monitoring checklist.

Every check

Find your finding

Listed in the order the audit runs them. Take the check name from the third field of the result line and open its page.

  • Brute-Force Protection

    Soon

    Checks whether fail2ban is installed, running and has active jails, or another brute-force blocker is in place

    MediumNeeds root4 results

  • System Log Rotation

    Soon

    Checks whether logrotate is installed and rotating, and flags log files that have grown past 100MB

    MediumNeeds root2 results

  • Failed SSH Logins

    Soon

    Checks the auth log for failed SSH login attempts in the last 24 hours

    LowNeeds root3 results
Why checks skip

A SKIP is never a pass

A skipped check verified nothing at all. The most common cause is privilege: 3 of the 3 checks in this audit need root for a complete result. Before every run, each script works out which of four privilege modes it is in.

The four privilege modes an audit script can run in, and what each one means for checks that need root
ModeHow it is reachedWhat it means for your results
rootThe audit runs as UID 0.Every privileged branch runs directly. No check skips for lack of permission.
nopasssudo -n true succeeds, so the account has passwordless sudo.Privileged commands run through sudo -n.
passA sudo password was supplied in the CtrlOps audit settings and accepted.Privileged commands run through sudo -S.
noneNone of the above worked.CAN_ROOT=0. Every privileged branch returns SKIP with a "Need root" message rather than guessing.

If many checks skip with a “need root” message, run the audit as root, grant the audit account sudo (with or without NOPASSWD), or supply the sudo password in the CtrlOps audit settings.

Keep going

Related audits

FAQ

Logging & Monitoring questions

Yes, and it usually means password authentication is switched off. The check counts lines containing the literal string "Failed password", which sshd only writes when a password attempt was possible; with PasswordAuthentication no, the same attackers generate "Invalid user" and "Connection closed by authenticating user" lines instead, and none of those are counted. A low number is therefore evidence about your auth configuration, not about how quiet the host is. The file branches count today's entries while the journal branch counts the last 24 hours, so the two disagree around midnight.
The check looks for /var/log/*.1 or /var/log/*.gz as evidence that something rotated. A journald-only host, which covers Fedora, Arch and minimal Debian 12 images with no rsyslog, never produces those files, because journald rotates its own binary journals under /var/log/journal instead. That makes the warning a false positive there; confirm with journalctl --disk-usage and the SystemMaxUse setting in journald.conf. A host less than a day old simply has not rotated anything yet.
The check reads the jail list from fail2ban-client status and stops there, so it confirms a jail exists without confirming that jail is reading a log file that exists. The common cause on Debian 12 and any host without rsyslog is an sshd jail pointed at /var/log/auth.log when that file was never created, in which case the jail runs and matches nothing. Set backend = systemd in jail.local, restart fail2ban, and verify with fail2ban-client status sshd: a jail showing 0 total failures after days of traffic on a public IP is doing nothing.
Audit your fleet

Run all 3 Logging & Monitoring checks, in one click

CtrlOps runs this audit over your existing SSH connection - no agents, no scripts to manage. $7/user/month after a 1 month free trial - no credit card required.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals