joe curlee

This guide is the third in a series. Read the Part 1 and Part 2 before attempting anything here.

This article bridges the gap between a well-hardened personal Linux system and the configuration baseline used by the NSA, DoD, and other government agencies on RHEL-based systems. Most of what is described here is technically achievable on Debian and MX Linux. Some of it—particularly full FIPS 140-3 compliance and DoD-grade PKI—is not achievable on a personal machine without institutional infrastructure. Where that is the case, this guide explains what the government does and why, so you understand the full picture.

Blunt disclaimer: No configuration of a personal desktop OS will protect you against a patient, well-resourced nation-state attacker with zero-day exploits and physical access capabilities. The purpose of this guide is to close every gap that is closable, to understand exactly what remains open, and to apply the same reasoning—if not always the same tooling—that professional security engineers use.

This guide was written with research assistance by AI, without input from military personnel and as such may not be completely accurate.

---

What the Government Actually Runs

The DoD's primary Linux platform is Red Hat Enterprise Linux (RHEL) hardened to the DISA STIG (Security Technical Implementation Guide) standard. A STIG is a checklist of over 200 security-relevant configuration requirements. Compliance is verified and enforced automatically via SCAP (Security Content Automation Protocol) tooling built into RHEL.

On top of the STIG, classified enclaves add:

• SELinux in MLS (Multi-Level Security) mode — not standard SELinux, but full Bell-LaPadula mandatory access control with information flow restrictions between security domains
• FIPS 140-3 mode — all cryptographic operations must use NSA-approved algorithms implemented in validated modules
• auditd at maximum verbosity with STIG-prescribed rules covering every privilege escalation and file access
• CAC (Common Access Card) smart card hardware authentication for every login
• Air-gapped networks for classified workloads, with cross-domain guards for any data movement between classification levels
• IMA/EVM (Integrity Measurement Architecture / Extended Verification Module) for kernel-level file integrity enforcement

The reason they do not use Void, Artix, or any non-systemd distribution is simple: those distributions have never been through the DoD's Risk Management Framework (RMF) accreditation process. Getting an OS an Authority to Operate (ATO) can take years and millions of dollars. RHEL is pre-certified. There is no business case to start over with an unaccredited OS regardless of its technical merits.

---

Step 1: Eliminate systemd (Use Devuan as Your Base)

The first and most principled divergence from the personal hardening guides: if you are hardening to the maximum degree possible for a private individual, start with Devuan instead of Debian. Devuan is a byte-for-byte fork of Debian with systemd removed and sysvinit as PID 1. Every apt package that does not have a hard systemd dependency works identically.

Installing Devuan instead of Debian eliminates the entire systemd attack surface documented in the companion article: journald's binary log store, systemd-resolved's DNS interception, systemd-homed's credential management, and every D-Bus interface exposed by systemd's peripheral daemons.

All hardening steps in this guide that reference init system commands will use SysVinit syntax. Devuan uses the same package repositories as Debian, so every tool below installs identically via apt.

---

Step 2: SELinux on Debian/Devuan

The NSA's primary hardening mechanism is SELinux in enforcing mode. AppArmor (the Debian default) is path-based and profile-driven. SELinux uses type enforcement: every process, file, socket, and device is assigned a security label, and the policy defines exactly which label-to-label transitions are permitted. A compromised process cannot access anything outside its defined type domain regardless of UNIX permissions.

Installing SELinux on Debian:

sudo apt install selinux-basics selinux-policy-default auditd
sudo selinux-activate

Reboot. The first boot will take significantly longer as SELinux relabels your filesystem. The system will boot in permissive mode by default (logs violations but does not block them).

Review violations before enabling enforcing mode:

sudo audit2why -al

Once you are confident the policy is not blocking legitimate operations, switch to enforcing mode:

sudo setenforce 1

Make it permanent by editing /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=default

Why this matters: With SELinux in enforcing mode, even if an attacker exploits a vulnerability in a running daemon, they are confined to that daemon's type domain. Lateral movement to your SSH keys, your home directory, or other processes requires breaking SELinux policy separately—a substantially harder second exploit.

AppArmor vs. SELinux: You cannot run both simultaneously. Choosing SELinux means removing AppArmor. On Debian, this is a significant operational trade-off—the SELinux policy for Debian is less mature than RHEL's, and you will likely encounter more false positives. For most users, AppArmor is the correct choice. SELinux is the correct choice if your threat model approaches a professional security environment.

---

Step 3: FIPS-Like Cryptographic Hardening

Full FIPS 140-3 compliance requires a purpose-built kernel and validated cryptographic modules—this is not achievable on stock Debian without significant patching. However, you can enforce FIPS-compatible algorithm choices across your system without the formal validation, which closes the same practical vulnerabilities.

Disable weak and deprecated algorithms system-wide:

Edit /etc/ssl/openssl.cnf and add under [system_default_sect]:

