From 0758813e6375ab0a461513465fa104c07ce7faec Mon Sep 17 00:00:00 2001 From: spektr Date: Thu, 24 Sep 2026 17:34:33 +0200 Subject: [PATCH] CT-103 SSH Migration abgeschlossen und dokumentiert. --- docs/GNAI-000-DOC_Index.md | 2 +- docs/GNAI-001-PLAN_Project-Roadmap.md | 19 +++++----- docs/platform/GNAI-005-SEC_Access-Control.md | 19 +++++++--- .../GNAI-011-SEC_LXC-SSH-Architecture.md | 35 ++++++++++++------- .../ct-103/GNAI-006-SEC_Reverse-Proxy.md | 29 +++++++++++---- 5 files changed, 71 insertions(+), 33 deletions(-) diff --git a/docs/GNAI-000-DOC_Index.md b/docs/GNAI-000-DOC_Index.md index 45a56c9..b535599 100644 --- a/docs/GNAI-000-DOC_Index.md +++ b/docs/GNAI-000-DOC_Index.md @@ -65,7 +65,7 @@ Am 22.09.2026 wurden KI-Host und Proxmox-LXCs in getrennte Unterverzeichnisse | 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 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 | +| Reverse Proxy | CT-103-Lesekonto, persönlicher Schlüsselzugang mit passwortgeschütztem sudo sowie SSH- und LAN/WireGuard-Netzbaseline einschließlich Reboot abgenommen; Root-/Passwortzugriff abgelehnt; NPM 2.15.1 und Fail2Ban aktiv; sensible NPM-Dateirechte gehärtet | wirksame Jails/Bans und deren Wiederanlauf; Keycloak-Adminpfad weiterhin offen | | 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 627473d..19cf493 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-22 +**Stand:** 2026-09-24 **Status:** Arbeitsgrundlage; Entscheidungstore vor externer Veröffentlichung offen @@ -61,14 +61,17 @@ 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 +**Ausführungsstand 24.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. +WireGuard-Gateways wurden auf `0600` gehärtet. Auf CT 103 sind persönlicher und +lesender Schlüsselzugang, passwortgeschütztes sudo, SSH-Härtung, +LAN/WireGuard-Netzbaseline und der Wiederanlauf nach einem kontrollierten +Neustart abgenommen. Für die nächsten wirksamen Änderungen fehlen weiterhin +(1) ein aktueller Rückfallstand vor der Keycloak-Änderung sowie (2) die +verbindliche Rolle der beiden vorhandenen VPN-Peers. Die technische Reihenfolge +ist deshalb: Backup sichern, öffentlichen `/admin`-Pfad sperren und +regressionsprüfen, Peers zuordnen und Gateway-Regeln umsetzen, anschließend die +noch offenen Fail2Ban-Funktionstests abschließen. **Fertig, wenn:** Die vier priorisierten Sicherheitsbefunde im zentralen Index als bestanden oder mit ausdrücklich akzeptiertem Restrisiko dokumentiert sind. diff --git a/docs/platform/GNAI-005-SEC_Access-Control.md b/docs/platform/GNAI-005-SEC_Access-Control.md index 879e624..59c5817 100644 --- a/docs/platform/GNAI-005-SEC_Access-Control.md +++ b/docs/platform/GNAI-005-SEC_Access-Control.md @@ -16,6 +16,7 @@ | 2026-09-16 | 1.2 | spektr | Fail2Ban-Pin `1.1.0-r2-ls43` und wieder laufenden Container als Ist-Stand übernommen; technische Abnahme bleibt in GNAI-006 geführt. | | 2026-09-18 | 1.3 | spektr | KI-Anwendungsdienste als Zielbild und bestehende Fail2Ban-Jails als dokumentierten Ist-Stand eingeordnet. | | 2026-09-21 | 1.4 | spektr / Codex | Zugriffsziel von einer vorentschiedenen LiteLLM-Implementierung auf eine noch festzulegende API-Policy-Schicht verallgemeinert | +| 2026-09-24 | 1.5 | Codex | Einfache serverseitige SSH-Netzbaseline festgelegt: TCP 22 aus lokalem LAN und über WireGuard erreichbar, öffentliche Netze gesperrt; Anmeldung weiterhin nur mit individuellen Public Keys. | --- @@ -149,13 +150,21 @@ API-Keys sollen: ### 4.4 SSH -SSH wird auf dem LLM-Server schlüsselbasiert betrieben. +SSH wird auf den Servern schlüsselbasiert betrieben. Die serverseitige +Netzbaseline erlaubt TCP 22 aus dem lokalen LAN sowie für Verkehr, der über das +WireGuard-Gateway zum Server gelangt. Eine zusätzliche Einschränkung auf eine +einzelne Admin-Workstation oder deren dynamische DHCP-Adresse ist nicht +vorgesehen. Öffentliche Netze bleiben ausgeschlossen. -Zusätzliche Schutzschicht: +Diese grobe Netzgrenze ersetzt keine Authentifizierung: Jeder tatsächliche +Login benötigt einen individuell zugeordneten SSH-Public-Key. Passwort- und +Root-Login über SSH bleiben deaktiviert. Die Umgebung verwendet derzeit +Public-Key-Authentifizierung, keine von einer SSH-CA signierten +OpenSSH-Zertifikate. -WireGuard-Zielberechtigung und eigener SSH-Public-Key-Login. - -Passwort- und Root-Login über SSH bleiben deaktiviert. +VPN-Rollen dürfen weiterhin vorgelagert am WireGuard-Gateway steuern, welche +Zielserver ein Peer überhaupt erreicht. Die Zielserver führen jedoch keine +zusätzliche per-Workstation- oder per-Peer-SSH-Allowlist. --- 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 index d450af6..fc9b4f8 100644 --- a/docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md +++ b/docs/platform/proxmox-lxc/GNAI-011-SEC_LXC-SSH-Architecture.md @@ -2,7 +2,7 @@ **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 +**Status:** Legacy-Root-Bestand und Zielbild definiert; CT-103-SSH-Rollout einschließlich Neustart abgenommen **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) @@ -16,6 +16,9 @@ | 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. | +| 2026-09-24 | 0.7 | Codex | Effektive CT-103-INPUT-DROP-Policy und LAN-Begrenzung von SSH bestätigt; engere Management-Allowlist wegen dynamischer Workstation-Adresse zurückgestellt. | +| 2026-09-24 | 0.8 | Codex | Einfache Host-Netzbaseline für alle Server festgelegt: SSH aus LAN und via WireGuard zulassen, keine Workstation-`/32`-Allowlist; CT 103 serverseitig abgenommen. | +| 2026-09-24 | 1.0 | Codex | Kontrollierten CT-103-Neustart, Dienstwiederanlauf, Firewallwirkung, öffentliche Proxy-Pfade sowie Agenten- und persönlichen SSH-Zugang erfolgreich abgenommen. | ## 1. Zweck und Abgrenzung @@ -41,8 +44,11 @@ Verfahren. Ö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. +Netzwerkebene auf das lokale LAN sowie über das WireGuard-Gateway kommenden +Verkehr begrenzt. Welche Zielserver ein einzelner VPN-Peer erreicht, kann +weiterhin am Gateway gesteuert werden; der Ziel-LXC pflegt dafür keine zweite +per-Peer- oder per-Workstation-Allowlist. Ein erreichbarer TCP-Port gewährt +ohne zugeordneten Public Key keine Anmeldung. ## 3. Identitäten und Schlüssel @@ -136,11 +142,14 @@ 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. +- Der lokale LXC-Paketfilter erlaubt TCP 22 aus dem lokalen LAN und für den + über WireGuard weitergeleiteten beziehungsweise maskierten Verkehr. +- Eine zusätzliche Einschränkung auf einzelne Admin-Workstations oder + dynamische DHCP-Adressen wird auf den Zielservern nicht gepflegt. +- Die Anmeldung benötigt unabhängig vom Netzpfad einen individuellen + SSH-Public-Key; Root- und Passwort-SSH bleiben gesperrt. +- Öffentliche Netze bleiben gesperrt. Optionale VPN-Rollentrennung wird am + WireGuard-Gateway vor NAT durchgesetzt, nicht erneut auf jedem Zielserver. - 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. @@ -202,7 +211,9 @@ Reihenfolge: | 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`. | +| 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`; die temporäre Public-Key-Kopie wurde aus `/tmp` entfernt. | +| Netzwerkfilter | Aktiver und beim Boot aktivierter nftables-Dienst mit INPUT-Policy `drop`; TCP 22 und 81 werden nur aus `10.0.0.0/24`, TCP 80 und 443 allgemein angenommen. Der SSH-Listener bindet zwar an `*:22`, wird aber durch den Paketfilter begrenzt. Die LAN-Regel schließt den durch CT 105 maskierten WireGuard-Verkehr mit Quelladresse `10.0.0.15` ein und entspricht damit der beschlossenen einfachen Host-Netzbaseline. Eine Workstation-`/32`-Allowlist ist bewusst nicht vorgesehen. | +| Neustartabnahme | Kontrollierter Neustart am 24.09.2026; neuer Bootzeitpunkt `15:01:14`. `ssh.socket`, `ssh.service`, `nftables`, NPM und Fail2Ban waren danach aktiv, keine systemd-Unit fehlgeschlagen. Agenten- und persönlicher Schlüsselzugang sowie passwortgeschütztes sudo funktionierten. Port 81 war aus dem LAN erreichbar, Port 3000 durch die Firewall nicht erreichbar; Vaultwarden, Keycloak, Jellyfin, Nextcloud/OIDC und Gitea antworteten erfolgreich. | ## 8. Abnahmekriterien @@ -212,7 +223,7 @@ Reihenfolge: - [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 ist serverseitig nur aus LAN und über den WireGuard-Pfad erreichbar; öffentliche Netze sind durch die aktive INPUT-DROP-Policy ausgeschlossen. - [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. +- [x] LXC-Neustart und Wiederanlauf wurden erfolgreich geprüft. +- [x] CT-103-Private-Keys, Passwörter und Inhalte der beiden `authorized_keys` fehlen in Git und Laufprotokollen; dokumentiert sind nur Pfade und Public-Key-Fingerprints. diff --git a/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md b/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md index aa40ced..6466c55 100644 --- a/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md +++ b/docs/platform/proxmox-lxc/ct-103/GNAI-006-SEC_Reverse-Proxy.md @@ -2,7 +2,7 @@ **Dokumenten-ID:** GNAI-006-SEC **Titel:** Reverse Proxy und Fail2Ban – Konfiguration, Betrieb und Sicherheitsabnahme -**Status:** NPM 2.15.1 und Fail2Ban aktiv; lesender SSH-Zugang und lokale Dateirechte gehärtet; Keycloak-Admin-Exposure offen +**Status:** NPM 2.15.1 und Fail2Ban aktiv; SSH-Rollout 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) @@ -27,6 +27,9 @@ | 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. | +| 2026-09-24 | 2.3 | Codex | Aktive nftables-INPUT-DROP-Policy, LAN-Begrenzung von SSH und Boot-Aktivierung bestätigt; temporäre Public-Key-Datei entfernt. | +| 2026-09-24 | 2.4 | Codex | LAN- und WireGuard-Erreichbarkeit als bewusste einfache SSH-Netzbaseline bestätigt; engere Workstation-Allowlist verworfen. | +| 2026-09-24 | 2.5 | Codex | Kontrollierten Neustart und Wiederanlauf von SSH, nftables, NPM, Fail2Ban und öffentlichen Proxy-Pfaden erfolgreich abgenommen. | --- @@ -64,10 +67,11 @@ Dieses Dokument hält Konfiguration, Betrieb und Sicherheitsabnahme des zentrale 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 +Root konnte damit im Ausgangszustand nicht remote anmelden; die +Proxmox-Konsole war der administrative Zugang. Ein externer Handshake +bestätigte damals TCP/22, OpenSSH `10.0p2 Debian-7+deb13u4`, den bekannten +ED25519-Hostschlüssel und die global angebotenen Methoden +`publickey,password`. Effektiv galten außerdem `PasswordAuthentication yes`, `KbdInteractiveAuthentication no` und `PubkeyAuthentication yes`. Passwörter werden weder in diesem Repository noch in automatisierten Laufprotokollen verarbeitet. @@ -109,10 +113,21 @@ Hostschlüsselprüfung und ausschließlich diesen Schlüssel. | 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. | +| Firewall | Persistente und aktive nftables-INPUT-Policy `drop`; erlaubt TCP 22/81 aus `10.0.0.0/24` und TCP 80/443 allgemein. Port 3000 fällt durch die Default-Policy. `nftables.service` ist aktiv und aktiviert. Der SSH-Socket lauscht auf `*:22`, seine Netzfreigabe wird durch nftables begrenzt. | | 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. | +### 2.3 Wiederanlaufabnahme am 24.09.2026 + +Nach einem kontrollierten CT-Neustart meldete das System den neuen +Bootzeitpunkt `15:01:14`. `ssh.socket`, `ssh.service`, `nftables`, NPM und +Fail2Ban waren aktiv; fehlgeschlagene systemd-Units wurden nicht gemeldet. +Sowohl `ghost-agent` als auch der persönliche Schlüsselzugang `ghost` +funktionierten, einschließlich passwortgeschütztem sudo bis Root. Port 81 war +aus dem LAN erreichbar, während Port 3000 in einen Timeout lief. Vaultwarden, +Keycloak, Jellyfin, Nextcloud mit OIDC-Weiterleitung und Gitea antworteten über +den Reverse Proxy erfolgreich. + **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 @@ -159,7 +174,7 @@ table inet filter { | 80 | TCP | HTTP Ingress (NPM) | Öffentlich | | 443 | TCP | HTTPS Ingress (NPM) | Öffentlich | | 81 | TCP | NPM Web Admin Interface | Nur LAN (`10.0.0.0/24`) | -| 22 | TCP | OpenSSH Management | Nur LAN (`10.0.0.0/24`) | +| 22 | TCP | OpenSSH Management | LAN (`10.0.0.0/24`) einschließlich des durch CT 105 maskierten WireGuard-Verkehrs | | 3000 | TCP | NPM Node.js Backend | Intern / Nicht exponiert | `10.0.0.0/24` in den Freigaben für 22/81 umfasst auch die Gateway-Adresse `10.0.0.15`. Durch das aktuelle VPN-MASQUERADE erscheinen VPN-Clients bei NPM unter dieser Adresse. Die Port-Matrix beschreibt deshalb **keine** bereits wirksame VPN-Rollentrennung; diese muss am Gateway vor NAT umgesetzt und getestet werden.