┌─────────────────────────────────────────────────────────────┐
│ APPARMOR AUFRUFABLAUF IM KERNEL                             │
├─────────────────────────────────────────────────────────────┤
│ [Prozess]                                                   │
│     │                                                       │
│     ▼                                                       │
│ ┌──────────────────┐                                        │
│ │ System-Call      │  z.B. open(), execve(), connect()      │
│ │ (Userspace)      │                                        │
│ └────────┬─────────┘                                        │
│          │                                                  │
│          ▼                                                  │
│ ┌──────────────────┐                                        │
│ │ Kernel LSM-Hook  │  security_file_open(), etc.            │
│ └────────┬─────────┘                                        │
│          │                                                  │
│          ▼                                                  │
│ ┌──────────────────┐                                        │
│ │ AppArmor prüft   │  Profil geladen? Regel vorhanden?      │
│ │ Pfad + Perm.     │  Dateipfad + gewünschte Berechtigung   │
│ └────────┬─────────┘                                        │
│          │                                                  │
│    ┌─────┴─────┐                                            │
│    │           │                                            │
│    ▼           ▼                                            │
│ [ALLOW]    [DENY]  → Audit-Log (AVC-Message)                │
└─────────────────────────────────────────────────────────────┘

# AppArmor installieren
sudo pacman -S apparmor

sudo nano /etc/default/grub

# In GRUB_CMDLINE_LINUX_DEFAULT hinzufügen:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet lsm=landlock,lockdown,yama,integrity,apparmor,bpf"

# GRUB neu generieren
sudo grub-mkconfig -o /boot/grub/grub.cfg

# AppArmor beim Start laden und aktivieren
sudo systemctl enable --now apparmor.service

# 1. Prüfen, ob AppArmor als aktives LSM geladen ist
cat /sys/kernel/security/lsm
# Erwartete Ausgabe: landlock,lockdown,yama,integrity,apparmor,bpf

# 2. Prüfen, ob das Kernelmodul geladen ist
lsmod | grep apparmor

# 3. Status des systemd-Dienstes prüfen
systemctl status apparmor.service

sudo aa-status

apparmor module is loaded.
38 profiles are loaded.
38 profiles are in enforce mode.
   /usr/bin/cat
   /usr/bin/gpg
   /usr/sbin/cron
   ...
0 profiles are in complain mode.

# Nur lesbar
/etc/nginx/nginx.conf r,

