---
id: 2025-11-15-arch-linux-system-hardening-security-best-practices
slug: arch-linux-system-hardening-security-best-practices
title: "Arch Linux: System Hardening and Security – Best Practices"
excerpt: "Deep system hardening for Arch Linux: PAM policies, sudo hardening, SUID/Capabilities, Pacman integrity, LUKS2 with Argon2id, fstab flags, nftables ruleset, SSH crypto, and journald FSS."
date: "2025-11-15T09:00:00+01:00"
updated: "2026-08-27T20:30:00+02:00"
author:
  name: "Sebastian Palencsar"
  handle: "spalencsar"
category: "arch-linux-serie"
tags: ["arch-linux", "systemhaertung", "sicherheit", "nftables", "ssh", "luks", "sudo", "pam", "fail2ban", "lynis"]
toc: true
reading_time: 45
---

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.

<span class="nb-accent">Minimalism alone does not protect against compromise:</span> 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](/en/category/arch-linux-serie){.badge-link-text} 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).

<blockquote class="infobox infobox--info">
💡 **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](/en/arch-linux-serie/arch-linux-advanced-security-features-and-maintenance){.badge-link-text}.
</blockquote>

## System Hardening Layer Model

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

```markdown
┌─────────────────────────────────────────────────────────────┐
│ 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:

```bash
# 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:

```bash
id adminuser
```

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

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

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

```bash
# 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.

```bash
sudo visudo
```

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

```ini
# 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`:

```bash
sudo pacman -S libpwquality
```

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

```ini
# 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`:

```bash
pwscore
# Prompt: Enter your test password
```

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

```ini
# 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:

```bash
# 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`:

```ini
# 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:

```bash
# 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:

```bash
# 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.

```bash
# 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:

```bash
# 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:

```ini
[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:

```bash
# 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:

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

<blockquote class="infobox infobox--info">
💡 **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.
</blockquote>

### Generate Secure HTTPS Mirrors with `reflector`

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

```bash
# Install reflector
sudo pacman -S reflector
```

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

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

Automate this process via the included systemd timer:

```bash
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.

```bash
# 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:

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

Run the audit:

```bash
arch-audit
```

Example output for known vulnerabilities:

```bash
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`:

```ini
[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:

```bash
# 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:

```bash
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`:

```ini
# /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:

```bash
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=`:

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

Perform remount:

```bash
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`:

```bash
# 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:

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

Check the header information:

```bash
sudo cryptsetup luksDump /dev/nvme0n1p3
```

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

```bash
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`:

```ini
# 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:

```bash
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:

```bash
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:

```bash
# 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`:

```bash
sudo pacman -S nftables
```

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

```ini
#!/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:

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

Load rules and permanently enable the service:

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

Verify the active ruleset in the kernel:

```bash
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:

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

Transfer the public key to your Arch server:

```bash
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`:

```ini
# 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:

```bash
sudo sshd -t
```

<blockquote class="infobox infobox--warn">
⚠️ **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.
</blockquote>

Reload the SSH daemon:

```bash
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`.

```bash
# Install fail2ban
sudo pacman -S fail2ban
```

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

```ini
[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:

```bash
sudo systemctl enable --now fail2ban.service
```

Check SSH jail status and blocked IPs:

```bash
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`:

```ini
[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:

```bash
sudo journalctl --setup-keys
```

The output provides a **verification key**:

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

<blockquote class="infobox infobox--practice">
❗ **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.
</blockquote>

Regularly verify the integrity of log files:

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

Expected result for intact logs:

```bash
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:

```bash
# Install lynis
sudo pacman -S lynis
```

Run a full system scan:

```bash
sudo lynis audit system
```

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

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

## Best Practice Checklist

| Area | Measure | Configuration File / Tool |
|------|---------|---------------------------|
| **Identity** | Unprivileged user + `wheel` | `useradd -m -G wheel`, `/etc/sudoers` |
| **Sudo Hardening** | Timeout & I/O logging | `visudo` (`timestamp_timeout=10`, `use_pty`) |
| **Passwords** | Minimum 14 characters & complexity | `/etc/security/pwquality.conf` |
| **Local Brute-Force** | Account lock after 4 failed attempts | `/etc/security/faillock.conf` |
| **Package Management** | Strict GPG signature verification | `/etc/pacman.conf` (`SigLevel = Required`) |
| **Mirrors** | HTTPS mirrors with automatic update | `reflector.timer`, `/etc/pacman.d/mirrorlist` |
| **File System** | `noexec`, `nosuid` on `/tmp` & `/var/tmp` | `/etc/fstab` |
| **Processes** | Hidden foreign processes | `proc` mount with `hidepid=invisible` |
| **Disk** | LUKS2 with Argon2id PBKDF | `cryptsetup luksFormat --type luks2` |
| **Kernel** | Symlink/hardlink protection | `/etc/sysctl.d/50-security.conf` |
| **Firewall** | Default Drop Stateful Firewall | `nftables.service`, `/etc/nftables.conf` |
| **SSH Server** | Ed25519 keys only, root off, modern ciphers | `/etc/ssh/sshd_config.d/99-hardening.conf` |
| **Network Defense** | Automatic IP blocking on SSH attacks | `fail2ban.service` (`nftables-multiport`) |
| **Logging** | Tamper-proof journal (FSS) | `systemd-journald`, `journalctl --setup-keys` |
| **Auditing** | CVE & system check | `arch-audit`, `lynis audit system` |

## Further Resources

[Arch Linux: Advanced Security Features and Maintenance](/en/arch-linux-serie/arch-linux-advanced-security-features-and-maintenance){.badge-link-text}
[Linux Server Hardening: FIDO2, SSH Security and CrowdSec](/en/server-environments/linux-server-hardening-fido2-crowdsec){.badge-link-text}
[Pacman: The Comprehensive Guide](/en/arch-linux-serie/arch-linux-comprehensive-guide-package-manager-pacman){.badge-link-text}
[Official Arch Linux Wiki – Security Best Practices](https://wiki.archlinux.org/title/Security){.badge-link-text}
[nftables Documentation (Arch Wiki)](https://wiki.archlinux.org/title/Nftables){.badge-link-text}

## 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.

<blockquote class="infobox infobox--info">
💡 **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.
</blockquote>

In the sixth and final part of our series, we address the advanced system hardening: In [Arch Linux: Advanced Security Features and Maintenance](/en/arch-linux-serie/arch-linux-advanced-security-features-and-maintenance){.badge-link-text} 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.