diff --git a/hosts/cfgmon.md b/hosts/cfgmon.md index 7c0050e..4f1420d 100644 --- a/hosts/cfgmon.md +++ b/hosts/cfgmon.md @@ -147,8 +147,16 @@ umgesetzt ist er nicht. **Nächster Schritt:** Beide Ports per Hetzner-Cloud-Firewall auf die Absender einschränken. Sauberer wäre, sie gar nicht öffentlich zu binden: k3s liegt mit `10.0.0.2` im selben privaten Netz wie CFGMON (`10.0.0.3`), der Push könnte also -über das private Netz laufen. Für den Matrix-Server auf `49.13.132.245` prüfen, ob -er in dasselbe Netz aufgenommen werden kann — siehe [matrix](matrix.md). +über das private Netz laufen. + +**Update 2026-07-30**: der k3s/Matrix-Host (`49.13.132.245`, privat `10.0.0.2` — ist +derselbe Host, siehe [MATRIX-02](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus--erledigt-2026-07-30)) +nutzt für seinen eigenen Remote-Write/Loki-Push bereits die private IP +(`http://10.0.0.3:9090`/`:3100`, verifiziert in `apps/monitoring/alloy-config.yaml`), nicht +`188.245.193.243`. Der öffentlich erreichbare, unauthentifizierte Port bleibt trotzdem ein +CFGMON-seitiges Risiko (jeder im Internet könnte ihn ansprechen, nicht nur der k3s-Host) - +dieser Teil des Punkts ist also weiterhin offen, nur nicht mehr durch fehlende +Netz-Erreichbarkeit des Matrix-Hosts blockiert. --- @@ -171,6 +179,34 @@ sauberer, weil dafür kein Admin-Passwort nötig ist. --- +## CFGMON-08 — Kein Gitea-Actions-Runner registriert, Standort noch offen + +**Status:** offen + +`gitea.rohana.axion1337.de` (dieser Host) hostet mehrere Repos mit `.gitea/workflows/` +(u. a. `axion1337.chat-gitops`, `ThreadNet-Web`), aber es läuft **kein Runner** — Workflows +existieren, greifen aber nie. Tracking der eigentlichen Notwendigkeit (drei Baustellen +hängen daran: Web-/Desktop-Build-CI, Electron-Automatisierung, npm-Publish für +`threadnet-call`) läuft zentral in +[gitops#33](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/33) — hier nur +die **Standort-Frage**, die noch nicht entschieden ist: + +- **Auf CFGMON** (neben Gitea selbst): kürzeste Wege zu Gitea, aber dieser Host hat laut + [CFGMON-02](#cfgmon-02--traefik-gitea-und-cadvisor-sind-nicht-versioniert) ohnehin schon + unversionierte Infrastruktur - ein weiterer nicht-deklarativer Baustein wäre ungünstig, + außer der Runner wird von Anfang an sauber (IaC) aufgesetzt. +- **Auf dem k3s/Matrix-Cluster** (siehe [matrix](matrix.md)): passt zum GitOps-Modell dort + (alles deklarativ), Runner-Pod bräuchte aber Netzzugriff zu Gitea auf CFGMON - existiert + bereits privat (`10.0.0.2` ↔ `10.0.0.3`). +- **Secret-Handling für CI-Tokens** (z. B. der npm-Publish-Token für `threadnet-call`): + unabhängig vom Standort über Gitea Actions' eigene Secrets-Funktion (Repo-/Org-Settings), + nicht SOPS - siehe Begründung in gitops#33. + +**Nächster Schritt:** Standort entscheiden, dann Runner registrieren, dann #33 und die +verlinkten Issues (ThreadNet-Web#2, gitops#44) abarbeiten. + +--- + ## Erledigt ### CFGMON-05 — Monitoring-Stack unter IaC bringen · erledigt 2026-07-30 diff --git a/hosts/matrix.md b/hosts/matrix.md index 9efff99..506f988 100644 --- a/hosts/matrix.md +++ b/hosts/matrix.md @@ -1,74 +1,29 @@ # matrix -Matrix-Homeserver. +Matrix-Homeserver (Element Server Suite / Synapse) + K3s-Single-Node-Cluster, GitOps-verwaltet. | | | |---|---| +| **Hostname** | `MATRIX` | | **IPv4** | `49.13.132.245` | | **IPv6** | kein AAAA-Record | -| **DNS** | `matrix.axion1337.de` | +| **Privat** | `10.0.0.2` (`enp7s0`, dasselbe Hetzner-Netz wie CFGMON `10.0.0.3`) | +| **OS** | Debian 13 (trixie) | +| **DNS** | `matrix.axion1337.de` **und** `matrix.axion1337.chat` zeigen auf dieselbe IP — ebenso `axion1337.chat` (Apex) und `account.axion1337.chat` (MAS). `axion1337.de` ist die ältere/Registrar-Domain (IONOS-Mail läuft dort), `axion1337.chat` die eigentliche Matrix-Service-Domain. | | **Stand** | 2026-07-30 | -> **Nicht inventarisiert.** Alle Angaben stammen aus DNS-Abfragen und der -> Prometheus-Konfiguration auf CFGMON. Auf dem Host selbst wurde nichts geprüft. -> Beim ersten direkten Zugriff OS, Dienste und Compose-Projekte hier nachtragen. -> Verwandte Repos, noch nicht zugeordnet: `sorb/axion1337.chat-gitops`, -> `sorb/element-web`, `sorb/ThreadNet-Stack`. +**Inventarisiert** (direkter SSH-Zugriff, `~/.ssh/config`-Alias `axion1337`, Port 2248): +K3s + FluxCD + Element Server Suite (Synapse, MAS, Element Web, MatrixRTC), Authentik (OIDC), +Traefik, Cert-Manager, coturn, Draupnir, ClamAV, NetworkPolicies (Default-Deny). IaC-Repo: +[`sorb/axion1337.chat-gitops`](https://rohana.axion1337.de/sorb/axion1337.chat-gitops) - dieser +Host **ist** das Deployment-Ziel dieses Repos, nicht nur verwandt. Client-Forks: +`sorb/ThreadNet-Web` (Element Web), `sorb/threadnet-call` (Element Call/LiveKit-Widget). +`sorb/element-web` und `sorb/ThreadNet-Stack` sind **veraltete/abgelöste** Vorgänger-Repos +(letzte Aktivität 2026-05-11 bzw. 2025-10-24) - nicht mehr das, was hier läuft. ---- - -## MATRIX-01 — Klären, ob der Server Mail als `@matrix.axion1337.de` verschickt - -**Status:** offen — **blockiert die Mail-Härtung der Zone** - -Für `matrix.axion1337.de` existiert der komplette IONOS-Mail-Satz: `MX mx00/mx01`, -`TXT "v=spf1 include:_spf-eu.ionos.com ~all"`, `CNAME s1-ionos._domainkey` und -`CNAME autodiscover`. Bei `selendis` ist dasselbe Muster reine Altlast aus dem -Anlegen der Subdomain und wird entfernt. - -**Hier nicht ungeprüft übernehmen.** Matrix-Homeserver verschicken typischerweise -Mail für Registrierungsbestätigungen, Passwort-Resets und Benachrichtigungen. Wenn -der Absender `…@matrix.axion1337.de` lautet, sind SPF und DKIM auf diesem Namen -**funktional nötig** — sie zu löschen oder auf `-all` zu setzen würde den Mailversand -zerlegen, und zwar auf eine Weise, die erst auffällt, wenn sich jemand nicht -registrieren kann. - -**Nächster Schritt:** in der SMTP-Konfiguration des Homeservers den `From:`-Absender -nachsehen (bei Synapse: `email.notif_from` in der `homeserver.yaml`). Dann: - -- **Absender lautet auf `matrix.axion1337.de`:** SPF und DKIM behalten und prüfen, - ob sie den tatsächlichen versendenden Host abdecken. Läuft der Versand nicht über - IONOS, ist das aktuelle `include:_spf-eu.ionos.com` falsch und der echte Relay - muss aufgenommen werden. -- **Absender lautet anders** (z. B. auf den Apex): Härtung wie bei `selendis` — - Null-MX, `v=spf1 -all`, `_dmarc` mit `p=reject`. - -In beiden Fällen kann `autodiscover.matrix` weg: das ist ein Exchange-/Outlook- -Mechanismus, für Matrix-Föderation irrelevant — die läuft über `.well-known` bzw. -SRV-Records. - -Dieser Punkt blockiert außerdem `sp=reject` am Apex, siehe -[ZONE-02](../shared/zone-axion1337.md). - ---- - -## MATRIX-02 — Pusht per Remote-Write auf einen offenen Prometheus - -**Status:** offen — Gegenstück zu [CFGMON-03](cfgmon.md#cfgmon-03--prometheus-remote-write-und-loki-sind-öffentlich-ohne-auth) - -Dieser Host schreibt Metriken per Remote-Write an Prometheus auf CFGMON. Der -Receiver dort ist auf `188.245.193.243:9090` öffentlich und **ohne -Authentifizierung** erreichbar. - -**Nächster Schritt:** prüfen, ob dieser Host in das private Hetzner-Netz aufgenommen -werden kann, in dem CFGMON (`10.0.0.3`) und der k3s-Host (`10.0.0.2`) liegen. Dann -kann der Push über die private Adresse laufen und Port 9090 muss nicht mehr -öffentlich offen sein. Falls nicht möglich: Firewall-Regel auf CFGMON, die 9090 auf -`49.13.132.245` und die k3s-Absender einschränkt. - -Wichtig bei der Umstellung: die Remote-Write-URL liegt in der Konfiguration **dieses** -Hosts, die Firewall-Regel auf CFGMON. Beides muss zusammen geändert werden, sonst -brechen die Metriken ab. +`ufw`: aktiv, Default Deny Incoming / Allow Outgoing, explizite Allow-Regeln für +2248/tcp (SSH), 80/443, TURN/RTC-Ports. `unattended-upgrades` aktiv (Debian-Security + +Debian-Origin), siehe [MATRIX-04](#matrix-04--host-level-pre-update-benachrichtigung-erledigt). --- @@ -81,3 +36,68 @@ angelegt. Begründung siehe [ZONE-01](../shared/zone-axion1337.md). **Nicht verifiziert**, ob auf dem Host etwas auf den Namen hört. **Nächster Schritt:** prüfen und sonst löschen. + +--- + +## Erledigt + +### MATRIX-01 — Klären, ob der Server Mail als `@matrix.axion1337.de` verschickt · erledigt 2026-07-30 + +Für `matrix.axion1337.de` existiert der komplette IONOS-Mail-Satz: `MX mx00/mx01`, +`TXT "v=spf1 include:_spf-eu.ionos.com ~all"`, `CNAME s1-ionos._domainkey` und +`CNAME autodiscover`. Bei `selendis` ist dasselbe Muster reine Altlast; hier war die Frage +offen, weil Matrix-Homeserver typischerweise Mail für Registrierung/Passwort-Reset +verschicken. + +**Antwort, verifiziert per Config** (nicht nur vermutet) — direkt im IaC-Repo +`sorb/axion1337.chat-gitops`, dem tatsächlich hier deployten Stand geprüft: + +- `apps/production/custom-configs/synapse-values.yaml` — kein `email:`/`smtp_host`/ + `notif_from`-Block. +- `apps/production/custom-configs/mas-secret.yaml` (SOPS-entschlüsselt geprüft) — kein + `email`/`smtp`/`mailer`-Eintrag. +- `apps/production/element-server-suite.yaml` (HelmRelease values) — dito, nichts. + +Weder Synapse noch MAS versenden aktuell irgendeine Mail. Registrierung/Passwort-Reset +laufen ausschließlich über Authentik (OIDC, `auth.axion1337.chat`) und Einladungslinks. +Der komplette IONOS-Mail-Satz auf `matrix.axion1337.de` ist damit **funktional unnötig** — +dieselbe Härtung wie bei `selendis` anwenden (Null-MX, `v=spf1 -all`, `_dmarc p=reject`), +`autodiscover.matrix` kann ebenfalls weg. Damit ist auch +[ZONE-02](../shared/zone-axion1337.md) an dieser Stelle entblockt. + +**Separat davon** (andere Domain-Ebene, kein Widerspruch): auf diesem Host läuft seit +2026-07-30 ein eigener Mailversand für Host-Wartungsbenachrichtigungen +(`wartung@axion1337.de`, **Apex**-Postfach, nicht die `matrix.`-Subdomain) — siehe +MATRIX-04 unten. Nutzt die ohnehin am Apex laufende echte IONOS-Mail-Infrastruktur, +betrifft die `matrix.`-Subdomain-Records oben also nicht. + +### MATRIX-02 — Pusht per Remote-Write auf einen offenen Prometheus · erledigt 2026-07-30 + +**Korrektur einer falschen Annahme im ursprünglichen Eintrag**: der Text ging von zwei +getrennten Absendern aus - "CFGMON (`10.0.0.3`) und der k3s-Host (`10.0.0.2`)" - als wären +das zwei verschiedene Maschinen. Es ist **dieselbe Maschine**: dieser Host (`matrix`) hat +selbst die private IP `10.0.0.2` (verifiziert per `ip -4 addr show` auf dem Host). + +Verifiziert in `apps/monitoring/alloy-config.yaml` (diesem Cluster): Der Remote-Write-Push +geht bereits an `http://10.0.0.3:9090/api/v1/write` und Loki an `http://10.0.0.3:3100/...` - +**private IP, nicht die öffentliche** `188.245.193.243:9090`. Von dieser Seite aus ist hier +nichts mehr zu tun. Ob Prometheus/Loki auf CFGMON zusätzlich öffentlich erreichbar sind +(unabhängig davon, ob dieser Host den privaten Weg nutzt), ist +[CFGMON-03](cfgmon.md#cfgmon-03--prometheus-remote-write-und-loki-sind-öffentlich-ohne-auth) +- ein reines CFGMON-Thema, nicht mehr blockiert durch etwas auf diesem Host. + +### MATRIX-04 — Host-Level Pre-Update-Benachrichtigung · erledigt 2026-07-30 + +Neuer, eigenständiger Mechanismus auf diesem Host, außerhalb von Flux/GitOps (Details: +`docs/deployment-guides/07-host-maintenance-notifications.md` im gitops-Repo, +[Issue #24](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/24)): +`unattended-upgrades` war bereits aktiv, neu ergänzt ist ein systemd-Timer +(`maintenance-notify.timer`, fest 05:00 Uhr, vor dem 06:00-07:00-Update-Fenster), der bei +anstehenden Paket-Updates per Mail **und** Matrix (Thread-Reply im `wartung`-Raum) +benachrichtigt. + +Mail-Versand läuft über `msmtp`, Absender `wartung@axion1337.de` (IONOS SMTP, +`smtp.ionos.de:587`, STARTTLS - **Port 465 war ausgehend blockiert**, vermutlich +Cloud-Provider-Firewall-Regel, 587 ging durch). Relevant für die Mail-Policy-Diskussion +oben: dieses Postfach nutzt die reale, bereits am Apex laufende IONOS-Mail-Infrastruktur, +keine neue Subdomain, kein neuer Handlungsbedarf für die Zone. diff --git a/shared/zone-axion1337.md b/shared/zone-axion1337.md index 575acf9..35ab610 100644 --- a/shared/zone-axion1337.md +++ b/shared/zone-axion1337.md @@ -119,13 +119,22 @@ explizite „nimmt keine Mail an"-Aussage. - **`game`** und **`matrix`**: `www.`-Records, siehe [GAME-02](../hosts/game.md#game-02--wwwgameaxion1337de-ist-überflüssig) und [MATRIX-03](../hosts/matrix.md#matrix-03--wwwmatrixaxion1337de-ist-überflüssig). -- **Mail-Records auf `matrix`**: **erst** [MATRIX-01](../hosts/matrix.md) klären. Wenn - der Homeserver Mail als `@matrix.axion1337.de` verschickt, sind SPF und DKIM dort - funktional nötig. - **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket, zeigt auf IONOS und nicht auf eigene Infrastruktur — also keine zusätzliche Angriffsfläche, aber Ballast. Löschen, falls dort kein FTP genutzt wird. +### Geklärt: Mail-Records auf `matrix` + +[MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30) +ist erledigt (2026-07-30): weder Synapse noch MAS versenden Mail (per Config verifiziert, +nicht nur vermutet — Registrierung/Reset laufen über Authentik). Der komplette Mail-Satz +auf `matrix.axion1337.de` kann damit genauso gehärtet werden wie bei `selendis` +(Null-MX, `v=spf1 -all`, `_dmarc p=reject`), siehe ZONE-01 oben. Separat davon läuft seit +2026-07-30 echter, unabhängiger Mailversand über das **Apex**-Postfach +`wartung@axion1337.de` (Host-Wartungsbenachrichtigungen) - betrifft die +`matrix.`-Subdomain-Records nicht, bestätigt aber, dass am Apex weiterhin reale +IONOS-Mail-Infrastruktur aktiv genutzt wird. + **Nach der Umsetzung von hier aus verifizieren:** dass `www.rohana` und `www.selendis` nicht mehr auflösen; dass MX, SPF und DMARC greifen und **nur ein** SPF-Record pro Name existiert; und dass `A`/`AAAA` von `rohana` und `selendis` @@ -136,7 +145,7 @@ Punkt ist der, bei dem ein Verklicker in der IONOS-Oberfläche wehtun würde. ## ZONE-02 — Apex-DMARC ist `p=none` und schützt nichts -**Status:** offen — **blockiert durch [MATRIX-01](../hosts/matrix.md)** +**Status:** offen — nicht mehr blockiert, [MATRIX-01](../hosts/matrix.md#matrix-01--klären-ob-der-server-mail-als-matrixaxion1337de-verschickt--erledigt-2026-07-30) ist seit 2026-07-30 erledigt `_dmarc.axion1337.de` enthält `v=DMARC1; p=none;` (via `dmarc.ionos.de`). Das ist reines Monitoring: Empfänger melden Verstöße, verwerfen aber nichts. Für gefälschte