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:
-nand-Pflags: These stoplsoffrom wasting time doing reverse DNS lookups and converting port numbers to names (like changing22tossh). It gives you raw IPs and raw ports fast.- Unintended listeners: If you see Postgres (
5432), MySQL (3306), or Docker internal APIs listening on0.0.0.0(any interface) instead of127.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:
| Flag | Meaning | The Risk |
|---|---|---|
| S | Size Mismatch | The file size differs from the original package. |
| M | Mode Modified | File permissions or symlink targets have changed. |
| 5 | Digest/Hash Failure | Critical. The cryptographic hash changed; the code was modified. |
| T | mTime Mismatch | The 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/passwdto ensure all system service accounts point strictly to/usr/sbin/nologinand onlyroothas a UID of 0. - [ ] Privilege Audit: Verify
/etc/sudoersand/etc/sudoers.d/for unsafeNOPASSWDrules or binaries that permit shell escapes (e.g.,less,vi). - [ ] Group Hardening: Restrict access to high-privilege groups, especially the
dockergroup, which allows full host root directory mounting. - [ ] File Security: Audit SUID/SGID flags using
find / -perm /u+s,g+s 2>/dev/nulland cross-reference unknown binaries against the GTFOBins database. - [ ] Cryptographic Integrity: Execute
dpkg --verifyordebsums -cto confirm that core system utilities and shared libraries haven’t been tampered with. - [ ] Socket Inspection: Map active listening ports with
lsof -iTCP -sTCP:LISTEN -nPwithout triggering outbound DNS lookup leakage. - [ ] Runtime Security: Use
bpftool prog showandbpftool cgroup treeto 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!
