Linux Security Baseline Audit Checklist for Small Teams (Practical & Repeatable)

If you manage one or more Linux servers in production, here is the uncomfortable truth: most security incidents do not begin with “advanced hacking.”

They usually start with basic gaps:

• SSH still allows risky patterns,
• old users still have access,
• firewall rules are messy,
• logs are available but never reviewed,
• and incident response steps live only in someone’s head.

This article is a practical server hardening checklist you can run as a monthly baseline audit. It is designed for small teams that need something realistic, not enterprise-heavy theory.

Target keyword: linux security hardening
Search intent (weekly rotation): Best-practice / implementation checklist
Monthly cluster: linux security hardening, server hardening checklist, basic incident response linux, secure shell scripting

The goal is simple: reduce avoidable risk with repeatable steps.

Why baseline audits matter (even when “nothing is wrong”)

Security work is often reactive. Teams only look at hardening after something suspicious happens. That is expensive.

A baseline audit helps you:

1. catch low-effort attack paths early,
2. reduce blast radius if compromise happens,
3. improve incident response speed,
4. and create shared operational standards across the team.

If you already faced suspicious activity, this checklist complements your IR workflow. Related reading: Linux Incident Response Playbook: Practical Troubleshooting and Containment.

Scope: what this checklist covers

We will audit seven layers:

1. SSH access
2. User & privilege hygiene
3. Network exposure
4. Service and package baseline
5. File and script integrity habits
6. Logging & monitoring readiness
7. Recovery and incident preparedness

Use this in staging first, then production with a maintenance window if needed.

1) SSH hardening baseline

SSH is still the most common entry path on Linux servers. Start here.

Quick checks

# Validate effective SSH-related config (including includes)
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding|allowusers|allowgroups'

# See who logged in recently
last -n 20

# Failed login attempts (Debian/Ubuntu)
sudo journalctl -u ssh --since "-24 hours" --no-pager

Recommended baseline

• PermitRootLogin no
• PasswordAuthentication no (key-based auth only)
• MaxAuthTries kept low
• AllowUsers or AllowGroups explicitly defined
• SSH open only from trusted IP/VPN range

For a tactical combination with firewall + brute-force mitigation, see: UFW vs Fail2Ban vs SSH Hardening: Kombinasi Wajib Keamanan Server Linux.

2) User, group, and sudo hygiene

Many teams forget to remove old users after role changes. That creates silent risk.

What to audit

# Human users (UID >= 1000 on many distros)
awk -F: '$3 >= 1000 && $1 != "nobody" {print $1, $3, $6, $7}' /etc/passwd

# Members of sudo/wheel
getent group sudo
getent group wheel

# Accounts with interactive shells
grep -E '/bin/bash|/bin/zsh|/bin/sh' /etc/passwd

Baseline rules

• Every privileged account must have an owner.
• Remove or lock stale accounts immediately.
• Avoid shared admin accounts.
• Enforce least privilege for sudoers.

Also review ~/.ssh/authorized_keys for privileged users and remove unknown keys.

3) Firewall and network exposure review

A lot of “hardened” servers still expose unnecessary ports.

Exposure checks

# Listening ports + owning process
sudo ss -tulpen

# UFW status (if used)
sudo ufw status verbose

# Optional: nftables/iptables overview
sudo nft list ruleset 2>/dev/null | head -n 80
sudo iptables -S 2>/dev/null | head -n 80

Baseline rules

• Keep public ports minimal (usually only 80/443 and controlled SSH).
• Restrict admin interfaces to private/VPN networks.
• Remove temporary allow rules after emergency work.
• Review egress policy for sensitive hosts.

If you run Docker, check published ports (0.0.0.0) so internal services are not accidentally public.

4) Service and package baseline

Old packages and unknown services increase attack surface.

Audit commands

# Failed services
systemctl --failed

# Enabled services (review what should exist)
systemctl list-unit-files --type=service --state=enabled

# Security updates status (Debian/Ubuntu style)
sudo apt update
apt list --upgradable 2>/dev/null | sed -n '1,80p'

Baseline rules

• Disable services you do not use.
• Apply security updates regularly (with rollback plan).
• Keep runtime versions supported.
• Document exception cases (why outdated package is temporarily accepted).

No documentation = no control.

5) Shell scripts and automation safety

Automation is powerful, but unsafe scripts can create security incidents by themselves.

For operational scripts, apply secure shell scripting conventions:

#!/usr/bin/env bash
set -Eeuo pipefail
IFS=$'\n\t'

