docs(issues): wiki enrolment live, mail blocker gone, console seen for the wrong host
Three corrections to questions I should not have asked again. #0103 is implemented: autoEnrollGroups points at wiki-anwender, verified in the live database rather than from the job log. The decision was already in #0049 - the role model was built, only the way in was missing. #0102's blocker was in the documentation all along: maintenance-notify sends under .de, not .chat, via IONOS on 587. The MAIL_FROM in config.example is an example, not the operating state. So hardening .chat cannot break maintenance mail, and Authentik remains its only .chat sender - DKIM-covered. #0008 is not resolved by the console screenshots: they show fw-matrix-cx42, the Matrix host, while the issue asks which rule keeps 9090 and 3100 shut on CFGMON. Still open. What they did show is worth keeping: SSH and the Kubernetes API are properly source-restricted, and several rules open ports to everyone where nothing listens - including an inbound smtp 587 that cannot help the outbound sending it was presumably added for. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Thore Cimbal
co-authored by
Claude Opus 5
Claude Opus 5
parent
b3d2faa032
commit
a90ebd379b
@@ -79,3 +79,35 @@ echter Gruppen-Call.
|
||||
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.
|
||||
|
||||
@@ -98,3 +98,27 @@ Richtlinie verschärfen** — umgekehrt zerlegt es den Versand unbemerkt.
|
||||
- `notfallhandbuch:dns-soll.md` und `pruefe-dns.sh` tragen den neuen Soll-Stand;
|
||||
der bisherige Satz „Härtung vorgeschlagen, aber nicht entschieden" wird
|
||||
ersetzt.
|
||||
|
||||
## Blocker aufgelöst 2026-08-19 — `maintenance-notify` sendet unter `.de`
|
||||
|
||||
Die offene Frage („worüber verschickt `maintenance-notify` tatsächlich?") steht in der
|
||||
Doku, nicht auf dem Host: `gitops:docs/deployment-guides/07-host-maintenance-notifications.md`,
|
||||
Abschnitt Stolpersteine.
|
||||
|
||||
> **Absender-Domain ≠ Matrix-Server-Domain.** […] bei axion1337 z.B. Mail unter `.de`,
|
||||
> Matrix unter `.chat` — `MAIL_FROM` und der `user`/`from` in `msmtprc` müssen zur
|
||||
> tatsächlichen Mail-Domain passen.
|
||||
|
||||
Der Versand läuft über **IONOS auf 587/STARTTLS** (465 ist ausgehend blockiert, ebenfalls
|
||||
dort dokumentiert). Die `MAIL_FROM="wartung@axion1337.chat"` in `config.example` ist ein
|
||||
**Beispiel**, nicht der Betriebsstand.
|
||||
|
||||
**Folge für dieses Issue:** Eine Härtung von `axion1337.chat` berührt
|
||||
`maintenance-notify` nicht — dessen Absenderdomain `.de` trägt bereits `p=reject`
|
||||
(#0006). Damit bleibt als einziger `.chat`-Absender **Authentik** (`gamemaster@`,
|
||||
IONOS-SMTP, DKIM über die drei `*.dkim.ionos.com`-CNAMEs gedeckt).
|
||||
|
||||
Der Vorschlag im Issue ist damit ohne die befürchtete Nebenwirkung umsetzbar: eigener
|
||||
`_dmarc`-TXT statt IONOS-CNAME, zunächst `p=quarantine` mit `rua=`, danach `p=reject`;
|
||||
Null-MX und `-all` auf den sieben Service-Namen. Abnahme unverändert: Authentik-Testmail
|
||||
und eine Wartungsmeldung müssen **nachweislich** ankommen.
|
||||
|
||||
@@ -147,3 +147,34 @@ zugeordnet.
|
||||
entschieden. Solange die Punkte oben offen sind, bleibt für diese Konten der stumme
|
||||
Fall bestehen — das ist der Grund, warum dieses Issue nicht mit den Freigaben
|
||||
erledigt ist.
|
||||
|
||||
## Umgesetzt 2026-08-19 — Auto-Enrollment aktiv
|
||||
|
||||
Entscheidung sorb, und sie stand schon in **#0049**: normale Authentik-Nutzer lesen die
|
||||
Anwenderdoku, Admins sind Admins („Betrieb = Admin"). Das Rollenmodell war umgesetzt,
|
||||
der **Weg hinein** nicht — deshalb dieser Fall.
|
||||
|
||||
`autoEnrollGroups` der OIDC-Strategy zeigt jetzt auf `wiki-anwender`
|
||||
(`gitops:apps/production/wikijs-config.py`, Commit `dfb88a3`). Der Konfig-Job wurde neu
|
||||
angestoßen (Job löschen → Flux legt ihn an, wie im Dateikopf beschrieben) und meldet:
|
||||
`Auto-Enrollment in wiki-anwender, id 4`.
|
||||
|
||||
**In der laufenden Datenbank gegengeprüft**, nicht am Logtext:
|
||||
|
||||
```
|
||||
OIDC-Strategy selfRegistration=t autoEnrollGroups={"v":[4]} # 4 = wiki-anwender
|
||||
local selfRegistration=f autoEnrollGroups={"v":[]} # Break-Glass, unverändert
|
||||
```
|
||||
|
||||
Admins bleiben Handarbeit in Authentik: Mitgliedschaft in `authentik Admins` kommt über
|
||||
den `groups`-Claim und wird von dieser Grundausstattung nicht berührt. `betrieb/*`
|
||||
behält sein Default-Deny — die in #0049 end-to-end verifizierte Abschottung gilt
|
||||
unverändert, sie greift nur nicht mehr gegen Leute, die gar nicht erst hereingelassen
|
||||
wurden.
|
||||
|
||||
Der Skript-Teil bricht ab, wenn `wiki-anwender` fehlt, statt in eine leere Gruppe zu
|
||||
enrollen — das wäre genau der Fehler, den dieses Issue beschreibt.
|
||||
|
||||
**Offen bleibt der Aufräumteil:** die tote Authentik-Anwendung `wiki` ohne Provider und
|
||||
die Gruppe `wiki-zugang` (4 Mitglieder), die Rechte an ihr verteilt. Beides fasse ich
|
||||
erst auf Zuruf an, weil es Authentik-Konfiguration ist.
|
||||
|
||||
Reference in New Issue
Block a user