Questo articolo è il quarto di un ciclo di articoli intitolato "Come controllare l'infrastruttura di rete". I contenuti di tutti gli articoli del ciclo e i link possono essere trovati qui.

In prima parte 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 è senza dubbio uno dei più complessi del mondo delle reti di trasmissione dei dati. Come nei casi precedenti, senza pretendere di essere esaustivo e dettagliato, discuterò qui alcune questioni abbastanza semplici ma, secondo me, importanti, le cui risposte spero possano contribuire a migliorare il livello di sicurezza della vostra rete.

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

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

Design

Come esempio di design per questo segmento in una rete aziendale, raccomanderei guida di Cisco all'interno del modello SAFE.

Naturalmente, potrebbe sembrare che le soluzioni di altri fornitori siano più attraenti (vedi quadrante Gartner del 2018), ma, senza invitarvi a seguire questo design nei dettagli, ritengo comunque utile comprendere i principi e le idee sottostanti.

Nota
Nel modello SAFE, il segmento "Remote Access" fa parte di "Internet Access". Ma in questo ciclo di articoli lo esamineremo separatamente.

L'insieme standard di attrezzature per questo segmento per una rete aziendale è composto da

router di confine (border routers)
firewall

Nota 1
In questo ciclo di articoli, quando parlo di firewall, intendo NGFW.

Nota 2
Non prendo in considerazione vari tipi di soluzioni L2/L1 o overlay L2 su L3 necessari per garantire la connettività L1/L2 e mi limito solo a questioni di livello L3 e superiore. In parte, le questioni L1/L2 sono state trattate nel capitolo "Pulizia e documentazione«.

Se non avete trovato un firewall in questo segmento, non affrettatevi a fare conclusioni.

Diamo, come in parte precedente, iniziamo dalla domanda se sia necessario utilizzare un firewall in questo segmento nel vostro caso.

Posso dire che, apparentemente, questo è il posto più giustificato per l'uso di firewall e per l'applicazione di algoritmi complessi di filtraggio del traffico. Nella parte 1 abbiamo menzionato 4 fattori che possono ostacolare l'uso dei firewall nel segmento dei data center. Ma qui non sono più così significativi.

Esempio 1. Ritardo
Quando si tratta di internet, non ha senso parlare di ritardi anche di solo 1 millisecondo. Pertanto, i ritardi in questo segmento non possono rappresentare un fattore limitante per l'uso del firewall.

Esempio 2. Prestazioni
In alcuni casi, questo fattore può ancora essere significativo. Pertanto, potrebbe essere necessario deviare parte del traffico (ad esempio, il traffico dei bilanciatori di carico) bypassando il firewall.

Esempio 3. Affidabilità
Questo fattore deve ancora essere considerato, ma tenendo conto dell'affidabilità dell'internet stesso, la sua importanza per questo segmento non è così significativa come per il data center.
Supponiamo che il tuo servizio funzioni su http/https (con sessioni brevi). In questo caso puoi utilizzare due box indipendenti (senza HA) e in caso di problemi con uno di essi, instradare tutto il traffico sul secondo.
Oppure puoi utilizzare i firewall in modalità trasparente e, in caso di guasto, deviare temporaneamente il traffico bypassando i firewall.

Pertanto, è probabile che sia proprio solo il prezzo il fattore che ti costringerà a rinunciare all'utilizzo dei firewall in questo segmento.

Importante!
C'è la tentazione di combinare questo firewall con quello del data center (utilizzando un unico firewall per questi segmenti). Questa soluzione è teoricamente possibile, ma è importante comprendere che, poiché il firewall 'Internet Access' si trova effettivamente in prima linea nella tua difesa e 'prende su di sé', almeno in parte, il traffico malevolo, è necessario considerare l'aumento del rischio che questo firewall possa guastarsi. Cioè, utilizzando gli stessi dispositivi in questi due segmenti, ridurrai sostanzialmente la disponibilità del segmento del tuo data center.

Come al solito, è necessario comprendere che a seconda del servizio fornito dall'azienda, il design di questo segmento può variare significativamente. Puoi, come al solito, scegliere diversi approcci a seconda delle esigenze.

Esempio
Se sei un provider di contenuti, con una rete CDN (vedi, ad esempio, un insieme di articoli), potresti non voler creare decine, se non centinaia, di punti di presenza nell'infrastruttura utilizzando dispositivi separati per l'instradamento e la filtrazione del traffico. Questo sarebbe costoso e potrebbe anche essere semplicemente superfluo.
Per BGP non è affatto necessario avere router dedicati; puoi utilizzare strumenti open-source, per esempio, Quagga. Pertanto, potrebbe bastarti un server o più server, uno switch e BGP.
In questo caso, il tuo server o più server possono svolgere il ruolo non solo di server CDN, ma anche di router. Certo, ci sono ancora molti dettagli qui (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 da attacchi DDoS forniti dai tuoi provider di servizi internet) e decine o centinaia di punti di presenza "semplificati" solo con switch L2 e server.
E riguardo alla protezione in questo caso?
Prendiamo in considerazione, ad esempio, la popolare attacco DDoS di amplificazione DNS. La sua pericolosità risiede nel fatto che viene generato un grande volume di traffico, che semplicemente "intasa" al 100% tutti i tuoi uplink.
Cosa abbiamo nel caso del nostro design.

