Questo articolo è il quarto di una serie di articoli su "Come prendere il controllo della propria infrastruttura di rete". Il contenuto di tutti gli articoli della serie e i relativi link possono essere trovati qui.

In parte uno In questo capitolo abbiamo esaminato alcuni aspetti della sicurezza della rete nel segmento "Data Center". Questa parte sarà dedicata al segmento "Internet Access".

Accesso a Internet

Il tema della sicurezza è sicuramente uno dei più complessi nel mondo delle reti di trasmissione dati. Come nei casi precedenti, senza pretendere approfondimenti e completezza, discuterò qui questioni relativamente semplici ma, a mio avviso, importanti, le cui risposte spero possano contribuire ad aumentare il livello di protezione della vostra rete.

Durante l'audit di questo segmento, fate attenzione ai seguenti aspetti:

il design
configurazioni BGP
protezione DOS/DDOS
filtraggio del traffico sul firewall

Design

Come esempio di design per questo segmento per la rete di un'azienda, suggerirei la guida di Cisco nell'ambito del modello SAFE.

Certo, è possibile che soluzioni di altri fornitori vi sembrino più attraenti (vedi il quadrante di Gartner del 2018), ma, senza invitarvi a seguire in dettaglio questo design, ritengo comunque utile comprendere i principi e le idee che ne stanno alla base.

Nota
Nel segmento SAFE, «Remote Access» fa parte di «Internet Access». Tuttavia, in questo ciclo di articoli lo esamineremo separatamente.

L'attrezzatura standard in questo segmento per la rete aziendale (enterprise network) include

router di confine (border routers)
firewall

Nota 1
In questo ciclo di articoli, quando parlo di firewall, mi riferisco a NGFW.

Nota 2
Escludo l'analisi di vari tipi di soluzioni L2/L1 o overlay L2 su L3 necessarie per garantire la connettività L1/L2 e mi limito solo agli aspetti di livello L3 e oltre. In parte, le questioni L1/L2 sono state trattate nel capitolo «Pulizia e documentazione«.

Se non hai trovato un firewall in questo segmento, non affrettarti a fare conclusioni.

Dunque, come in parte precedente, iniziamo con la questione se sia necessario utilizzare un firewall in questo segmento nel tuo caso.

Posso dire che sembra essere il posto più giustificato per l'uso di firewall e per l'applicazione di algoritmi di filtraggio complessi. In parte 1 abbiamo menzionato 4 fattori che possono ostacolare l'uso dei firewall nel segmento dei data center. Ma qui non sono già così rilevanti.

Esempio 1. Latenza
Quando si parla di internet, non ha senso discutere di latenze anche di 1 millisecondo. Pertanto, la latenza in questo ambito non può rappresentare un fattore limitante per l'uso dei firewall.

Esempio 2. Prestazioni
In alcuni casi, questo fattore può comunque essere rilevante. Quindi, potrebbe essere necessario instradare una parte del traffico (ad esempio, il traffico dei bilanciatori di carico) al di fuori del firewall.

Esempio 3. Affidabilità
Questo fattore deve ancora essere considerato, ma considerando l'affidabilità stessa di internet, la sua importanza per questo ambito non è così significativa come per un data center.
Supponiamo che il tuo servizio operi sopra http/https (con sessioni brevi). In questo caso, puoi utilizzare due macchine indipendenti (senza HA) e, in caso di problemi con una di esse, reindirizzare tutto il traffico sulla seconda.
Oppure puoi utilizzare i firewall in modalità trasparente e, nel caso in cui si verifichi un malfunzionamento, instradare temporaneamente il traffico al di fuori dei firewall mentre risolvi il problema.

Pertanto, è proprio questo il prezzo può essere il fattore che ti porterà a rinunciare all'uso dei firewall in questo ambito.

Attenzione!
C'è la tentazione di combinare questo firewall con quello del data center (utilizzare un solo firewall per questi segmenti). La soluzione, in linea di principio, è possibile, ma bisogna tenere a mente che, poiché il firewall per l'«Accesso a Internet» si trova effettivamente in prima linea nella vostra difesa e gestisce, almeno in parte, il traffico malevolo, è necessario considerare il maggiore rischio che questo firewall possa essere compromesso. In altre parole, utilizzando gli stessi dispositivi in entrambi questi segmenti, ridurrete notevolmente la disponibilità del vostro segmento del data center.

