OpenClaw est un assistant IA open-source et auto-hébergé qui se connecte aux applications de messagerie (WhatsApp, Telegram, Discord, Slack, Signal) et aux fournisseurs de modèles IA. Il exécute un processus Gateway sur votre serveur, reçoit les messages, exécute des actions d'agents via des outils et envoie les réponses. Toutes les données restent sur votre infrastructure.

Ce guide présente un déploiement axé sécurité sur un VPS sous Ubuntu 24.04. Vous allez durcir l'OS, installer OpenClaw, configurer l'authentification du gateway, mettre en place Nginx avec TLS en reverse proxy, corriger le contournement du pare-feu Docker/UFW, activer le sandboxing Docker, verrouiller la politique d'outils et exécuter le gateway comme service systemd durci.

Pourquoi la sécurité d'OpenClaw compte-t-elle sur un VPS ?

OpenClaw exécute des agents IA capables de lancer des commandes shell, lire des fichiers et naviguer sur le web depuis votre serveur. Une instance mal configurée donne aux attaquants ces mêmes capacités. Ce n'est pas théorique.

Début 2026, des chercheurs ont trouvé plus de 42 000 instances OpenClaw exposées sur l'internet public. 63 % étaient vulnérables à une exploitation à distance. CVE-2026-25253 (CVSS 8.8) permettait une exécution de code à distance en un clic via l'exfiltration du token d'authentification par un lien malveillant. L'attaquant pouvait voler le token du gateway, se connecter via WebSocket, désactiver les invites de confirmation, s'échapper du sandboxing Docker et exécuter des commandes arbitraires.

Le correctif est arrivé dans la version 2026.1.29, mais patcher seul ne suffit pas. La sécurité nécessite des couches : isolation réseau, authentification, TLS, sandboxing et restrictions d'outils fonctionnant ensemble. Une seule couche manquante (par exemple, l'auth du gateway sans pare-feu) laisse un chemin direct vers la compromission.

De quoi avez-vous besoin avant de commencer ?

Prérequis	Détails
VPS	Ubuntu 24.04, 4+ vCPU, 8 Go de RAM minimum
Nom de domaine	Enregistrement A pointant vers l'IP de votre VPS (ex. `openclaw.example.com`)
Accès SSH	Authentification par clé configurée
Clé API fournisseur IA	Anthropic, OpenAI ou Google Gemini
Node.js	Version 22 ou plus récente
Docker	Engine 20+ avec le plugin Compose

Si vous avez besoin d'aide pour provisionner un VPS ou configurer des clés SSH, consultez Sécurité Linux VPS : menaces, couches de défense et guide de durcissement.

Comment durcir le VPS avant d'installer OpenClaw ?

Avant d'installer quoi que ce soit, verrouillez l'OS. Si vous avez déjà suivi Sécurité Linux VPS : menaces, couches de défense et guide de durcissement et Sécuriser SSH sur un VPS Linux : guide sshd_config, passez à la section suivante.

Créer un utilisateur dédié

Exécuter des services en root est un risque inutile. Créez un utilisateur système openclaw :

sudo useradd -r -m -s /bin/bash openclaw

Cela crée un compte système avec un répertoire personnel. OpenClaw stocke sa configuration dans ~/.openclaw, le répertoire personnel est donc nécessaire.

Configurer UFW

Installez et activez le pare-feu avant d'exposer le moindre service :

sudo apt update && sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Contrôlez les règles :

sudo ufw status verbose

Vous devriez voir les trois ports autorisés et une politique de refus par défaut pour le trafic entrant. Le port 18789 (le gateway OpenClaw) est volontairement absent. Le gateway écoute uniquement sur localhost et se trouvé derrière Nginx.

Installer fail2ban

sudo apt update && sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Vérifiez qu'il tourne :

sudo systemctl status fail2ban

La sortie devrait afficher active (running). fail2ban surveille les logs SSH et bannit les IP après des tentatives de connexion échouées répétées.

Comment installer OpenClaw sur Ubuntu ?