# Lesen und Schreiben in allen Unterordnern
/var/log/nginx/** rw,

# Ausführbar (mit inherited Profil)
/usr/bin/nginx ix,

# mmap mit Exec-Berechtigung (für Shared Libraries)
/usr/lib/libssl.so* mr,

# IPv4 TCP (Stream)
network inet stream,

# IPv6 TCP
network inet6 stream,

# IPv4 UDP (Datagram)
network inet dgram,

# IPv6 UDP
network inet6 dgram,

# Bestimmte Ports einschränken
network inet stream, peer=(label=nginx),

# Capabilities erlauben
capability net_bind_service,    # Port < 1024 binden
capability setuid,              # UID wechseln
capability setgid,              # GID wechseln

# Capabilities explizit verbieten (deny-Regel)
deny capability sys_admin,     # Keine Admin-Capabilities
deny capability sys_rawio,     # Keinen direkten Hardware-Zugriff

# D-Bus System-Bus Kommunikation
dbus (send) bus=system path=/org/freedesktop/NetworkManager,
dbus (receive) bus=system path=/org/freedesktop/NetworkManager,

# D-Bus Signale begrenzen
dbus (send) bus=system path=/org/freedesktop/NetworkManager
    interface=org.freedesktop.NetworkManager
    member=StateChanged,

# Signals an andere Prozesse senden
signal (send) set=(term, kill) peer=/usr/sbin/nginx,

# Ptrace (Debugging) einschränken
ptrace (read, trace) peer=/usr/bin/gdb,

# Häufig genutzte Abstractions einbinden
#include <abstractions/base>           # Grundlegende Systemzugriffe
#include <abstractions/nameservice>    # DNS-Auflösung, /etc/passwd
#include <abstractions/ssl_certs>      # Zertifikate lesen
#include <abstractions/apache2-common> # Typische Webserver-Regeln
#include <abstractions/nvidia>         # Nvidia-Treiber-Zugriff

# /etc/apparmor.d/abstractions/my-webapp
#include <abstractions/base>
#include <abstractions/nameservice>

/var/webapp/** r,
/var/webapp/uploads/ rw,
/run/webapp/*.sock rw,

# Variablen-Definition (Standard in /etc/apparmor.d/tunables/home)
@{HOME}=@{HOMEDIRS}/* /root/

# In Profilen nutzbar:
owner @{HOME}/.config/** r,

# AppArmor-Utilities installieren
sudo pacman -S apparmor-utils

# Profil für Nginx interaktiv generieren
sudo aa-genprof nginx

#include <tunables/global>

/usr/bin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/ssl_certs>

  # ── Netzwerk ─────────────────────────────────
  network inet stream,
  network inet6 stream,

  # ── Binary ───────────────────────────────────
  /usr/bin/nginx mr,

  # ── Konfiguration ────────────────────────────
  /etc/nginx/** r,
  /etc/nginx/mime.types r,

  # ── Web-Root ─────────────────────────────────
  /var/www/** r,
  /var/www/html/** rw,

  # ── Logs & PID ───────────────────────────────
  /var/log/nginx/** w,
  /run/nginx.pid w,

  # ── Temporäre Dateien ────────────────────────
  /var/lib/nginx/** rw,
  /tmp/** w,

  # ── Unix-Sockets ─────────────────────────────
  unix stream,

  # ── Capabilities ─────────────────────────────
  capability net_bind_service,
  capability setuid,
  capability setgid,

  # ── Verbotene Zugriffe ───────────────────────
  deny /etc/shadow r,
  deny /etc/gshadow r,
  deny capability sys_admin,
}

sudo apparmor_parser -r /etc/apparmor.d/usr.bin.nginx

sudo aa-status | grep nginx
# Ausgabe: /usr/bin/nginx

# Profil in Complain-Modus versetzen
sudo aa-complain /usr/bin/nginx

sudo journalctl -k -g "apparmor"

# Profil scharfschalten
sudo aa-enforce /usr/bin/nginx

audit: type=1400 audit=1724764800.123:456
  apparmor="DENIED"
  operation="open"
  profile="/usr/bin/nginx"
  name="/etc/nginx/conf.d/secrets.conf"
  pid=1234 comm="nginx"
  requested_mask="r"
  denied_mask="r"
  fsuid=33
  ouid=33

# Alle AVC-Denials der letzten Stunde filtern
sudo ausearch -m AVC,USER_AVC -ts recent | grep "profile=/usr/bin/nginx"

sudo systemctl edit nginx.service

[Service]
AppArmorProfile=/etc/apparmor.d/usr.bin.nginx

sudo systemctl daemon-reload
sudo systemctl restart nginx

# linux-hardened und Headers für DKMS installieren
sudo pacman -S linux-hardened linux-hardened-headers

# GRUB neu generieren
sudo grub-mkconfig -o /boot/grub/grub.cfg

# Initramfs für alle installierten Kernel neu bauen
sudo mkinitcpio -P

# Kernel-Version prüfen
uname -r
# Ausgabe: 6.12.9-hardened1-1-hardened

# Aktive LSMs prüfen
cat /sys/kernel/security/lsm
# Ausgabe: landlock,lockdown,yama,integrity,apparmor,bpf

# Hardening-Build-Flags im Kernel überprüfen
zgrep HARDENED /proc/config.gz
# CONFIG_HARDENED_USERCOPY=y
# CONFIG_HARDENED_USERCOPY_FALLBACK=n
# CONFIG_INIT_STACK_ALL_ZERO=y

┌─────────────────────────────────────────────────────────────┐
│ ASLR SPEICHER-RANDOMISIERUNG (64-BIT)                       │
├─────────────────────────────────────────────────────────────┤
│ Prozess-Speicherlayout (vereinfacht):                       │
│                                                             │
│ 0x0000 0000 0000 ┌──────────────────┐                       │
│                  │ Stack            │ ← randomisierte Adr.  │
│                  │ (wächst abwärts) │                       │
│ 0x0000 7fff xxxx └──────────────────┘                       │
│                                                             │
│ 0x0000 7fff yyyy ┌──────────────────┐                       │
│                  │ mmap-Segment     │ ← Shared Libraries    │
│                  │ (Shared Libs)    │   werden randomisiert │
│ 0x0000 7fff zzzz └──────────────────┘                       │
│                                                             │
│ Bit 28-31 = Adress-Bits für mmap-Randomisierung             │
│ • mmap_rnd_bits=28 → 28 Bits Zufall → 268 Mio. Adressen     │
│ • mmap_rnd_bits=32 → 32 Bits Zufall → 4,3 Mrd. Adressen     │
└─────────────────────────────────────────────────────────────┘

# Maximaler Zufall für 64-Bit-Userspace-Prozesse
vm.mmap_rnd_bits = 32

# Kompatibilität für 32-Bit-Prozesse auf x86_64
vm.mmap_rnd_compat_bits = 16

sudo sysctl --system

# Verifikation
cat /proc/sys/vm/mmap_rnd_bits
# Ausgabe: 32

# ── Kernel-Symboladressen verbergen ────────────
# Auch Root kann /proc/kallsyms nicht mehr im Klartext lesen
kernel.kptr_restrict = 2

# ── dmesg-Zugriff beschränken ──────────────────
# Verhindert Informationslecks über Hardware & Treiber für reguläre Benutzer
kernel.dmesg_restrict = 1

# ── Ptrace-Scope einschränken ──────────────────
# Nur Prozesse mit CAP_SYS_PTRACE dürfen fremde Prozesse debuggen
kernel.yama.ptrace_scope = 2

# ── Magic SysRq deaktivieren ───────────────────
# Verhindert Memory-Dumps und Notfall-Befehle über physische Tastatureingaben
kernel.sysrq = 0

# ── Perf-Events einschränken ───────────────────
# Verhindert Seitenkanal-Angriffe über das Performance-Monitoring
kernel.perf_event_paranoid = 3

# ── Kexec deaktivieren ─────────────────────────
# Verhindert das Laden unauthorisierter Kernel im laufenden Betrieb
kernel.kexec_load_disabled = 1

# ── Unprivileged BPF sperren ───────────────────
kernel.unprivileged_bpf_disabled = 1

# ── BPF JIT-Härtung ───────────────────────────
# Konstanten-Randomisierung gegen JIT-Spray-Attacken
net.core.bpf_jit_harden = 2

sudo sysctl --system

sudo sysctl \
  kernel.kptr_restrict \
  kernel.dmesg_restrict \
  kernel.yama.ptrace_scope \
  kernel.perf_event_paranoid \
  kernel.kexec_load_disabled \
  kernel.unprivileged_bpf_disabled \
  net.core.bpf_jit_harden

# checksec installieren
sudo pacman -S checksec

checksec kernel

RELRO           STACK CANARY      NX            PIE             RPATH/RUNPATH
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH

Fortify Source   FORTIFY Functions  Format String  Pointer Protection
Yes              Yes                Yes            Yes

checksec --no-banner --no-warnings procAll

┌─────────────────────────────────────────────────────────────┐
│ ANGRIFFSSZENARIO: PHYSISCHER ZUGRIFF                        │
├─────────────────────────────────────────────────────────────┤
│ 1. Physischer Zugriff auf den Server                        │
│    ↓                                                        │
│ 2. GRUB-Menü erscheint (kein Passwort, Parameter editierbar)│
│    ↓                                                        │
│ 3. Angreifer übergibt `init=/bin/bash` als Kernel-Parameter │
│    ↓                                                        │
│ 4. Kernel bootet und startet Root-Shell statt Login-Maske   │
│    ↓                                                        │
│ 5. Root-Shell aktiv: Unverschlüsselte Daten sofort lesbar   │
│    ↓                                                        │
│ 6. Bei LUKS: Manipulation der Boot-Dateien / Evil-Maid      │
│                                                             │
│ FAZIT: GRUB-Passwort & LUKS-Header-Backup schützen den Boot.│
└─────────────────────────────────────────────────────────────┘

# Hash für das GRUB-Superuser-Passwort erzeugen
sudo grub-mkpasswd-pbkdf2

#!/bin/sh
exec tail -n +3 $0

# ── GRUB Superuser und Hash ────────────────────
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.DEIN_GENERIERTER_HASH...

# Notfall-Shells im Initramfs deaktivieren
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet rd.shell=0"

# Recovery-Einträge aus dem Boot-Menü entfernen
GRUB_DISABLE_RECOVERY=true

sudo grub-mkconfig -o /boot/grub/grub.cfg

┌─────────────────────────────────────────────────────────────┐
│ WAS PASSIERT BEI EINEM LUKS-HEADER-SCHADEN?                 │
├─────────────────────────────────────────────────────────────┤
│ SZENARIO 1: Kein Backup vorhanden                           │
│ • Header defekt → Alle Keyslots verloren                    │
│ • Selbst mit korrektem Passwort: Totalschaden aller Daten   │
│                                                             │
│ SZENARIO 2: Offline-Backup auf USB-Stick (Tresor)           │
│ • Header defekt → Live-USB booten & Header restoren         │
│ • Keyslots wiederhergestellt → Entschlüsselung gelingt      │
│                                                             │
│ SZENARIO 3: Backup nur lokal auf dem gleichen Server        │
│ • Server oder Dateisystem zerstört → Backup unzugänglich    │
│ • Ergebnis: Ebenfalls vollständiger Datenverlust            │
│                                                             │
│ REGEL: Header-Backups zwingend offline & verschlüsselt!     │
└─────────────────────────────────────────────────────────────┘

# Backup-Verzeichnis anlegen
sudo mkdir -p /root/luks-backups

# LUKS2-Header sichern
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p2 \
    --header-backup-file /root/luks-backups/nvme0n1p2-header.img

# Auf externen Offline-Datenträger transferieren
sudo mount /dev/sdb1 /mnt/usb
sudo cp /root/luks-backups/nvme0n1p2-header.img /mnt/usb/
sudo umount /mnt/usb

# Aus einem Live-System heraus:
sudo cryptsetup luksHeaderRestore /dev/nvme0n1p2 \
    --header-backup-file /mnt/usb/nvme0n1p2-header.img

# Header und aktive Keyslots inspizieren
sudo cryptsetup luksDump /dev/nvme0n1p2

LUKS header information
Version:        2
Epoch:          5
Metadata area:  [16384, 8176640]
Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   regular
    PBKDF:      argon2id
    Time cost:  4
    Memory:     1048576
    Threads:    4

sudo cryptsetup luksAddKey /dev/nvme0n1p2

# Keyslot 1 gezielt löschen
sudo cryptsetup luksKillSlot /dev/nvme0n1p2 1

# Keyfile generieren und strikt berechtigen
sudo dd if=/dev/urandom of=/root/data-drive.keyfile bs=512 count=8
sudo chmod 400 /root/data-drive.keyfile
sudo chown root:root /root/data-drive.keyfile

# Keyfile dem sekundären Volume zuweisen
sudo cryptsetup luksAddKey /dev/sdb1 /root/data-drive.keyfile

# In /etc/crypttab hinterlegen
echo "data-volume  /dev/sdb1  /root/data-drive.keyfile  luks" | sudo tee -a /etc/crypttab

┌─────────────────────────────────────────────────────────────┐
│ TPM2-BINDUNG: AUSWIRKUNG VON SYSTEM-ÄNDERUNGEN              │
├─────────────────────────────────────────────────────────────┤
│ BIOS/UEFI-UPDATE:                                           │
│ • PCR 0 ändert sich → TPM2 blockiert automatischen Unlock   │
│ • Lösung: Manuelle Passphrase als Fallback eingeben         │
│                                                             │
│ SECURE BOOT DEAKTIVIERT:                                    │
│ • PCR 7 ändert sich → TPM2 verweigert Entsperrung           │
│ • Schutz gegen Boot unautorisierter Live-Systeme            │
│                                                             │
│ DIEBSTAHL DES LAUFWERKS:                                    │
│ • TPM2 ist fest auf dem Mainboard verlötet                  │
│ • Auf fremdem Mainboard ohne Passphrase nicht lesbar        │
│                                                             │
│ WICHTIG: Passphrase im Tresor bleibt Pflicht-Fallback!      │
└─────────────────────────────────────────────────────────────┘

# TPM2-Gerät auf dem System identifizieren
sudo systemd-cryptenroll --tpm2-device=list

# Volume an PCR 0, 1 und 7 binden
sudo systemd-cryptenroll /dev/nvme0n1p2 \
    --tpm2-device=auto \
    --tpm2-pcrs=0+1+7

# ═══════════════════════════════════════════════════
# Vergleich: Docker iptables vs. nftables
# ═══════════════════════════════════════════════════

# Docker iptables (Standard):
# - Docker schreibt autonome Regeln in nat, filter, mangle
# - Manuelle Regeln können bei Container-Neustart überschrieben werden
# - Port-Forwarding via -p 8080:80 erzeugt unkontrollierte DNAT-Regeln
# - Keine granulare Kontrolle über Container-to-Container Traffic

# nftables (mit --iptables=false):
# - Docker erstellt KEINE autonomen Regeln
# - Volle Kontrolle über jeden Paketfluss im Host-Kernel
# - Regeln überleben Container-Neustarts dauerhaft
# - Granulare Isolation zwischen Micro-Services
# - Connection Tracking (conntrack) für zustandsbehaftete Filterung

┌─────────────────────────────────────────────────────────────┐
│ DOCKER BRIDGING & VETH-ISOLATION                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  HOST-SYSTEM                                                │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ docker0 Linux-Bridge (Default Gateway: 172.17.0.1)    │  │
│  │                                                       │  │
│  │      [ veth-web1 ]                 [ veth-db1 ]       │  │
│  └────────────┬─────────────────────────────┬────────────┘  │
│               │                             │               │
│         veth-Verbindung               veth-Verbindung       │
│               │                             │               │
│  ┌────────────┴─────────────┐ ┌─────────────┴────────────┐  │
│  │ CONTAINER 1 (Webserver)  │ │ CONTAINER 2 (PostgreSQL) │  │
│  │ Net-Namespace: ns-web    │ │ Net-Namespace: ns-db     │  │
│  │ eth0: 172.17.0.2         │ │ eth0: 172.17.0.3         │  │
│  │ Interface: [ veth-web2 ] │ │ Interface: [ veth-db2 ]  │  │
│  └──────────────────────────┘ └──────────────────────────┘  │
│                                                             │
│  TRAFFIC-WEG & FIREWALL-KONTROLLE:                          │
│  • Standard: docker0 leitet Pakete ungefiltert weiter       │
│  • nftables: `forward`-Chain erzwingt Default-Drop          │
└─────────────────────────────────────────────────────────────┘

# Bridge-Interface prüfen
ip link show docker0

# Aktive Nachbarn auf der Bridge
ip neigh show dev docker0

#!/usr/sbin/nft -f

flush ruleset

define CONTAINER_NET = 172.17.0.0/16
define HOST_IP = 192.168.1.100

table inet container_filter {

    # Dynamische IP-Sets für Container-Rechte
    set internet_allowed {
        type ipv4_addr
        flags interval, timeout
    }

    set host_allowed {
        type ipv4_addr
        flags interval, timeout
    }

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

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        # SSH nur aus dem physischen LAN erlauben, niemals aus Containern
        tcp dport 22 ip saddr != $CONTAINER_NET accept

        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # Autorisierte Container-to-Host Zugriffe (z. B. DNS oder Monitoring)
        ip saddr @host_allowed tcp dport { 80, 443, 8080 } accept
        ip saddr @host_allowed udp dport 53 accept

        log prefix "[CONTAINER-INPUT-DROP] " counter drop
    }

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

        ct state established,related accept
        ct state invalid drop

        # Container-to-Internet: Nur Container im Set internet_allowed
        ip saddr @internet_allowed oif "eth0" accept

        # Explizite Freigabe für Micro-Services (z. B. Web zu DB)
        ip saddr 172.17.0.2 ip daddr 172.17.0.3 tcp dport 5432 accept

        # DNS-Anfragen der Container weiterleiten
        ip saddr $CONTAINER_NET udp dport 53 accept

        log prefix "[CONTAINER-FORWARD-DROP] " counter drop
    }

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

table ip nat {
    chain prerouting {
        type nat hook prerouting priority dstnat;

        # Port-Forwarding: Host Port 8443 auf Container 172.17.0.2:443
        tcp dport 8443 dnat to 172.17.0.2:443
    }

    chain postrouting {
        type nat hook postrouting priority srcnat;

        # Masquerading für autorisierten ausgehenden WAN-Traffic
        ip saddr $CONTAINER_NET oif "eth0" masquerade
    }
}

sudo nano /usr/local/bin/update-container-ips.sh

#!/bin/bash
set -euo pipefail

INTERNET_ALLOWED=("172.17.0.2" "172.17.0.3")
HOST_ALLOWED=("172.17.0.4" "172.17.0.5")

nft flush set inet container_filter internet_allowed
nft flush set inet container_filter host_allowed

for ip in "${INTERNET_ALLOWED[@]}"; do
    nft add element inet container_filter internet_allowed { "$ip" }
done

for ip in "${HOST_ALLOWED[@]}"; do
    nft add element inet container_filter host_allowed { "$ip" }
done

sudo chmod 750 /usr/local/bin/update-container-ips.sh

┌─────────────────────────────────────────────────────────────┐
│ TRAFFIC-ISOLATION: WEBSERVER & POSTGRESQL                   │
├─────────────────────────────────────────────────────────────┤
│ WEBSERVER (172.17.0.2):                                     │
│ • Zu postgres:5432  -> [ERLAUBT]  (SQL-Queries an DB)       │
│ • Zu Internet:443   -> [ERLAUBT]  (Paket-Updates)           │
│ • Zu Host:22        -> [GESPERRT] (SSH-Zugriff blockiert)   │
│                                                             │
│ POSTGRESQL (172.17.0.3):                                    │
│ • Zu Webserver      -> [GESPERRT] (Kein Initiieren nötig)   │
│ • Zu Internet       -> [GESPERRT] (Vollständig isoliert)    │
│ • Zu Host           -> [GESPERRT] (Kein Host-Zugriff)       │
│                                                             │
│ SICHERHEIT: Web-Compromise erreicht niemals Host oder WAN!  │
└─────────────────────────────────────────────────────────────┘

docker run -d --name web --ip 172.17.0.2 nginx
docker run -d --name db --ip 172.17.0.3 postgres:16

sudo nft add element inet container_filter internet_allowed { 172.17.0.2 }

# Build-Container ohne Internetzugang starten
docker run -d --name builder --ip 172.17.0.10 registry.local/build-env

# Nur Traffic zur lokalen Registry auf 192.168.1.50:5000 erlauben
sudo nft add rule inet container_filter forward \
    ip saddr 172.17.0.10 ip daddr 192.168.1.50 tcp dport 5000 accept

# DNS erlauben
sudo nft add rule inet container_filter forward \
    ip saddr 172.17.0.10 udp dport 53 accept

docker run -d --name prometheus --ip 172.17.0.20 prom/prometheus
docker run -d --name node-exporter --ip 172.17.0.21 prom/node-exporter

# Nur Prometheus darf Node-Exporter auf Port 9100 scrapen
sudo nft add rule inet container_filter forward \
    ip saddr 172.17.0.20 ip daddr 172.17.0.21 tcp dport 9100 accept

# Eigenes isoliertes Netzwerk in Podman erstellen
podman network create --subnet 10.89.0.0/24 podman-net

# Container im Subnetz ausführen
podman run -d --network podman-net --name web nginx
podman run -d --network podman-net --name db postgres:16

:msg, contains, "[CONTAINER-" /var/log/container-firewall.log
& stop

/var/log/container-firewall.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0640 root root
}

┌─────────────────────────────────────────────────────────────┐
│ MULTI-HOST-LOGGING: TLS-FORWARDING-TOPOLOGIE                │
├─────────────────────────────────────────────────────────────┤
│ HOST A (Web)         HOST B (DB)          HOST C (Monitor)  │
│ ┌─────────────┐     ┌─────────────┐      ┌─────────────┐    │
│ │ rsyslog     │     │ rsyslog     │      │ rsyslog     │    │
│ │ (Sender)    │     │ (Sender)    │      │ (Sender)    │    │
│ └──────┬──────┘     └──────┬──────┘      └──────┬──────┘    │
│        │                   │                    │           │
│        │   mTLS (Port 6514)│   mTLS (Port 6514) │           │
│        └───────────────────┼────────────────────┘           │
│                            │                                │
│                 ┌──────────┴──────────┐                     │
│                 │ LOG-SERVER (Host D) │                     │
│                 │ rsyslog Receiver    │                     │
│                 │ /logs/{web,db,...}  │                     │
│                 └─────────────────────┘                     │
│                                                             │
│ VORTEIL: Bei Host-Compromise bleiben Logs auf D unantastbar.│
└─────────────────────────────────────────────────────────────┘

# Verzeichnis für Zertifikate erstellen
sudo mkdir -p /etc/rsyslog/ca
cd /etc/rsyslog/ca

# CA privaten Schlüssel erzeugen (4096 Bit, RSA)
sudo openssl genrsa -out ca.key 4096

# CA-Zertifikat erzeugen (gültig für 10 Jahre)
sudo openssl req -x509 -new -nodes -key ca.key \
    -sha256 -days 3650 \
    -out ca.crt \
    -subj "/C=DE/ST=Bayern/L=Muenchen/O=Homelab/CN=Log-CA"

# Verifikation
sudo openssl x509 -in ca.crt -text -noout | grep -A2 "Issuer"
# Issuer: C = DE, ST = Bayern, L = Muenchen, O = Homelab, CN = Log-CA

cd /etc/rsyslog/ca

# Server-Key erzeugen
sudo openssl genrsa -out server.key 4096

# CSR (Certificate Signing Request) erzeugen
sudo openssl req -new -key server.key \
    -out server.csr \
    -subj "/C=DE/ST=Bayern/L=Muenchen/O=Homelab/CN=logserver.local"

# Server-Zertifikat signieren (gültig für 5 Jahre)
sudo openssl x509 -req -in server.csr \
    -CA ca.crt -CAkey ca.key -CAcreateserial \
    -out server.crt -days 1825 -sha256

# SAN (Subject Alternative Name) hinzufügen
# ACHTUNG: Ohne SAN verweigert rsyslog die Verbindung!
sudo openssl x509 -in server.crt -out server-san.crt \
    -extfile <(printf "subjectAltName=DNS:logserver.local,DNS:logserver,IP:192.168.1.12")
sudo mv server-san.crt server.crt

# Für jeden Host ein eigenes Zertifikat erzeugen
for HOST in webserver dbserver monitor; do
    sudo openssl genrsa -out ${HOST}.key 4096
    sudo openssl req -new -key ${HOST}.key \
        -out ${HOST}.csr \
        -subj "/C=DE/ST=Bayern/L=Muenchen/O=Homelab/CN=${HOST}.local"
    sudo openssl x509 -req -in ${HOST}.csr \
        -CA ca.crt -CAkey ca.key -CAcreateserial \
        -out ${HOST}.crt -days 1825 -sha256
done

# Auf jedem Host:
sudo mkdir -p /etc/rsyslog/certs

# CA-Zertifikat (auf alle Hosts)
sudo cp ca.crt /etc/rsyslog/certs/

# Server-Zertifikat (nur auf Log-Server)
sudo cp server.key server.crt /etc/rsyslog/certs/

# Client-Zertifikat (auf den jeweiligen Host)
sudo cp webserver.key webserver.crt /etc/rsyslog/certs/

# Prüfen, ob Zertifikat von CA signiert ist
sudo openssl verify -CAfile ca.crt server.crt
# server.crt: OK

sudo openssl verify -CAfile ca.crt webserver.crt
# webserver.crt: OK

# Zertifikat-Details anzeigen
sudo openssl x509 -in server.crt -text -noout | grep -A2 "Subject:"
# Subject: C = DE, ST = Bayern, L = Muenchen, O = Homelab, CN = logserver.local

sudo nano /etc/rsyslog.d/50-forward.conf

# ═══════════════════════════════════════════════════
# rsyslog TLS-Forwarding (Sender)
# ═══════════════════════════════════════════════════

# Globale Module laden
module(load="imuxsock")    # Lokale Logs
module(load="imklog")      # Kernel-Logs
module(load="imfile")      # Datei-Monitoring
module(load="omfwd")       # Forwarding

# ─────────────────────────────────────────────────
# TLS-Transport-Definition
# ─────────────────────────────────────────────────

# TLS-Zertifikate
$DefaultNetstreamDriverCAFile /etc/rsyslog/certs/ca.crt
$DefaultNetstreamDriverCertFile /etc/rsyslog/certs/webserver.crt
$DefaultNetstreamDriverKeyFile /etc/rsyslog/certs/webserver.key

# TLS-Transport aktivieren
$ActionSendStreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode x509/certvalid

# ─────────────────────────────────────────────────
# Forwarding-Regeln
# ─────────────────────────────────────────────────

# Alle lokalen Logs an Log-Server senden
*.* @@(omfwd)logserver.local:6514;RSYSLOG_SyslogProtocol23Format

# ─────────────────────────────────────────────────
# Queueing für Zuverlässigkeit
# ─────────────────────────────────────────────────

# Queue-Typ: Disk-assisted (overflow auf Festplatte)
$ActionQueueType LinkedList
$ActionQueueFileName fwd_queue
$ActionQueueMaxDiskSpace 256m
$ActionQueueSaveOnShutdown on
$ActionQueueTimeoutEnqueue 100
$ActionResumeRetryCount -1
$ActionResumeInterval 30

# ─────────────────────────────────────────────────
# Rate-Limiting gegen Log-Flooding
# ─────────────────────────────────────────────────

# Maximal 1000 Nachrichten pro Sekunde
$NetstatsRateLimit 1000

# Verifikation: Syntax prüfen
sudo rsyslogd -N1
# rsyslogd: version ..., config validation run took 0.001 seconds

# rsyslog neu starten
sudo systemctl restart rsyslog

# Verbindungsstatus prüfen
sudo systemctl status rsyslog
# active (running)

┌─────────────────────────────────────────────────────────────┐
│ QUEUEING-VERHALTEN BEI NETZWERKAUSFALL                      │
├─────────────────────────────────────────────────────────────┤
│ 1. NETZWERKAUSFALL:                                         │
│ • rsyslog puffert Logs in /var/spool/rsyslog/fwd_queue      │
│ • Maximal 256 MB Disk-assisted Spooling aktiv               │
│                                                             │
│ 2. WIEDERVERBINDUNG:                                        │
│ • TCP-Verbindung zu Port 6514 wird automatisch reaktiviert  │
│ • Lokale Queue wird chronologisch an Log-Server übertragen  │
│                                                             │
│ 3. REBOOT-SICHERHEIT:                                       │
│ • Unversendete Logs überstehen einen Server-Neustart        │
│ • Kein Datenverlust bei Verbindungsabbrüchen                │
└─────────────────────────────────────────────────────────────┘

sudo nano /etc/rsyslog.d/00-receiver.conf

# ═══════════════════════════════════════════════════
# rsyslog TLS-Receiver (Log-Server)
# ═══════════════════════════════════════════════════

# Modul für TCP-Eingang laden
module(load="imtcp"
       StreamDriver="gtls"
       StreamDriver.AuthMode="x509/certvalid"
       StreamDriver.Mode="1")

# TLS-Zertifikate
$DefaultNetstreamDriverCAFile /etc/rsyslog/certs/ca.crt
$DefaultNetstreamDriverCertFile /etc/rsyslog/certs/server.crt
$DefaultNetstreamDriverKeyFile /etc/rsyslog/certs/server.key

# Port öffnen
input(type="imtcp" port="6514")

# ─────────────────────────────────────────────────
# Log-Speicherung nach Host/Tag
# ─────────────────────────────────────────────────

# Template: Speicherpfad mit Hostname
template(name="HostLog" type="string"
    string="/logs/%programname%.log")

# Template: Pfad mit Hostname + Datum
template(name="HostLogRotated" type="string"
    string="/logs/%HOSTNAME%/%$year%-%$month%-%$day%.log")

# Empfangene Logs nach Host speichern
if $hostname != 'logserver' then {
    # Logs des jeweiligen Hosts speichern
    action(type="omfile"
           dynaFile="HostLogRotated"
           FileCreateMode="0640"
           DirCreateMode="0750")

    # Auth-Logs separat speichern (für Audit)
    if $programname == "sshd" or $programname == "sudo" then {
        action(type="omfile"
               file="/logs/auth/audit.log"
               FileCreateMode="0640")
    }
}

# Verzeichnisse erstellen
sudo mkdir -p /logs/{auth,web,db,monitor}
sudo mkdir -p /logs/{webserver,dbserver,monitor}

# Berechtigungen setzen
sudo chown -R root:adm /logs
sudo chmod -R 750 /logs

# Log-Rotation konfigurieren
sudo nano /etc/logrotate.d/remote-logs

/logs/*/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    dateext
    dateformat -%Y-%m-%d
}

