Installare e configurare Nessus su Debian

Perché installarlo così, e non “solo” avviarlo

Nessus su Debian funziona bene quando lo tratti come un servizio esposto in modo controllato, non come un’app da lanciare e dimenticare. La differenza la fanno tre cose: aggiornamento del pacchetto, superficie di rete ridotta e accesso amministrativo limitato alla sola interfaccia web. Se salti questi passaggi, ottieni comunque un motore di scansione, ma ti ritrovi anche con più rischio operativo del necessario.

Qui l’obiettivo è installare Nessus su Debian in modo ripetibile, verificare che il daemon sia davvero in ascolto, completare l’activation iniziale e arrivare a una configurazione base sensata per un ambiente reale. Le istruzioni presuppongono Debian recente e privilegi di root o sudo.

Prerequisiti minimi e scelta del pacchetto

Prima di toccare il sistema, verifica architettura e release. Nessus distribuisce pacchetti dedicati per architettura, quindi non conviene improvvisare con un file sbagliato. Su una macchina Debian standard il controllo più rapido è questo:

dpkg --print-architecture
cat /etc/debian_version
uname -m

Il risultato atteso è coerente: su un host amd64 moderno, dpkg --print-architecture deve restituire amd64. Se l’architettura non coincide con il pacchetto che scarichi, fermati subito: il problema non è Nessus, è la base di installazione.

Serve anche spazio disco sufficiente. Nessus non è leggero quanto a contenuti e aggiornamenti del feed; su macchine strette conviene tenere margine, soprattutto se il sistema ospita anche altri servizi. Un controllo semplice è:

df -h /
df -h /opt

Se /opt è una partizione separata, controllala esplicitamente: su Debian il pacchetto tende a collocare i file applicativi lì. Con meno di qualche gigabyte libero, l’aggiornamento iniziale e i plugin possono diventare fragili.

Installazione del pacchetto .deb

Il flusso più pulito è scaricare il pacchetto dal portale Tenable e installarlo localmente. Tenable aggiorna il pacchetto periodicamente, quindi è buona pratica non fissare il file in un vecchio mirror non verificato. Dopo il download, usa apt per risolvere eventuali dipendenze mancanti invece di forzare dpkg -i e basta.

Sequenza tipica:

sudo apt update
sudo apt install -y curl ca-certificates
curl -LO https://www.tenable.com/downloads/api/v1/public/pages/nessus/downloads/...
sudo apt install ./Nessus-*.deb

Il punto importante non è l’URL in sé, che cambia nel tempo, ma il metodo: scarichi il file ufficiale e lo installi con apt. Se usi dpkg -i e trovi dipendenze mancanti, poi devi rincorrerle a mano. Con apt install ./file.deb il sistema tende a chiudere il cerchio in modo più ordinato.

Se il pacchetto viene installato correttamente, dovresti vedere il servizio registrato da systemd:

systemctl status nessusd

Lo stato atteso, dopo l’installazione, è inactive o dead fino al primo avvio, non necessariamente active. L’importante è che l’unità esista e non ci siano errori di installazione nei log di apt.

Avvio del servizio e prima verifica di ascolto

Una volta installato, abilita e avvia il daemon. Su Debian recente il servizio è gestito da systemd, quindi il controllo è lineare:

sudo systemctl enable --now nessusd
sudo systemctl status nessusd --no-pager

Il servizio deve risultare active (running). Se invece resta in activating o va in failed, il primo posto da guardare è il journal:

sudo journalctl -u nessusd -b --no-pager | tail -n 50

Quasi sempre, nei primi minuti, l’errore non è “Nessus rotto” ma un problema di binding porta, permessi o inizializzazione del database interno. La porta standard dell’interfaccia web è la 8834. Verifica subito che il processo la stia ascoltando:

sudo ss -ltnp | grep 8834

Se non compare nulla, il daemon non è arrivato allo stato utile. Se compare in ascolto solo su 127.0.0.1:8834, sei in una configurazione più restrittiva del normale: va bene solo se prevedi accesso via tunnel locale o reverse proxy dedicato. Se invece ascolta su 0.0.0.0:8834, l’interfaccia è esposta su tutte le interfacce e devi chiudere la rete a monte.