Come al solito, è fondamentale comprendere che, a seconda del servizio che l'azienda fornisce, il design di questo segmento può variare notevolmente. Potete, come al solito, scegliere diversi approcci a seconda delle esigenze.

Esempio
Se siete un fornitore di contenuti, con una rete CDN (vedi, ad esempio, una serie di articoli), potresti non voler creare infrastrutture in decine, se non centinaia, di punti di presenza utilizzando dispositivi separati per indirizzare e filtrare il traffico. Questo sarebbe costoso e potrebbe essere semplicemente eccessivo.
Per BGP non è necessario avere router dedicati, puoi utilizzare strumenti open-source come Quagga. Di conseguenza, tutto ciò di cui potresti avere bisogno è un server o più server, uno switch e BGP.
In questo caso, il tuo server o più server possono fungere non solo da server CDN, ma anche da router. Naturalmente, ci sono molti dettagli da considerare (ad esempio, come garantire il bilanciamento), ma è realizzabile e questo approccio è stato applicato con successo per uno dei nostri partner.
Puoi avere diversi data center con protezione completa (firewall, servizi di protezione DDoS forniti dai tuoi provider di internet) e decine o centinaia di "punti di presenza semplificati" solo con switch L2 e server.
E per quanto riguarda la protezione in questo caso?
Consideriamo, ad esempio, il popolare attacco DDoS di amplificazione DNS. La sua pericolosità sta nel fatto che genera un'enorme quantità di traffico che semplicemente "riempie" al 100% tutti i tuoi uplink.
Cosa abbiamo nel caso del nostro design.

