Sicherheitsabschluss und Repository-Neustrukturierung

Dokumenten-ID: GNAI-013-PLAN
Stand: 2026-10-05
Status: Aktiver Arbeitsplan

1. Ziel

Dieser Plan führt die noch offenen Zugriffs- und Sicherheitsarbeiten bis zum Start des internen LLM-Vertical-Slice. Er ist zugleich die laufende Checkliste: Erledigte Punkte werden erst nach einem technischen Nachweis abgehakt.

2. Zielstruktur der Dokumentation

docs/
├── GNAI-000-DOC_Index.md
├── GNAI-001-PLAN_Project-Roadmap.md
├── GNAI-013-PLAN_Security-Closure-and-Repository-Restructure.md
└── platform/
    ├── GNAI-005-SEC_Access-Control.md
    ├── proxmox-server/
    │   ├── GNAI-011-SEC_LXC-SSH-Architecture.md
    │   └── lxc/
    │       ├── ct-100-dns/GNAI-012-PLAN_Pi-hole-DNS-Handoff.md
    │       ├── ct-103-reverse-proxy/GNAI-006-SEC_Reverse-Proxy.md
    │       └── ct-105-wireguard/GNAI-007-SEC_*.md
    └── llm-server/
        ├── host/GNAI-002-INFRA_BaseSystem.md
        ├── host/GNAI-003-INFRA_Users.md
        ├── ai/GNAI-004-INFRA_Architecture.md
        ├── ai/GNAI-008-PLAN_Ansible-Deployment.md
        ├── ai/GNAI-009-PLAN_Llama-Model-Evaluation.md
        ├── ai/GNAI-010-TECH_Llama-Serving.md
        └── encoding/GNENC-*.md

3. Arbeitscheckliste

A. Dokumentation und lokale Geheimnisse

Projekt- und Live-Zustand von DNS, Reverse Proxy und WireGuard lesend inventarisiert.
Dokumentation in die geräteorientierte Zielstruktur verschieben.
Alle relativen lokalen Markdown-Links nach der Verschiebung validieren.
Zentrale Indizes und Architekturübersicht an die neue Struktur anpassen.
WireGuard-Profile aus dem Repository-Baum in einen privaten lokalen Konfigurationspfad verschieben; Verzeichnis 0700, Dateien 0600.
Sicherstellen, dass keine WireGuard-PrivateKeys oder PresharedKeys in versionierten Dateien oder der Git-Historie liegen.
Bereits offengelegte Altpeers über wg-easy rotieren oder widerrufen.

B. WireGuard-Arbeitsplatz und Gateway

NetworkManager-Unterstützung auf dem CachyOS-Arbeitsplatz prüfen; wireguard-tools ist für die verwendete native NetworkManager-Methode nicht erforderlich und bleibt bewusst uninstalliert.
Laptop-Profil geschützt in NetworkManager importieren und Autoconnect zunächst deaktiviert lassen.
Verbindung aus einem fremden Netz positiv testen: Handshake, erlaubtes Ziel, Split-Tunnel und DNS.
Alten Laptopzugang zunächst Server Admin zuordnen und anschließend durch den neuen Peer ghost-laptop mit nativer nftables-Durchsetzung ersetzen.
Testpeer Android-LLMAdmin widerrufen und aus wg-easy entfernen.
Vor Gateway-Änderungen ein aktuelles konsistentes Backup von CT 105 erstellen.
Native nftables-Zielpolicy und Gateway-INPUT-Rechte umsetzen; parallele wg-easy-iptables-legacy-Hooks und Laufzeitregeln entfernen und einen wg-easy-Neustart ohne Wiederkehr der Regeln prüfen.
Positive und negative Rollentests mit absichtlich erweitertem Client-Routing durchführen.
CT 105 härten: SSH-Forwarding abschalten, Patchverfahren festlegen, defekte wtmpdb-rotate.timer-Referenz bereinigen und Wiederanlauf testen.

C. Interner Keycloak-Adminzugang

