Your server can be running perfectly and still be easier to access than you intended.
An old administrator account. A database listening on the wrong interface. A firewall rule nobody remembers adding. These problems rarely announce themselves.
This Linux server security checklist helps you inspect the settings that matter before they become a problem.
You’ll review SSH access, user permissions, firewall rules, open ports, running services, updates, logs, and recovery readiness. Most importantly, you’ll learn what the results actually mean.
To audit a Linux server’s security, review installed updates, user accounts, administrator privileges, SSH settings, firewall rules, listening ports, running services, sensitive permissions, and authentication logs. Document unexpected findings before making changes. A useful audit identifies risks without interrupting the server you’re trying to protect.
- What Does a Linux Server Security Audit Check?
- 15 Linux Server Security Checklist: 15 Essential Audit Checks
- 01 — Access & Updates
- 02 — Network & Host Exposure
- 03 — Logs, Automation & Recovery
- How to Interpret Your Security Audit Results
- A 5-Minute Linux VPS Security Check
- Step 1 — Identify the operating system
- Step 2 — Inspect listening ports
- Step 3 — Review running services
- Step 4 — Check recent warnings
- Step 5 — Record what needs attention
- Before Changing SSH or Firewall Settings
- How Often Should You Audit a Linux Server?
- Frequently Asked Questions
- Know What Your Server Is Actually Running
- Continue Learning Linux Server Security
- Technical References
What Does a Linux Server Security Audit Check?
A security audit is a structured review of your server’s current configuration and observable activity.
It answers practical questions: Who can log in? Which services are reachable? Are important updates missing? Do recent logs contain anything that needs investigating?
You don’t have to change settings during the review. In fact, separating inspection from remediation makes it easier to understand what you found.
Identify accounts, permissions, and authentication paths that deserve closer review.
Compare listening services and firewall rules with what your server actually needs.
Record the expected state so unexpected changes become easier to recognize.
This checklist focuses on inspection.
Some commands require authorized
sudo access.
Don’t disable SSH authentication,
remove users, or change firewall
rules while reviewing an unfamiliar
remote server. Preserve a working
access method and recovery path first.
15 Linux Server Security Checklist: 15 Essential Audit Checks
Work through the checks in order. Tick an item once you’ve inspected the result and recorded anything unusual.
The commands are examples for common systemd-based Linux servers. Package managers, security tools, and service names vary by distribution.
01 — Access & Updates
Checks 1–5Identify the operating system, then review packages waiting for updates. Unsupported releases and delayed security patches deserve attention.
cat /etc/os-release
apt list --upgradable
What to look for
The second command is for
Debian and Ubuntu systems using APT.
Fedora and RHEL-family systems
commonly use dnf check-update.
Package information may need refreshing
before it reflects the latest updates.
DNF can return status 100 when updates
are available; that is expected behavior.
Check which accounts exist and whether each one has a legitimate purpose. Old employee accounts, forgotten deployment users, and unexpected login shells are worth investigating.
getent passwd | cut -d: -f1,3,7
What to look for
The output shows account names, numeric user IDs, and login shells. System accounts are normal. An account you don’t recognize is a reason to investigate, not proof of compromise. Don’t delete accounts until you understand their purpose.
Understand which commands your current account is authorized to run as another user. Broad administrative permissions should be intentional.
sudo -l
What to look for
This command reports privileges for the current user; it is not a complete audit of every account. Also review relevant sudo and wheel group membership, sudoers rules, and any centrally managed access.
Review whether root login, password authentication, and public-key authentication match your intended access policy.
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
What to look for
sshd -T prints
effective OpenSSH server settings.
Conditional Match
blocks can affect particular
connections; testing those
requires suitable
sshd -T -C parameters.
The command requires an installed
OpenSSH server.
Determine which keys can access administrative accounts. Check that their owners are known and that key files have appropriate permissions.
ls -ld ~/.ssh ~/.ssh/authorized_keys
What to look for
This checks the current user’s
default SSH key locations.
Other accounts and custom
AuthorizedKeysFile
settings need separate review.
Missing files aren’t automatically
a vulnerability. Don’t publish
access details or key material
in screenshots or public reports.
02 — Network & Host Exposure
Checks 6–10Review which network traffic the server is configured to accept. Compare permitted connections against the services you actually run.
sudo nft list ruleset
What to look for
This inspects nftables rules where nftables is available. Systems may use UFW, firewalld, or other firewall arrangements. Cloud-provider security groups and upstream firewalls must be reviewed separately. An empty local ruleset doesn’t describe the entire network security policy.
Find services waiting for incoming connections. A database listening on every network interface may need a closer look.
sudo ss -lntup
What to look for
Addresses such as
127.0.0.1
usually indicate local-only
IPv4 listening.
0.0.0.0
means listening on all IPv4
interfaces. IPv6 has its
own addressing behavior.
A listening port is not
necessarily reachable
from the public internet:
firewall rules, routing,
and provider settings matter.
Look for services you no longer need or don’t recognize. Every unnecessary application can increase maintenance work and the potential attack surface.
systemctl list-units --type=service --state=running --no-pager
What to look for
Check each unfamiliar service against your installed software. A running service isn’t automatically a problem. This command lists running systemd services, not every process or container workload. Do not stop unfamiliar services before identifying their dependencies.
Verify ownership and access permissions for important system files. Configuration and credential files shouldn’t be writable by unauthorized users.
sudo stat -c '%a %U:%G %n' /etc/passwd /etc/shadow /etc/ssh/sshd_config
What to look for
Compare results with your distribution’s expected settings. Correct permissions vary by file and operating system. An absent SSH configuration file may simply mean the SSH server isn’t installed. Avoid applying blanket permission changes.
Some distributions use AppArmor or SELinux to restrict what applications can access, even when ordinary Unix file permissions would allow it.
sudo aa-status
getenforce
What to look for
Run the command appropriate for your system, if the tool is installed. AppArmor and SELinux are different security frameworks. Review whether the expected profiles or policies are enforcing restrictions. A missing utility does not, by itself, prove a security problem.
03 — Logs, Automation & Recovery
Checks 11–15Look at recent SSH activity, particularly repeated failures or successful logins that don’t match expected administrator activity.
sudo journalctl -u ssh -u sshd --since "24 hours ago" -n 80 --no-pager
What to look for
Service names and logging destinations vary. Failed login attempts are common on internet-facing SSH servers and don’t automatically mean someone gained access. Unexpected successful authentication deserves more investigation.
Review recurring errors, failed services, and unusual system messages. Some security problems first appear as ordinary operational failures.
sudo journalctl -p warning --since "24 hours ago" -n 60 --no-pager
What to look for
A warning isn’t necessarily a security incident. Compare messages with normal server activity and recent changes. The system journal may not contain every application or security event.
Identify scheduled scripts, maintenance jobs, and timers. A forgotten task may use outdated credentials, run with unnecessary privileges, or execute software that nobody maintains.
crontab -l
systemctl list-timers --all --no-pager
What to look for
The first command checks only the current user’s crontab. Other user crontabs, system cron directories, and application-specific scheduling mechanisms require separate inspection. An unfamiliar job needs identification before removal.
Check that usable backups exist outside the original VPS, important databases are included, and a recovery test has succeeded. Recovery matters when preventive controls aren’t enough.
df -h
What to look for
Disk usage is only a supporting check. It cannot prove that backups exist or can be restored. Verify off-server storage, backup job results, retention, and an actual restore test. Never treat a snapshot as automatically equivalent to a tested backup.
Write down the unexpected settings, affected services, business impact, and next actions. Prioritize issues according to exposure and consequences, not just the number of warnings you found.
What to look for
A useful audit record includes the finding, affected host, evidence, severity, owner, remediation plan, and retest date. Keep sensitive command output in protected internal records, not public issue trackers.
How to Interpret Your Security Audit Results
Not every unusual setting is a vulnerability. The key is understanding why something exists and whether it matches your intended setup.
An SSH service listening on an external interface may be entirely expected for a VPS. A database accidentally exposed to the internet is a different matter.
| Finding | Priority | Next action |
|---|---|---|
| Unexpected public exposure of a sensitive service | High | Confirm reachability and investigate promptly. Plan safe containment. |
| Unknown privileged account | High | Verify ownership and authorization before changing access. |
| Pending important security updates | Review | Assess severity, exposure, and maintenance requirements. |
| Unfamiliar scheduled task | Review | Identify its owner, purpose, privileges, and executable. |
| Expected service with documented access | Baseline | Record its intended state and monitor for changes. |
These priorities are illustrative. A real security finding needs context: what is exposed, which data is involved, and how likely it is to be exploited.
A 5-Minute Linux VPS Security Check
Here’s a compact exercise you can run on a Linux VPS without changing its configuration.
You’ll inspect four areas: operating system information, listening ports, running services, and recent warnings.
A Linux terminal with appropriate permissions. The examples assume systemd and the usual Linux diagnostic tools. Some commands may produce sensitive operational information; avoid sharing their complete output publicly.
Step 1 — Identify the operating system
cat /etc/os-release
uname -rRecord the distribution and kernel release. You’ll need this information when researching updates or checking compatibility.
Step 2 — Inspect listening ports
sudo ss -lntupLook at the local address, port number, and process associated with each listener.
Ask yourself: does this service need to accept connections, and from which networks?
127.0.0.1:3306
generally indicates a service
bound to IPv4 loopback,
while 0.0.0.0:3306
indicates listening on all
local IPv4 interfaces.
Neither result alone tells you
what an external client
can reach through firewalls
and network infrastructure.
Step 3 — Review running services
systemctl list-units \
--type=service \
--state=running \
--no-pagerCheck whether the services match your server’s purpose. If you find something unfamiliar, investigate what installed it and whether another application depends on it.
Step 4 — Check recent warnings
sudo journalctl \
-p warning \
--since "24 hours ago" \
-n 60 \
--no-pagerLook for repeated problems, especially around authentication, service startup, and filesystem access.
Some warnings are routine. The useful question isn’t simply whether a warning exists, but whether it represents unexpected behavior.
Step 5 — Record what needs attention
Write a short audit note. For example:
Host: test-vps
Operating system: reviewed
Listening ports: reviewed
Running services: reviewed
Recent warnings: reviewed
Finding:
Unexpected service requires investigation.
Next action:
Confirm service owner and purpose.
Changes made:
None.That’s enough for a first pass: you have a clearer picture of the server without changing how it operates.
Before Changing SSH or Firewall Settings
Some audit findings may need configuration changes. Remote access deserves particular care.
A firewall rule or SSH change can be technically valid and still block the connection you use to manage the server.
Before applying SSH or firewall changes, confirm that you have a working alternative access method, such as your provider’s console. Keep the current SSH session open, validate the proposed configuration, and test a new connection before closing the original session.
When editing OpenSSH server configuration, you can test its syntax using:
sudo sshd -tThis checks configuration syntax and host-key sanity. It does not guarantee that a particular user can authenticate or that your network policy will allow a connection.
For a safe editing workflow, see our guide to editing Linux configuration files .
How Often Should You Audit a Linux Server?
There’s no single schedule that fits every environment. A small personal VPS and a production system holding sensitive customer data have different requirements.
This is a practical starting point:
| When | What to review |
|---|---|
| After initial setup | Users, SSH, firewall, exposed services, and updates. |
| After major changes | New accounts, packages, services, network access, and configuration changes. |
| During routine maintenance | Updates, authentication events, logs, and unexpected services. |
| After suspicious activity | Preserve evidence and follow a suitable incident-response procedure rather than relying on a routine checklist alone. |
Routine monitoring can identify important changes between audits. A scheduled checklist is useful, but it shouldn’t be the only way you learn that something on the server has changed.
Frequently Asked Questions
What should a Linux server security checklist include?
It should cover software updates, user accounts, administrative privileges, SSH configuration, firewall policies, listening ports, running services, file permissions, logging, scheduled tasks, and recovery readiness. The checks should reflect the server’s actual role.
Can I audit my VPS without changing its configuration?
Yes. Many useful security checks involve reading system information, inspecting settings, and reviewing logs. Some require elevated privileges, but they don’t have to modify the server’s configuration.
Does an open port mean my VPS is vulnerable?
No. An open port may be necessary for a legitimate service. The risk depends on whether the service is exposed to unintended networks, how it is configured, and whether it has exploitable weaknesses.
Are failed SSH login attempts proof of an attack?
Not necessarily. Internet-facing SSH servers commonly receive unwanted authentication attempts. Investigate unusual patterns and unexpected successful logins. Failed attempts alone don’t prove that access was obtained.
Does completing this checklist prove my server is secure?
No. It provides a useful configuration and activity review, not a complete penetration test or a guarantee that the system has not been compromised. Security also depends on application vulnerabilities, credentials, network architecture, and ongoing monitoring.
Know What Your Server Is Actually Running
A good Linux security audit doesn’t begin by disabling everything that looks unfamiliar. It begins by finding out what belongs on the server and what doesn’t.
Use this Linux server security checklist to establish that baseline: review access, understand exposed services, inspect logs, and investigate unexpected changes.
Then fix confirmed problems carefully, verify the results, and keep a record for your next audit.
Continue Learning Linux Server Security
Each part of this security audit connects to a larger Linux topic. These Servers Academy lessons explain the underlying concepts and tools in more detail.
Technical References
These references document the commands and security features used throughout this guide.