Se stai utilizzando AnyCast, il traffico viene distribuito tra i tuoi punti di presenza. Se la tua larghezza di banda totale è in terabit, questo di per sé ti protegge sostanzialmente (anche se ci sono stati recentemente diversi attacchi con traffico dannoso dell'ordine di un terabit) dal "sovraccarico" degli uplink.

Se alcuni uplink sono comunque "intasati", puoi semplicemente rimuovere questo nodo dal servizio (smettere di annunciare il prefisso).

Puoi anche aumentare la quota di traffico proveniente dai tuoi data center "completi" (e, quindi, protetti), riducendo in questo modo una parte sostanziale del traffico dannoso dai punti di presenza non protetti.
E una piccola nota su questo esempio. Se trasferisci un'adeguata quantità di traffico tramite gli IX, questo riduce anche la tua vulnerabilità a tali attacchi.

Configurazione BGP

Qui ci sono due argomenti.

Connettività
Configurazione BGP

Abbiamo già parlato un po' della connettività. parte 1. L'essenza è che il traffico verso i vostri clienti segua il percorso ottimale. Anche se l'ottimalità non riguarda sempre solo la latenza, di solito è proprio la bassa latenza a essere il principale indicatore di ottimalità. Per alcune aziende questo è più importante, per altre meno. Dipende dal servizio che offrite.

Esempio 1
Se siete un exchange e per i vostri clienti sono importanti intervalli di tempo inferiori a un millisecondo, è chiaro che non si può nemmeno parlare di internet.

Esempio 2
Se siete un'azienda di giochi e per voi sono importanti decine di millisecondi, la connettività è ovviamente molto importante.

Esempio 3
Bisogna anche capire che, a causa delle proprietà del protocollo TCP, la velocità di trasmissione dei dati all'interno di una singola sessione TCP dipende anche dal RTT (Round Trip Time). Le reti CDN sono costruite anche per affrontare questo problema, portando i server di distribuzione dei contenuti più vicini ai consumatori di questi contenuti.

L'analisi della connettività è un tema interessante a parte, degno di un articolo o di una serie di articoli, e richiede una buona comprensione di come è 'strutturato' internet.

Risorse utili:

ripe.net
bgp.he.net

Esempio
Fornirò solo un piccolo esempio.
Supponiamo che il tuo data center si trovi a Mosca e che tu abbia un'unica connessione – Rostelecom (AS12389). In questo caso, non hai bisogno del BGP (single homed) e come indirizzi pubblici probabilmente utilizzi l'pool di indirizzi di Rostelecom.
Immagina di offrire un servizio e di avere un numero sufficiente di clienti dall'Ucraina che segnalano alti ritardi. Indagando, hai scoperto che gli indirizzi IP di alcuni di essi appartengono alla rete 37.52.0.0/21.
Eseguendo un traceroute, hai visto che il traffico passa attraverso AS1299 (Telia), mentre eseguendo un ping hai ottenuto un RTT medio di 70 – 80 millisecondi. Puoi vedere questo anche su looking glass di Rostelecom.
Utilizzando lo strumento whois (sul sito ripe.net o un'utilità locale), puoi facilmente determinare che il blocco 37.52.0.0/21 appartiene ad AS6849 (Ukrtelecom).
Successivamente, andando su bgp.he.net vedi che AS6849 non ha relazioni con AS12389 (non sono né clienti né collegamenti reciproci e non hanno nemmeno peering). Ma se guardi il elenco dei peer per AS6849, vedrai, ad esempio, AS29226 (Mastertel) e AS31133 (Megafon).
Trovando il looking glass di questi provider, puoi confrontare il percorso e l'RTT. Ad esempio, per Mastertel l'RTT sarà già di circa 30 millisecondi.
Quindi, se la differenza tra 80 e 30 millisecondi è significativa per il tuo servizio, potrebbe essere il momento di considerare la connettività, ottenere il tuo numero AS in RIPE, il tuo pool di indirizzi e connettere ulteriori uplink e/o creare punti di presenza presso gli IX.

Utilizzando BGP, non solo puoi migliorare la connettività, ma anche riservare la tua connessione a Internet.

Questo documento contiene raccomandazioni per la configurazione di BGP. Anche se queste raccomandazioni sono state sviluppate sulla base delle «best practice» dei fornitori, rimangono sicuramente utili e dovrebbero far parte del processo di hardening di cui abbiamo discusso. parte uno.

protezione DOS/DDOS

Oggi, gli attacchi DOS/DDOS sono diventati una realtà quotidiana per molte aziende. In effetti, in un modo o nell'altro, siete attaccati abbastanza spesso. Il fatto che non lo notiate ancora significa solo che non è stata ancora organizzata un'attacco mirato contro di voi e che gli strumenti di protezione che utilizzate, anche senza esserne consapevoli (diverse protezioni integrate nei sistemi operativi), sono sufficienti per minimizzare il degrado del servizio offerto a voi e ai vostri clienti.

Esistono risorse online che, basandosi sui log delle apparecchiature, creano in tempo reale belle mappe degli attacchi.

Qui si possono trovare riferimenti a esse.

La mia preferita mappa di CheckPoint.

La protezione contro DDOS/DOS è solitamente stratificata. Per capire il perché, è necessario comprendere quali tipi di attacchi DOS/DDOS esistono (vedi ad esempio, qui o qui)

Quindi abbiamo tre tipologie di attacchi:

attacchi volumetrici
attacchi a protocollo
attacchi all'applicazione

Se dagli ultimi due tipi di attacchi puoi proteggerti autonomamente, ad esempio utilizzando un firewall, dagli attacchi mirati al "overflow" dei tuoi uplink non potrai proteggerti da solo (ovviamente, se la tua capacità totale delle linee internet non si misura in terabit, ma meglio, in decine di terabit).

Pertanto, la prima linea di difesa è quella contro gli attacchi "volumetrici", e questa protezione deve garantirla il tuo provider o i tuoi fornitori. Se non ti sei ancora reso conto di questo, considera che per ora sei solo fortunato.

Esempio
Supponiamo che tu abbia diversi uplink, ma solo uno dei fornitori può offrirti questa protezione. Ma se tutto il traffico passa attraverso un solo fornitore, come si colloca la connettività di cui abbiamo parlato brevemente poco fa?
Durante l'attacco, in questo caso, dovrai sacrificare in parte la connettività. Ma

questo è solo per la durata dell'attacco. Puoi, in caso di attacco, riconfigurare manualmente o automaticamente il BGP in modo che il traffico passi solo attraverso il fornitore che ti offre il "ombrello". Al termine dell'attacco, puoi ripristinare il routing allo stato precedente.

Non è necessario tradurre tutto il traffico. Se, ad esempio, notate che attraverso alcuni uplink o peer non ci sono attacchi (o il traffico non è significativo), potete continuare ad annunciare i prefissi con attributi competitivi verso questi vicini BGP.

La protezione contro gli «attacchi di protocollo» e gli «attacchi alle applicazioni» può anche essere affidata ai partner.
Ecco qui Potete leggere una buona ricerca (traduzione). Certo, l'articolo ha due anni, ma vi darà un'idea degli approcci su come potete proteggervi dagli attacchi DDoS.

In linea di principio, potete limitarvi a questo, delegando completamente la vostra protezione in outsourcing. Questa soluzione ha vantaggi, ma presenta anche ovvi svantaggi. Il fatto è che si può trattare (ancora una volta, a seconda di ciò che fa la vostra azienda) della sopravvivenza del business. E affidare queste cose a organizzazioni esterne...

Pertanto, esaminiamo come organizzare una seconda e una terza linea di difesa (come complemento alla protezione del fornitore).

Quindi, la seconda linea di difesa è la filtrazione e i limitatori di traffico (policers) all'ingresso della vostra rete.

Esempio 1
Supponiamo che tu ti sia "protetto con un ombrello" contro le DDOS tramite uno dei fornitori. Supponiamo che questo fornitore utilizzi Arbor per filtrare il traffico e i filtri al confine della propria rete.
La bandwidth che Arbor può "gestire" è limitata, e il fornitore, ovviamente, non può continuamente far passare tutto il traffico dei propri partner che hanno ordinato questo servizio attraverso l'attrezzatura di filtraggio. Pertanto, in condizioni normali, il traffico non viene filtrato.
Immagina che ci sia un attacco SYN flood. Anche se hai ordinato un servizio che, in caso di attacco, devia automaticamente il traffico per il filtraggio, questo non avviene immediatamente. Per un minuto o più, rimani sotto attacco. E questo può portare al guasto della tua attrezzatura o alla degradazione del servizio. In questo caso, la limitazione del traffico sulla roteazione al confine, sebbene porti alla mancata istituzione di alcune sessioni TCP in quel periodo, salverà la tua infrastruttura da problemi più gravi.

Esempio 2
Un numero anomalo di pacchetti SYN potrebbe non essere solo il risultato di un attacco SYN flood. Supponiamo che tu stia offrendo un servizio che consente circa 100.000 connessioni TCP contemporaneamente (in un singolo data center).
Immagina che, a causa di un problema temporaneo con uno dei tuoi principali fornitori, metà delle sessioni siano state 'espulse'. Se la tua applicazione è progettata in modo tale da tentare immediatamente (o dopo un intervallo di tempo uguale per tutte le sessioni) di ristabilire la connessione, potresti ricevere contemporaneamente almeno 50.000 pacchetti SYN.
Se sopra queste sessioni deve funzionare, ad esempio, un handshake ssl/tls, che prevede uno scambio di certificati, dal punto di vista dell'esaurimento delle risorse per il tuo bilanciatore di carico, questo rappresenterà un 'DDoS' molto più forte rispetto a un semplice SYN flood. Sembrerebbe che i bilanciatori dovrebbero gestire eventi del genere, ma... sfortunatamente, ci siamo trovati ad affrontare questa problematica con grande intensità.
E, naturalmente, un policer sul router di confine salverà la tua attrezzatura anche in questo caso.

Il terzo livello di protezione contro DDOS/DOS riguarda le impostazioni del tuo firewall.

Qui puoi gestire attacchi sia di secondo che di terzo tipo. In generale, tutto ciò che arriva al firewall può essere filtrato qui.

Suggerimento
Cerca di dare al firewall il minor lavoro possibile, filtrando il più possibile nelle prime due linee di difesa. Ecco perché.
Ti è mai capitato di generare traffico casualmente, per esempio, per testare quanto sia resistente il sistema operativo dei tuoi server agli attacchi DDOS, e di ‘saturare’ il tuo firewall caricandolo al 100% con traffico di intensità normale? Se no, forse è solo perché non ci hai mai provato?
In generale, un firewall, come ho già detto, è una cosa complessa e funziona bene con vulnerabilità note e soluzioni testate. Tuttavia, se invii qualcosa di insolito, semplicemente spazzatura o pacchetti con intestazioni errate, c'è una certa probabilità (basata sulla mia esperienza) che tu possa confondere anche l'hardware più avanzato. Pertanto, nella fase 2, utilizza normali ACL (a livello L3/L4) per consentire nella tua rete solo il traffico previsto.

Filtraggio del traffico sul firewall

Continuiamo la discussione sul firewall. È importante comprendere che gli attacchi DOS/DDOS rappresentano solo una delle varietà di attacchi informatici.

Oltre alla protezione DOS/DDOS, possiamo anche avere qualcosa di simile al seguente elenco di funzionalità: