Amazon VPC (Virtual Private Cloud) è un servizio che offre un cloud privato virtuale, predisponendo una sezione logicamente isolata del cloud Amazon Web Services (AWS). I clienti aziendali possono accedere ad Amazon Elastic Compute Cloud (EC2) su una rete privata virtuale basata su IPsec. A differenza delle istanze EC2 tradizionali, a cui vengono assegnati numeri IP interni ed esterni da Amazon, con Amazon VPC il cliente può assegnare numeri IP a sua scelta da una o più sottoreti, il che fornisce un controllo sulla sicurezza molto più granulare. La premessa è che, per proteggere al meglio gli accessi al networking, gli amministratori AWS devono creare delle regole per le varie risorse di rete.
Le garanzie del cloud provider non bastano
Sebbene AWS abbia integrato la sicurezza in Amazon VPC, non è sufficiente fare affidamento solo sulla progettazione impostata dal fornitore. Per avere tutte le garanzie di un hosting ben presidiato, gli amministratori devono assicurarsi di configurare meticolosamente Amazon VPC per mantenere le applicazioni, i server e le varie risorse associate.
Amazon VPC: due diligence e garanzie di sicurezza
Quando si tratta di sicurezza della rete è possibile prevenire gli incidenti di sicurezza eseguendo la due diligence. In quanto attività di investigazione e di approfondimento di dati e di informazioni relative all’oggetto di una trattativa, la due diligence permette di valutare la convenienza di un servizio e di identificarne i rischi e i problemi connessi. Questo permette di negoziare termini e condizioni del contratto ma anche di predisporre adeguati strumenti di garanzia, di indennizzo o di risarcimento. Per evitare denial-of-service o attacchi SSH a forza bruta in Amazon VPC il modo migliore è creare VPC, sottoreti e gruppi di sicurezza ben presidiati. Si tratta di attacchi che possono essere facilmente prevenuti. Il problema è che in merito agli strumenti di sicurezza AWS, gli amministratori del cloud non sono tutti a conoscenza delle informazioni opportune.
3 Esempi di vulnerabilità
Il seguente estratto dal capitolo 4 di AWS Security pubblicato da Manning Publications estrapola tutte le linee guida utili a implementare tutti i framework di sicurezza relativi ad Amazon VPC.
#1 Attenzione alle configurazioni delle risorse
Può capitare che un utente malintenzionato provi a esfiltrare informazioni da un database accessibile pubblicamente. Perché questi database rimangono vulnerabili? Uno dei motivi è che la configurazione della sicurezza delle reti può comportare l’attivazione di molte risorse il che non è sempre fatto nel modo più pertinente. Ad esempio, se si va a creare un server Web e un database senza creare anche i gruppi di sicurezza, questi verranno inclusi in un gruppo di sicurezza predefinito. In questo modo, ogni volta che si dà un accesso alla rete pubblica al server web, si va a esporre anche il proprio database.
#2 Denial of Services
Un altro attacco comune è la negazione del servizio, nota come DoS o DDoS (Distributed Denial of Service). Questo tipo di attacco inonda un’applicazione con tonnellate di richieste false in modo da andare a sovraccaricare il sistema al punto da impedire di soddisfare le richieste reali. Gli esperti spiegano come utilizzare le risorse di rete AWS per mitigare alcuni tipi di attacchi Denial of Service utilizzando Web-App e firewall di nuova generazione.
#3 SSH (Secure Shell)
Un terzo attacco è quello che mira a ottenere l’accesso SSH a un server web. Quando si gestisce un sito web, generalmente il traffico all’Internet pubblico viene consentito di proposito. L’importante è assicurarsi di non aver esposto nulla di privato che potrebbe essere in esecuzione sullo stesso server. In molti casi un’istanza EC2 esegue un server Web e l’operatore apre tutto il traffico di rete all’istanza, il che consente a tutti di visualizzare il sito Web, ma anche a tutti di inviare altri tipi di traffico, come le connessioni SSH. Se si esegue l’SSH sulla porta predefinita, utilizzare un utente predefinito per il sistema operativo e una password per l’autenticazione anziché una chiave SSH è pericoloso. L’accesso al server da parte di un utente malintenzionato, infatti, diventa solo una questione di tempo. In questo articolo vedremo come creare facilmente regole che consentono l’accesso pubblico al proprio sito web, evitando di abilitare altri tipi di traffico, come l’SSH.
Linee guida per una corretta configurazione di Amazon VPC
Un estratto dal capitolo 4 di AWS Security pubblicato da Manning Publications estrapola tutte le linee guida utili a implementare tutti i framework di sicurezza relativi ad Amazon VPC .
IAM e VPC: similitudini e differenze
Oltre a configurare in modo sicuro l’accesso logico alle risorse AWS tramite IAM è fondamentale risolvere il controllo dell’accesso alla rete, principalmente tramite un cloud privato virtuale, o VPC, e le risorse di rete associate.
Molti dei concetti in IAM e VPC sono simili. Vogliamo creare regole che determinino chi ha un certo tipo di accesso alle nostre risorse AWS. In un sistema IAM le regole sono costituite da policy che specificano le azioni che possono essere eseguite a livello di API o di console e queste regole vengono applicate alle entità IAM (utenti, gruppi e così via) che vengono autenticate utilizzando le credenziali AWS.
Nella sfera della rete, le regole riguardano il tipo di traffico consentito nella rete e in seguito le risorse specifiche all’interno della rete. Ad esempio, una regola potrebbe consentire solo il traffico HTTPS nella rete e solo sulla porta 443. Invece di essere applicate alle entità autenticate, queste regole vengono applicate in base all’origine del traffico; oppure, sarebbe possibile applicare la precedente regola del traffico HTTPS a qualsiasi traffico proveniente dall’esterno della rete, consentendo qualsiasi tipo di traffico proveniente dalla tua rete. Sebbene i concetti siano simili, i meccanismi per la creazione e la configurazione di queste regole di accesso sono completamente diversi. In questo capitolo, esamineremo le principali risorse di rete Amazon VPC e come configurarle.
Lavorare con un cloud privato virtuale
Le regole che creiamo per controllare l’accesso alla rete in AWS si applicano a varie risorse di rete. Per capire come funzionano queste regole, dobbiamo prima comprendere le principali risorse di rete a disposizione.
- VPC: Al livello più alto, abbiamo il VPC. Un VPC rappresenta una rete isolata. All’interno di un VPC abbiamo sottoreti o singole sottoreti. La maggior parte delle risorse di rete, come le istanze EC2, sono collegate a una sottorete. Queste sottoreti possono essere pubbliche o private, il che si riferisce al fatto che le risorse all’interno della sottorete siano accessibili o meno su Internet pubblico. Il traffico tra le risorse all’interno di un VPC verrà instradato attraverso il VPC stesso. Il traffico non lascia Amazon VPC invulnerabile agli stessi tipi di attacchi di snooping e man-in-the-middle come se fosse passato su Internet pubblico. Per questo motivo, quando possibile, è meglio mantenere il traffico all’interno di Amazon VPC e non instradare il traffico sulla rete Internet pubblica. Questo è un concetto così importante che esistono diverse risorse di rete per questo scopo specifico come, ad esempio, peering VPC, PrivateLink o TransitGateways.
- Elastic Network Interface (ENI): un equivalente virtuale di una scheda di rete.
- IP elastici (EIP): un indirizzo IPv4 pubblico assegnato al tuo account.
- Internet Gateway (IGW): una risorsa che consente alla rete di comunicare con la rete Internet pubblica.
- Gateway NAT: una risorsa che consente di avviare connessioni a Internet pubblico dall’interno della rete, ma non viceversa.
- Gateway Internet solo in uscita: l’equivalente IPv6 di un gateway NAT.
L’utilizzo di Amazon VPC e di altre risorse di rete consente di controllare l’accesso alla rete da e verso le tue risorse AWS. La configurazione di firewall virtuali integrati come gruppi di sicurezza e ACL di rete permette di bloccare la rete e proteggerla dall’accesso non autorizzato alle risorse.
Come impostare Amazon VPC per gestire un account
Partendo dal presupposto che Amazon VPC è una rete virtuale, se si desidera creare delle risorse di rete in AWS, prima è necessario creare un VPC. Questa è un’attività relativamente facile, perché un VPC ha solo un paio di opzioni. Il principale è il blocco CIDR (Classless Inter-Domain Routing). Questo è l’intervallo di indirizzi IP che sarà disponibile per l’uso nella propria rete. I blocchi CIDR si riferiscono a un intervallo di indirizzi IP sequenziali. Ecco alcuni esempi di blocchi CIDR:
- 0.0 / 24
- 1.1 / 32
- 0.0 / 0
I blocchi CIDR sono costituiti da un indirizzo IP seguito da una barra e un numero compreso tra 0 e 32. L’indirizzo IP si riferisce all’IP più piccolo nel blocco e il numero dopo la barra si riferisce alla dimensione della rete. La dimensione della rete è gli indirizzi IP, dove è il numero dopo la barra. Notare che numeri più grandi corrispondono a dimensioni di rete più piccole. Un blocco CIDR che termina con / 32 risulterebbe in un solo indirizzo IP e un blocco che termina con / 24 produrrebbe 256 indirizzi. La Tabella 4.1 contiene gli intervalli di indirizzi IP che corrispondono ai blocchi CIDR di esempio precedenti.
Quando si sceglie un blocco CIDR per il VPC Ci sono due cose importanti da considerare.
- La prima è che per ciascuna risorsa di rete che viene inserita nel VPC, il blocco CIDR verrà assegnato all’indirizzo IP privato. Se si crea un VPC con un blocco CIDR / 24 che ha 256 indirizzi, in quel VPC non è possibile inserire più di 256 risorse. In effetti, AWS riserva cinque indirizzi IP all’interno di ogni sottorete, quindi se anche si avesse una sola sottorete sarebbe possibile inserire solo 251 risorse in un VPC di dimensioni / 24. Esiste un modo per associare un blocco CIDR aggiuntivo al VPC, ma questo presuppone la scelta di una dimensione di rete abbastanza grande da supportare tutte le risorse che si prevede di inserire nel VPC.
- La seconda cosa da considerare è che gli intervalli IP sovrapposti creano problemi di routing. Ad esempio, Google utilizza gli indirizzi IP nel blocco 64.233.160.0/24. Se si crea un VPC con lo stesso blocco, ci si ritroverà con un host che ha lo stesso indirizzo IP dei server di Google, il che rende difficile determinare dove debba essere instradato il traffico. Per questo motivo, è necessario attenersi agli intervalli riservati alle reti private, come 10.0.0.0/8 (10.0.0.0—10.255.255.255) e 172.16.0.0/12 (172.16.0.0—172.31.255.255). Inoltre, se si prevede di instradare il traffico tra due VPC non si dovrebbero mai utilizzare intervalli sovrapposti. AWS crea automaticamente un VPC per ogni account (chiamato VPC predefinito). Questo VPC è configurato con l’intervallo CIDR 172.31.0.0/16 ed è inizializzato con sottoreti pubbliche e un gateway Internet. In questo modo è facile iniziare con molti servizi AWS come EC2, perché è possibile avviare un’istanza e accedervi, senza preoccuparsi di configurare queste risorse di rete. Tuttavia, la configurazione del VPC predefinito probabilmente non è la più sicura per qualsiasi cosa: in certi casi è necessario andare a creare tutte le risorse autonomamente.
Come creare un VPC da zero
Per creare un VPC va usato il comando create-vpc di AWS CLI:
Come gestire le sottoreti di Amazon VPC, private e pubbliche
Una subnet è una rete più piccola all’interno di Amazon VPC che contiene un intervallo parziale di indirizzi IP nel VPC. Mentre i VPC risiedono in una regione AWS, le sottoreti risiedono in una zona di disponibilità specifica. Queste subnet si trovano laddove è possibile posizionare le proprie risorse di rete. Se si ha un’istanza EC2, non è possibile avviarla in un VPC. È necessario avviarla all’interno di una sottorete specifica in quel VPC. Questo significa che, se si vuole fare qualcosa all’interno di Amazon VPC, è necessario creare delle subnet.
Subnet private: quando si creano delle subnet è necessario battezzarle con una ripartizione come, ad esempio, PublicSubnet e PrivateSubnet. Come accennato in precedenza, le sottoreti pubbliche sono quelle a cui è possibile accedere tramite Internet pubblico, mentre le sottoreti private sono quelle che non possono. Nel caso succitato entrambe le sottoreti che create possono essere private, poiché per impostazione predefinita non esiste alcuna connessione tra una sottorete e la rete Internet pubblica. La trasformazione di una sottorete privata in una sottorete pubblica richiede la creazione di un gateway Internet e una tabella delle rotte.
Subnet pubbliche: Le sottoreti predefinite create da AWS nel VPC predefinito sono subnet pubbliche. Essendo configurate con route a un gateway Internet, se si collega un’istanza a una delle sottoreti predefinite, questa sarà accessibile pubblicamente. Vale la pena notare che questo è diverso dal comportamento della sottorete appena creata, che è privata. Non è possibile eseguire un SSH dalla propria stazione di lavoro a un’istanza collegata a una sottorete privata senza prima configurare un gateway Internet e percorsi appropriati.
Interfacce di rete e IP
Partendo dal presupposto che le istanze sono collegate alle sottoreti, l’operazione viene eseguita collegando prima un’interfaccia di rete elastica (ENI) all’istanza e quindi collegando la stessa alla subnet.
Cos’è esattamente un’interfaccia di rete elastica? Le interfacce di rete elastiche sono l’equivalente virtuale di una scheda di rete o di una scheda di rete su una macchina fisica che lavora con un cloud privato virtuale 7. Le ENI costituiscono la connessione tra le risorse di rete come le istanze EC2 e una rete virtuale. È possibile allegare ENI aggiuntivi alle proprie istanze, sapendo che potranno trovarsi in due sottoreti diverse. Questo crea quelle che vengono chiamate istanze dual-homed. Il processo di creazione e collegamento dell’ENI viene astratto nel processo di creazione di un’istanza. Quando si crea un’istanza tramite l’AWS CLI o la console, AWS andrà a creare automaticamente l’ENI, lo collegherà alla nuova istanza e lo collegherà alla sottorete specificata.
