Questu articulu hè u quartu in a serie "Cumu piglià u cuntrollu di a vostra infrastruttura di rete". U cuntenutu di tutti l'articuli in a serie è i ligami ponu esse truvati .
В In questu capitulu, avemu vistu alcuni aspetti di a sicurità di a rete in u segmentu di u Data Center. Sta parte serà dedicata à u segmentu "Access à Internet".
Accessu Internet
U tema di a sicurità hè senza dubbitu unu di i temi più cumplessi in u mondu di e rete di dati. Cum'è in i casi precedenti, senza riclamà a prufundità è a cumplessità, vi cunsiderà quì abbastanza simplice, ma, in my opinion, dumande impurtanti, e risposte à quale, spergu, aiutanu à elevà u livellu di sicurità di a vostra reta.
Quandu verificate stu segmentu, fate attenzione à i seguenti aspetti:
- u so designu
- paràmetri BGP
- Prutezzione DOS / DDOS
- filtrazione di u trafficu nantu à u firewall
cuncezzione
Cum'è un esempiu di u disignu di stu segmentu per una reta di l'impresa, ricumanderaghju da Cisco in l'internu .
Di sicuru, forse a suluzione di altri venditori vi parerà più attrattiva (vede. ), ma senza incuragisce à seguità stu disignu in detail, aghju sempri utile à capisce i principii è l'idee daretu.
Nota
In SAFE, u segmentu "Access Remote" face parte di u segmentu "Access à Internet". Ma in questa serie di articuli avemu da cunsiderà separatamente.
U settore standard di l'equipaggiu in questu segmentu per una reta di l'impresa hè
- routers di cunfini
- firewalls
Nota 1
In questa serie d'articuli, quandu parlu di firewalls, vogliu dì .
Nota 2
Omettu a considerazione di varii tipi di L2 / L1 o overlay L2 over L3 soluzioni necessarii per assicurà a connettività L1 / L2 è mi limità solu à prublemi à u livellu L3 è sopra. Parzialmente, i prublemi L1 / L2 sò stati discututi in u capitulu "".
Se ùn avete micca truvatu un firewall in questu segmentu, ùn avete micca affruntà à cunclusioni.
Facemu u listessu cum'è in Cuminciamu cù a quistione: hè necessariu di utilizà un firewall in questu segmentu in u vostru casu?
Puderaghju dì chì questu pare esse u locu più ghjustificatu per utilizà firewalls è applicà algoritmi cumplessi di filtrazione di trafficu. IN Avemu citatu 4 fattori chì ponu interferiscenu cù l'usu di firewalls in u segmentu di u centru di dati. Ma quì ùn sò più cusì significativu.
1 esempio. Ritardu
In quantu à Internet, ùn ci hè nunda di parlà di ritardi ancu di circa 1 millisecondu. Dunque, u ritardu in questu segmentu ùn pò micca esse un fattore chì limita l'usu di u firewall.
2 esempio. Produttività
In certi casi, stu fattore pò ancu esse significativu. Dunque, pudete avè da permette à qualchì trafficu (per esempiu, u trafficu da i balancers di carica) per passà u firewall.
3 esempio. Affidabilità
Stu fattore deve ancu esse cunsideratu, ma ancu, datu l'inaffidabilità di l'Internet stessu, a so impurtanza per questu segmentu ùn hè micca significativu cum'è per u centru di dati.
Dunque, supponemu chì u vostru serviziu campa nantu à http/https (cù sessioni brevi). In questu casu, pudete aduprà dui scatuli indipendenti (senza HA) è se ci hè un prublema di routing cù unu di elli, trasfiriu tuttu u trafficu à u sicondu.
O pudete aduprà firewalls in modu trasparente è, se fallenu, permettenu u trafficu per svià u firewall mentre risolve u prublema.
Dunque, assai prubabilmente solu u prezzu pò esse u fattore chì vi furzà à abbandunà l'usu di firewalls in questu segmentu.
Impurtante!
Ci hè una tentazione di cumminà stu firewall cù u firewall di u centru di dati (utilizate un firewall per questi segmenti). A suluzione hè, in principiu, pussibule, ma avete bisognu di capisce chì perchè Un firewall d'accessu à Internet hè veramente in prima linea di a vostra difesa è "prende" almenu una parte di u trafficu maliziusu, allora, sicuru, avete bisognu di piglià in contu u risicu aumentatu chì stu firewall serà disattivatu. Vale à dì, usendu i stessi dispositi in questi dui segmenti, riducerete significativamente a dispunibilità di u vostru segmentu di u centru di dati.
Comu sempre, avete bisognu di capiscenu chì sicondu u serviziu chì a cumpagnia furnisce, u disignu di stu segmentu pò varià assai. Cum'è sempre, pudete sceglie diversi approcci sicondu i vostri bisogni.
Esempiu:
Sè vo site un fornitore di cuntenutu, cù una rete CDN (vede, per esempiu, ), allura pudete micca vulete creà infrastruttura in decine o ancu centinaie di punti di prisenza utilizendu dispositi separati per u routing è u filtru di u trafficu. Serà caru, è pò esse simplicemente inutile.
Per BGP ùn hè micca necessariu avè un router dedicatu, pudete aduprà strumenti open-source cum'è . Allora forsi tuttu ciò chì avete bisognu hè un servitore o parechji servitori, un switch è BGP.
In questu casu, u vostru servitore o parechji servitori ponu ghjucà u rolu di micca solu un servitore CDN, ma ancu un router. Di sicuru, ci sò ancu assai ditaglii (cum'è cumu per assicurà l'equilibriu), ma hè fattibile, è hè un approcciu chì avemu usatu successu per unu di i nostri partenarii.
Pudete avè parechji centri di dati cù una prutezzione completa (firewalls, servizii di prutezzione DDOS furniti da i vostri fornituri d'Internet) è decine o centinaie di punti di prisenza "simplificati" cù solu switch L2 è servitori.
Ma chì hè a prutezzione in stu casu?
Fighjemu, per esempiu, u pocu populari . U so periculu si trova in u fattu chì una grande quantità di trafficu hè generatu, chì solu "clogs" 100% di tutti i vostri uplinks.
Chì avemu in u casu di u nostru disignu.
- sè vo aduprate AnyCast, allura u trafficu hè distribuitu trà i vostri punti di prisenza. Se a vostra larghezza di banda tutale hè terabits, allora questu in sè stessu in realtà (in ogni modu, recentemente ci sò stati parechji attacchi cù trafficu maliziusu nantu à l'ordine di terabits) vi pruteghja da i uplinks "overflowing"
- Se, però, alcuni uplinks sò intasati, allora basta à caccià stu situ da u serviziu (smetta di publicità u prefissu)
- Pudete ancu aumentà a parte di u trafficu mandatu da i vostri centri di dati "pieni" (è, per quessa, prutetti), eliminendu cusì una parte significativa di u trafficu maliziusu da i punti di presenza senza prutezzione.
È una altra piccula nota à questu esempiu. Se mandate abbastanza trafficu attraversu IX, allora questu riduce ancu a vostra vulnerabilità à tali attacchi
Configurazione di BGP
Ci sò dui temi quì.
- Connettività
- Configurazione di BGP
Avemu digià parlatu un pocu di cunnessione in . U puntu hè di assicurà chì u trafficu à i vostri clienti segue u percorsu ottimali. Ancu s'è l'ottimalità ùn hè micca sempre solu per a latenza, a latenza bassa hè di solitu l'indicatore principale di l'ottima. Per certi cumpagnie questu hè più impurtante, per altri hè menu. Tuttu dipende di u serviziu chì furnisce.
esempiu 1
Sè vo site un scambiu, è intervalli di tempu di menu di millisecondi sò impurtanti per i vostri clienti, allora, sicuru, ùn si pò micca parlà di ogni tipu di Internet.
esempiu 2
Sè vo site una cumpagnia di ghjocu è decine di millisecondi sò impurtanti per voi, allora, sicuru, a cunnessione hè assai impurtante per voi.
esempiu 3
Avete ancu bisognu di capiscenu chì, per via di e proprietà di u protocolu TCP, a tarifa di trasferimentu di dati in una sessione TCP dipende ancu da RTT (Round Trip Time). E rete CDN sò ancu esse custruite per risolve stu prublema movendu i servitori di distribuzione di cuntenutu più vicinu à u cunsumadore di stu cuntenutu.
U studiu di a cunnessione hè un tema interessante in u so propiu dirittu, degne di u so propiu articulu o seria d'articuli, è esige una bona cunniscenza di cumu "funziona" l'Internet.
Risorse utili:
Esempiu:
Daraghju solu un picculu esempiu.
Assumimu chì u vostru centru di dati hè situatu in Mosca, è avete un unicu uplink - Rostelecom (AS12389). In questu casu (single homed) ùn avete micca bisognu di BGP, è probabilmente utilizate l'indirizzu pool da Rostelecom cum'è indirizzi publichi.
Assumimu chì furnisce un certu serviziu, è avete un numeru suffirenziu di clienti da l'Ucraina, è si lamentanu di longu ritardi. Durante a vostra ricerca, avete scupertu chì l'indirizzi IP di alcuni di elli sò in a griglia 37.52.0.0/21.
Eseguendu un traceroute, avete vistu chì u trafficu passava per AS1299 (Telia), è eseguendu un ping, avete un RTT mediu di 70 - 80 millisecondi. Pudete ancu vede questu à .
Utilizendu l'utilità whois (in ripe.net o una utilità lucale), pudete facilmente stabilisce chì u bloccu 37.52.0.0/21 appartene à AS6849 (Ukrtelecom).
Dopu, andendu à vi vede chì AS6849 ùn hà micca rilazioni cù AS12389 (ùn sò nè clienti nè uplinks à l'altri, nè anu peering). Ma s'è vo guardate per AS6849, vi vede, per esempiu, AS29226 (Mastertel) è AS31133 (Megafon).
Una volta truvate u vetru di sti fornituri, pudete paragunà a strada è RTT. Per esempiu, per Mastertel RTT serà di circa 30 millisecondi.
Allora, se a diffarenza trà 80 è 30 millisecondi hè significativa per u vostru serviziu, allora forsi avete bisognu di pensà à a cunnessione, uttene u vostru numeru AS, u vostru indirizzu pool da RIPE è cunnette uplinks supplementari è / o creanu punti di presenza in IX.
Quandu utilizate BGP, ùn avete micca solu l'uppurtunità di migliurà a cunnessione, ma ancu mantene a vostra cunnessione Internet in modu redundante.
cuntene cunsiglii per cunfigurà BGP. Malgradu u fattu chì sti cunsiglii sò stati sviluppati in basa di a "best practice" di i fornituri, però (se i vostri paràmetri BGP ùn sò micca abbastanza basi) sò senza dubbitu utili è in fattu duveranu esse parti di l'indurimentu chì avemu discututu in .
Prutezzione DOS / DDOS
Avà l'attacchi DOS / DDOS sò diventati una realità di ogni ghjornu per parechje cumpagnie. In fatti, vi sò attaccati abbastanza spessu in una forma o l'altru. U fattu chì ùn avete micca ancu nutatu questu significa solu chì un attaccu miratu ùn hè micca ancu urganizatu contru à voi, è chì e misure di prutezzione chì utilizate, ancu forse senza sapè (diverse prutezioni integrate di sistemi operativi), basta à assicuratevi chì a degradazione di u serviziu furnitu hè minimizatu per voi è i vostri clienti.
Ci sò risorse Internet chì, basatu nantu à i logs di l'equipaggiu, disegnanu belle carte d'attaccu in tempu reale.
pudete truvà ligami per elli.
A mo bella da CheckPoint.
A prutezzione contra DDOS / DOS hè di solitu stratificata. Per capisce perchè, avete bisognu di capisce chì tipi di attacchi DOS / DDOS esistenu (vede, per esempiu, o )
Vale à dì, avemu trè tippi di attacchi:
- attacchi volumetrici
- attacchi di protokollu
- attacchi di applicazioni
Se pudete prutegevi da l'ultimi dui tipi di attacchi utilizendu, per esempiu, firewalls, allora ùn pudete micca pruteggiri di l'attacchi destinati à "spruverà" i vostri uplinks (di sicuru, se a vostra capacità tutale di i canali Internet ùn hè micca calculata in terabits, o megliu ancu, in decine di terabit).
Per quessa, a prima linea di difesa hè a prutezzione contra l'attacchi "volumetrici", è u vostru fornitore o fornituri deve furnisce questa prutezzione per voi. Se ùn avete micca capitu questu, allora site solu furtunatu per avà.
Esempiu:
Diciamu chì avete parechji uplinks, ma solu unu di i fornituri vi ponu furnisce sta prutezzione. Ma se tuttu u trafficu passa per un fornitore, allora chì ne di a cunnessione chì avemu discututu brevemente un pocu prima?
In questu casu, avete da sacrificà in parte a cunnessione durante l'attaccu. Ma
- questu hè solu per a durata di l'attaccu. In casu di un attaccu, pudete cunfigurà manualmente o automaticamente BGP per chì u trafficu passa solu per u fornitore chì vi furnisce u "umbrella". Dopu chì l'attaccu hè finitu, pudete rinvià u routing à u so statu precedente
- Ùn hè micca necessariu di trasfiriri tuttu u trafficu. Se, per esempiu, vi vede chì ùn ci sò micca attacchi attraversu qualchi uplinks o peerings (o u trafficu ùn hè micca significativu), pudete cuntinuà à publicità prefissi cù attributi competitivi versu questi vicini BGP.
Pudete ancu delegate a prutezzione di "attacchi di protocolli" è "attacchi di applicazioni" à i vostri partenarii.
quì pudete leghje un bonu studiu (). True, l'articulu hè di dui anni, ma vi darà una idea di l'avvicinamenti nantu à cumu pudete prutegge da l'attacchi DDOS.
In principiu, pudete limità à questu, outsourcing cumplettamente a vostra prutezzione. Ci sò vantaghji à sta decisione, ma ci hè ancu un svantaghju evidenti. U fattu hè chì pudemu parlà (di novu, secondu ciò chì a vostra cumpagnia faci) di a sopravvivenza di l'affari. È affidate tali cose à terze parti...
Dunque, fighjemu cumu urganizà a seconda è a terza linea di difesa (cum'è un aghjuntu à a prutezzione di u fornitore).
Allora, a seconda linea di difesa hè u filtru è i limitatori di trafficu (pulizie) à l'entrata di a vostra reta.
esempiu 1
Assumimu chì avete cupertu cun un paraplu contr'à DDOS cù l'aiutu di unu di i fornituri. Assumimu chì stu fornitore usa Arbor per filtrà u trafficu è i filtri à a riva di a so reta.
A larghezza di banda chì Arbor pò "prucessa" hè limitata, è u fornitore, sicuru, ùn pò micca passà constantemente u trafficu di tutti i so cumpagni chì urdinanu stu serviziu per l'equipaggiu di filtrazione. Dunque, in cundizioni normali, u trafficu ùn hè micca filtratu.
Assumimu chì ci hè un attaccu di inundazioni SYN. Ancu s'è avete urdinatu un serviziu chì cambia automaticamente u trafficu à u filtru in casu d'attaccu, questu ùn succede micca istantaneamente. Per un minutu o più stà sottu attaccu. È questu pò purtà à fallimentu di u vostru equipamentu o degradazione di u serviziu. In questu casu, limità u trafficu à u routing di u bordu, ancu s'ellu porta à u fattu chì alcune sessioni TCP ùn saranu micca stabilite durante stu tempu, salverà a vostra infrastruttura da prublemi più grande.
esempiu 2
Un numeru anormalmente grande di pacchetti SYN pò esse micca solu u risultatu di un attaccu di inundazioni SYN. Assumimu chì furnisce un serviziu in u quale pudete avè simultaneamente circa 100 mila cunnessione TCP (à un centru di dati).
Dicemu chì per via di un prublema di cortu termine cù unu di i vostri fornituri principali, a mità di e vostre sessioni sò cacciate. Se a vostra applicazione hè cuncepita in tale manera chì, senza pensà duie volte, immediatamente (o dopu qualchì intervallu di tempu chì hè u listessu per tutte e sessioni) prova di ristabilisce a cunnessione, allora riceverete almenu 50 mila pacchetti SYN circa. simultaneamente.
Se, per esempiu, duvete eseguisce ssl/tls handshake in cima di queste sessioni, chì implica u scambiu di certificati, allora da u puntu di vista di sguassate risorse per u vostru balancer di carica, questu serà un "DDOS" assai più forte cà un simplice. SYN inundazione. Sembra chì i equilibratori duveranu trattà tali avvenimenti, ma... sfurtunatamenti, simu di fronte à un tali prublema.
E, sicuru, un pulizzeru nantu à u router di u bordu salverà u vostru equipamentu ancu in questu casu.
U terzu livellu di prutezzione contra DDOS / DOS hè a vostra paràmetra di firewall.
Quì pudete piantà tramindui attacchi di u sicondu è u terzu tipu. In generale, tuttu ciò chì ghjunghje à u firewall pò esse filtratu quì.
Tip
Pruvate di dà u firewall u più pocu travagliu pussibule, filtrà quant'è pussibule nantu à e prime duie linee di difesa. È hè per quessa.
Hè mai accadutu à voi chì per casu, mentre generava trafficu per verificà, per esempiu, quantu hè resistente u sistema operatore di i vostri servitori à l'attacchi DDOS, avete "ammazzatu" u vostru firewall, carrichendu à 100 per centu, cù u trafficu à intensità normale. ? Se no, forse hè solu perchè ùn avete micca pruvatu?
In generale, un firewall, cum'è aghju dettu, hè una cosa cumplessa, è funziona bè cù vulnerabilità cunnisciute è suluzioni pruvati, ma s'è vo mandate qualcosa inusual, solu qualchi basura o pacchetti cù intestazioni sbagliate, allora site cun alcuni, micca Cù una probabilità cusì chjuca (basatu nantu à a mo sperienza), pudete stupefy ancu l'equipaggiu di punta. Per quessa, in u stadiu 2, utilizendu ACLs regularmente (à u livellu L3 / L4), permette solu u trafficu in a vostra reta chì deve entre quì.
Filtrà u trafficu nantu à u firewall
Cuntinuemu a conversazione nantu à u firewall. Avete bisognu di capisce chì l'attacchi DOS / DDOS sò solu un tipu d'attaccu ciberneticu.
In più di a prutezzione DOS / DDOS, pudemu ancu avè qualcosa cum'è a seguente lista di funzioni:
- firewall di l'applicazione
- prevenzione di minacce (antivirus, anti-spyware è vulnerabilità)
- Filtru URL
- filtru di dati (filtru di cuntenutu)
- bluccatu di schedari (bluccamentu di i tipi di schedari)
Hè à voi di decide ciò chì avete bisognu di sta lista.
Per esse continuatu
Source: www.habr.com
