J’exploite Matrix avec Element et LiveKit sur mon infrastructure. Ces services sont utilisés chaque jour pour les messages, les appels audio et vidéo et le partage d’écran. Connexions internes sécurisées, administration et exploitation quotidienne font partie du même ensemble.
Sommaire
Une plateforme, trois responsabilités
- Chat : Element fournit l’interface ; Synapse gère comptes, salons et événements.
- Appels : LiveKit prend en charge audio, vidéo et partage d’écran ; lk-jwt fournit l’autorisation adaptée.
- Exploitation : Nginx et HAProxy contrôlent l’accès web ; Synapse Admin assure l’administration.
PostgreSQL conserve les données persistantes de Synapse. Redis sert au cache et, selon le mode de déploiement, à la coordination des processus. Ces deux dépendances internes n’ont pas besoin d’exposition publique.
Les appels suivent un autre chemin
WSS transporte la signalisation et WebRTC les médias. Audio et vidéo ne traversent donc pas le reverse proxy comme des requêtes HTTP ordinaires. LiveKit peut utiliser son TURN intégré ; coturn dessert d’autres chemins compatibles.
Avec lk-jwt, intégration et actions autorisées dans les salles varient selon version et mode de fonctionnement. Une identité Matrix valide doit recevoir seulement les droits média prévus, pas un usage illimité de l’infrastructure.
Séparer contenu et transport
Dans un salon Matrix chiffré de bout en bout, un administrateur serveur ne peut pas déchiffrer les textes sans les clés du salon. TLS protège une connexion pouvant se terminer au proxy. Une autre connexion TLS vers le backend nécessite sa propre vérification d’identité.
Métadonnées et appareils compromis restent d’autres questions. Pour appels et partage d’écran, vérifier E2EE avec les clients et fonctions réellement utilisés.
Le Zero Trust vaut aussi en interne
Je traite mon réseau interne comme un réseau externe potentiellement non fiable. Une adresse interne ne confère aucun droit. Connexions autorisées explicitement, identités vérifiées et privilèges limités : le durcissement se poursuit au-delà du reverse proxy public.
Le projet a limité Synapse Admin et son API. Le vrai client compte : HAProxy peut être fiable pour transmettre son IP sans obtenir lui-même des droits administratifs. Les tests de mise en place ont aussi rejeté des en-têtes falsifiés.
Derrière le proxy, les règles limitent source, destination et service. Base et cache restent internes ; le listener Synapse décrit écoute sur loopback local. Entre hôtes, chiffrement et validation des certificats sont explicites. Une permission réseau ne remplace toujours pas la connexion applicative.
Adapter le durcissement à l’application
À l’entrée web publique, j’utilise aussi ModSecurity avec l’OWASP Core Rule Set pour examiner les requêtes HTTP et détecter des attaques courantes. Les exceptions doivent rester ciblées par route, afin de préserver connexion, synchronisation et transferts. Les médias WebRTC ne passent pas par cette inspection HTTP.
- Limiter connexion et requêtes par endpoint ; répondre aux refus avec des statuts HTTP adaptés, comme 403 ou 429.
- Tenir compte de WebSockets et de la synchronisation : des délais globaux inadaptés ne doivent pas couper les connexions longues légitimes.
- Utiliser des filtres Fail2ban personnalisés pour reconnaître les abus et bloquer le vrai client à un endroit efficace.
Tokens et mots de passe restent hors des logs. Les événements techniques centralisés rapprochent accès web, Synapse et démarrage des médias. Une connexion réussie seule ne prouve pas qu’un appel fonctionne.
Tester aussi l’exploitation
| Test contrôlé | Ce qui doit fonctionner |
|---|---|
| Appel depuis un autre réseau | Signalisation, audio, vidéo et TURN si nécessaire. |
| Requête admin ou token non autorisée | Refus au bon endroit, même avec des en-têtes IP falsifiés. |
| Panne d’un service | Évaluer séparément messages, connexion et appels en cours. |
| Restauration | Inclure base, médias et clés nécessaires, puis tester les parcours réels. |
Mises à jour, rétention limitée des logs et sauvegardes testées comptent autant que l’installation. Je simule les pannes virtuellement ; cela ne remplace pas des sites physiques séparés. Une instance Synapse supplémentaire ne rend pas automatiquement base et médias hautement disponibles.
Conclusion
Ces services font partie de l’exploitation quotidienne. Pour moi, chat et appels doivent fonctionner, les accès rester limités et les incidents pouvoir être diagnostiqués et résolus.
Références techniques: Synapse reverse proxy · Matrix E2EE · LiveKit deployment · lk-jwt · Fail2ban · Zero Trust: NIST SP 800-207 · ModSecurity / OWASP CRS