SWAG, mon reverse proxy 🔒 Auto-Reload, Recaptcha, Accès Int/Ext, Géoblocage... (09/XX)

En bref

Prérequis	SWAG installé (épisode précédent), CrowdSec configuré, AdGuard Home comme DNS/DHCP
Résultat	SWAG qui se recharge automatiquement, captcha CrowdSec fonctionnel, règles réseau internes/externes, géoblocage actif
Ressources	Securing SWAG — virtualize.link

---

Cet épisode est le neuvième de la série sur mon reverse proxy SWAG. Quatre sujets abordés, par ordre de complexité croissante.

Rappel rapide : à quoi sert un reverse proxy

Pour les gens qui ne connaissent pas encore : un reverse proxy, c’est un guichet d’entrée unique pour tous vos services auto-hébergés. Plutôt que d’exposer chaque service individuellement sur internet — avec tout ce que ça implique en termes de sécurisation individuelle — on centralise tout derrière SWAG, qui gère pour vous la sécurisation des accès.

SWAG s’occupe de :

• La gestion des certificats HTTPS
• L’authentification des utilisateurs (avec Authelia, SSO, multifacteur)
• L’analyse comportementale avec CrowdSec pour détecter et bannir les IP suspectes
• La centralisation des logs

Chez moi, Homepage sert de page d’accueil qui liste tous mes services : Nextcloud pour les fichiers et photos, Jellyfin pour les vidéos et musique, Duplicati pour les sauvegardes, LibreSpeed pour les tests de débit, File Browser pour manipuler des fichiers, Vaultwarden pour les mots de passe. Plus la couche domotique avec Jeedom, Home Assistant, et AdGuard Home pour le DNS/DHCP.

Tout ça tourne sur une machine qui fait tourner Open MediaVault avec Docker par-dessus.

Point 1 — Auto-reload natif dans SWAG

C’est la nouveauté la plus directement utile de cet épisode.

Depuis SWAG v3.1.0-ls356 (publiée mi-janvier 2025), l’auto-reload est intégré directement dans l’image de base. Ce n’était pas le cas avant — il fallait utiliser un Docker mod séparé, que j’avais d’ailleurs mentionné dans une vidéo précédente. Ce mod est maintenant déprécié (deprecation notice dans le README de l’image), remplacé par la fonctionnalité native.

Concrètement, l’auto-reload surveille tous les fichiers sous config/nginx/ (probablement via inotify en interne) et déclenche automatiquement un rechargement de la configuration nginx à chaque modification. Plus besoin de faire docker compose restart swag après avoir modifié un fichier .conf.

Pour l’activer, deux variables d’environnement à ajouter dans le docker-compose de SWAG :

environment:
  - SWAG_AUTORELOAD=true
  - SWAG_WATCH_LIST=  # optionnel, personnalisable

Par défaut SWAG_AUTORELOAD=false, donc si vous ne le mettez pas, rien ne change.

Démonstration en direct : j’ai renommé le fichier librespeed.subdomain.conf en .backup — SWAG a immédiatement détecté le déplacement et rechargé sa configuration. En rafraîchissant la page LibreSpeed, le service était déjà inaccessible, remplacé par la page 404 par défaut de mon reverse proxy. Pareil dans l’autre sens : modifier le fichier déclenche un rechargement visible dans les logs avec un modify suivi d’un rechargement.

Mise en garde importante : je conseille de désactiver l’auto-reload en production une fois les services stables. En phase de mise en place ou d’expérimentation, c’est super pratique. Mais si on modifie un fichier par inadvertance et que ça déclenche un rechargement avec une configuration incorrecte, ça peut rendre des services momentanément inaccessibles. Pire : si on décommente des lignes de protection Authelia par erreur, on peut se retrouver à exposer des services non sécurisés sur internet sans s’en rendre compte immédiatement.

La bonne pratique en production : faire toutes ses modifications, les passer en revue avec VS Code pour vérifier l’ensemble des changements, puis faire un seul rechargement intentionnel.

Point 2 — reCAPTCHA CrowdSec enfin fonctionnel

La remediation par captcha était une fonctionnalité que j’avais essayé de configurer il y a longtemps, mais elle ne fonctionnait pas correctement à cause de bugs de compatibilité entre les dépendances Lua de nginx (utilisées par SWAG) et le module CrowdSec. Deux bugs en particulier me posaient problème :

1. Une erreur critique au démarrage de SWAG, ouverte par Giovanni Papini — corrigée il y a peu
2. Des warnings de dépréciation autour de la cryptographie dans les images nginx — moins critique mais embêtant

Ces incompatibilités entre les dépendances Lua de SWAG et CrowdSec faisaient que le captcha était activable sur le papier mais inopérant en pratique. Les deux problèmes sont maintenant résolus.

Comment ça fonctionne : CrowdSec peut prendre deux types de décisions face à une IP suspecte — le ban direct, ou le captcha. Le captcha présente un challenge Google reCAPTCHA à l’IP concernée : si c’est un humain, il résout le challenge et passe ; si c’est un bot, il ne peut pas.

