Server security

Linux Server Security Audit Checklist

The box itself - access, network, patches and permissions.

7
audits
VPS & Server
45
individual checks
named
~76s
to run the category
read-only

A server security audit reads the machine itself: who can reach it, what it is running, which files are writable by the wrong people, and how far behind it is on patches.

  • Read-only, safe on production
  • No agent installed
  • ~76s for the category
  • 10 distros auto-detected

How much of this is serious?

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

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

What these audits cover

  • Root login, key-based authentication, sudo grants and who can open a session
  • Firewall state, listening ports, 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 cover

  • Application-level bugs in the code you deploy. These audits read server configuration, not your source.
  • Intrusion detection and brute-force blocking. Fail2Ban, sshguard and CrowdSec are not evaluated.
  • Anything behind a managed platform you do not control. On Kubernetes or a PaaS there is no sshd to read.
FAQ

VPS & Server security questions

A Linux server security audit is a systematic read of a server's configuration to find settings that expose it: permissive SSH access, an inactive or over-open firewall, services listening on public interfaces, over-privileged accounts, dangerous file permissions and missing security patches. It inspects state rather than changing it, so a full audit is safe to run against production.
Audit after every change to who has access - a new hire, a departure, a contractor finishing - and after provisioning any new server. Beyond that, monthly is a reasonable baseline. The reason is configuration drift rather than new vulnerabilities: a setting relaxed for a quick test is rarely reverted, and nothing on the server reminds you.
Most of them, yes. Checks that read another account's files or the sudoers configuration need root, and are reported as skipped rather than guessed when you run without it. The rest read files that are world-readable by default, such as sshd_config and login.defs, and work as any user.
All of them in common server use. Every audit script carries a cross-distribution preamble that detects the package family for itself, covering Ubuntu, Debian, RHEL, CentOS, Rocky, Alma, Amazon Linux, Fedora, Oracle Linux, SUSE and Alpine, then adapts the commands it runs accordingly.
No. The checks are read-only: they parse configuration files and query system state, and the whole server category takes roughly a minute and a half of wall-clock time. Nothing is installed, no service is restarted and nothing is written to the host.
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