Comment déployer SafeLine WAF sur un VPS Linux

Les applications web exposées sur Internet sont régulièrement sondées à la recherche d'injections SQL, d'abus d'identifiants et de schémas de vulnérabilités connues. SafeLine est un WAF auto-hébergé sous licence GPL-3.0 qui s'exécute sous forme de stack Docker Compose et filtre le trafic HTTP/S avant de transmettre les requêtes autorisées à l'origine. Son plan Personal gratuit prend en charge jusqu'à 10 applications.

Ce tutoriel couvre l'installation et trois points qui méritent une attention particulière : le choix de l'architecture de reverse proxy, la configuration du réseau Docker lorsque SafeLine se trouve derrière un proxy existant comme Nginx Proxy Manager, et une commande de vérification à exécuter après l'installation pour confirmer que le WAF intercepte réellement les attaques.

La version courte

• Installez SafeLine sur un VPS Linux avec Docker Compose. Utilisez l'installateur en une ligne, ou empruntez la voie manuelle Docker Compose pour inspecter la définition Compose et la configuration de l'environnement avant de démarrer la stack.
• Choisissez l'architecture de reverse proxy avant l'installation : SafeLine comme seul proxy, SafeLine derrière un Nginx Proxy Manager existant, ou SafeLine partageant la machine avec Caddy. Chaque configuration nécessite des affectations de ports et des réglages X-Forwarded-For différents.
• Après l'installation, vérifiez le WAF en envoyant une sonde d'injection SQL via curl vers l'URL protégée. En mode Balanced ou Strict, une réponse 403 accompagnée d'une entrée correspondante dans Attack Events confirme le blocage. En mode Monitor, l'événement correspondant confirme la détection même si la réponse reste un succès.
• Le palier Personal gratuit couvre jusqu'à 10 applications et le moteur de détection principal. Le géoblocage, l'export des journaux d'attaques et les notifications externes nécessitent le palier Lite ; une détection d'attaques plus poussée et la répartition de charge nécessitent Pro.

Avant de commencer : prérequis et contenu de ce tutoriel

Ce tutoriel suppose que vous disposez d'un VPS Linux accessible en SSH avec un accès root ou sudo, et que Docker est installé. Vous repartirez avec une instance SafeLine fonctionnelle protégeant au moins un site et une commande de vérification que vous pourrez relancer à tout moment.

Il vous faut :

• Un VPS Linux. Les commandes ci-dessous supposent un système de type Debian ou Ubuntu avec systemd ; vérifiez les noms des paquets et des services sur les autres distributions.
• Au moins 1 vCPU, 1 GB RAM et 5 GB de disque selon les prérequis de déploiement officiels. Pour une marge de manœuvre confortable en production, ce guide recommande 2 vCPU, 4 GB RAM et 20 GB de disque.
• Docker 20.10.14 ou version ultérieure et Docker Compose 2.0 ou version ultérieure.
• Un CPU x86_64 prenant en charge SSSE3 ; vérifiez-le avec lscpu | grep ssse3 plutôt que de supposer que l'instruction est présente.
• Un domaine ou sous-domaine dont le DNS pointe vers l'IP publique du VPS si vous prévoyez d'exposer l'application protégée en HTTPS public.
• Des ports adaptés à la topologie choisie. Les configurations A et C attribuent normalement les ports 80 et 443 à SafeLine, tandis que la configuration B laisse ces ports à Nginx Proxy Manager et affecte à SafeLine un écouteur différent tel que 10080.
• Un accès root ou sudo.

Au niveau du pare-feu ou du groupe de sécurité du fournisseur de VPS, n'exposez que les ports publics dont la topologie choisie a besoin. Restreignez SSH et TCP 9443 à des sources d'administration de confiance. Dans la configuration B, gardez TCP 10080 fermé aux IPv4 et IPv6 publiques, et gardez les ports backend tels que 8080 privés dans toutes les topologies. Un accès direct à 10080 contournerait NPM et invaliderait la frontière de confiance X-Forwarded-For.

