# 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 ```text 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 - [x] Projekt- und Live-Zustand von DNS, Reverse Proxy und WireGuard lesend inventarisiert. - [x] Dokumentation in die geräteorientierte Zielstruktur verschieben. - [x] Alle relativen lokalen Markdown-Links nach der Verschiebung validieren. - [x] Zentrale Indizes und Architekturübersicht an die neue Struktur anpassen. - [x] WireGuard-Profile aus dem Repository-Baum in einen privaten lokalen Konfigurationspfad verschieben; Verzeichnis `0700`, Dateien `0600`. - [x] Sicherstellen, dass keine WireGuard-PrivateKeys oder PresharedKeys in versionierten Dateien oder der Git-Historie liegen. - [x] Bereits offengelegte Altpeers über wg-easy rotieren oder widerrufen. ### B. WireGuard-Arbeitsplatz und Gateway - [x] 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. - [x] Laptop-Profil geschützt in NetworkManager importieren und Autoconnect zunächst deaktiviert lassen. - [x] Verbindung aus einem fremden Netz positiv testen: Handshake, erlaubtes Ziel, Split-Tunnel und DNS. - [x] Alten Laptopzugang zunächst Server Admin zuordnen und anschließend durch den neuen Peer `ghost-laptop` mit nativer nftables-Durchsetzung ersetzen. - [x] Testpeer `Android-LLMAdmin` widerrufen und aus wg-easy entfernen. - [x] Vor Gateway-Änderungen ein aktuelles konsistentes Backup von CT 105 erstellen. - [x] 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. - [x] Positive und negative Rollentests mit absichtlich erweitertem Client-Routing durchführen. - [x] 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.