Un
metodo pratico per risparmiare e tenere al sicuro i propri dati.
In questo periodo in cui le finanze delle Aziende e Pubbliche
Amministrazioni sono messe a dura prova, è facile trovare Direttivi
che pensano alla Sicurezza come ad un costo, e non come un’esigenza
reale della propria infrastruttura.
E’ facile, dunque,
immaginare uno scenario abbastanza preoccupante dove la struttura non
è propriamente adeguata.
Server non adeguati,
software non aggiornati, nessuna possibilità di modifica delle
piattaforme e chi più ne ha più ne metta.
Determinati contesti
in realtà non sono rari ed è quindi doveroso prepararsi ad agire
anche a fronte di scarse risorse.
In generale,
implementare una soluzione software su hardware non dedicati, come la
soluzione che andremo ad analizzare di seguito, può essere
concretamente utile nei seguenti casi:
- Mancanza di fondi
- Necessità di
adottare una soluzione “tampone” senza costi aggiuntivi in caso
di estrema emergenza
- Necessità di
difendere piccole macchine (ad esempio laptop) e non poter adottare
soluzioni “classiche”, per via di condizioni eccezionali.
- Necessità di
riconfigurare una rete isolata, ad esempio un laboratorio, senza
dover acquistare hardware aggiuntivo, mantenendo la flessibilità
della rete stessa.
Questi sono solo
alcuni esempi, in realtà le possibilità sono molte.
A seconda dei casi,
nel caso si voglia adottare la soluzione basata su Windows, non si
avrà un calo considerevole delle prestazioni.
Il discorso cambia
nel caso si voglia adottare OPNSense.
Consiglio OPNSense
se non sono mai stati eseguiti dei test sulle applicazioni e i
sistemi da difendere, mentre Windows nel caso in cui si conosca bene
il limite delle proprie applicazioni e come mettere in sicurezza il
codice.
E’ possibile, con
un po’ di pazienza, risparmiare su Firewall hardware e UTM
(comunque caldamente consigliati), per andare a proteggere una
“situazione disperata”?
I Firewall Hardware
sono degli apparati appositamente costruiti per ospitare un sistema
operativo (il “cuore” di ogni elaboratore), di solito in versione
“hardened”.
Per Sistema
Operativo (OS) “hardened” (rinforzato), si intende un Sistema a
cui sono state applicate delle specifiche patch e bugfix, ovvero
delle specifiche correzioni e modifiche, che permettono al sistema
stesso di resistere a fronte di numerose tipologie di attacchi.
Gli UTM (Unified
Threat Management – Gestione Unificata delle Minacce) sono delle
macchine le quali possono gestire numerose tipologie di attacchi in
maniera centralizzata.
L’utente può, ad
esempio, impostare delle regole sia per il Firewall, che per il
filtro anti-spam direttamente da un’unica interfaccia, di solito
accessibile via browser.
Ovviamente in una
“situazione disperata” non abbiamo nulla di tutto ciò a livello
“hardware”, dovremo quindi ingegnarci per trovare una soluzione
ad un problema piuttosto difficile.
Quello che può
ricorrere in nostro aiuto è la “virtualizzazione”.
La virtualizzazione
è una specifica tecnica che permette di “astrarre”, ovvero
rendere disponibili in maniera virtuale, delle componenti hardware.
Per spiegare meglio
il concetto, immaginiamo di avere un processore (il componente che
nell’elaboratore esegue materialmente le operazioni) di 20 “cores”
(le varie unità che nel processore eseguono i calcoli).
Tramite la
virtualizzazione possiamo “separare” ad esempio 10 cores e
dedicarli ad un altro sistema operativo.
Lo stesso concetto
di “dedicare” o “astrarre” una porzione di hardware ad altri
software può essere applicato con la RAM, con le schede di rete ecc.
Questo permette di
avere contemporaneamente un sistema operativo “host” (il sistema
operativo principale) e più sistemi “guest” (i sistemi
virtualizzati), sulla stessa macchina, contemporaneamente
funzionanti.
Il componente che
permette questa “astrazione” è detto “Hypervisor”.
In commercio si
possono trovare molti sistemi di virtualizzazione, i quali hanno in
alcuni casi dei costi di licenza proibitivi per la nostra “situazione
disperata”.
Nel nostro caso, la
scelta del sistema di virtualizzazione ricade sul software
VirtualBox, sviluppato da Oracle.
VirtualBox è un
software Open Source, ovvero il suo codice è aperto, cioè leggibile e modificabile da chiunque.
Ma perché la
virtualizzazione può venire in nostro aiuto?
Per rispondere a
questo, dobbiamo pensare al “concetto” di UTM.
Concettualmente un
sistema di sicurezza può essere semplificato come una “scatola
nera” con due cavi, uno di entrata e uno di uscita.
Il cavo di entrata
si collega direttamente ad Internet, e da lì arrivano dei pacchetti
(ovvero dati e connessioni) di cui non conosciamo la natura, se
malevola o legittima.
Nella scatola nera
avviene il controllo, e i pacchetti malevoli vengono scartati, mentre
i legittimi vengono fatti passare tramite il cavo di uscita, verso la
macchina che contiene il servizio vero e proprio (un sito web, ad
esempio).
E’ quindi
fondamentale tenere presenti tre aspetti fondamentali:
- La “scatola
nera” deve essere “davanti” alla macchina da proteggere
- La “scatola
nera” deve essere collegata ad internet
- La “scatola
nera” deve filtrare i pacchetti in ingresso
Questo tipo di
configurazione sembra essere perfetta per il nostro caso, ovvero una
macchina virtuale, che diventa la nostra “scatola nera”.
Il fatto che
VirtualBox sia Open Source, ci aiuta a non imbatterci in costi
inaspettati, e per aiutarci a non avere “brutte sorprese”, non
installeremo il pacchetto “Extension Pack” di VirtualBox.
Le soluzioni
proposte qui sono in realtà due, con relativi vantaggi e svantaggi:
- Soluzione basata
su Windows 7 (si, esattamente su Windows 7)
- Soluzione basata
su OPNSense
La soluzione basata
su Windows 7 ha il vantaggio di avere un consumo di risorse minimo e
una velocità di connessione pari a quella della macchina “host”
direttamente collegata alla Rete.
Lo svantaggio di
avere Windows 7 è che di default non possiede nessun Intrusion
Prevention System (un sistema che rileva e blocca in automatico
eventuali pacchetti malevoli).
La soluzione basata
su OPNSense ha il vantaggio di avere moltissimi strumenti di
controllo e può essere configurato facilmente come Intrusion
Prevention System (IPS).
Lo svantaggio di
OPNSense è dato dai suoi stessi strumenti, ovvero l’impatto sulle
risorse hardware è maggiore, e dal momento che l’IPS deve
controllare il flusso dati, anche l’impatto sulla velocità di
connessione sarà notevole.
Si è scelto
OPNSense rispetto a pfSense (sistema analogo a OPNSense) per il suo
sistema di analisi.
PfSense utilizza un
componente di nome “Snort”, il quale analizza i pacchetti in
transito e risulta piuttosto pesante, soprattutto se installato su
macchina virtuale.
OPNSense utilizza Suricata ovvero un altro sistema di analisi dei
pacchetti che sfrutta il multithreading, ovvero una tecnica che
permette di eseguire più processi di calcolo contemporaneamente da
parte del processore.
Ad oggi Suricata è
un sistema NIDPS, ovvero Network Intrusion Detection and Prevention
System (esattamente ciò che ci serve, in quanto riesce a prevenire
le minacce e non solo ad individuarle), mentre Snort è un NIDS,
ovvero un Network Intrusion Detection System.
Questa combinazione
è preferibile, specialmente in una macchina virtuale dove si deve
prestare particolare attenzione all’impatto che questi sistemi
possono avere sulle performance generali.
Il sistema da
difendere è Metasploitable, ovvero una macchina virtuale
appositamente costruita per essere vulnerabile.
In questo caso,
immaginiamo che Metasploitable sia il sistema da proteggere:
Analizziamo, quindi, come installare e rendere operative queste due
soluzioni.
Lo scenario iniziale
vede il nostro sistema senza difese.
Analizziamolo
utilizzando Kali Linux, una distribuzione appositamente costruita per
aiutare i Penetration Testers, ovvero persone che bucano sistemi per
lavoro, per trovarne le vulnerabilità e sanarle.
Per prima cosa,
facciamo una rapida scansione con nmap (un tool molto efficace che
permette di scoprire le porte aperte e altre informazioni relative al
sistema bersaglio):
Come si può vedere, la situazione del nostro sistema è disastrosa.
Le numerose porte
aperte espongono dei servizi della macchina, molti di loro
vulnerabili.
Proviamo a lanciare
un attacco verso la macchina, per questo test, dal momento che è
solo una prova, utilizzerò “db_autopwn”, un comando di
Metasploit che semplifica il lancio di exploit verso il bersaglio.
Il comando
“db_autopwn” è deprecato (cioè sconsigliato), e per questo test è stato utilizzato
un modulo esterno che reimplementa il comando sull’ultima versione
di Metasploit.
Come si può notare, Metasploit è riuscito ad aprire due sessioni
sulla macchina:
Per la prima soluzione abbiamo a disposizione Windows 7, installato
su una macchina virtuale.
Apriamo VirtualBox e
configuriamo due schede di rete, in questo modo:
Abbiamo bisogno di due schede di rete, connesse in modalità bridge,
alla scheda di rete attualmente connessa ad internet.
Abbiamo quindi
creato la situazione della “scatola nera”, almeno a livello
hardware.
Vediamo come
configurare la macchina, a livello software.
Per prima cosa,
dobbiamo configurare sulla prima scheda di rete, la connessione
reale, ovvero l’indirizzo IP e il gateway di rete (dobbiamo quindi
fare in modo che la prima scheda di rete sia funzionante e collegata
ad internet).
Ovviamente questa configurazione è solo un esempio, e in questo caso
Windows non è realmente collegato ad internet.
Una volta impostato
l’indirizzo IP per la prima scheda, sempre sulla stessa scheda
dobbiamo attivare la condivisione della connessione internet
Ora, nel caso in cui volessimo esporre dei servizi (ad esempio il
sito web) su internet, clicchiamo su “impostazioni” e settiamo
“Server Web (HTTP)”
Perchè questa configurazione?
Attivando la
condivisione connessione internet, sulla seconda scheda di rete viene
impostato da Windows una sottorete fittizia “192.168.137.x”.
La nostra macchina
da proteggere, in questo caso, è impostata sull’indirizzo IP
“192.168.137.143”, di conseguenza questo indirizzo va settato
nella maschera “Impostazioni servizio” come mostrato in figura
precedente.
Ora confermiamo il
tutto, cliccando su “OK” sulle varie maschere.
Una volta
confermato, apriamo “secpol.msc”
Sull’icona
“Criteri di sicurezza IP”, cliccando con il pulsante destro del
mouse, è possibile creare un nuovo criterio di sicurezza IP.
Nella procedura guidata, diamo un nome alla nostra configurazione e
andiamo sempre avanti, fino alla creazione del filtro.
A questo punto ci
troviamo davanti ad una nuova schermata, quindi clicchiamo su
“Aggiungi”, andiamo sempre avanti fino alla schermata “Elenchi
Filtri IP”.
Qui clicchiamo su
“Aggiungi”
Dobbiamo creare la prima regola, ovvero dobbiamo bloccare qualunque
connessione su qualunque porta.
Per fare questo,
clicchiamo su “Aggiungi” e andiamo sempre avanti, in questo modo
abbiamo creato una regola che funziona su qualunque Connessione, per
qualunque protocollo.
Selezioniamo la
regola appena creata e andiamo avanti.
Nella schermata
successiva (Operazioni filtro), clicchiamo su “Aggiungi”, diamo
il nome “Blocca” e clicchiamo su “Blocca”.
Una volta creata l’operazione filtro, selezioniamola e andiamo
avanti per confermare la creazione della regola completa.
Ora abbiamo appena
bloccato tutte le porte per tutte le connessioni della macchina, dal
momento che nel nostro caso vogliamo rendere disponibile il sito web
sulla porta 80, dobbiamo creare un’altra regola, che autorizza il
passaggio dei dati sulla porta 80.
Sulla creazione del
filtro IP, appena arriviamo sulla pagina “Protocolli”
specifichiamo “TCP” e nelle porte, al secondo campo di testo
clicchiamo sull’opzione “a questa porta” e specifichiamo la
porta 80.
Mentre nelle operazioni filtro, questa volta dobbiamo specificare
“Autorizza”
Una volta completata
la configurazione, clicchiamo con il tasto destro sul filtro creato e
successivamente su “Assegna”
A questo punto, possiamo eseguire nuovamente i nostri test:
Il sito è funzionante
Le porte inoltre sono coperte dalla “scatola nera” che abbiamo
inserito tra la rete internet e la nostra macchina.
Attacchiamo, quindi,
di nuovo la nostra macchina per testare se la configurazione ha
cambiato qualcosa:
Come possiamo vedere, Metasploit non è riuscito ad aprire sessioni.
Perchè abbiamo
questo brusco cambio di comportamento, nonostante non abbiamo
modificato/aggiornato il sistema?
Il motivo è insito
nel tipo di configurazione che abbiamo impostato.
Questo tipo di
configurazione prevede l’utilizzo della condivisione connessione
per creare una sotto-rete, tramite la quale si collega alla nostra
macchina.
Se avessimo
utilizzato solo la condivisione della connessione, Metasploit sarebbe
comunque riuscito ad aprire una sessione, in quanto nonostante
l’inoltro delle porte fosse impostato sulla 80 (per rendere
disponibile il sito web dall’esterno), non avrebbe comunque
impedito le “reverse connections”, ovvero una connessione ad una porta aperta da un client interno alla rete per consentire la connessione di un server remoto.
Quando attacchiamo
una macchina, ciò che permette la comunicazione del bersaglio alla
nostra macchina è il “payload”, ovvero un software che si
connette alla nostra macchina, permettendo di lanciare comandi e
interagire con il bersaglio, agendo da “ponte” tra noi e il
bersaglio.
Dal momento che le
porte “classiche” sono già utilizzate dai normali servizi del
bersaglio, il payload non può sfruttare tali porte per comunicare.
Di conseguenza, il
payload attiva una connessione su una porta randomica e generalmente
superiore alla 10000 che, connettendosi al nostro computer, permette
di stabilire la comunicazione tra noi e il bersaglio.
Per risolvere questo
problema, derivato dal fatto che generalmente le connessioni in
uscita non vengono bloccate dai firewall, abbiamo utilizzato il filtro sopra
descritto, per impedire connessioni non volute.
In questo modo,
anche se il sistema non è aggiornato, o esiste una vulnerabilità
sfruttabile, l’aggressore non può sfruttare gli exploit
disponibili in quanto i payload non possono comunicare.
Ovviamente, questa
soluzione non impedisce lo sfruttamento di SQL Injection o altre
vulnerabilità che non hanno bisogno di un payload per poter
comunicare con la nostra macchina.
Ricordo infatti, che
con questa soluzione non è disponibile l’analisi dei pacchetti.
Per abilitare
l’analisi dei pacchetti, dovremo per forza di cose affidarci ad un
software di “Intrusion Prevention”.
Per questa
situazione è stato individuato OPNSense, che come descritto in
precedenza utilizza Suricata come sistema di analisi dei pacchetti, e
Netmap per diminuire il carico sulla CPU e ottimizzare le schede di
rete.
Vorrei porre
all’attenzione sul fatto che non c’è un cambiamento nello schema “logico”
che abbiamo creato, né tantomeno all’infrastruttura
virtualizzata.
Cambia solo il
sistema operativo della “scatola nera”, per permettere appunto
l’analisi dei pacchetti in tempo reale.
Per permettere ad
OPNSense di operare al meglio, dedichiamo alla macchina virtuale 2 GB
di RAM (a differenza della prima soluzione, dove era sufficiente
anche un solo GB).
Ecco un esempio di
configurazione per OPNSense:
Avviando la macchina, compare la schermata di accesso:
La macchina che dobbiamo proteggere, quindi, nel nostro caso avrà
come indirizzo IP “192.168.2.2” e come gateway “192.168.2.1”.
Possiamo entrare
nella configurazione di OPNSense, collegando un dispositivo alla LAN
e, tramite un normale browser, puntando al link “
https://192.168.2.1”
Si aprirà il
seguente pannello:
Una volta loggati, ci troviamo di fronte al pannello principale di
OPNSense:
Andiamo su “Services” → “Intrusion Detection” →
“Administration” e spuntiamo tutte le opzioni:
Clicchiamo su “applica” e andiamo su “download”:
Clicchiamo sulla spunta per selezionare tutto, dopodichée clicchiamo
su “Enable selected”, quindi riselezioniamo tutto e clicchiamo su
“Enable (drop filter)”.
Per finire, a fondo pagina clicchiamo su “Download and update
rules”.
Controlliamo quindi
che tutte le regole siano correttamente aggiornate, e abbiamo quindi
impostato l’analisi dei pacchetti.
Per coprire ogni
tipo di casistica, impostiamo il “caching proxy”.
Il caching proxy è
un componente, già presente in OPNSense, che permette di estendere
la capacità di rilevamento delle intrusioni da parte di Suricata.
Questo perché per i
protocolli cifrati, come HTTPS, Suricata non riuscirebbe a decifrare
i dati in transito in tempo reale.
Per evitare questo
problema, il caching proxy permette di fare da ponte tra la rete
esterna e il sito web visitato.
Facendo da ponte, i
pacchetti vengono decifrati dal proxy, che solo successivamente li
ritrasmette al servizio vero e proprio.
Ovviamente questa
operazione avviene anche in maniera speculare.
Questo permette ai
pacchetti di poter essere controllati da Suricata.
Il software che
permette tutto questo si chiama “Squid”.
Per abilitare squid
su OPNSense, andiamo su “Services” → “Web Proxy” →
“Administration”, spuntiamo “Enable Proxy”:
Andiamo poi su “Forward Proxy” e abilitiamo le tre spunte come in
figura.
Nonostante queste soluzioni rappresentino una valida alternativa per
quelle realtà che non possono provvedere all’acquisto di strumenti
hardware-based, io raccomando comunque l’utilizzo della soluzione hardware.
In conclusione, se
vogliamo proprio dormire sonni tranquilli, raccomando sempre di
installare gli ultimi aggiornamenti per i sistemi operativi
utilizzati, scrivere codice testandone anche le varie vulnerabilità
utilizzando strumenti automatici e non, ed infine raccomando di
cambiare la propria mentalità nei confronti della sicurezza: la sicurezza non è
un prodotto, non lo è mai stata e non lo sarà mai, bensì è un
processo e come tale ha bisogno di essere seguito, standardizzato,
applicato e controllato.
Alessandro Fiori
Per approfondire: