Greenbone OpenVAS: Trova le Vulnerabilità di Rete su pfSense

Greenbone OpenVAS è lo strumento che trova le vulnerabilità conosciute che affliggono i sistemi su pfSense e OPNsense, mediante l’uso di un Vulnerability Assessment Scanner, e consiglia (talvolta) un metodo per risolvere il problema.

1. Cosa sta capitando

• Gli attacchi alla sicurezza informatica avvengono a tutti i livelli (dalla piccola azienda alla multinazionale) con un’intensità crescente.

• La vigente normativa in materia di privacy, ovvero il regolamento (UE) n. 2016/679 e meglio noto con la sigla GDPR, che impone degli standard come audit periodici sulla sicurezza, e procedure di controllo.

2. Come abbiamo effettuato le prove

Per questo articolo abbiamo utilizzato l’Appliance A3 Server Aluminum, 32 GB RAM, dischi SSD.

Sarebbe anche utilizzabile hardware più economico come il Virtual Appliance A2 Server.

È ormai risaputo che, mai come in questi ultimi tempi, il tema della sicurezza stia investendo il settore informatico come un fiume in piena. Questo per 2 ragioni principali.

Molto più frequentemente rispetto al passato, capita di sentire storie di aziende che hanno dovuto pagare migliaia di euro di riscatto per riavere i propri dati dopo che un virus, o un hacker, li aveva cifrati rendendoli inutilizzabili.

Su un campione di circa 100 aziende che hanno avuto “disagi” in ambito di sicurezza informatica abbiamo scoperto, che quasi tutte possedeva un firewall, che nella maggior parte dei casi avevano un sistema operativo obsoleto e quindi in “end of life” e non più manutenuto.

In alcuni casi lo stesso firewall era “obsoleto” con molte porte aperte configurate in modalità forward, che inoltravano il traffico verso sistemi operativi obsoleti utilizzando protocolli non sicuri.

Ma come possiamo sapere se il nostro firewall pfSense o OPNsense è sicuro e ben configurato? Chi ce lo può dire? Vedi la comparazione tecnica tra pfSense e OPNsense.

Come facciamo a “certificare” che abbiamo fatto tutto il possibile per garantire la sicurezza della nostra rete e dei nostri dati?

Greenbone OpenVAS ci viene in aiuto!

Scarica la soluzione pronta all’uso!

3. Verificare i firewall e creare il report GDPR con Greenbone OpenVAS

Cosa è Greenbone OpenVAS, come nasce e cosa fa?

Greenbone OpenVAS è uno scanner di vulnerabilità completo.

Tra le sue features troviamo migliaia di test pronti all’uso per protocolli Internet e industriali (sia di alto livello che di basso livello), ottimizzazione delle prestazioni per scansioni su larga scala, e un potente linguaggio di programmazione interno per implementare qualsiasi tipo di test di vulnerabilità.

Lo scanner di Greenbone OpenVAS comprende un test di vulnerabilità formato da un database aggiornato con cadenza giornaliera dalla comunità che ad oggi conta più di 50.000 test.

Il progetto è nato nel 2005 come fork del celebre Nessus (commerciale), ed è rilasciato come Open Source alla comunità sotto la licenza GNU General Public License (GNU GPL). Di fatto è completamente libero e gratuito.

Le 3 pietre miliari del progetto sono le seguenti:

1. La soluzione deve andare oltre la semplice scansione delle vulnerabilità verso una soluzione completa di gestione delle vulnerabilità.
2. Creare un prodotto appliance chiavi in ​​mano per i clienti aziendali.
3. Aderire allo stile Open Source. Creare una tecnologia di sicurezza trasparente.

Come impostare una scansione?

Per prima cosa c’è da sapere che:

NVT = Network Vulnerability Test
VAS = Vulnerability Assessment System

Diamo per scontato che la macchina virtuale (VM) che abbiamo creato, e che avete scaricato, sia funzionante e aggiornata.

Una volta running, aprire un terminale ed eseguire questi comandi per aggiornare il sistema operativo:

Fate partire il servizio dando il comando

Accedete al localhost del sistema sulla porta 9392

La schermata che visualizzeremo sarà la seguente:

Username: admin
Password: admin (i dati di accesso saranno inviati con la mail di registrazione).

 

Accederemo così alla Dashboard principale: Settiamo subito il refresh della pagina cliccando su “No auto-refresh” e settiamo “Refresh every 30 Sec.”

 

Per effettuare il primo scan clicchiamo su: SCAN, poi TASKS come mostrato in figura.

 

Clicchiamo poi sull’icona blu, poi New Task come mostrato in figura.

Per effettuare le prove abbiamo utilizzato una vecchia macchina con Windows XP che, chiaramente, ci darà modo di vedere come Greenbone OpenVAS visualizza molte vulnerabilità gravi.

Si aprirà quindi la schermata che ci permetterà di indicare il target del nostro vulnerability test.

Andiamo a compilare questa scheda con: il nome che vogliamo assegnare al task ed un commento.

 

Clicchiamo poi sull’icona blu per impostare lo Scan Target.

Questo menù serve per impostare il o i target/s. Possiamo indicare un indirizzo IP oppure possiamo caricare un file di testo ed indicare più target.

In questo esempio ci limiteremo ad indicare un solo ip in corrispondenza del campo manual.

I due menù Port list e Alive Test permettono di accedere a menù di configurazione avanzati.

Cliccando su SSH potremo anche impostare una user id ed una password con cui Greenbone OpenVAS tenterà di accedere.

Questo per esempio ci permetterà di verificare se abbiamo dimenticato la nostra password di default sul nostro firewall pfSense, OPNsense, o IPfire.

In questo esempio lasceremo tutto di default.

 

Clicchiamo su create, poi nuovamente create. Abbiamo quindi creato il nostro primo task.

La schermata che vedremo sarà questa:

 

Per far partire la scansione clicchiamo sulla freccia verde a destra sotto la scritta Actions.

Facciamo notare che eseguire un vulnerability test su un target non di nostra proprietà e senza l’autorizzazione del proprietario è contro la legge.

Sotto la colonna status possiamo osservare lo stato di avanzamento del task con la percentuale di completamento.

 

Alla fine della scansione, lo status del task viene segalato come “Done”.

Per eseguire una scansione, a seconda dell’hardware utilizzato, ci possono volere dai 15 minuti fino a molte ore. Greenbone OpenVAS è molto esoso di risorse, soprattutto di CPU.

Attenzione anche al target, in quanto i test lo sottopongono ad un traffico che, a seconda dalle condizioni in cui si trova, potrebbero metterlo in crisi in quanto verrà richiesta molta CPU.

Per vedere i risultati clicchiamo in corrispondenza della colonna last sulla data che compare in blu “24 Giugno 2019”.

 

In questa schermata possiamo osservare i risultati che Greenbone OpenVAS ha trovato.

Notiamo subito la scritta Report: Results (219 of 327). Questo vuol dire che a video vedrò solo 219 report rispetto alla totalità di 327 che è stata riscontrata.

Questo avviene principalmente per limitare i report rispetto al parametro QoD (spiegato più avanti nel presente articolo).

Qualora volessimo visualizzare tutto ci sarà sufficiente cliccare sulla chiave inglese alla destra del campo filter e selezionare ciò che vogliamo vedere.

Per esempio possiamo portare a 0 il parametro QoD. Clicchiamo su Update.

Analizziamo meglio le colonne più importanti.

4. Descrizione della vulnerabilità riscontrata.

Cliccando all’interno possiamo visualizzare i dettagli delle vulnerabilità trovate. Ad oggi nel database di Greenbone OpenVAS ne sono presenti circa 51400.

(Seconda colonna) Solution Type: queste informazioni mostrano possibili soluzioni per il fix della vulnerabilità. I possibili scenari che possiamo trovare sono:

• Soluzione alternativa: sono disponibili informazioni su una configurazione alternativa che è possibile utilizzare per evitare l’esposizione alla vulnerabilità.

  Questa è in genere la “prima linea di difesa” contro una nuova vulnerabilità prima che una soluzione di mitigazione del vendor sia stata pubblicata, o addirittura scoperta.

• Attenuazione: le informazioni sono disponibili su uno scenario di configurazione, o implementazione, che aiuta a ridurre il rischio di vulnerabilità, ma che non risolve la vulnerabilità sul prodotto interessato.

  Le attenuazioni possono includere l’utilizzo di dispositivi, o controlli di accesso, esterni al prodotto interessato. Le mitigation possono, o non possono, essere rilasciate dall’autore originale del prodotto e possono essere, o non essere, emesse ufficialmente dal produttore del documento.

• Vendor-Fix: sono disponibili informazioni su una correzione ufficiale rilasciata dall’autore originale del prodotto interessato. Salvo diversa indicazione, si presume che questa correzione risolva completamente la vulnerabilità.
• Nessuna disponibile: al momento non è disponibile alcuna correzione. Le informazioni dovrebbero contenere dettagli sul motivo per cui non vi è alcuna correzione.
• WillNotFix: non esiste una correzione per la vulnerabilità e non ce ne sarà mai una.

  Questo è spesso il caso in cui un prodotto su cui è stato abbandonato lo sviluppo, si trova al termine del ciclo di vita (end of life), o comunque deprecato.

  Le informazioni dovrebbero contenere dettagli sul motivo per cui non sarà emessa alcuna correzione.

5. La gravità della vulnerabilità riscontrata

La gravità è un valore compreso tra 0,0 (nessuna gravità) e 10,0 (gravità più alta) ed esprime anche una classe di gravità (Nessuna, Bassa, Media o Alta).

Questo concetto è basato su CVSS (Common Vulnerability Scoring System) ma è applicato anche dove non è disponibile un vettore base CVSS completo

Confronto, ponderazione, prioritizzazione: tutti possibili per qualsiasi risultato di scansione o NVT poiché questo concetto di severità è strettamente applicato all’intero sistema. (ndr: non ho capito questa severità!)

Le classi di gravità Nessuna, Bassa, Media e Alta sono definite da sotto-intervalli dell’intervallo principale 0.0-10.0.

Gli utenti possono scegliere di utilizzare diverse classificazioni. L’impostazione predefinita è la classificazione NVD, che è quella più comunemente utilizzata.

Ai risultati della scansione viene assegnata una severità mentre vengono testati e riscontrati. Tuttavia, la gravità del relativo NVT può cambiare nel tempo.

Gli utenti possono selezionare Gravità dinamica (Dynamic Severity) per consentire al sistema di utilizzare sempre la gravità NVT più recente.

6. La qualità del rilevamento

Quality of Detection (QoD) è un valore compreso tra 0% e 100% che descrive l’affidabilità del rilevamento della vulnerabilità o del rilevamento del prodotto.

Di seguito pubblichiamo una tabella che ha l’obiettivo di spiegare:

QoD	Tipo di QoD	Descrizione
100%	exploit	Il rilevamento è avvenuto tramite un exploit e quindi è completamente verificato.
99%	remote_vul	Controlli attivi remoti (esecuzione di codice, traversal attack, SQL injection etc.) In cui la risposta mostra chiaramente la presenza della vulnerabilità.
98%	remote_app	Controlli attivi remoti (esecuzione di codice, traversal attack, sql injection etc) In cui la risposta mostra chiaramente la presenza dell’applicazione vulnerabile.
97%	package	Controlli con tentativi di accesso autenticati basati su pacchetti per sistemi Linux (oid).
97%	registry	Controlli con tentativi di accesso basati sul Registro di sistema per sistemi Windows.
95%	remote_active	Controlli attivi remoti (esecuzione di codice, traversal attack, sql injection etc.) In cui la risposta mostra la probabile presenza dell’applicazione vulnerabile o della vulnerabilità. “Probabilmente” significa che sono possibili solo in rare circostanze in cui il rilevamento sarebbe sbagliato.
80%	remote_banner	Verifica di banner a distanza di applicazioni che offrono un livello di patch nella versione. Molti prodotti proprietari lo fanno.
80%	executable_version	Controlli della versione eseguibile autenticato per Linux (oid) o sistemi Windows in cui le applicazioni offrono un livello di patch nella versione.
75%		Questo valore è stato assegnato a qualsiasi risultato pre-qod durante la migrazione del sistema. Tuttavia, alcuni NVT alla fine potrebbero possedere questo valore per qualche motivo.
70%	remote_analysis	Controlli remoti che eseguono alcune analisi ma che non sono sempre completamente affidabili.
50%	remote_probe	Controlli remoti dove sistemi intermedi come i firewall potrebbero fingere il rilevamento corretto in modo che non sia in realtà chiaro se l’applicazione stessa ha risposto. Questo può accadere ad esempio per connessioni non TLS.
30%	remote_banner_unreliable	Verifica di banner a distanza di applicazioni che non offrono livello di patch nell’identificazione della versione. Ad esempio, questo è il caso di molti prodotti Open Source a causa di patch di backport.
30%	executable_version_unreliable	La versione eseguibile autenticata verifica i sistemi Linux (oid) in cui le applicazioni non offrono livello di patch nell’identificazione della versione.
1%	general_note	Nota generale sulla potenziale vulnerabilità senza trovare alcuna domanda presente.

Il valore 70% è il minimo predefinito utilizzato per visualizzare i risultati nei report.

Qualora volessimo visualizzare anche i risultati “nascosti” ci basterà agire sul parametro filter spiegato nelle righe superiori.

7. Come ottenere uno report ufficiale

Qualora volessimo avere un report in pdf del task appena eseguito possiamo cliccare in alto a sinistra su “Anonymous XML” e selezionare il formato desiderato da un elenco veramente molto fornito.

Selezionando il formato PDF viene creato un documento che può essere allegato all’audit da allegare alla documentazione GDPR.

8. Greenbone OpenVAS su pfSense

Ora che abbiamo imparato a eseguire le scansioni e sappiamo come produrre dei risultati possiamo provare a testare un firewall con pfSense.

Per testare la bontà di Greenbone OpenVAS simuliamo alcune criticità come:

• Una versione di pfSense non molto aggiornata (ver. 2.3.2)
• Abilitiamo la risposta al ping sulla nostra installazione di pfSense.
• Ci “dimentichiamo” la password di default.

Ora lanciamo la scansione mantenendo i valori de default.

Ecco i risultati:

Come possiamo osservare, Greenbone OpenVAS identifica immediatamente la presenza di credenziali di default e ce lo segnala con un QoD del 100% e segnala ben 50 risultati di cui:

• 5 con severity Hight
• 6 con severity Medium
• 1 con severity Low
• 30 classificati come Log.

Ora proviamo a peggiorare le cose e installiamo una vecchissima versione di pfSense:

• Versione pfSense1.5
• Abilitiamo la risposta al ping sulla nostra installazione di pfSense.
• Ci “dimentichiamo” la password di default.

Il risultato che otteniamo è il seguente:

Come si può notare abbiamo ottenuto ben 72 report rispetto ai 50 segnalati in precedenza.

Greenbone OpenVAS continua ad informarci immediatamente della presenza di credenziali di default. I 72 risultati sono suddivisi in:

• 8 con severity Hight
• 23 con severity Medium
• 5 con severity Low
• 36 classificati come Log.

Note Finali:

Normalmente non è bene che l’azienda che ha effettuato la vendita e l’installazione del firewall al cliente finale esegua le verifiche sulla sicurezza (o come abbiamo visto Vulnerability Assessment). Se ciò avvenisse sarebbe come se il “controllato” coincidesse con il “controllore”.