Accesso iniziale alla web UI e activation

La prima configurazione passa quasi sempre dalla web UI, raggiungibile su https://IP-del-server:8834/. Il browser mostrerà un certificato autofirmato: è normale nella fase iniziale. Non è il momento di “accettare tutto e basta”, ma di capire che stai parlando con l’host giusto. Prima di aprire la UI da remoto, meglio fare un test locale o tramite tunnel SSH.

ssh -L 8834:127.0.0.1:8834 user@server-debian

Aprendo https://127.0.0.1:8834/ dal tuo browser, riduci il rischio di esporre subito l’interfaccia in rete. È una scelta semplice e spesso migliore del port forwarding aperto a tutta la LAN.

Durante il wizard iniziale ti verrà chiesto il codice di attivazione. Questo è il punto in cui molte guide diventano vaghe; qui la regola è banale: inserisci il codice fornito da Tenable nel canale previsto e non salvarlo in chiaro in file di testo o ticket. Se devi documentarlo internamente, redigilo o usa un vault. La procedura completa cambia a seconda del tipo di licenza, quindi non ha senso inventare schermate che non vedo.

Dopo l’attivazione, Nessus scarica i plugin. È la fase più lunga. In ambiente con uscita Internet filtrata, devi consentire almeno la connessione verso i repository Tenable necessari all’aggiornamento dei feed. Se il download si blocca, la UI di solito mostra uno stato incompleto, mentre nei log compaiono errori di fetch o di TLS. In quel caso il problema non è la scansione, ma la connettività in uscita.

Rendere l’esposizione meno ingenua

La porta 8834 non dovrebbe restare aperta verso Internet. In pratica hai tre modelli sensati: accesso solo da rete amministrativa, accesso via VPN, oppure accesso locale con tunnel SSH. Se devi pubblicarla in una rete interna, applica almeno un controllo di firewall host o di security group.

Con ufw il concetto è diretto, ma se usi nftables o un firewall centralizzato, applica la stessa logica altrove. Esempio con UFW, da adattare all’IP del tuo bastion o della tua subnet admin:

sudo ufw allow from 10.10.10.0/24 to any port 8834 proto tcp
sudo ufw status verbose

Blast radius: limitare l’accesso alla porta 8834 non impatta le scansioni già configurate, ma può bloccare gli operatori che amministrano Nessus da postazioni non autorizzate. Rollback semplice: rimuovi la regola o restringi temporaneamente la finestra di accesso. Se stai lavorando su un host in produzione, non cambiare il firewall senza una sessione già pronta via console o SSH alternativo.

Organizzare i permessi e l’uso operativo

La tentazione è creare un account condiviso “nessus-admin” e finirla lì. È una scorciatoia che regge poco. Meglio distinguere tra chi amministra il motore, chi lancia scansioni e chi legge i report. Se il tuo processo non supporta ruoli granulari come vorresti, almeno separa gli accessi a livello di OS e di rete.

Dal lato Linux, il servizio gira con il proprio utente applicativo. Evita di cambiare ownership di directory interne senza motivo. Se qualcosa non funziona, prima guarda i log dell’applicazione e i permessi effettivi:

sudo ls -ld /opt/nessus /opt/nessus/var /opt/nessus/var/nessus
sudo find /opt/nessus -maxdepth 2 -type f | head

Se trovi errori di permesso, non correggerli “a colpi di chmod 777”. Serve capire quale directory o file è fuori contesto, e perché. Su un sistema ben tenuto, le modifiche di permessi devono essere mirate e documentate.

Prima scansione: partire piccolo, non con la rete intera

La prima scansione non deve essere un’intera /16. Parti con un host noto, uno o due servizi, e controlla il comportamento del motore. L’obiettivo è verificare che la catena funzioni: credenziali, connettività, plugin e report. Una scansione troppo ampia al primo colpo serve solo a confondere il debug.

Se stai testando un host locale o un server di laboratorio, controlla prima la raggiungibilità dei servizi target. Per esempio, da una macchina di scansione:

nc -vz 192.0.2.10 22
nc -vz 192.0.2.10 80
nc -vz 192.0.2.10 443