# Auf dem Sender (Host A/B/C):
sudo nano /etc/systemd/journald.conf

[Journal]
# Remote-Forwarding an rsyslog
ForwardToSyslog=yes
ForwardToSyslogSocket=yes
SyslogSocket=192.168.1.12:6514

# Lokale Logs beibehalten
Storage=persistent
SystemMaxUse=1G
SystemMaxFileSize=100M
MaxRetentionSec=30day

# Auf dem Receiver (Log-Server):
sudo nano /etc/rsyslog.d/10-journald.conf

# journald-Logs annehmen (falls zusätzlich zu rsyslog)
module(load="imudp")
input(type="imudp" port="514")

# journald neu starten
sudo systemctl restart systemd-journald

# Auf dem Log-Server:
sudo nano /etc/rsyslog.d/20-signing.conf

# ═══════════════════════════════════════════════════
# Log-Signierung
# ═══════════════════════════════════════════════════

# Signierungs-Schlüssel erzeugen (einmalig)
# openssl genrsa -out /etc/rsyslog/signing.key 4096

module(load="omfile")

# Logs nach dem Schreiben signieren
template(name="SignedLog" type="string"
    string="/logs/%HOSTNAME%/%programname%.log")

action(type="omfile"
       dynaFile="SignedLog"
       FileCreateMode="0640"
       DirCreateMode="0750"
       cmd="/usr/bin/rsyslog-log-signer -s /etc/rsyslog/signing.key")

