ghostnet.ai/infrastructure
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Sicherheitsarchitektur überprüft. CT-103 SSH login aktualisiert.

Browse Source
This commit is contained in:
spektr
2026-09-22 20:27:42 +02:00
parent 53c5970c60
commit 03a284c66e
15 changed files with 413 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/GNAI-000-DOC_Index.md
+13 -10
View File
@@ -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
docs/GNAI-001-PLAN_Project-Roadmap.md
+10 -1
View File
@@ -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.
docs/ai/GNAI-004-INFRA_Architecture.md
+1 -1
View File
@@ -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)
---
docs/platform/GNAI-005-SEC_Access-Control.md
+3 -3
View File
@@ -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.
docs/platform/README.md
+11 -12
View File
@@ -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).
docs/platform/GNAI-002-INFRA_BaseSystem.md → docs/platform/ghostnet-ai/GNAI-002-INFRA_BaseSystem.md
+3 -2
View File
@@ -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. |
---
docs/platform/GNAI-003-INFRA_Users.md → docs/platform/ghostnet-ai/GNAI-003-INFRA_Users.md
+3 -2
View File
@@ -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. |
---
docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md
+218
View File
@@ -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.
docs/platform/proxmox-lxc/README.md
+11
View File
@@ -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 |
docs/platform/GNAI-006-SEC_Reverse-Proxy.md → docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md
+102 -7
View File
@@ -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 |
docs/platform/GNAI-007-SEC_VPN.md → docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN.md
+8 -6
View File
@@ -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
docs/platform/GNAI-007-SEC_VPN_Client-Management.md → docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Client-Management.md
+2 -2
View File
@@ -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
docs/platform/GNAI-007-SEC_VPN_Clients_Linux.md → docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Linux.md
+1 -1
View File
@@ -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
docs/platform/GNAI-007-SEC_VPN_Clients_Windows11.md → docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Clients_Windows11.md
+1 -1
View File
@@ -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
docs/platform/GNAI-007-SEC_VPN_Implementation-Log.md → docs/platform/proxmox-lxc/ct-105/GNAI-007-SEC_VPN_Implementation-Log.md
+26 -4
View File
@@ -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.