Linux Security Checklist: Essential Command-Line Tools for Auditing

L

When managing fleet security—whether it’s production servers or a batch of developer laptops—we often rely on automated tools. But automated scanners can miss context, and sometimes you just need to drop into the terminal and see exactly what is running on a machine.

This guide provides a practical, command-first Linux security checklist. These are the exact commands used to audit company laptops and personal machines, paired with standard hardening baselines to keep systems locked down.

1. Administrative Privileges & Group Membership

Keep a very tight leash on who belongs to high-privilege groups such as sudo, wheel, root, or docker. Being in the docker group is practically equivalent to having root access—anyone in that group can spin up a container, mount the host’s root directory, and fully compromise the physical host.

Analyze your /etc/sudoers file and any files inside /etc/sudoers.d/. Search for configuration mistakes that allow users to run binaries without password verification (NOPASSWD). Be especially paranoid about binaries that support shell escapes (like less, vi, or compilers). If a user can run these under sudo, they can easily break out of their restricted environment and spawn a root console.

2. Network Exposure & Open Ports

An exposed port is an open door. The first step in any laptop or server audit is checking what services are listening for incoming connections.

Run these two commands to get a clear view of your networking layer:

sudo lsof -iTCP -sTCP:LISTEN -n -P

What to look for:

  • -n and -P flags: These stop lsof from wasting time doing reverse DNS lookups and converting port numbers to names (like changing 22 to ssh). It gives you raw IPs and raw ports fast.
  • Unintended listeners: If you see Postgres (5432), MySQL (3306), or Docker internal APIs listening on 0.0.0.0 (any interface) instead of 127.0.0.1 (localhost) on a local laptop, lock it down immediately.

3. Process Tracking & Active Services

Malicious persistence relies on hiding in plain sight as a background service. You need to inspect what is actually running right now.

# Snapshot of every process running on the system
ps -ef

# List all active systemd services
systemctl --type service

# Explicitly check your local endpoint protection status - hope you have it :) 
sudo systemctl status clamav-daemon

The Peer Check: Don’t just look at the process names. Look at the parent process IDs (PPIDs). A suspicious process mimicking a kernel thread but spawned by a non-root user shell is an immediate red flag.

Inspect /etc/passwd. Every service-specific or system account (like those used for SFTP, Samba/CIFS, or databases) must be locked out of interactive shell access. They should explicitly use a non-interactive shell placeholder: /usr/sbin/nologin.

Additionally, you must verify that no account other than root possesses a User ID (UID) of 0. If you spot a rogue account with a UID of 0, your system has already been backdoored.

4. File System Integrity & Package Auditing

Before trusting the tools on a system, you have to verify that the system packages themselves haven’t been tampered with or modified by an attacker.

# Step 1: Identify your OS baseline
cat /etc/os-release

# Step 2: Verify the cryptographic integrity of all installed system files
sudo dpkg --verify

When you run dpkg --verify (or rpm -V on RedHat-based systems), the tool checks local file hashes against the original repository state. This compares your local files against the original metadata database. If you want a quick, silent audit that only reports errors/mismatches, use debsums:

debsums -c

Deciphering the Integrity Flags

If a file has changed, you will see a string of characters instead of a clean pass (.). Keep an eye out for these critical markers:

FlagMeaningThe Risk
SSize MismatchThe file size differs from the original package.
MMode ModifiedFile permissions or symlink targets have changed.
5Digest/Hash FailureCritical. The cryptographic hash changed; the code was modified.
TmTime MismatchThe file modification time does not match original records.

If you need to visually navigate dependencies or cleanup orphaned software packages during your audit, an interactive package browser makes life easier:

sudo apt install aptitude
sudo aptitude

Securing your system package repositories is only half the battle. Many vulnerabilities hide in application-level dependencies downloaded via pip or npm. Enforcing Software Bill of Materials (SBOM) tracking, tracking application CVE hazards, and verifying GPG signatures across all custom repositories is essential to keep your software supply chain risk as close to zero as possible.

5. Hunting Privileged Executables (SUID/SGID)

Files with SUID (Set User ID) or SGID (Set Group ID) permissions execute with the privileges of the file owner (often root) rather than the user calling them. Attackers use misconfigured SUID binaries to break out of unprivileged accounts.

To locate every privileged file on the system, use:

find / -type f -perm +6000 2>/dev/null

Note on Syntax: Depending on your version of find, you can also use find / -perm /u+s,g+s 2>/dev/null. This safely discards “Permission Denied” errors and surfaces only binaries with high-privilege execution flags. Cross-reference any custom binaries you find here against databases like GTFOBins to ensure they can’t be exploited for shell escapes.