OpenClaw propose deux méthodes d'installation : npm (directe) et Docker. Les deux sont couvertes ci-dessous. Choisissez-en une. Docker est recommandé pour les déploiements VPS car l'isolation par conteneur limite le rayon d'impact si le processus agent est compromis.

Option A : installation Docker (recommandée)

Installez Docker s'il n'est pas déjà présent :

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Ajoutez l'utilisateur openclaw au groupe docker :

sudo usermod -aG docker openclaw

Note : l'appartenance au groupe Docker accorde l'équivalent d'un accès root sur l'hôte. C'est nécessaire pour les fonctionnalités Docker d'OpenClaw, mais cela signifie que l'utilisateur openclaw peut contrôler tous les conteneurs du système. Le durcissement systemd et l'isolation sandbox ci-dessous limitent ce que le processus OpenClaw peut effectivement faire.

Passez à l'utilisateur openclaw et configurez OpenClaw :

sudo -u openclaw -i

Clonez le dépôt et lancez la configuration avec l'image pré-construite officielle :

git clone https://github.com/openclaw/openclaw.git ~/openclaw-src
cd ~/openclaw-src
OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:latest ./docker-setup.sh

Définir OPENCLAW_IMAGE indique au script de télécharger l'image pré-construite depuis GitHub Container Registry au lieu de compiler depuis les sources. Le script lance l'onboarding et démarre le gateway via Docker Compose.

Le gateway à l'intérieur du conteneur écoute sur toutes les interfaces par défaut (mode lan). C'est correct pour les déploiements Docker car le port mapping de Docker doit atteindre le gateway dans le conteneur. L'accès externe est bloqué au niveau de l'hôte via les règles iptables DOCKER-USER (couvertes plus bas).

Assurez-vous que le gateway tourne :

curl -fsS http://127.0.0.1:18789/healthz

Une réponse 200 OK confirme que le gateway est actif. Le endpoint /readyz confirme qu'il est prêt à accepter des connexions :

curl -fsS http://127.0.0.1:18789/readyz

Option B : installation npm

Installez Node.js 22 via NodeSource :

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Confirmez la version :

node --version

La sortie devrait afficher v22.x.x ou plus récent.

Passez à l'utilisateur openclaw et installez :

sudo -u openclaw -i
npm install -g openclaw@latest

Lancez l'onboarding :

openclaw onboard

Sélectionnez loopback pour le mode de liaison. L'assistant d'onboarding génère un token d'authentification du gateway et le stocke dans ~/.openclaw/openclaw.json.

Démarrez le gateway :

openclaw gateway start

Confirmez :

curl -fsS http://127.0.0.1:18789/healthz

Vérifier la liaison du gateway

Vérifiez sur quoi le gateway écoute :

ss -tulpn | grep 18789

Pour les installations npm : la sortie devrait afficher 127.0.0.1:18789, pas 0.0.0.0:18789. Si vous voyez 0.0.0.0, arrêtez le gateway et définissez gateway.bind a "loopback" dans openclaw.json.

Pour les installations Docker : vous verrez 0.0.0.0:18789 du processus docker-proxy. C'est attendu. Le port mapping de Docker publie le port sur toutes les interfaces de l'hôte pour que le trafic localhost atteigne le conteneur. Les règles iptables DOCKER-USER (couvertes dans la section pare-feu ci-dessous) bloquent l'accès externe au niveau réseau.

Verrouiller les permissions de fichiers

Le fichier de configuration contient votre token d'authentification et vos clés API :

chmod 700 /home/openclaw/.openclaw
chmod 600 /home/openclaw/.openclaw/openclaw.json

Testez :

ls -la /home/openclaw/.openclaw/openclaw.json

Vous devriez voir -rw-------. Pour les installations npm, le propriétaire est openclaw. Pour les installations Docker, le propriétaire peut s'afficher comme uid 1000 (l'utilisateur node dans le conteneur). C'est normal et nécessaire pour que le conteneur puisse lire la configuration.

Comment configurer l'authentification du gateway ?

Le gateway OpenClaw exige une authentification par défaut. Si aucun token ni mot de passe n'est configuré, le gateway refuse les connexions WebSocket (fail-closed). L'assistant d'onboarding génère un token automatiquement.