# Log-Partition mounten (append-only)
# ACHTUNG: Danach können Logs nur hinzugefügt, nicht gelöscht werden!
sudo mount -o remount,append-only /logs

# Verifikation
mount | grep /logs
# /dev/sdb1 on /logs type ext4 (rw,appendonly)

┌─────────────────────────────────────────────────────────────┐
│ LOG-INTEGRITÄT: VERGLEICH DER SICHERUNGSMETHODEN            │
├─────────────────────────────────────────────────────────────┤
│ APPEND-ONLY FILESYSTEM (mount -o append-only / chattr +a):  │
│ • Verhindert: Löschen und Überschreiben bestehender Zeilen  │
│ • Erlaubt: Nur kontinuierliches Anhängen neuer Log-Daten    │
│ • Praxis: Geringer Overhead, ideal für Linux-Logserver      │
│                                                             │
│ KRYPTOGRAFISCHE SIGNIERUNG (rsyslog-log-signer / RFC 5424): │
│ • Verhindert: Fälschung und Manipulation durch Angreifer    │
│ • Schutz: Integritätsprüfung jedes einzelnen Log-Blocks     │
│                                                             │
│ EMPFEHLUNG: mTLS-Forwarding kombiniert mit Append-Only!     │
└─────────────────────────────────────────────────────────────┘

