Guide

Linux Server Security Audit Checklist: Step-by-Step VPS Guide

A Linux server security audit checklist helps VPS administrators identify security vulnerabilities, review server configurations, and strengthen overall system security. By following this checklist, you can inspect user accounts, SSH access, firewall rules, software updates, file permissions, authentication logs, and backup procedures to reduce security risks and protect your Linux server from unauthorized access.

Whether you manage a production VPS, a web hosting server, or a private application server, a structured security review helps you understand your server’s current security posture and prioritize improvements.

This guide covers practical Linux security audit steps, commands, and verification methods for administrators managing Linux-based servers.

1. Check User Accounts and Administrative Privileges

Start by reviewing the accounts that can access your server. Remove or disable unnecessary accounts and verify that only authorized users have administrative privileges.

List local user accounts:

cat /etc/passwd

Review users with UID 0:

awk -F: '$3 == 0 {print $1}' /etc/passwd

Normally, the root account is the only account with UID 0. Investigate any additional entries carefully.

Check which users belong to administrative groups:

getent group sudo
getent group wheel

The relevant group depends on your Linux distribution.

Also review user login history:

last -a

Check recent failed login attempts where supported:

sudo lastb -a

The lastb command may require root privileges and an available failed-login database.

What to look for:

  • Unknown user accounts
  • Unexpected users with administrative privileges
  • Unfamiliar login sessions
  • Accounts belonging to former employees or contractors
  • Suspicious login times or source addresses

Do not delete an account simply because you do not recognize it. First determine whether it belongs to a system service or an application.

2. Audit SSH Configuration

SSH is one of the most important access points to review during a Linux server security audit. An exposed SSH service with weak authentication can increase the risk of unauthorized access.

Inspect the effective SSH server configuration:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'

Review the configuration files if you need to identify where a setting originates:

sudo grep -RniE 'PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|Port' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ 2>/dev/null

For public-facing servers, consider using SSH key authentication and disabling password authentication when your access arrangements support it. Restrict direct root login where practical.

Before changing SSH settings, confirm that you have a working alternative administrative session and access to your provider’s recovery console.

Validate the configuration before reloading SSH:

sudo sshd -t

If validation succeeds, reload the SSH service using the correct service name for your distribution.

For example, common service names include sshd and ssh.

Important: Never disable password authentication before confirming that your SSH keys work and that you can regain access if the configuration fails.

3. Inspect Listening Ports and Network Services

Every listening service creates a potential point of exposure. Your audit should identify which services are listening, which interfaces they use, and whether they need to be publicly accessible.

List listening TCP and UDP sockets:

sudo ss -tulpn

Check active services:

systemctl --type=service --state=running

Common ports include:

  • 22: SSH
  • 25: SMTP
  • 53: DNS
  • 80: HTTP
  • 443: HTTPS
  • 3306: MySQL or MariaDB
  • 5432: PostgreSQL

These are common defaults, not a complete list. Services may use custom ports, and a listening port does not automatically mean that it is publicly accessible.

Review each exposed service and determine whether it is required. Database services, administrative panels, and internal APIs should generally be restricted to trusted networks or specific source addresses whenever possible.

Do not stop an unfamiliar service until you understand its purpose and dependencies.

4. Review Firewall Rules

A properly configured firewall limits access to services that must not be publicly reachable.

Check which firewall tools are installed and active.

For UFW:

sudo ufw status verbose

For firewalld:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

For systems using nftables:

sudo nft list ruleset

For systems using iptables:

sudo iptables -S
sudo ip6tables -S

You may not need every command. Use the firewall system configured on your server.

Verify that:

  • SSH access is permitted from the required locations.
  • Public web traffic is allowed only where necessary.
  • Database ports are not unnecessarily exposed.
  • IPv4 and IPv6 rules are both considered.
  • The firewall rules survive a reboot where expected.

Be particularly careful when changing firewall rules remotely. An incorrect rule can lock you out of your own server. Keep a provider console or another recovery method available.

5. Check Operating System and Package Updates

Outdated software can contain publicly known vulnerabilities. Check the operating system version and identify available security updates.

Display operating system information:

cat /etc/os-release

On Debian or Ubuntu:

sudo apt update
apt list --upgradable

On RHEL-compatible distributions using DNF:

sudo dnf check-update

Review the packages that need updating, prioritizing security fixes and exposed services.

Also verify whether your Linux distribution is still supported. An end-of-life operating system may no longer receive normal security updates.

Before applying major updates to a production server, confirm that you have a usable backup and understand whether a service restart or reboot will be required.

After patching, verify the relevant service status and check application logs for errors.

6. Review File Permissions and Sensitive Files

Incorrect file permissions can expose configuration files, SSH keys, credentials, and other sensitive data.

Check SSH directory permissions for the current user:

chmod 700 ~/.ssh

Restrict access to the user’s authorized public-key list:

chmod 600 ~/.ssh/authorized_keys

These commands are examples for a typical user-owned SSH directory. Run them as the appropriate account and verify ownership before making changes.

Check for world-writable filesystems entries on the current filesystem:

find / -xdev -type f -perm -0002 -print 2>/dev/null

Review the results rather than changing permissions automatically. Some applications require specific writable files or directories.

You can also identify files with the set-user-ID permission bit:

find / -xdev -type f -perm -4000 -print 2>/dev/null

Set-user-ID files are not automatically malicious. Many legitimate system utilities use this permission. Investigate unexpected files, their ownership, package origin, and modification history.

Avoid running recursive permission changes across system directories. Commands such as broad recursive chmod or chown operations can break applications and prevent the operating system from functioning correctly.

7. Examine Authentication Logs

Authentication logs can help identify repeated login failures, unexpected access, and suspicious activity.

