La Network Functions Virtualization (NFV) è il processo di virtualizzazione delle funzionalità di rete che permette di sostituire i servizi forniti da dispositivi hardware di reti proprietarie con componenti software installati su commodity server. È così che si elimina la necessità di utilizzare dispositivi di rete fisici e dedicati come router, firewall e switch, scegliendo l’astrazione logica.
L’NFV e il Software Defined Networking (SDN), infatti, sono due approcci strettamente correlati tra di loro: quando il Software Defined Networking gira sull’infrastruttura NFV, inoltra i pacchetti di dati da un dispositivo di rete a un altro, mentre le funzioni del routing di rete vengono eseguite su una macchina virtuale. Ma sia la Network Functions Virtualization che il Software Defined Networking presentano diversi problemi legati alla sicurezza che non possono essere ignorati.
NFV: virtualizzare le funzioni di rete
La Network Functions Virtualization è nata dalla frustrazione dei service provider, perennemente impegnati nell’installare router di proprietà, gateway e altri dispositivi di rete per eseguire le funzioni di rete proprietarie. I fornitori puntavano a trovare un approccio che gli consentisse di virtualizzare funzioni di networking da qualsiasi punto della rete senza, dover tener conto dei vari dispositivi, vecchi o nuovi che fossero.
Così, nel gennaio del 2013, i service provider si sono consorziati, dando origine al Network Function Virtualization Industry Specification Group (NFV ISG) dell’ETSI (European Telecommunications Standards Institute), con l’obiettivo di sviluppare le specifiche utili a separare le funzioni di networking dalle apparecchiature proprietarie nell’infrastruttura NFV. Un dispositivo di interfaccia di rete (NID – Network Interface Device) non deve essere virtualizzato, ma è necessario per fornire un punto di demarcazione utile a misurare l’efficienza della rete.
SDN: controllare il data plane
Il Software Defined Networking, invece, è nato dalla frustrazione degli amministratori di rete di dover modificare il software ogni volta che occorreva sperimentare nuovi protocolli. La necessità di poter sorvegliare da un unico punto centrale e in tempo reale il comportamento dell’intera rete, ha spinto i team a trovare un nuovo approccio tecnologico. Poco dopo l’istituzione dell’Industry Specification Group (ISG) per la NFV è stato creato un nuovo gruppo per sviluppare specifiche sulla separazione del control plane dal data plane e per creare un controller SDN per la sua gestione. Il controller, tra le sue funzioni, gestisce il traffico proveniente da dispositivi di rete, sia fisici che virtuali e rappresenta il punto centrale da cui un amministratore di rete, tramite una console, può presidiare le informazioni relative a tutta la rete. OpenFlow, la prima interfaccia di comunicazione standard aperta SDN-based, viene utilizzato per accedere e inoltrare il traffico da un dispositivo a un altro nel piano dati. La criticità? Che da sè solo non garantisce una protezione da vulnerabilità e altri problemi di sicurezza.
La sicurezza nella Network Functions Virtualization: 4 cose da sapere
Sono quattro le considerazioni principali sulla sicurezza che gli amministratori di rete devono affrontare quando intendono integrare il Software Defined Networking nelle infrastrutture NFV.
#1 La vulnerabilità degli hypervisor è il primo aspetto da prendere inconsiderazione. Nelle infrastrutture NFV, funzioni di rete virtuali sono eseguite su macchine virtuali. Ciò è reso possibile da un hypervisor che permette a diverse macchine virtuali di condividere le risorse di un singolo computer o server. Una delle vulnerabilità è il cosiddetto hyperjacking, un tipo di attacco che consente a un hacker di superare il controllo di un hypervisor, ottenere l’accesso alle macchine virtuali meno sicure e, eventualmente, anche ai controller SDN configurati in modo errato o ad altri hypervisor non adeguatamente protetti.
#2 La vulnerabilità delle reti di grandi dimensioni sono la seconda considerazione da tenere in conto per gli amministratori di rete. Uno dei pericoli è il verificarsi di un attacco informatico disastroso in grado di colpire l’intera rete, che include multi-hypervisor. Per mitigare i rischi di un guasto completo della rete, l’amministratore deve considerare la possibilità di dividere una rete di grandi dimensioni in segmenti più piccoli. Con la segmentazione della rete l’amministratore può utilizzare un controller per dirigere il traffico da un segmento che comincia a rallentare – a causa, per esempio, di un denial of service – verso segmenti sani, senza spegnere l’intera rete.
#3 Le vulnerabilità del controller SDN dovrebbero essere affrontate dopo aver corretto le vulnerabilità nell’infrastruttura NFV. Quando viene installato prima il Software Defined Networking, l’amministratore deve configurare correttamente il controller, dato che una configurazione non corretta potrebbe permettere a un hacker di agire indisturbato. Gli aggressori possono superare il sistema come utenti root, fingersi host, deviare i flussi di rete a un dispositivo di rete già occupato e interferisce con i conflitti tra più dispositivi di rete SDN. Nella fase di realizzazione del controller è importante considerare le credenziali e le competenze dell’amministratore per assicurarsi che non si verifichino errori di configurazione.
#4 La capacità del controller SDN dovrebbe essere l’ultima considerazione da fare in merito alla sicurezza NFV. Un ambiente SDN su larga scala ha bisogno di più controller all’interno di una rete o tra le reti. La comunicazione tra più controller può essere attivata dalla cosiddetta interfaccia SDN east-west o SDNi. Per far sì che i controller possano inoltrare il traffico tra di loro necessitano di essere connessi utilizzando il Border Gateway Protocol per la condivisione delle informazioni di routing. Quando il traffico è leggero non è pratico avere tutti i controller SDN in esecuzione contemporaneamente. Per riuscire a contenere i costi energetici durante i periodi di traffico di rete basso, tenere attivo un solo controller può essere sufficiente. Sta all’amministratore di rete determinare quale sia il numero di controller necessari nelle ore di punta, nel caso in cui il traffico diventi improvvisamente pesante o la rete sia in espansione, considerando anche che avere troppi controller attivi contemporaneamente rende più difficile per l’amministratore applicare politiche di sicurezza e le correggere eventuali vulnerabilità.
