Deployer OpenClaw sur un VPS en securite (2026)

OpenClaw est un assistant IA open-source et auto-heberge qui se connecte aux applications de messagerie (WhatsApp, Telegram, Discord, Slack, Signal) et aux fournisseurs de modeles IA. Il execute un processus Gateway sur votre serveur, recoit les messages, execute des actions d'agents via des outils et envoie les reponses. Toutes les donnees restent sur votre infrastructure.

Ce guide presente un deploiement axe securite 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 executer le gateway comme service systemd durci.

Pourquoi la securite d'OpenClaw compte-t-elle sur un VPS ?

OpenClaw execute des agents IA capables de lancer des commandes shell, lire des fichiers et naviguer sur le web depuis votre serveur. Une instance mal configuree donne aux attaquants ces memes capacites. Ce n'est pas theorique.

Debut 2026, des chercheurs ont trouve plus de 42 000 instances OpenClaw exposees sur l'internet public. 63 % etaient vulnerables a une exploitation a distance. CVE-2026-25253 (CVSS 8.8) permettait une execution de code a 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, desactiver les invites de confirmation, s'echapper du sandboxing Docker et executer des commandes arbitraires.

Le correctif est arrive dans la version 2026.1.29, mais patcher seul ne suffit pas. La securite necessite des couches : isolation reseau, 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 ?

