DanLevy.net

FR

Votre Assistant IA m'a Donné un Accès Shell

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

OpenClaw (anciennement Clawdbot/Moltbot) vous offre un assistant IA personnel qui fonctionne sur WhatsApp, Slack, Discord, iMessage et d’autres canaux. Mais si vous exposez sa passerelle, ses contrôles de nœud ou son 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 par défaut la plus sûre : garder la passerelle d’OpenClaw sur loopback, l’exposer uniquement à votre tailnet avec Tailscale Serve, verrouiller SSH, et vérifier de l’extérieur que la passerelle n’est pas publique.

L’adoption rapide du projet a révélé de réels problèmes de sécurité : des 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 la base de code. Une partie provenait de scanners automatisés et certains éléments ont changé depuis le renommage en OpenClaw en janvier 2026, donc 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é — vous devez simplement éviter de publier des surfaces opérateur avant d’avoir déployé.

Ce Que Vous Exposez Réellement

Selon la façon dont vous avez installé et exposé le service, trois surfaces méritent votre attention :

La documentation actuelle d’accès à distance d’OpenClaw indique que le WebSocket de la passerelle se lie à loopback par défaut et recommande de le garder ainsi sauf si vous choisissez intentionnellement une liaison LAN/tailnet/personnalisée. C’est bien. Le risque apparaît lorsque vous remplacez cette valeur par défaut, publiez des ports Docker, ajoutez un proxy inverse, activez Funnel, ou laissez SSH ouvert au monde.

La passerelle est la plus critique. C’est la surface 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 divulguée, un attaquant pourrait piloter l’agent ou invoquer des outils avec les permissions de votre utilisateur.

Le contrôle navigateur est presque aussi sensible. Les docs actuelles d’OpenClaw recommandent d’exécuter le contrôle navigateur via un nœud appairé sur la machine cible et de traiter l’appairage de nœuds comme un accès opérateur. Si une passerelle peut invoquer system.run sur un nœud appairé, c’est une exécution de code à distance sur ce nœud, sous réserve de la politique de nœud de la passerelle et des approbations d’exécution du nœud lui-même.

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

La Solution Tailscale

Pour OpenClaw, Tailscale offre un accès distant sans publier vos services opérateur :

  1. Votre instance OpenClaw s’exécute sur un VPS ou une machine locale
  2. La passerelle reste liée à loopback et est accessible via Tailscale Serve, ou elle se lie directement à l’IP du tailnet avec une authentification explicite
  3. Vous installez Tailscale sur le serveur et sur vos appareils personnels
  4. Vous accédez à OpenClaw via son IP Tailscale ou son nom MagicDNS
  5. Tout le reste d’internet ne voit rien, sauf si vous activez intentionnellement Funnel ou un autre proxy public

Faut-il Laisser OpenClaw Gérer Tailscale ?

OpenClaw dispose d’une intégration Tailscale intégrée qui peut configurer tailscale serve ou tailscale funnel pour la passerelle.

Le mode Serve garde les choses sur votre seul tailnet. La passerelle reste liée à 127.0.0.1 pendant que Tailscale gère le routage et le HTTPS. Quand gateway.auth.allowTailscale est activé, OpenClaw peut authentifier le trafic de l’interface de contrôle et du 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 déploiements personnels.

Le mode Funnel expose la passerelle publiquement via la fonctionnalité de point de terminaison public de Tailscale. La propre documentation de Tailscale décrit Funnel comme acheminant le trafic depuis l’internet général vers un service local. OpenClaw refuse de démarrer Funnel sauf si le mode d’authentification de la passerelle est password, mais vous choisissez quand même une exposition publique pour une surface opérateur.

La documentation de sécurité d’OpenClaw précise que l’injection de prompt et l’accès aux outils sont des risques fondamentaux pour un assistant personnel. Ne donnez pas à l’agent un moyen de se rendre silencieusement public. Utilisez Serve délibérément, é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 de Manière Sécurisée

É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 la connexion)
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 ping 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 actuel le plus sûr est : garder la passerelle sur loopback et l’exposer à votre tailnet avec Tailscale Serve.

Dans la config OpenClaw :

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

Puis démarrez la passerelle avec Serve :

Terminal window
openclaw gateway --tailscale serve

Les docs d’OpenClaw indiquent que cela maintient la passerelle sur 127.0.0.1 pendant que Tailscale fournit le HTTPS et le routage tailnet. Vous y accédez à https://<nom-magicdns>/, pas à l’IP publique de votre VPS.

Si vous préférez une liaison directe au tailnet plutôt que Serve, utilisez une authentification explicite de la passerelle :

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

Connectez-vous ensuite depuis un autre appareil du tailnet :

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

Si vous utilisez Docker ou un autre environnement de conteneurisation, soyez particulièrement prudent avec la publication de ports. Une publication comme -p 18789:18789 se lie généralement à toutes les interfaces hôte. Préférez loopback avec Tailscale Serve, ou liez le côté hôte explicitement à l’IP Tailscale après avoir vérifié 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 de 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 : Verrouiller 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_DU_SERVEUR


# Placez le durcissement dans un fichier drop-in plutôt que 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 la connexion par mot de passe et la connexion root. L’étape suivante utilise UFW pour empêcher tout SSH public tout en autorisant SSH via tailscale0.

Étape 4 : Règles de Pare-feu

Configurez un pare-feu comme deuxième couche :

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 structure : autoriser tailscale0, refuser les autres trafics entrants, 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


# Sortie attendue 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 du point de terminaison Tailscale Funnel, et non de la passerelle OpenClaw par accident.

Vérifier Ce Qui Écoute Localement

Sur votre serveur OpenClaw :

Terminal window
# Afficher tous les ports d'écoute et leurs liaisons
sudo ss -tulpn | grep LISTEN


# Recherchez des lignes comme celle-ci (bon pour Serve) :
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# Ou celle-ci (acceptable pour une liaison directe tailnet avec auth) :
# tcp   LISTEN 0   128   100.x.y.z:18789   *:*
#
# PAS comme celle-ci (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.

Audit de Sécurité Intégré

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

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

L’audit vérifie l’exposition de la passerelle, le mode Tailscale, les paramètres d’authentification, l’accès aux canaux, la politique d’outils, l’inventaire des plugins et les permissions des fichiers. Considérez --fix comme un outil 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 opérateurs. Cela ne résout pas tout :

Stockage des identifiants : OpenClaw stocke les transcriptions de sessions, les jetons OAuth et les clés API sur le disque. Assurez-vous que ces fichiers ont des permissions appropriées (chmod 600 pour les fichiers, chmod 700 pour les répertoires de config privés) et ne sont pas dans un système de versionnement. L’audit intégré vérifie cela.

Sandboxing des plugins : Les plugins s’exécutent avec les permissions complètes de votre utilisateur. Installez uniquement des plugins provenant de sources de confiance et examinez les capacités qu’ils demandent. L’outil d’audit dresse l’inventaire des plugins installés.

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

Liste de Vérification de Déploiement

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

Ressources

Loading comments...