cleanup() {
  # rollback or temp cleanup
  :
}
trap cleanup EXIT

What to audit in scripts

• Avoid plain-text secrets in script files.
• Validate input variables before using them in commands.
• Prefer explicit paths (/usr/bin/…) in privileged scripts.
• Add logging for important security actions.
• Ensure scripts are idempotent where possible.

Related reading for safe reruns: Idempotent Shell Script: Jalankan Berkali-kali Tanpa Bikin Berantakan.

6) Logging, auditability, and alert readiness

If logging is weak, incident response becomes guesswork.

Minimum logging baseline

# Check journal disk usage
journalctl --disk-usage

# Verify auth log availability
sudo ls -lah /var/log/auth.log 2>/dev/null

# Recent SSH events
sudo journalctl -u ssh --since "-6 hours" --no-pager | tail -n 80

Baseline rules

• Keep enough retention to investigate incidents (not just a few hours).
• Forward logs to central storage if possible.
• Add lightweight alerts for suspicious patterns:
  • repeated failed SSH attempts,
  • sudden privilege escalation events,
  • new listening ports.

For practical CLI habits while triaging, this post is useful: Linux Shell Command yang Sering Dipakai Developer Modern.

7) Basic incident response readiness

You do not need a full SOC to be prepared. You need a clear first-hour protocol.

First-hour readiness checklist

• Contact owner and escalation path documented
• Quick triage commands prepared
• Containment playbook approved
• Credential rotation procedure tested
• Backup restore test completed recently

If your team has never run a drill, start with a 30-minute tabletop scenario. Simulate suspicious SSH activity and practice decision flow.

Suggested monthly audit workflow (90 minutes)

Here is a practical schedule you can actually maintain:

Minute 0–20: Access and identity

• SSH config diff against baseline
• Review privileged users and keys
• Remove stale access

Minute 20–40: Network and services

• Verify listening ports
• Check firewall rules
• Review enabled services and failed units

Minute 40–60: Patching and script review

• Security update status
• Review critical automation scripts
• Confirm secret handling practices

Minute 60–75: Logs and detection

• Confirm log retention
• Sample auth events
• Validate alert channels

Minute 75–90: Report and action items

• Record findings with severity (High/Med/Low)
• Assign owners and deadlines
• Track closure in next cycle

Consistency beats complexity.

Common mistakes teams make

1) Hardening once, then forgetting it

Baseline drift happens quickly after deployments and hotfixes.

2) Confusing “installed tool” with “effective security”

Having Fail2Ban, UFW, or any scanner installed is not enough. Configuration and routine review are what matter.

3) No rollback plan for security changes

A good hardening change can still break production traffic. Always test and define rollback steps.

4) No owner for each security control

Unowned controls silently decay over time.

Copy-paste audit template (for your repo)

Save this as SECURITY_BASELINE_AUDIT.md:

# Security Baseline Audit - YYYY-MM-DD

## 1. SSH Access

- Findings:
- Actions:
- Owner:

## 2. Users & Privileges

- Findings:
- Actions:
- Owner:

## 3. Network Exposure

- Findings:
- Actions:
- Owner:

## 4. Services & Patching

- Findings:
- Actions:
- Owner:

## 5. Scripts & Secrets

- Findings:
- Actions:
- Owner:

## 6. Logging & Alerting

- Findings:
- Actions:
- Owner:

## 7. Incident Readiness

- Findings:
- Actions:
- Owner:

This is simple, but it builds institutional memory fast.

Final takeaway

You do not need a huge budget to improve Linux security posture.

A repeatable linux security hardening baseline audit already gives major wins:

• fewer obvious entry points,
• faster investigation when anomalies appear,
• and better confidence when operating production servers.

Start small, run it monthly, and iterate. Security maturity is built through habits, not panic.

---

FAQ (Schema-ready)

1) How often should we run a Linux security baseline audit?

Monthly is a practical baseline for most small teams. For high-change environments, run critical checks weekly.

2) What should be prioritized first if time is limited?

Prioritize SSH hardening, privileged user review, and exposed port cleanup. These usually give the biggest immediate risk reduction.

3) Is disabling password-based SSH authentication always recommended?

In most production cases, yes. Key-based authentication with strict key management is significantly safer.

4) Do we need expensive SIEM tools to do useful security monitoring?

Not at the start. Strong logging discipline, retention, and simple alerts already improve detection a lot.

5) How do we keep hardening from breaking production?

Use staged rollout, test in staging, maintain rollback commands, and document every security change.