Prerequis	Details
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`)
Acces SSH	Authentification par cle configuree
Cle API fournisseur IA	Anthropic, OpenAI ou Google Gemini
Node.js	Version 22 ou plus recente
Docker	Engine 20+ avec le plugin Compose

Si vous avez besoin d'aide pour provisionner un VPS ou configurer des cles SSH, consultez Securiser un VPS Linux.

Comment durcir le VPS avant d'installer OpenClaw ?

Avant d'installer quoi que ce soit, verrouillez l'OS. Si vous avez deja suivi Securiser un VPS Linux et Configuration de la securite SSH, passez a la section suivante.

Creer un utilisateur dedie

Executer des services en root est un risque inutile. Creez un utilisateur systeme openclaw :

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

Cela cree un compte systeme avec un repertoire personnel. OpenClaw stocke sa configuration dans ~/.openclaw, le repertoire personnel est donc necessaire.

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

Verifiez les regles :

sudo ufw status verbose

Vous devriez voir les trois ports autorises et une politique de refus par defaut pour le trafic entrant. Le port 18789 (le gateway OpenClaw) est volontairement absent. Le gateway ecoute uniquement sur localhost et se trouve derriere Nginx.

Installer fail2ban

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

Verifiez qu'il tourne :

sudo systemctl status fail2ban

La sortie devrait afficher active (running). fail2ban surveille les logs SSH et bannit les IP apres des tentatives de connexion echouees repetees.

Comment installer OpenClaw sur Ubuntu ?

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

Option A : installation Docker (recommandee)

Installez Docker s'il n'est pas deja present :

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'equivalent d'un acces root sur l'hote. C'est necessaire pour les fonctionnalites Docker d'OpenClaw, mais cela signifie que l'utilisateur openclaw peut controler tous les conteneurs du systeme. Le durcissement systemd et l'isolation sandbox ci-dessous limitent ce que le processus OpenClaw peut effectivement faire.

Passez a l'utilisateur openclaw et configurez OpenClaw :

sudo -u openclaw -i

Clonez le depot et lancez la configuration avec l'image pre-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

Definir OPENCLAW_IMAGE indique au script de telecharger l'image pre-construite depuis GitHub Container Registry au lieu de compiler depuis les sources. Le script lance l'onboarding et demarre le gateway via Docker Compose.

Le gateway a l'interieur du conteneur ecoute sur toutes les interfaces par defaut (mode lan). C'est correct pour les deploiements Docker car le port mapping de Docker doit atteindre le gateway dans le conteneur. L'acces externe est bloque au niveau de l'hote via les regles iptables DOCKER-USER (couvertes plus bas).

Verifiez que le gateway tourne :

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

Une reponse 200 OK confirme que le gateway est actif. Le endpoint /readyz confirme qu'il est pret a 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

Verifiez la version :

node --version

La sortie devrait afficher v22.x.x ou plus recent.

Passez a l'utilisateur openclaw et installez :

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

Lancez l'onboarding :

openclaw onboard

Selectionnez loopback pour le mode de liaison. L'assistant d'onboarding genere un token d'authentification du gateway et le stocke dans ~/.openclaw/openclaw.json.

Demarrez le gateway :

openclaw gateway start

Verifiez :

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

Verifier la liaison du gateway

Verifiez sur quoi le gateway ecoute :

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, arretez le gateway et definissez 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'hote pour que le trafic localhost atteigne le conteneur. Les regles iptables DOCKER-USER (couvertes dans la section pare-feu ci-dessous) bloquent l'acces externe au niveau reseau.

Verrouiller les permissions de fichiers

Le fichier de configuration contient votre token d'authentification et vos cles API :

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

Verifiez :

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

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

Comment configurer l'authentification du gateway ?

Le gateway OpenClaw exige une authentification par defaut. Si aucun token ni mot de passe n'est configure, le gateway refuse les connexions WebSocket (fail-closed). L'assistant d'onboarding genere un token automatiquement.

OpenClaw supporte trois modes d'authentification :

Mode	Fonctionnement	Ideal pour
`token`	Token partage dans chaque requete	VPS mono-utilisateur (recommande)
`password`	Authentification par mot de passe	Configurations multi-appareils
`trusted-proxy`	Delegue l'auth a un reverse proxy	Configurations entreprise/SSO

Definir un token fort

Si vous souhaitez remplacer le token genere automatiquement, generez-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. Creez 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

Editez ~/.openclaw/openclaw.json pour referencer 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 demarrage. Pour les installations Docker, definissez la variable OPENCLAW_GATEWAY_TOKEN dans le fichier .env de votre repertoire openclaw-src. Le script docker-setup.sh genere ce fichier automatiquement.

Redemarrez le gateway et testez que les requetes non authentifiees sont rejetees :

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

Le endpoint de sante 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 entrees auth required ou connection rejected confirmant le comportement fail-closed.

Comment configurer Nginx comme reverse proxy TLS pour OpenClaw ?

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

Pour en savoir plus sur les reverse proxies Nginx, consultez Reverse Proxy Nginx. Pour la configuration TLS avec Let's Encrypt, voir Nginx SSL/TLS avec Let's Encrypt.

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 reel. Certbot configure le renouvellement automatique.

Configurer le reverse proxy

Creez 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 utilise $remote_addr (ecrasement), pas $proxy_add_x_forwarded_for (ajout). C'est intentionnel. L'ajout permet aux clients d'injecter de fausses IP dans l'en-tete. La documentation OpenClaw recommande specifiquement l'ecrasement.

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-tetes 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}"
    }
  }
}

Redemarrez le gateway pour appliquer. Verifiez que le TLS fonctionne depuis votre machine locale (pas le serveur) :

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

Vous devriez obtenir une reponse 200 en HTTPS avec un certificat valide. Pour plus de durcissement Nginx, consultez le guide de durcissement securite Nginx (a venir).

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

Docker manipule iptables directement, contournant UFW entierement. Si vous executez OpenClaw avec Docker et publiez un port, ce port est accessible depuis internet meme si UFW le bloque. C'est l'une des erreurs de configuration les plus courantes dans les deploiements Docker.

Pour une explication complete de ce probleme, consultez Correction du pare-feu Docker UFW.

La correction utilise la chaine DOCKER-USER, que Docker traite avant de transmettre le trafic aux conteneurs.

Bloquer tout acces 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 differe (verifiez avec ip link show).

Autoriser le trafic loopback

Nginx sur le meme hote doit pouvoir atteindre le conteneur gateway sur localhost :

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

Autoriser les connexions etablies

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

Rendre les regles persistantes

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

Verifier les regles

sudo iptables -L DOCKER-USER -n -v

Vous devriez voir les regles ACCEPT pour le loopback et les connexions etablies au-dessus de la regle DROP pour eth0. L'ordre compte : iptables traite les regles 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 execute les outils des agents dans des conteneurs isoles. Quand un agent lance une commande shell ou ecrit un fichier, cela se passe dans un conteneur jetable, pas sur votre hote.

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 parametre :

Parametre	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'acces reseau depuis la sandbox (empeche l'exfiltration)
`memory`	`"1g"`	Limite la RAM du conteneur a 1 Go
`cpus`	`1`	Limite le conteneur a 1 coeur CPU

Construisez l'image de sandbox :

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

Verifiez 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 portee, l'acces a l'espace de travail, la politique d'outils et les surcharges eventuelles. Confirmez que mode: all et network: none apparaissent dans la sortie.

Si vous avez besoin d'un acces reseau pour des outils specifiques (ex. web_search), accordez-le selectivement par agent plutot que de modifier le defaut global. Voir la section politique d'outils ci-dessous.

OpenClaw bloque par defaut les sources de montages bind dangereuses : /var/run/docker.sock, /etc, /proc, /sys et /dev sont tous refuses. Ne surchargez pas cela avec des montages bind personnalises qui les re-exposent. Si un conteneur sandbox a besoin d'acceder a des donnees de l'hote, utilisez 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 donnees mais pas les modifier.

Comment verrouiller la politique d'outils OpenClaw ?

La politique d'outils controle quels outils les agents peuvent utiliser. La sandbox a son propre filtre d'outils, separe des permissions au niveau agent. Le refus l'emporte toujours sur l'autorisation.

Politique de refus par defaut

Definissez un defaut restrictif dans ~/.openclaw/openclaw.json :

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

Cela bloque l'execution de commandes, l'ecriture de fichiers, l'edition de fichiers et l'acces navigateur par defaut. Les agents peuvent toujours lire des fichiers et effectuer des recherches web.

Profils par agent

Surchargez les defauts pour des agents specifiques qui ont besoin de plus d'acces. 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 executer des commandes mais uniquement dans un conteneur sandbox sans reseau. Le messaging-agent peut lire et chercher mais ne peut rien executer.

Desactiver le mode eleve

Le mode eleve (elevated mode) permet aux agents d'executer des commandes directement sur l'hote du gateway, contournant la sandbox. Desactivez-le :

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

Si vous laissez le mode eleve active, toute personne pouvant discuter avec l'agent peut potentiellement executer des commandes sur l'hote. Sur un VPS, c'est de l'execution de code a distance.

Isolation DM multi-utilisateurs

Si plusieurs personnes envoient des messages a votre instance OpenClaw, activez le cloisonnement DM par pair. Par defaut, 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 a chaque expediteur sa propre session avec un contexte isole et un conteneur sandbox separe.

Comment executer OpenClaw comme service systemd durci ?

Executer OpenClaw sous systemd signifie qu'il demarre au boot, redemarre en cas de crash et beneficie de l'isolation de processus via les directives de durcissement.

Creer le fichier d'unite de service

Pour les installations Docker, creez le fichier d'unite 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`	Empeche le processus d'acquerir des privileges supplementaires via setuid/setgid
`PrivateTmp`	Donne au service son propre `/tmp`, invisible aux autres processus
`ProtectSystem=strict`	Monte l'ensemble du systeme de fichiers en lecture seule sauf les `ReadWritePaths` explicites
`ProtectHome=read-only`	Empeche l'ecriture dans tout repertoire personnel sauf le chemin autorise
`CapabilityBoundingSet=`	Supprime toutes les capabilities Linux (ensemble vide)
`ProtectKernelTunables`	Bloque les ecritures vers `/proc/sys`, `/sys`
`ProtectKernelModules`	Empeche le chargement de modules noyau
`MemoryMax=4G`	Tue le service s'il depasse 4 Go de RAM, empechant l'OOM sur l'hote

