Arch Linux: System Hardening and Security – Best Practices

After the base installation and package management are set up, Arch Linux runs as a lean system — but by default without significant barriers against misconfigurations or external attacks. Arch follows the KISS principle (Keep It Simple, Stupid), which means: security is not an integrated automatic, but lies entirely in the administrator's responsibility.

Minimalism alone does not protect against compromise: A system without restrictive package filtering, with unrestricted sudo privileges or unencrypted block devices offers the same attack surface as any other standard distribution. In a rolling-release environment, constant software changes are added, which require clean package verification and tamper-proof logging.

This guide is part of our Arch Linux series and establishes the operational security foundation for workstations and servers. We address four real attack vectors:

1. Identity & Privileges: Privilege minimization via wheel, sudo hardening, Linux Capabilities, and PAM security modules (pam_faillock, libpwquality).
2. Supply Chain & Package Integrity: Cryptographic signature enforcement in Pacman, GPG web-of-trust, verified HTTPS mirrors, and secure AUR builds in clean chroots.
3. Data at Rest & File System: LUKS2 full-disk encryption with Argon2id, restrictive mount flags (noexec, nosuid, nodev, hidepid), and kernel file system protection (sysctl).
4. Network Exposure & Interfaces: Stateful firewalling with nftables (incl. connection tracking & rate limiting), SSH cryptographic hardening to modern standards, Fail2Ban integration, and cryptographic journal sealing (FSS).

💡 Prerequisites & Scope: A running Arch system with root or sudo access. This article covers fundamental hardening at the operating system and network level. Advanced mechanisms like Mandatory Access Control (AppArmor), kernel hardening (linux-hardened), and container isolation build directly on this foundation in the follow-up article.

System Hardening Layer Model

Security follows the principle of defense in depth. If one security measure fails, the underlying layer catches the attack:

┌─────────────────────────────────────────────────────────────┐
│ 1. NETWORK LEVEL                                            │
│    nftables (Default Drop) | SSH (Keys only) | Fail2Ban     │
├─────────────────────────────────────────────────────────────┤
│ 2. ACCESS & AUTHENTICATION LEVEL                            │
│    wheel group | visudo timeout | libpwquality policies     │
├─────────────────────────────────────────────────────────────┤
│ 3. FILE SYSTEM & KERNEL LEVEL                               │
│    LUKS2 (AES-XTS) | fstab (noexec, nosuid) | fs.protected  │
├─────────────────────────────────────────────────────────────┤
│ 4. AUDIT & MONITORING LEVEL                                 │
│    systemd-journald (Sealing) | Lynis system audits         │
└─────────────────────────────────────────────────────────────┘

1. User Management, PAM & Privilege Minimization

The primary security goal at the operating system level is: prevent direct logins as root, delegate administrative tasks to dedicated user accounts, and restrict privileges to the absolute minimum.

Unprivileged Users and the wheel Group

Under Arch Linux, there is no group named sudo by default. Administrative rights are traditionally delegated via the wheel group.

Create a new administrative user if not already done:

# Create user with home directory and assign to wheel group
sudo useradd -m -G wheel -s /bin/bash adminuser

# Set a strong password
sudo passwd adminuser

Verify the group membership:

id adminuser

The output confirms the UID and membership in the wheel group:

uid=1001(adminuser) gid=1001(adminuser) groups=1001(adminuser),998(wheel)

Lock the direct root account after successful sudo access setup against password logins:

# Lock root password (login only via sudo or SSH keys if allowed)
sudo passwd -l root

Harden Sudo Configuration with visudo

Never edit /etc/sudoers with a regular text editor, but exclusively via visudo. visudo locks the file against simultaneous writes and validates syntax before saving to prevent fatal lockouts.

sudo visudo

Enable administrative rights for members of the wheel group and set restrictive defaults:

# Defaults for increased security
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults timestamp_timeout=10
Defaults passwd_tries=3
Defaults use_pty
Defaults logfile="/var/log/sudo.log"
Defaults log_input, log_output

# Members of the wheel group may execute all commands with password authentication
%wheel ALL=(ALL:ALL) ALL

• timestamp_timeout=10: The sudo cache expires after 10 minutes of inactivity.
• passwd_tries=3: Maximum three password attempts before abort.
• use_pty: Forces execution of sudo commands in a pseudo-terminal (protection against terminal injection attacks).
• log_input, log_output: Logs executed commands and their I/O streams auditably in /var/log/sudo-io/.

Harden PAM Stack: Brute-Force Lockout & Password Quality

Under Arch Linux, PAM (Pluggable Authentication Modules) controls all authentication flows. We configure two essential modules:

1. pam_faillock: Locks accounts after repeated failed attempts (protection against offline and local brute-force attacks).
2. pam_pwquality: Enforces cryptographically robust passwords.

Install libpwquality:

sudo pacman -S libpwquality

Configure the global quality policies in /etc/security/pwquality.conf:

# Minimum password length
minlen = 14

# Minimum number of different character classes (upper, lower, digits, special)
minclass = 3

# Maximum repetition of identical consecutive characters
maxrepeat = 2

# Maximum allowed character sequence from the username
maxsequence = 3

# Dictionary check against known leaks
gecoscheck = 1

Test a password interactively with pwscore:

pwscore
# Prompt: Enter your test password

Configure pam_faillock in /etc/security/faillock.conf:

# Lock after 4 failed attempts
deny = 4

# Failed attempt window: 10 minutes (600 seconds)
fail_interval = 600

# Lock duration: 15 minutes (900 seconds)
unlock_time = 900

# Also enforce for local TTY and SSH sessions
even_deny_root = false

To manually unlock a user before the lock period expires:

# Check failed attempt status
faillock --user adminuser

# Manually reset lock
faillock --user adminuser --reset

Restrict Root Switching with pam_wheel

By default, any user with knowledge of the root password can run su -. Restrict access to su strictly to members of the wheel group in /etc/pam.d/su:

# Uncomment in /etc/pam.d/su:
auth required pam_wheel.so use_uid

Audit SUID and SGID Binaries

Files with the SUID bit set (Set User ID, octal value 4000) run with the file owner's privileges (root), regardless of who executes them. Outdated or unnecessary SUID binaries are a primary target for privilege escalation exploits.

List all SUID/SGID files on the system:

# List SUID files
sudo find / -perm -4000 -type f -exec ls -la {} + 2>/dev/null

# List SGID files
sudo find / -perm -2000 -type f -exec ls -la {} + 2>/dev/null

Typical legitimate SUID programs are /usr/bin/sudo, /usr/bin/passwd, /usr/bin/su, and /usr/bin/pkexec. If your system contains tools not needed by regular users (e.g., network tools like traceroute or old helpers), revoke the SUID bit:

# Remove SUID bit
sudo chmod u-s /usr/bin/chfn
sudo chmod u-s /usr/bin/chsh

Use Linux Capabilities Instead of SUID

Modern Linux systems allow assigning fine-grained kernel privileges (Capabilities) to processes instead of granting full root privileges via SUID across the board.

# Display currently set file system capabilities
sudo getcap -r /usr/bin 2>/dev/null

Example: If a tool should be allowed to bind network sockets without being root, CAP_NET_BIND_SERVICE suffices:

# Set capability instead of SUID
sudo setcap 'cap_net_bind_service=+ep' /path/to/binary

2. Package Management, Repositories & AUR Hygiene

In a rolling-release distribution like Arch Linux, the integrity of software sources is fundamental. Manipulated packages or compromised mirrors must never reach the system unnoticed.

Strict GPG Signature Verification in pacman.conf

Pacman uses GPG signatures to verify package and database integrity. Open /etc/pacman.conf and ensure signatures are enforced without exception:

[options]
# Package signatures must be valid
SigLevel           = Required DatabaseOptional
LocalFileSigLevel  = Optional

# For maximum security on all repositories:
[core]
SigLevel = PackageRequired DatabaseOptional

[extra]
SigLevel = PackageRequired DatabaseOptional

[multilib]
SigLevel = PackageRequired DatabaseOptional

Initialize and update the official Arch keyring:

# Initialize keyring and populate with Arch master keys
sudo pacman-key --init
sudo pacman-key --populate archlinux

# Update keyring
sudo pacman -Sy archlinux-keyring

If a key is expired or invalid, force a refresh:

# Update GPG keys via keyserver
sudo pacman-key --refresh-keys

💡 Practical tip – No Partial Upgrades: Never run pacman -Sy <package> without -u. An incomplete upgrade only synchronizes the package database and installs newer dependencies while the rest of the system remains outdated. This breaks dynamic libraries (shared objects) and leads to system instability. Use pacman -Syu without exception.

Generate Secure HTTPS Mirrors with reflector

Package downloads should exclusively run over encrypted HTTPS mirrors to prevent man-in-the-middle attacks on metadata:

# Install reflector
sudo pacman -S reflector

Generate a sorted, current mirror list for Germany over HTTPS:

sudo reflector \
  --country Germany \
  --latest 15 \
  --protocol https \
  --sort rate \
  --save /etc/pacman.d/mirrorlist

Automate this process via the included systemd timer:

sudo systemctl enable --now reflector.timer

AUR Security: Isolated Builds in Clean Chroots

The Arch User Repository (AUR) contains unmoderated, community-provided PKGBUILD scripts. A malicious PKGBUILD or .install script runs by default with the executing user's privileges.

Best practices for AUR usage:

1. No blind execution of AUR helpers (yay, paru): Before every build, review the contents of the PKGBUILD and any accompanying .install files for suspicious network access (curl, wget) or chmod commands.
2. Isolate AUR builds in clean chroots: Build AUR packages with the official devtools in an isolated chroot environment.

# Install devtools
sudo pacman -S devtools

# Create clean build chroot
mkdir -p ~/chroot
mkarchroot ~/chroot/root base-devel

# Build package in isolated chroot
cd ~/my-aur-package/
makechrootpkg -c -r ~/chroot

This prevents the build process from accessing files in your user directory and leaves no build artifacts on the host system.

CVE and Security Audits for Packages: arch-audit

With arch-audit, you check installed packages directly against the official security database of the Arch Linux Security Admins:

# Install arch-audit
sudo pacman -S arch-audit

Run the audit:

arch-audit

Example output for known vulnerabilities:

Package openssh is affected by CVE-2024-6387. High severity! Update to 9.8p1-1.

Integrate arch-audit as an automated Pacman hook in /etc/pacman.d/hooks/90-arch-audit.hook:

