DanLevy.net

Il Mio Assistente AI Mi Ha Dato Accesso alla Shell

Come proteggere il tuo setup OpenClaw/Moltbot locale o su VPS

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

Questa guida mostra il default più sicuro: mantieni il gateway di OpenClaw su loopback, esponilo solo alla tua tailnet con Tailscale Serve, proteggi SSH e verifica dall’esterno che il gateway non sia pubblico.

L’adozione rapida del progetto ha rivelato preoccupazioni di sicurezza reali: le scansioni di Shodan hanno trovato 2.847 istanze esposte nelle prime settimane, e un issue di audit di sicurezza su GitHub ha segnalato 512 findings nel codebase. Parte di questo era output di scanner automatizzati e parte è cambiato dopo il rename a OpenClaw del gennaio 2026, quindi tratta il numero come un segnale d’allarme piuttosto che un conteggio preciso e attuale delle vulnerabilità. Non devi essere un esperto di sicurezza — devi solo evitare di pubblicare superfici operatore prima di fare il deploy.

Cosa Stai Effettivamente Espone

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

L’attuale documentazione sull’accesso remoto di OpenClaw dice che il gateway WebSocket si binda su loopback di default e raccomanda di mantenerlo solo su loopback a meno che tu non scelga intenzionalmente un bind LAN/tailnet/custom. Questo è un bene. Il rischio si presenta quando sovrascrivi quel default, pubblichi porte Docker, aggiungi un reverse proxy, attivi Funnel o lasci SSH aperto al mondo.

Il gateway è il punto più critico. È la superficie operatore per il tuo assistente, inclusi i percorsi di invocazione dei tool. Se è raggiungibile da internet e l’autenticazione è assente, debole, bypassata o trapelata, un attaccante potrebbe essere in grado di pilotare l’agent o invocare tool con i permessi del tuo utente.

Il controllo browser è quasi altrettanto sensibile. L’attuale documentazione di OpenClaw raccomanda di eseguire il controllo browser attraverso un host nodo accoppiato sulla macchina browser e di trattare il pairing dei nodi come accesso operatore. Se un gateway può invocare system.run su un nodo accoppiato, quella è esecuzione di codice remoto su quel nodo, soggetta alla policy dei nodi del gateway e alle approvazioni exec del nodo stesso.

SSH è SSH. Se stai usando l’autenticazione tramite password abilitata, i tentativi di brute force sono inevitabili su una VPS pubblica.

La Soluzione Tailscale

Per OpenClaw, Tailscale ti offre accesso remoto senza pubblicare servizi operatore:

  1. La tua istanza OpenClaw gira su una VPS o macchina locale
  2. Il gateway resta bindato su loopback e viene raggiunto tramite Tailscale Serve, oppure si binda direttamente all’IP 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 built-in che può configurare tailscale serve o tailscale funnel per il gateway.

Modalità Serve mantiene le cose solo sulla tua tailnet. Il gateway resta bindato su 127.0.0.1 mentre Tailscale gestisce routing e HTTPS. Quando gateway.auth.allowTailscale è abilitato, OpenClaw può autenticare il traffico Control UI/WebSocket usando gli header identità Tailscale e verificare la sorgente con tailscale whois. Questa è la modalità giusta per la maggior parte dei deployment personali.

Modalità Funnel espone il gateway pubblicamente attraverso la funzionalità endpoint pubblico di Tailscale. La stessa documentazione di Tailscale descrive Funnel come un routing del traffico dall’intero internet verso un servizio locale. OpenClaw si rifiuta di avviare Funnel a meno che la modalità auth del gateway non sia password, ma stai comunque scegliendo l’esposizione pubblica per una superficie operatore.

La documentazione sulla sicurezza di OpenClaw è chiara: prompt injection e accesso ai tool sono rischi fondamentali per un assistente personale. Non dare all’agent un percorso per rendersi pubblicamente accessibile in silenzio. Usa Serve con consapevolezza, evita Funnel a meno che tu non abbia davvero bisogno di accesso pubblico e richiedi l’approvazione exec per qualsiasi comando tailscale.