se utilizzi AnyCast, il traffico viene distribuito tra i tuoi punti di presenza. Se la larghezza di banda totale è in terabits, questo di per sé ti protegge (anche se ultimamente ci sono state alcune attacchi con traffico dannoso dell'ordine di un terabit) da "saturare" gli uplink.

se comunque alcuni uplink "si intasano", puoi semplicemente dismettere quella piattaforma (smettendo di annunciare il prefisso).

Puoi anche aumentare la percentuale di traffico proveniente dai tuoi data center "completi" (e, di conseguenza, protetti), in modo da rimuovere una parte sostanziale del traffico dannoso dai punti di presenza non protetti.
E un'ulteriore osservazione a questo esempio. Se una quantità sufficiente di traffico viene deviato attraverso gli IX, questo riduce anche la tua esposizione a tali attacchi.

Configurazione BGP

Qui ci sono due argomenti.

Connettività
Configurazione BGP

Di connettività ne abbiamo già parlato un po' in parte 1. Il punto è che il traffico verso i tuoi clienti deve seguire il percorso ottimale. Tuttavia, l'ottimalità non riguarda sempre solo il ritardo, ma di solito il ritardo basso è l'indicatore principale dell'ottimalità. Per alcune aziende ciò è più importante, per altre meno. Dipende tutto dal servizio che offri.

Esempio 1
Se sei uno scambio e per i tuoi clienti sono importanti intervalli di tempo inferiori a un millisecondo, allora è chiaro che non si può parlare affatto di internet.

Esempio 2
Se sei un'azienda di gioco e per te sono importanti decine di millisecondi, allora, naturalmente, la connettività è molto importante per te.

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

Lo studio della connettività è un tema interessante a sé stante, meritevole 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
Porterò solo un piccolo esempio.
Supponiamo che il tuo data center si trovi a Mosca e tu abbia un solo uplink: Rostelecom (AS12389). In questo caso (single homed), BGP non ti serve, e come indirizzi pubblici probabilmente utilizzi un pool di indirizzi di Rostelecom.
Supponiamo che tu fornisca un servizio e abbia un numero sufficiente di clienti dall'Ucraina, e che questi si lamentino di alte latenze. Indagando, hai scoperto che gli indirizzi IP di alcuni di loro si trovano nella rete 37.52.0.0/21.
Eseguendo un traceroute, hai visto che il traffico passa tramite AS1299 (Telia), e facendo un ping hai ottenuto un RTT medio di 70-80 millisecondi. Puoi vedere questo anche su looking glass di Rostelecom.
Utilizzando il tool 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, accedendo a bgp.he.net puoi vedere che AS6849 non ha relazioni con AS12389 (non sono né clienti né uplink l'uno dell'altro, e non hanno neppure peering). Ma se guardi la lista dei peering 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à attorno ai 30 millisecondi.
Quindi, se la differenza tra 80 e 30 millisecondi è significativa per il tuo servizio, allora forse è il caso di considerare la connettività, ottenere un numero AS in RIPE, un pool di indirizzi e connettere ulteriori uplink e/o creare punti di presenza sugli IX.

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

Questo documento contiene raccomandazioni per la configurazione di BGP. Sebbene queste raccomandazioni siano state sviluppate sulla base delle "best practice" dei fornitori, esse rimangono senza dubbio utili e dovrebbero far parte del hardening di cui abbiamo discusso in prima parte.

protezione DOS/DDOS

Attualmente, gli attacchi DOS/DDOS sono diventati una realtà quotidiana per molte aziende. In effetti, in un modo o nell'altro, vieni attaccato piuttosto frequentemente. Il fatto che tu non te ne accorga dipende solo dal fatto che non è stata organizzata un'attacco mirato contro di te, e che i mezzi di protezione di cui disponi, anche senza saperlo (diverse protezioni integrate dei sistemi operativi), sono sufficienti a minimizzare il degrado del servizio per te e i tuoi clienti.

Esistono risorse online che, sulla base dei log delle attrezzature, disegnano in tempo reale belle mappe degli attacchi.

Qui Puoi trovare i link a queste.

La mia preferita mappa di CheckPoint.

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

Cioè abbiamo tre tipi di attacchi:

attacchi volumetrici
attacchi di protocollo
attacchi applicativi

Se per i ultimi due tipi di attacchi puoi proteggerti autonomamente utilizzando, ad esempio, dei firewall, per gli attacchi mirati a "saturare" i tuoi uplink non puoi proteggerti da solo (ovviamente, se la tua capacità complessiva delle linee internet non è calcolata in terabit, meglio, decine di terabit).

Pertanto, la prima linea di difesa è la protezione contro gli attacchi "volumetrici" e questa protezione deve fornirla il tuo fornitore o i fornitori. Se non te ne sei ancora reso conto, allora sei semplicemente fortunato.

Esempio
Supponiamo che tu abbia diversi uplink, ma solo uno dei fornitori possa fornirti questa protezione. Ma se tutto il traffico passerà attraverso un solo fornitore, com'è la connettività di cui abbiamo brevemente parlato poco fa?
Durante l'attacco dovrai in parte sacrificare la connettività.

questo è solo temporaneo durante l'attacco. In caso di attacco, puoi riconfigurare BGP manualmente o automaticamente in modo che il traffico passi solo attraverso il fornitore che ti fornisce "l'ombrello". Dopo la fine dell'attacco, puoi ripristinare il routing al suo stato originale.

non è necessario ridirigere tutto il traffico. Se, ad esempio, vedi che tramite alcuni uplink o peering non ci sono attacchi (o il traffico è insignificante), puoi continuare ad annunciare i prefissi con attributi competitivi verso quei vicini BGP.

Puoi anche delegare la protezione contro gli "attacchi di protocollo" e gli "attacchi applicativi" ai partner.
Ecco qui Puoi leggere una buona ricerca (traduzione). Certo, l'articolo è di due anni fa, ma ti darà una visione degli approcci su come puoi difenderti dagli attacchi DDoS.

In linea di principio, puoi anche limitarti a questo, delegando completamente la tua protezione a terzi. Questa soluzione ha dei vantaggi, ma presenta anche un evidente svantaggio. Il fatto è che si può trattare (di nuovo, a seconda di quello che fa la tua azienda) della sopravvivenza del business. E affidare tali questioni a organizzazioni esterne…

Pertanto, vediamo 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 limiti di traffico (policers) all'ingresso della tua rete.

Esempio 1
Supponiamo che tu sia "protetto dall'ombrello" contro i DDoS tramite uno dei fornitori. Supponiamo che questo fornitore utilizzi Arbor per filtrare il traffico e i filtri ai confini della propria rete.
La banda che Arbor può "gestire" è limitata, e il fornitore, ovviamente, non può costantemente far passare il traffico di tutti i suoi partner che hanno ordinato questo servizio attraverso l'hardware filtrante. Pertanto, in condizioni normali, il traffico non viene filtrato.
Supponiamo che ci sia un attacco SYN flood. Anche se hai ordinato un servizio in cui, in caso di attacco, il traffico viene automaticamente indirizzato al filtro, ciò non avviene istantaneamente. Per un minuto o più rimani sotto attacco. E questo può portare al malfunzionamento della tua attrezzatura o alla degradazione del servizio. In questo caso, il limite di traffico sul router di confine, sebbene porti al fatto che alcune sessioni TCP non verranno stabilite durante questo tempo, salverà la tua infrastruttura da problemi più gravi.

Esempio 2
Un numero anormale di pacchetti SYN può non essere solo il risultato di un attacco SYN flood. Supponiamo che fornisci un servizio in cui puoi avere simultaneamente circa 100.000 connessioni TCP (in un data center).
Supponiamo che, a causa di un problema temporaneo con uno dei tuoi principali fornitori, metà delle sessioni siano state 'interrotte'. Se la tua applicazione è strutturata in modo tale che, 'senza pensarci troppo', cerca subito (o dopo un intervallo di tempo uniforme per tutte le sessioni) di ristabilire la connessione, riceverai contemporaneamente almeno 50.000 pacchetti SYN.
Se sopra queste sessioni deve funzionare, ad esempio, un handshake ssl/tls, che implica uno scambio di certificati, dal punto di vista dell'esaurimento delle risorse per il tuo bilanciatore di carico sarà un 'DDOS' molto più forte rispetto a un semplice SYN flood. Potrebbe sembrare che i bilanciatori dovrebbero gestire eventi di questo tipo, ma... sfortunatamente, ci siamo trovati di fronte a questo problema in pieno.
E, naturalmente, un policer sul router di confine salverà la tua attrezzatura in questo caso.

Il terzo livello di protezione contro DDOS/DOS è la configurazione del tuo firewall.

Qui puoi contenere sia attacchi di secondo che di terzo tipo. In generale, tutto ciò che raggiunge il firewall potrà essere filtrato qui.

Consiglio
Cerca di dare al firewall il minor lavoro possibile, filtrando il più possibile sulle prime due linee di difesa. Ecco perché.
Non ti è mai capitato di generare traffico per verificare, ad esempio, quanto sia resistente il sistema operativo dei tuoi server agli attacchi DDOS e di "uccidere" il tuo firewall caricandolo al 100%, utilizzando un traffico di intensità normale? Se no, forse è solo perché non ci hai mai provato?
In generale, il firewall, come ho già detto, è una cosa complessa, e funziona bene con vulnerabilità note e soluzioni testate, ma se invii qualcosa di insolito, semplicemente spazzatura o pacchetti con intestazioni errate, potresti con una certa probabilità, non così piccola (basandomi sulla mia esperienza), mettere in difficoltà anche l'hardware di alta gamma. Pertanto, nella fase 2, utilizza normali ACL (a livello L3/L4) per consentire nella tua rete solo quel traffico che deve entrarvi.