# ─────────────────────────────────────────────────────
# Log-Server (192.168.1.12)
# ─────────────────────────────────────────────────────

# 1. Zertifikate installieren
sudo cp ca.crt server.key server.crt /etc/rsyslog/certs/

# 2. Receiver-Konfiguration aktivieren
# /etc/rsyslog.d/00-receiver.conf

# 3. Firewall öffnen
sudo nft add rule inet filter input \
    tcp dport 6514 accept comment "rsyslog TLS"

# 4. Log-Verzeichnisse erstellen
sudo mkdir -p /logs/{auth,web,db,monitor}
sudo chown -R root:adm /logs

# 5. rsyslog starten
sudo systemctl enable --now rsyslog

# 6. Verifikation
sudo ss -tlnp | grep 6514
# LISTEN  0  128  0.0.0.0:6514  0.0.0.0:*  users:(("rsyslogd",pid=1234,fd=6))

# ─────────────────────────────────────────────────────
# Web-Server (192.168.1.10)
# ─────────────────────────────────────────────────────

# 1. Zertifikate installieren
sudo cp ca.crt webserver.key webserver.crt /etc/rsyslog/certs/

# 2. Sender-Konfiguration hinterlegen
# /etc/rsyslog.d/50-forward.conf

# 3. rsyslog starten
sudo systemctl enable --now rsyslog