Configurare OpenClaw in Modo Sicuro

Passo 1: Installare Tailscale

Sulla tua VPS o server locale:

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


# Autenticazione (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 alla tua VPS usando il suo IP Tailscale e il traffico passerà attraverso il tunnel crittografato.

Passo 2: Configurare OpenClaw per Usare Tailscale

Il pattern più sicuro attuale è: mantieni 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

La documentazione di OpenClaw dice che questo mantiene il gateway su 127.0.0.1 mentre Tailscale fornisce HTTPS e routing tailnet. Lo apri su https://<magicdns-name>/, non sull’IP pubblico della tua VPS.

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

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

Poi connettiti da un altro dispositivo tailnet:

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

Se stai usando Docker o un altro container runtime, fai particolare attenzione alla pubblicazione delle porte. Un publish come -p 18789:18789 di solito binda su tutte le interfacce host. Preferisci loopback più Tailscale Serve, oppure binda 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 Docker, controlla dall’esterno con nmap e localmente con ss. Docker può bypassare o riordinare le assunzioni del firewall host se non ne tieni conto.

Passo 3: Proteggere SSH

Anche con Tailscale, dovresti proteggere SSH correttamente:

Terminal window
# Mantieni la tua sessione SSH corrente aperta mentre fai questo.
# Prima, dalla tua macchina client, conferma di poter fare SSH su Tailscale:
ssh tuo-utente@IP_TAILSCALE_SERVER


# Inserisci l'hardening 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


# Valida 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 l’accesso root. Il passo successivo usa UFW per prevenire SSH pubblico interamente consentendo comunque SSH su tailscale0.

Passo 4: Regole del Firewall

Configura un firewall come secondo strato di difesa:

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 guida di hardening Ubuntu di Tailscale usa questa stessa forma: consenti tailscale0, nega altro traffico in entrata, poi verifica che SSH pubblico vada in timeout mentre SSH all’indirizzo 100.x.y.z funziona ancora. Se gestisci un sito web pubblico sulla stessa VPS, mantieni solo le regole pubbliche di cui hai realmente bisogno, come 80/tcp e 443/tcp.

Verificare la Tua Esposizione

Controllare 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 atteso per un'istanza sicura:
# 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 è aperto, assicurati che sia solo il tuo sito web pubblico intenzionale o l’endpoint Tailscale Funnel, non il gateway OpenClaw per errore.

Controllare Cosa È in Ascolto Localmente

Sul tuo server OpenClaw:

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


# Cerca righe come questa (bene per Serve):
# tcp   LISTEN 0   128   127.0.0.1:18789   *:*
#
# Oppure questa (accettabile per bind tailnet diretto con auth):
# 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 Built-in

OpenClaw include un comando di audit di sicurezza che controlla la tua configurazione rispetto alle best practice 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 auth, l’accesso ai canali, la policy dei tool, l’inventario dei plugin e i permessi dei file. Tratta --fix come un helper utile, non come un sostituto per la lettura dei findings.

Cosa Questo Non Risolve

Tailscale rimuove l’errore più grande: l’esposizione pubblica dell’operatore. Non risolve tutto:

Archiviazione delle credenziali: OpenClaw memorizza trascrizioni di sessioni, token OAuth e chiavi API su disco. Assicurati che questi abbiano permessi file corretti (chmod 600 per i file, chmod 700 per le directory di configurazione private) e che non siano nel version control. L’audit built-in controlla questo aspetto.

Sandboxing dei plugin: I plugin girano con i permessi completi del tuo utente. Installa solo plugin da fonti di cui ti fidi e rivedi quali capacità richiedono. Il tool di audit inventoria i plugin installati.

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

Checklist di Deployment

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

Risorse

Loading comments...