Il y a 389 articles et 19 utilisateurs inscrits (ce bandeau est défini dans MediaWiki:Sitenotice)
Matomo/HAProxy
Publication et sécurisation de Matomo avec HAProxy
[modifier | modifier le wikicode]Objectif
[modifier | modifier le wikicode]Cette procédure décrit la publication d'une instance Matomo derrière les répartiteurs HAProxy d'AJLSM.
Elle permet de :
- Publier Matomo en HTTPS.
- Autoriser les requêtes de collecte des statistiques provenant des visiteurs.
- Réserver l'interface d'administration aux adresses IP autorisées.
- Déployer une configuration identique sur les deux HAProxy à l'aide d'Ansible.
- Vérifier le fonctionnement depuis une connexion extérieure.
Cette procédure complète :
1. Architecture
[modifier | modifier le wikicode]Dans l'infrastructure AJLSM, le trafic suit généralement le chemin suivant :
Navigateur du visiteur
|
| HTTPS
v
HAProxy (haproxy-01 / haproxy-02)
|
| HTTPS ou HTTP interne
v
VM applicative
|
v
Apache + PHP-FPM + Matomo
|
v
MariaDB
Le navigateur charge le JavaScript Matomo et transmet les données de fréquentation au serveur Matomo.
Important : la collecte des statistiques doit fonctionner pour les visiteurs extérieurs, même lorsque l'interface d'administration Matomo est réservée à AJLSM.
2. Prérequis
[modifier | modifier le wikicode]Avant de modifier HAProxy, vérifier :
- Que Matomo fonctionne sur la VM applicative.
- Que le VirtualHost Apache est configuré.
- Que le nom DNS public de Matomo est défini.
- Que le certificat HTTPS public est disponible sur HAProxy.
- Que le backend Matomo est joignable depuis les répartiteurs.
- Que l'adresse IP ou le réseau autorisé pour l'administration est connu.
La configuration HAProxy est gérée par Ansible. Les modifications doivent être réalisées dans les fichiers sources du dépôt `ansible-ajlsm`, et non directement dans `/etc/haproxy/haproxy.cfg` sur les serveurs.
3. Paramètres à personnaliser
[modifier | modifier le wikicode]Pour chaque nouvelle installation, identifier les paramètres suivants :
| Paramètre | Exemple | Description |
|---|---|---|
| Domaine Matomo | matomo.exemple.fr | Nom DNS public de Matomo |
| Backend | back_ssl_projet_matomo | Nom du backend HAProxy |
| Adresse de la VM | 10.0.0.X | Adresse privée de la VM hébergeant Matomo |
| Port backend | 443 | Port HTTPS interne, si utilisé |
| ACL des administrateurs | allowed_ajlsm | Adresses IP autorisées à accéder à l'interface |
4. Configuration des ACL
[modifier | modifier le wikicode]Principe
[modifier | modifier le wikicode]Deux chemins sont nécessaires au suivi Matomo standard :
- `/matomo.js` : chargement du JavaScript de suivi.
- `/matomo.php` : réception des données de fréquentation.
Ces deux chemins doivent rester accessibles publiquement.
Les autres chemins de l'interface Matomo sont réservés aux adresses IP autorisées.
Exemple générique
[modifier | modifier le wikicode]Ajouter les règles suivantes dans le frontend HAProxy approprié :
# MATOMO - PROJET
acl host_projet_matomo hdr(host),host_only -i matomo.exemple.fr
# Ressources de collecte accessibles publiquement
acl projet_matomo_tracking path -i /matomo.js /matomo.php
# Interface Matomo réservée à AJLSM
http-request deny if host_projet_matomo !allowed_ajlsm !projet_matomo_tracking
# Redirection HTTP vers HTTPS
http-request redirect scheme https if host_projet_matomo !{ ssl_fc }
# Routage vers le backend Matomo
use_backend back_ssl_projet_matomo if host_projet_matomo
Attention : cet exemple utilise l'ACL `allowed_ajlsm` déjà présente dans l'infrastructure AJLSM. Vérifier son existence et son contenu avant de déployer la configuration.
L'ACL `path -i` effectue une correspondance exacte des chemins. Elle ne rend pas accessibles les autres pages de l'administration Matomo.
Cette configuration est adaptée au suivi JavaScript standard. Si des fonctionnalités supplémentaires nécessitent d'autres points d'accès, leurs chemins doivent être étudiés séparément avant toute ouverture.
5. Configuration du backend
[modifier | modifier le wikicode]Exemple HTTPS
[modifier | modifier le wikicode]backend back_ssl_projet_matomo
server SSLPROJETMATOMO 10.0.0.X:443 check ssl verify none sni str(matomo.exemple.fr)
Remplacer l'adresse IP, le nom du serveur et le nom de domaine par les paramètres du projet.
Sécurité : `verify none` désactive la vérification du certificat présenté par le backend. Cette configuration existe sur AD64, mais ne doit pas être considérée comme une recommandation générale.
Pour une nouvelle installation, privilégier une validation TLS du backend avec une autorité de certification appropriée lorsque l'architecture le permet.
Backend HTTP
[modifier | modifier le wikicode]Un backend HTTP peut également être utilisé sur un réseau interne maîtrisé :
backend back_projet_matomo
server PROJETMATOMO 10.0.0.X:80 check
Le choix entre HTTP et HTTPS interne dépend de l'architecture du projet et des exigences de sécurité.
6. Certificats HTTPS
[modifier | modifier le wikicode]Dans l'infrastructure AJLSM, les certificats publics HAProxy peuvent être gérés par `acme.sh`.
Sur les serveurs HAProxy concernés, vérifier :
- L'existence du certificat pour le domaine Matomo.
- Sa date d'expiration.
- La configuration de renouvellement automatique.
- Le mécanisme de déploiement du certificat dans HAProxy.
Exemple de vérification depuis un poste client :
openssl s_client \
-connect matomo.exemple.fr:443 \
-servername matomo.exemple.fr </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
La présence d'une tâche automatique de renouvellement ne garantit pas à elle seule que le déploiement d'un nouveau certificat fonctionnera. Le renouvellement et le rechargement effectif du certificat doivent être contrôlés.
7. Déploiement avec Ansible
[modifier | modifier le wikicode]Voir aussi la configuration du WAF avec ansible : WAF 2026
Modification
[modifier | modifier le wikicode]Depuis le Mac d'administration :
- Ouvrir le dépôt `ansible-ajlsm`.
- Modifier la configuration HAProxy dans les sources Ansible.
- Ajouter les ACL et le routage du nouveau domaine Matomo.
- Vérifier que les backends sont définis.
- Ne pas modifier directement les configurations générées sur les deux serveurs.
Vérification de la syntaxe du playbook
[modifier | modifier le wikicode]ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --syntax-check
Simulation du déploiement
[modifier | modifier le wikicode]ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --check --diff
Vérifier :
- Que les modifications sont identiques sur les deux HAProxy.
- Que seuls les blocs attendus changent.
- Qu'aucune configuration d'un autre client n'est modifiée.
- Qu'aucune erreur n'est signalée.
Important : le mode `--check` est une simulation. Il ne garantit pas à lui seul le succès du déploiement réel ni le comportement des ACL en production.
Déploiement réel
[modifier | modifier le wikicode]ansible-playbook -i inventory ./plays/deploy.haproxy.yml \
--limit ajlsm_loadbalancer --diff
Vérifier le résultat du playbook sur les deux serveurs.
Si le playbook prévoit un redémarrage ou un rechargement HAProxy, contrôler ensuite que les services restent actifs et que les applications existantes répondent normalement.
8. Vérification depuis une connexion extérieure
[modifier | modifier le wikicode]Important : effectuer les tests depuis une connexion qui n'utilise ni l'adresse IP publique du bureau ni le VPN AJLSM.
Une connexion autorisée ne permet pas de vérifier correctement le refus d'accès à l'administration.
Tester les ressources de suivi
[modifier | modifier le wikicode]MATOMO_URL="https://matomo.exemple.fr"
for RESOURCE in matomo.js matomo.php; do
echo "===== /$RESOURCE ====="
curl -sS -o /dev/null -w "HTTP %{http_code}\n" \
"$MATOMO_URL/$RESOURCE"
done
Résultats attendus pour l'installation standard :
| Ressource | Résultat attendu |
|---|---|
| /matomo.js | HTTP 200 |
| /matomo.php | Accessible sans HTTP 403 HAProxy |
Remarque : une réponse HTTP 200 de `matomo.php` sans paramètres de suivi ne constitue pas une preuve de collecte effective.
Tester la protection de l'administration
[modifier | modifier le wikicode]curl -sS -o /dev/null -w "HTTP %{http_code}\n" \
"$MATOMO_URL/"
Résultat attendu depuis une adresse IP extérieure non autorisée :
HTTP 403
Tester depuis une adresse autorisée
[modifier | modifier le wikicode]Depuis le réseau AJLSM ou un accès VPN autorisé, vérifier que l'interface Matomo reste accessible et que l'authentification Matomo fonctionne.
9. Vérification de la collecte
[modifier | modifier le wikicode]Une fois les règles HAProxy appliquées :
- Ouvrir une application Drupal ou Pleade suivie par Matomo.
- Naviguer sur plusieurs pages publiques.
- Vérifier l'envoi des requêtes de suivi dans les outils réseau du navigateur.
- Vérifier l'apparition des visites dans l'interface Matomo.
Pour une vérification directe en base :
SELECT
idsite,
COUNT(*) AS visites,
MAX(visit_last_action_time) AS derniere_activite
FROM matomo_log_visit
GROUP BY idsite;
Cette requête doit être exécutée dans la base Matomo avec un compte disposant des droits nécessaires.
Voir Matomo/Drupal et Matomo/Debug.
10. Exemple validé : AD64 — octobre 2026
[modifier | modifier le wikicode]Environnement
[modifier | modifier le wikicode]| Élément | Valeur |
|---|---|
| Serveur Matomo | ad64 |
| Domaine | ad64-matomo.pleade.com |
| Adresse privée de la VM | 10.0.0.41 |
| Backend HTTPS | back_ssl_ad64_matomo |
| Répartiteurs | haproxy-01 et haproxy-02 |
| Applications suivies | Drupal Internet et Drupal Salle de lecture |
Configuration HAProxy
[modifier | modifier le wikicode]# AD64 MATOMO
acl host_ad64_matomo hdr(host),host_only -i ad64-matomo.pleade.com
# Points de collecte accessibles publiquement
acl ad64_matomo_tracking path -i /matomo.js /matomo.php
# Administration réservée à AJLSM
http-request deny if host_ad64_matomo !allowed_ajlsm !ad64_matomo_tracking
http-request redirect scheme https if host_ad64_matomo !{ ssl_fc }
use_backend back_ssl_ad64_matomo if host_ad64_matomo
Backend HTTPS existant :
backend back_ssl_ad64_matomo
server SSLAD64MATOMO 10.0.0.41:443 check ssl verify none sni str(ad64-matomo.pleade.com)
L'ancien backend HTTP `back_ad64_matomo` a été conservé sans modification, bien qu'il ne soit plus utilisé par ce routage.
Résultats des tests
[modifier | modifier le wikicode]Les vérifications réalisées le 20 octobre 2026 depuis une connexion extérieure au bureau ont donné :
| Test | Résultat |
|---|---|
| https://ad64-matomo.pleade.com/matomo.js | HTTP 200 |
| https://ad64-matomo.pleade.com/matomo.php | HTTP 200 |
| https://ad64-matomo.pleade.com/ | HTTP 403 |
Les visites Drupal Internet et Salle de lecture avaient également été enregistrées dans MariaDB, avec les identifiants Matomo 2 et 3.
La collecte et la restriction d'accès ont donc été vérifiées.
11. Points de vigilance
[modifier | modifier le wikicode]- Ne jamais ouvrir toute l'interface Matomo à Internet uniquement pour permettre la collecte.
- Ne pas autoriser systématiquement les adresses IP du client à accéder à l'administration.
- Ne pas bloquer les points de collecte nécessaires aux visiteurs.
- Ne pas modifier directement les fichiers HAProxy générés par Ansible.
- Tester depuis une véritable connexion extérieure.
- Vérifier le certificat HTTPS et son renouvellement.
- Vérifier que la collecte réelle fonctionne, au-delà du simple chargement du JavaScript.
12. Maintenance et diagnostic
[modifier | modifier le wikicode]En cas d'anomalie, vérifier successivement :
- La résolution DNS du domaine Matomo.
- Le certificat HTTPS présenté par HAProxy.
- La correspondance de l'ACL `host`.
- Les règles `http-request deny`.
- Les chemins autorisés pour le suivi.
- L'état du backend HAProxy.
- La disponibilité d'Apache et PHP-FPM sur la VM.
- La réception effective des visites dans Matomo.
Voir Matomo/Debug et Matomo/Maintenance.