La configuration du captcha remediation se fait dans le fichier de profil CrowdSec. On ajoute une entrée captcha remediation avant l’entrée de ban standard, avec des conditions pour décider quand l’appliquer. L’idée : si une IP a déclenché un scénario HTTP et que c’est sa première alerte, on lui présente d’abord un captcha pendant 4 heures. Si elle le résout, elle est libérée. Sinon, elle reste bloquée, et les alertes suivantes peuvent déclencher un ban direct.

Démonstration : j’ai ajouté manuellement une décision captcha sur mon adresse IP locale via cscli decisions add --ip X.X.X.X --type captcha --duration 1h. En retournant sur ma page Homepage, tous les services sont passés au rouge, et j’avais bien un Google reCAPTCHA qui s’affichait. Après avoir cliqué (Google a détecté une activité humaine, pas de challenge d’images à résoudre), j’étais débanni. J’ai aussi reçu une notification par mail, puisque j’ai configuré les notifications CrowdSec par email — utile pour être informé des bannissements sans avoir à surveiller activement.

Point 3 — Différenciation accès interne / externe

Cette configuration n’est pas dans les templates par défaut de SWAG. Je l’ai mise en place sur ma machine à ma sauce, en m’inspirant d’un blog que je n’ai malheureusement pas retrouvé pour le citer correctement.

Le principe : chaque fichier de configuration de service dans nginx/proxy-confs/ peut avoir deux blocs de règles d’accès — un pour le réseau interne, un pour l’accès externe depuis internet. Ça permet d’appliquer des règles de sécurité différentes selon l’origine.

Le contexte réseau chez moi : ma Livebox est le routeur, mais AdGuard Home est le serveur DNS/DHCP. Dans AdGuard Home, j’ai des réécritures DNS : mes noms de domaine publics (monservice.mondomaine.fr) redirigent vers l’IP locale de mon serveur reverse proxy quand on est sur mon réseau local. Résultat : que je sois chez moi ou dehors, j’utilise les mêmes URLs. Mais quand je suis chez moi, le trafic passe en local directement — pas besoin de sortir sur internet pour atteindre mes services.

Deux fichiers de configuration à créer dans le dossier nginx/ :

internal.conf — valide uniquement si la requête vient d’une IP du réseau local : il faut y déclarer la plage d’adresses autorisées (ex. 192.168.1.0/24) avec un allow, suivi d’un deny all pour tout le reste.

external.conf — valide pour les accès depuis internet, avec gestion du géoblocage : il faut y tester la variable $geo_blacklist et retourner une 404 si elle vaut yes.

Dans chaque fichier .conf de service, j’ajoute ensuite un bloc selon que le service est exposé en interne uniquement, en externe uniquement, ou dans les deux cas. Pour LibreSpeed par exemple, ça n’a aucun sens de l’exposer sur internet — je fais mes tests de débit en interne. Je le configure donc en internal uniquement.

L’avantage de cette approche : tout est centralisé dans le fichier de config du service, visible d’un seul coup d’œil. Et si un jour je veux exposer un service qui n’était qu’interne, je change juste le bloc dans le fichier .conf correspondant — avec l’auto-reload, c’est actif immédiatement.

Point 4 (bonus) — Géoblocage avec DB-IP

Le docker mod DB-IP enrichit SWAG avec une base de données de géolocalisation des adresses IP. On peut ensuite configurer nginx pour rejeter automatiquement les requêtes provenant de certains pays.

Activation dans le docker-compose : dans la variable DOCKER_MODS, on ajoute le module linuxserver/mods:swag-dbip à la suite des autres mods déjà présents (swag-dashboard, swag-crowdsec).

Configuration en deux étapes :

1. Dans nginx/nginx.conf, dans le bloc HTTP : on ajoute un include vers le fichier dbip.conf.

2. Dans dbip.conf (fourni par le docker mod), on liste les pays à bloquer : le bloc geo associe la variable $geo_blacklist à une valeur yes pour chaque code ISO 3166-1 des pays à bloquer, et à no pour les plages d’IP locales (qui ne sont jamais géolocalisables).

Pour les adresses IP locales (192.168.x.x), il n’y a pas de géolocalisation possible — elles sont toujours en no donc toujours autorisées. C’est la raison pour laquelle cette configuration s’articule avec le point 3 : en interne, on vérifie que c’est bien une IP locale ; en externe, on vérifie que le pays n’est pas bloqué.

Dans mon cas, j’ai déjà une liste de pays bloqués qui me paraissent ne pas avoir de raison légitime d’accéder à mes services personnels. Je pense même à rajouter les États-Unis — je suis régulièrement scanné depuis des IPs américaines, et il n’y a aucune raison qu’un américain inconnu accède à mes données personnelles auto-hébergées.

En pratique, quel niveau activer ?

Pour synthétiser ce que j’ai en production :

• Auto-reload : activé uniquement quand j’ajoute ou modifie des services, désactivé le reste du temps
• reCAPTCHA CrowdSec : activé en permanence — c’est maintenant stable, autant l’avoir
• Internal/External : activé en permanence, sur tous les services
• DB-IP : activé en permanence avec une liste de pays bloqués

Ce sont des couches complémentaires. Chacune apporte quelque chose, et l’ensemble forme une protection assez solide pour un serveur personnel auto-hébergé.

La série sur SWAG continuera — il y a encore des sujets à couvrir pour compléter l’installation.