Come prendere il controllo della tua infrastruttura di rete. Capitolo tre. Sicurezza della rete. Seconda parte

Questo articolo è il quarto della serie "Come assumere il controllo della propria infrastruttura di rete". È possibile trovare il contenuto di tutti gli articoli della serie e i collegamenti qui.

В la prima parte In questo capitolo abbiamo esaminato alcuni aspetti della sicurezza di rete nel segmento Data Center. Questa parte sarà dedicata al segmento “Accesso a Internet”.

Come prendere il controllo della tua infrastruttura di rete. Capitolo tre. Sicurezza della rete. Seconda parte

Accesso ad Internet

Il tema della sicurezza è senza dubbio uno degli argomenti più complessi nel mondo delle reti dati. Come nei casi precedenti, senza pretesa di profondità e completezza, prenderò in considerazione qui domande abbastanza semplici, ma, a mio avviso, importanti, le cui risposte, spero, contribuiranno ad aumentare il livello di sicurezza della vostra rete.

Quando controlli questo segmento, presta attenzione ai seguenti aspetti:

  • disegno
  • Impostazioni BGP
  • Protezione DOS/DDOS
  • filtraggio del traffico sul firewall

disegno

Come esempio della progettazione di questo segmento per una rete aziendale, lo consiglierei guida da Cisco all'interno Modelli SICURI.

Naturalmente, forse la soluzione di altri fornitori ti sembrerà più interessante (vedi. Quadrante Gartner 2018), ma senza incoraggiarvi a seguire questo progetto nel dettaglio, trovo comunque utile comprenderne i principi e le idee alla base.

osservazione

In SAFE, il segmento "Accesso remoto" fa parte del segmento "Accesso Internet". Ma in questa serie di articoli lo considereremo separatamente.

Il set standard di apparecchiature in questo segmento per una rete aziendale è

  • router di confine
  • firewall

Osservazione 1

In questa serie di articoli, quando parlo di firewall, intendo NGFW.

Osservazione 2

Tralascio la considerazione dei vari tipi di soluzioni L2/L1 o sovrapposizione L2 su L3 necessarie per garantire la connettività L1/L2 e mi limito solo ai problemi a livello L3 e superiore. Parzialmente, le questioni L1/L2 sono state discusse nel capitolo “Pulizia e documentazione«.

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

Facciamo lo stesso come in sezione precedenteCominciamo con la domanda: nel tuo caso è necessario utilizzare un firewall in questo segmento?

Posso dire che questo sembra essere il luogo più giustificato per utilizzare i firewall e applicare algoritmi complessi di filtraggio del traffico. IN parti di 1 Abbiamo menzionato 4 fattori che potrebbero interferire con l'uso dei firewall nel segmento dei data center. Ma qui non sono più così significativi.

Esempio 1. ritardo

Per quanto riguarda Internet non ha senso parlare di ritardi anche di circa 1 millisecondo. Pertanto il ritardo in questo segmento non può costituire un fattore limitante l'utilizzo del firewall.

Esempio 2. Производительность

In alcuni casi questo fattore può essere ancora significativo. Pertanto, potrebbe essere necessario consentire ad una parte del traffico (ad esempio, il traffico proveniente dai bilanciatori del carico) di bypassare il firewall.

Esempio 3. Affidabilità

Questo fattore deve ancora essere preso in considerazione, ma, data l'inaffidabilità di Internet stessa, la sua importanza per questo segmento non è così significativa come per il data center.

Quindi, supponiamo che il tuo servizio risieda su http/https (con sessioni brevi). In questo caso puoi utilizzare due box indipendenti (senza HA) e se c'è un problema di routing con uno di essi, trasferire tutto il traffico al secondo.

Oppure puoi utilizzare i firewall in modalità trasparente e, se falliscono, consentire al traffico di aggirare il firewall mentre risolvi il problema.

Pertanto, molto probabilmente solo prezzo potrebbe essere il fattore che ti costringerà ad abbandonare l'uso dei firewall in questo segmento.

Importante!

Esiste la tentazione di combinare questo firewall con il firewall del data center (utilizzare un firewall per questi segmenti). La soluzione è, in linea di principio, possibile, ma è necessario capirlo perché Un firewall per l'accesso a Internet è in realtà in prima linea nella tua difesa e "assume" almeno una parte del traffico dannoso, quindi, ovviamente, devi tenere conto del rischio maggiore che questo firewall venga disabilitato. Cioè, utilizzando gli stessi dispositivi in ​​questi due segmenti, ridurrai significativamente la disponibilità del segmento del tuo data center.

Come sempre, è necessario comprendere che, a seconda del servizio fornito dall'azienda, la struttura di questo segmento può variare notevolmente. Come sempre, puoi scegliere diversi approcci a seconda delle tue esigenze.

esempio

Se sei un fornitore di contenuti, dotato di rete CDN (vedi ad esempio serie di articoli), allora potresti non voler creare un'infrastruttura su dozzine o addirittura centinaia di punti di presenza utilizzando dispositivi separati per instradare e filtrare il traffico. Sarà costoso e potrebbe semplicemente non essere necessario.

Per BGP non devi necessariamente avere router dedicati, puoi utilizzare strumenti open source come quagga. Quindi forse tutto ciò di cui hai bisogno è uno 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. Naturalmente, ci sono ancora molti dettagli (ad esempio come garantire il bilanciamento), ma è fattibile ed è un approccio che abbiamo utilizzato con successo per uno dei nostri partner.

Puoi avere più data center con protezione completa (firewall, servizi di protezione DDOS forniti dai tuoi provider Internet) e decine o centinaia di punti di presenza “semplificati” con solo switch e server L2.

Ma per quanto riguarda la protezione in questo caso?

Diamo un'occhiata, ad esempio, a quello recentemente popolare Attacco DDOS di amplificazione DNS. Il suo pericolo sta nel fatto che viene generata una grande quantità di traffico, che semplicemente “intasa” il 100% di 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 tua larghezza di banda totale è di terabit, allora questo di per sé in realtà (tuttavia, recentemente si sono verificati diversi attacchi con traffico dannoso nell'ordine dei terabit) ti protegge dagli uplink "traboccanti"
  • Se, tuttavia, alcuni uplink si intasano, rimuovi semplicemente questo sito dal servizio (smetti di pubblicizzare il prefisso)
  • puoi anche aumentare la quota di traffico inviata dai tuoi data center “completi” (e, di conseguenza, protetti), rimuovendo così una parte significativa del traffico dannoso dai punti di presenza non protetti

E ancora una piccola nota a questo esempio. Se invii abbastanza traffico tramite IX, anche questo riduce la tua vulnerabilità a tali attacchi

Configurazione di BGP

Ci sono due argomenti qui.

  • Connettività
  • Configurazione di BGP

Abbiamo già parlato un po' della connettività in parti di 1. Il punto è garantire che il traffico verso i tuoi clienti segua il percorso ottimale. Sebbene l’ottimalità non riguardi sempre solo la latenza, la bassa latenza è solitamente il principale indicatore dell’ottimalità. Per alcune aziende questo è più importante, per altre lo è meno. Tutto dipende dal servizio che offri.

esempio 1

Se sei uno scambio e gli intervalli di tempo inferiori ai millisecondi sono importanti per i tuoi clienti, allora, ovviamente, non si può parlare di alcun tipo di Internet.

esempio 2

Se sei un'azienda di giochi e le decine di millisecondi sono importanti per te, allora, ovviamente, la connettività è molto importante per te.

esempio 3

È inoltre necessario comprendere che, a causa delle proprietà del protocollo TCP, la velocità di trasferimento dei dati all'interno di una sessione TCP dipende anche dal RTT (Round Trip Time). Si stanno inoltre costruendo reti CDN per risolvere questo problema spostando i server di distribuzione dei contenuti più vicini al consumatore di questi contenuti.

Lo studio della connettività è un argomento interessante di per sé, meritevole di un articolo o di una serie di articoli a sé stanti, e richiede una buona comprensione di come “funziona” Internet.

Risorse utili:

ripe.net
bgp.he.net

esempio

Faccio solo un piccolo esempio.

Supponiamo che il tuo data center si trovi a Mosca e che tu abbia un unico uplink: Rostelecom (AS12389). In questo caso (single homed) non hai bisogno di BGP e molto probabilmente utilizzerai il pool di indirizzi di Rostelecom come indirizzi pubblici.

Supponiamo che tu fornisca un determinato servizio e che tu abbia un numero sufficiente di clienti dall'Ucraina e che si lamentino di lunghi ritardi. Durante la tua ricerca, hai scoperto che gli indirizzi IP di alcuni di essi si trovano nella griglia 37.52.0.0/21.

Eseguendo un traceroute, hai visto che il traffico stava attraversando AS1299 (Telia) ed eseguendo un ping, hai ottenuto un RTT medio di 70 - 80 millisecondi. Puoi anche vederlo su specchio Rostelecom.