Activer et demarrer

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

enable le fait demarrer au boot. --now le demarre immediatement.

Verifiez qu'il tourne :

sudo systemctl status openclaw-gateway

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

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

Comment verifier que le deploiement complet est securise ?

Parcourez cette checklist apres le deploiement pour confirmer que chaque couche fonctionne.

1. Lancer l'audit de securite integre 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 reseau sans authentification, permissions d'outils elevees, problemes 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'acces externe est bloque par les regles 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. Verifier 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 lies a la sante.

6. Verifier 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. Verifier 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. Verifier le durcissement systemd

systemd-analyze security openclaw-gateway

Cela note les proprietes de securite du service. Visez un score autour de 5.0 ou moins (plus bas = plus securise). Les services bases sur Docker obtiennent generalement un score entre 5.0 et 5.5 car Docker necessite l'acces aux namespaces et interfaces de peripheriques. Les directives de durcissement ci-dessus font passer le score du defaut ~9.6 a environ 5.2.

9. Verifier les regles 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 chaine DOCKER-USER devrait rejeter le trafic externe.

10. Verifier les services exposes

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 apparaitre.

Comment garder OpenClaw a jour et sauvegarde ?

Masquage de version

Masquez la version d'OpenClaw dans les reponses du gateway. La divulgation de version aide les attaquants a cibler des vulnerabilites connues. Dans ~/.openclaw/openclaw.json :