Remarque : Pour un déploiement manuel ARM64, définissez ARCH_SUFFIX=-arm. La documentation de déploiement officielle de SafeLine indique qu'ARM nécessite une licence Pro et que l'édition Personal n'est pas prise en charge sur ARM. Utilisez un VPS x86_64 pour l'édition Personal.

Vérifiez Docker avant de commencer :

docker --version
docker compose version

Les deux commandes doivent renvoyer les versions installées. Ne continuez que si Docker est en version 20.10.14 ou ultérieure et Docker Compose en version 2.0.0 ou ultérieure ; sinon, mettez à niveau avant d'installer SafeLine.

Choisissez d'abord votre architecture de reverse proxy

Un VPS vierge permet à SafeLine de s'approprier directement les ports 80 et 443. Un VPS qui exécute déjà Nginx Proxy Manager, Caddy ou le propre Nginx de l'application ne le permet pas, et le choix de l'architecture fait toute la différence entre une installation sans accroc et un conflit de ports au premier démarrage. Réglez ce point une bonne fois au départ et le reste du déploiement est mécanique.

Les trois configurations :

• Configuration A, SafeLine comme unique reverse proxy. SafeLine possède les ports 80 et 443 et gère TLS pour l'application protégée. Les versions CE actuelles incluent un workflow Free Cert, tandis que le téléversement manuel de certificats reste disponible ; vérifiez les options de certificat exactes dans la version installée. Le backend s'exécute sur un port non public et SafeLine y achemine le trafic.
• Configuration B, SafeLine derrière Nginx Proxy Manager (NPM). NPM conserve les ports 80 et 443 et gère SSL. SafeLine écoute sur le port 10080 (HTTP uniquement, puisque NPM a déjà terminé TLS). NPM transmet vers SafeLine ; SafeLine transmet vers le backend. C'est une configuration courante lorsque NPM est déjà déployé.
• Configuration C, SafeLine aux côtés de Caddy. Le HTTPS automatique de Caddy entre en concurrence avec SafeLine pour le port 443. Un agencement fonctionnel attribue les ports 80 et 443 à SafeLine et déplace Caddy vers un port HTTP interne non public tel que 8080 pour le trajet SafeLine vers Caddy vers application.

Point clé : La configuration A est la plus simple pour un VPS vierge ; la configuration B est le bon choix lorsque NPM tourne déjà ; la configuration C nécessite une réaffectation délibérée des ports de Caddy.

Installer SafeLine sur votre VPS

L'installation en elle-même est la partie facile. SafeLine propose deux méthodes d'installation : un installateur automatisé qui récupère un script distant depuis waf.chaitin.com, et une méthode manuelle Docker Compose qui vous permet de tout inspecter avant l'exécution. Choisissez celle qui correspond à votre politique de sécurité.

Étape 1 : confirmer que Docker est prêt

Revérifiez la version de Docker et que le daemon Docker est en cours d'exécution :

docker --version
docker compose version
sudo systemctl status docker

La sortie attendue inclut active (running) pour le daemon Docker. S'il n'est pas en cours d'exécution, démarrez-le avec sudo systemctl start docker et activez-le au démarrage avec sudo systemctl enable docker.

Étape 2 : exécuter l'installateur SafeLine

Il existe deux sous-méthodes. Choisissez-en une.

Étape 2a, installation automatisée. Exécutez l'installateur avec les privilèges root :

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Le script demande où placer le répertoire de données de SafeLine, récupère les images Docker et démarre la stack. Après l'installation, exécutez sudo docker exec safeline-mgt resetadmin pour récupérer ou réinitialiser les identifiants administrateur, comme décrit dans le guide de déploiement officiel. Conservez les identifiants obtenus en lieu sûr.

Remarque : Cette commande télécharge et exécute un script shell distant depuis waf.chaitin.com en tant que root. La commande officielle en une ligne inclut curl -k, qui désactive la vérification des certificats TLS. Examinez le script téléchargé avant de l'exécuter, ou utilisez l'étape 2b si ce risque est inacceptable. SafeLine est également disponible sous forme de déploiement Cloudzy en un clic, mais cette image utilise /opt/safeline, /opt/safeline/.env, et /opt/safeline/docker-compose.yml. N'utilisez pas les /data/safeline chemins de ce guide tels quels sur l'image Cloudzy.

