Installare WPScan su Ubuntu 20.04 LTS per la sicurezza di WordPress

WPScan è uno strumento utile quando devi fare un controllo difensivo su un’istanza WordPress: versioni core, plugin, temi, esposizione dei metadati e alcuni indicatori di configurazioni deboli. Su Ubuntu 20.04 LTS conviene installarlo in modo pulito, verificare prima i prerequisiti e poi usarlo con criterio, perché un’analisi fatta male produce falsi positivi, rumore nei log e, in alcuni casi, traffico non desiderato verso il sito.

Il punto non è “lanciare uno scanner e sperare”. Il punto è avere una procedura ripetibile: ambiente pronto, dipendenze presenti, aggiornamento del tool, chiavi API se servono, e un modo per leggere i risultati senza confondere indizio e prova. Se devi monitorare siti tuoi o di clienti con autorizzazione, questa è la base corretta.

Installazione su Ubuntu 20.04 LTS: scelta pratica

Su Ubuntu 20.04 LTS hai tre strade: pacchetto della distribuzione, installazione via RubyGems, oppure esecuzione in container. Per un host amministrato di frequente, la via più lineare resta RubyGems, perché tende ad avere versioni più aggiornate rispetto ai repository Ubuntu. Se però vuoi isolare il tool dal sistema, il container è una scelta sensata. Qui parto dall’installazione nativa, che è la più comoda in un contesto sysadmin.

Prima di tutto verifica lo stato del sistema e aggiorna l’indice pacchetti. Non c’è nulla di speciale, ma è il modo migliore per evitare dipendenze vecchie o repository non coerenti.

sudo apt update
sudo apt -y upgrade

Ora installa Ruby, i tool di compilazione minimi e alcune librerie utili. Su 20.04 non sempre trovi tutto già pronto nella versione che serve a WPScan, quindi conviene preparare l’ambiente in modo esplicito.

sudo apt install -y ruby-full ruby-dev build-essential libcurl4-openssl-dev libxml2 libxml2-dev libxslt1-dev zlib1g-dev

A questo punto puoi installare WPScan con RubyGems. L’opzione -N evita di installare documentazione inutile e mantiene il sistema più pulito.

sudo gem install wpscan -N

Se il comando non è nel PATH della tua shell, controlla dove Ruby ha posizionato gli eseguibili. Su alcuni sistemi il binario finisce in una directory come /usr/local/bin, su altri in un path gestito da Ruby. Il controllo più rapido è questo:

which wpscan
wpscan --version

Se which non restituisce nulla, ma l’installazione è andata a buon fine, individua il binario con gem env e aggiungi il path corretto alla variabile d’ambiente PATH. Non forzare symlink improvvisati: prima capisci dove Ruby ha installato l’eseguibile.

gem env home
gem env path

Verifica prerequisiti e aggiornamento del database

Una volta installato, il primo controllo utile non è un audit su un sito reale, ma la verifica della versione e dell’accesso al database delle vulnerabilità. WPScan usa informazioni aggiornate per riconoscere versioni e pattern, quindi se il database è vecchio i risultati perdono affidabilità.

wpscan --version
wpscan --update

Se il comando di update fallisce, non partire subito a fare troubleshooting del sito target. Prima guarda se hai connettività, DNS funzionante e orario di sistema corretto. Un clock sballato o un problema TLS a livello host può rompere update e chiamate esterne in modo poco intuitivo.

timedatectl status
curl -I https://wpscan.com
resolvectl status 2>/dev/null || cat /etc/resolv.conf

Se vuoi usare le API ufficiali per ottenere dati più completi, registra una chiave e salvala senza scriverla in chiaro in script o documenti. Il modo più semplice è esportarla solo nella sessione corrente.

export WPSCAN_API_TOKEN='token-qui'
wp_scan_test=1 wpscan --api-token "$WPSCAN_API_TOKEN" --url https://example.com

Qui c’è una nota importante: la chiave non va inserita in file condivisi o repository. Se devi automatizzare, usa un secret manager, una variabile d’ambiente in un job controllato o un file di configurazione con permessi stretti. L’obiettivo è ridurre l’esposizione accidentale, non “nascondere” la chiave in modo fragile.

Primo scan: cosa controllare davvero

Il primo scan dovrebbe essere conservativo. Non serve martellare il sito con opzioni aggressive: ti basta confermare che il target risponde, che WordPress è rilevato correttamente e che i risultati hanno senso. Un esempio minimo:

wpscan --url https://example.com --enumerate vp,vt,u

Le sigle indicano rispettivamente plugin vulnerabili, temi vulnerabili e utenti. In pratica, però, devi leggere il contesto. Un plugin segnalato come vulnerabile non significa automaticamente exploit disponibile sul tuo sito, così come un utente enumerato non rappresenta di per sé una compromissione. È un indicatore da incrociare con versione, esposizione e configurazione.

Se vuoi ridurre il rumore, puoi iniziare senza enumerazione estesa e poi aggiungere solo quello che ti serve. Per un check veloce su una finestra di manutenzione, l’ordine sensato è: raggiungibilità, fingerprint del core, plugin principali, poi utenti solo se c’è un motivo operativo. La scansione totale “per vedere cosa esce” produce spesso più lavoro che valore.

wpscan --url https://example.com --random-user-agent --disable-tls-checks

L’opzione --disable-tls-checks va usata solo in ambienti di test o quando stai verificando un problema di certificato noto. In produzione è preferibile correggere il certificato, non aggirarlo. Se il certificato è invalido, lo scanner ti sta già dicendo qualcosa di utile: la connettività sicura è rotta e va sistemata prima di tutto.

Interpretare output e falsi positivi

