DanLevy.net

IT

Il tuo assistente AI mi ha dato accesso alla shell

Come mettere in sicurezza la tua installazione locale o VPS di OpenClaw/Moltbot

OpenClaw (precedentemente Clawdbot/Moltbot) ti offre un assistente AI personale che funziona su WhatsApp, Slack, Discord, iMessage e altri canali. Ma se metti il suo gateway, i controlli dei nodi o SSH su internet pubblico senza un’autenticazione forte, stai dando a estranei un percorso verso l’accesso shell sulla tua macchina.

Questa guida mostra la configurazione predefinita più sicura: tieni il gateway di OpenClaw su loopback, esponilo solo alla tua tailnet con Tailscale Serve, blocca SSH e verifica dall’esterno che il gateway non sia pubblico.

L’adozione rapida del progetto ha rivelato reali problemi di sicurezza: scansioni Shodan hanno trovato 2.847 istanze esposte nelle prime settimane, e un issue di audit di sicurezza su GitHub ha riportato 512 risultati nel codice. Parte di questi proveniva da scanner automatizzati e alcune cose sono cambiate dopo il rename a OpenClaw del gennaio 2026, quindi considera il numero come un campanello d’allarme piuttosto che un conteggio preciso delle vulnerabilità attuali. Non devi essere un esperto di sicurezza—devi solo evitare di pubblicizzare superfici operative prima del deploy.

Cosa stai effettivamente esponendo

A seconda di come hai installato ed esposto il tutto, ci sono tre superfici che vale la pena controllare:

La documentazione attuale di OpenClaw sull’accesso remoto dice che il WebSocket del gateway si lega al loopback per impostazione predefinita e raccomanda di mantenerlo solo su loopback a meno che tu non scelga intenzionalmente un bind LAN/tailnet/personalizzato. Questo è positivo. Il rischio si presenta quando sovrascrivi questa impostazione predefinita, pubblichi porte Docker, aggiungi un reverse proxy, attivi Funnel o lasci SSH aperto al mondo.

Il gateway è il punto critico. È la superficie operativa del tuo assistente, inclusi i percorsi di invocazione degli strumenti. Se è raggiungibile da internet e l’autenticazione è assente, debole, bypassata o divulgata, un attaccante potrebbe essere in grado di guidare l’agente o invocare strumenti con i permessi del tuo utente.

Il controllo del browser è quasi altrettanto sensibile. I documenti attuali di OpenClaw raccomandano di eseguire il controllo del browser attraverso un host nodo abbinato sulla macchina del browser e di trattare l’abbinamento dei nodi come l’accesso operativo. Se un gateway può invocare system.run su un nodo abbinato, questa è esecuzione remota di codice su quel nodo, soggetta alla policy del nodo del gateway e alle approvazioni di esecuzione del nodo stesso.

SSH è SSH. Se stai usando l’autenticazione tramite password, i tentativi di forza bruta sono inevitabili su un VPS pubblico.

La soluzione Tailscale

Per OpenClaw, Tailscale ti dà accesso remoto senza pubblicare servizi operativi:

  1. La tua istanza di OpenClaw gira su un VPS o una macchina locale
  2. Il gateway rimane legato al loopback e viene raggiunto tramite Tailscale Serve, oppure si lega direttamente all’IP della tailnet con autenticazione esplicita
  3. Installi Tailscale sia sul server che sui tuoi dispositivi personali
  4. Accedi a OpenClaw tramite il suo IP Tailscale o nome MagicDNS
  5. Tutti gli altri su internet non vedono nulla, a meno che tu non abiliti intenzionalmente Funnel o un altro proxy pubblico

Dovresti lasciare che OpenClaw gestisca Tailscale?

OpenClaw ha un’integrazione Tailscale integrata che può configurare tailscale serve o tailscale funnel per il gateway.

Modalità Serve mantiene tutto sulla tua tailnet. Il gateway resta legato a 127.0.0.1 mentre Tailscale gestisce il routing e l’HTTPS. Quando gateway.auth.allowTailscale è abilitato, OpenClaw può autenticare il traffico dell’Interfaccia di Controllo/WebSocket usando gli header di identità Tailscale e verificare la fonte con tailscale whois. Questa è la modalità giusta per la maggior parte delle installazioni personali.

Modalità Funnel espone il gateway pubblicamente tramite la funzione di endpoint pubblico di Tailscale. La stessa documentazione di Tailscale descrive Funnel come instradamento del traffico da internet più ampio a un servizio locale. OpenClaw rifiuta di avviare Funnel a meno che la modalità di autenticazione del gateway non sia password, ma stai comunque scegliendo l’esposizione pubblica per una superficie operativa.

La documentazione sulla sicurezza di OpenClaw è chiara: l’iniezione di prompt e l’accesso agli strumenti sono rischi centrali per un assistente personale. Non dare all’agente un percorso per rendersi silenziosamente pubblico. Usa Serve deliberatamente, evita Funnel a meno che tu non abbia realmente bisogno di accesso pubblico e richiedi l’approvazione di esecuzione per qualsiasi comando tailscale.

Configurare OpenClaw in modo sicuro

Passo 1: Installa Tailscale

Sul tuo VPS o server locale:

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


# Autenticati (apre un browser per il login)
sudo tailscale up


# Ottieni il tuo IP Tailscale
tailscale ip -4
# Output: 100.x.x.x

Sulla tua macchina client, installa Tailscale dalla pagina di download ufficiale e accedi alla stessa tailnet.

Ora entrambe le macchine sono sulla stessa rete privata. Puoi fare ping al tuo VPS usando il suo IP Tailscale e passerà attraverso il tunnel crittografato.