Étape 2b, installation manuelle avec Docker Compose. Téléchargez et inspectez le fichier Compose officiel, puis démarrez la stack :

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Après avoir docker compose up -d est terminé, listez les conteneurs en cours d'exécution pour confirmer :

sudo docker compose ps

Vous devriez voir des conteneurs pour safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi et safeline-chaos. Si un conteneur affiche Exited, consultez l'étape 3 pour les deux causes les plus fréquentes.

Étape 3 : résoudre les erreurs d'installation courantes

Deux erreurs reviennent assez souvent pour mériter leur propre étape.

Chevauchement de sous-réseau. Si l'installation échoue avec Pool overlaps with other one on this address space, le sous-réseau SafeLine par défaut entre en conflit avec un réseau Docker existant. Comme le documente un guide de dépannage de l'installation de SafeLine, corrigez cela en modifiant /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Erreur du résolveur IPv6. Si safeline-tengine plante avec nginx: [emerg] invalid IPv6 address in resolver, inspectez d'abord le fichier du résolveur et déterminez qui le gère :

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Ne modifiez pas /etc/resolv.conf directement s'il est généré par systemd-resolved, NetworkManager ou le fournisseur de VPS. Corrigez la valeur nameserver mal formée dans la configuration du service gestionnaire, régénérez le fichier du résolveur, puis redémarrez Tengine :

sudo docker restart safeline-tengine

Étape 4 : accéder au tableau de bord

Le tableau de bord d'administration de SafeLine écoute sur TCP 9443 en HTTPS. Ne laissez pas ce port d'administration ouvert à tout Internet. Restreignez-le à une adresse source de confiance ou à un VPN, ou bloquez l'accès public et utilisez un tunnel SSH :

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Ouvrez https://localhost:9443 à travers le tunnel. Un avertissement de certificat auto-signé est attendu au premier accès ; vérifiez que la connexion SSH a bien atteint le serveur voulu avant de poursuivre.

Si vous avez perdu les identifiants initiaux, réinitialisez le mot de passe admin depuis l'hôte :

sudo docker exec safeline-mgt resetadmin

La commande affiche des identifiants administrateur que vous pouvez utiliser pour vous reconnecter.

Configurer SafeLine pour votre architecture

SafeLine tourne désormais, mais il ne protège encore rien. La page Applications du tableau de bord est l'endroit où vous indiquez à SafeLine quels sites protéger et où transmettre le trafic nettoyé. La configuration diffère selon l'architecture que vous avez choisie plus tôt, c'est pourquoi chaque configuration a sa propre sous-section. Ne traitez que celle qui correspond à votre installation.

Configuration A : SafeLine comme unique reverse proxy

Pour la configuration A, SafeLine écoute directement sur les ports 80 et 443 et transmet le trafic nettoyé à votre application backend sur un port non public. Dans le tableau de bord :

1. Accédez à Applications, puis Ajouter une application.
2. Définissez le port d'écoute sur 443 et activez SSL. Utilisez le workflow de certificat disponible dans la version de SafeLine que vous avez installée. Les versions CE actuelles incluent la demande et le renouvellement Free Cert, tandis que le téléversement manuel de certificats reste disponible.
3. Définissez l'upstream sur http://127.0.0.1:8080. Si le backend s'exécute dans Docker, ne publiez son port que sur la boucle locale, par exemple "127.0.0.1:8080:8080" dans la section ports du service. Évitez une IP de conteneur codée en dur telle que 172.17.0.5 car elle peut changer lorsque le conteneur est recréé.
4. Enregistrez l'application. SafeLine se met immédiatement à écouter sur 443 et à transmettre le trafic nettoyé au backend.
5. Vérifiez que l'enregistrement DNS A de votre domaine pointe vers l'IP publique du VPS et que les ports 80 et 443 sont accessibles depuis l'extérieur.