OpenClaw supporte trois modes d'authentification :

Mode	Fonctionnement	Idéal pour
`token`	Token partagé dans chaque requête	VPS mono-utilisateur (recommande)
`password`	Authentification par mot de passe	Configurations multi-appareils
`trusted-proxy`	Délégué l'auth à un reverse proxy	Configurations entreprise/SSO

Définir un token fort

Si vous souhaitez remplacer le token génère automatiquement, générez-en un nouveau :

openssl rand -base64 32

Stockez-le comme variable d'environnement au lieu de le coder en dur dans le fichier de configuration. Créez un fichier d'environnement :

sudo mkdir -p /etc/openclaw
sudo tee /etc/openclaw/env > /dev/null << 'EOF'
OPENCLAW_GATEWAY_TOKEN=your-generated-token-here
EOF
sudo chmod 600 /etc/openclaw/env
sudo chown openclaw:openclaw /etc/openclaw/env

Éditez ~/.openclaw/openclaw.json pour référencer la variable d'environnement :

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

OpenClaw supporte la substitution ${VARIABLE} dans sa configuration JSON5, le token est donc lu depuis l'environnement au démarrage. Pour les installations Docker, définissez la variable OPENCLAW_GATEWAY_TOKEN dans le fichier .env de votre répertoire openclaw-src. Le script docker-setup.sh génère ce fichier automatiquement.

Redémarrez le gateway et testez que les requêtes non authentifiées sont rejetées :

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:18789/healthz

