Sécuriser ton serveur Clawdbot : le guide complet

J'ai installé fail2ban sur mon serveur Clawdbot ce soir. En moins de 60 secondes, il a banni son premier attaquant.

Pas un test. Un vrai bot était activement en train de brute-forcer SSH pendant que je configurais le pare-feu.

Jan 27 02:46:55 sshd: Invalid user oracle from 217.154.38.135
Jan 27 02:47:25 sshd: Invalid user main from 217.154.38.135
Jan 27 02:47:56 sshd: Invalid user HwHiAiUser from 217.154.38.135
Jan 27 02:48:26 sshd: Invalid user guest from 217.154.38.135
Jan 27 02:48:57 sshd: Invalid user git from 217.154.38.135

Toutes les 30 secondes. Des noms d'utilisateur différents. Automatisé. Sans relâche.

Puis fail2ban est entré en action :

2026-01-27 02:50:54 NOTICE [sshd] Ban 217.154.38.135

Terminé. Ban de 30 jours. Si tu fais tourner Clawdbot sur un VPS, tu as besoin de ça.

Pourquoi les serveurs Clawdbot sont des cibles

Les serveurs Clawdbot sont des cibles de choix parce qu'ils ont généralement :

• Un accès shell — L'agent peut exécuter des commandes
• Des clés API — Anthropic, OpenAI, plateformes de messagerie
• Des données personnelles — Logs de session, fichiers mémoire, contacts
• Une connectivité permanente — Disponibilité 24/7 sur un VPS cloud

Un attaquant qui compromet ton serveur Clawdbot accède à toutes les capacités de ton assistant IA. Il pourrait lire tes conversations, usurper ton identité sur des plateformes de messagerie, ou faire exploser tes factures API.

On va régler ça.

Étape 1 : Authentification par clé SSH (Critique)

C'est l'étape de sécurité la plus importante. L'authentification par mot de passe est le maillon faible. Les clés SSH sont cryptographiquement sûres et impossibles à brute-forcer.

Sur ta machine locale, génère une paire de clés :

ssh-keygen -t ed25519 -C "your_email@example.com"

Cela crée deux fichiers :

• ~/.ssh/id_ed25519 — Ta clé privée (ne la partage jamais)
• ~/.ssh/id_ed25519.pub — Ta clé publique (va sur le serveur)

Copie ta clé publique sur le serveur :

ssh-copy-id user@your-server-ip

Ou manuellement :

# On your local machine
cat ~/.ssh/id_ed25519.pub

# Copy the output, then on your server:
echo "your-public-key-here" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Teste que ça marche :

ssh user@your-server-ip

Si tu te connectes sans qu'on te demande de mot de passe, c'est bon.

Étape 2 : Désactiver l'authentification par mot de passe

Une fois que les clés SSH fonctionnent, désactive complètement l'authentification par mot de passe :

sudo nano /etc/ssh/sshd_config

Trouve et modifie ces lignes :

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Redémarre SSH :

sudo systemctl restart sshd

Maintenant la seule façon d'entrer, c'est avec ta clé privée. Les attaques brute-force deviennent totalement inutiles — ils essaient de deviner un mot de passe qui n'existe pas.

Étape 3 : Installer fail2ban

Même avec les clés SSH, on veut fail2ban comme couche de protection supplémentaire pour garder les logs propres et éviter le gaspillage de ressources.

sudo apt update
sudo apt install -y fail2ban

Crée une config locale :

sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 2592000
findtime = 600
EOF

Ce que ça fait :

• maxretry = 3 — Trois tentatives échouées = banni
• bantime = 2592000 — Ban de 30 jours (si tu utilises des clés SSH, toute tentative échouée est forcément un attaquant)
• findtime = 600 — Les tentatives sont comptées sur une fenêtre de 10 minutes

Lance-le :

sudo systemctl enable fail2ban
sudo systemctl restart fail2ban

Vérifie que ça fonctionne :

sudo fail2ban-client status sshd

