Come configurare OpenClaw in sicurezza su VPS

Cos'è OpenClaw e perché è necessario metterlo in sicurezza per primo

OpenClaw è un agente AI self-hosted. Viene eseguito sul proprio server, collegato a un modello linguistico di grandi dimensioni (LLM) e può eseguire comandi shell, controllare un browser, leggere e scrivere file e agire sui messaggi inviati tramite app di chat. Questa ampiezza operativa è l'obiettivo principale dello strumento, ma rappresenta anche il rischio principale. Un agente in grado di eseguire qualsiasi comando è sicuro solo quanto lo è il sistema su cui gira e i limiti che gli vengono imposti.

Due fatti definiscono l'approccio di questa guida. Primo, OpenClaw è progettato per essere messo in sicurezza dall'utente. Il suo modello di sicurezza delega all'operatore la responsabilità di definire policy rigorose per gli strumenti, il sandboxing e i permessi, invece di affidarsi a impostazioni predefinite sicure. Secondo, il progetto ha già subito un grave incidente di sicurezza: nel marzo 2026 sono state rese note nove vulnerabilità in quattro giorni, inclusa una falla critica di privilege-escalation, CVE-2026-32922, con un punteggio di 9.9 su 10. Nessuno dei due fatti implica che si debba evitare OpenClaw. Significa che non bisogna eseguirlo in modo negligente; questa guida descrive invece il metodo accurato.

Ci sono anche notizie positive. OpenClaw implementa già una scelta sicura: il suo gateway, l'unico processo che controlla tutto, ascolta sull'indirizzo loopback di default, quindi non è raggiungibile da internet a meno che non si decida esplicitamente di esporlo. La maggior parte del lavoro descritto di seguito consiste nel mantenere questa configurazione e nel limitare l'area di impatto in caso di compromissione.

Assegnare a OpenClaw un proprio utente senza privilegi

Non eseguire mai un agente come root. Se OpenClaw viene eseguito come root e si verifica un errore, che sia un bug, un comando errato o una CVE come quella sopra citata, il danno non avrà limiti. Crea un utente di sistema dedicato, senza shell di login e senza permessi sudo, ed esegui l'agente con tale utente:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Tutto ciò che OpenClaw possiede risiede sotto /opt/openclaw, di proprietà di tale account. Questo è il passaggio più importante e segue lo stesso principio descritto in esecuzione di servizi come utente senza privilegi: l'account sotto cui gira un agente rappresenta il limite massimo di ciò che può compromettere.

Installare OpenClaw

OpenClaw è distribuito come pacchetto npm, quindi installa prima Node.js se il server non lo possiede. Installa il pacchetto globalmente, il che aggiunge il binario openclaw al PATH per ogni utente, quindi esegui il passaggio di onboarding una tantum:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Eseguire l'onboarding come utente openclaw significa che la configurazione dell'agente verrà salvata nella sua home directory, /opt/openclaw, e non in quella di root. Il progetto offre anche un installer curl -fsSL https://openclaw.ai/install.sh | bash che esegue la stessa installazione in una riga. Salta il flag --install-daemon durante l'onboarding: registrerebbe il servizio proprietario di OpenClaw, mentre l'unità systemd messa in sicurezza che costruirai di seguito è più restrittiva.

Mantenere il gateway su loopback, dietro un firewall

Il gateway è vincolato a 127.0.0.1 di default. Lascialo così. Non c'è quasi mai motivo di pubblicare quella porta su internet; farlo fornirebbe a chiunque la trovi un punto di accesso remoto a un processo che esegue comandi per operare.

Configura un firewall con politica di default-deny davanti al server per evitare che qualcosa venga esposto accidentalmente:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Due insidie da evitare. Un firewall che copre solo IPv4 può lasciare lo stesso servizio aperto su IPv6, che è esattamente il gap del firewall IPv6 che coinvolge molte persone. Inoltre, se devi raggiungere il gateway dal tuo laptop, non aprire la porta. Connettiti tramite VPN o un tunnel SSH, in modo che l'agente non ascolti mai su internet aperto.

Isolare i segreti

OpenClaw richiede una chiave API per il modello linguistico a cui lo colleghi. Tale chiave può consumare il tuo budget e, tramite l'agente, agire a tuo nome; trattala quindi come una password. Non inserirla nel file dell'unità e non inserirla in alcun repository. Salvala in un file che solo l'utente OpenClaw può leggere:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