Le endpoint de santé renvoie 200 sans authentification (c'est un health check). Pour tester l'application de l'authentification sur le endpoint WebSocket, consultez les logs du gateway :

Pour les installations systemd/npm :

journalctl -u openclaw-gateway --no-pager -n 20

Pour les installations Docker :

cd ~/openclaw-src && docker compose logs openclaw-gateway --tail 20

Cherchez les entrées auth required ou connection rejected confirmant le comportement fail-closed.

Comment configurer Nginx comme reverse proxy TLS pour OpenClaw ?

Le gateway écoute sur localhost. Nginx se place devant, termine le TLS et proxifie les connexions WebSocket vers le gateway. Cela vous donne des connexions chiffrées sans exposer le port du gateway.

Pour en savoir plus sur les reverse proxies Nginx, consultez Configurer Nginx comme reverse proxy. Pour la configuration TLS avec Let's Encrypt, voir Configurer Let's Encrypt SSL/TLS pour Nginx sur Debian 12 et Ubuntu 24.04.

Installer Nginx et Certbot

sudo apt install -y nginx certbot python3-certbot-nginx

Obtenir un certificat TLS

sudo certbot --nginx -d openclaw.example.com

Remplacez openclaw.example.com par votre domaine réel. Certbot configuré le renouvellement automatique.

Configurer le reverse proxy

Créez le bloc serveur Nginx :

sudo tee /etc/nginx/sites-available/openclaw.conf > /dev/null << 'NGINX'
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name openclaw.example.com;

    ssl_certificate /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # Hide Nginx version
    server_tokens off;

    # WebSocket proxy to OpenClaw gateway
    location / {
        proxy_pass http://127.0.0.1:18789;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Overwrite X-Forwarded-For, do not append
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;

        # Timeouts for long-running agent sessions
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name openclaw.example.com;
    return 301 https://$host$request_uri;
}
NGINX

Point important : proxy_set_header X-Forwarded-For $remote_addr utilisé $remote_addr (écrasement), pas $proxy_add_x_forwarded_for (ajout). C'est intentionnel. L'ajout permet aux clients d'injecter de fausses IP dans l'en-tête. La documentation OpenClaw recommandé spécifiquement l'écrasement.

Activez le site et testez la configuration :

sudo ln -s /etc/nginx/sites-available/openclaw.conf /etc/nginx/sites-enabled/
sudo nginx -t

La sortie devrait afficher syntax is ok et test is successful. Rechargez Nginx :

sudo systemctl reload nginx

Configurer OpenClaw pour faire confiance au proxy

Indiquez au gateway de faire confiance aux en-têtes transmis par Nginx en ajoutant trustedProxies a ~/.openclaw/openclaw.json :

{
  gateway: {
    bind: "loopback",  // use "loopback" for npm, keep default for Docker
    port: 18789,
    trustedProxies: ["127.0.0.1"],
    auth: {
      mode: "token",
      token: "${OPENCLAW_GATEWAY_TOKEN}"
    }
  }
}

Redémarrez le gateway pour appliquer. Vérifiez que le TLS fonctionne depuis votre machine locale (pas le serveur) :

curl -I https://openclaw.example.com/healthz

Vous devriez obtenir une réponse 200 en HTTPS avec un certificat valide. Durcissement de la sécurité Nginx sur Ubuntu et DebianPour plus de durcissement Nginx, consultez le guide de durcissement sécurité Nginx (à venir).

Comment corriger le contournement du pare-feu Docker et UFW ?

Docker manipule iptables directement, contournant UFW entièrement. Si vous exécutez OpenClaw avec Docker et publiez un port, ce port est accessible depuis internet même si UFW le bloque. C'est l'une des erreurs de configuration les plus courantes dans les déploiements Docker.

Pour une explication complète de ce problème, consultez Docker contourne UFW : 4 solutions testées pour votre VPS.

La correction utilisé la chaîne DOCKER-USER, que Docker traite avant de transmettre le trafic aux conteneurs.

Bloquer tout accès externe aux ports Docker

sudo iptables -I DOCKER-USER -i eth0 -j DROP

Cela rejette tout le trafic provenant de l'interface externe (eth0) que Docker transmettrait autrement aux conteneurs. Adaptez le nom de l'interface si le votre diffère (vérifiez avec ip link show).

Autoriser le trafic loopback

Nginx sur le même hôte doit pouvoir atteindre le conteneur gateway sur localhost :

sudo iptables -I DOCKER-USER -i lo -j ACCEPT

Autoriser les connexions établies

sudo iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Rendre les règles persistantes

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Vérifier les règles

sudo iptables -L DOCKER-USER -n -v

Vous devriez voir les règles ACCEPT pour le loopback et les connexions établiés àu-dessus de la règle DROP pour eth0. L'ordre compte : iptables traite les règles de haut en bas.

Testez depuis une machine externe que le port du gateway n'est pas accessible :

nmap -p 18789 your-server-ip

Le port 18789 devrait afficher filtered ou closed, pas open.

Comment activer le sandboxing Docker pour OpenClaw ?

Le sandboxing Docker exécute les outils des agents dans des conteneurs isolés. Quand un agent lance une commande shell ou écrit un fichier, cela se passe dans un conteneur jetable, pas sur votre hôte.

Ajoutez la configuration de sandbox a ~/.openclaw/openclaw.json :

{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "none",
        docker: {
          image: "openclaw-sandbox:bookworm-slim",
          network: "none",
          user: "1000:1000",
          memory: "1g",
          cpus: 1
        }
      }
    }
  }
}

Ce que fait chaque paramètre :

Paramètre	Valeur	Effet
`mode`	`"all"`	Chaque session tourne en sandbox, sans exception
`scope`	`"session"`	Chaque session de chat obtient son propre conteneur
`workspaceAccess`	`"none"`	La sandbox ne peut pas voir l'espace de travail de l'agent
`network`	`"none"`	Pas d'accès réseau depuis la sandbox (empêche l'exfiltration)
`memory`	`"1g"`	Limite la RAM du conteneur à 1 Go
`cpus`	`1`	Limite le conteneur à 1 coeur CPU

Construisez l'image de sandbox :

cd ~/openclaw-src
scripts/sandbox-setup.sh

Contrôlez la configuration de la sandbox :

openclaw sandbox explain

Pour les installations Docker, lancez via compose :

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Cette commande affiche le mode sandbox effectif, la portée, l'accès a l'espace de travail, la politique d'outils et les surcharges éventuelles. Confirmez que mode: all et network: none apparaissent dans la sortie.