Étape 4 : Configurer le pare-feu ufw

# Default: block everything incoming
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow only what Clawdbot needs
sudo ufw allow 22/tcp    # SSH (we'll change this later)
sudo ufw allow 80/tcp    # HTTP (if using webhooks)
sudo ufw allow 443/tcp   # HTTPS

# Enable
sudo ufw --force enable

Vérifie :

sudo ufw status verbose

Étape 5 : Piège SSH avec endlessh (La partie fun)

C'est là que ça devient intéressant. L'idée : déplacer le vrai SSH sur un port non standard, mettre endlessh sur le port 22. Les bots se connectent au port 22 et se retrouvent piégés dans une bannière infiniment lente qui envoie un octet aléatoire toutes les 10 secondes. Ils n'arrivent jamais à l'écran de connexion. Pendant ce temps, le vrai SSH tourne tranquille sur un autre port.

Ce que fait endlessh

endlessh est un piège SSH (tarpit). Quand un bot se connecte, il envoie une bannière SSH infiniment lentement — un octet aléatoire toutes les 10 secondes. La spécification SSH autorise des bannières jusqu'à 255 caractères, mais ne précise pas de vitesse minimale. La plupart des bots attendent patiemment la bannière complète, consommant un slot de connexion et perdant leur temps.

C'est comme des sables mouvants numériques pour les bots SSH.

Installer endlessh

sudo apt install endlessh

Déplacer le vrai SSH sur le port 2222

Sur Ubuntu moderne, SSH est géré par des sockets systemd, donc il faut override la config du socket :

sudo mkdir -p /etc/systemd/system/ssh.socket.d/
sudo tee /etc/systemd/system/ssh.socket.d/override.conf << 'EOF'
[Socket]
ListenStream=
ListenStream=2222
EOF

Recharge et redémarre :

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl restart ssh

Vérifie que SSH est maintenant sur le port 2222 :

ss -tlnp | grep :2222

Configurer endlessh sur le port 22

sudo mkdir -p /etc/endlessh
sudo tee /etc/endlessh/config << 'EOF'
Port 22
Delay 10000
MaxLineLength 32
MaxClients 4096
LogLevel 1
EOF

Ça configure :

• Port 22 — Le port SSH standard (les bots trouveront celui-ci)
• Delay 10000 — Envoie un octet toutes les 10 secondes
• MaxClients 4096 — Gère plein de bots piégés
• LogLevel 1 — Journalise les connexions pour le divertissement

Corriger le service systemd

endlessh peut échouer avec une erreur NAMESPACE sur les systèmes récents. Crée un override du service :

sudo mkdir -p /etc/systemd/system/endlessh.service.d/
sudo tee /etc/systemd/system/endlessh.service.d/override.conf << 'EOF'
[Service]
PrivateUsers=false
EOF

Lancer endlessh

sudo systemctl daemon-reload
sudo systemctl enable endlessh
sudo systemctl start endlessh

Vérifie que ça tourne :

sudo systemctl status endlessh
ss -tlnp | grep :22

Mettre à jour ufw pour le nouveau port SSH

# Allow the new SSH port
sudo ufw allow 2222/tcp

# Remove the old SSH rule (port 22 is now the tarpit)
sudo ufw delete allow 22/tcp

Tester le piège

Depuis une autre machine, essaie de te connecter au port 22 :

ssh user@your-server-ip -p 22

Ça devrait juste rester bloqué, en envoyant un caractère toutes les 10 secondes. Au bout d'un moment tu verras une bannière super lente et illisible. Appuie sur Ctrl+C pour en sortir.

Maintenant essaie le vrai SSH :

ssh user@your-server-ip -p 2222

Connexion instantanée avec ta clé SSH.

Les résultats

Les bots perdent leur temps sur le port 22 pendant que ton vrai SSH tourne tranquille sur le 2222. Tes logs restent propres parce que les tentatives échouées frappent le piège, pas ton vrai service SSH. Regarder journalctl -f -u endlessh est étonnamment divertissant — des bots qui se connectent et qui... attendent.