Un errore frequente è prendere l’output di WPScan come verità assoluta. In realtà è un insieme di segnali. Se il plugin è rilevato da una stringa nel markup o da un asset pubblico, la fiducia è alta ma non totale. Se la versione viene dedotta indirettamente, il margine di errore sale. Per questo conviene sempre confrontare il risultato con i file reali del sito o con il pannello di amministrazione, quando hai accesso legittimo.

Per esempio, se WPScan segnala un plugin ma il sito usa una build customizzata o un reverse proxy che serve asset cache-izzati, l’identificazione può essere parziale. In questi casi verifica i file nella directory del plugin, o controlla il changelog del vendor. Il dato utile non è “c’è una segnalazione”, ma “la versione esposta è davvero quella vulnerabile?”.

Controlli da fare subito dopo uno scan:

• verificare la versione WordPress nel markup o dal backend;

• confrontare plugin e temi rilevati con l’inventario reale;

• aprire il riferimento CVE o advisory e controllare se il vettore è applicabile;

• distinguere tra vulnerabilità esposta e vulnerabilità mitigata da configurazione.

Se hai accesso al filesystem, il controllo più robusto resta il confronto con i file del codice. Non è glamour, ma funziona. In molti casi basta leggere il file di intestazione del plugin o il changelog per capire se la segnalazione è attuale o già risolta.

Esecuzione sicura: limiti, rate e impatto

Anche se WPScan non è un exploit kit, resta uno scanner. Se lo lanci contro un sito in produzione senza criterio, puoi aumentare log, saturare rate limit applicativi o far scattare controlli WAF/CDN. Per questo è meglio partire con un profilo leggero e osservare l’effetto sul server.

Un approccio prudente è questo:

1. esegui lo scan in una finestra di bassa attività;

2. monitora access log, error log e metriche HTTP;

3. se il sito usa WAF o CDN, controlla eventuali blocchi o challenge;

4. solo dopo aumenta enumerazione o profondità.

Se noti risposte lente o 403 anomali, non insistere a caso. Prima identifica il layer che sta reagendo: edge, origin o applicazione. Un esempio pratico è confrontare un curl -I verso il dominio pubblico con una richiesta diretta all’origin, se disponibile e autorizzata. Se il comportamento cambia, il problema non è WPScan in sé ma la protezione perimetrale o la configurazione dell’host.

curl -I https://example.com
wpscan --url https://example.com --enumerate vp --api-token "$WPSCAN_API_TOKEN"

Se devi integrare lo strumento in una pipeline interna, evita di salvare report in percorsi mondi scrivibili o condivisi. Genera output in una directory dedicata, con permessi stretti, e se il report contiene dettagli sensibili trattalo come materiale operativo, non come allegato da inoltrare liberamente.

Uso in automazione e report

In ambienti reali WPScan è spesso utile in schedulazione: controlli periodici, confronti tra release, verifica post-deploy. La logica giusta è trattarlo come un sensore, non come una sentenza. Un report utile deve dirti cosa è stato trovato, con quale confidenza e quale azione è richiesta.

Un esempio minimale di output in file:

wpscan --url https://example.com --format json --output /var/log/wpscan/example.json

Quel file va poi integrato con un parser o con una piattaforma di monitoraggio. La parte importante è mantenere la tracciabilità: data del controllo, target, versione del tool, token usato, esito. Senza questi elementi il report perde valore forense e operativo.

Se usi cron o systemd timer, ricorda che l’ambiente è più povero di una shell interattiva. Imposta path completi, esporta le variabili necessarie e scrivi log espliciti. Un timer ben fatto è più affidabile di uno script “che in terminale funziona”.

# esempio concettuale di job periodico
/usr/local/bin/wpscan --url https://example.com --api-token "$WPSCAN_API_TOKEN" --format json --output /var/log/wpscan/example.json

Quando non basta WPScan

WPScan copre bene la superficie WordPress, ma non sostituisce patch management, hardening e revisione dei privilegi. Se un plugin è vecchio, la vera correzione è aggiornarlo o rimuoverlo. Se l’admin è esposto senza MFA, la vera correzione è chiudere il buco di autenticazione. Se il web server serve directory listing o file di backup, il problema è di configurazione, non di scanner.

In altre parole, lo strumento serve a trovare il segnale; il fix sta nel sistema. Il ciclo sano è: inventario, scan, validazione, correzione, nuova scansione. Quando il secondo scan non mostra più la stessa esposizione, hai una prova utile. Non è una garanzia matematica di sicurezza, ma è una verifica concreta del miglioramento.

Se vuoi una postura difensiva più solida, abbina WPScan a questi controlli: aggiornamenti automatici dei componenti, backup verificati, permessi corretti su `wp-config.php`, disabilitazione dell’editor di file dal backend e monitoraggio dei log di accesso. Lo scanner è uno strumento, non una strategia.

Checklist operativa finale

Prima di considerare il lavoro fatto, verifica questi punti:

• wpscan --version restituisce la versione attesa;

• wpscan --update completa senza errori;

• il token API, se usato, non è salvato in chiaro in repository o ticket;

• i risultati sono incrociati con file, backend o changelog;

• eventuali blocchi WAF/CDN sono stati interpretati come segnale operativo, non ignorati.

Su Ubuntu 20.04 LTS, l’installazione di WPScan è semplice; la parte delicata è usarlo bene. La differenza la fanno il contesto, la lettura dei risultati e la disciplina nel non confondere una scoperta con una compromissione. Se tieni separati installazione, verifica e interpretazione, lo strumento diventa davvero utile nella routine di sicurezza di WordPress.

Assunzione: accesso amministrativo a Ubuntu 20.04 LTS, uso autorizzato su siti WordPress di cui hai responsabilità operativa.