Aktuellen Keycloak-Stand und wirksame Hostname-/Proxy-Konfiguration sichern und inventarisieren.
Internen NPM-vHost für auth-admin.ghostnet.selfhost.eu mit gültigem TLS und ohne öffentliche Freigabe einrichten.
Keycloak hostname-admin passend zur installierten Version setzen.
Internen Adminlogin über LAN und berechtigte VPN-Rolle positiv testen.
Öffentliche /admin-GUI und Admin-API über HTTP und HTTPS sperren.
Externe Negativtests sowie Vaultwarden-/OIDC-Regression durchführen.

D. Reverse Proxy, Fail2Ban und Recovery

Fail2Ban-Konfiguration, aktive Jails und Imagezustand prüfen.
Kontrollierten Ban/Unban für HTTP und HTTPS nachweisen.
Dienst- und LXC-Wiederanlauf einschließlich Jails und Regeln testen.
Praktischen FRITZ!Box-DNS-Rollback auf einem Testclient durchführen.
Hostunabhängige Backupkopien und mindestens einen Restore-Test planen beziehungsweise abnehmen.

E. Übergang zum LLM-Stack

KI-Server kontrolliert einschalten und Resolver auf den beschlossenen Pi-hole-Pfad abstimmen.
Lokale Ansible-.venv wegen des veralteten Repository-Pfads neu erstellen und alle Syntaxprüfungen regulär ausführen.
Lesenden Preflight sowie Host-/ROCm-Verifikation wiederholen.
Internes, nicht öffentliches llama.cpp-Testing-Vertical-Slice nach GNAI-010 implementieren und bei 64k abnehmen.

4. Arbeitsnachweise

05.10.2026 – Struktur, Geheimnisse und lokaler VPN-Client