6. Next-Gen Observability: Kernel Audit via eBPF

Traditional rootkits can manipulate ps or lsof to hide their own processes and ports. To bypass user-space deception, go straight to the Linux kernel using eBPF (Extended Berkeley Packet Filter).

First, install the necessary kernel tools matching your runtime environment:

sudo apt install linux-tools-common
sudo apt install linux-tools-5.15.0-139-generic linux-cloud-tools-5.15.0-139-generic

Once installed, use bpftool to inspect programs loaded directly into kernel space:

# List all active eBPF programs loaded into the kernel
sudo bpftool prog

# View the eBPF control group tree to see where programs are attached
bpftool cgroup tree

By auditing at the eBPF layer, you can see exactly what programs are monitoring network sockets or system calls directly inside the kernel, rendering user-space rootkits completely visible.

7. Immutable Logs & Boot Integrity

When a system is compromised, the first thing an attacker does is clear local logs to hide their tracks. If your logs aren’t forwarded instantly, you are flying blind.

Secure Log Transmission with RELP

While standard loggers use rsyslog or systemd-journald, sending logs over standard UDP or TCP syslog is risky due to potential packet loss. To prevent this, implement RELP (Reliable Event Logging Protocol) in your rsyslog configuration. RELP provides application-level delivery confirmation, guaranteeing that no critical audit lines are silently dropped during network anomalies.

Hardware, Bootloader, and Persistence Security

Logical security means nothing if an attacker gets physical access or infects the hardware firmware.

  • UEFI Secure Boot: Enforce cryptographically signed bootloader verification to ensure only trusted GRUB binaries and Linux kernels can execute, preventing early-boot malware injection.
  • Full Disk Encryption (FDE): Always encrypt your main storage partitions using LUKS. If your laptop is stolen or the SSD is extracted, your code, API keys, and corporate data remain completely unreadable.

The Ultimate Linux Security Auditing Checklist

  • Before wrapping up, use this copy-pasteable, actionable summary checklist to audit your server or development workstation today:
  • [ ] Identity Check: Run cat /etc/passwd to ensure all system service accounts point strictly to /usr/sbin/nologin and only root has a UID of 0.
  • [ ] Privilege Audit: Verify /etc/sudoers and /etc/sudoers.d/ for unsafe NOPASSWD rules or binaries that permit shell escapes (e.g., less, vi).
  • [ ] Group Hardening: Restrict access to high-privilege groups, especially the docker group, which allows full host root directory mounting.
  • [ ] File Security: Audit SUID/SGID flags using find / -perm /u+s,g+s 2>/dev/null and cross-reference unknown binaries against the GTFOBins database.
  • [ ] Cryptographic Integrity: Execute dpkg --verify or debsums -c to confirm that core system utilities and shared libraries haven’t been tampered with.
  • [ ] Socket Inspection: Map active listening ports with lsof -iTCP -sTCP:LISTEN -nP without triggering outbound DNS lookup leakage.
  • [ ] Runtime Security: Use bpftool prog show and bpftool cgroup tree to uncover hidden kernel tracing hooks or container escape vectors.
  • [ ] Storage Protection: Confirm all primary local partitions use Full Disk Encryption via LUKS to prevent unauthorized physical data extraction.

Conclusion

Hardening a Linux system isn’t a set-it-and-forget-it task. It’s a continuous process of verification. While static package checks like dpkg --verify are excellent for identifying changes to the files sitting on your drive, modern system auditing requires monitoring live kernel behaviors using tools like bpftool. Running these runtime tracing checks is how you spot real, resident threats attempting to establish silent persistence on your machines.

Apply these configurations, run these commands on your laptops, and see what you find! Stay safe out there, and see you in the next post!

About the author

sergii-demianchuk

Software engineer with over 18 year’s experience. Everyday stack: PHP, Python, Java, Javascript, Symfony, Flask, Spring, Vue, Docker, AWS Cloud, Machine Learning, Ansible, Terraform, Jenkins, MariaDB, MySQL, Mongo, Redis, ElasticSeach. Udemy instructor with over 35K students.

architecture AWS cluster cyber-security devops devops-basics docker elasticsearch flask geo high availability java machine learning opensearch php programming languages python recommendation systems search systems spring boot symfony

Privacy Overview
Sergii Demianchuk Blog

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

3rd Party Cookies

This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.

Keeping this cookie enabled helps us to improve our website.