Claude Code e sicurezza del server Linux

Controllare la sicurezza di un server Linux significa leggere molto output: porte in ascolto, configurazione di SSH, pacchetti da aggiornare, log di accesso. È un lavoro ripetitivo e proprio per questo adatto a Claude Code, che sa leggere quell’output, metterlo in relazione e scrivere un rapporto ordinato. In questa guida vedi come installarlo, come impostarlo in modo prudente e come usarlo per un controllo di sicurezza periodico, con i comandi che uso io.

Prima di cominciare: cosa fa e cosa no

Claude Code è un assistente da riga di comando: legge file, propone ed esegue comandi (con la tua conferma) e ragiona sul risultato. Non è uno scanner di vulnerabilità e non sostituisce un vulnerability assessment o un test di intrusione: interpreta quello che gli strumenti trovano, e può sbagliare. Ogni segnalazione va verificata, e ogni correzione la decidi e la lanci tu. Nel metodo che descrivo, Claude Code legge e riferisce; non modifica il server.

Dove installarlo

Le possibilità sono due:

Sulla tua postazione di amministrazione, collegandoti al server via SSH e passando a Claude Code l’output dei comandi. È la scelta più semplice e quella che consiglio per cominciare: sul server non si installa nulla.
Sul server stesso, con un utente dedicato. Serve se vuoi automatizzare un rapporto periodico o lavorare direttamente sui file di configurazione.

In entrambi i casi vale la regola di sempre: mai come root. Claude Code non deve mai ricevere privilegi che non daresti a un collaboratore alle prime armi.

Installazione su Linux

Crea un utente senza privilegi, che userà solo per l’audit:

sudo adduser --disabled-password --gecos "" auditor
sudo -iu auditor

Poi installa Claude Code con l’installatore ufficiale (verifica sempre il comando aggiornato nella documentazione di Claude Code, perché può cambiare):

curl -fsSL https://claude.ai/install.sh | bash
claude --version

In alternativa esiste l’installazione tramite npm (npm install -g @anthropic-ai/claude-code), che richiede Node.js. Al primo avvio con claude ti viene chiesto di accedere: su un server senza browser ti viene mostrato un indirizzo da aprire dal tuo computer, dove completi l’accesso con il tuo account. Se usi una chiave API, tienila in una variabile d’ambiente dell’utente auditor e non scriverla mai in file di un repository o in chat.

Il file CLAUDE.md dell’audit

Nella cartella di lavoro dell’utente (per esempio ~/audit) crea un CLAUDE.md che dica a Claude Code che cosa deve fare e che cosa gli è vietato:

# Audit di sicurezza - server web-01 (Ubuntu 24.04)
- Ruolo: SOLA LETTURA. Analizza, riferisci, proponi. Non modificare nulla.
- Non eseguire comandi che scrivono, riavviano servizi o cambiano permessi.
- Non leggere né stampare: .env, chiavi private, dump del database, /etc/shadow.
- Il rapporto va scritto in report/AAAA-MM-GG.md con: rischio (alto/medio/basso),
  evidenza (comando e riga), correzione proposta, impatto della correzione.
- Se un'informazione manca, dillo: non inventare.

Permessi ristretti

Nel file .claude/settings.json puoi consentire in automatico i soli comandi di lettura e negare il resto:

{
  "permissions": {
    "allow": [
      "Bash(ss:*)", "Bash(sshd -T:*)", "Bash(ufw status:*)",
      "Bash(systemctl list-units:*)", "Bash(systemctl --failed:*)",
      "Bash(apt list --upgradable:*)", "Bash(last:*)", "Bash(df:*)"
    ],
    "deny": ["Bash(rm:*)", "Bash(sudo:*)", "Read(./.env)", "Read(/etc/shadow)"]
  }
}

La sintassi esatta delle regole può cambiare fra una versione e l’altra: controllala nella documentazione della versione che usi. Con sudo negato, i controlli che richiedono privilegi li lanci tu e fornisci a Claude Code il risultato (vedi sotto).

Il controllo: cosa raccogliere

Ecco un elenco ragionato di comandi di sola lettura, che raccolgo in una cartella e poi faccio leggere a Claude Code:

# Servizi esposti
ss -tulpn

# Configurazione effettiva di SSH
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|allowusers'