MinProtocol = TLSv1.2
CipherString = ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20

This forces all OpenSSL-linked applications (which includes the vast majority of encrypted networking tools on your system) to reject TLS 1.0 and 1.1 and only negotiate forward-secure cipher suites.

Enforce SSH cryptographic minimums:

Edit /etc/ssh/sshd_config and add:

KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

This eliminates all non-forward-secret key exchanges, all CBC-mode ciphers (vulnerable to BEAST and Lucky13 variants), and all MD5 or SHA1-based MACs from your SSH server.

Disable weak kernel crypto:

Add to /etc/sysctl.conf:

# Disable MD4 (used by legacy Samba/NTLM)
net.ipv4.tcp_timestamps = 0

Prevent loading of weak crypto kernel modules by adding them to the module blacklist:

echo "install md4 /bin/false" | sudo tee -a /etc/modprobe.d/blacklist-weak-crypto.conf
echo "install des /bin/false" | sudo tee -a /etc/modprobe.d/blacklist-weak-crypto.conf
echo "install rc4 /bin/false" | sudo tee -a /etc/modprobe.d/blacklist-weak-crypto.conf

---

Step 4: STIG-Level auditd Configuration

The basic auditd setup in the first hardening guide covers common-sense surveillance points. STIG-level auditd is considerably more comprehensive. Replace your /etc/audit/rules.d/audit.rules with the following ruleset, which mirrors the DISA STIG categories:

## Remove any existing rules
-D

## Set buffer size (increase if you see audit backlog warnings)
-b 8192

## Failure mode: 1 = log to kernel log, 2 = kernel panic on audit failure
-f 1

## --- Identity and Authentication ---
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

## --- Privilege Escalation ---
-w /usr/bin/sudo -p x -k privilege_escalation
-w /usr/bin/su -p x -k privilege_escalation
-w /bin/su -p x -k privilege_escalation
-a always,exit -F arch=b64 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setreuid -S setregid -k privilege_escalation

## --- Unauthorized Access Attempts ---
-a always,exit -F arch=b64 -S open -F exit=-EACCES -k access_denied
-a always,exit -F arch=b64 -S open -F exit=-EPERM -k access_denied
-a always,exit -F arch=b32 -S open -F exit=-EACCES -k access_denied
-a always,exit -F arch=b32 -S open -F exit=-EPERM -k access_denied

## --- File Deletion ---
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -k file_deletion
-a always,exit -F arch=b32 -S unlink -S unlinkat -S rename -S renameat -k file_deletion

## --- Module Loading and Unloading ---
-w /sbin/insmod -p x -k module_insert
-w /sbin/rmmod -p x -k module_remove
-w /sbin/modprobe -p x -k module_insert
-a always,exit -F arch=b64 -S init_module -S delete_module -k module_change

## --- Network Configuration Changes ---
-w /etc/hosts -p wa -k network
-w /etc/network/ -p wa -k network
-w /etc/NetworkManager/ -p wa -k network
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k network

## --- Login and Session Tracking ---
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/log/tallylog -p wa -k logins
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/log/btmp -p wa -k session

## --- Cron and Scheduled Tasks ---
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -p wa -k cron

## --- Kernel and Boot ---
-w /etc/sysctl.conf -p wa -k kernel_params
-w /etc/sysctl.d/ -p wa -k kernel_params
-w /boot/grub/grub.cfg -p wa -k bootloader

## --- Make audit rules immutable (requires reboot to change) ---
-e 2

The final -e 2 flag makes the audit rules immutable for the duration of the running session. An attacker who gains root cannot disable or modify auditing without triggering a reboot—which itself gets logged.

Load the new rules:

sudo augenrules --load

---

Step 5: Kernel Module Lockdown

The Linux kernel will load modules on demand from /lib/modules. An attacker with root access can load a malicious kernel module that intercepts system calls, hides processes, or backdoors the kernel at a level below all userspace security tools. Restrict this.

Blacklist unnecessary and dangerous modules:

Create /etc/modprobe.d/security-blacklist.conf:

# Uncommon network protocols (attack surface, rarely needed on a desktop)
install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false
install n-hdlc /bin/false
install ax25 /bin/false
install netrom /bin/false
install x25 /bin/false
install rose /bin/false
install decnet /bin/false
install econet /bin/false
install af_802154 /bin/false
install ipx /bin/false
install appletalk /bin/false
install psnap /bin/false
install p8022 /bin/false
install p8023 /bin/false
install llc2 /bin/false

# Uncommon filesystems (attack surface)
install cramfs /bin/false
install freevxfs /bin/false
install jffs2 /bin/false
install hfs /bin/false
install hfsplus /bin/false
install squashfs /bin/false
install udf /bin/false

# FireWire DMA (physical memory access attack vector)
install firewire-core /bin/false
install thunderbolt /bin/false

