diff --git a/docs/GNAI-000-DOC_Index.md b/docs/GNAI-000-DOC_Index.md index e5bd569..45a56c9 100644 --- a/docs/GNAI-000-DOC_Index.md +++ b/docs/GNAI-000-DOC_Index.md @@ -1,6 +1,6 @@ # Ghostnet.AI – Dokumentationsindex und Projektstand -**Stand:** 2026-09-21 +**Stand:** 2026-09-22 **Status:** Plattformgrundlage vorhanden; Sicherheitsabschluss und LLM-Serving offen @@ -22,14 +22,15 @@ jeweiligen Fachdokumenten. Die priorisierte weitere Umsetzung beschreibt der | Dokument | Verbindlicher Inhalt | | --- | --- | | [Bereichsindex](platform/README.md) | Einstieg in Host-, Zugriffs-, Reverse-Proxy- und VPN-Dokumentation | -| [GNAI-002](platform/GNAI-002-INFRA_BaseSystem.md) | Hardware und Debian-Basis des KI-Servers | -| [GNAI-003](platform/GNAI-003-INFRA_Users.md) | Benutzer, Hostnetz, Resolver und SSH | +| [Ghostnet.AI-Host](platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basis des KI-Servers `10.0.0.90` | +| [Ghostnet.AI-Zugänge](platform/ghostnet-ai/GNAI-003-INFRA_Users.md) | GNAI-003 Benutzer, Hostnetz, Resolver und SSH des KI-Servers | | [GNAI-005](platform/GNAI-005-SEC_Access-Control.md) | Rollen- und Zugriffsziel | -| [GNAI-006](platform/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad | -| [GNAI-007](platform/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall | -| [VPN-Client-Verwaltung](platform/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen | -| [Windows 11](platform/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs | -| [VPN-Implementation-Log](platform/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz | +| [Proxmox-LXC-SSH](platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md) | GNAI-011 gemeinsame SSH-Sicherheitsarchitektur der LXCs; Hypervisor ausgenommen | +| [CT 103 / GNAI-006](platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) | NPM, Fail2Ban und Keycloak-Adminpfad | +| [CT 105 / GNAI-007](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall | +| [VPN-Client-Verwaltung](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md) | Ausgabe, Änderung und Widerruf von Geräteprofilen | +| [Windows 11](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md) / [Linux](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md) | Client-SOPs | +| [VPN-Implementation-Log](platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung und datierte Evidenz | ### KI und Deployment @@ -52,6 +53,8 @@ jeweiligen Fachdokumenten. Die priorisierte weitere Umsetzung beschreibt der Die Dokumente wurden am 21.09.2026 neu geordnet: Die Roadmap belegt `GNAI-001`; die zuvor bestehenden Dokumente `GNAI-001` bis `GNAI-009` wurden unter Beibehaltung ihrer Reihenfolge zu `GNAI-002` bis `GNAI-010`. +Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse +überführt; GNAI-011 beschreibt die gemeinsame SSH-Architektur der LXCs. ## 2. Belegter Stand @@ -61,8 +64,8 @@ unter Beibehaltung ihrer Reihenfolge zu `GNAI-002` bis `GNAI-010`. | GPU/ROCm | beide RX 6900 XT als `gfx1030`, `ROCm0` und `ROCm1` im gepinnten Testing-Image erkannt | Modellladen, Layer-Verteilung, reale Inferenz, 64k/128k-Stabilität | | LLM-Serving | zwei unveränderlich definierte Modellkandidaten und technische Sollkonfiguration | Modelle, Quadlets, dauerhaftes Podman-Netz und Health Checks | | Deployment | lokales Ansible-Control-Projekt und idempotente Hostrollen | statische CI, Runner, geschützte Freigaben, Production-Inventar und automatisierter Rollback | -| VPN | wg-easy v15.4.0 aktiv, WAN-Handshake als Teiltest | serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme | -| Reverse Proxy | NPM aktiv; Fail2Ban-Pin laut Betreiber umgesetzt | wirksame Jails/Bans und Wiederanlauf; Keycloak-Adminpfad weiterhin offen | +| VPN | wg-easy v15.4.0 und Regelwerke am 22.09.2026 live geprüft; Schlüsseldateien auf `0600` gehärtet | serverseitige Rollenrechte, negative Tests, IPv6-/Restart-/Restore-Abnahme | +| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo und SSH-Baseline aktiv; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und Wiederanlauf; Keycloak-Adminpfad weiterhin offen; Netzwerk- und Rebootabnahme der SSH-Baseline | | Encoding | Konto, Pfade und eigener rootless Store | Workload, Zeitsteuerung, Ressourcenlimits und Lasttest | Ein Zielbild, eine Betreiberangabe oder ein erfolgreicher Teiltest gilt nicht als diff --git a/docs/GNAI-001-PLAN_Project-Roadmap.md b/docs/GNAI-001-PLAN_Project-Roadmap.md index 9fa141c..627473d 100644 --- a/docs/GNAI-001-PLAN_Project-Roadmap.md +++ b/docs/GNAI-001-PLAN_Project-Roadmap.md @@ -4,7 +4,7 @@ **Titel:** Priorisierte Roadmap für Ghostnet.AI -**Stand:** 2026-09-21 +**Stand:** 2026-09-22 **Status:** Arbeitsgrundlage; Entscheidungstore vor externer Veröffentlichung offen @@ -61,6 +61,15 @@ Netzwerkgrenzen, bevor weitere öffentliche Dienste hinzukommen. - WAN- und IPv6-Exposure für Managementports erfassen; - Ergebnisse mit Datum und Negativtests in GNAI-006/GNAI-007 dokumentieren. +**Ausführungsstand 22.09.2026:** Die externe Keycloak-Administration und die +fehlende VPN-Rollenisolierung sind live bestätigt. Die Schlüsseldateien des +WireGuard-Gateways wurden auf `0600` gehärtet. Für die nächsten wirksamen +Änderungen fehlen (1) ein aktueller Rückfallstand und administrativer Zugriff +auf CT 103 sowie (2) die verbindliche Rolle der beiden vorhandenen VPN-Peers. +Die technische Reihenfolge ist deshalb: Backup und Recovery-Pfad sichern, +öffentlichen `/admin`-Pfad sperren und regressionsprüfen, Peers zuordnen und +Gateway-Regeln umsetzen, anschließend Fail2Ban- und Wiederanlauftests. + **Fertig, wenn:** Die vier priorisierten Sicherheitsbefunde im zentralen Index als bestanden oder mit ausdrücklich akzeptiertem Restrisiko dokumentiert sind. diff --git a/docs/ai/GNAI-004-INFRA_Architecture.md b/docs/ai/GNAI-004-INFRA_Architecture.md index c695d07..5a65902 100644 --- a/docs/ai/GNAI-004-INFRA_Architecture.md +++ b/docs/ai/GNAI-004-INFRA_Architecture.md @@ -3,7 +3,7 @@ **Dokumenten-ID:** GNAI-004-INFRA **Titel:** Homelab / LLM-Infrastruktur – Zielarchitektur **Status:** Zielarchitektur; bestätigter Teilstand und offene Umsetzung separat ausgewiesen -**Vorgänger / Referenzen:** [Basisinstallation](../platform/GNAI-002-INFRA_BaseSystem.md), [Benutzer/SSH](../platform/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../platform/GNAI-005-SEC_Access-Control.md), [Reverse Proxy](../platform/GNAI-006-SEC_Reverse-Proxy.md), [WireGuard](../platform/GNAI-007-SEC_VPN.md) +**Vorgänger / Referenzen:** [Basisinstallation](../platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md), [Benutzer/SSH](../platform/ghostnet-ai/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../platform/GNAI-005-SEC_Access-Control.md), [Reverse Proxy](../platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md), [WireGuard](../platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) --- diff --git a/docs/platform/GNAI-005-SEC_Access-Control.md b/docs/platform/GNAI-005-SEC_Access-Control.md index 0d4274c..879e624 100644 --- a/docs/platform/GNAI-005-SEC_Access-Control.md +++ b/docs/platform/GNAI-005-SEC_Access-Control.md @@ -3,7 +3,7 @@ **Dokumenten-ID:** GNAI-005-SEC **Titel:** Homelab / LLM-Infrastruktur – Sicherheits-, Authentifizierungs- und Zugriffskonzept **Status:** Verbindliches Zielmodell; technische Durchsetzung teilweise offen -**Vorgänger / Referenzen:** [Architektur](../ai/GNAI-004-INFRA_Architecture.md), [Gateway](GNAI-007-SEC_VPN.md), [GUI-SOP](GNAI-007-SEC_VPN_Client-Management.md), [Reverse Proxy](GNAI-006-SEC_Reverse-Proxy.md) +**Vorgänger / Referenzen:** [Architektur](../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md), [Gateway](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md), [GUI-SOP](proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md), [Reverse Proxy](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) --- @@ -213,7 +213,7 @@ Nicht vorgesehen ist ein pauschales Blocking aller HTTP-Fehlercodes. Insbesondere soll ein allgemeiner `404` nicht automatisch als Angriff gewertet werden. -Die vorhandenen NPM-Jails sind in [GNAI-006](GNAI-006-SEC_Reverse-Proxy.md) dokumentiert. Ihre Funktion nach dem Image-Pin sowie Neustart und Wiederanlauf müssen noch abgenommen werden. +Die vorhandenen NPM-Jails sind in [GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) dokumentiert. Ihre Funktion nach dem Image-Pin sowie Neustart und Wiederanlauf müssen noch abgenommen werden. --- @@ -302,4 +302,4 @@ Das Sicherheitsmodell basiert damit nicht auf einem einzelnen „Security-Progra ## 11. Umsetzungsnachweise -Dieses Dokument definiert die Zugriffsziele. Der [Dokumentationsindex](../GNAI-000-DOC_Index.md) bündelt den aktuellen Projektstand. Konkrete Gateway-Regeln und Rollentests stehen in [GNAI-007](GNAI-007-SEC_VPN.md), der Keycloak-Adminpfad und Fail2Ban in [GNAI-006](GNAI-006-SEC_Reverse-Proxy.md). Offene Zielrechte gelten bis zu ihrer technischen Abnahme nicht als durchgesetzt. +Dieses Dokument definiert die Zugriffsziele. Der [Dokumentationsindex](../GNAI-000-DOC_Index.md) bündelt den aktuellen Projektstand. Konkrete Gateway-Regeln und Rollentests stehen in [GNAI-007](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md), der Keycloak-Adminpfad und Fail2Ban in [GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md). Offene Zielrechte gelten bis zu ihrer technischen Abnahme nicht als durchgesetzt. diff --git a/docs/platform/README.md b/docs/platform/README.md index 0a45e46..9a05548 100644 --- a/docs/platform/README.md +++ b/docs/platform/README.md @@ -1,21 +1,20 @@ # Plattform- und Hostdokumentation -Dieser Bereich enthält die gemeinsame Infrastruktur, auf der KI- und -Encoding-Workloads aufbauen. Dazu gehören Hostinstallation, Benutzer und SSH, -das übergreifende Zugriffsmodell, Reverse Proxy und VPN. Workload-spezifische -Architektur und Nutzerverfahren liegen in den jeweiligen Nachbarverzeichnissen. +Dieser Bereich trennt den physischen KI-Host von den auf Proxmox betriebenen +LXCs. Übergreifende Rollen und Zugriffsziele bleiben auf dieser Ebene; +host- beziehungsweise LXC-spezifische Betriebsdokumente liegen in eigenen +Unterverzeichnissen. Die SSH-Konfiguration des Proxmox-Hypervisors selbst ist +nicht Teil der LXC-Dokumentation. | Dokument | Inhalt | | --- | --- | -| [GNAI-002](GNAI-002-INFRA_BaseSystem.md) | Hardware und Debian-Basisinstallation des KI-Servers | -| [GNAI-003](GNAI-003-INFRA_Users.md) | Hostbenutzer, Netzwerk, Resolver und SSH | +| [Ghostnet.AI-Host](ghostnet-ai/GNAI-002-INFRA_BaseSystem.md) | GNAI-002 Hardware und Debian-Basisinstallation des KI-Servers `10.0.0.90` | +| [Ghostnet.AI-Zugänge](ghostnet-ai/GNAI-003-INFRA_Users.md) | GNAI-003 Hostbenutzer, Netzwerk, Resolver und SSH des KI-Servers | | [GNAI-005](GNAI-005-SEC_Access-Control.md) | Rollen- und Zugriffsziel für die Infrastruktur | -| [GNAI-006](GNAI-006-SEC_Reverse-Proxy.md) | Reverse Proxy, Keycloak-Adminpfad und Fail2Ban | -| [GNAI-007](GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall | -| [VPN-Client-Verwaltung](GNAI-007-SEC_VPN_Client-Management.md) | Profile ausgeben, ändern und widerrufen | -| [Windows 11](GNAI-007-SEC_VPN_Clients_Windows11.md) | WireGuard-Client unter Windows 11 | -| [Linux](GNAI-007-SEC_VPN_Clients_Linux.md) | WireGuard-Client unter unterstützten Linux-Varianten | -| [VPN-Implementation-Log](GNAI-007-SEC_VPN_Implementation-Log.md) | historische Umsetzung, Tests und Evidenzkorrekturen | +| [Proxmox-LXCs](proxmox-lxc/README.md) | gemeinsamer Einstieg für CTs auf Proxmox `10.0.0.2` | +| [GNAI-011](proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md) | gemeinsame SSH-Sicherheitsarchitektur der LXCs | +| [CT 103 / GNAI-006](proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md) | Reverse Proxy, Keycloak-Adminpfad und Fail2Ban | +| [CT 105 / GNAI-007](proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway und Rollen-Firewall | Der übergreifende Projektstand steht im [zentralen Dokumentationsindex](../GNAI-000-DOC_Index.md). diff --git a/docs/platform/GNAI-002-INFRA_BaseSystem.md b/docs/platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md similarity index 97% rename from docs/platform/GNAI-002-INFRA_BaseSystem.md rename to docs/platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md index 3b632e6..e1b0c7a 100644 --- a/docs/platform/GNAI-002-INFRA_BaseSystem.md +++ b/docs/platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md @@ -1,7 +1,7 @@ -# Standard Operating Procedure +# Ghostnet.AI-Host – Basisinstallation **Dokumenten-ID:** GNAI-002-INFRA -**Titel:** Initialisierung und OS-Installation: LLM-Server (Phase 1) +**Titel:** Initialisierung und OS-Installation des KI-Hosts `10.0.0.90` **Status:** Installationsanleitung mit lesendem Teilabgleich; vollständige Abnahme offen **Referenzen:** - @@ -16,6 +16,7 @@ | 2026-09-16 | 1.2 | spektr | Benutzer- und Netzwerkaufgaben nach GNAI-003 verlagert; ungesicherte Downloadpfade und Domainvorgabe entfernt. | | 2026-09-18 | 1.3 | spektr | GPU-Abnahme auf nachweisbare Geräteerkennung begrenzt; Firmwarepaket präzisiert. | | 2026-09-19 | 1.4 | spektr | Getrennte SSH-Zugänge für `ghost` und `ghost-agent` als erfolgreich getestet übernommen. | +| 2026-09-22 | 1.5 | Codex | In die hostbezogene Struktur `platform/ghostnet-ai/` verschoben und Geltungsbereich präzisiert. | --- diff --git a/docs/platform/GNAI-003-INFRA_Users.md b/docs/platform/ghostnet-ai/GNAI-003-INFRA_Users.md similarity index 97% rename from docs/platform/GNAI-003-INFRA_Users.md rename to docs/platform/ghostnet-ai/GNAI-003-INFRA_Users.md index 9fcf4ec..ad375ae 100644 --- a/docs/platform/GNAI-003-INFRA_Users.md +++ b/docs/platform/ghostnet-ai/GNAI-003-INFRA_Users.md @@ -1,7 +1,7 @@ -# Standard Operating Procedure +# Ghostnet.AI-Host – Benutzer, Netzwerk und SSH **Dokumenten-ID:** GNAI-003-INFRA -**Titel:** Benutzerverwaltung, SSH-Härtung & Netzwerkkonfiguration (Phase 2) +**Titel:** Benutzer-, Netzwerk- und SSH-Sicherheitsarchitektur des KI-Hosts `10.0.0.90` **Status:** Betriebsanleitung; tatsächliche Netzverwaltung und Konten vor Anwendung prüfen --- @@ -17,6 +17,7 @@ | 2026-09-19 | 1.4 | spektr | Persönlichen Login `ghost` und Agentenlogin `ghost-agent` als erfolgreich getestet dokumentiert. | | 2026-09-20 | 1.5 | spektr / Codex | Deployment- und getrennte rootless Workload-Konten mit festen IDs und Zuständigkeiten ergänzt. | | 2026-09-20 | 1.6 | spektr / Codex | `render`-Mitgliedschaft und geprüfte AMD-Geräterechte der beiden KI-Konten ergänzt. | +| 2026-09-22 | 1.7 | Codex | In die hostbezogene Struktur `platform/ghostnet-ai/` verschoben und Geltungsbereich präzisiert. | --- diff --git a/docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md b/docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md new file mode 100644 index 0000000..d450af6 --- /dev/null +++ b/docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md @@ -0,0 +1,218 @@ +# Proxmox-LXCs – SSH-Sicherheitsarchitektur + +**Dokumenten-ID:** GNAI-011-SEC +**Titel:** Gemeinsame SSH-Sicherheitsarchitektur der LXCs auf Ghostnet Proxmox +**Status:** Legacy-Root-Bestand und Zielbild definiert; CT-103-Identitäten und SSH-Baseline umgesetzt, Netzwerk-/Rebootabnahme offen +**Geltungsbereich:** LXCs auf Proxmox `10.0.0.2`; nicht der Proxmox-Host selbst +**Referenzen:** [KI-Host-SSH](../ghostnet-ai/GNAI-003-INFRA_Users.md), [Zugriffskonzept](../GNAI-005-SEC_Access-Control.md), [CT 103](ct-103/GNAI-006-SEC_Reverse-Proxy.md), [CT 105](ct-105/GNAI-007-SEC_VPN.md) + +## Änderungsverlauf + +| Datum | Version | Autor | Änderung | +| --- | --- | --- | --- | +| 2026-09-22 | 0.1 | Codex | Geltungsbereich, Kontentrennung, SSH-Baseline und sicheren Rollout für Proxmox-LXCs definiert. | +| 2026-09-22 | 0.2 | Codex | Root-only-Bestand der Legacy-LXCs und CT 105 als bereits migrierte Ausnahme aufgenommen; CT-103-Bootstrap konkretisiert. | +| 2026-09-22 | 0.3 | Codex | CT-103-Agentenzugang und SSH-Baseline umgesetzt; systemd-Socket-Aktivierung und externe Negativtests dokumentiert. | +| 2026-09-22 | 0.4 | Codex | Persönliches Administrationskonto für CT 103 auf `ghost` festgelegt; bestehendes CT-105-Konto `admin` bleibt eine dokumentierte Ausnahme. | +| 2026-09-22 | 0.5 | Codex | CT-103-Allowlist auf `ghost-agent ghost` korrigiert; Dienstzustand und neue Agentenverbindung erfolgreich geprüft. | +| 2026-09-22 | 0.6 | Codex | Persönliches Konto `ghost`, passphrasegeschützten Schlüssel und passwortgeschütztes sudo auf CT 103 eingerichtet und praktisch abgenommen. | + +## 1. Zweck und Abgrenzung + +Dieses Dokument definiert die gemeinsame SSH-Sicherheitsarchitektur für die +LXCs, die auf Ghostnet Proxmox betrieben werden. Es übernimmt vom KI-Host das +Prinzip getrennter persönlicher, lesender und automatisierter Identitäten, +übernimmt aber weder dessen konkrete Konten noch dessen Schlüssel. + +Der Proxmox-Host `10.0.0.2` wird in diesem Verfahren nicht verändert. Seine +Konsole ist der Rückweg, falls eine SSH-Änderung in einem LXC fehlschlägt. +Proxmox-Hostzugang, PVE-Rollen und Cluster-SSH benötigen ein eigenes, späteres +Verfahren. + +## 2. Geltende Vertrauensgrenzen + +| System | Rolle | SSH-Einordnung | +| --- | --- | --- | +| CT 103 `10.0.0.10` | Reverse Proxy, NPM und Fail2Ban; öffentliches HTTP(S)-Ingress | `ghost` als persönlicher Administrator und `ghost-agent` als unprivilegiertes Lesekonto; Root- und Passwort-SSH deaktiviert; Proxmox-Konsole bleibt Recovery-Weg | +| CT 105 `10.0.0.15` | WireGuard-Gateway und wg-easy | verifizierte Ausnahme: `admin` UID 1000, Key-Login und sudo/`NOPASSWD`; vollständige Baseline noch abnehmen | +| weitere Legacy-LXCs | unterschiedliche Plattformdienste | laut Betreiber nur `root`; erst nach Inventaraufnahme einzeln migrieren, keine ungeprüfte Massenänderung | +| KI-Host `10.0.0.90` | physischer KI-Server | eigene Dokumentation unter `platform/ghostnet-ai/` | +| Proxmox `10.0.0.2` | Hypervisor und Recovery-Konsole | ausdrücklich außerhalb dieses Dokuments | + +Öffentliche Anwendungsports eines LXC begründen keine öffentliche +SSH-Freigabe. SSH ist ausschließlich Managementverkehr und wird auf der +Netzwerkebene auf vertrauenswürdiges LAN sowie berechtigte VPN-Rollen begrenzt. +Ein LLM-Admin-Peer erhält keinen SSH-Pfad zu CT 103 oder anderen Service-LXCs. + +## 3. Identitäten und Schlüssel + +### 3.1 Rollen pro LXC + +| Rolle | Zweck | Rechte | +| --- | --- | --- | +| persönlicher Administrator | interaktive Wartung und Notfallarbeit | eigener Public Key; `sudo` nur nach bestätigtem Bedarf | +| lesender Agent | Inventar, Status- und Logprüfung | eigener Public Key; keine sudo-Gruppe und kein schreibbarer Dienstzustand | +| Deployment-Automation | reproduzierbare, vorab definierte Änderungen | gesperrtes Passwort, eigener Key, quellenbeschränkt; sudo nur für benötigte Befehle | +| Dienstkonto | Ausführung eines Workloads | standardmäßig kein SSH-Login und gesperrtes Passwort | + +Nicht jeder LXC benötigt sofort alle Rollen. CT 103 beginnt mit einem +unprivilegierten Lesekonto für die sichere Bestandsaufnahme und einem +persönlichen Administrationskonto für spätere Änderungen. Root bleibt als +lokales Recovery-Konto erhalten, wird im Zielzustand aber nicht per SSH +verwendet. Automation wird nicht vorsorglich mit `NOPASSWD: ALL` ausgestattet. + +### 3.2 Ausgangszustand und Migrationsziel + +Der gemeldete Legacy-Standard der LXCs ist ein einzelnes `root`-Konto; dessen +Authentifizierungszustand muss pro LXC geprüft werden. CT 103 besaß im +Ausgangszustand weder ein Root-Passwort noch einen installierten Root-Schlüssel +und war nur über die Proxmox-Konsole administrierbar. Die Migration auf +`ghost` und `ghost-agent` ist inzwischen erfolgt. CT 105 ist bereits eine +Ausnahme und besitzt das Konto `admin` mit Schlüsselzugang. Dieser Zustand wird +nicht rückwirkend als allgemeine Freigabe für `NOPASSWD: ALL` interpretiert. + +Für jeden Legacy-LXC gilt: + +1. Die Proxmox-Konsole dient zum kontrollierten Bootstrap. Ein vorhandener + Root-SSH-Zugang wird weder vorausgesetzt noch vorübergehend aktiviert. +2. Ein gesperrtes, unprivilegiertes `ghost-agent`-Konto erhält einen eigenen + LXC-Schlüssel und keinerlei sudo-Rechte. +3. Ein persönliches Administrationskonto `ghost` erhält einen eigenen, + passphrasegeschützten Schlüssel und nur die bestätigten sudo-Rechte. +4. Erst nach positiven und negativen Tests werden Passwort- und Root-Login über + SSH deaktiviert. Das Root-Konto bleibt für die Proxmox-Konsole erhalten. + +### 3.3 Schlüsselregeln + +- eigener Ed25519-Schlüssel pro LXC und Rolle; keine Wiederverwendung des + CT-105- oder KI-Host-Schlüssels; +- persönlicher Schlüssel grundsätzlich passphrasegeschützt und bei Bedarf über + einen lokalen SSH-Agenten entsperrt; +- private Schlüssel nur auf der Admin-Workstation beziehungsweise in einem + freigegebenen Secret Store, niemals im Repository oder auf dem Ziel-LXC; +- `~/.ssh` auf dem LXC mit Modus `0700`, `authorized_keys` mit `0600` und dem + Eigentümer des Zielkontos; +- vorhandene Schlüssel beim Bootstrap erhalten, bis der neue Zugang und der + Recovery-Weg geprüft sind; +- Hostschlüssel-Fingerprint vor der ersten vertrauenswürdigen Verbindung über + die Proxmox-Konsole oder einen bereits verifizierten Kanal vergleichen. + +## 4. Gemeinsame SSH-Baseline + +Die Baseline wird als Drop-in unter `/etc/ssh/sshd_config.d/99-security.conf` +geführt. Vor Anwendung sind effektive Einstellungen und vorhandene Drop-ins zu +inventarisieren. `AllowUsers` wird nicht pauschal gesetzt, weil ein +unvollständiger Eintrag bestehende Betriebs- oder Recovery-Konten aussperren +kann. + +```text +PermitRootLogin no +PubkeyAuthentication yes +PasswordAuthentication no +KbdInteractiveAuthentication no +PermitEmptyPasswords no +AuthenticationMethods publickey + +X11Forwarding no +AllowAgentForwarding no +AllowTcpForwarding no +GatewayPorts no +PermitTunnel no + +MaxAuthTries 3 +LoginGraceTime 30 +``` + +Abweichungen benötigen einen dokumentierten Anwendungsfall. Insbesondere +Port-, Agent- oder X11-Forwarding wird nicht nur aus Bequemlichkeit aktiviert. +Änderungen werden mit `sshd -t` geprüft. Vor der Aktivierung ist zu prüfen, ob +`ssh.socket` aktiv ist. Auf CT 103 schlug `systemctl reload ssh.service` fehl, +weil der per Socket-Aktivierung gestartete Daemon beim SIGHUP Port 22 erneut +binden wollte. `ssh.socket` startete den Dienst beim nächsten Zugriff wieder +korrekt. Dort künftig nach erfolgreichem Syntaxcheck und bei offener +Proxmox-Konsole `systemctl restart ssh.service` verwenden, nicht Reload. Die +bestehende Sitzung bleibt offen, bis eine zweite Schlüsselverbindung +erfolgreich war. + +## 5. Netzwerk- und Berechtigungsgrenze + +- Der lokale LXC-Paketfilter erlaubt TCP 22 nur aus bestätigten + Managementquellen. +- Familie und Server Admin dürfen den SSH-Netzpfad nur gemäß GNAI-005 nutzen; + die Anmeldung benötigt zusätzlich einen individuellen SSH-Schlüssel. +- LLM Admin und öffentliche Netze bleiben gesperrt. +- Solange WireGuard-Verkehr vor dem LAN-Ausgang maskiert wird, sieht ein LXC + typischerweise `10.0.0.15` als Quelle. Die Rollentrennung muss deshalb bereits + am WireGuard-Gateway vor NAT wirksam sein. +- Passwortsperre und Paketfilter sind unabhängige Kontrollen; eine ersetzt die + andere nicht. + +## 6. Sicheres Rolloutverfahren pro LXC + +1. Proxmox-Konsole als getesteten Rückweg öffnen und aktuellen Zustand sichern. +2. Über den vorhandenen Root-Zugang ein gesperrtes, unprivilegiertes Lesekonto + mit dediziertem Public Key anlegen; Root-Zugang noch nicht verändern. +3. Mit dem Lesekonto Konten, Gruppen, sudo-Regeln, `sshd -T`, Drop-ins, + Listener, Paketfilter und vorhandene `authorized_keys` inventarisieren. +4. Persönliches Administrationskonto und dessen dedizierten Public Key + aufnehmen; Login, Identität und beabsichtigte sudo-Rechte in einer zweiten + Sitzung prüfen. +5. SSH-Drop-in zunächst ohne Abschalten des letzten funktionierenden + Authentifizierungswegs vorbereiten, mit `sshd -t` prüfen und neu laden. +6. Schlüssel-Login erneut prüfen. Erst danach Passwort- und + Keyboard-Interactive-Anmeldung deaktivieren. +7. Positive und negative Tests durchführen: richtiger Key erfolgreich; + Passwort, Root und falscher Key abgelehnt; verbotene VPN-Rolle ohne + Netzpfad. +8. Neustart sowie Zugriff über LAN und vorgesehenes VPN testen und die Evidenz + im zuständigen CT-Dokument protokollieren. + +## 7. CT-103-Rollout + +CT 103 ist der erste Ziel-LXC. Der Ausgangszustand und die effektive +SSH-Konfiguration wurden inzwischen über die Proxmox-Konsole und externe +Positiv- sowie Negativtests bestätigt. + +Reihenfolge: + +1. Root-Kontostatus, effektive SSH-Regeln und ED25519-Hostschlüssel über die + Proxmox-Konsole bestätigen; +2. dedizierten CT-103-Agentenschlüssel anlegen und `ghost-agent` ohne Passwort, + Gruppen- oder sudo-Rechte über die Root-Sitzung bootstrappen; +3. CT 103 über `ghost-agent` vollständig lesend inventarisieren; +4. dedizierten, passphrasegeschützten CT-103-Schlüssel erzeugen, `ghost` + einrichten und dessen sudo-Verfahren praktisch prüfen; +5. aktuellen Proxmox-Rückfallstand herstellen, SSH-Baseline anwenden und + Negativtests durchführen; +6. erst danach Keycloak-Adminpfad, Fail2Ban und weitere Härtung bearbeiten. + +### 7.1 Umsetzungsstand am 22.09.2026 + +| Schritt | Stand | +| --- | --- | +| Legacy-Konto | Konsole bestätigt ausschließlich `root`; `passwd -S root` meldet `NP`, also kein gesetztes Root-Passwort. `/root/.ssh` ist Modus `0700`, enthält aber keine Schlüsseldatei. | +| Effektive SSH-Regeln | `PermitRootLogin without-password`, `PasswordAuthentication yes`, `KbdInteractiveAuthentication no`, `PubkeyAuthentication yes`, `AuthenticationMethods any`. Root kann mangels Passwort und Schlüssel derzeit nicht remote anmelden; Passwort-SSH ist für spätere Nicht-Root-Konten aber noch global erlaubt. | +| Externer SSH-Handshake | TCP/22 erreichbar; OpenSSH `10.0p2 Debian-7+deb13u4` bietet `publickey,password` an. | +| CT-103-Hostschlüssel | ED25519-Fingerprint `SHA256:XtPIUVMsVhvL7kFzsC/cZfo6I9vXCNGdROtoxzeNkdg` wurde über die Proxmox-Konsole unabhängig bestätigt. | +| Leseschlüssel | dedizierter lokaler Ed25519-Schlüssel für `ghost-agent` erzeugt; Public-Key-Fingerprint `SHA256:+ZDrKCioDtIkw10XWbfvCAoPP25znfFGzYXtq8rxzME`. Private-Key-Material bleibt außerhalb des Repositorys. | +| Serverinstallation | `ghost-agent` als UID/GID 1000 mit gesperrtem Passwort, eigener Primärgruppe, ohne Zusatzgruppen und ohne sudo eingerichtet. `.ssh` ist `0700`, `authorized_keys` `0600`. | +| Zugangstest | Direkter Schlüsseltest und lokaler Alias `ghostnet-ct103-agent` melden erfolgreich `ghost-agent@reverse-proxy`; strikte Hostschlüsselprüfung und `IdentitiesOnly yes` aktiv. | +| SSH-Baseline | Drop-in `99-security.conf` setzt Root-/Passwort-/Keyboard-Interactive-Login aus, verlangt Public Key, erlaubt ausschließlich `ghost-agent` und `ghost` und deaktiviert X11-, Agent-, TCP-Forwarding sowie Tunnel. Syntaxprüfung bestand. | +| Aktivierung | Reload schlug wegen aktiver `ssh.socket`-Socket-Aktivierung mit `Cannot bind any address` fehl. Der Socket startete `ssh.service` anschließend erfolgreich neu; Dienst und Listener sind aktiv. Künftig Restart statt Reload verwenden. | +| Effektive Abnahme | Konsolenprüfung bestätigt `PermitRootLogin no`, `PasswordAuthentication no`, Public-Key-Pflicht, `AllowUsers ghost-agent ghost`, `MaxAuthTries 3`, `LoginGraceTime 30`, `LogLevel VERBOSE` sowie deaktivierte X11-, Agent-, TCP-Forwarding- und Tunnelfunktionen. `ssh.service` und `ssh.socket` sind aktiv; eine anschließend neu aufgebaute Verbindung als `ghost-agent` war erfolgreich. | +| Negativtests | Neue Agentensitzung erfolgreich; Passwortversuch für `ghost-agent` und Root-Versuch mit dem Agentenschlüssel jeweils mit `Permission denied (publickey)` abgelehnt. | +| Schlüsseldatei | Der beim Konsolen-Paste getrennte Kommentar wurde auf eine gültige `authorized_keys`-Zeile korrigiert; Fingerprint und neuer Login erneut erfolgreich geprüft. | +| Persönlicher Zugang | `ghost` als UID/GID 1001 mit den Gruppen `sudo` und `users` eingerichtet. Der dedizierte, passphrasegeschützte Ed25519-Schlüssel hat den Fingerprint `SHA256:tIV8GMBzFcMSzaQhmkAw7wSvKDf82RHVoTKVJk7bAgA`; `.ssh` ist `0700`, `authorized_keys` `0600`. Interaktiver Login und passwortgeschütztes `sudo` bis `uid=0(root)` wurden erfolgreich geprüft. Es gilt kein `NOPASSWD`. | + +## 8. Abnahmekriterien + +- [x] Proxmox-Konsole ist als Recovery-Weg geprüft. +- [x] Bestehende Konten und SSH-Ausgangskonfiguration sind dokumentiert. +- [x] Dedizierter Leseschlüssel und strikte Hostschlüsselprüfung funktionieren. +- [x] Persönlicher Schlüsselzugang und passwortgeschütztes sudo funktionieren. +- [x] Root- und Passwort-Login werden extern abgelehnt; Keyboard-Interactive ist in der Baseline deaktiviert. +- [x] X11-, Agent-, TCP-Forwarding und Tunnel sind aus. +- [ ] SSH ist nur aus zugelassenen LAN-/VPN-Pfaden erreichbar. +- [x] SSH-Dienst wurde nach dem Socket-Aktivierungsereignis erfolgreich neu gestartet und erneut verbunden. +- [ ] LXC-Neustart und Wiederanlauf wurden erfolgreich geprüft. +- [ ] Private Schlüssel, Passwörter und vollständige `authorized_keys` fehlen in Git und Laufprotokollen. diff --git a/docs/platform/proxmox-lxc/README.md b/docs/platform/proxmox-lxc/README.md new file mode 100644 index 0000000..bf51688 --- /dev/null +++ b/docs/platform/proxmox-lxc/README.md @@ -0,0 +1,11 @@ +# Proxmox-LXCs + +Dieser Bereich dokumentiert ausschließlich die auf Ghostnet Proxmox +`10.0.0.2` betriebenen LXCs. Er beschreibt nicht die SSH-Konfiguration des +Hypervisors selbst. + +| Dokument / Bereich | Inhalt | +| --- | --- | +| [GNAI-011](GNAI-011-SEC_LXC-SSH-Architecture.md) | gemeinsame SSH-Sicherheitsarchitektur und Rolloutverfahren der LXCs | +| [CT 103](ct-103/GNAI-006-SEC_Reverse-Proxy.md) | Reverse Proxy, Keycloak-Adminpfad und Fail2Ban | +| [CT 105](ct-105/GNAI-007-SEC_VPN.md) | WireGuard-Gateway, Rollen-Firewall und Clientverfahren | diff --git a/docs/platform/GNAI-006-SEC_Reverse-Proxy.md b/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md similarity index 69% rename from docs/platform/GNAI-006-SEC_Reverse-Proxy.md rename to docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md index 5559175..aa40ced 100644 --- a/docs/platform/GNAI-006-SEC_Reverse-Proxy.md +++ b/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md @@ -1,9 +1,10 @@ -# Betriebs- und Sicherheitsdokumentation – Reverse Proxy +# CT 103 – Reverse Proxy und Sicherheitsbetrieb **Dokumenten-ID:** GNAI-006-SEC **Titel:** Reverse Proxy und Fail2Ban – Konfiguration, Betrieb und Sicherheitsabnahme -**Status:** NPM aktiv; Fail2Ban laut Betreiber fest gepinnt und wieder in Betrieb; Keycloak-Admin-Exposure bestätigt, Korrektur offen -**Vorgänger / Referenzen:** [Architektur](../ai/GNAI-004-INFRA_Architecture.md), [Zugriffskonzept](GNAI-005-SEC_Access-Control.md), [WireGuard](GNAI-007-SEC_VPN.md) +**Status:** NPM 2.15.1 und Fail2Ban aktiv; lesender SSH-Zugang und lokale Dateirechte gehärtet; Keycloak-Admin-Exposure offen + +**Vorgänger / Referenzen:** [Architektur](../../../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [WireGuard](../ct-105/GNAI-007-SEC_VPN.md) --- @@ -18,12 +19,20 @@ | 2026-09-15 | 1.2 | spektr | Version/Tabellen korrigiert; bestätigte Keycloak-Exposure und TLS-Widerspruch dokumentiert; Korrekturverfahren, Fail2Ban-Upgrade/Pin und bewusste HTTP-Client-Sperren ergänzt. | | 2026-09-16 | 1.3 | spektr | Fail2Ban-Image auf `1.1.0-r2-ls43` fest gepinnt; wieder laufenden Container bestätigt; verbleibende Funktions- und Wiederanlauftests getrennt ausgewiesen. | | 2026-09-18 | 1.4 | spektr | Wirkung der LAN-Freigaben auf VPN-Verkehr hinter MASQUERADE unmittelbar an der Port-Matrix erläutert. Zweck als Betriebs- und Sicherheitsdokumentation geklärt; veraltete Image-Digests aus dem Verfahren entfernt. | +| 2026-09-22 | 1.5 | Codex | Öffentliche Keycloak-/TLS-Pfade und Vaultwarden-Webkonfiguration erneut geprüft; fehlenden administrativen Zugriff auf CT 103 als Umsetzungsblocker dokumentiert. | +| 2026-09-22 | 1.6 | Codex | In die CT-bezogene Dokumentationsstruktur verschoben und CT 103 als ersten Rollout der gemeinsamen LXC-SSH-Architektur aufgenommen. | +| 2026-09-22 | 1.7 | Codex | `ghost-agent` eingerichtet, Schlüsselzugang und Live-Bestand geprüft; NPM 2.15.1 sowie unsichere Rechte auf Datenbank, Schlüsseldatei und Logs dokumentiert. | +| 2026-09-22 | 1.8 | Codex | NPM-Daten und Logs lokal gehärtet; Containerzugriff, Negativzugriff des Agenten und öffentliche Dienste erfolgreich regressionsgeprüft. | +| 2026-09-22 | 1.9 | Codex | SSH-Baseline angewendet, Socket-Aktivierungsbesonderheit erfasst und Root-/Passwort-Negativtests bestanden. | +| 2026-09-22 | 2.0 | Codex | Persönlichen CT-103-Zugang auf `ghost` statt des geteilten Rollenbegriffs `admin` festgelegt; Allowlist-Korrektur als offen ausgewiesen. | +| 2026-09-22 | 2.1 | Codex | Allowlist auf `ghost-agent ghost` korrigiert; SSH-Dienste und neue Agentenverbindung erfolgreich geprüft. | +| 2026-09-22 | 2.2 | Codex | Persönliches Konto `ghost`, dedizierten Schlüssel und passwortgeschütztes sudo eingerichtet und erfolgreich geprüft. | --- ## 1. Zweck & Geltungsbereich -Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentralen Reverse Proxy und des logbasierten Fail2Ban auf Proxmox LXC 103 (`reverse-proxy`) fest. Angaben zum laufenden Zustand beruhen auf den jeweils datierten Betreiberbestätigungen und Tests; eine neue Live-Prüfung von CT 103 fand bei dieser Revision nicht statt. +Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentralen Reverse Proxy und des logbasierten Fail2Ban auf Proxmox LXC 103 (`reverse-proxy`) fest. Angaben zum laufenden Zustand beruhen auf den jeweils datierten Betreiberbestätigungen und Tests. Am 22.09.2026 wurden die öffentlichen Endpunkte und der über `ghost-agent` lesbare Live-Zustand geprüft. Für privilegierte Wartung steht inzwischen das persönliche, passwortgeschützte sudo-Konto `ghost` bereit; die Proxmox-Konsole bleibt der Recovery-Weg. **Umfang dieses Dokuments:** @@ -50,6 +59,71 @@ Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentrale *Hinweis zur Proxmox-Firewall:* Laut bisheriger Implementierungsdokumentation sind Proxmox Cluster- und Node-Firewalls deaktiviert (`enable 0`); bei Änderungen den tatsächlichen Zustand prüfen. Die dokumentierte Filter-Baseline liegt lokal im LXC unter `nftables`. Effektive Regeln und weitere Netfilter-Tabellen vor Änderungen live prüfen. +### 2.1 SSH-Migrationsstand + +Im Ausgangszustand besaß CT 103 ausschließlich das Legacy-Konto `root`. +Die Konsolenprüfung am 22.09.2026 zeigte für Root den Passwortstatus `NP`, +keinen installierten Root-Schlüssel und `PermitRootLogin without-password`. +Root kann damit derzeit nicht remote anmelden; die Proxmox-Konsole ist der +administrative Zugang. Ein externer Handshake bestätigte TCP/22, OpenSSH `10.0p2 +Debian-7+deb13u4`, den bekannten ED25519-Hostschlüssel und die global +angebotenen Methoden `publickey,password`. Effektiv gelten außerdem +`PasswordAuthentication yes`, `KbdInteractiveAuthentication no` und +`PubkeyAuthentication yes`. Passwörter werden weder in +diesem Repository noch in automatisierten Laufprotokollen verarbeitet. + +CT 103 ist der erste Rollout der gemeinsamen +[LXC-SSH-Architektur](../GNAI-011-SEC_LXC-SSH-Architecture.md). `ghost-agent` +ist mit eigenem Schlüssel, ohne Passwort, Zusatzgruppen oder sudo eingerichtet. +Das Drop-in `99-security.conf` deaktiviert Root-, Passwort- und +Keyboard-Interactive-Login, verlangt Public Key, erlaubt nur `ghost-agent` und +`ghost` und deaktiviert X11-, Agent-, TCP-Forwarding sowie Tunnel. Nach der +Allowlist-Korrektur blieben beide SSH-Units aktiv und eine neue Verbindung als +`ghost-agent` war erfolgreich. +Neue Agentenanmeldung, Root-Ablehnung und Passwort-Ablehnung wurden extern +geprüft. Die effektive Konsolenabfrage bestätigte außerdem sämtliche +Forwarding-Sperren, `MaxAuthTries 3`, `LoginGraceTime 30` und `LogLevel VERBOSE`. +Der beim Konsolen-Paste getrennte Schlüsselkommentar wurde anschließend zu +einer gültigen `authorized_keys`-Zeile korrigiert und erneut getestet. + +CT 103 verwendet `ssh.socket`. Ein `systemctl reload ssh.service` schlug trotz +gültiger Syntax fehl, weil der Daemon Port 22 beim SIGHUP erneut binden wollte. +Der aktive Socket startete `ssh.service` beim nächsten Zugriff wieder korrekt. +Nach künftigen Änderungen bei offener Proxmox-Konsole `sshd -t` und danach +`systemctl restart ssh.service` verwenden, nicht Reload. Das persönliche Konto +`ghost` verwendet einen eigenen passphrasegeschützten Schlüssel und +passwortgeschütztes sudo; Login und Rechteerhöhung bis Root wurden praktisch +geprüft. Der Proxmox-Hypervisor selbst wurde nicht verändert. + +### 2.2 Lesender Live-Abgleich am 22.09.2026 + +Der neu eingerichtete Benutzer `ghost-agent` meldet sich mit einem eigenen +Ed25519-Schlüssel als UID/GID 1000 an, besitzt keine Zusatzgruppen und keine +sudo-Rechte. Der lokale SSH-Alias `ghostnet-ct103-agent` verwendet strikte +Hostschlüsselprüfung und ausschließlich diesen Schlüssel. + +| Bereich | Beobachtung | +| --- | --- | +| System | Debian 13, PVE-Kernel `7.0.14-14-pve`, Podman 5.4.2, nftables 1.1.3 und OpenSSH `10.0p1-7+deb13u4`. | +| Dienste | SSH, nftables, `nginx-proxy-manager` und `fail2ban` aktiv; keine fehlgeschlagenen systemd-Units. NPM läuft seit 02.09., Fail2Ban seit 16.09.; jeweils `NRestarts=0`. | +| Updates | `unattended-upgrades` aktiv und aktiviert; apt-daily- und apt-daily-upgrade-Timer vorhanden. | +| Containerdefinition | NPM ist im Quadlet auf `2.15.1`, Fail2Ban auf `1.1.0-r2-ls43` gepinnt. Beide laufen rootful mit Hostnetz; Fail2Ban besitzt `NET_ADMIN` und `NET_RAW`. | +| Listener | TCP 80, 81 und 443 auf IPv4, TCP 22 und NPM-Backend 3000 auf IPv4/IPv6 beziehungsweise allen Adressen. Auf `eth0` existiert nur IPv4 plus link-lokales IPv6. Listener beweisen keine Erreichbarkeit durch die Firewall. | +| Firewall-Datei | `/etc/nftables.conf` enthält INPUT `drop`, erlaubt 22/81 aus `10.0.0.0/24`, 80/443 allgemein und lässt Port 3000 durch die Default-Policy fallen. Der effektive Kernel-Regelsatz benötigt Root und ist noch nicht live bestätigt. | +| SSH | `ghost-agent` und persönliches Konto `ghost` mit getrennten Schlüsseln aktiv; Drop-in mit `AllowUsers ghost-agent ghost`. Root-/Passwortversuche extern abgelehnt, persönlicher Login und passwortgeschütztes sudo erfolgreich. `ssh.socket` und `ssh.service` aktiv. | +| Speicher | Root-Dateisystem 51 % belegt. | + +**Lokaler Berechtigungsbefund und Korrektur:** NPM lief im LXC als Root, aber +`database.sqlite` und `keys.json` waren `0644` in einem durchsuchbaren +`0755`-Datenverzeichnis. Das Logverzeichnis war `0777`; zahlreiche rotierte +Logs waren `0666` oder `0777`. Die Inventur hat Inhalte dieser Dateien nicht +geöffnet. Am 22.09.2026 wurden Datenbank und Schlüsseldatei auf `0600`, Daten- +und Logverzeichnis auf `0750` sowie reguläre Logdateien auf `0640` reduziert. +NPM behielt Lese-/Schreibzugriff und Fail2Ban Lese-/Traverse-Zugriff. Danach +waren beide Dienste aktiv, Vaultwarden und der öffentliche Keycloak-Realm +lieferten HTTP 200, während `ghost-agent` weder Datenbank, Schlüsseldatei noch +Logs lesen oder schreiben konnte. + --- ## 3. Netzwerk- & Firewall-Architektur (nftables) @@ -99,7 +173,7 @@ Nginx Proxy Manager und Fail2Ban werden als rootful Podman-Container via systemd ### 4.1 Nginx Proxy Manager Quadlet * **Datei:** `/etc/containers/systemd/nginx-proxy-manager.container` -* **Image:** `docker.io/jc21/nginx-proxy-manager:2.11.1` *(ausdrücklich gepinnt)* +* **Image, live bestätigt am 22.09.2026:** `docker.io/jc21/nginx-proxy-manager:2.15.1` *(ausdrücklich gepinnt)* ```ini [Unit] @@ -108,7 +182,7 @@ Wants=network-online.target After=network-online.target [Container] -Image=docker.io/jc21/nginx-proxy-manager:2.11.1 +Image=docker.io/jc21/nginx-proxy-manager:2.15.1 ContainerName=nginx-proxy-manager Network=host Volume=/opt/nginx-proxy-manager/data:/data:rw @@ -308,7 +382,7 @@ podman exec fail2ban fail2ban-client set npm-scanner unbanip "$BAN_IP" ## 9. Sicherheits- & Betriebsregeln für Administrierende 1. **Kein generisches Statuscode-Banning:** Generische HTTP `4xx`- oder `5xx`-Fehler dürfen nicht als pauschales Ban-Kriterium verwendet werden. -2. **Geprüfte Upgrades:** NPM ist im Quellenstand auf `2.11.1` festgeschrieben. Fail2Ban ist auf `1.1.0-r2-ls43` festgeschrieben. Beide Pins regelmäßig auf Updates prüfen; Änderungen mit Backup, Tests und Rückfallplan durchführen. +2. **Geprüfte Upgrades:** NPM ist live auf `2.15.1`, Fail2Ban auf `1.1.0-r2-ls43` festgeschrieben. Beide Pins regelmäßig auf Updates prüfen; Änderungen mit Backup, Tests und Rückfallplan durchführen. 3. **Privilegien-Minimierung:** Der Fail2Ban-Container wird strikt ohne `--privileged` betrieben (`NET_ADMIN` und `NET_RAW` reichen aus). 4. **Whitelist-Pflicht:** Das Subnetz `10.0.0.0/24` sowie `127.0.0.1/8` müssen in allen Jails in `ignoreip` hinterlegt bleiben, um Aussperrungen zu verhindern. 5. **Syntax-Check vor Reload:** Jede Änderung an Fail2Ban-Konfigurationen ist vorab mit `podman exec fail2ban fail2ban-client -t` auf Gültigkeit zu prüfen. @@ -348,6 +422,26 @@ proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; ``` +Der erneute externe Abgleich am 22.09.2026 ergab: + +| Prüfung | Beobachtung | +| --- | --- | +| DNS | `auth.ghostnet.selfhost.eu` besitzt einen A-Record; kein AAAA-Record wurde geliefert. | +| HTTPS `/admin` | Redirect zur Admin-Konsole; `/admin/master/console/` lieferte anschließend HTTP 200. Die Administration ist weiterhin öffentlich erreichbar. | +| HTTP `/admin` | Redirect blieb auf HTTP. Eine erzwungene HTTP→HTTPS-Weiterleitung ist damit nicht belegt. | +| TLS | Gültiges Let's-Encrypt-Zertifikat für `auth.ghostnet.selfhost.eu`, Laufzeit 11.09.–10.12.2026. | +| Managementpfade | `/health` und `/metrics` lieferten HTTP 404; eine Veröffentlichung dieser Pfade wurde nicht festgestellt. | +| Master-Realm | `/realms/master/account/` antwortete mit einem Redirect. Der Master-Realm ist über den öffentlichen Host erreichbar. | +| Vaultwarden-Webkonfiguration | `/api/config` liefert `environment.sso` als leeren String. Das widerspricht der bisherigen Betreiberangabe eines produktiven OIDC-Logins, beweist allein aber nicht, dass serverseitig kein OIDC-Client existiert. | + +Die Sperre von `/admin` kann unabhängig vom Anwendungsrealm erfolgen. Eine +zusätzliche Sperre von `/realms/master/` bleibt bis zur Identifikation des +tatsächlichen Vaultwarden-Issuers zurückgestellt. Vor der Änderung fehlt noch +ein aktuelles Backup. Der bei der ersten Prüfung fehlende administrative Weg +zu CT 103 wurde später durch die getrennten Konten `ghost` und `ghost-agent` +hergestellt; Root besitzt weiterhin weder Passwort noch installierten +SSH-Schlüssel. + **TLS-Widerspruch:** Externer HTTPS-Login funktionierte, obwohl für diesen Proxy Host SSL als ausgeschaltet angegeben ist. Effektiven Listener, Zertifikat und vHost-Zuordnung prüfen, bevor eine vollständige HTTPS-Bereitstellung behauptet wird. Auf CT 103 etwa: ```bash @@ -420,3 +514,4 @@ LLM Admins dürfen nur `.90` erreichen und haben keinen allgemeinen NPM-/LXC-Zug | Keycloak Admin extern nutzbar | externe Sperre von GUI und API über tatsächliche HTTP/HTTPS-/IPv6-Pfade, interner Adminzugang und Vaultwarden-OIDC weiter funktionsfähig | | TLS-Zuordnung des auth-Hosts unklar | effektiver Listener, Zertifikat, Redirects und Backend-Pfad dokumentiert | | Fail2Ban auf `1.1.0-r2-ls43` gepinnt und Container wieder laufend | effektives Image und Version dokumentiert; Jail-/Filter-/Ban-/Dienstneustart-/Reboottests bestanden | +| NPM-Daten und Logs lokal weltlesbar beziehungsweise weltbeschreibbar | am 22.09.2026 korrigiert und positiv/negativ regressionsgeprüft; künftige Dateierzeugung und Logrotation weiter beobachten | diff --git a/docs/platform/GNAI-007-SEC_VPN.md b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md similarity index 94% rename from docs/platform/GNAI-007-SEC_VPN.md rename to docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md index 7bc3b1d..41b07de 100644 --- a/docs/platform/GNAI-007-SEC_VPN.md +++ b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md @@ -1,8 +1,9 @@ -# Technische Architekturbeschreibung – WireGuard-Gateway +# CT 105 – WireGuard-Gateway **Dokumenten-ID:** GNAI-007-SEC -**Status:** Dokumentation bereinigt; technische Umsetzung und Abnahme teilweise offen -**Referenzen:** [Zielarchitektur](../ai/GNAI-004-INFRA_Architecture.md), [Zugriffskonzept](GNAI-005-SEC_Access-Control.md), [GUI-SOP](GNAI-007-SEC_VPN_Client-Management.md), [Implementation-Log](GNAI-007-SEC_VPN_Implementation-Log.md) +**Status:** Live-Stand am 22.09.2026 verifiziert; Schlüsseldateien gehärtet; Rollen-Firewall und Abnahme offen + +**Referenzen:** [Zielarchitektur](../../../ai/GNAI-004-INFRA_Architecture.md), [LXC-SSH](../GNAI-011-SEC_LXC-SSH-Architecture.md), [Zugriffskonzept](../../GNAI-005-SEC_Access-Control.md), [GUI-SOP](GNAI-007-SEC_VPN_Client-Management.md), [Implementation-Log](GNAI-007-SEC_VPN_Implementation-Log.md) ## Änderungsverlauf @@ -12,14 +13,15 @@ | 2026-09-09 | 1.0–1.5 | spektr | Aufbau und Migration von v14 auf v15; historische Details im Implementation-Log | | 2026-09-15 | 2.0 | spektr | Rollen Familie/Server Admin/LLM Admin; bestätigtes LXC und Hooks; NAT-Abhängigkeit; v15-Bereinigung; getrennte SOPs und belastbarer Abnahmestatus | | 2026-09-18 | 2.1 | spektr | Lesenden Gateway-Abgleich, iptables-legacy-Befund und DNS-Abgleich ergänzt; Betriebshinweise entsprechend korrigiert. | +| 2026-09-22 | 2.2 | Codex | Gateway, Container, Regelwerke, Peers, Listener und SSH-Baseline erneut live geprüft; Schlüsseldateien auf Modus 0600 gehärtet. | ## 1. Zweck und dokumentierter Stand Das Gateway ermöglicht administrativen und familiären Fernzugriff auf das Heimnetz. WireGuard authentifiziert Geräte durch Schlüssel; die Zielsysteme verlangen weiterhin ihre eigene Anmeldung. Ein Peer wird pro Gerät vergeben. Eine gemeinsame Konfiguration für mehrere gleichzeitig verwendete Geräte ist nicht vorgesehen. -Das WireGuard-Gateway läuft bereits. Die nachfolgende Installation beschreibt seinen reproduzierbaren Aufbau; neue Sicherheitsmaßnahmen sind als **Soll** gekennzeichnet. Grundlage sind die Quellen, die Tests vom 12.09.2026, die vom Betreiber bereitgestellte Konfiguration und der lesende Gateway-Abgleich vom 18.09.2026. Es wurden keine Systemkonfigurationen geändert und keine neuen Client- oder Rollentests durchgeführt. +Das WireGuard-Gateway läuft bereits. Die nachfolgende Installation beschreibt seinen reproduzierbaren Aufbau; neue Sicherheitsmaßnahmen sind als **Soll** gekennzeichnet. Grundlage sind die Quellen, die Tests vom 12.09.2026, die vom Betreiber bereitgestellte Konfiguration und die lesenden Gateway-Abgleiche vom 18. und 22.09.2026. Am 22.09.2026 wurden ausschließlich die Dateirechte von `wg-easy.db` und dem historischen `wg0.json` auf `0600` reduziert; Client- und Rollentests wurden nicht durchgeführt. -**Wesentliche offene Umsetzung:** Per-Client Firewall ist deaktiviert. Die bisherige breite Forward-Regel erzwingt keine Rollenisolierung. HTTPS für die wg-easy-GUI ist noch nicht eingerichtet. Der dokumentierte Endpoint `vpn.ghostnet.selfhost.eu` stimmte am 18.09.2026 mit der ausgehenden IPv4 des Gateways überein; die DynDNS-Aktualisierung nach einem Adresswechsel ist noch nicht nachgewiesen. +**Wesentliche offene Umsetzung:** Per-Client Firewall ist deaktiviert. Die bisherige breite Forward-Regel erzwingt keine Rollenisolierung. HTTPS für die wg-easy-GUI ist noch nicht eingerichtet. Der dokumentierte Endpoint `vpn.ghostnet.selfhost.eu` stimmte am 18.09.2026 mit der ausgehenden IPv4 des Gateways überein; die DynDNS-Aktualisierung nach einem Adresswechsel ist noch nicht nachgewiesen. Der aktuelle Live-Abgleich steht im Implementation-Log. ## 2. Architektur und Adressplan @@ -113,7 +115,7 @@ sudo install -m 600 /dev/null /opt/wg-easy/environment Der letzte Befehl ist ausschließlich für eine **Neuinstallation**: ein vorhandenes Environment-File nicht überschreiben. Dokumentiert ist Podman 5.4.2. Die durch Debian bereitgestellte Version mit `podman --version` festhalten und Quadlet-Unterstützung prüfen. -Den Benutzer `admin` nur anlegen, wenn er noch nicht existiert. SSH-Key hinterlegen und Rechte testen. Für die SSH-Härtung die allgemeinen Prüfschritte aus [GNAI-003](GNAI-003-INFRA_Users.md) auf diesen LXC übertragen; dessen KI-Server-Konten und Netzwerte nicht übernehmen. Im bestehenden WireGuard-LXC ist `admin ALL=(ALL) NOPASSWD: ALL` eingerichtet; das ist der bestätigte Ist-Stand und keine allgemeine Vorgabe für alle LLM-Benutzer. Änderungen an SSH immer mit einer offenen zweiten Sitzung oder Proxmox-Konsole absichern. +Den Benutzer `admin` nur anlegen, wenn er noch nicht existiert. SSH-Key hinterlegen und Rechte testen. Für die SSH-Härtung gilt die gemeinsame [LXC-SSH-Architektur](../GNAI-011-SEC_LXC-SSH-Architecture.md); KI-Host-Konten und Netzwerte werden nicht übernommen. Im bestehenden WireGuard-LXC ist `admin ALL=(ALL) NOPASSWD: ALL` eingerichtet; das ist der bestätigte Ist-Stand und keine allgemeine Vorgabe für andere LXCs. Änderungen an SSH immer mit einer offenen zweiten Sitzung oder Proxmox-Konsole absichern. ### 3.3 IP-Forwarding diff --git a/docs/platform/GNAI-007-SEC_VPN_Client-Management.md b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md similarity index 98% rename from docs/platform/GNAI-007-SEC_VPN_Client-Management.md rename to docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md index 1c3363a..35e6e90 100644 --- a/docs/platform/GNAI-007-SEC_VPN_Client-Management.md +++ b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md @@ -1,9 +1,9 @@ -# Standard Operating Procedure +# CT 105 – WireGuard-Clientverwaltung **Dokumenten-ID:** GNAI-007-SEC-SOP-01 **Titel:** Clients in der wg-easy-GUI einrichten und verwalten **Status:** Betriebsverfahren dokumentiert; Rollen-Firewall noch nicht umgesetzt oder abgenommen -**Referenzen:** [Gateway-Architektur](GNAI-007-SEC_VPN.md), [Rollenmodell](GNAI-005-SEC_Access-Control.md), [Windows](GNAI-007-SEC_VPN_Clients_Windows11.md), [Linux](GNAI-007-SEC_VPN_Clients_Linux.md) +**Referenzen:** [Gateway-Architektur](GNAI-007-SEC_VPN.md), [Rollenmodell](../../GNAI-005-SEC_Access-Control.md), [Windows](GNAI-007-SEC_VPN_Clients_Windows11.md), [Linux](GNAI-007-SEC_VPN_Clients_Linux.md) ## Änderungsverlauf diff --git a/docs/platform/GNAI-007-SEC_VPN_Clients_Linux.md b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md similarity index 99% rename from docs/platform/GNAI-007-SEC_VPN_Clients_Linux.md rename to docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md index 332c8a8..c8c5e99 100644 --- a/docs/platform/GNAI-007-SEC_VPN_Clients_Linux.md +++ b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md @@ -1,4 +1,4 @@ -# SOP – WireGuard unter Linux einrichten und verwenden +# CT 105 – WireGuard unter Linux einrichten und verwenden **Dokumenten-ID:** GNAI-007-SEC-SOP-03 **Plattformen:** Debian, Arch/CachyOS und Fedora; Fedora Kinoite gesondert berücksichtigt diff --git a/docs/platform/GNAI-007-SEC_VPN_Clients_Windows11.md b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md similarity index 99% rename from docs/platform/GNAI-007-SEC_VPN_Clients_Windows11.md rename to docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md index c8bc679..7577b21 100644 --- a/docs/platform/GNAI-007-SEC_VPN_Clients_Windows11.md +++ b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md @@ -1,4 +1,4 @@ -# SOP – WireGuard unter Windows 11 einrichten und verwenden +# CT 105 – WireGuard unter Windows 11 einrichten und verwenden **Dokumenten-ID:** GNAI-007-SEC-SOP-02 **Status:** Anleitung bereinigt; Windows-Praxistest noch offen diff --git a/docs/platform/GNAI-007-SEC_VPN_Implementation-Log.md b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md similarity index 79% rename from docs/platform/GNAI-007-SEC_VPN_Implementation-Log.md rename to docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md index ebffa5c..964be3e 100644 --- a/docs/platform/GNAI-007-SEC_VPN_Implementation-Log.md +++ b/docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md @@ -1,4 +1,4 @@ -# GNAI-007-SEC – Implementation-Log +# CT 105 – GNAI-007-SEC Implementation-Log **Dokumenten-ID:** GNAI-007-SEC-SOP-04 **Bezug:** [Gateway-Architektur](GNAI-007-SEC_VPN.md) @@ -12,6 +12,7 @@ | 2026-09-15 | 2.0 | spektr | Historie nach v14/v15 getrennt, Betreiberangaben eingearbeitet, unbelegte Befunde korrigiert, offene Sicherheitsabnahmen ausgewiesen | | 2026-09-16 | 2.1 | spektr | bestätigten Fail2Ban-Pin und wieder laufenden Container als Querverweis aufgenommen; weitergehende Abnahme nicht unterstellt | | 2026-09-18 | 2.2 | spektr | Lesenden SSH-Abgleich von CT 105 und Grenzen des Nachweises dokumentiert. | +| 2026-09-22 | 2.3 | Codex | aktuellen Gateway-Zustand live inventarisiert und Berechtigungen der Schlüsseldateien gehärtet | ## 1. Evidenz und zeitliche Einordnung @@ -23,7 +24,8 @@ | 15.09.2026 | Betreiber bestätigt NPM `.10`, WireGuard `.15`, dynamischen LXC-Bestand bis `.99`, DHCP `.100–.200`; neues Rollenmodell | | 16.09.2026 | Betreiber bestätigt Fail2Ban-Pin `1.1.0-r2-ls43` und wieder laufenden Container; weitergehende Fail2Ban-Abnahme nicht gemeldet | | 18.09.2026 | lesender SSH-Abgleich auf CT 105: Dienste, Container, nftables, iptables-legacy und Listener geprüft | -| diese Revision | Dokumentationsänderungen; keine WireGuard-Systemänderung und keine zusätzliche WireGuard-Abnahme | +| 22.09.2026 | erneuter Live-Abgleich; `wg-easy.db` und historisches `wg0.json` von 0644/0640 auf 0600 gehärtet; Dienst und WireGuard-Interface anschließend funktionsfähig | +| diese Revision | Dateirechte gehärtet und Laufzeit geprüft; keine Firewall-, Peer- oder Routingänderung und keine zusätzliche Rollenabnahme | ## 2. Historischer Serveraufbau am 09.09.2026 @@ -126,7 +128,26 @@ Per SSH-Profil `lxc` wurde CT 105 ohne Konfigurationsänderung geprüft: Diese Beobachtungen bestätigen den breiten Netzpfad und die NAT-Abhängigkeit. Sie belegen keine Peer-spezifische Zugriffsbeschränkung; Per-Client Firewall und negative Rollentests bleiben offen. Die Prüfung erfasste weder die GUI-Einstellungen noch die Fritzbox-, IPv6-Perimeter- oder Clientseite. -## 8. Offene Umsetzung und Abnahme +## 8. Live-Verifikation und erste Härtung am 22.09.2026 + +Der aktuelle Zustand wurde erneut per SSH-Profil `lxc` geprüft. Geheime +Schlüssel, Peer-Public-Keys und externe Peer-Endpunkte werden nicht im +Repository protokolliert. + +| Bereich | Ergebnis | +| --- | --- | +| Laufzeit | Debian 13; `wg-easy`, `nftables` und SSH aktiv. `wg-easy.service` lief seit dem 09.09.2026 ohne registrierten Neustart. | +| Container | `ghcr.io/wg-easy/wg-easy:15.4.0`, Image-Digest `sha256:6b89677a396dc2831d3b5b74d720d6d50c38fd2cbe9071bc8419453f236a94b3`, rootful, Hostnetz, `NET_ADMIN` und `NET_RAW`. | +| Forwarding | IPv4-Forwarding aktiv, IPv6-Forwarding aus. | +| Firewall | nftables bleibt bei INPUT/FORWARD `drop`, enthält aber die breite Freigabe neuer VPN→LAN-Verbindungen. Die von wg-easy erzeugten iptables-legacy-Regeln akzeptieren `wg0` in beide Richtungen. Peer-spezifische Regeln fehlen. | +| Peers | `.2` hatte bereits einen Handshake; `.3` noch nie. `Laptop-FullAdmin` muss weiterhin Familie oder Server Admin zugeordnet werden; für `Android-LLMAdmin` ist Beibehalten oder Widerruf zu entscheiden. | +| Listener | UDP 51820 auf IPv4/IPv6; TCP 51821 auf allen IPv4-Adressen; SSH auf IPv4/IPv6. Die nftables-INPUT-Regeln erlauben TCP 22/51821 nur aus dem LAN. Eine externe Perimeterprüfung steht aus. | +| SSH | Root-, Passwort- und Keyboard-Interactive-Login aus; Public-Key-Login an. X11- und allgemeines TCP-Forwarding sind noch erlaubt und müssen gegen den vorgesehenen Betriebszugang bewertet werden. | +| Updates | Installierte nftables- und OpenSSH-Pakete entsprechen den angebotenen Paketständen. `unattended-upgrades.service` ist nicht vorhanden; Patchverfahren und Wartungsfenster sind festzulegen. | +| Backup | Nur das historische wg-easy-Backup vom 09.09.2026 wurde gefunden. Ein aktuelles konsistentes Proxmox-/Dateibackup vor Firewall- oder Peer-Änderungen ist nicht belegt. | +| Dateirechte | `wg0.conf` war bereits `0600`. `wg-easy.db` und das historische `wg0.json` wurden von `0644` beziehungsweise `0640` auf `0600` reduziert. Danach waren Dienst und WireGuard-Interface weiterhin funktionsfähig. | + +## 9. Offene Umsetzung und Abnahme | ID | Arbeit | Status | | --- | --- | --- | @@ -139,5 +160,6 @@ Diese Beobachtungen bestätigen den breiten Netzpfad und die NAT-Abhängigkeit. | O7 | WAN-/IPv6-Managementport-Isolation | offen | | O8 | Reboot, Firewall-Reload und Restore | offen | | O9 | wg-easy-GUI-HTTPS und lokales Gruppenmodell | geplant; Werte noch festzulegen | +| O10 | SSH-Forwarding, X11 und automatisches Updateverfahren entscheiden | offen; keine Änderung ohne bestätigten Betriebsbedarf und Wartungsmodell | -Andere Sicherheitsbefunde werden im [Dokumentationsindex](../GNAI-000-DOC_Index.md) geführt. Dieses Log hält nur WireGuard-Umsetzung und zugehörige Tests fest. +Andere Sicherheitsbefunde werden im [Dokumentationsindex](../../../GNAI-000-DOC_Index.md) geführt. Dieses Log hält nur WireGuard-Umsetzung und zugehörige Tests fest.