Guide

OpenVAS: testare la sicurezza di pfSense, OPNsense Zeroshell e IPfire con il sistema di Vulnerability Assessment System, gratuito più famoso del web.

Obiettivo di questo articolo:

Obiettivo di questa guida è:

  1. Misurare quanto il nostro firewall (e anche ciò che sta dietro) è, o non è, sicuro, mediante l’uso di un Vulnerability Assessment System, ovvero uno strumento che è in grado di trovare le vulnerabilità conosciute che affliggono il sistema scansionato, e consigliarci (talvolta) un metodo per risolvere il problema.
  2. Creare dei report sulla sicurezza che possano arricchire gli audit previsti dalla normativa GDPR.
  3. Testare OpenVAS su pfSense per misurare le vulnerabilità. Ovviamente con gli stessi parametri si potrebbe fare la stessa cosa con OPNsense Zeroshell e IPfire.

Per chi volesse approfondire altri aspetti legati all’ottimizzazione dei firewall legata alla normativa GDPR può leggere questo articolo. (link: https://www.firewallhardware.it/gdpr-e-pfsense-opnsense/ )

La situazione attuale: cosa sta capitando

È 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.

  • 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.

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ù manutentuto. 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, OPNsense, Zeroshell, IPfire è sicuro e ben configurato?

Chi ce lo può dire?

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

OpenVAS ci viene in aiuto!

Come abbiamo effettuato le prove

Di seguito elenchiamo gli strumenti che abbiamo utilizzato per questo articolo.

Hardware:
Virtual Appliance A3 Server, 32 GB RAM, dischi SSD.
Per far girare questa soluzione sarebbe anche utilizzabile hardware più economico come:
Virtual Appliance A2 Server, oppure Virtual Appliance A1 Server

Software:
Ambiente di virtualizzazione Proxmox VE, (https://www.firewallhardware.it/proxmox-ve/)
Macchina virtuale: S.O. Kali Linux, 8 GB RAM, 50 GB Disco, n. 4 core

Per chi volesse scaricare la VM già fatta e pronta per Proxmox VE (KVM), VmWare o Virtualbox portà scaricarla dal seg. link dopo essersi registrato con la mail.

Utilizzare OpenVAS per verificare i firewall e creare report per il GDPR.

Cosa è OpneVAS, come nasce e cosa fa.
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 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 VM che abbiamo creato, e che potete scaricare gratuitamente qui:

sia funzionante e aggiornata. Saltiamo quindi tutta la parte di installazione e configurazione iniziale.

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

# apt update

# apt upgrade

Fate partire il servizio dando il comando

# openvas-start

Accedete al localhost del sistema sulla porta 9392

# https://172.0.0.1:9392

La schermata che visualizzeremo sarà la seguente.

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

OpenVAS

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

OpenVAS

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

OpenVAS

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

OpenVAS

Per effettuare le prove abbiamo utilizzato una vecchia macchina con Windows XP che, chiaramente, ci darà modo di vedere come 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.

OpenVAS

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 openVAS tenterà di accedere. Questo per esempio ci permetterà di verificare se abbiamo dimenticato la nostra password di default sul nostro pfSense, OPNsense, Zeroshell o IPfire. In questo esempio lasceremo tutto di default.

OpenVAS

Clicchiamo su create, poi nuovamente create.

Abbiamo quindi creato il nostro primo task.

La schermata che vedremo sarà questa:

OpenVAS

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.

OpenVAS

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. 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”.

OpenVAS

In questa schermata possiamo osservare i risultati che 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.

Vulnerability: descrizione della vulnerabilità riscontrata.

Cliccando all’interno possiamo visualizzare i dettagli delle vulnerabilità trovate. Ad oggi nel database di 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.

Severity: ovvero 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.

Quality of Detection (QoD) ovvero 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

QoDTipo di QoDDescrizione
100%exploitIl rilevamento è avvenuto tramite un exploit e quindi è completamente verificato.
99%remote_vulControlli attivi remoti (esecuzione di codice, traversal attack, SQL injection etc.) In cui la risposta mostra chiaramente la presenza della vulnerabilità.
98%remote_appControlli attivi remoti (esecuzione di codice, traversal attack, sql injection etc) In cui la risposta mostra chiaramente la presenza dell’applicazione vulnerabile.
97%packageControlli con tentativi di accesso autenticati basati su pacchetti per sistemi Linux (oid).
97%registryControlli con tentativi di accesso basati sul Registro di sistema per sistemi Windows.
95%remote_activeControlli 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_bannerVerifica di banner a distanza di applicazioni che offrono un livello di patch nella versione. Molti prodotti proprietari lo fanno.
80%executable_versionControlli 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_analysisControlli remoti che eseguono alcune analisi ma che non sono sempre completamente affidabili.
50%remote_probeControlli 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_unreliableVerifica 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_unreliableLa versione eseguibile autenticata verifica i sistemi Linux (oid) in cui le applicazioni non offrono livello di patch nell’identificazione della versione.
1%general_noteNota 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.

Come ottenere uno report sulle vulnerabilità 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.

OpenVAS applicato ad un’installazione 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 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:

OpenVAS

Come possiamo osservare, 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:

OpenVAS

Come si può notare abbiamo ottenuto ben 72 report rispetto ai 50 segnalati in precedenza.
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.

Per chi volesse approfondire altri aspetti legati all’ottimizzazione dei firewall e la normativa GDPR può leggere questo articolo. (Link: https://www.firewallhardware.it/gdpr-e-pfsense-opnsense/ )

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”.

Per chi fosse interessato la nostra azienda offre questo tipo di servizio. Potete contattarci al seguente link (https://www.firewallhardware.it/contatti/ ).

  ti posso interessare anche