Utilizzando l'utilità whois (su ripe.net o un'utilità locale), puoi facilmente determinare che il blocco 37.52.0.0/21 appartiene a AS6849 (Ukrtelecom).

Successivamente, andando a bgp.he.net vedi che AS6849 non ha alcuna relazione con AS12389 (non sono né client né uplink tra loro, né hanno peering). Ma se guardi elenco dei pari per AS6849 vedrai, ad esempio, AS29226 (Mastertel) e AS31133 (Megafon).

Una volta trovato lo specchio di questi fornitori, puoi confrontare il percorso e l'RTT. Ad esempio, per Mastertel RTT sarà di circa 30 millisecondi.

Quindi, se la differenza tra 80 e 30 millisecondi è significativa per il tuo servizio, allora forse devi pensare alla connettività, ottenere il tuo numero AS, il tuo pool di indirizzi da RIPE e connettere uplink aggiuntivi e/o creare punti di presenza sugli IX.

Quando usi BGP, non solo hai l'opportunità di migliorare la connettività, ma mantieni anche la tua connessione Internet in modo ridondante.

Questo documento contiene consigli per la configurazione di BGP. Nonostante il fatto che queste raccomandazioni siano state sviluppate sulla base delle “migliori pratiche” dei provider, tuttavia (se le impostazioni BGP non sono del tutto basilari) sono senza dubbio utili e in effetti dovrebbero far parte del rafforzamento di cui abbiamo discusso in la prima parte.

Protezione DOS/DDOS

Oggi gli attacchi DOS/DDOS sono diventati una realtà quotidiana per molte aziende. In effetti, vieni attaccato abbastanza spesso in una forma o nell'altra. Il fatto che tu non te ne sia ancora accorto significa solo che non è stato ancora organizzato un attacco mirato contro di te, e che le misure di protezione che utilizzi, anche magari senza saperlo (varie protezioni integrate dei sistemi operativi), sufficienti a garantire che il degrado del servizio fornito sia ridotto al minimo per te e i tuoi clienti.

Esistono risorse Internet che, sulla base dei registri delle apparecchiature, disegnano bellissime mappe di attacco in tempo reale.

Qui puoi trovare i link ad essi.

Il mio preferito mappa dal Check Point.

La protezione contro DDOS/DOS è solitamente stratificata. Per capirne il motivo è necessario capire quali tipologie di attacchi DOS/DDOS esistono (vedi, ad esempio, qui o qui)

Cioè, abbiamo tre tipi di attacchi:

  • attacchi volumetrici
  • attacchi di protocollo
  • attacchi alle applicazioni

Se potete proteggervi dagli ultimi due tipi di attacchi utilizzando, ad esempio, i firewall, allora non potrete proteggervi dagli attacchi volti a “sopraffare” i vostri uplink (ovviamente, se la vostra capacità totale di canali Internet non è calcolata in terabit, o meglio ancora, in decine di terabit).

Pertanto, la prima linea di difesa è la protezione contro gli attacchi “volumetrici” e il tuo fornitore o i tuoi fornitori devono fornirti questa protezione. Se non l'hai ancora capito, per ora sei solo fortunato.

esempio

Supponiamo che tu abbia diversi uplink, ma solo uno dei fornitori può fornirti questa protezione. Ma se tutto il traffico passa attraverso un unico provider, che dire della connettività di cui abbiamo brevemente parlato poco prima?

In questo caso bisognerà sacrificare in parte la connettività durante l’attacco. Ma

  • questo è solo per la durata dell'attacco. In caso di attacco, puoi riconfigurare manualmente o automaticamente BGP in modo che il traffico passi solo attraverso il provider che ti fornisce l’”ombrello”. Una volta terminato l'attacco, è possibile riportare il routing allo stato precedente
  • Non è necessario trasferire tutto il traffico. Se, ad esempio, vedi che non ci sono attacchi attraverso alcuni uplink o peering (o il traffico non è significativo), puoi continuare a pubblicizzare prefissi con attributi competitivi nei confronti di questi vicini BGP.

Puoi anche delegare la protezione dagli “attacchi al protocollo” e dagli “attacchi alle applicazioni” ai tuoi partner.
Qui qui puoi leggere un buon studio (traduzione). È vero, l’articolo è vecchio di due anni, ma ti darà un’idea degli approcci su come proteggerti dagli attacchi DDOS.

In linea di principio potete limitarvi a questo, esternalizzando completamente la vostra protezione. Ci sono dei vantaggi in questa decisione, ma c’è anche un evidente svantaggio. Il fatto è che possiamo parlare (di nuovo, a seconda di cosa fa la tua azienda) della sopravvivenza del business. E affidare queste cose a terzi...

Vediamo quindi come organizzare la seconda e la terza linea di difesa (in aggiunta alla protezione del provider).

Quindi, la seconda linea di difesa è il filtraggio e i limitatori di traffico (poliziotti) all'ingresso della rete.

esempio 1

Supponiamo che vi siate protetti con l'aiuto di uno dei fornitori con un ombrello contro DDOS. Supponiamo che questo provider utilizzi Arbor per filtrare il traffico e filtrare ai margini della propria rete.

La larghezza di banda che Arbor può "elaborare" è limitata e il fornitore, ovviamente, non può far passare costantemente il traffico di tutti i suoi partner che ordinano questo servizio attraverso apparecchiature di filtraggio. Pertanto, in condizioni normali, il traffico non viene filtrato.

Supponiamo che si verifichi un attacco SYN Flood. Anche se hai ordinato un servizio che commuta automaticamente il traffico sul filtraggio in caso di attacco, ciò non avviene immediatamente. Per un minuto o più rimani sotto attacco. E questo può portare al guasto delle tue apparecchiature o al degrado del servizio. In questo caso, limitare il traffico all'edge routing, anche se porterà al fatto che alcune sessioni TCP non verranno stabilite durante questo periodo, salverà la vostra infrastruttura da problemi su larga scala.

esempio 2

Un numero anormalmente elevato di pacchetti SYN potrebbe non essere solo il risultato di un attacco SYN Flood. Supponiamo che tu fornisca un servizio in cui puoi avere contemporaneamente circa 100mila connessioni TCP (a un data center).

Diciamo che a causa di un problema a breve termine con uno dei tuoi principali fornitori, metà delle tue sessioni vengono sospese. Se la tua applicazione è progettata in modo tale che, senza pensarci due volte, tenta immediatamente (o dopo un intervallo di tempo uguale per tutte le sessioni) di ristabilire la connessione, allora riceverai almeno 50mila pacchetti SYN circa contemporaneamente.

Se, ad esempio, devi eseguire l'handshake ssl/tls sopra queste sessioni, che implica lo scambio di certificati, dal punto di vista dell'esaurimento delle risorse per il tuo sistema di bilanciamento del carico, questo sarà un "DDOS" molto più forte di un semplice Alluvione SYN. Sembrerebbe che i bilanciatori dovrebbero gestire tali eventi, ma... sfortunatamente, ci troviamo di fronte a un problema del genere.

E, naturalmente, anche in questo caso un poliziotto sul router periferico salverà la vostra attrezzatura.

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

Qui puoi fermare entrambi gli attacchi del secondo e del terzo tipo. In generale, tutto ciò che raggiunge il firewall può essere filtrato qui.

Consiglio

Cerca di dare al firewall il minor lavoro possibile, filtrando il più possibile le prime due linee di difesa. Ed ecco perché.

Ti è mai capitato che per caso, mentre generavi traffico per verificare, ad esempio, quanto è resistente il sistema operativo dei tuoi server agli attacchi DDOS, hai “ucciso” il tuo firewall, caricandolo al 100 per cento, con traffico ad intensità normale ? Se no, forse è semplicemente perché non hai provato?

In generale, un firewall, come ho detto, è una cosa complessa e funziona bene con vulnerabilità note e soluzioni testate, ma se invii qualcosa di insolito, solo spazzatura o pacchetti con intestazioni errate, allora sei con alcuni, non con una probabilità così piccola (in base alla mia esperienza), puoi stupire anche le apparecchiature di fascia alta. Pertanto, nella fase 2, utilizzando gli ACL regolari (a livello L3/L4), consenti solo il traffico nella rete che dovrebbe entrare lì.

Filtraggio del traffico sul firewall

Continuiamo la conversazione sul firewall. È necessario comprendere che gli attacchi DOS/DDOS sono solo un tipo di attacco informatico.

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

  • firewall dell'applicazione
  • prevenzione delle minacce (antivirus, anti-spyware e vulnerabilità)
  • Filtro URL
  • filtraggio dei dati (filtraggio dei contenuti)
  • blocco dei file (blocco dei tipi di file)

Sta a te decidere cosa ti serve da questo elenco.

essere continuato

Fonte: habr.com

Aggiungi un commento