# 4. Verifikation
sudo rsyslogd -N1
# config validation run took 0.001 seconds

# ─────────────────────────────────────────────────────
# DB-Server (192.168.1.11)
# ─────────────────────────────────────────────────────

# 1. Zertifikate installieren
sudo cp ca.crt dbserver.key dbserver.crt /etc/rsyslog/certs/

# 2. Sender-Konfiguration hinterlegen
# /etc/rsyslog.d/50-forward.conf

# 3. PostgreSQL-Logs zusätzlich erfassen
# /etc/rsyslog.d/51-postgres.conf:
# $AddUnixListenSocket /var/run/postgresql/.s.PGSQL.5432
# :programname, isequal, "postgres" /var/log/postgres.log
# & stop

# 4. rsyslog starten
sudo systemctl enable --now rsyslog

# 1. Auf Web-Server: Test-Log generieren
logger -t test "Multi-Host-Logging Test from webserver"

# 2. Auf Log-Server: Prüfen
sudo tail -f /logs/webserver/test.log
# Aug 27 12:34:56 webserver test: Multi-Host-Logging Test from webserver

# 3. Auth-Logs prüfen
sudo tail -f /logs/auth/audit.log
# Aug 27 12:34:56 webserver sshd[1234]: Accepted publickey for user

# 4. TLS-Verbindung prüfen
openssl s_client -connect logserver:6514 \
    -cert /etc/rsyslog/certs/webserver.crt \
    -key /etc/rsyslog/certs/webserver.key \
    -CAfile /etc/rsyslog/certs/ca.crt
# Verify return code: 0 (ok)

# /etc/logrotate.d/remote-logs
/logs/*/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    dateext
    dateformat -%Y-%m-%d
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service > /dev/null 2>&1 || true
    endscript
}

# /etc/cron.d/log-cleanup (Täglich um 03:00 Uhr: Logs älter als 365 Tage löschen)
0 3 * * * root find /logs -name "*.log.*" -mtime +365 -delete

# 1. Auf ALLEN Hosts: rsyslog-Syntax prüfen
sudo rsyslogd -N1
# Erwartung: "config validation run took 0.001 seconds"

# 2. Log-Server: Port 6514 geöffnet?
sudo ss -tlnp | grep 6514
# LISTEN  0  128  0.0.0.0:6514  0.0.0.0:*  users:(("rsyslogd",...))

# 3. Sender → Receiver: TLS-Verbindung
sudo openssl s_client -connect logserver:6514 \
    -cert /etc/rsyslog/certs/webserver.crt \
    -key /etc/rsyslog/certs/webserver.key \
    -CAfile /etc/rsyslog/certs/ca.crt \
    </dev/null 2>/dev/null | grep "Verify return code"
# Verify return code: 0 (ok)

# 4. Log-Eingang auf Log-Server
logger -t verification "Test from $(hostname)"
sleep 1
sudo tail -5 /logs/$(hostname)/$(date +%Y-%m-%d).log
# Aug 27 12:34:56 webserver verification: Test from webserver

# 5. Queue-Status prüfen (bei Netzwerkproblemen)
sudo find /var/spool/rsyslog/ -name "fwd_queue*" -ls

# 6. Log-Integrität prüfen
mount | grep /logs
# /dev/sdb1 on /logs type ext4 (rw,appendonly)

┌─────────────────────────────────────────────────────────────┐
│ ANGRIFFS-PLAYBOOK: RANSOMWARE AUF LINUX-SERVERN             │
├─────────────────────────────────────────────────────────────┤
│ 1. ROOT-RECHTE ERLANGEN:                                    │
│ • SSH-Compromise, Kernel-Exploit oder Container-Escape      │
│                                                             │
│ 2. BACKUPS & SNAPSHOTS IDENTIFIZIEREN:                      │
│ • Lokale BTRFS-Snapshots: `btrfs subvolume list /`          │
│ • Lokale Archive unter /backup/ und /var/backup/ scannen    │
│                                                             │
│ 3. LOKALE BACKUPS VERNICHTEN & DATEIEN CHIFFRIEREN:         │
│ • Snapshots löschen: `btrfs subvolume delete /snapshots/*`  │
│ • Produktivdaten verschlüsseln & Ransom-Note hinterlegen    │
│                                                             │
│ SCHUTZ: Unantastbare, unveränderliche Offsite-Backups!      │
└─────────────────────────────────────────────────────────────┘

# Angreifer findet Snapshots
sudo btrfs subvolume list /
# ID 257 gen 5 path @
# ID 258 gen 100 path @home
# ID 300 gen 200 path @snapshots/2026-08-01
# ID 301 gen 210 path @snapshots/2026-08-15
# ID 302 gen 220 path @snapshots/2026-08-27

# Angreifer löscht ALLE Snapshots
sudo btrfs subvolume delete /@snapshots/2026-08-01
sudo btrfs subvolume delete /@snapshots/2026-08-15
sudo btrfs subvolume delete /@snapshots/2026-08-27
# → Alle Snapshots weg. Kein Rollback möglich.

# Read-only Snapshot erstellen (kann nicht gelöscht werden, nur über *)
sudo btrfs subvolume snapshot -r / /@snapshots/2026-08-27-readonly

# ACHTUNG: read-only Snapshots können NICHT gelöscht werden
# * Außer: Angreifer mountet das Volume und macht es read-write
# → Daher: Snapshots auf EXTERNES Volume sichern!

# ─────────────────────────────────────────────────────
# Snapper + Push-to-NAS (automatisiert)
# ─────────────────────────────────────────────────────

# NAS einbinden (z.B. via NFS)
sudo mount -t nfs 192.168.1.200:/backup /mnt/nas

# Snapper-Konfiguration anpassen
sudo nano /etc/snapper/configs/root

# Snapper-Konfiguration
SUBVOLUME="/"
FSTYPE="btrfs"

# Snapshot-Verzeichnis auf NAS
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="5"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_MONTHLY="6"

# Post-Snapshot-Skript: Snapshot auf NAS pushen
RUN_FREQUENCY=1

# Post-Snapshot-Skript erstellen
sudo nano /etc/snapper/post-snapshot.d/10-push-to-nas.sh

#!/bin/bash
# Snapshot auf NAS synchronisieren (nach jedem neuen Snapshot)

SNAPSHOT_DIR="/@snapshots"
NAS_TARGET="/mnt/nas/snapshots/$(hostname)"

# NAS-Zielverzeichnis erstellen
mkdir -p "$NAS_TARGET"

# Neuesten Snapshot auf NAS pushen
NEWEST=$(ls -td ${SNAPSHOT_DIR}/*/  | head -1)
rsync -a --delete "${NEWEST}" "${NAS_TARGET}/"

# Verifikation
echo "Snapshot pushed: $(basename $NEWEST) → $NAS_TARGET"

# Ausführbar machen
sudo chmod +x /etc/snapper/post-snapshot.d/10-push-to-nas.sh

# Regelmäßige Integritätsprüfung aller Snapshots
sudo btrfs scrub start /

# Status prüfen
sudo btrfs scrub status /
# UUID:             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# Scrub started:    Mon Aug 27 12:00:00 2026
# Status:           finished
# Duration:         0:05:23
# Total to scrub:   128.00GB
# Rate:             400.00MB/s
# Error summary:    no errors found

# Cron: Monatlich automatisch scruben
echo "0 3 1 * * root btrfs scrub start /" | \
    sudo tee /etc/cron.d/btrfs-scrub

# ─────────────────────────────────────────────────────
# Restic: Verschlüsseltes Backup mit Deduplizierung
# ─────────────────────────────────────────────────────

