Mit Matrix, Element und LiveKit betreibe ich eine Plattform für Nachrichten, Sprach- und Videoanrufe sowie Bildschirmfreigabe. Die Dienste werden täglich genutzt. In diesem Beitrag zeige ich, wie die Komponenten zusammenarbeiten und wie ich den öffentlichen Zugang, interne Verbindungen und die Verwaltung absichere.
Inhaltsverzeichnis
Wie die Komponenten zusammenspielen
- Chat: Element ist die Oberfläche, Synapse verwaltet Konten, Räume und Ereignisse.
- Anrufe: Element Call übernimmt die Anrufoberfläche, LiveKit die Medienverteilung und lk-jwt die Autorisierung.
- Betrieb: Nginx und HAProxy steuern den Webzugang, Synapse Admin dient der Verwaltung.
PostgreSQL speichert die dauerhaften Daten von Synapse. Redis unterstützt Caching und, je nach Aufbau, die Kommunikation zwischen Synapse-Prozessen. Datenbank und Cache sind ausschließlich intern erreichbar.
Warum Anrufe mehr als HTTPS brauchen
Für den Verbindungsaufbau nutzt LiveKit sichere WebSockets (WSS). Audio, Video und Bildschirmfreigabe werden über WebRTC übertragen und brauchen eigene Netzwerkfreigaben. Eine funktionierende HTTPS-Verbindung zum Webclient reicht deshalb für einen Anruf noch nicht aus. LiveKit bringt einen TURN-Dienst mit; coturn deckt weitere unterstützte WebRTC-Anrufpfade ab.
lk-jwt verbindet die Matrix-Identität mit dem Zugang zu LiveKit und stellt dafür Tokens aus. Welche Nutzer Medienräume erstellen oder ihnen beitreten dürfen, muss zur verwendeten Version und Betriebsart passen. Eine erfolgreiche Anmeldung allein soll keinen uneingeschränkten Zugriff auf die Medieninfrastruktur erlauben.
Was E2EE schützt – und was TLS übernimmt
In Ende-zu-Ende-verschlüsselten Matrix-Räumen werden Nachrichten auf den Endgeräten verschlüsselt. Ein Serveradministrator kann die Inhalte ohne die Raumschlüssel nicht entschlüsseln. TLS schützt dagegen den Transport: Endet die Verbindung am Reverse Proxy, ist die Verbindung zum Backend gesondert abzusichern und dessen Zertifikat zu prüfen.
E2EE schützt nicht sämtliche Metadaten und auch kein kompromittiertes Endgerät. Ob Anrufe und Bildschirmfreigabe ebenfalls Ende-zu-Ende-verschlüsselt sind, ist für die eingesetzten Clients und Funktionen separat zu prüfen.
Zero Trust gilt auch im internen Netz
Ich behandle interne Verbindungen mit derselben Sorgfalt wie öffentliche Zugriffe. Eine interne IP-Adresse schafft keine Berechtigung. Netzwerkregeln erlauben gezielt die benötigten Verbindungen; Authentifizierung und begrenzte Rechte bleiben auch dahinter erforderlich.
Synapse Admin und die zugehörige Admin-API sind nur für freigegebene Verwaltungszugriffe erreichbar. Die Regeln werten die tatsächliche Client-IP aus. Weiterleitungsheader werden nur von vertrauenswürdigen Proxies übernommen. Bei der Einrichtung habe ich auch geprüft, dass sich die Freigabe nicht mit gefälschten Headern umgehen lässt.
Hinter dem Proxy begrenze ich Verbindungen nach Quelle, Ziel und Dienst. Synapse wird über den vorgesehenen Proxyweg angesprochen, Datenbank und Cache bleiben vom öffentlichen Zugang getrennt. Für Verbindungen zwischen Hosts gehören Verschlüsselung und die Prüfung der Gegenstelle zum Sicherheitskonzept.
WAF, Rate Limits und Fail2ban
Am öffentlichen Webzugang setze ich zusätzlich ModSecurity mit dem OWASP Core Rule Set ein. Die WAF prüft HTTP-Anfragen auf verbreitete Angriffsmuster. Nötige Ausnahmen müssen eng begrenzt sein, damit Anmeldung, Synchronisation und Uploads funktionieren. WebRTC-Medien werden von dieser HTTP-Prüfung nicht erfasst.
- Rate Limits nach Endpunkt wählen. Ein unzulässiger Zugriff wird mit 403 abgewiesen, eine überschrittene Anfragerate mit 429.
- Zeitlimits auf WebSockets und Matrix-Synchronisation abstimmen, damit reguläre lange Verbindungen bestehen bleiben.
- Eigene Fail2ban-Filter erkennen wiederholten Missbrauch. Die Sperre muss dort greifen, wo sich die tatsächliche Client-IP wirksam blockieren lässt.
In den Logs sollen weder Passwörter noch Zugangstokens landen. Die zentrale Auswertung hilft mir, Fehler beim Webzugriff, in Synapse und beim Aufbau einer Medienverbindung zusammenzuführen. Ich prüfe deshalb den gesamten Ablauf bis zum tatsächlichen Austausch von Audio und Video.
Die Plattform im Betrieb prüfen
| Testfall | Erwartetes Ergebnis |
|---|---|
| Anruf aus einem anderen Netz | Der Anruf wird aufgebaut; Audio, Video und Bildschirmfreigabe funktionieren, bei Bedarf über TURN. |
| Nicht erlaubter Verwaltungszugriff | Der Zugriff wird abgewiesen, auch bei gefälschten Weiterleitungsheadern. |
| Ausfall eines Dienstes | Die Auswirkungen auf Anmeldung, Nachrichten und laufende Anrufe werden getrennt erfasst. |
| Wiederherstellung | Nach der Rücksicherung werden Anmeldung, Nachrichten, Medienabruf und Anrufe praktisch getestet. |
Zum laufenden Betrieb gehören Updates, begrenzte Logaufbewahrung und überprüfte Backups. Für die Wiederherstellung müssen Datenbank, hochgeladene Medien, Konfiguration und benötigte Schlüssel zusammenpassen. Ausfälle einzelner Komponenten teste ich getrennt, denn eine weitere Synapse-Instanz sichert Datenbank und Medienpfade nicht automatisch mit ab.
Standortausfälle bilde ich virtuell nach. So lassen sich Abhängigkeiten und Übernahmen testen. Eine echte räumliche Trennung, etwa mit unabhängiger Strom- und Internetversorgung, kann dieser Testaufbau nicht ersetzen.
Fazit
Die größte Aufgabe liegt für mich im Zusammenspiel der Dienste: Chat, Anrufe und Verwaltung haben unterschiedliche Zugriffswege und Abhängigkeiten. Klare Freigaben, geprüfte interne Verbindungen und Tests aus verschiedenen Netzen helfen mir, diese Plattform sicher und zuverlässig zu betreiben.
Technische Referenzen: Synapse reverse proxy · Matrix E2EE · LiveKit deployment · lk-jwt · Fail2ban · Zero Trust: NIST SP 800-207 · ModSecurity / OWASP CRS