// Learning Objectives
- Define system hardening and articulate its purpose in cybersecurity.
- Explain the concept of attack surface and how hardening reduces it.
- Describe the three core principles: least privilege, defence in depth, minimal footprint.
- Distinguish between hardening and patching.
- Set up a safe, isolated lab environment for practice.
What Is System Hardening?
When a Linux operating system is installed, it is configured for maximum compatibility — not maximum security. It ships with services you may never use, default accounts that are predictable, open ports that serve no purpose, and settings tuned for convenience rather than defence.
System hardening is the deliberate process of reconfiguring a system to eliminate all unnecessary exposure. The goal is to make a system do exactly what it needs to do — nothing more. Every extra service, open port, unused account, and default setting is a potential doorway for an attacker.
Think of it this way: a bank vault is not just a strong box. It has multiple locked doors, a time lock, motion sensors, a security guard, and reinforced walls. Remove any one layer and the vault becomes easier to breach. System hardening applies the same layered thinking to an operating system.
Attack Surface: All the points where an attacker could try to enter or extract data. This includes open ports, running services, user accounts, installed software, and configuration settings.
System Hardening: The process of reducing the attack surface by removing unnecessary components, tightening configurations, and applying security controls — making a system harder to compromise.
A default Ubuntu server may have 500+ installed packages, dozens of running services, and multiple open ports — most of which your application will never use. Each is an opportunity for an attacker. A vulnerability in an unused service is just as dangerous as one in your core application. Hardening forces you to consciously justify everything that stays on the system.
The Three Core Principles
Every hardening decision flows from three principles. Master these and you can make sound security decisions in any situation — even those not covered by a checklist.
Least Privilege
Every user, process, and service gets only the minimum permissions needed to function. A web server should not run as root. A developer should not have system-wide sudo access.
Defence in Depth
Layer multiple independent controls. If an attacker bypasses the firewall, access controls still block them. If they gain a user account, they are still blocked from root.
Minimal Footprint
Install, run, and expose only what is necessary. Every extra package and open port is a potential vulnerability. If you do not need it, remove it.
Continuous Review
Hardening is not a one-time event. New vulnerabilities are discovered daily. Systems change over time. Security posture must be revisited regularly.
Download VirtualBox from virtualbox.org and Ubuntu 22.04 LTS Server ISO from ubuntu.com/download/server. Create a VM with at least 2GB RAM and 20GB disk. Use a minimal server installation — no desktop needed.
Before any changes, take a snapshot. This is your safety net — if anything goes wrong during a lab, you can instantly revert to a clean state.
// Knowledge Check — Module 1
- Define "attack surface" in your own words. Give two examples of components that contribute to it.Write your answer below ↓
- Explain the principle of "least privilege." Why would giving every user admin access be a security risk?
- What is the difference between hardening a system and patching it?
// Learning Objectives
- Explain why unnecessary software increases security risk.
- Audit installed packages and identify those not required.
- Safely remove packages including configuration files.
- Identify and remove legacy insecure network protocol packages.
Why Every Installed Package Is a Risk
Every piece of software on a system introduces potential vulnerabilities. Software contains code, and code can have bugs. Some bugs are security vulnerabilities — flaws attackers exploit to gain unauthorised access or escalate privileges.
A default Ubuntu installation includes hundreds of packages for general use. On a dedicated web server, you do not need printing software (CUPS), Bluetooth support, or graphical tools — yet these may be installed and running, silently expanding your attack surface.
The principle: "If it is not needed, it should not be there." This is not about saving disk space — it is about eliminating attack vectors that exist purely by default.
In 2021, a vulnerability in the polkit package (CVE-2021-4034, "PwnKit") let any local user gain root access on virtually every major Linux distribution. Many servers had polkit installed by default — even those that never used it. Servers without polkit were completely unaffected. One unnecessary package, one critical compromise.
apt remove: Removes the program binaries but leaves configuration files on disk. Those leftover configs can cause confusion or occasionally be exploited.
apt purge: Removes the program AND all its configuration files. Always use purge when hardening — leave no traces of packages you have decided to remove.
These packages provide services that transmit data in plain text — every byte, including passwords, visible to any network observer.
| Insecure Package | Risk | Secure Replacement |
|---|---|---|
telnet | All data including passwords sent unencrypted | SSH (OpenSSH) |
ftp | Unencrypted file transfer, credentials exposed | SFTP or SCP |
rsh-client | Remote shell with no encryption | SSH |
rlogin | Remote login with no encryption | SSH |
talk | Unencrypted network chat protocol | N/A — remove |
// Knowledge Check — Module 2
- Why is telnet considered dangerous even on a private internal network?
- What is the difference between
apt removeandapt purge? Which should you use when hardening and why?
// Learning Objectives
- Explain what the Linux kernel is and what sysctl controls.
- Identify kernel parameters relevant to network and memory security.
- Apply and persist hardened sysctl settings with documented rationale.
- Understand the specific attack each parameter mitigates.
The Linux Kernel and Runtime Configuration
The Linux kernel is the core of the OS — the layer between hardware and software. It manages memory, processes, devices, and networking. The kernel decides how the system responds to network packets, how it handles memory, and how processes interact.
Linux exposes kernel settings through a virtual filesystem at /proc/sys/. The sysctl command reads and changes these settings at runtime. Settings persist across reboots when written to files in /etc/sysctl.d/.
Default kernel settings favour compatibility over security. For example, by default the kernel may accept ICMP redirects (used by attackers to manipulate routing) and may not validate packet source addresses (enabling IP spoofing).
SYN Flood (tcp_syncookies): Attacker sends thousands of half-open connection requests, exhausting the server's connection table and making it unreachable. SYN cookies allow the server to handle legitimate connections without maintaining state for incomplete ones.
IP Spoofing (rp_filter): Attacker sends packets claiming to come from a trusted address. Reverse path filtering drops packets whose source address would not be reachable via the interface it arrived on — catching most spoofed packets.
Route Hijacking (accept_redirects): Attacker sends ICMP redirect messages to change your routing table, forcing your traffic through their machine. Disabling redirect acceptance eliminates this attack vector entirely.
Memory Exploits (randomize_va_space): ASLR randomises where code, stack, and heap are placed in memory, making it far harder to predict addresses needed for buffer overflow and return-oriented programming attacks.
We create a new file in /etc/sysctl.d/ rather than editing the main /etc/sysctl.conf. This keeps hardening changes separate, easy to audit, and easy to remove without affecting other settings.
// Knowledge Check — Module 3
- What is a SYN flood attack? How does enabling tcp_syncookies defend against it without breaking legitimate connections?
- What is IP spoofing? Which kernel parameter helps prevent it and how does it work?
- Why is ASLR (kernel.randomize_va_space = 2) a useful defence against memory-based exploits?
// Learning Objectives
- Understand Linux file permissions and their security implications.
- Find and fix world-writable files and dangerous SUID/SGID binaries.
- Harden temporary directories using mount flags.
- Explain and apply the sticky bit to shared directories.
Linux File Permissions — The Foundation of Access Control
Every file and directory in Linux has three permission sets: owner, group, and other (everyone else). Each set includes read (r=4), write (w=2), and execute (x=1). Together they form the access control layer that determines what each user can do with each file.
Misconfigured permissions are one of the most common security issues found during Linux audits. A sensitive file readable by all users leaks information. An executable with the SUID bit set unnecessarily can be abused for privilege escalation.
SUID (Set User ID, bit 4000): When set on an executable, the program runs with the file owner's permissions (often root) — regardless of who launched it. Legitimate use: passwd needs SUID to modify /etc/shadow. Unnecessary SUID binaries on unexpected files are privilege escalation risks.
SGID (Set Group ID, bit 2000): Similar to SUID but for group. When set on a directory, new files inherit the directory's group rather than the creator's group.
Sticky Bit (bit 1000): On a directory, users can only delete or rename their own files — even if the directory is world-writable. Essential for /tmp to prevent users deleting each other's files.
World-Writable File: A file any user can modify. If a privileged process (e.g., a root cron job) reads or executes this file, an attacker can modify it to inject malicious commands.
The /tmp directory is world-writable by design — all users need to create temporary files there. Without the noexec mount flag, an attacker who uploads a malicious script to /tmp can execute it directly. Many privilege escalation techniques specifically target /tmp because it is writable by any user. Mounting /tmp with noexec, nosuid, and nodev eliminates this entire attack class.
Mount flags that harden /tmp:
- noexec — prevents execution of any binary or script from this filesystem
- nosuid — SUID/SGID bits are ignored — stops privilege escalation via files placed here
- nodev — prevents creation of device files — blocks device-based exploits
// Learning Objectives
- Explain what a firewall does and why deny-by-default is the correct posture.
- Audit open ports and map each to its owning service.
- Configure UFW with a deny-by-default policy and explicit allow rules.
- Test and verify firewall rules are working correctly.
What Is a Firewall and Why Is Port Control Critical?
A firewall is a security control that monitors and filters network traffic based on defined rules. It sits between your system and the network, deciding which connections are permitted and which are blocked.
Every open network port is a potential entry point. Automated scanners continuously search the internet for open ports, then attempt to exploit whatever service is listening. The fewer ports you expose, the smaller your network attack surface.
The golden rule: deny all traffic by default, then explicitly allow only what is required. This approach is categorically safer than allowing everything and trying to block known-bad traffic, because attackers constantly find new attack methods that no blocklist covers yet.
Shodan.io and similar scanners index the entire public internet continuously. A new server with a public IP address will receive its first automated port scan within minutes of going online. A default Ubuntu server may expose ports for printing (631), RPC (111), and other services that have no place on a web server. Each gives an attacker another target to probe and potentially exploit.
| Port | Service | Needed on Server? | Action |
|---|---|---|---|
| 22 | SSH | Yes | Keep — harden in Module 8 |
| 80/443 | HTTP/HTTPS | Only if web server | Allow only if running web server |
| 631 | CUPS Printing | No | Disable CUPS service |
| 111 | rpcbind | Only for NFS | Disable unless NFS is required |
| 25 | SMTP | Only if mail server | Disable unless running mail |
// Learning Objectives
- Audit all user accounts and identify unnecessary or dangerous ones.
- Enforce a strong password policy using PAM and pwquality.
- Configure account lockout after repeated failed login attempts.
- Apply password ageing to limit the lifespan of compromised credentials.
Why User Account Hygiene Is Critical
User accounts are the identity layer of a system. Attackers targeting a system will almost always try to compromise or create user accounts. Common techniques include brute-forcing passwords, exploiting default accounts, escalating from a low-privilege account to root, and creating backdoor accounts during an intrusion.
Every account should have a clear, current purpose. A departed employee's account, a decommissioned service account, or a default vendor account that was never removed — each is a potential entry point that should no longer exist.
Password brute-force attacks are automated and fast. Modern GPUs can test billions of password combinations per second against offline password hashes. A 6-character password can be cracked in seconds. A 14+ character password with mixed complexity requires centuries of compute time with current hardware. Online lockout policies make remote brute-force practically impossible regardless of password length, by blocking the attacker after just a few attempts.
PAM (Pluggable Authentication Modules) is Linux's authentication framework. The pam_pwquality module enforces quality requirements when passwords are set, rejecting weak passwords before they are accepted.
Password ageing limits how long a compromised credential remains useful. If an attacker steals a hash that takes weeks to crack, an expiry policy ensures the password has changed by the time they crack it.
// Learning Objectives
- Explain why unnecessary running services increase risk.
- Audit all running and enabled services.
- Understand the security difference between disabling and masking a service.
- Identify which services are appropriate for different server roles.
Services as an Attack Surface
A service (or daemon) is a background process that runs continuously, waiting to perform a task — often handling network requests. Every running service is a potential attack target. If a service has a vulnerability, an attacker can exploit it to gain a foothold on the system.
A fresh Ubuntu install may run 40+ services by default. On a dedicated web server, printing (CUPS), Bluetooth, mDNS announcer (Avahi), and NFS support (rpcbind) all start automatically — none of them needed, all of them potential vulnerabilities.
Disable: Stops automatic start at boot. The service can still be started manually or triggered by other services. Use when you might occasionally need the service.
Mask: Creates a symlink to /dev/null. The service cannot start by any means — automatic or manual — until explicitly unmasked. Use for services that should NEVER run on this system under any circumstances.
The 2017 WannaCry ransomware exploited SMBv1 — a file sharing protocol. Hundreds of thousands of systems had SMBv1 running even though they were not used as file servers. Systems where SMB was disabled or removed were completely immune. One unnecessary service: a global ransomware pandemic affecting 200,000+ computers across 150 countries.
// Learning Objectives
- Explain why SSH is a high-value attack target and what brute-force means.
- Generate an SSH key pair and configure key-based authentication.
- Harden sshd_config to disable root login and password authentication.
- Apply connection limits, timeouts, and logging improvements.
Why SSH Is the Most Targeted Service on the Internet
SSH (Secure Shell) is the standard tool for remote Linux server administration. Because it provides full system access and is universally deployed, it is one of the most targeted services on the internet. Automated bots continuously scan for port 22 and attempt logins using lists of common usernames and passwords — this is called a credential stuffing or brute-force attack.
SSH key-based authentication replaces passwords with cryptographic key pairs. The private key stays on your local machine. The public key is placed on the server. Authentication proves possession of the private key using mathematics — no password transmitted, no password to brute-force. An attacker without your private key file cannot log in, regardless of what they try.
A new cloud server typically receives its first automated brute-force SSH attempt within minutes of going online. Logs on default-configured servers routinely show thousands of failed login attempts per day from bots. The only thing protecting a server with password authentication is whether anyone guesses correctly. Disabling password authentication entirely eliminates this whole attack category — bots cannot brute-force a login method that does not exist.
sshd -t before restarting. Keep your current SSH session open while testing in a new session. A broken sshd_config can lock you out.// Learning Objectives
- Explain the difference between Discretionary and Mandatory Access Control.
- Describe what AppArmor is and how it confines applications.
- Check AppArmor status and understand enforce vs complain modes.
- Enable and enforce AppArmor profiles for common services.
Discretionary vs Mandatory Access Control
Discretionary Access Control (DAC) — the traditional Linux permission model — lets file owners decide who can access their files. It is flexible but has a critical weakness: if a process runs as root, or as a user with broad permissions, it can access anything that user can access. A compromised root process has no additional restrictions.
Mandatory Access Control (MAC) operates independently above DAC. Even a root process is constrained by MAC policies defined by the administrator. MAC specifies exactly what each application is allowed to access — and blocks everything else, regardless of the process's user identity.
AppArmor is Ubuntu's built-in MAC system. It assigns each application a profile — a whitelist of permitted file paths, capabilities, and network operations. If a web server is exploited and an attacker tries to read /etc/shadow, AppArmor blocks it because that path is not in the web server's profile.
In 2014, Shellshock allowed code execution through bash. Systems with proper MAC confinement limited the blast radius — even with arbitrary code execution, the compromised processes could not access files or make network connections outside their AppArmor profiles. MAC converts a full system compromise into a contained, limited breach. It is already installed and active on Ubuntu — you just need to ensure all profiles are in enforce mode.
// Knowledge Check — Modules 7–9
- What is the difference between systemctl disable and systemctl mask? Give a real-world example of when you would use each.
- Why is disabling password authentication for SSH more secure than simply having a strong password?
- Explain MAC in plain language. Why is it powerful even against a process running as root?
// Learning Objectives
- Explain why direct root login is dangerous and how sudo improves on it.
- Configure sudoers to grant least-privilege access to specific commands only.
- Enable sudo logging to create an audit trail of every privileged command.
- Identify and remediate dangerous sudo misconfigurations.
The Purpose and Risks of sudo
sudo (superuser do) lets authorised users run commands as root without logging in as root directly. This is a major security improvement: every sudo use is logged by default, users authenticate with their own password rather than the root password, and access can be restricted to specific commands.
However, sudo itself can be misconfigured. Granting a user unrestricted sudo (ALL=(ALL:ALL) ALL) is effectively the same as giving them the root password. The NOPASSWD directive removes even the authentication step. Granting sudo access to text editors, file viewers, or scripting tools enables privilege escalation via their built-in shell escape features.
GTFOBins (gtfobins.github.io) is a security research database documenting how common Unix binaries can be abused for privilege escalation. If a user has sudo vim, they can type :!/bin/bash inside vim to get a root shell. sudo find . -exec /bin/sh \; works the same way with find. The fix: grant sudo access only to the exact commands a user needs for their role — never to general-purpose tools.
// Learning Objectives
- Explain what the GRUB bootloader is and why it requires protection.
- Identify the single-user mode bypass attack and its impact.
- Password-protect GRUB using a hashed credential.
What Is GRUB and Why Does It Need a Password?
The GRUB bootloader is the first software that runs when a Linux system powers on. It lets you select which OS or kernel to boot and provides access to advanced boot modes including single-user mode (also called recovery mode) — a minimal root shell with no login prompt.
Without a GRUB password, anyone with physical or console access can boot into single-user mode and gain a full root shell in under three minutes. Every other hardening measure becomes irrelevant — file permissions, account controls, AppArmor — none of them apply to someone sitting at a root shell before the full OS has loaded.
This attack requires console or physical access, not network access. But in cloud environments, virtual console access (out-of-band management, KVM, IPMI) may be accessible to a wider group than SSH. Data centres may also have inadequate physical security. GRUB hardening closes this gap.
Single-user mode bypass is a standard technique in both penetration testing and real-world attacks. It is used to reset root passwords, extract data, install backdoors, and bypass all login controls. It is one of the fastest ways to take full control of a Linux system. A server that is perfectly hardened at the OS level can be completely compromised in minutes by anyone who can reach a console without GRUB protection.
Never store plain-text passwords in GRUB configuration. PBKDF2 creates a one-way hash that GRUB can verify without storing the actual password.
// Learning Objectives
- Define encryption at rest and explain when it is necessary.
- Describe how LUKS works conceptually.
- Create and manage a LUKS-encrypted volume.
- Understand the relationship between encryption and other security controls.
What Is Encryption at Rest?
Encryption at rest means data stored on disk is encrypted — unreadable without the correct key, even if someone physically removes the storage device and connects it to another machine. All network security and access controls cannot protect data if an attacker can simply take the hard drive.
LUKS (Linux Unified Key Setup) is the standard disk encryption framework on Linux. It creates an encrypted block device on a partition. When the device is "opened" (unlocked) with the correct passphrase, the OS sees it as a normal filesystem. Without the key, the data is indistinguishable from random noise — mathematically infeasible to decrypt.
Compliance: PCI-DSS requires encryption of cardholder data at rest. HIPAA requires encryption of protected health information. GDPR strongly recommends encryption as a safeguard for personal data.
Physical risk: Laptops are stolen. Server drives are sometimes removed from data centres. Cloud providers have physical access to the underlying hardware. Encryption ensures that physical access to media does not equal access to data.
Defence in depth: If every other security control fails and an attacker obtains the raw storage media, encryption is the final barrier between them and your data.
Add a second virtual disk to your VM in VirtualBox settings (1GB is sufficient for this lab) before starting.
// Knowledge Check — Modules 10–12
- A junior sysadmin gives a developer the following sudo rule:
devuser ALL=(ALL) NOPASSWD: ALL. What is wrong with this? How would you fix it? - Why is GRUB password protection important even on a server with strong SSH hardening?
- A company stores medical records on a server. Explain why disk encryption is important even if the server has a firewall, strong passwords, and AppArmor enabled.
// Learning Objectives
- Explain why logging is a critical component of a security strategy.
- Configure auditd to log specific security-relevant system events.
- Identify and use key Linux log files for security analysis.
- Set up fail2ban to automatically block brute-force attacks.
Logging: Your Security Eyes and Ears
Hardening reduces the probability of a successful attack, but no system is impenetrable. When an attack occurs — or is attempted — logs are how you find out. They record who did what, when, from where, and whether they succeeded. Without comprehensive logging, you are blind to attacks in progress and unable to investigate incidents after they occur.
auditd is the Linux kernel audit daemon. It intercepts and records system calls — the low-level operations every program must perform. By writing audit rules, you can be alerted any time a sensitive file is modified, a privileged command is executed, or a user account is changed.
Fail2ban monitors log files for patterns of malicious behaviour and automatically adds firewall rules to block the offending source. It converts passive logging into active defence.
The average time between a breach occurring and it being detected has historically been measured in months. Comprehensive logging dramatically shrinks this window. A user account logging in at 3am, a configuration file being modified outside maintenance windows, or a privileged command from an unexpected account — these anomalies are visible in logs and can trigger alerts. Without logs, even post-incident forensics is nearly impossible, leaving you unable to understand what was compromised, how, or for how long.
| Log File | What It Contains |
|---|---|
/var/log/auth.log | All authentication: SSH logins, sudo, su, PAM events |
/var/log/syslog | General system messages from kernel and services |
/var/log/ufw.log | Firewall blocks and allows |
/var/log/audit/audit.log | Kernel-level audit events (file access, system calls) |
/var/log/faillog | Failed login attempt counter per user |
/var/log/sudo.log | All sudo commands (if configured in sudoers) |
// Learning Objectives
- Define file integrity monitoring and explain its purpose.
- Explain what a cryptographic hash is and why it detects tampering.
- Initialise AIDE to create a known-good baseline of the system.
- Run integrity checks and correctly interpret changed-file reports.
What Is File Integrity Monitoring?
File Integrity Monitoring (FIM) answers a critical security question: "Has anything on this system changed that should not have?"
FIM works by taking a cryptographic snapshot of every important file when the system is in a known-clean state. A cryptographic hash function (such as SHA-256) generates a unique fixed-length fingerprint from a file's contents. If even one byte changes — whether from a legitimate update, accidental corruption, or an attacker modifying a system binary to install a backdoor — the hash changes. Comparing current hashes to the stored baseline immediately reveals any unauthorised modification.
AIDE (Advanced Intrusion Detection Environment) is a free, open-source FIM tool. It records file content hashes, permissions, ownership, timestamps, and other attributes. Any deviation from the baseline is flagged as a potential intrusion or unauthorised change.
Sophisticated attackers who gain root access often modify system binaries to maintain persistent access — replacing /usr/sbin/sshd with a backdoored version that accepts a secret password, or replacing /bin/ls with a version that hides their files. Without FIM, you may never notice. With AIDE, the modification appears immediately on the next check because the file hash no longer matches the baseline. FIM is your defence against this class of attack, and is often required by compliance frameworks like PCI-DSS and HIPAA.
// Knowledge Check — Modules 13–14
- What is a cryptographic hash function? Why does it make file tampering detectable?
- When should you update the AIDE baseline? What is the risk of updating it carelessly after an incident?
- How does fail2ban complement static firewall rules? What attack does it specifically defend against?
// Learning Objectives
- Explain why manual hardening does not scale and automation is essential.
- Run a full Lynis security audit and interpret the results.
- Write a comprehensive hardening shell script covering all previous modules.
- Understand the role of CIS Benchmarks as an industry standard.
Why Automation Is a Security Requirement, Not a Convenience
Manually hardening one server takes hours and introduces human error. A missed step, a typo in a config file, or simply forgetting a module means inconsistent protection. An organisation managing tens, hundreds, or thousands of servers cannot harden them by hand and maintain consistency.
Automation solves this: write the hardening logic once, test it, and apply it uniformly to every server. It is auditable (you can see exactly what was applied), repeatable (a freshly rebuilt server gets the same treatment), and consistent (no forgotten steps).
CIS Benchmarks are industry-standard security configuration guidelines published by the Center for Internet Security. They are the most widely adopted hardening reference globally, with specific technical guidance for every major OS, cloud platform, and application. Many compliance frameworks (PCI-DSS, HIPAA, SOC 2) explicitly reference CIS Benchmarks.
Lynis is an open-source auditing tool that evaluates a system against a large set of security checks, produces a hardening index score, and gives prioritised, specific recommendations. It is the fastest way to get an objective picture of a system's security posture.
// Lynis Reflection Exercise
- Initial Lynis score (before any hardening):
- Your top 5 Lynis suggestions:
- Score after completing all 14 previous modules:
- Which single improvement had the greatest impact on your score?
Create a single reusable script that automates the core hardening steps from all previous modules. This is how production environments are hardened at scale — one tested script, applied consistently to every server.
Complete all tasks independently, in any order:
// Final Reflection
- Before this workbook, how would you have described system hardening? How has your understanding changed?
- Which hardening technique has the highest impact for the least effort? Justify your answer.
- Describe a scenario where hardening alone is insufficient. What complementary controls are needed?
- If you needed to harden 50 servers for a new organisation, what would your approach be? What tools and processes would you use?
- Which module topic do you want to explore further? Why?
| Category | Command | Purpose |
|---|---|---|
| Packages | apt purge <pkg> | Remove package and all config files |
| Kernel | sysctl --system | Apply all /etc/sysctl.d/ settings |
| Ports | ss -tulnp | List all listening services with PID |
| Firewall | ufw status verbose | Show all firewall rules and policy |
| Services | systemctl mask <svc> | Permanently prevent a service from running |
| Users | passwd -l <user> | Lock a user account |
| SSH | sshd -t | Validate SSH config syntax before restart |
| AppArmor | aa-enforce /etc/apparmor.d/* | Enforce all AppArmor profiles |
| Sudo | visudo -f /etc/sudoers.d/user | Safely edit per-user sudo rules |
| Encryption | cryptsetup luksFormat /dev/sdb | Create LUKS encrypted volume |
| Audit | ausearch -k <key> | Search audit log by rule key |
| Fail2ban | fail2ban-client status sshd | SSH jail status and banned IPs |
| AIDE | aide --check | Run file integrity check vs baseline |
| Lynis | lynis audit system | Full system security audit with score |
| Permissions | find / -perm -4000 2>/dev/null | Find all SUID binaries |
| Permissions | find / -perm -002 2>/dev/null | Find world-writable files |