Si vous avez besoin d'un accès réseau pour des outils spécifiques (ex. web_search), accordez-le sélectivement par agent plutôt que de modifier le défaut global. Voir la section politique d'outils ci-dessous.

OpenClaw bloqué par défaut les sources de montages bind dangereuses : /var/run/docker.sock, /etc, /proc, /sys et /dev sont tous refusés. Ne surchargez pas cela avec des montages bind personnalisés qui les re-exposent. Si un conteneur sandbox a besoin d'accéder à des données de l'hôte, utiliséz des montages en lecture seule avec des chemins explicites :

{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/home/openclaw/shared-data:/data:ro"]
        }
      }
    }
  }
}

Le suffixe :ro garantit que le conteneur peut lire les données mais pas les modifier.

Comment verrouiller la politique d'outils OpenClaw ?

La politique d'outils contrôle quels outils les agents peuvent utilisér. La sandbox a son propre filtre d'outils, séparé des permissions au niveau agent. Le refus l'emporte toujours sur l'autorisation.

Politique de refus par défaut

Définissez un défaut restrictif dans ~/.openclaw/openclaw.json :

{
  tools: {
    deny: ["exec", "write", "edit", "browser"],
    allow: ["read", "web_search"]
  }
}

Cela bloqué l'exécution de commandes, l'écriture de fichiers, l'édition de fichiers et l'accès navigateur par défaut. Les agents peuvent toujours lire des fichiers et effectuer des recherches web.

Profils par agent

Surchargez les défauts pour des agents spécifiques qui ont besoin de plus d'accès. Ajoutez des profils sous agents.list :

{
  agents: {
    list: [
      {
        name: "coding-agent",
        tools: {
          allow: ["exec", "read", "write", "edit"],
          deny: ["browser"]
        },
        sandbox: {
          mode: "all",
          docker: {
            network: "none"
          }
        }
      },
      {
        name: "messaging-agent",
        tools: {
          allow: ["read", "web_search"],
          deny: ["exec", "write", "edit", "browser"]
        }
      }
    ]
  }
}

Le coding-agent peut exécuter des commandes mais uniquement dans un conteneur sandbox sans réseau. Le messaging-agent peut lire et chercher mais ne peut rien exécuter.

Désactiver le mode élevé

Le mode élevé (elevated mode) permet aux agents d'exécuter des commandes directement sur l'hôte du gateway, contournant la sandbox. Désactivez-le :

{
  tools: {
    elevated: {
      enabled: false
    }
  }
}

Si vous laissez le mode élevé activé, toute personne pouvant discuter avec l'agent peut potentiellement exécuter des commandes sur l'hôte. Sur un VPS, c'est de l'exécution de code à distance.

Isolation DM multi-utilisateurs

Si plusieurs personnes envoient des messages a votre instance OpenClaw, activez le cloisonnement DM par pair. Par défaut, tous les DM partagent une seule session principale. Cela signifie que l'Utilisateur A peut voir le contexte de la conversation de l'Utilisateur B.

{
  session: {
    dmScope: "per-peer"
  }
}

Cela donne à chaque expéditeur sa propre session avec un contexte isolé et un conteneur sandbox séparé.

Comment exécuter OpenClaw comme service systemd durci ?

Exécuter OpenClaw sous systemd signifie qu'il démarre au boot, redémarre en cas de crash et bénéficie de l'isolation de processus via les directives de durcissement.

Créer le fichier d'unité de service

Pour les installations Docker, créez le fichier d'unité suivant :

sudo tee /etc/systemd/system/openclaw-gateway.service > /dev/null << 'EOF'
[Unit]
Description=OpenClaw Gateway
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/openclaw-src
EnvironmentFile=/etc/openclaw/env
ExecStart=/usr/bin/docker compose up --no-log-prefix openclaw-gateway
ExecStop=/usr/bin/docker compose down
Restart=always
RestartSec=10

# Security hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/openclaw/.openclaw
CapabilityBoundingSet=
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes
MemoryMax=4G

[Install]
WantedBy=multi-user.target
EOF

Pour les installations npm, remplacez les lignes ExecStart et ExecStop :