L'unità systemd carica quel file tramite EnvironmentFile, così la chiave raggiunge il processo senza mai apparire in una riga di comando, in un log o nella cronologia della shell.

Eseguire l'agente come servizio systemd protetto

Eseguire l'agente tramite systemd fornisce riavvii automatici, log puliti tramite journalctl e, soprattutto, un set di opzioni di sandboxing a livello kernel che riducono ciò che il processo può toccare, anche in caso di compromissione. Le opzioni più importanti per un agente sono NoNewPrivileges per impedire l'acquisizione di nuovi privilegi, ProtectSystem=strict per rendere il filesystem in sola lettura eccetto dove è consentita la scrittura, PrivateTmp per la sua directory temporanea isolata e ProtectHome per impedire la lettura delle home directory.

Genera qui un'unità completa e protetta, quindi copiala in /etc/systemd/system/openclaw.service:

L'unità avvia openclaw gateway, il processo a lunga esecuzione che controlla l'agente; se which openclaw mostra un percorso diverso sul tuo server, modifica ExecStart per farlo corrispondere. La guida completa a queste direttive, e a daemon-reload e enable --now, si trova in esecuzione di un programma come servizio systemd. La versione breve dopo aver incollato l'unità:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Proteggere anche il perimetro esterno

Un server per agenti è sicuro quanto lo è il server che lo ospita. Altri due livelli completano il lavoro. Configura SSH per l'autenticazione tramite chiavi e disabilita il login root, come in hardening SSH su un VPS, in modo che l'account da cui gestisci il server non sia vulnerabile al brute-force. Aggiungi quindi Fail2ban per bloccare gli scanner che colpiscono ogni porta pubblica. Nessuno di questi interventi tocca direttamente OpenClaw, ma entrambi interrompono le rotte che un attaccante userebbe per raggiungerlo.

Mantienilo aggiornato, intenzionalmente

Le vulnerabilità di marzo 2026 sono l'argomento più chiaro per restare aggiornati. Un bug di privilege-escalation in un agente è molto più serio che in una normale web app, perché l'agente esegue già comandi. Monitora i rilasci del progetto, applica rapidamente gli aggiornamenti di sicurezza e tratta l'aggiornamento di OpenClaw come una manutenzione ordinaria piuttosto che come qualcosa da rimandare.

Per capire cosa stai effettivamente proteggendo, l'architettura di un agente stile OpenClaw analizza i componenti operativi, mentre costruire il proprio agente AI su un VPS descrive la struttura generale di qualsiasi agente.

FAQ

È sicuro eseguire OpenClaw su un VPS pubblico?

Può esserlo, se lo metti in sicurezza. OpenClaw è potente per progettazione: esegue comandi shell e controlla un browser, quindi una configurazione superficiale è realmente pericolosa, e il progetto ha già avuto una CVE critica (CVE-2026-32922 nel marzo 2026). Il suo modello di sicurezza richiede che sia l'operatore ad aggiungere i limiti. Eseguilo come utente senza privilegi, mantieni il gateway su loopback dietro un firewall default-deny, isola le chiavi API ed eseguilo come servizio systemd protetto.

Devo esporre il gateway di OpenClaw su internet?

No. Il gateway è vincolato al loopback di default e deve rimanere tale. È l'unico processo che controlla l'agente, quindi un gateway esposto è un percorso remoto verso un sistema che esegue comandi. Se devi raggiungerlo da remoto, usa una VPN o un tunnel SSH invece di aprire la porta.

Con quale utente deve essere eseguito OpenClaw?

Un utente di sistema dedicato, senza shell di login e senza sudo, mai come root. Se l'agente viene compromesso, l'account utente limita l'entità del danno; pertanto, tale account deve possedere solo i propri file sotto una directory come /opt/openclaw e nient'altro.

Come posso mantenere sicure le chiavi API di OpenClaw?

Memorizzale in un file leggibile solo dall'utente OpenClaw (modalità 600) e caricalo nel servizio tramite EnvironmentFile di systemd. Mantieni la chiave fuori dal file dell'unità, fuori dalla cronologia della shell e fuori da qualsiasi repository git. Ruotala se sospetti che sia stata compromessa.