# Alpine Security: LUKS und System-Härtung

TL;DR / Management Summary Alpine Linux ist von Haus aus sicher, aber für den Betrieb auf physischer Hardware oder Edge-Devices ist die Verschlüsselung der Daten unumgänglich. In diesem Modul lernen wir, wie man LUKS (Linux Unified Key Setup) in das minimalistische Alpine-System integriert, wie der Boot-Prozess die Entschlüsselung via mkinitfs handhabt und welche zusätzlichen Härtungsmaßnahmen (wie PaX und Stack-Protection) Alpine standardmäßig mitbringt.

# 1. Einführung & Architektur

Security by Design.

Alpine nutzt den “Hardened” Kernel als Standard. Er enthält Patches gegen Buffer Overflows und Memory-Exploits. Die Disk-Verschlüsselung schützt die Daten zusätzlich, falls das physische Gerät gestohlen wird.

# Der Security-Stack (Mermaid)

graph TD
    A[Hardware: Disk] --> B[LUKS Header]
    B --> C[Kernel: dm-crypt]
    C --> D[Alpine initfs: Decryption Prompt]
    D --> E[Root Filesystem: /]
    subgraph "Kernel Security"
        F[SSP: Stack Smashing Protection]
        G[PIE: Position Independent Executables]
        H[PaX / Grsec: Zero-Day Protection]
    end
    E --- F
    E --- G
    E --- H

# 2. Disk Encryption (LUKS) einrichten

Verschlüsselung beim Setup.

Alpine macht es einem einfach, die Verschlüsselung während der Installation zu aktivieren.

# via setup-alpine

1. Starten Sie setup-alpine.
2. Wählen Sie die Disk für die Installation.
3. Auf die Frage nach dem Disk-Modus antworten Sie: crypt.
4. Geben Sie eine starke Passphrase ein.

# Manuelle Verwaltung (cryptsetup)

Falls Sie eine zusätzliche Datenplatte verschlüsseln wollen:

apk add cryptsetup
cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 secure_data
mkfs.ext4 /dev/mapper/secure_data

# 3. Initramfs Konfiguration

Den Boot-Prozess vorbereiten.

Damit Alpine beim Booten nach dem Passwort fragt, muss das crypt-Feature in das Initramfs eingebaut werden.

Datei: /etc/mkinitfs/mkinitfs.conf

features="ata base ide scsi virtio ext4 crypt"

Danach das Image neu bauen:

mkinitfs $(uname -r)

# 4. Day-2 Operations: System Härtung

Den Wächter schärfen.

# 1. Read-Only Root (Diskless Mode)

Alpine ist prädestiniert für den Betrieb als Read-Only System.

• Vorteil: Ein Angreifer kann keine permanenten Änderungen am System vornehmen.
• Wartung: Änderungen müssen mit lbu commit explizit gespeichert werden.

# 2. Sudo vs. Doas

Alpine nutzt oft doas statt sudo, um die Komplexität und Angriffsfläche zu minimieren.

apk add doas
# Config in /etc/doas.conf
# permit persist :wheel

# 5. Troubleshooting & “War Stories”

Wenn der Schlüssel klemmt.

# Story 1: “Der hängende Remote-Reboot”

Symptom: Ein Server in einem fernen RZ wird neu gestartet, kommt aber nicht wieder online. Ursache: Der Server wartet an der physischen Konsole auf die LUKS-Passphrase. Ohne IPMI/KVM-over-IP ist der Server “tot”. Lösung: Nutzen Sie Dropbear-initramfs. Dies startet einen minimalistischen SSH-Server im Boot-Prozess, über den Sie das Passwort aus der Ferne eingeben können.

# Story 2: “Das langsame Crypto-I/O”

Symptom: Die I/O-Performance auf einer verschlüsselten SSD ist deutlich schlechter als auf einer unverschlüsselten. Ursache: Die CPU unterstützt keine Hardware-Beschleunigung (AES-NI) oder der Kernel nutzt ineffiziente Buffer-Größen. Lösung: Prüfen Sie mit cryptsetup benchmark. Stellen Sie sicher, dass in der /etc/fstab die Option discard gesetzt ist (falls Sie der Sicherheitseinbuße durch SSD-Trim zustimmen).

# 6. Fazit & Empfehlung

• Edge Devices: Nutzen Sie LUKS für alle Geräte, die nicht in einem gesicherten RZ stehen.
• Automation: Nutzen Sie Keyfiles für automatisierte Backups, aber schützen Sie diese via Berechtigungen (600).
• Integrität: Kombinieren Sie LUKS mit einem Trusted Platform Module (TPM), falls Ihre Hardware dies unterstützt.

# Anhang: Cheatsheet