ExecStart=/usr/bin/openclaw gateway start --foreground
ExecStop=/usr/bin/openclaw gateway stop

Et supprimez la ligne Requires=docker.service.

Ce que fait chaque directive de durcissement :

Directive	Protection
`NoNewPrivileges`	Empêche le processus d'acquérir des privilèges supplémentaires via setuid/setgid
`PrivateTmp`	Donne au service son propre `/tmp`, invisible aux autres processus
`ProtectSystem=strict`	Monte l'ensemble du système de fichiers en lecture seule sauf les `ReadWritePaths` explicites
`ProtectHome=read-only`	Empêche l'écriture dans tout répertoire personnel sauf le chemin autorisé
`CapabilityBoundingSet=`	Supprime toutes les capabilities Linux (ensemble vide)
`ProtectKernelTunables`	Bloque les écritures vers `/proc/sys`, `/sys`
`ProtectKernelModules`	Empêche le chargement de modules noyau
`MemoryMax=4G`	Tue le service s'il dépasse 4 Go de RAM, empêchant l'OOM sur l'hôte

Activer et démarrer

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway

enable le fait démarrer au boot. --now le démarre immédiatement.

Vérifiez qu'il tourne :

sudo systemctl status openclaw-gateway

La sortie devrait afficher active (running). Consultez les logs pour d'éventuelles erreurs :

journalctl -u openclaw-gateway -f --no-pager -n 50

Comment vérifier que le déploiement complet est sécurisé ?

Parcourez cette checklist après le déploiement pour confirmer que chaque couche fonctionne.

1. Lancer l'audit de sécurité intégré d'OpenClaw

Pour les installations npm :

sudo -u openclaw openclaw security audit --deep

Pour les installations Docker :

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit --deep

Cela signale les erreurs de configuration courantes : exposition réseau sans authentification, permissions d'outils élevées, problèmes de permissions de fichiers. Corrigez tous les avertissements avant de continuer.

2. Confirmer la liaison du gateway

ss -tulpn | grep 18789

Installations npm : attendu 127.0.0.1:18789. Pas 0.0.0.0:18789.

Installations Docker : attendu 0.0.0.0:18789 depuis docker-proxy. C'est normal. L'accès externe est bloqué par les règles iptables DOCKER-USER.

3. Scan de ports externe

Depuis votre machine locale (pas le serveur) :

nmap -p 18789 your-server-ip

Attendu : filtered ou closed.

4. Vérifier le TLS

curl -I https://openclaw.example.com/healthz

Attendu : 200 en HTTPS avec un certificat valide.

5. Tester l'application de l'authentification

curl -s -o /dev/null -w "%{http_code}" https://openclaw.example.com/

Le gateway devrait exiger une authentification pour les endpoints non liés à la santé.

6. Vérifier l'isolation de la sandbox

Pour les installations npm :

sudo -u openclaw openclaw sandbox explain

Pour les installations Docker :

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js sandbox explain

Confirmez mode: all, network: none et aucune surcharge elevated.

7. Vérifier les permissions de fichiers

ls -la /home/openclaw/.openclaw/openclaw.json
ls -la /etc/openclaw/env

Les deux devraient afficher des permissions 600. Le fichier env appartient a openclaw. Pour les installations Docker, openclaw.json peut appartenir a l'uid 1000 (l'utilisateur node du conteneur).

8. Vérifier le durcissement systemd

systemd-analyze security openclaw-gateway

Cela note les propriétés de sécurité du service. Visez un score autour de 5.0 ou moins (plus bas = plus sécurisé). Les services basés sur Docker obtiennent généralement un score entre 5.0 et 5.5 car Docker nécessite l'accès aux namespaces et interfaces de périphériques. Les directives de durcissement ci-dessus font passer le score du défaut ~9.6 à environ 5.2.

9. Vérifier les règles UFW et DOCKER-USER

sudo ufw status
sudo iptables -L DOCKER-USER -n -v

UFW devrait afficher uniquement les ports 22, 80 et 443. La chaîne DOCKER-USER devrait rejeter le trafic externe.