Se i port check falliscono, Nessus non può “indovinare” il resto. Una scansione che parte su un host irraggiungibile produce solo rumore e falsi problemi. Se invece i servizi rispondono, lancia una policy di base e osserva il tempo di completamento, gli errori e la qualità del report.

Per la metrica obiettivo iniziale, non fissarti sul numero di vulnerabilità trovate ma su tre segnali pratici: assenza di errori di autenticazione, completamento del job senza crash e report coerente con i servizi effettivamente esposti. Se il tempo di scansione è anomalo, il collo di bottiglia può essere rete, DNS, rate limiting o credentialed checks falliti.

Configurazione TLS e accesso fidato

Il certificato autofirmato iniziale va bene per il bootstrap, non come stato finale. In un ambiente serio conviene sostituirlo con un certificato emesso dalla tua PKI interna o da una CA attendibile per gli operatori. Così eviti warning continui e riduci la probabilità che qualcuno accetti il certificato sbagliato in una sessione remota.

Il percorso dei file può variare leggermente con la versione, ma il concetto è sempre lo stesso: identifica il certificato attuale, sostituiscilo con uno valido e riavvia il servizio solo quando hai i file pronti. Prima di farlo, localizza la configurazione effettiva nei log o nella documentazione del pacchetto installato; se il path esatto non è noto, non inventarlo. Su un sistema Debian tipico, il controllo del servizio e dei file sotto /opt/nessus è il primo passo.

Se usi un reverse proxy davanti alla UI, sposta il TLS lì solo se sai esattamente cosa stai facendo. Nessus è già un servizio HTTPS; aggiungere un proxy senza una ragione precisa introduce un secondo punto di manutenzione e può complicare gli aggiornamenti. Ha senso quando vuoi centralizzare certificati, logging o access control, non per moda.

Manutenzione: aggiornamenti, log e spazio disco

Dopo l’installazione, il lavoro vero è mantenerlo sano. Aggiorna il pacchetto quando esce una nuova release del software e controlla periodicamente i feed dei plugin. I due errori classici sono: aggiornamento del sistema operativo senza test del servizio, oppure spazio disco ignorato fino a quando i feed non si aggiornano più.

Tre controlli utili da schedulare:

systemctl is-active nessusd
journalctl -u nessusd -S -24h --no-pager | tail -n 100
df -h / /opt

Se il journal mostra errori ripetuti di update o di scaricamento contenuti, non ignorarli. Prima correggi connettività, DNS e spazio, poi valuta il riavvio del servizio. Riavviare a vuoto un daemon che fallisce per cause ambientali è solo rumore operativo.

Problemi tipici e come leggerli senza perdere tempo

Se la UI non si apre, il primo layer da escludere è la rete locale: porta chiusa, firewall, binding errato o servizio non avviato. Un curl -kI https://127.0.0.1:8834/ dal server stesso distingue subito tra problema di ascolto e problema di routing esterno. Se risponde localmente ma non da remoto, il colpevole è quasi certamente il firewall o una ACL a monte.

Se il wizard resta bloccato sull’aggiornamento dei plugin, guarda la connettività in uscita e la risoluzione DNS. Un resolvectl status o un semplice getent hosts verso i domini necessari ti dice se il sistema riesce a risolvere. In ambienti filtrati, non dare per scontato che il problema sia Nessus: spesso è il proxy uscita che taglia il traffico TLS.

Se le scansioni falliscono solo in modalità credentialed, il problema non è la porta 8834 ma le credenziali, i privilegi sul target o il blocco dell’account remoto. Qui la verifica corretta non è “riprovare a caso”, ma controllare i log del target, il tipo di autenticazione richiesto e la reachability dei servizi amministrativi.

Chiusura operativa

A fine installazione, un Nessus ben messo su Debian deve rispettare questa sequenza: servizio attivo, porta 8834 raggiungibile solo dai sistemi autorizzati, activation completata, plugin aggiornati e prima scansione su un target piccolo andata a buon fine. Se uno di questi punti manca, non passare oltre finché non hai un’evidenza concreta dal sistema: stato systemd, journal, porta in ascolto o risposta della UI.

Assunzione operativa: questa guida parte da un host Debian recente, con accesso sudo e connettività di rete sufficiente per scaricare il pacchetto e i feed iniziali.