management/docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md

type, id, status, created, milestone, priority, host, area, wartegrund, gitlab_iid, related

type	id	status	created	milestone	priority	host	area	wartegrund	gitlab_iid	related
issue	0008	waiting	2026-08-01	M1	medium	cfgmon	security	Wartet auf den gemeinsamen Blick in die Hetzner-Cloud-Console mit sorb: welche Firewall-Regeln existieren real (das Backlog-Bild wich davon ab). Von außen sind 9090/3100 bereits dicht — es geht um die bewusste, dokumentierte Regel, nicht mehr um akute Exposition.	8

CFGMON-03: Prometheus-Remote-Write und Loki öffentlich ohne Auth — Weg A, nachgelagerte Prüfung

Import aus management#8 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

Prometheus 9090 (--web.enable-remote-write-receiver) und Loki 3100 sind öffentlich ohne Auth — Fremde könnten Metriken einspeisen und Daten/Logs auslesen. Absender-Inventur: k3s/Matrix pusht längst privat (10.0.0.3); öffentlich bräuchte die Ports nur der GAME-Host (→ GAME-01).

Weg A beschlossen (sorb 2026-08-01): Hetzner-Cloud-Firewall — 9090/3100 nur für bekannte Absender. Nachgelagerte Prüfung nötig: Beim Baseline-Check vom Mac waren 9090/3100 bereits zu, OHNE dass der Console-Klick gemacht war — die reale Firewall-Lage weicht vom Backlog-Bild ab. Vor dem Abhaken gemeinsam in die Hetzner-Console schauen: welche Regeln existieren wirklich, und läuft der GAME-Push (nach GAME-01) noch durch? Weg B (GAME in den vSwitch, Ports ganz zu) bleibt die saubere Endstufe; Weg C (BasicAuth via Traefik) verworfen.

Quelle: hosts/cfgmon.md

---

Übernommen aus dem Backlogs-Markdown beim Framework-Umbau 2026-08-01 (voller Wortlaut: Git-Historie der Datei).

Nachgeprüft 2026-08-15 — akute Exposition besteht nicht

Messung vom Mac gegen die öffentliche CFGMON-IP: 9090 (Prometheus remote-write) und 3100 (Loki) antworten nicht, während :443 sofort antwortet (Gegenprobe, Messmethode also gültig). Das bestätigt die im Issue vermerkte Beobachtung: die Ports sind zu, ohne dass der Console-Klick je gemacht wurde.

Damit verschiebt sich der Charakter des Issues: Es geht nicht mehr um akutes Risiko, sondern darum, dass der Ist-Zustand nicht bewusst hergestellt und nicht dokumentiert ist — was heute zufällig zu ist, kann bei der nächsten Änderung unbemerkt aufgehen. Zu klären bleibt: welche Regeln greifen tatsächlich, und trägt das den GAME-Push (#0002) nach dessen vSwitch-Umzug noch?

Wächter gebaut 2026-08-19 — der Ist-Zustand hat jetzt eine Instanz, die ihn hält

Aus dem Befund vom 15.08. („zu, aber nicht bewusst hergestellt und nicht dokumentiert") folgt genau ein wirksamer Schritt, und er ist getan: notfallhandbuch:pruefe-ports.sh plus ports-soll.md, nach dem Muster von pruefe-dns.sh.

Gemessen, nicht abgeleitet (2026-08-19, von sorbs Mac):

Host	offen	zu
Matrix 49.13.132.245	80, 443, 3478, 5349, 30001, 2248	22
CFGMON 188.245.193.243	80, 443	9090, 3100, 22

Das Skript prüft beide Richtungen — eine reine Erreichbarkeitsprüfung würde eine öffentlich stehende Telemetrie nie bemerken. Vor und nach jeder Firewall-Änderung laufen lassen; damit ist auch die Frage aus dem Issue beantwortbar, ob der GAME-Push (#0002) nach dem vSwitch-Umzug noch trägt: einmal vorher, einmal nachher.

Die Gegenprobe ist der Kern, nicht die Zierde. In einem Netz, das ausgehende Verbindungen filtert, meldet jede Portprüfung „alles zu" — was wie ein perfektes Ergebnis aussieht. Beim Bau real passiert: Die erste Fassung nutzte /dev/tcp, das die zsh nicht kennt, und meldete jeden Port als geschlossen, 443 eingeschlossen. Das Skript bricht deshalb mit Exit 2 ab, wenn ein bekannt offener Port nicht antwortet.

UDP bleibt bewusst außen vor (TURN 3478, SFU 30002): Ohne Antwort sind „gefiltert" und „offen, aber still" nicht zu trennen. Diese Strecken belegt nur ein echter Gruppen-Call.

Weiterhin offen — der Teil, der sorb braucht: der gemeinsame Blick in die Hetzner-Console. Das Skript sagt, was von außen erreichbar ist; welche Regeln das bewirken und ob sie bewusst so stehen, sagt nur die Console. Erst danach ist das Issue erledigt.

Console-Einblick 2026-08-19 — Matrix-Host gesehen, CFGMON weiterhin nicht

sorb hat die Hetzner-Console gezeigt: fw-matrix-cx42, 15 Regeln, vollständig angewandt. Das ist der Matrix-Host, nicht CFGMON — die Frage dieses Issues (welche Regel hält 9090/3100 auf CFGMON zu?) ist damit noch offen. Gemessen sind beide Ports zu; warum, weiß weiterhin niemand.

Der Einblick war trotzdem wertvoll, in zwei Richtungen.

Sauber gelöst: SSH (2248) und die Kubernetes-API (6443) sind quellbeschränkt auf sorbs Anschluss (178.25.213.70, 2a02:8108:0:2f::/64), nicht für alle offen. Das hat auch einen Fehler in pruefe-ports.sh aufgedeckt: Die Liste führte 2248 schlicht als „offen", womit das Skript aus jedem anderen Netz zwei Falschbefunde gemeldet hätte. Behoben — beide gelten jetzt als quellbeschraenkt und werden berichtet, aber nicht gewertet.

Die Firewall ist deutlich weiter offen als die Plattform. Von außen gemessen antwortet auf diesen Regeln nichts:

Regel	Befund
smtp TCP 587 eingehend, Any	Vermutlich versehentlich. Der Host verschickt Mail ausgehend; eingehende Regeln helfen dabei nicht (Hetzner filtert nur eingehend). Der Deployment-Guide dokumentiert genau dieses Debugging („465 blockiert, 587 geht") — die Regel sieht nach dessen Rest aus.
mRTC SFU muxed UDP 30000–65535	~35.500 Ports für einen benötigten (30002).
mRTC SFU TCP TCP 30000–60000	~30.000 Ports für einen benötigten (30001).
RTC SFU 1 6789, RTC SFU 2 7880, mRTC Auth 8080, je Any	nichts lauscht; die Dienste laufen über den Ingress auf 443.

Kein akutes Risiko — aber eine unnötig breite erklärte Angriffsfläche: Sobald dort je etwas horcht, ist es sofort weltweit erreichbar, ohne dass jemand eine Regel anfassen müsste. Festgehalten in notfallhandbuch:ports-soll.md.

Zum Abschluss dieses Issues fehlt weiterhin: der Blick auf die CFGMON-Firewall.