Acest articol este al patrulea din ciclul de articole „Cum să îți controlezi infrastructura de rețea”. Conținutul tuturor articolelor din ciclu și linkurile pot fi găsite aici.

În prima parte în această capitol am examinat unele aspecte ale securității rețelelor din segmentul „Data Center”. Această parte va fi dedicată segmentului „Internet Access”.

Acces la internet

Tema securității este cu siguranță una dintre cele mai complexe teme din lumea rețelelor de date. Ca și în cazurile anterioare, fără a pretinde la o adâncire și completitudine, voi aborda aici câteva întrebări destul de simple, dar, în opinia mea, importante, ale căror răspunsuri sper să ajute la îmbunătățirea nivelului de securitate a rețelei tale.

Atunci când auditezi acest segment, fii atent la următoarele aspecte:

design
configurările BGP
Protecția DOS/DDOS
filtrarea traficului la firewall

Design

Ca exemplu de design pentru acest segment al rețelei de întreprindere, aș recomanda ghid de la Cisco în cadrul modelului SAFE.

Desigur, este posibil ca soluțiile altor furnizori să ți se pară mai atrăgătoare (vezi quadrantul Gartner pentru 2018), dar, fără a te încuraja să urmezi în detaliu acest design, consider totuși util să înțelegi principiile și ideile care stau la baza sa.

Observație
În modelul SAFE, segmentul „Remote Access” face parte din „Internet Access”. Dar în acest ciclu de articole, îl vom examina separat.

Setul standard de echipamente în acest segment pentru rețeaua de întreprindere este

routere de frontieră (border routers)
firewall-uri

Notă 1
În acest ciclu de articole, atunci când vorbesc despre firewall-uri, mă refer la NGFW.

Notă 2
Sari peste studierea diferitelor soluții L2/L1 sau overlay L2 over L3 necesare pentru asigurarea conectivității L1/L2 și mă voi limita doar la întrebările de nivel L3 și mai sus. Parțial, întrebările L1/L2 au fost discutate în capitolul „Curățarea și documentarea«.

Dacă nu ai descoperit un firewall în acest segment, nu te grăbi să tragi concluzii.

Hai, la fel ca în partea anterioară, să începem cu întrebarea dacă utilizarea unui firewall în acest segment este necesară în cazul tău?

Pot spune că, pare că acesta este cel mai justificat loc pentru utilizarea firewall-urilor și pentru aplicarea unor algoritmi complexi de filtrare a traficului. În partea 1 am menționat 4 factori care pot împiedica utilizarea firewall-urilor în segmentul data center. Dar aici aceștia nu mai sunt la fel de semnificativi.

Exemplul 1. Întârziere
În ceea ce privește internetul, nu are sens să discutăm despre întârzieri de ordinul a 1 milisecundă. Prin urmare, întârzierile în acest segment nu pot fi un factor care să limiteze utilizarea firewall-ului.

Exemplul 2. Performanță
În unele cazuri, acest factor poate fi în continuare semnificativ. De aceea, este posibil ca o parte a traficului (de exemplu, traficul echilibratoarelor de sarcină) să trebuiască să ocolosească firewall-ul.

Exemplul 3. Fiabilitate
Acest factor trebuie să fie în continuare luat în considerare, dar, având în vedere fiabilitatea scăzută a internetului, importanța sa pentru acest segment nu este la fel de semnificativă ca pentru un centru de date.
Să presupunem că serviciul dumneavoastră funcționează pe http/https (cu sesiuni scurte). În acest caz, puteți utiliza două cutii independente (fără HA) și, în cazul unei probleme cu una dintre ele, să redirecționați tot traficul către a doua.
Sau puteți utiliza firewall-uri în modul transparent și, în cazul în care acestea ies din funcțiune, să lăsați traficul să ocolească firewall-urile în timpul soluționării problemei.

De aceea, mai degrabă doar prețul poate fi acel factor care vă va determina să renunțați la utilizarea firewall-urilor în acest segment.

Important!
Există tentația de a combina acest firewall cu firewall-ul centrului de date (să folosiți un singur firewall pentru aceste segmente). O soluție, în principiu, posibilă, dar trebuie să înțelegeți că, deoarece firewall-ul de acces la Internet se află, de fapt, în prima linie a apărării dumneavoastră și «preia», cel puțin, o parte din traficul dăunător, trebuie să considerați riscul crescut ca acest firewall să fie dezactivat. Asta înseamnă că, folosind aceleași dispozitive în aceste două segmente, veți reduce semnificativ disponibilitatea segmentului centrului de date.