# Installieren
sudo pacman -S restic

# Repository erstellen (verschlüsselt)
# Passwort wird interaktiv abgefragt
restic init --repo /mnt/nas/backups/$(hostname)

# Oder: Passwort-Datei verwenden
echo "MeinSicheresBackupPasswort123!" | \
    restic init --repo /mnt/nas/backups/$(hostname) --password-file /dev/stdin

# Backup erstellen
restic backup /home /etc /var/log \
    --repo /mnt/nas/backups/$(hostname) \
    --password-file /mnt/usb/backup-passwd.txt \
    --verbose

# Inkrementelles Backup (nur geänderte Daten)
restic backup /home /etc /var/log \
    --repo /mnt/nas/backups/$(hostname) \
    --password-file /mnt/usb/backup-passwd.txt

# Snapshots anzeigen
restic snapshots --repo /mnt/nas/backups/$(hostname)

# Backup wiederherstellen
restic restore latest \
    --repo /mnt/nas/backups/$(hostname) \
    --target /restore/

sudo nano /etc/cron.d/restic-backup

# Täglich um 02:00 Uhr: Backup erstellen
0 2 * * * root restic backup /home /etc /var/log \
    --repo /mnt/nas/backups/$(hostname) \
    --password-file /mnt/usb/backup-passwd.txt \
    --verbose >> /var/log/restic-backup.log 2>&1

# Wöchentlich (Sonntag 04:00): Alte Snapshots löschen
# (behält: 7 täglich, 4 wöchentlich, 6 monatlich)
0 4 * * 0 root restic forget --repo /mnt/nas/backups/$(hostname) \
    --password-file /mnt/usb/backup-passwd.txt \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
    --prune --verbose >> /var/log/restic-forget.log 2>&1

# ─────────────────────────────────────────────────────
# BorgBackup: Deduplizierung + Verschlüsselung
# ─────────────────────────────────────────────────────

# Auf dem Backup-Server (NAS):
sudo pacman -S borg

# Borg-Repository erstellen
borg init --encryption=repokey /mnt/nas/backups/$(hostname)

# Auf dem Quell-Server (Pull-Modus):
# Der Backup-Server ruft die Daten ab (kein SSH-Key auf dem Quellserver nötig!)

# Borg-Service auf dem Backup-Server konfigurieren
sudo nano /etc/borg.d/pull-webserver.conf

# Borg Pull-Konfiguration
SOURCE_HOST="webserver.local"
SOURCE_USER="backup"
SOURCE_PATH="/home /etc"
REMOTE_BORG_REPO="/mnt/nas/backups/webserver"

# SSH-Verbindung zum Quell-Server
borg create --stats --progress \
    ssh://${SOURCE_USER}@${SOURCE_HOST}${REMOTE_BORG_REPO}::'{hostname}-{now}' \
    ${SOURCE_PATH}

# ─────────────────────────────────────────────────────
# rsync + GPG: Verschlüsselter Transfer
# ─────────────────────────────────────────────────────

# GPG-Schlüssel erzeugen (einmalig)
gpg --gen-key
# Fingerabdruck notieren!
## Security Audits & Auditd

### Warum Security Audits?

Ein Security Audit ist keine Einmal-Aktion, sondern ein wiederkehrender Prozess. Die Frage ist nicht, ob ein System kompromittiert wird, sondern wann. Regelmäßige Audits finden Schwachstellen, bevor ein Angreifer sie ausnutzt.

**Wann wird ein Audit durchgeführt?**

| Anlass | Häufigkeit | Schwerpunkt |
|--------|------------|-------------|
| Routine | Halbjährlich | Komplett-Check |
| Nach Änderungen | Bei Bedarf | Betroffene Komponente |
| Incident Response | Nach Vorfall | Schadensbegrenzung |
| Compliance | Jährlich | DSGVO, IT-SiG, BSI-IT-Grundschutz |
| Vor Deploy | Bei Bedarf | Konfiguration, Abhängigkeiten |

### Audit-Checkliste

Die folgende Checkliste dient als Arbeitsvorlage für jedes Audit. Jeder Punkt wird mit Status (OK/fehlend/kritisch) und Begründung dokumentiert.

**System:**

| # | Prüfpunkt | Befehl | Status |
|---|-----------|--------|--------|
| 1.1 | Kernel-Version (hardened?) | `uname -r` | |
| 1.2 | Installierte Pakete aktuell? | `checkupdates` | |
| 1.3 | Benutzer ohne Passwort? | `awk -F: '($2 == "") {print $1}' /etc/shadow` | |
| 1.4 | Root ohne Passwort? | `passwd -S root` | |
| 1.5 | Unbenutzte Benutzer deaktiviert? | `lastlog \| grep -v "Never logged in"` | |
| 1.6 | SUID-Binaries reduziert? | `find / -perm -4000 -type f 2>/dev/null` | |

**Netzwerk:**

| # | Prüfpunkt | Befehl | Status |
|---|-----------|--------|--------|
| 2.1 | Offene Ports nur notwendige? | `ss -tlnp` | |
| 2.2 | Firewall aktiv? | `nft list ruleset` | |
| 2.3 | SSH: Root-Login deaktiviert? | `grep PermitRootLogin /etc/ssh/sshd_config` | |
| 2.4 | SSH: Passwort-Auth deaktiviert? | `grep PasswordAuthentication /etc/ssh/sshd_config` | |
| 2.5 | TLS auf allen Services? | `openssl s_client -connect ...` | |

**Verschlüsselung:**

| # | Prüfpunkt | Befehl | Status |
|---|-----------|--------|--------|
| 3.1 | LUKS aktiv? | `lsblk -f` | |
| 3.2 | LUKS-Header-Backup vorhanden? | Physisch geprüft | |
| 3.3 | SSH-Key-Verschlüsselung? | `ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key` | |
| 3.4 | TLS-Zertifikate gültig? | `openssl x509 -in ... -checkend 0` | |

**Logging:**

| # | Prüfpunkt | Befehl | Status |
|---|-----------|--------|--------|
| 4.1 | auditd aktiv? | `systemctl status auditd` | |
| 4.2 | rsyslog aktiv? | `systemctl status rsyslog` | |
| 4.3 | Zentrale Logs vorhanden? | `ls /logs/` | |
| 4.4 | Log-Rotation aktiv? | `cat /etc/logrotate.d/remote-logs` | |

**Backups:**

| # | Prüfpunkt | Befehl | Status |
|---|-----------|--------|--------|
| 5.1 | Backups vorhanden? | `restic snapshots --repo ...` | |
| 5.2 | Integrität geprüft? | `restic check --read-data ...` | |
| 5.3 | Restore-Test durchgeführt? | Dokumentation vorhanden | |
| 5.4 | Offsite-Backup vorhanden? | Physisch geprüft | |

### auditd: Das Linux Audit-Framework

`auditd` ist das Kernel-Level-Auditing für Linux. Es protokolliert System-Calls, Dateizugriffe und Benutzeraktionen auf Kernel-Ebene – das heißt, selbst ein root-Kompromittierter kann die Audit-Logs nicht löschen, ohne den Audit-Daemon zu stoppen (was im Normalfall nicht möglich ist).

**Installation und Aktivierung:**

**Audit-Regeln schreiben:**

**Audit-Regeln laden:**

**Audit-Logs auswerten:**

**Beispiel: Verdächtige Aktivität erkennen**

<blockquote class="infobox infobox--warn">
⚠️ **Audit-Performance:** Zu viele Audit-Regeln können die Performance beeinträchtigen. Jedes execve-Event erzeugt einen Audit-Eintrag. Bei einem aktiven Webserver mit vielen HTTP-Requests kann das zu erheblichem Overhead führen. Beschränke execve-Auditing auf verdächtige Programme, nicht auf alles.
</blockquote>

