You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
52 lines
6.0 KiB
52 lines
6.0 KiB
\onehalfspacing
|
|
\section{Contesto Applicativo}
|
|
|
|
\subsection{Firewall}\label{firewall_cont}
|
|
Un \textit{\textbf{firewall}} è un componente \textit{software}, \textit{hardware} o una \textit{combinazione dei due} che filtra i flussi di traffico di rete, solitamente posto ai confini di essa. Filtra il traffico consultando una \textit{tabella di regole definite staticamente} che definiscono quale traffico può o non può passarci attraverso.
|
|
\newline
|
|
Le regole sono tradizionalmente espresse in \textit{cinque} tuple:
|
|
|
|
\begin{itemize}
|
|
\item indirizzo IP di origine
|
|
\item indirizzo di destinazione
|
|
\item protocollo di trasporto
|
|
\item numero della porta di origine
|
|
\item numero della porta di destinazione
|
|
\end{itemize}
|
|
|
|
I firewall possono utilizzare \textit{due} metodi di filtro contrastanti per applicare una politica di sicurezza della rete. Questi metodi possono essere descritti come \textit{permissivi} o \textit{restrittivi} \cite{collings2014openflow}.
|
|
|
|
I \textbf{\textit{firewall permissivi}} non eliminano il traffico per impostazione predefinita, a meno che non sia specificato. Al contrario, i \textbf{\textit{firewall restrittivi}} eliminano tutto il traffico per impostazione predefinita. In entrambi i casi, i flussi desiderabili di traffico richiedono precise specifiche, rispettivamente tramite \textit{blacklist} e \textit{whitelist}.
|
|
|
|
\subsection{Lavori collegati}\label{works}
|
|
I firewall basati su OpenFlow sono stati sviluppati e studiati nella ricerca per vari scopi.
|
|
|
|
Il lavoro del gruppo di \textit{Suh} \cite{suh2014building} per esempio si concentra sul miglioramento dell'interfaccia uomo-firewall per facilitare agli amministratori di rete l'installazione e l'aggiornamento delle politiche di rete, mentre il gruppo di \textit{Collings} \cite{collings2014openflow} sviluppa un firewall al fine di presentare un quadro di valutazione delle prestazioni di base per misurare l'overhead di comunicazione tra il controller e lo switch.
|
|
|
|
\textit{Wang} \cite{wang2013towards} si concentra sulle possibili problematiche e sfide per quanto concerne la sicurezza ed implementare firewall robusti basati su SDN.
|
|
|
|
Infine \textit{Bakker} \cite{bakker2016network} cerca di sfruttare appieno le capacità del paradigma SDN con OpenFlow e di spostare il concetto di firewall da elemento visto come barriera/filtro posto ai confini della rete ad elemento esteso su tutta la rete composto da una od una serie di poliche a seconda del tratto di rete che si va a considerare.
|
|
|
|
Quest'ultimo lavoro è quello su cui l'autore di questo scritto ha deciso di \textit{focalizzare l'attenzione}.
|
|
|
|
|
|
\section{Motivazioni}
|
|
|
|
I firewall tradizionali si limitano a filtrare il traffico nei loro punti di distribuzione.
|
|
Le ricerche sinteticamente presentate nel paragrafo \ref{works} hanno dimostrato che OpenFlow è una tecnologia adatta per il filtraggio dei pacchetti in una rete, tuttavia, eccetto per il lavoro del gruppo di \textit{Bekker} \cite{bakker2016network} non sembra essersi prestata sufficiente attenzione al modo in cui può essere utilizzata per filtrare in modo flessibile il traffico attraverso una rete che implementa di più di uno switch.
|
|
|
|
Un altro motivo per cui questo argomento merita più attenzione è che è potenzialmente una \textit{valida alternativa} al dover comprare (e poi integrare e mantenere) costosi firewall esterni dedicati da fornitori come Cisco o Juniper, ognuno con il proprio stack dedicato \cite{suh2014building}; che per giunta non è detto che siano facilmente integrabili tra di loro (tra marche diverse), oltre che mantenibili e scalabili se si guarda anche con un'ottica a lungo termine.
|
|
|
|
\subsection{Firewall non solo ai confini della rete}\label{firewall_confini}
|
|
Quello che il gruppo di \textit{Bekker} propone è un firewall virtuale basato su OpenFlow in grado di filtrare il traffico di rete attraverso \textit{un'intera rete, non solo ai limiti} \cite{bakker2016network}. Di conseguenza, i dispositivi di rete possono essere protetti indipendentemente dalla loro posizione e il firewall non può essere più un singolo punto di vulnerabilità (SPOF).
|
|
|
|
La soluzione proposta offre flessibilità grazie alla possibilità di raggruppare le regole del firewall in domini di politiche (policy domains) che possono quindi essere assegnati agli switch OpenFlow; l'applicazione delle regole può essere selettiva in base a criteri diversi ed arbitrari come posizione, ora, tipo di dispositivo, ecc...
|
|
|
|
\subsection{Nella pratica}
|
|
In pratica se ogni switch ethernet potesse funzionare come un firewall tradizionale, cambierebbe il modo in cui la politica di sicurezza viene implementata in un ambiente di rete. Immaginiamo se ogni switch ethernet fosse un firewall multiporta, quindi i criteri del firewall potrebbero essere implementati in tutta la rete, su ogni porta di ingresso di switch e su ogni collegamento tra switch. Ci sarebbero firewall per ogni server, desktop, ed ogni altro collegamento e la politica del firewall sarebbe implementata da un \textit{controller} che mantiene una visione \textit{\textbf{globale}} del traffico dell'applicazione corrente e potere decisionale su quale traffico dovrebbe essere consentito.
|
|
|
|
Avere una o più politiche di sicurezza applicata su tutto l'ambiente significherebbe una vera e propria \textit{\textbf{erosione del perimetro}} \cite{opengroup_erosion} di sicurezza della rete stessa.
|
|
|
|
Questo andrebbe tamponare in maniera non trascurabile il problema nella sicurezza che pone la politica negli ultimi anni di permettere agli utenti di collegare alla rete interna dell'organizzazione i propri dispositivi personali invalidando automaticamente l'oramai obsoleto \textit{"assioma"} che il traffico malevolo può venire solo dall'esterno \cite{bakker2016network}.
|
|
|
|
Detto questo, avere molte politiche di sicurezza implementate da gestire manualmente sarebbe un vero inconveniente. Tuttavia, come accennato nei paragrafi \ref{sdn} e \ref{openflow} con un'architettura di controller, la politica (policy) verrebbe creata una volta sola e poi trasferita atuomaticamente a tutti i dispositivi di rete associati per essere applicata.
|
|
|