Si le port 443 était déjà occupé par un autre processus, le conteneur SafeLine ne parviendra pas à s'y attacher et le tableau de bord affichera une erreur sur cette application. Arrêtez le processus en conflit, ou choisissez un autre port, avant d'ajouter l'application.

Configuration B : SafeLine derrière Nginx Proxy Manager

La configuration B laisse NPM faire ce qu'il fait déjà (posséder 80 et 443, gérer Let's Encrypt) et insère SafeLine derrière lui comme couche de sécurité dédiée. Le flux du trafic est le suivant : client, puis NPM (port 443, terminaison TLS), puis SafeLine (port 10080, HTTP), puis l'application backend.

Dans le tableau de bord SafeLine :

1. Applications, puis Ajouter une application. Définissez le port d'écoute sur 10080 et laissez SSL désactivé (NPM a déjà terminé TLS).
2. Définissez l'upstream sur l'adresse interne de l'application, comme décrit dans la configuration A.
3. Enregistrez l'application.

Dans Nginx Proxy Manager :

1. Hosts, puis Proxy Hosts, puis Add Proxy Host.
2. Onglet Details : définissez le nom de domaine, le schéma http, et le port de transfert 10080. Si NPM s'exécute directement sur l'hôte, utilisez 127.0.0.1 comme nom d'hôte de transfert. Si NPM s'exécute dans Docker sur Linux, 127.0.0.1 pointe vers le conteneur NPM plutôt que vers l'hôte VPS. Ajoutez le mappage host-gateway de Docker au service Compose de NPM, puis utilisez host.docker.internal comme nom d'hôte de transfert :

extra_hosts:
  - "host.docker.internal:host-gateway"

Depuis le répertoire Compose de NPM, exécutez sudo docker compose up -d afin que le conteneur soit recréé avec le nouveau mappage d'hôte.

3. Onglet SSL : demandez un certificat Let's Encrypt, forcez SSL et activez HTTP/2.
4. Laissez l'onglet Advanced de NPM vide pour X-Forwarded-For. Dans le modèle NPM actuel, le contenu Advanced est inséré au niveau du bloc server et ne remplace pas les en-têtes générés au niveau location selon les règles d'héritage de NGINX. Le bloc location généré envoie :

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

La seconde directive ajoute l'adresse observée par NPM comme valeur la plus à droite dans l'en-tête.

5. Enregistrez le Proxy Host.

De retour dans SafeLine, ne configurez l'extraction de l'IP source qu'après avoir confirmé la chaîne d'en-têtes effective. SafeLine 9.3.1 a introduit une extraction XFF flexible avec sélection de la direction et de l'index.

1. Settings, puis Advanced, puis Real IP from Header. Définissez le nom de l'en-tête sur X-Forwarded-For.
2. Utilisez l'extraction personnalisée à partir de la fin de l'en-tête et sélectionnez l'adresse la plus à droite ajoutée par NPM. Les libellés d'index exacts varient selon la version, vérifiez donc le résultat dans Logs, puis Access. Si la version installée est antérieure à 9.3.1, mettez-la à jour avant de suivre cette topologie.
3. Si Cloudflare ou un autre CDN se trouve devant NPM, configurez d'abord NPM pour ne faire confiance qu'aux plages de proxy publiées par ce fournisseur, afin que l'adresse ajoutée par NPM soit fiable. Ne sélectionnez pas de position fixe tant que vous n'avez pas inspecté et testé la chaîne d'en-têtes réelle.
4. Enregistrez et rechargez l'application.

Testez la configuration depuis une machine extérieure au VPS :

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

Le journal d'accès de SafeLine doit afficher votre adresse publique réelle, et non 1.2.3.4 ni l'adresse de pont de NPM.

Empêchez les utilisateurs de contourner SafeLine en gardant l'écouteur backend privé. Pour un backend Docker Compose, ne publiez le port que sur la boucle locale :

ports:
  - "127.0.0.1:8080:8080"

Pour un service s'exécutant directement sur l'hôte, configurez-le pour écouter sur 127.0.0.1:8080 au lieu de 0.0.0.0:8080. Vérifiez les deux ports internes depuis une machine extérieure au VPS :

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