**Audit-Regeln optimieren:**

### LinPEAS: Automatisierte Schwachstellensuche

LinPEAS (Linux Privilege Escalation Awesome Scripts) ist ein automatisiertes Tool, das ein System auf bekannte Schwachstellen und Fehlkonfigurationen prüft, die zu einer Privilege-Eskalation führen können.

**Installation und Ausführung:**

**Wichtige Befunde und deren Bedeutung:**

<blockquote class="infobox infobox--info">
💡 **LinPEAS vs. manuelles Audit:** LinPEAS findet automatisch die häufigsten Schwachstellen. Aber es ersetzt kein manuelles Audit. Es prüft nicht auf: unbekannte Zero-Days, unternehmensspezifische Anforderungen, oder komplexe Angriffsvektoren. LinPEAS ist der ERSTE Schritt, nicht der letzte.
</blockquote>

### Audit-Kombination: Alle Tools zusammen

Ein vollständiges Security-Audit kombiniert mehrere Werkzeuge in Phasen:

┌─────────────────────────────────────────────────────────────┐
│               Security-Audit: 3-Phasen-Modell               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Phase 1: Automatisiert (Dauer: ~30 Min.)                   │
│  ────────────────────────────────────────                   │
│  - lynis audit system                                       │
│  - checksec procAll                                         │
│  - LinPEAS (Privilege Escalation Scanner)                   │
│  - auditd: ausearch -ts today                               │
│  - Output: Rohdaten, Befunde & Schwachstellen               │
│                                                             │
│  Phase 2: Manuell (Dauer: 2-4 Std.)                         │
│  ──────────────────────────────────                         │
│  - Kernel-Härtung & sysctl prüfen                           │
│  - Offene Ports & TLS-Zertifikate auditieren                │
│  - Benutzer-Rechte & SUID-Binaries prüfen                   │
│  - Backup-Integrität & Restores verifizieren                │
│  - auditd-Regelsatz & Filter validieren                     │
│                                                             │
│  Phase 3: Bericht (Dauer: 1-2 Std.)                         │
│  ──────────────────────────────────                         │
│  - Befunde nach Kritikalität bewerten (Kritisch/Hoch/...)   │
│  - Konkreten Maßnahmen- & Härtungsplan ableiten             │
│  - Revisionssicheres Archiv anlegen (3 Jahre)               │
│  - Nächsten Audit-Termin terminieren (+6 Monate)            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

**Phase 1: Automatisiert**

**Phase 2: Manuell (Auswahl)**

### Praxis: Halbjähriger Security-Audit

**Schritt 1: Vorbereitung**

**Schritt 2: Automatisierte Tools**

**Schritt 3: Manuelle Prüfungen**

**Schritt 4: Bericht erstellen**

<blockquote class="infobox infobox--info">
💡 **Audit-Archivierung:** Speichere jeden Audit-Bericht mindestens 3 Jahre. Bei einem Sicherheitsvorfall oder einer Compliance-Prüfung kannst du nachweisen, dass regelmäßige Audits durchgeführt wurden.
</blockquote>

### Verifikation

## Offizielle Dokumentation

| Thema | Dokumentation |
|-------|---------------|
| Arch Linux Wiki | [wiki.archlinux.org](https://wiki.archlinux.org/) |
| AppArmor | [apparmor.net](https://apparmor.net/) |
| linux-hardened | [github.com/anthraxx/linux-hardened](https://github.com/anthraxx/linux-hardened) |
| nftables Wiki | [wiki.nftables.org](https://wiki.nftables.org/) |
| auditd | [github.com/linux-audit/audit-userspace](https://github.com/linux-audit/audit-userspace) |
| Restic | [restic.net](https://restic.net/) |
| BorgBackup | [borgbackup.readthedocs.io](https://borgbackup.readthedocs.io/) |
| checksec | [github.com/slimm609/checksec.sh](https://github.com/slimm609/checksec.sh) |
| LinPEAS | [github.com/carlospolop/PEASS-ng](https://github.com/carlospolop/PEASS-ng) |
| systemd-cryptenroll | [freedesktop.org/software/systemd/man/systemd-cryptenroll.html](https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html) |

## Weiterführende Artikel in dieser Serie

| Artikel | Thema |
|---------|-------|
| [Systemhärtung und Sicherheit](/de/arch-linux-serie/arch-linux-systemhaertung-sicherheit-best-practices){.badge-link-text} | Grundlagen: Benutzerverwaltung, nftables, SSH, Fail2Ban |
| [Best Practices und Tipps](/de/arch-linux-serie/arch-linux-best-practices-tipps){.badge-link-text} | BTRFS, Snapper, snap-pac, grub-btrfs |
| [Paketmanagement mit Pacman](/de/arch-linux-serie/arch-linux-der-umfassende-leitfaden-vom-paketmanager-pacman){.badge-link-text} | Paketquellen, Signaturen, Bereinigung |
| [Installation und Grundkonfiguration](/de/arch-linux-serie/archlinux-installation-und-grundkonfiguration){.badge-link-text} | UEFI, Partitionierung, BTRFS, Verschlüsselung |
| [Grafische Benutzeroberfläche](/de/arch-linux-serie/arch-linux-installation-der-grafischen-benutzeroberflaeche){.badge-link-text} | Wayland, PipeWire, SDDM, KDE Plasma 6 |

## Fazit: Das gehärtete Arch-Linux-Gesamtsystem

Mit dem Abschluss dieses sechsten Teils hast du den gesamten Weg von einem leeren Speichermedium bis zu einer hochgradig abgesicherten, enterprise-tauglichen Linux-Umgebung gemeistert. Arch Linux hat dabei bewiesen, dass es weit mehr als eine reine Bastel-Distribution ist: Durch die absolute Transparenz und minimale Basis lässt sich ein Sicherheitsniveau realisieren, das selbst vielen vorkonfigurierten Server-Distributionen überlegen ist.

**Wir haben das System Schicht für Schicht gehärtet:**

1. **Fundament:** Sauberes Paketmanagement mit `pacman`, verschlüsselte BTRFS-Subvolumes und sicheres Booten via GRUB und TPM2.
2. **Betrieb:** Wartungsarme Automatisierung mit Systemd-Timern und ausfallsichere Rollbacks durch `snapper` und `grub-btrfs`.
3. **Defense in Depth:** Mandatory Access Control mit `AppArmor`, Kernel-Härtung durch `linux-hardened` und ASLR-Optimierung.
4. **Isolation:** Container-Netzwerk-Segmentierung mit `nftables` ohne gefährliche Docker-Defaults.
5. **Observability & Resilienz:** Manipulationssicheres zentrales TLS-Logging, revisionssichere `auditd`-Überwachung und eine unveränderliche 3-2-1-Backup-Strategie.

<blockquote class="infobox infobox--info">
💡 **Abschließender Praxis-Tipp:** Sicherheit ist kein statischer Zustand, sondern ein kontinuierlicher Prozess. Halte deine Audit-Routinen halbjährlich ein, prüfe Audit-Logs regelmäßig auf Anomalien und teste deine Backup-Restores mindestens einmal im Quartal unter realen Bedingungen.
</blockquote>

Du besitzt nun ein tiefgreifendes Verständnis für die Architektur moderner Linux-Systeme und die Werkzeuge, um Produktivsysteme nach höchsten Sicherheitsstandards zu konzipieren, zu betreiben und zu verteidigen.