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.

Frage beantwortet 2026-08-19 — und ein größerer Fund daneben

sorb hat fw-matrix-cx23 gezeigt, die CFGMON-Firewall. Die Antwort auf die Frage dieses Issues ist einfach: Es gibt für 9090 und 3100 gar keine Regel. Hetzner-Firewalls sind eingehend Default-Deny — die Ports sind also nicht „zugemacht worden", sie waren nie offen. Das deckt sich exakt mit der Beobachtung vom 2026-08-01, dass sie zu waren, ohne dass jemand den Console-Klick gemacht hatte.

„Weg A" (Firewall-Regel, die 9090/3100 auf bekannte Absender beschränkt) ist damit gegenstandslos für den öffentlichen Weg. Die privaten Absender (k3s/Matrix über das Hetzner-Netz) laufen an der Cloud-Firewall vorbei, die nur öffentlichen Verkehr filtert.

Sauber gelöst ist der Rest von CFGMON: SSH (2248), Grafana (3000), Coolify (9001, 8000–8001) und WireGuard (51841) sind quellbeschränkt auf sorbs Anschluss; cadvisor (8080) und node-exporter (9100) nur für 157.90.155.206.

⚠️ Offener rekursiver DNS-Resolver auf CFGMON

Beim Nachmessen der freigegebenen Ports gefunden, nicht Gegenstand dieses Issues, aber schwerwiegender: 188.245.193.243:53 beantwortet Anfragen aus dem öffentlichen Internet, über TCP und UDP, rekursiv für beliebige Fremddomains:

dig @188.245.193.243 google.com A
;; flags: qr rd ra;  QUERY: 1, ANSWER: 6      <- ra = Rekursion verfügbar

Die sichtbare Firewall-Regel für 53 erlaubt als Quelle nur 10.58.73.17 — erreichbar ist der Dienst trotzdem von einer öffentlichen IP. Entweder existiert eine zweite, weiter gefasste Regel, oder die Beschränkung greift nicht.

Warum das zählt: Ein offener Resolver ist der klassische Reflektor für DDoS-Amplifikation. Mit gefälschter Absender-IP wird CFGMON zum Werkzeug in einem Angriff auf Dritte — gemessen ~275 Byte Antwort auf ~40 Byte Anfrage, und der Faktor lässt sich vom Angreifer über die Abfrage vergrößern. Die Folgen treffen dabei uns: Beschwerden beim Provider, Sperrlisten, im Zweifel Abuse-Verfahren.

Das ist die Klasse dieses Issues, nur an einem Port, auf den niemand geschaut hat. Gehört als eigener Befund verfolgt, nicht hier mitentschieden.