Les connexions TCP doivent être refusées ou expirer. Une erreur HTTP ou « Empty reply from server » signifie tout de même que le port est accessible publiquement et doit être sécurisé. Si la liaison sur la boucle locale est impossible, créez des règles de pare-feu adaptées à l'interface, au réseau Docker et au conteneur de destination réels plutôt que d'appliquer une règle DOCKER-USER générique.

Configuration C : SafeLine avec Caddy

Pour la configuration C, SafeLine prend les ports 80 et 443 ; Caddy passe sur un port HTTP interne non public. Le flux du trafic est le suivant : client, puis SafeLine (443, TLS), puis Caddy (8080, HTTP interne), puis le backend de l'application.

Modifier /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

The :8080 Le bloc site est la partie importante : Caddy écoute désormais sur un port HTTP interne au lieu de se disputer le port 443 avec SafeLine. La bind 127.0.0.1 ligne maintient cet écouteur local au VPS. Rechargez Caddy avec sudo systemctl reload caddy et confirmez avec sudo ss -ltnp | grep -E ':(443|8080)' que Caddy est bien attaché à 8080, et non à 443.

Dans SafeLine, ajoutez une application qui écoute sur 443 avec SSL activé, puis définissez l'upstream sur http://127.0.0.1:8080. Le réglage X-Forwarded-For peut rester sur l'option de connexion réseau par défaut car Caddy est derrière SafeLine, et non devant lui.

Choisir un mode de protection et vérifier que le WAF bloque les attaques

SafeLine dispose de trois modes de protection qui déterminent ce qui se passe lorsque le moteur signale une requête comme malveillante. Le bon mode de départ dépend de l'application ; l'étape de vérification est la même quel que soit le mode.

Modes de protection : Monitor, Balanced, Strict

Chaque application dans SafeLine possède son propre réglage de mode de protection, configurable sous Applications, puis votre application, puis Protection Mode:

• Monitor. SafeLine journalise les requêtes qu'il bloquerait autrement, mais ne les bloque pas. C'est le point de départ le plus sûr pour une application de production complexe comportant des formulaires de saisie riches (un forum, un panneau d'administration avec des champs WYSIWYG, une API acceptant des charges utiles JSON libres). Exécutez Monitor pendant quelques jours, examinez la page Attack Events et confirmez l'absence de faux positifs sur des utilisateurs réels avant de passer à Balanced.
• Balanced. Le mode par défaut. Les chiffres GitHub publiés par l'éditeur de SafeLine font état de 71.65% de détection, 99.45% de précision et 0.07% de taux de faux positifs pour le mode Balanced. Le mode Strict est annoncé à 76.17% de détection, 99.38% de précision et 0.22% de taux de faux positifs. Ce sont des résultats communiqués par l'éditeur et non un benchmark indépendant, et le README n'identifie pas le jeu de données comme WAF-Eval. Considérez-les comme des chiffres produit comparatifs, et non comme une performance de production garantie.
• Strict. Un ensemble de règles plus agressif avec des heuristiques plus strictes et le compromis détection/faux positifs présenté ci-dessus. À essayer après une semaine ou deux de fonctionnement propre en mode Balanced, une fois que vous comprenez votre trafic.

Recommandation : Balanced pour un nouveau déploiement sans trafic réel à perturber. Pour une application de production existante, commencez en Monitor pendant quelques jours, cherchez les faux positifs dans le journal Attack Events, et passez à Balanced une fois que vous avez ajusté les éventuelles exceptions. Strict vaut la peine d'être essayé après une semaine ou deux de Balanced, une fois que vous comprenez votre trafic.

Vérifier le WAF avec un test SQLi via curl

La dernière étape avant de considérer l'installation comme terminée consiste à confirmer que le WAF intercepte réellement une attaque. Lancez une sonde d'injection SQL bénigne contre votre site protégé depuis n'importe quelle machine extérieure au VPS :

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Il s'agit du vecteur de test d'injection SQL publié par SafeLine. En mode Balanced ou Strict, attendez-vous à un statut 403 et à une réponse de blocage de SafeLine. En mode Monitor, attendez-vous à ce que la requête soit journalisée sans blocage. La version HTTP et le corps exact de la réponse peuvent varier, confirmez donc le résultat par une entrée correspondante dans Attack Events.

Ouvrez ensuite le tableau de bord via la méthode d'accès restreint de l'étape 4 et rendez-vous dans Logs, puis Attack Events. Vous devriez voir une nouvelle entrée avec l'horodatage correspondant, le type d'attaque SQL Injection, l'IP source correspondant à la machine depuis laquelle vous avez lancé curl, et la chaîne de requête incriminée dans le détail de la requête. Cliquez sur l'événement pour voir la requête et la réponse complètes capturées par SafeLine.

Si la requête curl a renvoyé 200 OK, interprétez le résultat en le rapprochant du journal Attack Events :

• Un événement SQL Injection correspondant signifie que l'application est probablement en mode Monitor ; la journalisation sans blocage est attendue.
• S'il n'y a aucun événement correspondant, vérifiez que le DNS résout bien vers le VPS voulu, contrôlez la configuration de l'écouteur et de l'upstream de SafeLine, et corrélez l'heure de la requête avec le journal d'accès de SafeLine.
• Confirmez également que la protection est activée et qu'aucune liste blanche d'IP, règle d'autorisation personnalisée ou exception de chemin ne couvre la requête de test.

Point clé : Si la sonde curl renvoie 403 avec la page d'interception de SafeLine et qu'une entrée apparaît dans Attack Events avec le type d'attaque SQL Injection, le WAF intercepte correctement le trafic.

Ce que couvre le palier gratuit et ce qui nécessite un plan payant

Le palier Personal gratuit suffit à protéger la plupart des déploiements sur un seul VPS. Les paliers payants commencent à compter lorsque vous avez besoin de fonctionnalités opérationnelles (notifications, export de journaux, géoblocage) ou lorsque vous dépassez la limite de 10 applications.

Le détail, issu de la page tarifaire de CyberServal:

• Personal, gratuit. Jusqu'à 10 applications. Inclut le moteur de détection sémantique (SQLi, XSS, injection de commandes, traversée de répertoire, SSRF, XXE, CRLF), la limitation de débit, le défi CAPTCHA anti-bot, le chiffrement dynamique HTML/JS contre les scrapers automatisés, les règles ACL web et la gestion des certificats. Les versions CE actuelles incluent également la demande et le renouvellement Free Cert.
• Lite, $10/month ou $100/year. Ajoute le géoblocage, la base de données d'IP de renseignement sur les menaces, l'intégration des notifications Discord et Telegram, l'export des journaux d'attaques, et porte la limite d'applications à 20.
• Pro, $100/month ou $1,000/year. Ajoute une détection d'attaques plus poussée, des configurations par service et globales, des pages d'interception personnalisées, la répartition de charge en amont, la synchronisation de nœuds maître-esclave et des applications illimitées. Consultez la grille tarifaire actuelle pour connaître les évolutions.
• Ultimate, tarification personnalisée. Conditions entreprise sur mesure avec un support individuel sur tous les canaux et le développement de fonctionnalités personnalisées.

SafeLine traite et stocke les données applicatives au sein de sa stack Compose locale. Cependant, les notes de version CE actuelles mentionnent le partage de renseignement sur les menaces (Threat Intelligence Sharing), les opérateurs doivent donc examiner les contrôles UEP, de confidentialité et de partage de la version installée et observer les connexions sortantes avant de considérer le déploiement comme sans trafic sortant.

Pour aller plus loin

L'installation est terminée et le WAF est vérifié. Quelques tâches de suivi vous aideront à maintenir le déploiement en bon état.

• Pour toute application de production avec des saisies utilisateur riches (un forum, un panneau d'administration, une API libre), réglez le mode de protection sur Moniteur pendant trois à sept jours, examinez la page Attack Events chaque jour, et passez à Balanced une fois que vous avez ajusté les éventuels faux positifs.
• Sur le palier Lite, configurez l'intégration des notifications Discord ou Telegram afin que les alertes d'attaque vous parviennent en dehors du tableau de bord.
• Planifiez une fenêtre de maintenance mensuelle. Avant toute mise à niveau, sauvegardez les données et la configuration d'environnement de SafeLine, lisez les notes de version actuelles, et utilisez la procédure de mise à niveau prise en charge pour votre version installée. Ne vous fiez pas uniquement à docker compose pull puis docker compose up -d, car la définition Compose ou les variables d'environnement requises peuvent changer d'une version à l'autre. Les utilisateurs Cloudzy en un clic doivent partir de /opt/safeline et suivre les instructions de l'image du marketplace.
• Abonnez-vous à la page des versions de SafeLine pour les notifications de correctifs de sécurité et au dépôt du projet pour le suivi des problèmes.

Si vous ne disposez pas encore d'un VPS pour ce déploiement, SafeLine est disponible en déploiement en un clic dans La marketplace de Cloudzy. Un forfait avec 4 GB RAM offre la marge pratique recommandée dans ce guide ; vérifiez à nouveau le grille tarifaire actuelle sur Cloudzy au moment de la publication, car les spécifications des forfaits peuvent changer. L'image en un clic utilise /opt/safeline et /opt/safeline/docker-compose.yml, si bien que les instructions d'architecture et de tableau de bord s'appliquent, mais les /data/safeline commandes de ce guide ne s'appliquent pas à l'identique.

Foire aux questions

SafeLine WAF remplace-t-il Nginx Proxy Manager, ou dois-je utiliser les deux ?

SafeLine peut remplacer Nginx Proxy Manager lorsqu'il est déployé comme unique reverse proxy. Cependant, il n'a pas besoin de remplacer NPM. Une configuration courante garde NPM en frontal pour SSL et le routage, et place SafeLine derrière lui comme couche de sécurité dédiée. Les deux fonctionnent ; le choix dépend de si vous voulez un seul outil faisant les deux tâches ou deux outils faisant chacun une tâche correctement.

Le palier gratuit suffit-il pour un seul site WordPress ou un petit SaaS ?

Oui, pour la protection. Le palier Personal gratuit inclut le moteur de détection sémantique, la limitation de débit, le défi CAPTCHA anti-bot et le chiffrement dynamique HTML/JS, qui sont les défenses essentielles pour un site unique. Les paliers payants ajoutent des fonctionnalités opérationnelles telles que le géoblocage, l'export des journaux d'attaques, les notifications externes, des limites d'applications plus élevées, une détection plus poussée et la répartition de charge. Le fait qu'un palier payant soit nécessaire dépend des fonctionnalités requises et du nombre d'applications, et non du volume de trafic seul.

SafeLine fonctionne-t-il sur un VPS avec 1 GB RAM ?

Le minimum officiel de SafeLine est de 1 GB RAM. Cela peut suffire pour des tests ou une charge de travail très légère, mais la capacité en production dépend du trafic, des fonctionnalités activées et de la rétention des journaux. Pour un petit déploiement de production, 2 vCPU et 4 GB RAM constituent un point de départ prudent ; surveillez l'utilisation de la mémoire et dimensionnez à partir de la charge mesurée.

Pourquoi ARM64 nécessite-t-il une licence payante ?

Le documentation de déploiement officielle de SafeLine indique que les déploiements ARM nécessitent une licence Pro et que l'édition Personal n'est pas prise en charge sur ARM. Si vous voulez l'édition Personal, choisissez un VPS x86_64 ; si vous avez besoin d'ARM, prévoyez une licence Pro.

Que reçoit Chaitin Tech de mon instance SafeLine ?

Les données sortantes exactes peuvent varier selon la version et les fonctionnalités activées. Les notes de version CE actuelles mentionnent le partage de renseignement sur les menaces (Threat Intelligence Sharing), tandis que la version installée peut aussi exposer UEP ou d'autres contrôles de partage. Examinez ces réglages et les notes de version de votre installation, puis validez le trafic sortant au niveau réseau. Les conteneurs locaux de SafeLine traitent les données applicatives, mais ce seul fait ne prouve pas que refuser UEP stoppe toutes les requêtes sortantes.