Dokumente geräteorientiert verschoben; lokaler Linkvalidator meldet broken_local_links=0, alte Pfadverweise wurden nicht mehr gefunden.
Profile liegen in ~/.config/ghostnet/wireguard/; beide Dateinamen sind als Linux-Interface-Namen gültig. Elternverzeichnisse sind 0700, Dateien 0600.
Aktueller Arbeitsbaum und vollständige Git-Historie enthalten keine WireGuard-Schlüsselzuweisung im Format eines Base64-Schlüssels. Zwei Treffer in einer alten Anleitung sind keine Schlüsselwerte, sondern erklärender Beispieltext beziehungsweise Satzzeichen.
NetworkManager 1.58.1 hat gnai-laptop nativ importiert. Autoconnect ist aus, die Verbindung ist auf ghost beschränkt und wieder inaktiv; im Heimnetz ist keine WireGuard-Route verblieben.
wireguard-tools ist nicht installiert und für die gewählte native NetworkManager-Methode nicht erforderlich. Es wird nur bei späterem Bedarf an wg, wg-quick oder entsprechender CLI-Diagnose ergänzt.
Betreiberentscheidung: Laptop = Server Admin; der reine Android-Testpeer wird widerrufen.
Vor dem Peer-Widerruf wurde ein stop-konsistentes, rootgeschütztes wg-easy-Anwendungsbackup erstellt; Archiv- und Datenbankintegrität sowie der Dienstwiederanlauf wurden bestätigt. Ein vollständiges Proxmox-LXC-Backup ist dadurch nicht ersetzt.
Das lokale Android-Profil ist entfernt. Die endgültige serverseitige Löschung erfolgte über eine authentifizierte wg-easy-Administratorsitzung. Danach enthielten Datenbank und aktives wg0 jeweils genau den verbleibenden Laptop-Peer; SQLite-Integritätsprüfung und Dienststatus waren fehlerfrei.
Der Altpeer routet noch das gesamte LAN und verwendet 10.0.0.1 als DNS. Der neue Peer gnai-ghost-laptop mit 10.8.0.3 ersetzt ihn mit neuen Schlüsseln; seine explizite Client-Routenliste und der Profilimport stehen noch aus. Für Server Admin wurden einzelne dokumentierte Server-/32 einschließlich Pi-hole 10.0.0.14 beschlossen; Pi-hole ist zugleich der DNS-Server für Split-DNS. Die wg-easy-Per-Client-Firewall bleibt bewusst aus.
Native nftables-Sets und natives MASQUERADE sind mit den alten und neuen Laptop-Peer-IPs aktiv. Syntaxprüfung, gesicherter Rollout, neue SSH-Verbindung, Dienste, wg0, Netavark-Erhalt und Persistenzdatei wurden geprüft. Die wg-easy-Legacy-Hooks und ihre vier Laufzeitregeln wurden nach gesondertem Backup entfernt; nach kontrolliertem wg-easy-Neustart blieben Legacy-Regelzahl null, native Policy, NAT, Netavark, zwei Peers und GUI aktiv.
Das neue Profil ghost-laptop.conf wurde mit .3/32, Pi-hole-DNS und den elf Serverzielen validiert, geschützt nach ~/.config/ghostnet/wireguard/ verschoben und in NetworkManager manuell/inaktiv für ghost importiert. Der alte lokale Eintrag und die alte Profildatei sind entfernt.
Fremdnetzabnahme über Smartphone-Hotspot 10.62.63.0/24: aktueller Handshake und Transfer, Pi-hole-/Split-DNS, Proxmox, Keycloak, NPM, Pi-hole, wg-easy und Gateway-SSH bestanden. Die öffentliche IPv4 blieb vor, während und nach Aktivierung gleich. Mit absichtlich um 10.0.0.1/32 erweitertem Testprofil blieb Proxmox erreichbar, während die aktive FRITZ!Box per ICMP und HTTP gesperrt war; nftables-Zähler belegten vier erlaubte neue Verbindungen und drei Drops. Testverbindung und temporäres Profil wurden anschließend entfernt.
Nach bestandener Abnahme wurde Laptop-FullAdmin .2 über wg-easy gelöscht. Datenbank und wg0 enthalten nur noch ghost-laptop .3; .2 wurde auch aus der persistenten nftables-Rollenmenge entfernt. DNS, Proxmox und wg-easy funktionierten danach weiter, Legacy-Regelzahl blieb null und das VPN wurde kontrolliert getrennt.
Der Betreiber erstellte anschließend ein vollständiges Proxmox-Backup von CT 105 im Modus Stop. Der dadurch ausgelöste Wiederanlauf um 17:19 Uhr wurde live abgenommen: SSH, nftables und wg-easy waren aktiv, die persistente nftables-Datei bestand die Syntaxprüfung, Rollen- und Zielsets sowie natives NAT waren vorhanden, iptables-legacy enthielt keine wg-easy-Regeln, genau ein WireGuard-Peer war aktiv, SQLite meldete integrity_check=ok und die lokale wg-easy-GUI antwortete mit HTTP 302.
Die SSH-Baseline von CT 105 deaktiviert nun TCP-, Agent-, StreamLocal-, X11- und Tunnel-Forwarding. Ein Remote-Forwarding-Negativtest wurde vom Server abgelehnt. Der verwaiste wtmpdb-rotate.timer-Symlink wurde entfernt und ein kontrollierter LXC-Neustart um 17:38 Uhr bestätigte die Persistenz der SSH-, Firewall- und wg-easy-Konfiguration ohne fehlgeschlagene Units. Systemupdates erfolgen künftig kontrolliert manuell nach Simulation und mit dokumentiertem Health-Check; unbeaufsichtigte Upgrades bleiben deaktiviert.

5. Aktuell bestätigte Blocker

Der öffentliche Keycloak-Adminpfad ist noch erreichbar.
Die native WireGuard-Rollenpolicy ist aktiv und die Legacy-Regeln sind bereinigt; Fremdnetz-, Positiv-, Negativ- und Wiederanlauftests sind abgeschlossen.
Fail2Ban läuft, seine aktuelle funktionale Ban-Wirkung ist aber nicht abgenommen.
Der KI-Server ist bewusst ausgeschaltet und wird für die Punkte A bis D nicht benötigt.

6. Pflege

Nach jedem Arbeitsschritt werden hier Status und Nachweis aktualisiert. Ein Punkt gilt nicht allein aufgrund einer gespeicherten Konfiguration als erledigt, sondern erst nach dem zugehörigen Positiv- oder Negativtest.

10 KiB Raw Blame History Unescape Escape