# Firewall
sudo ufw status verbose

# Aggiornamenti in sospeso e riavvii necessari
apt list --upgradable 2>/dev/null
test -f /var/run/reboot-required && echo "riavvio necessario"

# Servizi falliti, accessi recenti e accessi falliti
systemctl --failed
last -n 20
sudo lastb -n 20

# File con SUID/SGID e file scrivibili da tutti
sudo find / -xdev -perm -4000 -type f 2>/dev/null
sudo find / -xdev -type f -perm -0002 2>/dev/null | head -50

Per un controllo più strutturato si può affiancare Lynis, uno strumento open source di audit per sistemi Unix/Linux che produce una valutazione e un elenco di suggerimenti:

sudo apt install lynis
sudo lynis audit system --quiet --no-colors > ~/audit/lynis-$(date +%F).txt

I comandi con sudo li lanci tu, una volta, e salvi l’output nella cartella dell’audit. Claude Code non ha bisogno di privilegi: lavora sui file di testo che trova lì.

Far analizzare i risultati a Claude Code

Con i file pronti, la richiesta è semplice. In modalità non interattiva (-p):

cd ~/audit
claude -p "Leggi i file in raw/ e scrivi report/$(date +%F).md seguendo le regole del CLAUDE.md. \
Ordina per rischio, indica per ogni voce l'evidenza e il comando di correzione, ma NON eseguirlo."

Oppure puoi lavorare in modo interattivo, facendo domande: «perché SSH accetta ancora la password?», «questa porta è davvero necessaria?», «quali di questi pacchetti hanno aggiornamenti di sicurezza?». Per chi vuole la massima prudenza, la modalità di pianificazione (--permission-mode plan) fa descrivere a Claude Code ciò che farebbe, senza eseguire nulla.

Il rapporto che ottengo è un file Markdown con voci come questa:

## [ALTO] Accesso SSH con password abilitato
Evidenza: sshd -T -> passwordauthentication yes
Correzione: PasswordAuthentication no in /etc/ssh/sshd_config.d/10-hardening.conf,
poi sshd -t e systemctl reload ssh (con una seconda sessione aperta).
Impatto: gli utenti senza chiave SSH non potranno più accedere.

Applicare le correzioni, con giudizio

Qui Claude Code è utile come revisore: gli chiedo di scrivere la modifica, di spiegare l’effetto e di indicare come tornare indietro. Poi la applico io, in una finestra di manutenzione, tenendo aperta una seconda sessione SSH quando tocco l’accesso remoto. Su server importanti il passaggio è prima sulla copia di prova (una macchina virtuale o uno snapshot).

Un rapporto ogni settimana

Quando la raccolta dei dati è affidabile, la si può programmare: uno script (o un timer di systemd) che salva i comandi di sola lettura in una cartella datata e un secondo passaggio che chiede a Claude Code di confrontare il rapporto con quello della settimana precedente. L’obiettivo non è un allarme in tempo reale, per cui servono strumenti come Wazuh o Graylog, ma una fotografia periodica che mostra cosa è cambiato: una porta nuova, un utente nuovo, un servizio fermo.

Privacy e responsabilità

Il testo che passi a Claude Code viene elaborato dal servizio: non includere chiavi, password, token, dump di database e dati dei clienti. Indirizzi IP, nomi utente ed email sono dati personali per il GDPR: ripuliscili o anonimizzali se il server non è tuo.
Per i server dei clienti chiarisci per iscritto che cosa viene analizzato e con quali strumenti.
Il modello può sbagliare o sembrare sicuro quando non lo è: ogni voce del rapporto va verificata sul server prima di agire.
Questo controllo è un aiuto alla manutenzione, non una certificazione e non sostituisce un assessment professionale.

In sintesi

Un utente dedicato senza privilegi, un CLAUDE.md con regole chiare, permessi in sola lettura e un rapporto Markdown a ogni controllo: è un metodo semplice che fa risparmiare ore e rende il controllo ripetibile. Se vuoi lo stesso approccio per l’aggiornamento di più server insieme, leggi anche Ansible e Claude Code. Per vedere come lavoriamo con Claude Code in azienda, qui trovi la pagina dedicata, e se ti serve un controllo di sicurezza vero sulla tua rete, scopri la nostra area cybersecurity.