Sécuriser OpenClaw : guide complet

Introduction

Vous avez suivi le guide d'installation OpenClaw sur VPS et votre instance tourne. Bonne nouvelle. Mauvaise nouvelle : elle est probablement accessible en HTTP sur le port 3000, sans authentification, avec vos clés API dans un fichier .env lisible par n'importe quel process. Ce guide couvre les cinq couches de sécurité indispensables avant toute mise en production : gestion des secrets, authentification de l'interface, reverse proxy HTTPS avec Nginx, pare-feu UFW et protection brute-force avec fail2ban. Chaque étape inclut les commandes exactes à exécuter.

Résumé rapide

• Ne jamais committer le fichier .env — ajouter .env au .gitignore dès maintenant
• Activer l'authentification dans la config OpenClaw avant toute exposition réseau
• Mettre Nginx en reverse proxy HTTPS avec Certbot (3 commandes)
• Restreindre UFW : autoriser uniquement les ports 80, 443 et 22
• Activer fail2ban pour bloquer les tentatives de connexion répétées

Pourquoi la sécurité d'OpenClaw mérite une attention particulière

OpenClaw est un orchestrateur d'agents IA. En production, il exécute des appels vers des APIs tierces (OpenAI, Anthropic, outils externes), gère des workflows automatisés et peut déclencher des actions sur vos systèmes. Une instance mal configurée expose plusieurs vecteurs d'attaque simultanément :

Exposition des clés API. Les clés OpenAI ou Anthropic stockées dans .env peuvent être lues par tout utilisateur avec accès au serveur, ou exfiltrées si le fichier est commité dans Git. Une fuite de clé se traduit en coûts non maîtrisés et en accès à vos données.

Interface non authentifiée. Par défaut, OpenClaw peut être configuré sans mot de passe. Tout accès réseau à l'interface permet de lancer des agents, consulter les logs et modifier les configurations.

Port 3000 ouvert en HTTP. Sans reverse proxy, le trafic circule en clair. Les credentials de l'interface sont transmis sans chiffrement et peuvent être interceptés sur le réseau.

Surface d'attaque élargie. Chaque port ouvert inutilement est un vecteur potentiel. La règle minimale est de n'exposer que ce qui est strictement nécessaire.

La configuration OpenClaw couvre les paramètres applicatifs. Ce guide se concentre sur la couche infrastructure, indépendante de la version d'OpenClaw utilisée.

Sécuriser OpenClaw étape par étape

1. Gérer les clés API et variables d'environnement

Ne jamais committer .env. C'est la règle numéro un, non négociable.

# Vérifier que .env est ignoré par Git
cat .gitignore | grep .env

# Si absent, l'ajouter immédiatement
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.*.local" >> .gitignore

Si vous avez déjà commité .env par erreur, retirez-le de l'historique Git avant d'aller plus loin — le fichier reste accessible dans les anciens commits même après suppression.

Restreindre les permissions du fichier .env. Sur le serveur, seul l'utilisateur qui exécute OpenClaw doit pouvoir le lire.

# Propriétaire : utilisateur openclaw (ou votre utilisateur applicatif)
chown openclaw:openclaw /home/openclaw/app/.env

# Lecture/écriture propriétaire uniquement, aucun accès pour les autres
chmod 600 /home/openclaw/app/.env

# Vérification
ls -la /home/openclaw/app/.env
# Résultat attendu : -rw------- 1 openclaw openclaw ...

Rotation des clés. Générez des clés API distinctes pour chaque environnement (dev, staging, prod). En cas de doute sur une fuite, révoquez et remplacez la clé depuis la console du fournisseur — pas besoin de redémarrer le serveur si la clé est chargée au démarrage du process.

2. Authentification de l'interface OpenClaw

Avant d'exposer OpenClaw, activez l'authentification dans le fichier de configuration principal. Consultez la configuration OpenClaw pour localiser ce fichier selon votre installation.

# config.yaml ou config.json selon la version
auth:
  enabled: true
  username: "admin"
  password: "votre-mot-de-passe-fort-ici"
  anonymous_access: false

Points critiques :

• anonymous_access: false — désactive l'accès sans credentials
• Utilisez un mot de passe d'au moins 20 caractères généré aléatoirement (openssl rand -base64 24)
• Redémarrez OpenClaw après modification pour que la configuration soit prise en compte