Ca de obicei, trebuie să înțelegem că, în funcție de serviciul pe care compania îl furnizează, designul acestui segment poate varia considerabil. După cum este obișnuit, puteți alege diferite abordări în funcție de cerințe.

Exemplu
Dacă sunteți un furnizor de conținut, cu o rețea CDN (vezi, de exemplu, seria de articole), atunci poate nu doriți să creați infrastructura în zeci, poate chiar sute de puncte de prezență, folosind dispozitive separate pentru rutare și filtrare a traficului. Acest lucru ar fi costisitor și ar putea fi pur și simplu de prisos.
Pentru BGP nu este deloc necesar să aveți routere dedicate, puteți folosi instrumente open-source, cum ar fi Quagga. Așadar, poate tot ce aveți nevoie sunt un server sau mai multe servere, un switch și BGP.
În acest caz, serverul sau serverele dvs. pot acționa nu doar ca servere CDN, ci și ca routere. Desigur, există multe detalii aici (de exemplu, cum să asigurați echilibrarea), dar este realizabil, iar această abordare a fost aplicată cu succes pentru unul dintre partenerii noștri.
Puteți avea mai multe centre de date cu o protecție completă (firewall-uri, servicii de protecție împotriva DDoS oferite de furnizorii dvs. de internet) și zeci sau sute de puncte de prezență „simplificate” doar cu switch-uri L2 și servere.
Și ce facem în acest caz pentru protecție?
Să luăm în considerare, de exemplu, populara în ultima vreme atac DDoS prin amplificare DNS. Pericolul acestuia constă în faptul că se generează o cantitate mare de trafic, care pur și simplu „umple” 100% din toate uplink-urile dvs.
Ce avem în cazul designului nostru.

dacă folosiți AnyCast, atunci traficul se împarte între punctele dvs. de prezență. Dacă lățimea de bandă totală este de terabiți, aceasta în sine (deși recent au existat câteva atacuri cu trafic dăunător de ordinul terabitului) vă protejează de „umplerea” uplink-urilor.

dacă totuși unele uplink-uri „se umplu”, pur și simplu scoateți acel site din serviciu (opriți anunțarea prefixului).

de asemenea, puteți crește proporția de trafic livrat din centrele dvs. de date „complete” (și, prin urmare, protejate), astfel eliminând o parte semnificativă a traficului dăunător de la punctele de prezență neprotejate.
Și o mică observație referitoare la acest exemplu. Dacă o cantitate suficientă de trafic este livrată prin IX-uri, aceasta reduce și vulnerabilitatea dvs. la astfel de atacuri.

Configurarea BGP

Aici sunt două teme.

Conectivitate
Configurarea BGP

Despre conectivitate am discutat deja puțin în partea 1. Esența este ca traficul către clienții dvs. să urmeze cea mai optimă cale. Cu toate acestea, optimizarea nu se referă întotdeauna doar la întârziere, dar de obicei, întârzierea scăzută este principalul indicator al optimizării. Pentru unele companii este mai important, pentru altele mai puțin. Totul depinde de serviciul pe care îl oferiți.

Exemplu 1
Dacă sunteți o bursă și pentru clienții dumneavoastră intervalele de timp sub o milisecundă sunt importante, atunci, evident, nu poate fi vorba despre internet în general.

Exemplu 2
Dacă sunteți o companie de jocuri și pentru dumneavoastră sunt importante zecile de milisecunde, atunci, desigur, conexiunea este foarte importantă pentru dumneavoastră.

Exemplul 3
De asemenea, trebuie să înțelegem că, din cauza caracteristicilor protocolului TCP, viteza de transfer a datelor într-o sesiune TCP depinde și de RTT (Round Trip Time). Rețelele CDN sunt construite și pentru a rezolva această problemă, mutând serverele de livrare a conținutului mai aproape de consumatorul acestui conținut.

Cercetarea conexiunii este un subiect interesant, care merită un articol separat sau o serie de articole și necesită o bună înțelegere a modului în care este „construit” internetul.

Resurse utile:

ripe.net
bgp.he.net

