DanLevy.net

Mon assistant IA m'a donné un accès shell

Comment sécuriser votre installation locale ou VPS OpenClaw/Moltbot

OpenClaw (anciennement Clawdbot/Moltbot) vous offre un assistant IA personnel qui fonctionne via WhatsApp, Slack, Discord, iMessage et d’autres canaux. Mais si vous exposez sa gateway, ses contrôles de nœuds ou SSH sur l’internet public sans authentification forte, vous offrez à des inconnus un chemin vers un accès shell sur votre machine.

Ce guide présente la configuration la plus sûre par défaut : maintenez la gateway OpenClaw en loopback, exposez-la uniquement à votre tailnet avec Tailscale Serve, sécurisez SSH, et vérifiez depuis l’extérieur que la gateway n’est pas publique.

L’adoption rapide du projet a révélé de véritables préoccupations de sécurité : les scans Shodan ont trouvé 2 847 instances exposées dans les premières semaines, et un audit de sécurité GitHub a rapporté 512 résultats dans le codebase. Une partie provenait de scanners automatiques et certaines choses ont changé depuis le renommage en OpenClaw en janvier 2026, alors considérez ce chiffre comme un signal d’alarme plutôt qu’un décompte précis de vulnérabilités actuelles. Vous n’avez pas besoin d’être un expert en sécurité — il suffit d’éviter de publier des surfaces d’opérateur avant de déployer.

Ce que vous exposez réellement

Selon la façon dont vous l’avez installé et exposé, il y a trois surfaces à vérifier :

La documentation d’accès distant d’OpenClaw indique que la gateway WebSocket se lie au loopback par défaut et recommande de rester en loopback sauf si vous choisissez délibérément une liaison LAN/tailnet/personnalisée. C’est une bonne chose. Le risque apparaît quand vous remplacez ce paramètre par défaut, publiez des ports Docker, ajoutez un reverse proxy, activez Funnel, ou laissez SSH ouvert au monde entier.

La gateway est le point le plus critique. C’est la surface d’opérateur de votre assistant, incluant les chemins d’invocation d’outils. Si elle est accessible depuis internet et que l’authentification est absente, faible, contournée ou fuite, un attaquant pourrait piloter l’agent ou invoquer des outils avec les permissions de votre utilisateur.

Le contrôle du navigateur est presque aussi sensible. La documentation actuelle d’OpenClaw recommande d’exécuter le contrôle du navigateur via un nœud paired sur la machine du navigateur et de traiter le pairing de nœuds comme un accès opérateur. Si une gateway peut invoquer system.run sur un nœud paired, cela constitue une exécution de code distante sur ce nœud, soumise à la politique de nœuds de la gateway et aux approbations d’exécution du nœud.

SSH, c’est SSH. Si vous fonctionnez avec l’authentification par mot de passe activée, les tentatives de brute force sont inévitables sur un VPS public.

La solution Tailscale

Pour OpenClaw, Tailscale vous donne un accès distant sans publier de services opérateurs :

  1. Votre instance OpenClaw tourne sur un VPS ou une machine locale
  2. La gateway reste liée au loopback et est accessible via Tailscale Serve, ou elle se lie directement à l’IP tailnet avec une authentification explicite
  3. Vous installez Tailscale à la fois sur le serveur et sur vos appareils personnels
  4. Vous accédez à OpenClaw via son IP Tailscale ou son nom MagicDNS
  5. Tous les autres sur internet ne voient rien, sauf si vous activez intentionnellement Funnel ou un autre proxy public

Devez-vous laisser OpenClaw gérer Tailscale ?

OpenClaw dispose d’une intégration Tailscale native qui peut configurer tailscale serve ou tailscale funnel pour la gateway.

Le mode Serve maintient les choses uniquement sur votre tailnet. La gateway reste liée à 127.0.0.1 tandis que Tailscale gère le routage et le HTTPS. Quand gateway.auth.allowTailscale est activé, OpenClaw peut authentifier le trafic Control UI/WebSocket en utilisant les en-têtes d’identité Tailscale et vérifier la source avec tailscale whois. C’est le bon mode pour la plupart des installations personnelles.