C'est vraiment efficace ?

Un chercheur a fait tourner endlessh pendant des mois et collecté des données sur les bots piégés. Les résultats sont hilarants :

• Un bot maintenait 416 connexions simultanées ouvertes en même temps — il en ouvrait sans cesse de nouvelles sans fermer les anciennes
• Une seule IP est restée connectée pendant 690 172 secondes — soit 8 jours d'affilée — téléchargeant 1,2 Mo de données aléatoires en pensant que c'était une bannière SSH
• Certaines connexions duraient plus de 12 000 secondes (3,3 heures) avant que le bot abandonne
• Le temps de piégeage médian était de 17 secondes (les bots "intelligents" avec des timeouts), mais la moyenne était de 119 secondes — tirée vers le haut par les bots idiots qui attendent indéfiniment

La qualité des logiciels de scan souterrains varie énormément. Certains bots ont un timeout de 15 secondes et passent à autre chose. D'autres n'ont aucun timeout — ils resteront là jusqu'à la mort thermique de l'univers en attendant un écran de connexion qui n'arrivera jamais.

Et le meilleur : endlessh consomme quasi zéro ressource. C'est un seul processus qui gère des milliers de connexions avec un minimum de CPU et de mémoire. Ce sont les bots qui brûlent des ressources, pas toi.

Surveiller le piège

Regarde les bots se faire piéger en temps réel :

journalctl -f -u endlessh

Compte les connexions piégées en cours :

ss -tn | grep :22 | grep ESTAB | wc -l

Étape 6 : Changer le port SSH (Bref)

On a déjà déplacé SSH sur le port 2222 pour le piège, mais voici l'approche générale si tu veux juste changer de port sans endlessh :

# In /etc/ssh/sshd_config
Port 2222

Mets à jour le pare-feu :

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo systemctl restart sshd

La sécurité par l'obscurité n'est pas de la vraie sécurité, mais ça réduit le bruit des scans aléatoires. Combiné avec les clés SSH et fail2ban, c'est efficace.

Étape 7 : Gestion des secrets avec pass

Ne stocke pas tes clés API et mots de passe en clair dans des fichiers de config. Utilise pass — le gestionnaire de mots de passe Unix standard.

Installe-le :

sudo apt install pass gnupg

Configure-le :

# Generate a GPG key (if you don't have one)
gpg --gen-key

# Initialize pass with your GPG key
pass init "your-email@example.com"

Stocke des secrets :

pass insert api/anthropic
pass insert api/openai
pass insert gmail/app-password

Récupère des secrets dans tes scripts :

export ANTHROPIC_API_KEY=$(pass show api/anthropic)

Pourquoi c'est important :

• Les secrets sont chiffrés avec GPG au repos
• Même si quelqu'un accède à ton système de fichiers, il ne peut pas lire les mots de passe sans ta clé GPG
• Tu peux synchroniser ton store de mots de passe via git (en toute sécurité, puisque tout est chiffré)
• Fonctionne très bien avec Clawdbot — stocke tes clés API et tokens de canaux en toute sécurité

Ton répertoire ~/.password-store/ est chiffré. Ton ~/.clawdbot/clawdbot.json avec les tokens en clair ? Pas vraiment.

Étape 8 : Audit de sécurité Clawdbot

Clawdbot a un scanner de sécurité intégré. Lance-le :

clawdbot security audit

Pour une vérification plus poussée :

clawdbot security audit --deep

Pour corriger automatiquement les problèmes courants :

clawdbot security audit --fix

Ce que vérifie l'audit

• Accès entrant — Est-ce que des inconnus peuvent envoyer des messages à ton bot ?
• Rayon d'action des outils — Est-ce qu'une injection de prompt pourrait mener à un accès shell ?
• Exposition réseau — Ton Gateway est-il exposé sans authentification ?
• Contrôle du navigateur — Le contrôle distant du navigateur est-il sécurisé ?
• Permissions disque — Les credentials et les logs sont-ils protégés ?
• Plugins — Des extensions non fiables sont-elles chargées ?

Corriger les permissions du workspace

L'audit va probablement avertir sur les permissions. Corrige-les :

chmod 700 ~/.clawdbot
chmod 600 ~/.clawdbot/clawdbot.json

Ça garantit que seul ton utilisateur peut lire la config et les credentials de Clawdbot.

Emplacements de stockage des credentials

Sache où vivent tes secrets :

• Token Telegram : config ou channels.telegram.tokenFile
• Auth WhatsApp : ~/.clawdbot/credentials/whatsapp/*/creds.json
• Allowlists de pairing : ~/.clawdbot/credentials/*-allowFrom.json
• Logs de session : ~/.clawdbot/agents/*/sessions/*.jsonl

Tout ça devrait être lisible uniquement par ton utilisateur (pas groupe/world).

Étape 9 : Sécurité des canaux

Verrouiller les DMs

Par défaut, Clawdbot peut accepter des messages de n'importe qui. Resserre ça :

Dans ta config, mets les politiques de DM sur allowlist :

{
  "channels": {
    "telegram": {
      "dmPolicy": "allowlist",
      "dmAllowFrom": ["your_telegram_id"]
    }
  }
}

Verrouiller les groupes

Pareil pour les groupes — utilise des allowlists au lieu de laisser ouvert :

{
  "groupPolicy": "allowlist",
  "groupAllowFrom": ["allowed_group_id"]
}

L'audit de sécurité signalera les politiques ouvertes.

Étape 10 : Signaler les attaquants à AbuseIPDB

Bloquer les attaquants localement, c'est bien. Les faire blacklister globalement, c'est mieux.

AbuseIPDB est une base de données communautaire d'IPs abusives. Quand tu signales un attaquant, chaque autre serveur utilisant leur blocklist en bénéficie. C'est de la défense collective.

Obtenir une clé API gratuite

Inscris-toi sur abuseipdb.com — le tier gratuit autorise 1000 signalements/jour.

Stocke-la en sécurité :

pass insert abuseipdb/api-key

Signaler une IP bannie

ABUSEIPDB_KEY=$(pass show abuseipdb/api-key)

curl -s https://api.abuseipdb.com/api/v2/report \
  -H "Key: $ABUSEIPDB_KEY" \
  -H "Accept: application/json" \
  --data-urlencode "ip=2.57.122.209" \
  -d "categories=18,22" \
  --data-urlencode "comment=SSH brute-force (fail2ban auto-ban)"

Catégories 18,22 = brute-force + SSH.

Auto-signalement avec Clawdbot

J'ai créé un skill Clawdbot qui signale automatiquement chaque nouveau ban à AbuseIPDB. Si tu fais tourner Clawdbot, installe-le :

clawdhub install fail2ban-reporter

Ou récupère-le depuis GitHub :

git clone https://github.com/jestersimpps/clawdbot-fail2ban-reporter.git
sudo bash clawdbot-fail2ban-reporter/scripts/install.sh

Après la configuration, chaque ban fail2ban est automatiquement signalé à AbuseIPDB. Zéro effort, impact communautaire maximum.

Étape 11 : Surveiller les attaques en cours

Vérifie qui a été banni :

sudo fail2ban-client status sshd

Regarde les bans en direct :

sudo tail -f /var/log/fail2ban.log | grep Ban

Vérifie les tentatives SSH récentes :

journalctl -u ssh -n 50 | grep -E "Failed|Invalid"

Regarde endlessh piéger les bots en temps réel :

sudo journalctl -f -u endlessh

Tu verras des connexions qui restent bloquées. Chacune est un bot qui perd son temps au lieu d'embêter ton vrai SSH.

Ce que les attaquants essaient vraiment

D'après mes logs serveur sur une seule heure :

• oracle — Utilisateur par défaut Oracle DB
• postgres — Par défaut PostgreSQL
• git — Serveurs GitLab/Gitea
• solana — Opérateurs de nœuds crypto (cible populaire)
• HwHiAiUser — Par défaut des appareils Huawei
• admin, root — Les classiques
• ftpuser — FTP legacy

Ils spamment des noms d'utilisateur courants en espérant que quelque chose passe. fail2ban les arrête après 3 tentatives, mais maintenant ils tombent d'abord dans le piège.

Le setup complet en 5 minutes

Copie-colle ce bloc entier pour sécuriser un serveur Clawdbot fraîchement installé :

# Install security tools
sudo apt update && sudo apt install -y fail2ban ufw endlessh gnupg pass

# Generate SSH key (run on your LOCAL machine)
ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id user@your-server-ip

# Disable password auth (ON THE SERVER)
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config

# Move SSH to port 2222 for tarpit setup
sudo mkdir -p /etc/systemd/system/ssh.socket.d/
sudo tee /etc/systemd/system/ssh.socket.d/override.conf << 'EOF'
[Socket]
ListenStream=
ListenStream=2222
EOF

# Configure endlessh tarpit on port 22
sudo mkdir -p /etc/endlessh
sudo tee /etc/endlessh/config << 'EOF'
Port 22
Delay 10000
MaxLineLength 32
MaxClients 4096
LogLevel 1
EOF

# Fix endlessh systemd service
sudo mkdir -p /etc/systemd/system/endlessh.service.d/
sudo tee /etc/systemd/system/endlessh.service.d/override.conf << 'EOF'
[Service]
PrivateUsers=false
EOF

# Configure fail2ban
sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 2592000
findtime = 600
EOF

# Configure firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp  # New SSH port
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS
sudo ufw --force enable

# Start everything
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket ssh
sudo systemctl enable --now fail2ban endlessh

# Fix Clawdbot permissions
chmod 700 ~/.clawdbot
chmod 600 ~/.clawdbot/clawdbot.json 2>/dev/null

# Run Clawdbot security audit
clawdbot security audit --fix

# Verify everything
echo "=== SSH on port 2222 ==="
ss -tlnp | grep :2222
echo "=== endlessh tarpit on port 22 ==="
ss -tlnp | grep :22
echo "=== fail2ban status ==="
sudo fail2ban-client status sshd
echo "=== ufw status ==="
sudo ufw status verbose
echo "=== Clawdbot security ==="
clawdbot security audit

Important : Après avoir exécuté ça, connecte-toi via SSH sur le nouveau port :

ssh user@your-server-ip -p 2222

La stack de sécurité complète

Après avoir suivi ce guide, ton serveur Clawdbot dispose de :

• Authentification par clé SSH — Aucun mot de passe à brute-forcer
• Auth par mot de passe désactivée — Même s'ils devinent juste, ça ne marchera pas
• Piège endlessh — Les bots perdent leur temps sur le port 22 pendant que le vrai SSH se cache sur le 2222
• fail2ban — 3 tentatives → ban de 30 jours (couche de secours)
• Pare-feu ufw — Seuls les ports nécessaires sont exposés
• pass — Secrets chiffrés avec GPG au repos
• Pairing Clawdbot — Les inconnus ne peuvent pas envoyer de messages à ton bot
• Permissions correctes — Config et credentials verrouillés
• Signalement AbuseIPDB — Les attaquants sont blacklistés globalement

C'est de la défense en profondeur. Plusieurs couches, chacune rendant l'attaque suivante plus difficile. Le piège, c'est la cerise sur le gâteau — au lieu de simplement bloquer les attaquants, tu gaspilles leur temps et leurs ressources tout en gardant tes vrais services cachés.

Ce n'est pas de la paranoïa quand chaque serveur avec une IP publique se fait attaquer en quelques heures. Cinq minutes de configuration. Dors mieux la nuit.

Pour plus de détails sur la sécurité Clawdbot, consulte la documentation officielle de sécurité.