Important: Blacklisting thunderbolt will disable Thunderbolt ports entirely. If you use Thunderbolt peripherals, remove that line. Similarly, review the filesystem list—squashfs is used by Snap packages on Ubuntu. This is Debian-centric; adjust for your specific software.

Update the initramfs to apply blacklists at early boot:

sudo update-initramfs -u

Enable kernel lockdown mode (Debian 5.4+):

Kernel lockdown mode restricts what root can do to the running kernel—blocking /dev/mem access, preventing unsigned module loading, and disabling hibernation (which can expose memory to disk). Add to GRUB's kernel command line in /etc/default/grub:

GRUB_CMDLINE_LINUX="lockdown=confidentiality"

Then: sudo update-grub

The confidentiality level is the stricter of the two lockdown modes. It prevents any mechanism that could allow user-space code to read or modify kernel memory.

---

Step 6: IMA/EVM (Integrity Measurement Architecture)

IMA is a kernel subsystem that cryptographically measures every file executed or opened on the system and records those measurements in a tamper-evident log. EVM extends this to protect security-critical extended attributes from offline tampering. Together, they provide runtime file integrity verification at the kernel level—a step above what AIDE provides, which is a periodic offline scan.

IMA/EVM is present in modern Debian kernels but requires configuration to activate.

Enable IMA measurement policy at boot by adding to GRUB in /etc/default/grub:

GRUB_CMDLINE_LINUX="ima_appraise=fix ima_policy=appraise_tcb"

Install the EVM tools:

sudo apt install ima-evm-utils

Initialize EVM keys (requires a TPM or software key; using a TPM is strongly preferred):

sudo evmctl generate --imahash --key /etc/keys/signing_key.pem /path/to/file

IMA/EVM configuration at a full STIG level is a multi-day project requiring careful policy tuning. The above gets you started. The Debian Wiki's IMA page and the Red Hat IMA/EVM documentation are the best references for building out the full policy. This is listed here primarily because it is a core component of government-grade Linux hardening that most personal hardening guides do not mention at all.

---

Step 7: Smart Card / Hardware Key Authentication

DoD systems require CAC (Common Access Card) smart card authentication for every login—a hardware cryptographic token that must be physically present. For personal use, the closest equivalent is a FIDO2 hardware security key (YubiKey, Nitrokey, or equivalent).

Configure PAM for hardware key login:

sudo apt install libpam-u2f

Register your key as your user:

mkdir -p ~/.config/Yubico
pamu2fcfg > ~/.config/Yubico/u2f_keys

Add the following to /etc/pam.d/sudo and /etc/pam.d/login to require the hardware key:

auth required pam_u2f.so authfile=/home/your_username/.config/Yubico/u2f_keys

This requires physical possession of the hardware key to authenticate to sudo or to log in—an attacker who steals your password alone cannot escalate privileges.

For SSH: Modern OpenSSH supports FIDO2 keys natively for key-based authentication. Generate a resident key stored on the hardware token:

ssh-keygen -t ed25519-sk -O resident -C "hardware_key"

---

Step 8: Complete Network Isolation Verification

At this point in the hardening process, audit every external connection your machine makes at idle—before you open a browser or launch any application. This gives you a true baseline.

Use ss to see all current connections:

sudo ss -tulnp

Use nethogs for a per-process bandwidth view:

sudo apt install nethogs
sudo nethogs

If you have OpenSnitch running, review its log of all outbound connection attempts over the past 24 hours. Any process making connections you cannot account for should be investigated immediately.

The standard you are working toward: At idle, a properly hardened machine should have zero outbound connections other than your VPN keep-alive, your dnscrypt-proxy heartbeat to your chosen DNS resolver, and optionally your NTP daemon if you are not routing through a local server.

---

What This Configuration Achieves vs. Government Standards

The honest gap is at the bottom of that table: formal accreditation, institutional PKI infrastructure, and physical air-gapping are not achievable for a private individual. Everything above that line is achievable and is covered in this guide. A machine hardened to this level has a substantially smaller attack surface than virtually any corporate workstation and is, for practical purposes, resistant to every automated and opportunistic attack class.

The remaining exposure is targeted attacks: an adversary who has decided to attack you specifically, has institutional resources, and is willing to invest sustained effort. Against that adversary, no software configuration alone is sufficient. Physical security, operational security, and behavior matter as much as your kernel parameters.

• privacy
• security
• mx linux
• debian
• advanced security
• linux
• systemd

Related Articles

• Hardening Debian for Privacy and Security: Part 2 March 28, 2026 This guide goes deeper. The first guide covered your baseline perimeter. This one covers active monitoring, integrity verification, behavioral controls, and hardening the browser …
• Harden your Raspberry Pi March 27, 2026 If you're using a Raspberry Pi as a server on your home network, this guide will give you some tips on how to harden …
• Hardening Debian for Privacy and Security: Part 1 March 27, 2026 A guide on hardening Debian (and Debian-based distributions like MX Linux or Ubuntu) for security and privacy.