10. Vérifier les services exposés

ss -tulpn

Seuls SSH (22), Nginx (80, 443) et OpenClaw (127.0.0.1:18789 pour npm, ou 0.0.0.0:18789 via docker-proxy pour Docker) devraient apparaître.

Comment garder OpenClaw à jour et sauvegarde ?

Masquage de version

Masquez la version d'OpenClaw dans les réponses du gateway. La divulgation de version aide les attaquants à cibler des vulnérabilités connues. Dans ~/.openclaw/openclaw.json :

{
  gateway: {
    exposeVersion: false
  }
}

Combine avec la directive server_tokens off; déjà présente dans la configuration Nginx, cela empêche le fingerprinting du reverse proxy et de l'application.

Mises à jour

OpenClaw publie des versions fréquemment. Vérifiez la version actuelle :

openclaw --version

Pour les installations Docker :

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js --version

Pour mettre à jour une installation Docker :

cd ~/openclaw-src
git pull
docker compose pull
docker compose up -d openclaw-gateway

Pour mettre à jour une installation npm :

npm update -g openclaw

Après la mise à jour, redémarrez le gateway et relancez l'audit de sécurité :

sudo systemctl restart openclaw-gateway

Pour npm :

sudo -u openclaw openclaw security audit

Pour Docker :

cd ~/openclaw-src && docker compose exec openclaw-gateway node dist/index.js security audit

Lisez les notes de version avant de mettre à jour. Des changements cassants dans le format de configuration arrivent. La version 2026.3.7 a introduit un champ gateway.auth.mode obligatoire quand token et password sont tous les deux présents. L'oublier après la mise à jour vous bloqué hors du gateway.

Sauvegardes

Sauvegardez le répertoire de configuration :

sudo tar czf /root/openclaw-backup-$(date +%Y%m%d).tar.gz /home/openclaw/.openclaw

Stockez les sauvegardes hors du serveur. Le répertoire de configuration contient vos tokens d'authentification, configurations d'agents et l'état des conversations. Protégez les sauvegardes avec le même soin que la configuration en production : chiffrez-les avec gpg ou stockez-les dans un volume chiffré.

Gestion des logs

Consultez les logs en temps réel :

journalctl -u openclaw-gateway -f

Les logs OpenClaw peuvent contenir des extraits de conversations. Définissez une rétention des logs pour limiter l'exposition :

sudo tee /etc/systemd/journald.conf.d/openclaw.conf > /dev/null << 'EOF'
[Journal]
MaxRetentionSec=7d
MaxFileSec=1d
EOF
sudo systemctl restart systemd-journald

Quelque chose ne fonctionne pas ?

Symptôme	Cause probable	Correction
Le gateway refuse de démarrer	Port 18789 déjà utilisé	`ss -tulpn \| grep 18789` pour trouver le processus en conflit
Les connexions WebSocket échouent à travers Nginx	En-têtes `Upgrade` et `Connection` manquants	Vérifiez les directives `proxy_set_header` dans votre configuration Nginx
Les conteneurs sandbox ne démarrent pas	Permissions du socket Docker	Assurez-vous que l'utilisateur `openclaw` est dans le groupe `docker` et reconnectez-vous
`openclaw security audit` affiche des avertissements	Dérive de configuration après mise à jour	Consultez la sortie de l'audit et appliquez les corrections recommandées
Gateway accessible depuis une IP externe	Contournement Docker/UFW	Ajoutez les règles iptables `DOCKER-USER` comme décrit ci-dessus
Erreurs de certificat TLS	Échec du renouvellement Certbot	Lancez `sudo certbot renew --dry-run` pour diagnostiquer
OOM kills sur le VPS	`MemoryMax` manquant dans l'unité systemd	Ajoutez `MemoryMax=4G` à la section `[Service]`

Sécuriser votre serveur d'agents IA : sandboxing, pare-feu et supervisionPour des sujets de sécurité avancés comme la limitation de débit et la surveillance des serveurs d'agents IA, consultez le guide de sécurisation des serveurs d'agents IA (à venir).

Articles associés