# Générer un mot de passe robuste
openssl rand -base64 24
# Exemple de sortie : 3kP+mJq8ZnX2/vLtRdWo4NQsYceBhFpA

# Redémarrer le service
sudo systemctl restart openclaw

3. Reverse proxy HTTPS avec Nginx

L'objectif est de rendre OpenClaw accessible via HTTPS sur le port 443, tout en bloquant l'accès direct au port 3000 depuis l'extérieur.

Installation de Nginx et Certbot.

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

Configuration du virtual host Nginx.

sudo nano /etc/nginx/sites-available/openclaw

server {
    listen 80;
    server_name votre-domaine.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

# Activer le site
sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/

# Tester la configuration
sudo nginx -t

# Recharger Nginx
sudo systemctl reload nginx

Obtenir un certificat Let's Encrypt avec Certbot.

# Remplacer votre-domaine.com par votre domaine réel
sudo certbot --nginx -d votre-domaine.com

# Certbot modifie automatiquement la config Nginx pour HTTPS
# Vérifier le renouvellement automatique
sudo certbot renew --dry-run

Certbot configure automatiquement la redirection HTTP → HTTPS et l'en-tête HSTS. Votre interface OpenClaw est maintenant accessible via https://votre-domaine.com.

4. Pare-feu avec UFW

UFW (Uncomplicated Firewall) est installé sur Ubuntu par défaut. L'objectif est d'autoriser uniquement les ports strictement nécessaires.

# Vérifier l'état actuel
sudo ufw status

# Réinitialiser les règles (attention : déconnecte les connexions actives)
# Ne faites cela que si vous avez accès console à votre serveur

# Autoriser SSH (à faire AVANT d'activer UFW)
sudo ufw allow 22/tcp

# Autoriser HTTP et HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Activer le pare-feu
sudo ufw enable

# Vérifier les règles actives
sudo ufw status verbose

Ce que vous ne devez pas faire : laisser le port 3000 ouvert. Si Nginx est en place, OpenClaw ne doit écouter que sur 127.0.0.1:3000, pas sur 0.0.0.0:3000.

# Vérifier que le port 3000 n'est pas accessible de l'extérieur
sudo ufw deny 3000/tcp

# Vérifier que OpenClaw écoute sur localhost uniquement
sudo ss -tlnp | grep 3000
# Résultat attendu : 127.0.0.1:3000 (pas 0.0.0.0:3000)

5. Protection brute-force avec fail2ban

fail2ban analyse les logs et bannit les IPs qui tentent trop de connexions en échec.

# Installation
sudo apt install fail2ban -y

# Créer une configuration locale (ne pas modifier jail.conf directement)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Configuration minimale recommandée.

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5
backend  = systemd

[sshd]
enabled = true
port    = ssh
logpath = %(sshd_log)s

[nginx-http-auth]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 5
bantime  = 3600

# Démarrer fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Vérifier l'état des jails
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo fail2ban-client status nginx-http-auth

6. Bonnes pratiques complémentaires

Rotation des clés API. Programmez une rotation trimestrielle des clés, ou immédiatement si un collaborateur quitte l'équipe. Gardez un journal des clés actives.

Logs d'audit. Activez les logs d'accès Nginx et les logs applicatifs OpenClaw. Configurez une rétention minimale de 30 jours. En cas d'incident, ces logs sont votre seule source de vérité.

# Vérifier les logs d'accès Nginx
tail -f /var/log/nginx/access.log

# Vérifier les logs OpenClaw
journalctl -u openclaw -f

Mises à jour régulières. Appliquez les mises à jour de sécurité du système chaque semaine.

sudo apt update && sudo apt upgrade -y

Sauvegardes de la configuration. Avant toute modification de configuration, sauvegardez l'état actuel.

cp /etc/nginx/sites-available/openclaw /etc/nginx/sites-available/openclaw.bak

Exemple concret : setup complet sur un VPS Ubuntu 22.04

Contexte : VPS Ubuntu 22.04 avec OpenClaw déjà installé et fonctionnel sur le port 3000. Domaine agents.monapp.fr pointant vers l'IP du serveur.

Séquence complète.

# 1. Sécuriser .env
chmod 600 /home/deploy/openclaw/.env
echo ".env" >> /home/deploy/openclaw/.gitignore

# 2. Installer Nginx + Certbot
sudo apt update && sudo apt install nginx certbot python3-certbot-nginx fail2ban -y

# 3. Créer la config Nginx
sudo tee /etc/nginx/sites-available/openclaw > /dev/null <<EOF
server {
    listen 80;
    server_name agents.monapp.fr;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-Proto \$scheme;
    }
}
EOF

sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

# 4. Certificat SSL
sudo certbot --nginx -d agents.monapp.fr --non-interactive --agree-tos -m admin@monapp.fr

# 5. UFW
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
sudo ufw deny 3000/tcp && sudo ufw --force enable

# 6. fail2ban
sudo systemctl enable fail2ban && sudo systemctl start fail2ban

Résultat attendu : OpenClaw est accessible sur https://agents.monapp.fr, le port 3000 est fermé depuis l'extérieur, SSH est protégé contre le brute-force et le trafic est chiffré TLS.

Vérification finale.

# Tester HTTPS
curl -I https://agents.monapp.fr
# Attendu : HTTP/2 200 ou 302 vers la page de login

# Vérifier que le port 3000 est inaccessible
curl http://agents.monapp.fr:3000
# Attendu : connexion refusée ou timeout

Bonnes pratiques

Erreurs fréquentes à éviter.

• Committer .env dans Git : vérifiez git log --all --full-history -- .env pour détecter un commit accidentel. Si c'est le cas, révoquez les clés immédiatement et purgez l'historique avec git filter-repo.
• Laisser le port 3000 ouvert : même avec Nginx en place, si OpenClaw écoute sur 0.0.0.0:3000, le port est accessible. Vérifiez avec ss -tlnp | grep 3000.
• Oublier le renouvellement Let's Encrypt : Certbot installe un timer systemd automatique, mais vérifiez qu'il est actif avec systemctl status certbot.timer.
• Désactiver fail2ban après un faux positif : préférez débannir l'IP légitime avec sudo fail2ban-client set sshd unbanip VOTRE_IP plutôt que de désactiver la protection.

Limites connues.

fail2ban ne protège pas contre les attaques distribuées (DDoS) provenant de milliers d'IPs différentes. Pour ce cas, un WAF (Cloudflare, pare-feu OVH) est nécessaire. La configuration présentée ici couvre les menaces courantes sur une instance self-hosted.

Questions fréquentes

Comment savoir si mon instance OpenClaw est exposée sur Internet ?

Utilisez sudo ss -tlnp | grep 3000 pour voir sur quelle interface OpenClaw écoute. Si vous voyez 0.0.0.0:3000, le port est accessible depuis l'extérieur. Vérifiez aussi avec un scanner en ligne comme shodan.io en cherchant votre IP.

Faut-il un domaine pour mettre HTTPS en place avec Certbot ?

Oui, Certbot Let's Encrypt requiert un nom de domaine pointant vers votre serveur. Si vous n'avez pas de domaine, vous pouvez utiliser un certificat auto-signé pour les environnements privés, mais les navigateurs afficheront un avertissement.

OpenClaw est-il sécurisé par défaut après l'installation ?

Non. Par défaut, OpenClaw écoute sur le port 3000 sans authentification obligatoire. La sécurité est à configurer manuellement, ce qui est l'objet de ce guide.

Comment tester que fail2ban fonctionne correctement ?

Effectuez volontairement 6 tentatives de connexion SSH échouées depuis une IP de test, puis vérifiez avec sudo fail2ban-client status sshd. L'IP doit apparaître dans la liste Banned IP list.

Est-il possible d'utiliser un autre reverse proxy qu'Nginx ?

Oui. Caddy est une alternative qui gère automatiquement les certificats Let's Encrypt sans configuration Certbot. La configuration est plus simple mais Nginx reste le standard sur les VPS Ubuntu. Traefik est une option pertinente si vous orchestrez plusieurs services avec Docker.

Articles liés

Votre instance OpenClaw est maintenant protégée contre les vecteurs d'attaque les plus courants. La prochaine étape logique est de passer à l'étape production, avec health checks, stratégie de rollback et monitoring. Combinez ce guide avec les ressources suivantes pour un setup complet et résilient.

• Installer OpenClaw sur un VPS : guide pas à pas
• Configurer OpenClaw : paramètres et options essentielles
• Mettre OpenClaw en production avec health checks et rollback
• OpenClaw avec Docker : déploiement conteneurisé
• Mettre OpenClaw en production avec health checks et rollback