[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Package
Target = *

[Action]
Description = Checking installed packages for known security vulnerabilities (CVEs)...
When = PostTransaction
Exec = /usr/bin/arch-audit

Cache Cleanup with paccache

Pacman by default stores all downloaded package versions in /var/cache/pacman/pkg/. To free disk space without losing rollback capability for emergencies:

# Install pacman-contrib
sudo pacman -S pacman-contrib

# Keep exactly the last 2 versions of each installed package
sudo paccache -r -k 2

# Remove all versions of uninstalled packages
sudo paccache -ruk0

Automate weekly cleanup via the systemd timer:

sudo systemctl enable --now paccache.timer

3. File System & Storage Security

Hardening at the file system level prevents malicious code from being executed from writable directories or physical theft from leading to plaintext data loss.

Restrictive Mount Options in /etc/fstab

Directories like /tmp or /var/tmp are world-writable (mode 1777). Without protective measures, an attacker can place and start executables there.

Configure /tmp as an isolated tmpfs and set restrictive flags in /etc/fstab:

# /etc/fstab hardening configuration

# Root file system
UUID=11111111-1111-1111-1111-111111111111   /           ext4    defaults,noatime                     0 1

# EFI System Partition
UUID=2222-2222                               /boot       vfat    defaults,noexec,nosuid,nodev,umask=0077 0 2

# /tmp in RAM with noexec, nosuid, and nodev
tmpfs                                        /tmp        tmpfs   defaults,noexec,nosuid,nodev,mode=1777,size=2G 0 0

# /var/tmp with noexec
UUID=33333333-3333-3333-3333-333333333333   /var/tmp    ext4    defaults,noexec,nosuid,nodev         0 2

# /home (nosuid and nodev)
UUID=44444444-4444-4444-4444-444444444444   /home       ext4    defaults,nosuid,nodev                0 2

• noexec: Prevents direct execution of binaries on the file system.
• nosuid: Ignores SUID and SGID bits on this partition.
• nodev: Prevents interpretation of block and character devices.
• noatime: Disables access timestamp updates (saves I/O load and SSD wear).

Apply mount changes in running operation without reboot:

sudo mount -o remount /tmp

Process Isolation with hidepid on /proc

By default, any local user can view the command-line arguments of all other processes on the system with ps aux or top — including potentially passed tokens or passwords.

With the mount option hidepid=invisible (or hidepid=2), each user sees only their own processes. Members of a defined group (e.g., wheel or monitoring services) are excluded via gid=:

# Add to /etc/fstab:
proc    /proc    proc    defaults,nosuid,nodev,noexec,relatime,hidepid=invisible,gid=wheel   0 0

Perform remount:

sudo mount -o remount /proc

Full-Disk Encryption with LUKS2 & Argon2id

For mobile devices and sensitive servers, full-disk encryption with LUKS2 (Linux Unified Key Setup) is mandatory. It protects data at rest from unauthorized access upon theft of the storage medium.

Format the partition with modern PBKDF argon2id:

# Initialize partition with LUKS2
sudo cryptsetup luksFormat \
  --type luks2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha512 \
  --pbkdf argon2id \
  --iter-time 3000 \
  /dev/nvme0n1p3

Open the encrypted container and create the file system:

sudo cryptsetup open /dev/nvme0n1p3 cryptroot
sudo mkfs.ext4 -L root /dev/mapper/cryptroot

Check the header information:

sudo cryptsetup luksDump /dev/nvme0n1p3

Always back up the LUKS header to a secure external location:

sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /path/to/luks-header-backup.img

Kernel Protection for Symlinks and Hardlinks (sysctl)

Malicious symbolic links in world-writable directories enable Time-of-Check-to-Time-of-Use (TOCTOU) attacks. Store hardening-relevant kernel parameters in /etc/sysctl.d/50-security.conf:

# Protection against symlink and hardlink exploits in world-writable directories
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2

# Prevents unauthorized core dumps of privileged processes
fs.suid_dumpable = 0

# Memory hardening: Restrict ptrace scope (only direct parent processes)
kernel.yama.ptrace_scope = 2

# Mask kernel pointers in /proc file system
kernel.kptr_restrict = 2

# Block dmesg access for unprivileged users
kernel.dmesg_restrict = 1

# Harden BPF JIT compiler
net.core.bpf_jit_harden = 2

Apply the parameters immediately:

sudo sysctl --system

4. Network Security & Firewall with nftables

A hardened system offers attackers on the network no attack surface. Every open TCP or UDP port is a potential entry point.

Identify Open Ports

Before configuring the firewall, check all active listeners on the system:

sudo ss -tulpn

Explanation of parameters:

• -t: TCP sockets
• -u: UDP sockets
• -l: Listening ports only
• -p: Show associated process name and PID
• -n: Numeric ports (no DNS/service name resolution)

Stop and disable all services that are not strictly required:

# Stop and disable unused service
sudo systemctl stop avahi-daemon.service
sudo systemctl disable avahi-daemon.service

nftables Configuration: Stateful & Default Drop

nftables is the modern Linux kernel subsystem for packet filtering. It replaces iptables, works more resource-efficiently, and offers a structured, performant rule syntax.

Install nftables:

sudo pacman -S nftables

Create a restrictive, production-ready base ruleset in /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    # Defined sets for trusted management IPs (optional)
    set trusted_mgmt {
        type ipv4_addr
        flags interval
        elements = { 192.168.1.0/24, 10.0.0.5 }
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # 1. Allow already established and related connections (stateful)
        ct state established,related accept

        # 2. Drop invalid packets immediately
        ct state invalid drop

        # 3. Allow loopback interface completely
        iif "lo" accept

        # 4. TCP flag check (protection against port scans / XMAS packets)
        tcp flags & (fin | syn | rst | psh | ack | urg) == 0 drop
        tcp flags & (fin | syn) == fin | syn drop
        tcp flags & (syn | rst) == syn | rst drop

        # 5. ICMP / ICMPv6 (rate limited against flood attacks)
        ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded } limit rate 5/second accept
        ip6 nexthdr icmpv6 icmpv6 type { 
            echo-request, echo-reply, destination-unreachable, packet-too-big, 
            time-exceeded, parameter-problem, nd-router-solicit, nd-router-advert, 
            nd-neighbor-solicit, nd-neighbor-advert 
        } limit rate 5/second accept

        # 6. SSH with rate limiting against brute-force (port 22)
        tcp dport 22 ct state new limit rate 10/minute burst 5 packets accept

        # 7. Optional: Web server (HTTP / HTTPS)
        # tcp dport { 80, 443 } ct state new accept

        # 8. Log and drop unauthorized packets (optional for debugging)
        limit rate 3/minute log prefix "nft-drop: " level warn
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Validate the configuration file syntax before activation:

sudo nft -c -f /etc/nftables.conf

Load rules and permanently enable the service:

sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables.service

Verify the active ruleset in the kernel:

sudo nft list ruleset

5. SSH Server Hardening

SSH is the central administration interface on Linux servers. Misconfigurations (e.g., allowing password logins) lead to automated brute-force attacks within minutes on publicly reachable IP addresses.

Key-Based Authentication (Ed25519)

Create a modern Ed25519 key pair on your client machine if not already present:

ssh-keygen -t ed25519 -a 100 -C "adminuser@arch-workstation"

Transfer the public key to your Arch server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub adminuser@your-server-ip

Strict sshd Configuration

Create a dedicated hardening configuration under /etc/ssh/sshd_config.d/99-hardening.conf:

# Completely disable direct root login
PermitRootLogin no

# Disable password authentication (keys only)
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# Strict authentication attempts
MaxAuthTries 3
MaxSessions 3
LoginGraceTime 30

# Disable X11 and forwarding options
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Force re-keying after 1GB traffic or 1 hour
RekeyLimit 1G 1h

# Modern cryptographic suites (Mozilla Modern / BSI Standard)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,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

# Use only Ed25519 host keys (disable RSA if all clients are current)
HostKey /etc/ssh/ssh_host_ed25519_key

# Suppress banner (no OS information leaking)
PrintMotd no
DebianBanner no

# Restrict access to specific groups
AllowGroups wheel

Validate the sshd configuration syntactically before restarting:

sudo sshd -t

⚠️ Lockout protection: Do not close your current SSH session immediately after reloading! Open a second terminal window and test login with your key: ssh -i ~/.ssh/id_ed25519 adminuser@your-server-ip Only when login works cleanly in the second terminal is the configuration safely active.

Reload the SSH daemon:

sudo systemctl reload sshd.service

Brute-Force Defense with fail2ban

fail2ban monitors log files for failed login attempts and temporarily blocks attacking IP addresses via nftables.

# Install fail2ban
sudo pacman -S fail2ban

Create a local configuration /etc/fail2ban/jail.local:

[DEFAULT]
bantime   = 1h
findtime  = 10m
maxretry  = 4
banaction = nftables-multiport
backend   = systemd

[sshd]
enabled   = true
port      = ssh
mode      = aggressive
maxretry  = 3
bantime   = 24h

Enable and start the service:

sudo systemctl enable --now fail2ban.service

Check SSH jail status and blocked IPs:

sudo fail2ban-client status sshd

6. Logging, Tamper Protection & Auditing

A hardened system must log anomalies and attacks traceably so that security incidents can be analyzed promptly.

Configure systemd-journald Persistent and Tamper-Proof

The systemd journal logs kernel and service messages. Configure /etc/systemd/journald.conf:

[Journal]
# Persistent storage under /var/log/journal
Storage=persistent

# Maximum storage limit for logs
SystemMaxUse=1G
SystemKeepFree=2G

# Enable Forward Secure Sealing (FSS)
Seal=yes

# Log rate limiting against denial of service
RateLimitIntervalSec=30s
RateLimitBurst=1000

Enable Forward Secure Sealing (FSS)

Forward Secure Sealing (FSS) cryptographically protects log files against subsequent tampering. Even if an attacker gains root privileges, they cannot unnoticedly modify or delete past log entries.

Initialize FSS:

sudo journalctl --setup-keys

The output provides a verification key:

The sealing key is stored in: /var/log/journal/xxxxxxxxxxxxxxxxxxxx/fss
The verification key is: 3a7f-9b2c-4d1e-8f0a-...

❗ Security notice: Always note and store the verification key at a secure, external location (e.g., password manager). Only the sealing key remains on the server, which cryptographically rotates every 15 minutes.

Regularly verify the integrity of log files:

journalctl --verify --verify-key="3a7f-9b2c-4d1e-8f0a-..."

Expected result for intact logs:

PASS: /var/log/journal/xxxxxxxxxxxxxxxxxxxx/system.journal
PASS: /var/log/journal/xxxxxxxxxxxxxxxxxxxx/user-1001.journal

Comprehensive Security Audits with lynis

lynis scans configurations, kernel parameters, file permissions, and installed packages for vulnerabilities:

# Install lynis
sudo pacman -S lynis

Run a full system scan:

sudo lynis audit system

The scan provides a hardening index (e.g., 78/100) as well as concrete action recommendations:

# Filter warnings and suggestions from the log
sudo grep -E "WARNING|SUGGESTION" /var/log/lynis.log

Best Practice Checklist

Further Resources

Arch Linux: Advanced Security Features and Maintenance Linux Server Hardening: FIDO2, SSH Security and CrowdSec Pacman: The Comprehensive Guide Official Arch Linux Wiki – Security Best Practices nftables Documentation (Arch Wiki)

Conclusion

Security under Linux is not a single switch you flip, but a multifaceted overall concept (defense in depth). By minimizing the attack surface on all levels — from strict PAM rules and restrictive file system mounts to an uncompromising stateful firewall and cryptographically sealed logs via Forward Secure Sealing (FSS) — your system stands on an extremely robust foundation.

Even if an attacker overcomes a single hurdle, downstream mechanisms like hidepid, restrictive sudo policies, and strict SSH configurations prevent network spread or unnoticed privilege escalation.

💡 Practical tip: After major system changes or package installations, regularly run a Lynis scan (sudo lynis audit system). This way you immediately detect newly emerged security gaps or reset default permissions.

In the sixth and final part of our series, we address the advanced system hardening: In Arch Linux: Advanced Security Features and Maintenance we implement Mandatory Access Control with AppArmor, switch to the hardened linux-hardened kernel, isolate container networks via nftables, build a central TLS logging network, and establish a 3-2-1 backup strategy.