On systems using systemd’s journal:

sudo journalctl -u ssh --since "24 hours ago"

On systems where the service is named sshd:

sudo journalctl -u sshd --since "24 hours ago"

On Debian and Ubuntu, authentication events may also be available in:

sudo tail -n 100 /var/log/auth.log

On many RHEL-compatible systems, check:

sudo tail -n 100 /var/log/secure

The available log location depends on the distribution and logging configuration.

Look for repeated failed logins, successful sessions from unfamiliar addresses, unexpected privilege escalation, and changes that occurred outside approved maintenance windows.

A large number of failed login attempts does not necessarily indicate a successful compromise. Correlate the logs with successful authentication events and other evidence.

If you suspect unauthorized access, preserve relevant logs before making changes.

8. Inspect Scheduled Tasks and Startup Services

Attackers sometimes use scheduled jobs or startup services to maintain access to a compromised server. However, legitimate applications also create scheduled tasks, so unfamiliar entries require investigation rather than immediate deletion.

List the current user’s cron jobs:

crontab -l

Review root’s scheduled tasks:

sudo crontab -l

Inspect system-wide cron directories:

ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly

List enabled systemd services:

systemctl list-unit-files --type=service --state=enabled

Review systemd timers:

systemctl list-timers --all

Check any unfamiliar script or service for its owner, contents, creation time, and purpose. Compare the findings against your deployment records and installed application documentation.

Do not remove a scheduled job solely because its name looks unusual. Removing legitimate maintenance tasks may interrupt backups, monitoring, or application operations.

9. Check for Suspicious Processes and Resource Usage

Unexpected processes, unfamiliar binaries, or unexplained resource consumption can indicate misconfiguration, runaway applications, or a security incident.

List processes using the most CPU:

ps aux --sort=-%cpu | head -n 15

List processes using the most memory:

ps aux --sort=-%mem | head -n 15

Inspect system resource usage:

free -h
uptime
df -h

If a process appears suspicious, identify its executable, owner, parent process, open files, and network connections before deciding what to do.

For example:

ps -fp PID

Replace PID with the actual process ID.

High CPU usage alone is not evidence of malware. A busy database, backup task, or application workload can produce similar symptoms. Investigate the process in context.

If you suspect a compromise, avoid immediately deleting suspicious files because doing so may destroy evidence needed to determine the incident’s scope.

10. Review Brute-Force Protection

Public-facing SSH and web services may receive automated login attempts. Tools such as Fail2ban can help reduce repeated unauthorized attempts by temporarily blocking sources that match configured rules.

Check whether Fail2ban is installed and running:

sudo fail2ban-client status

If the command is unavailable, Fail2ban may not be installed or may not be in the executable search path.

When it is active, inspect individual jails:

sudo fail2ban-client status sshd

The jail name may differ depending on your configuration.

Review the configured log sources, ban duration, and protected services. Fail2ban complements good authentication and firewall rules; it does not replace them.

Do not assume that installing Fail2ban alone secures a server. Confirm that the relevant jails are active and monitoring the correct logs.

11. Verify System Time and Log Consistency

Accurate system time helps administrators correlate authentication events, application errors, and security alerts.

Check the current time and synchronization status:

timedatectl status

If synchronization is unavailable, investigate the configured time service and network access to approved time sources.

Review timestamps from different logs and compare them with known administrative activity. Time discrepancies can make incident investigation more difficult.

Do not make manual clock changes on a production system without considering the effects on scheduled jobs, applications, and time-sensitive services.

12. Verify Backups and Recovery Procedures

Backups are an essential part of server security because even a well-maintained system can experience compromise, hardware failure, accidental deletion, or application corruption.

During your audit, verify:

  • When the most recent backup completed successfully.
  • Whether the backup includes the required files, databases, and configurations.
  • Whether backup credentials and storage locations are protected.
  • Whether copies are isolated from the production server.
  • Whether retention policies meet your recovery requirements.
  • Whether a restore has been tested recently.

A successful backup job does not prove that recovery will work. Perform a test restoration in a separate environment and verify the integrity of the recovered data.

Document the recovery steps, required credentials, and the people authorized to perform a restoration.

13. Create a Remediation Plan

A security audit is useful only when the findings lead to corrective action. Record each issue, assess its severity, and assign an owner and target date.

A practical priority order is:

  1. Critical: Confirmed unauthorized access, exposed credentials, or actively exploited vulnerabilities.
  2. High: Publicly exposed sensitive services, unsupported software, or serious authentication weaknesses.
  3. Medium: Excessive privileges, missing protective controls, or weak operational practices.
  4. Low: Documentation gaps and other improvements that do not create immediate material exposure.

Priorities should reflect the actual environment and available evidence. After remediation, repeat the relevant checks to verify that the issue is resolved.

Keep a record of what changed, when it changed, and how the result was verified.

How Often Should You Audit a Linux Server?

The appropriate audit frequency depends on the server’s role, exposure, and risk level.

For a public-facing production VPS, review security updates, authentication events, and critical alerts regularly. Perform a more comprehensive audit on a scheduled basis and after significant changes, such as a new public service, major operating system upgrade, administrative access change, or suspected security incident.

Automated monitoring can help detect changes between manual audits, but it should complement—not replace—periodic human review.

A Linux server security audit provides a structured way to identify weaknesses in access control, network exposure, software maintenance, logging, and recovery readiness. The commands in this guide help administrators gather evidence and investigate potential problems without blindly changing system settings.

Start with the highest-risk findings, preserve access and backups before making significant changes, and verify each remediation. Consistent auditing helps keep VPS infrastructure easier to maintain and more resilient against security incidents.

Related Posts