Exemplu
Voi oferi doar un mic exemplu.
Să presupunem că centrul dumneavoastră de date se află în Moscova și aveți o singură conexiune – Rostelecom (AS12389). În acest caz (single homed) BGP nu este necesar, iar ca adrese publice, cel mai probabil folosiți un pool de adrese de la Rostelecom.
Să presupunem că oferiți un serviciu și aveți un număr suficient de clienți din Ucraina care se plâng de întârzieri mari. În urma unei cercetări, ați constatat că adresele IP ale unora dintre ei se află în rețeaua 37.52.0.0/21.
După ce ați efectuat un traceroute, ați văzut că traficul trece prin AS1299 (Telia), iar executând un ping, ați obținut un RTT mediu de 70 — 80 de milisecunde. Acest lucru poate fi observat și pe looking glass-ul Rostelecom.
Cu ajutorul utilitarului whois (pe site-ul ripe.net sau cu un utilitar local) puteți determina cu ușurință că blocul 37.52.0.0/21 aparține AS6849 (Ukrtelecom).
Apoi, intrând pe bgp.he.net veți observa că AS6849 nu are relații cu AS12389 (nu sunt nici clienți, nici uplink-uri unul pentru celălalt, de asemenea nu au nici schimburi). Dar dacă priviți lista de peering-uri pentru AS6849, veți observa, de exemplu, AS29226 (Mastertel) și AS31133 (Megafon).
Găsind looking glass-ul acestor furnizori, puteți compara traseul și RTT. De exemplu, pentru Mastertel, RTT va fi de aproximativ 30 de milisecunde.
Așadar, dacă diferența dintre 80 și 30 de milisecunde este semnificativă pentru serviciul dumneavoastră, atunci, poate, ar trebui să reflectați asupra conexiunii, să obțineți de la RIPE numărul dumneavoastră AS, pool-ul de adrese și să conectați uplink-uri suplimentare și/sau să creați puncte de prezență pe IX-uri.

Prin utilizarea BGP, nu numai că aveți posibilitatea de a îmbunătăți conectivitatea, dar și de a rezerva conexiunea la internet.

Acest document conține recomandări pentru configurarea BGP. Deși aceste recomandări au fost dezvoltate pe baza „best practices” ale furnizorilor, ele sunt cu siguranță utile și ar trebui, în mod efectiv, să facă parte din procesul de întărire (hardening) de care am discutat în prima parte.

Protecția DOS/DDOS

Atacurile DOS/DDOS au devenit acum o realitate cotidiană pentru multe companii. În realitate, într-o formă sau alta, sunteți atacat destul de frecvent. Faptul că până acum nu ați observat acest lucru înseamnă doar că nu a fost organizat un atac direcționat împotriva dumneavoastră și că măsurile de protecție pe care le folosiți, chiar fără să fiți conștient de ele (diverse protecții integrate ale sistemelor de operare), sunt suficiente pentru a minimiza degradarea serviciului furnizat pentru dumneavoastră și clienții dvs.

Există resurse online care, pe baza jurnalelor de pe echipamente, creează în timp real hărți frumoase ale atacurilor.

Aici puteți găsi linkuri către acestea.

Harta mea preferată de la CheckPoint. Protecția împotriva DDOS/DOS este de obicei stratificată. Pentru a înțelege de ce, trebuie să știți ce tipuri de atacuri DOS/DDOS există (vezi de exemplu,

Deci avem trei tipuri de atacuri: aici sau aici)

atacuri volumetrice

atacuri de protocol
atacuri de aplicație
Dacă pentru ultimele două tipuri de atacuri vă puteți proteja singur folosind, de exemplu, firewalls, în cazul atacurilor care vizează „supraîncărcarea” uplink-urilor dvs., nu vă puteți proteja singur (desigur, dacă capacitatea totală a canalelor dvs. de internet nu se măsoară în terabiți, iar mai bine, în zeci de terabiți).

Prin urmare, prima linie de apărare este protecția împotriva atacurilor „volumetrice”, iar această protecție ar trebui să fie asigurată de furnizorul dvs. sau furnizorii. Dacă nu ați realizat încă acest lucru, atunci aveți pur și simplu noroc.

Presupunem că aveți câteva uplink-uri, dar doar unul dintre furnizori poate să vă ofere această protecție. Dar dacă tot traficul trece printr-un singur furnizor, atunci cum rămâne cu conectivitatea despre care am discutat pe scurt mai devreme?

Exemplu
În timpul atacului, va trebui să sacrificați în parte conectivitatea.
Dar

aceasta este doar pentru timpul atacului. Puteți, în cazul unui atac, să reajustați manual sau automat BGP, astfel încât traficul să circule doar prin furnizorul care vă oferă „umbrela”. După încheierea atacului, puteți reveni la rutarea anterioară.

nu este obligatoriu să traduceți tot traficul. Dacă, de exemplu, observați că prin anumite uplink-uri sau peering nu au loc atacuri (sau traficul nu este semnificativ), puteți continua să anunțați prefixele cu atribute competitive către acești vecini BGP.