{
  gateway: {
    exposeVersion: false
  }
}

Combine avec la directive server_tokens off; deja presente dans la configuration Nginx, cela empeche le fingerprinting du reverse proxy et de l'application.

Mises a jour

OpenClaw publie des versions frequemment. Verifiez la version actuelle :

openclaw --version

Pour les installations Docker :

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

Pour mettre a jour une installation Docker :

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

Pour mettre a jour une installation npm :

npm update -g openclaw

Apres la mise a jour, redemarrez le gateway et relancez l'audit de securite :

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 a 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 presents. L'oublier apres la mise a jour vous bloque hors du gateway.

Sauvegardes

Sauvegardez le repertoire de configuration :

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

Stockez les sauvegardes hors du serveur. Le repertoire de configuration contient vos tokens d'authentification, configurations d'agents et l'etat des conversations. Protegez les sauvegardes avec le meme soin que la configuration en production : chiffrez-les avec gpg ou stockez-les dans un volume chiffre.

Gestion des logs

Consultez les logs en temps reel :

journalctl -u openclaw-gateway -f

Les logs OpenClaw peuvent contenir des extraits de conversations. Definissez une retention 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 ?

Symptome	Cause probable	Correction
Le gateway refuse de demarrer	Port 18789 deja utilise	`ss -tulpn \| grep 18789` pour trouver le processus en conflit
Les connexions WebSocket echouent a travers Nginx	En-tetes `Upgrade` et `Connection` manquants	Verifiez les directives `proxy_set_header` dans votre configuration Nginx
Les conteneurs sandbox ne demarrent 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	Derive de configuration apres mise a jour	Consultez la sortie de l'audit et appliquez les corrections recommandees
Gateway accessible depuis une IP externe	Contournement Docker/UFW	Ajoutez les regles iptables `DOCKER-USER` comme decrit ci-dessus
Erreurs de certificat TLS	Echec du renouvellement Certbot	Lancez `sudo certbot renew --dry-run` pour diagnostiquer
OOM kills sur le VPS	`MemoryMax` manquant dans l'unite systemd	Ajoutez `MemoryMax=4G` a la section `[Service]`

Copyright 2026 Virtua.Cloud. Tous droits reserves. Ce contenu est une creation originale de l'equipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation ecrite est interdite.

Articles associés