Le mode Funnel expose la gateway publiquement via la fonctionnalité de point d’accès public de Tailscale. La documentation de Tailscale elle-même décrit Funnel comme acheminant le trafic depuis l’internet au sens large vers un service local. OpenClaw refuse de démarrer Funnel sauf si le mode d’authentification de la gateway est password, mais vous choisissez quand même l’exposition publique pour une surface d’opérateur.

La documentation de sécurité d’OpenClaw est claire : l’injection de prompts et l’accès aux outils sont des risques fondamentaux pour un assistant personnel. Ne donnez pas à l’agent un chemin pour se rendre publiquement en douce. Utilisez Serve de manière réfléchie, évitez Funnel sauf si vous avez vraiment besoin d’un accès public, et exigez une approbation d’exécution pour toute commande tailscale.

Configurer OpenClaw en sécurité

Étape 1 : Installer Tailscale

Sur votre VPS ou serveur local :

Terminal window
# Installer Tailscale
curl -fsSL https://tailscale.com/install.sh | sh


# S'authentifier (ouvre un navigateur pour se connecter)
sudo tailscale up


# Obtenir votre IP Tailscale
tailscale ip -4
# Sortie : 100.x.x.x

Sur votre machine cliente, installez Tailscale depuis la page de téléchargement officielle et connectez-vous au même tailnet.

Les deux machines sont maintenant sur le même réseau privé. Vous pouvez pinger votre VPS en utilisant son IP Tailscale, et le trafic passera par le tunnel chiffré.

Étape 2 : Configurer OpenClaw pour utiliser Tailscale

Le modèle le plus sûr actuellement : maintenez la gateway en loopback et exposez-la à votre tailnet avec Tailscale Serve.

Dans la configuration OpenClaw :

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

Puis lancez la gateway avec Serve :

Terminal window
openclaw gateway --tailscale serve

La documentation d’OpenClaw indique que cela maintient la gateway sur 127.0.0.1 tandis que Tailscale fournit le HTTPS et le routage tailnet. Vous y accédez via https://<magicdns-name>/, pas via l’IP publique de votre VPS.

Si vous préférez une liaison tailnet directe au lieu de Serve, utilisez une authentification explicite de la gateway :

{
  gateway: {
    bind: "tailnet",
    auth: {
      mode: "token",
      token: "remplacez-par-un-token-long-et-aleatoire",
    },
  },
}

Puis connectez-vous depuis un autre appareil du tailnet :

http://<tailscale-ip>:18789/
ws://<tailscale-ip>:18789

Si vous utilisez Docker ou un autre runtime de conteneurs, soyez particulièrement prudent avec la publication de ports. Une publication comme -p 18789:18789 se lie généralement sur toutes les interfaces de l’hôte. Privilégiez le loopback plus Tailscale Serve, ou liez explicitement le côté hôte à l’IP Tailscale après avoir confirmé que le conteneur reçoit toujours le trafic :

Terminal window
TAILSCALE_IP=$(tailscale ip -4)
docker run ... -p "$TAILSCALE_IP:18789:18789" ...

Après tout changement Docker, vérifiez depuis l’extérieur avec nmap et localement avec ss. Docker peut contourner ou réordonner les hypothèses du pare-feu hôte si vous n’en tenez pas compte.

Étape 3 : Sécuriser SSH

Même avec Tailscale, vous devez sécuriser SSH correctement :

Terminal window
# Gardez votre session SSH actuelle ouverte pendant cette opération.
# D'abord, depuis votre machine cliente, confirmez que vous pouvez SSH via Tailscale :
ssh votre-utilisateur@IP_TAILSCALE_SERVEUR


# Placez le durcissement dans un fichier drop-in au lieu de réécrire sshd_config.
sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF


# Validez avant de recharger. Ne sautez pas cette étape.
sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Cela désactive l’authentification par mot de passe et la connexion root. L’étape suivante utilise UFW pour empêcher totalement le SSH public tout en autorisant SSH via tailscale0.

Étape 4 : Règles de pare-feu

Configurez un pare-feu comme couche supplémentaire :

Terminal window
# Avec UFW (Ubuntu/Debian)
sudo ufw allow in on tailscale0
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw delete allow 22/tcp || true
sudo ufw reload
sudo ufw status verbose

Le guide de durcissement Ubuntu de Tailscale utilise la même approche : autoriser tailscale0, refuser le trafic entrant autre, puis vérifier que le SSH public expire tandis que le SSH vers l’adresse 100.x.y.z fonctionne toujours. Si vous hébergez un site web public sur le même VPS, ne gardez que les règles publiques dont vous avez vraiment besoin, comme 80/tcp et 443/tcp.

Vérifier votre exposition

Vérifier les ports ouverts depuis l’extérieur

Depuis une machine qui n’est PAS sur votre réseau Tailscale :

Terminal window
# Vérifier si les ports publics courants sont exposés
nmap -p 22,80,443,18789 VOTRE_IP_PUBLIQUE


# Résultat attendu pour une instance sécurisée :
# 22/tcp   filtered ssh
# 18789/tcp filtered unknown

Si 22 ou 18789 affiche open au lieu de filtered ou closed, vous avez un problème. Si 80 ou 443 est ouvert, assurez-vous qu’il s’agit uniquement de votre site web public intentionnel ou d’un point d’accès Tailscale Funnel, pas de la gateway OpenClaw par accident.

Vérifier ce qui écoute localement

Sur votre serveur OpenClaw :

Terminal window
# Afficher tous les ports en écoute et ce à quoi ils sont liés
sudo ss -tulpn | grep LISTEN


# Cherchez des lignes comme ceci (bon pour Serve) :
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# Ou comme ceci (acceptable pour une liaison tailnet directe avec auth) :
# tcp   LISTEN 0   128   100.x.y.z:18789   *:*
#
# PAS comme ceci (mauvais) :
# tcp   LISTEN 0   128   0.0.0.0:18789     *:*

Si vous voyez 0.0.0.0 ou ::: (équivalent IPv6), ce service est exposé au monde entier.

Audit de sécurité intégré

OpenClaw inclut une commande d’audit de sécurité qui vérifie votre configuration par rapport aux meilleures pratiques de sécurité :

Terminal window
openclaw security audit --deep
openclaw security audit --deep --fix

L’audit vérifie l’exposition de la gateway, le mode Tailscale, les paramètres d’authentification, l’accès aux canaux, la politique d’outils, l’inventaire des plugins et les permissions de fichiers. Considérez --fix comme une aide utile, pas comme un substitut à la lecture des résultats.

Ce que cela ne résout pas

Tailscale élimine la plus grosse erreur : l’exposition publique des surfaces d’opérateur. Mais il ne résout pas tout :

Stockage des identifiants : OpenClaw stocke les transcripts de session, les tokens OAuth et les clés API sur le disque. Assurez-vous qu’ils ont des permissions de fichier appropriées (chmod 600 pour les fichiers, chmod 700 pour les répertoires de configuration privés) et qu’ils ne sont pas dans le contrôle de version. L’audit intégré le vérifie.

Sandboxing des plugins : Les plugins s’exécutent avec les permissions complètes de votre utilisateur. Installez uniquement des plugins provenant de sources que vous connaissez et révisez les capacités qu’ils demandent. L’outil d’audit inventorie les plugins installés.

Sécurité des appareils : Si quelqu’un compromet votre compte Tailscale ou vole un appareil sur votre tailnet, il peut accéder à votre instance OpenClaw. Activez l’autorisation d’appareils Tailscale pour exiger une approbation des nouveaux appareils.

Checklist de déploiement

Avant de considérer votre instance OpenClaw/Moltbot comme prête pour la production :

Ressources

Loading comments...