# Sicherheitsabschluss und Repository-Neustrukturierung **Dokumenten-ID:** GNAI-013-PLAN **Stand:** 2026-10-14 **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 ``` Die ausführbare Infrastruktur ist seit 14.10.2026 ebenfalls hostbezogen: ```text ghostnet.ai-infrastructure/ ├── llm-server/ansible/ # physischer KI-Server ├── proxmox/ │ ├── shared/scripts/ # nur LXC-übergreifende PVE-Helfer │ └── lxc/ │ ├── ct-100-dns/ # Hostwurzel; Ansible-Import offen │ ├── ct-102-keycloak/{ansible,scripts}/ │ ├── ct-103-reverse-proxy/ # Hostwurzel; Ansible-Import offen │ ├── ct-104-keycloak/ # erhaltener Rückfall-/Referenzstand │ └── ct-105-wireguard/ └── shared/ansible/ # gemeinsam genutzte Rollen und Pins ``` Inventare und Playbooks liegen beim Zielhost. `shared/` enthält keine hostbezogenen Playbooks oder Inventare. ## 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. - [x] Wiederverwendbare LXC-Baseline als versionierten, idempotenten Proxmox-Post-install-Hook erstellen, auf CT 104 kontrolliert erproben und dokumentieren. Der Hook darf keine privaten Schlüssel enthalten und SSH nicht sperren, bevor individuelle Schlüsselzugänge geprüft wurden. ### 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 - [x] Sichere SSH-Zugänge für den Keycloak-LXC nach der gemeinsamen LXC-Baseline einrichten und positiv wie negativ testen. - [x] Aktuellen Keycloak-Stand und wirksame Hostname-/Proxy-Konfiguration sichern und inventarisieren. - [x] Leserechte der lokalen Keycloak-H2-Datenbank sofort auf Root begrenzen und den Agenten-Negativtest wiederholen. - [x] H2-`dev-file` und `start-dev` durch eine gesicherte Podman-/PostgreSQL-Blue/Green-Migration nach GNAI-015 ersetzen. - [x] Keycloak 26.2.4 im gepinnten Produktionsimage betreiben; ein späteres 26.x-Upgrade bleibt ein eigener kontrollierter Wartungsschritt. - [x] Internen NPM-vHost für `auth-admin.ghostnet.selfhost.eu` mit gültigem TLS und ohne öffentliche Freigabe einrichten. - [x] Keycloak `hostname-admin` passend zur installierten Version setzen. - [x] Internen Adminlogin über LAN positiv testen; Server-Admin-VPN nutzt denselben per Gateway freigegebenen NPM-Zielpfad. - [x] Öffentliche `/admin`-GUI und Admin-API über HTTPS sperren. - [x] Externe Negativtests sowie reale 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. - [x] 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. - Die Keycloak-Vorprüfung bestätigt Split-DNS zum internen Adminnamen, aber noch keinen passenden NPM-TLS-vHost. Der öffentliche `/admin`-Pfad bleibt erreichbar; Backendtests mit beiden Hostnamen erzwingen weiterhin den öffentlichen Frontendnamen und die Master-Realm-Discovery nennt den öffentlichen Issuer. Version und startwirksame `KC_HOSTNAME*`-Parameter müssen als Nächstes direkt im Keycloak-LXC inventarisiert werden. - CT 102 wurde über den unabhängig bestätigten ED25519-Hostschlüssel in die gemeinsame SSH-Architektur aufgenommen. `ghost-agent` besitzt weder Zusatzgruppen noch sudo; `ghost` verwendet einen eigenen passphrasegeschützten Schlüssel und passwortgeschütztes sudo. Root-, Passwort- und Forwarding-Zugriffe wurden nach dem Dienstneustart extern abgelehnt, beide Schlüsselzugänge positiv geprüft. Der vollständige LXC-Wiederanlauf folgt erst nach einem aktuellen Stop-Backup. - Beim Bootstrap zeigte sich eine bestehende numerische Eigentümerschaft von 464 Keycloak-Einträgen unter UID 1001/GID 118. Das zunächst mit UID 1001 angelegte Administratorkonto wurde nach Prüfung freier IDs auf UID/GID 1101 verschoben. Danach konnte `ghost` weder Programm noch Konfiguration schreiben; Agenten- und persönlicher Zugang, sudo, Passwortsperre sowie Keycloak und SSH wurden erneut erfolgreich geprüft. Die historischen Eigentümer werden erst nach Backup und gesonderter Betriebsprüfung bewertet. - Der neue Lesekanal bestätigt Keycloak 26.2.4 als nativen, rootgeführten systemd-Dienst aus `/opt/keycloak`. Der Dienst verwendet derzeit `kc.sh start-dev`, HTTP auf Port 8080, `proxy=edge`, `proxy-headers=xforwarded`, den festen öffentlichen Hostnamen und noch kein `hostname-admin`. Prüfsummen von Unit und Konfiguration wurden erfasst. Der Entwicklungsstart wird als eigener Härtungspunkt behandelt und nicht unkontrolliert mit der Adminpfad-Änderung vermischt. - Ein vollständiges Proxmox-Backup von CT 102 wurde im Modus `Stop` erstellt. Der LXC startete um 19:37 Uhr mit unveränderten Konfigurationsprüfsummen, UID-Trennung und Listenern. Keycloak und beide SSH-Units waren aktiv und aktiviert; Agenten- und persönlicher Schlüsselzugang, passwortgeschütztes sudo sowie Root-, Passwort- und Forwarding-Negativtests bestanden erneut. - Die Anwendung verwendet ausschließlich die lokale H2-`dev-file`-Datenbank; eigene Provider oder Themes wurden nicht gefunden. Daten- und H2-Verzeichnis sowie Datenbank- und Trace-Datei sind `0755` beziehungsweise `0644`; `ghost-agent` konnte die Identitätsdatenbank lesen. Dieser unmittelbare Rechtebefund wird vor weiteren Keycloak-Arbeiten geschlossen. - GNAI-015 legt die Migration als Blue/Green-Verfahren in CT 104 mit `10.0.0.16` fest. CT-ID und IP wurden bei der Erstellung auf Kollisionen geprüft. Import auf gleicher Version, PostgreSQL-Meilenstein, separates Versionsupgrade, Adminpfad-Trennung, NPM-Cutover, 14-tägiger Rückfallstand und Restore-Test besitzen eigene Abnahmeschranken. - Die H2-Verzeichnisse sind nun `0700`, die Datenbankdateien `0600` und systemd setzt für Keycloak `UMask=0077`. `ghost-agent` konnte das Datenverzeichnis danach weder traversieren noch die Datenbank lesen. Keycloak, SSH, lokale und öffentliche Discovery blieben funktionsfähig. Die zuvor irrtümlich dokumentierte CT-ID 106 wurde auf die tatsächlich verwendete CT-ID 104 korrigiert; die Ziel-IP bleibt `10.0.0.16`. - CT 104 wurde am 06.10.2026 über das Community-Script als unprivilegierter Debian-13-LXC mit 12 GB Datenträger, zwei CPU-Kernen, 4096 MiB RAM und vorinstalliertem Podman erstellt. IPv4, Internet- und DNS-Zugriff waren laut Installationsprotokoll erfolgreich; IPv6 war wie vorgesehen nicht verbunden. Podman 5.4.2, die UID-Map `0 -> 100000` und ein fehlerfreier systemd-Zustand wurden anschließend bestätigt. Der ED25519-Hostschlüssel `SHA256:AmLKE4H/ulGBQqC/J7mGO7rcu5U/xHtyKk45hhBuNRw` stimmte zwischen Proxmox-Konsole und unabhängiger Messung vom Admin-Laptop überein. - Das erste Stop-Baseline-Backup von CT 104 wurde erfolgreich als `/media/datenhdd2/dump/vzdump-lxc-104-2026_10_06-14_49_53.tar.zst` erstellt; der LXC war nach 16 Sekunden wieder online. Vor der Benutzeranlage wurde die Swap-Größe von 512 auf 1024 MiB angehoben. Der folgende Neustart bestätigte aktive SSH-Units, Podman 5.4.2 und keine fehlgeschlagenen systemd-Units. Hostname `keycloak` und die vorhandenen Community-Script-Tags bleiben auf Betreiberwunsch unverändert; CT 102 und CT 104 werden deshalb in Zugängen und Dokumentation stets über CT-ID und IP unterschieden. Für UID/GID 1000, 1001 und 1101 wurden keine vorhandenen Konten, Gruppen oder Dateieigentümer gefunden. - `ghost-agent` wurde auf CT 104 als UID/GID 1000 mit gesperrtem Passwort, eigener Primärgruppe und ohne Zusatzgruppen eingerichtet. Der dedizierte Schlüssel besitzt den Fingerprint `SHA256:GCCeciGznhKQjb8xRWm6qbqKNdsuIJAQ1+cgNzcKPmM`; Rechte, strikte Hostschlüsselbindung und der lokale Alias `ghostnet-ct104-agent` wurden praktisch geprüft. Eine Kontrollverbindung zu CT 102 bestätigte, dass dessen bestehender Agentenschlüssel mit Fingerprint `SHA256:PXJ0yuEyVoaW2CI5IVax5DYjM8u26Qfyyx/pIrmIkx0` durch den kurzzeitigen Bedienfehler nicht verändert wurde. - `ghost` wurde auf CT 104 als UID/GID 1001 mit eigenem passphrasegeschütztem Schlüssel und passwortgeschütztem sudo eingerichtet; Schlüsselfingerprint `SHA256:4OgAGXgf6M/uQFnGdDTcZ+5qturtdWDTUHb5FCjdz+8`. Das SSH-Drop-in `99-security.conf` erlaubt nur `ghost-agent` und `ghost`, verlangt Public Key und sperrt Root-, Passwort-, X11-, Agent-, TCP-, StreamLocal- und Tunnel-Forwarding. Positivtests beider Rollen, sudo, Root-/Passwort- und Forwarding-Negativtests sowie ein vollständiger LXC-Neustart mit aktiven SSH-Units, Podman 5.4.2 und ohne fehlgeschlagene systemd-Units wurden erfolgreich abgenommen. - Der secretfreie Post-install-Hook `proxmox/shared/scripts/ghostnet-lxc-baseline.sh` wurde mit Modus `0750` als `/usr/local/sbin/ghostnet-lxc-baseline.sh` auf Proxmox installiert. Seine geprüfte SHA-256 lautet `a0ee32a8fc2854c29a83b17b4e0cdb5ad55cde36de92d562f6bd890dc93ae89e`. Der idempotente Lauf gegen CT 104 übersprang die bereits vorhandenen Pakete, validierte beide Konten samt Passwortzustand und bewahrte die vorhandenen Schlüsseldateien. Anschließende Positiv- und Negativtests bestätigten den Agentenzugang sowie die fortbestehenden Root-, Passwort- und Forwarding-Sperren. - Auf CT 104 wurde eine eigene nftables-Tabelle `inet ghostnet_filter` mit INPUT- und FORWARD-Drop eingerichtet. Ein systemd-Override ersetzt das distributionsseitige vollständige `flush ruleset` beim Stoppen durch das Entfernen ausschließlich der Ghostnet-Tabelle. Die persistent neu geladene Konfiguration erlaubte SSH und ICMP, verwarf TCP 8080 vom Admin-Laptop und ließ denselben geschlossenen Port von CT 103 bis zum erwarteten sofortigen TCP-Reset passieren. IPv4-Forwarding ist für das geplante Podman-Netz aktiv, IPv6-Forwarding bleibt aus. Die abschließende Prüfung mit einem digest-gepinnten BusyBox-Quadlet belegte Aardvark-DNS, die feste Containeradresse `10.89.0.20`, Netavark-DNAT und den Quellfilter: CT 103 erhielt vor und nach einem vollständigen LXC-Neustart unmittelbar eine HTTP-Antwort, der Admin-Laptop lief jeweils in einen Timeout. nftables, Podman-Netz, Testcontainer und der gehärtete SSH-Zugang kamen nach dem Neustart automatisch und fehlerfrei wieder. ## 5. Aktuell bestätigte Blocker - Der öffentliche Keycloak-Adminpfad ist gesperrt; interner Adminzugang und Vaultwarden-OIDC sind abgenommen. - 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. - CT 102 befindet sich in der 14-tägigen Stabilisierungsphase; der praktische NPM-Rückfall auf den ausgeschalteten CT 104 bleibt offen. ## 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.