A Linux server can be fully patched, running normally, and still have security problems that nobody has noticed.
I've spent over 20 years working with IT infrastructure and information security. One thing I've learned is that a healthy server isn't necessarily a secure server.
These are five areas I always pay attention to, especially on production systems that have been running for years.
1. SSH configuration
SSH is usually one of the first things I check.
Password authentication, root login, and configuration overrides can easily be overlooked.
sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '
This shows effective SSH settings for the default connection context. Keep in mind that Match rules can produce different results depending on the user or source address.
Before making SSH changes, validate the configuration:
sudo sshd -t
And never close your existing SSH session until you've confirmed that you can establish a new connection.
I've seen simple SSH hardening changes turn into production access problems because nobody verified the recovery path first.
2. User accounts and privileged access
Temporary accounts often become permanent without anyone noticing.
Accounts created for troubleshooting, old applications, or former administrators may still exist years later.
A few basic checks:
getent passwd
getent group sudo
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd
For RHEL-based systems, also review the wheel group:
getent group wheel
Not every account should have an interactive login. The important questions are who has access, what privileges they have, and whether that access is still required.
3. Listening services
A server may be running perfectly fine while exposing services that nobody intended to make accessible.
Start by reviewing listening ports:
sudo ss -tulpen
Pay particular attention to services listening on 0.0.0.0 or ::.
That doesn't automatically mean they're accessible from the internet. Firewall rules, routing, containers, and cloud security groups all influence actual exposure.
But every unexpected listening service deserves investigation.
4. Firewall configuration
Firewall rules have a way of accumulating over time.
A temporary exception made during troubleshooting can remain active long after the original issue has been resolved.
On Ubuntu systems using UFW:
sudo ufw status verbose
On RHEL systems using firewalld:
sudo firewall-cmd --list-all
You can also review the active nftables ruleset where applicable:
sudo nft list ruleset
I don't just check whether the firewall is enabled.
I want to understand which connections are permitted, why they're permitted, and whether those exceptions are still necessary.
5. Security updates and configuration drift
Patching is important, but an updated operating system isn't automatically a hardened one.
On Ubuntu:
apt list --upgradable
On RHEL-based systems:
sudo dnf check-update
Keep in mind that dnf check-update can return exit code 100 when updates are available. That doesn't necessarily indicate a command failure.
Available updates also aren't necessarily all security fixes. Review their purpose, operational impact, and any required restarts before deploying them.
Beyond patching, configuration drift is another concern.
Production servers often pass through multiple administrators, troubleshooting sessions, migrations, and application upgrades.
Over time, security exceptions can become part of the environment without anyone remembering why they were introduced.
That's why periodic configuration reviews matter.
Why I built NextGenAlert Linux Security Audit
Manually reviewing these settings is useful, but it becomes repetitive when you're responsible for multiple Linux systems.
That's one reason I developed NextGenAlert Linux Security Audit.
It's a free Community Edition tool designed to review common Linux security settings and generate reports in HTML, PDF, and JSON formats.
The checks run locally, and the reports help identify areas that may need closer attention.
If you're responsible for Ubuntu, RHEL, AlmaLinux, or other supported Linux systems, you can explore the free tool here:
NextGenAlert Linux Security Audit — Free Community Edition
An automated audit is a starting point, not a replacement for understanding the environment.
I'm curious what other Linux administrators have encountered.
What's one security misconfiguration you've found on a production server that appeared completely healthy?
Top comments (0)