Server security

Linux Server Audit Fixes

These are the fixes for a server security audit: who can reach the box, what it is running, which files are writable by the wrong people, and how far behind it is on patches.

45
checks documented
7
audits in this category
17
need root or sudo
13
rated high severity

What these fixes cover

  • Root login, key-based authentication, sudo grants and who can open a session
  • Firewall state, listening ports, IPv6 coverage and services exposed beyond localhost
  • World-writable paths, set-id binaries and sensitive file permissions
  • Pending security updates, kernel state and whether a reboot is outstanding

What they do not

  • Application-level bugs in the code you deploy. These checks read server configuration, not your source.
  • Intrusion detection beyond whether Fail2Ban, sshguard or CrowdSec is present and running.
  • Anything behind a managed platform you do not control. On Kubernetes or a PaaS there is no sshd to read.

How much of this is serious?

Severity of all 45 VPS & Server checks, as the scripts rate them.

  • 13High severity29%
  • 21Medium severity47%
  • 11Low severity24%
FAQ

VPS & Server fix questions

Work down by severity, and inside a severity by exposure. A HIGH finding on SSH root login or an inactive firewall changes who can reach the machine at all, so it outranks a HIGH finding on file permissions, which requires an attacker to already be on the box. The audit sorts findings this way, and each page states the severity the script assigns.
Several can if applied carelessly, and the pages that carry that risk say so in the fix itself. The rule that prevents almost all lockouts: keep a second SSH session open while you edit sshd_config or firewall rules, validate with sshd -t or ufw status before reloading, and confirm the new path works in the second session before closing the first.
Commands are given for Debian and Ubuntu first, with the RHEL-family equivalent where it differs. The audit scripts themselves detect the package family at runtime and cover Ubuntu, Debian, RHEL, CentOS, Rocky, Alma, Amazon Linux, Fedora, Oracle Linux, SUSE and Alpine.
Almost always privilege. Checks that read another account's files, the sudoers configuration or firewall state need root, and they report SKIP rather than guessing when they cannot get it. Run the audit as root, grant the audit account sudo, or supply a sudo password in the audit settings. Each audit hub page has the full privilege-mode table.
Audit your fleet

Run all 45 VPS & Server checks, in one click

CtrlOps runs these audits 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