Traduttore automatico - Read this site in another language

sabato 5 ottobre 2019

HOW-TO: Come costruire un proprio Firewall “fatto in casa”

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:


By at

Nessun commento:

Posta un commento

Iscriviti a: Commenti sul post (Atom)