Passo 2: Configura OpenClaw per usare Tailscale

Il modello attuale più sicuro è: tieni il gateway su loopback ed esponilo alla tua tailnet con Tailscale Serve.

Nel config di OpenClaw:

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

Poi avvia il gateway con Serve:

Terminal window
openclaw gateway --tailscale serve

I documenti di OpenClaw dicono che questo mantiene il gateway su 127.0.0.1 mentre Tailscale fornisce HTTPS e routing sulla tailnet. Lo apri all’indirizzo https://<nome-magicdns>/, non al tuo IP pubblico del VPS.

Se preferisci un bind diretto alla tailnet invece di Serve, usa un’autenticazione esplicita del gateway:

{
  gateway: {
    bind: "tailnet",
    auth: {
      mode: "token",
      token: "sostituisci-con-un-token-lungo-e-casuale",
    },
  },
}

Poi connettiti da un altro dispositivo sulla tailnet:

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

Se stai usando Docker o un altro runtime di container, fai molta attenzione alla pubblicazione delle porte. Una pubblicazione come -p 18789:18789 di solito si lega a tutte le interfacce host. Preferisci loopback più Tailscale Serve, o lega il lato host esplicitamente all’IP Tailscale dopo aver confermato che il container riceve ancora traffico:

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

Dopo qualsiasi modifica a Docker, controlla dall’esterno con nmap e localmente con ss. Docker può bypassare o riordinare le supposizioni del firewall host se non ne tieni conto.

Passo 3: Blocca SSH

Anche con Tailscale, dovresti mettere in sicurezza SSH correttamente:

Terminal window
# Tieni aperta la sessione SSH corrente mentre fai questo.
# Prima, dalla tua macchina client, conferma di poter usare SSH via Tailscale:
ssh tuo-utente@IP-TAILSCALE-SERVER


# Metti le restrizioni in un file drop-in invece di riscrivere sshd_config.
sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF


# Convalida prima di ricaricare. Non saltare questo passaggio.
sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Questo disabilita l’accesso tramite password e il login di root. Il passo successivo usa UFW per impedire l’SSH pubblico mantenendo comunque la possibilità di SSH attraverso tailscale0.

Passo 4: Regole del firewall

Imposta un firewall come secondo livello:

Terminal window
# Usando 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

La stessa guida all’indurimento di Ubuntu di Tailscale usa questa stessa struttura: permetti tailscale0, nega altro traffico in entrata, poi verifica che SSH pubblico vada in timeout mentre SSH all’indirizzo 100.x.y.z funzioni ancora. Se hai un sito web pubblico sullo stesso VPS, mantieni solo le regole pubbliche di cui hai veramente bisogno, come 80/tcp e 443/tcp.

Verificare la tua esposizione

Controlla le porte aperte dall’esterno

Da una macchina che NON è sulla tua rete Tailscale:

Terminal window
# Controlla se le porte pubbliche comuni sono esposte
nmap -p 22,80,443,18789 IL_TUO_IP_PUBBLICO


# Output previsto per un'istanza protetta:
# 22/tcp   filtered ssh
# 18789/tcp filtered unknown

Se 22 o 18789 mostra open invece di filtered o closed, hai un problema. Se 80 o 443 è aperta, assicurati che sia solo il tuo sito web pubblico intenzionale o l’endpoint Tailscale Funnel, non il gateway di OpenClaw per sbaglio.

Controlla cosa è in ascolto localmente

Sul tuo server OpenClaw:

Terminal window
# Mostra tutte le porte in ascolto e a cosa sono legate
sudo ss -tulpn | grep LISTEN


# Cerca righe come queste (buono per Serve):
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# O questo (accettabile per bind diretto alla tailnet con autenticazione):
# tcp   LISTEN 0   128   100.x.y.z:18789   *:*
#
# NON come questa (male):
# tcp   LISTEN 0   128   0.0.0.0:18789     *:*

Se vedi 0.0.0.0 o ::: (equivalente IPv6), quel servizio è esposto al mondo.

Audit di sicurezza integrato

OpenClaw include un comando di audit di sicurezza che controlla la tua configurazione rispetto alle migliori pratiche di sicurezza:

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

L’audit controlla l’esposizione del gateway, la modalità Tailscale, le impostazioni di autenticazione, l’accesso ai canali, la policy degli strumenti, l’inventario dei plugin e i permessi dei file. Tratta --fix come un utile aiutante, non come un sostituto della lettura dei risultati.

Cosa questo non risolve

Tailscale elimina l’errore più grande: l’esposizione operativa pubblica. Non risolve tutto:

Archiviazione delle credenziali: OpenClaw memorizza trascrizioni di sessioni, token OAuth e chiavi API su disco. Assicurati che questi abbiano permessi file appropriati (chmod 600 per i file, chmod 700 per le directory di configurazione private) e non siano nel controllo versione. L’audit integrato controlla questo.

Sandboxing dei plugin: I plugin girano con tutti i permessi del tuo utente. Installa solo plugin da fonti di cui ti fidi e rivedi quali capacità richiedono. Lo strumento di audit cataloga i plugin installati.

Sicurezza del dispositivo: Se qualcuno compromette il tuo account Tailscale o ruba un dispositivo sulla tua tailnet, può accedere alla tua istanza OpenClaw. Abilita l’autorizzazione dei dispositivi Tailscale per richiedere approvazione per nuovi dispositivi.

Checklist di deploy

Prima di considerare la tua istanza OpenClaw/Moltbot pronta per la produzione:

Risorse

Loading comments...