🐧 Linux Host Security: Top 10 Misconfigurations and a Fast Audit Playbook

Intro: Most Linux security problems on cloud hosts are not exotic kernel exploits. They are ordinary, repeated, expensive mistakes: weak SSH settings, stale packages, sloppy permissions, no audit trail, and a machine that quietly drifted away from the intended baseline.

What this page includes

• ten high-value Linux misconfigurations worth checking first
• how to detect them with fast commands and with a lightweight audit tool
• a sample shell script for a quick host review
• a sample report with six representative findings and short fixes

Working assumptions

• the target is a baseline Linux host in a cloud environment, often EC2
• the goal is fast detection, triage, and remediation, not theoretical completeness
• the audit should be safe enough to run on a live host with change control

The top 10 Linux misconfigurations I would check first

| # | Misconfiguration | Why it is dangerous | Fast detection | | --- | --- | --- | --- | | 1 | PasswordAuthentication enabled in SSH | Makes credential stuffing and password guessing far more useful | sshd -T | grep passwordauthentication | | 2 | PermitRootLogin enabled | Gives attackers a direct admin target over SSH | sshd -T | grep permitrootlogin | | 3 | Security updates are not applied or not automated | Known CVEs stay exploitable far longer than they should | apt list --upgradable or dnf check-update | | 4 | Host firewall disabled or overly permissive | Attack surface grows well beyond the intended admin ports | ufw status, firewall-cmd --list-all, or iptables -S | | 5 | auditd missing or inactive | Post-incident reconstruction gets much harder | systemctl status auditd | | 6 | World-writable files or directories in sensitive paths | Makes persistence and tampering easier | find /etc /usr/local -xdev -type f -perm -0002 | | 7 | Weak permissions on private keys and SSH config | Private material leaks or is replaced | stat -c '%a %n' ~/.ssh/* /etc/ssh/* 2>/dev/null | | 8 | Time sync disabled | Logs become unreliable and auth systems drift | timedatectl status | | 9 | Kernel/network hardening sysctls are weak | Increases abuse potential for ptrace, redirects, source routing, and similar abuse paths | sysctl net.ipv4.conf.all.accept_redirects kernel.kptr_restrict | | 10 | Unnecessary listening services | Every open daemon is another attack surface and another patch burden | ss -tulpn |

My preferred fast audit order

1. SSH exposure
2. Patch state
3. Firewall
4. Audit and logging
5. Permissions
6. Listening services
7. Kernel/sysctl
8. Optional deeper audit with Lynis or OpenSCAP

That order is not random. It gets you the highest-value findings early.

Quick commands I would actually run

SSH posture

sudo sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding'

Patch posture

# Debian / Ubuntu
sudo apt update -qq
apt list --upgradable

# RHEL / Amazon Linux
sudo dnf check-update || true

Firewall

sudo ufw status verbose || true
sudo firewall-cmd --state || true
sudo iptables -S | sed -n '1,80p'

Services and ports

sudo ss -tulpn
sudo systemctl list-unit-files --type=service --state=enabled

auditd

sudo systemctl is-enabled auditd
sudo systemctl is-active auditd

World-writable files

sudo find /etc /usr/local /opt -xdev -type f -perm -0002 2>/dev/null

Time sync

timedatectl status

sysctl spot checks

sysctl   kernel.kptr_restrict   kernel.yama.ptrace_scope   net.ipv4.conf.all.accept_redirects   net.ipv4.conf.all.send_redirects   net.ipv4.conf.all.rp_filter   fs.protected_hardlinks   fs.protected_symlinks

Fast audit with Lynis

Lynis is useful when you want a broad host review without writing everything from scratch.

Install

# Debian / Ubuntu
sudo apt-get update
sudo apt-get install -y lynis

# RHEL / Amazon Linux
sudo dnf install -y lynis

Run

sudo lynis audit system

What it gives you

• a broad system hardening review;
• warnings and suggestions;
• a quick sense of whether the host is obviously behind the expected baseline.

What it does not do

It does not replace judgment, architecture context, or cloud-aware host review.

Sample quick-audit script

#!/usr/bin/env bash
set -euo pipefail

echo "== SSH settings =="
sshd -T | egrep 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding' || true

echo
echo "== Patch state =="
if command -v apt >/dev/null 2>&1; then
  apt list --upgradable 2>/dev/null | sed -n '1,40p'
elif command -v dnf >/dev/null 2>&1; then
  dnf check-update || true
fi

echo
echo "== Firewall =="
ufw status verbose || true
firewall-cmd --list-all || true

echo
echo "== auditd =="
systemctl is-enabled auditd || true
systemctl is-active auditd || true

echo
echo "== Listening ports =="
ss -tulpn | sed -n '1,60p'

echo
echo "== World-writable files =="
find /etc /usr/local /opt -xdev -type f -perm -0002 2>/dev/null | sed -n '1,40p'

echo
echo "== Time sync =="
timedatectl status | sed -n '1,15p'

Sample report

Host: ip-10-42-8-17
Audit timestamp: 2026-03-27T19:42:18Z

[HIGH] SSH password authentication enabled
  Evidence: passwordauthentication yes

[HIGH] SSH root login permitted
  Evidence: permitrootlogin yes

[MEDIUM] Host firewall inactive
  Evidence: ufw status -> inactive

[MEDIUM] auditd not enabled
  Evidence: systemctl is-enabled auditd -> disabled

[MEDIUM] 37 packages pending upgrade
  Evidence: apt list --upgradable

[LOW] World-writable file found
  Evidence: /usr/local/bin/deploy-helper.sh mode 0777

How to read that report

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload sshd

sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl reload sshd

sudo ufw allow OpenSSH
sudo ufw enable

sudo apt-get install -y auditd audispd-plugins
sudo systemctl enable --now auditd

sudo chown root:root /usr/local/bin/deploy-helper.sh
sudo chmod 0755 /usr/local/bin/deploy-helper.sh

Common failure patterns in Linux audits

1. Running checks without root, then assuming “no output” means “no issue”.
2. Checking SSH config files only, instead of using sshd -T to see the effective settings.
3. Looking only at the cloud firewall, ignoring host-level exposure.
4. Treating package count as the only patch metric, instead of looking at the actual severity mix.
5. Forgetting the systemd state, where a package is installed but the service is still disabled.
6. Running the audit once and never comparing it against a known-good baseline.

Where I would start remediating

If I inherited a messy host today, I would fix in this order:

1. SSH auth and admin access model
2. firewall and exposure
3. patching and reboot planning
4. auditd and central logs
5. permissions drift
6. unnecessary services
7. sysctl and hardening residue

That order gives you a fast reduction in real risk.

Cross-links

• Linux Base Image and Host Security Baseline
• Ansible for EC2 Host Security: 7 High-Value Tasks That Actually Matter
• Ansible Security Baseline and Top 10 Misconfigurations