Protecția împotriva „atacurilor de protocol” și „atacurilor de aplicație” o puteți delega, de asemenea, partenerilor.
Iată aici puteți citi un studiu bun (traducere). Deși este un articol de acum două ani, vă va oferi o idee despre abordările prin care vă puteți proteja împotriva atacurilor DDoS.

În principiu, puteți limita acest lucru, delegând întreaga protecție pe externalizare. Această soluție are avantaje, dar și un dezavantaj evident. Este vorba despre supraviețuirea afacerii dumneavoastră (din nou, în funcție de ceea ce face compania dumneavoastră). Și a încredința astfel de lucruri organizațiilor externe...

Așadar, să examinăm cum să organizăm a doua și a treia linie de apărare (ca supliment la protecția furnizorului).

Deci, a doua linie de apărare este filtrarea și limitatoarele de trafic (policers) la intrarea în rețeaua dumneavoastră.

Exemplu 1
Să presupunem că v-ați „închis sub umbrelă” împotriva DDoS prin intermediul unuia dintre furnizori. Să presupunem că acel furnizor folosește Arbor pentru filtrarea traficului și filtrele la marginea rețelei sale.
Lățimea de bandă pe care Arbor o poate „procesa” este limitată, iar furnizorul, desigur, nu poate permite constant traficul tuturor partenerilor săi care au comandat acest serviciu, prin echipamentele de filtrare. Prin urmare, în condiții normale, traficul nu este filtrat.
Să presupunem că se desfășoară un atac de tip SYN flood. Chiar dacă ați comandat un serviciu prin care, în caz de atac, traficul este redirecționat automat către filtrare, acest lucru nu se întâmplă instantaneu. În decurs de un minut sau mai mult, rămâneți sub atac. Și acest lucru poate duce la defectarea echipamentului dumneavoastră sau la degradarea serviciului. În această situație, limitarea traficului la routing-ul de frontieră, deși va conduce la faptul că unele sesiuni TCP nu se vor stabili în acest interval, va salva infrastructura dumneavoastră de probleme mai ample.

Exemplu 2
Un număr anormal de mare de pachete SYN poate fi nu doar rezultatul unei atac de tip SYN flood. Să presupunem că oferiți un serviciu în care pot avea simultan aproximativ 100.000 de conexiuni TCP (într-un singur centru de date).
Să presupunem că, din cauza unei probleme temporare cu unul dintre principalii dumneavoastră furnizori, a fost „închis” jumătate din sesiuni. Dacă aplicația dumneavoastră este concepută în așa fel încât să încerce imediat (sau după un interval de timp uniform pentru toate sesiune) să reinstaureze conexiunea, atunci veți primi aproximativ simultan cel puțin 50.000 de pachete SYN.
Dacă, în plus față de aceste sesiuni, de exemplu, trebuie să funcționeze un handshake ssl/tls, care implică schimbul de certificate, din punctul de vedere al epuizării resurselor pentru echilibrorul dumneavoastră de încărcare, aceasta va fi mult mai puternică „DDOS” decât un simplu SYN flood. Ar părea că echilibroarele ar trebui să gestioneze astfel de evenimente, dar... din păcate, ne-am confruntat în mod direct cu această problemă.
Și, desigur, un policer pe routerul de frontieră vă va salva echipamentul și în acest caz.

Nivelul trei de protecție împotriva DDOS/DOS - sunt setările firewall-ului dumneavoastră.

Aici puteți să limitați atât atacurile de tip secundar, cât și pe cele de tip terțiar. În general, tot ceea ce ajunge la firewall poate fi filtrat aici.

Sfaturi
Încercați să oferiți firewall-ului cât mai puțin de lucru, filtrând cât mai mult pe primele două linii de apărare. Și acesta este motivul.
Ați avut vreodată situația în care, generând trafic pentru a verifica, de exemplu, cât de bine rezistă sistemul de operare al serverelor dumneavoastră la atacurile DDOS, ați "ucis" firewall-ul, încărcându-l la 100% cu un trafic de intensitate normală? Dacă nu, poate că pur și simplu nu ați încercat?
În general, firewall-ul, așa cum am spus, este o chestiune complicată, iar acesta funcționează bine cu vulnerabilitățile cunoscute și soluțiile testate, dar dacă trimiteți ceva neobișnuit, doar niște date inutile sau pachete cu antete greșite, aveți o probabilitate destul de mare (din experiența mea) să blocați chiar și echipamentele de top. Prin urmare, la etapa 2 folosiți ACL-uri obișnuite (la nivel L3/L4) pentru a permite în rețeaua dumneavoastră doar traficul care ar trebui să intre.