Acest articol este al patrulea dintr-o serie de articole intitulate „Cum să preiei controlul asupra infrastructurii rețelei”. Conținutul tuturor articolelor din serie și linkurile pot fi găsite aici.

În prima parte în acest capitol am examinat unele aspecte ale securității rețelei 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 adâncime și exhaustivitate, voi aborda aici întrebări destul de simple, dar, în opinia mea, importante, ale căror răspunsuri, sper, vor ajuta la creșterea nivelului de protecție al rețelei dumneavoastră.

Atunci când auditați acest segment, fiți atenți la următoarele aspecte:

design
configurările BGP
Protecția DOS/DDOS
filtrarea traficului pe 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ă vi se pară mai atractive (vezi quadrantul Gartner din 2018), dar, fără a vă îndemna să urmați acest design în detaliu, consider în continuare util să înțelegeți principiile și ideile care stau la baza acestuia.

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

Setul standard de echipamente din acest segment pentru rețeaua de întreprindere (enterprise network) cuprinde

routere de frontieră (border routers)
firewall-uri

Observație 1
În această serie de articole, atunci când vorbesc despre firewall-uri, mă refer la NGFW.

Observație 2
Nu voi aborda diverse tipuri de soluții L2/L1 sau overlay L2 over L3 necesare pentru asigurarea conectivității L1/L2 și mă voi limita doar la probleme de nivel L3 și mai sus. Parțial, problemele L1/L2 au fost discutate în capitolul „Curățarea și documentarea«.

Dacă nu ați descoperit un firewall în acest segment, nu vă grăbiți să trageți concluzii.

Să începem, ca în partea anterioară, cu întrebarea, este necesară utilizarea unui firewall în acest segment în cazul dumneavoastră?

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

Exemplul 1. Întârziere
Când vine vorba de internet, nu are sens să discutăm despre întârzieri de chiar 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 totuși semnificativ. Prin urmare, este posibil ca o parte din trafic (de exemplu, traficul echilibrarelor de sarcină) să trebuiască să ocoliți firewall-ul.

Exemplul 3. Fiabilitate
Acest factor trebuie în continuare luat în considerare, dar având în vedere nestabilitatea internetului, importanța sa pentru acest segment nu este la fel de semnificativă ca în cazul centrului de date.
Să presupunem că serviciul dvs. funcționează pe http/https (cu sesiuni scurte). În acest caz, puteți folosi două boxe independente (fără HA) și, în caz de problemă cu una dintre ele din cauza rutării, să redirecționați tot traficul către cealaltă.
Sau puteți utiliza firewall-uri în mod transparent și, în cazul defectării lor, să redirecționați temporar traficul pe ocolirea firewall-urilor.

Așadar, este mai degrabă acesta prețul poate fi acel factor care vă va face 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 „Acces la Internet” se află în prima linie a apărării dumneavoastră și „prinde”, cel puțin, o parte din traficul dăunător, trebuie să țineți cont de riscul crescut ca acest firewall să fie dezactivat. Adică, folosind aceleași dispozitive în ambele segmente, veți reduce semnificativ disponibilitatea segmentului centrului de date.

Ca de obicei, trebuie să înțelegeți că, în funcție de serviciul pe care compania îl oferă, designul acestui segment poate varia foarte mult. Puteți alege, ca de obicei, 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, o serie de articole), atunci s-ar putea să nu doriți să creați o infrastructură în zeci sau chiar sute de puncte de prezență cu utilizarea de dispozitive separate pentru rutare și filtrare a traficului. Acest lucru ar fi costisitor și poate fi pur și simplu excesiv.
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 câteva servere, un switch și BGP.
În acest caz, serverul sau serverele dumneavoastră pot juca rolul nu doar de server CDN, ci și de router. Cu siguranță există multe detalii (de exemplu, cum să asigurați balance-ul), 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 protecție completă (firewall-uri, servicii de protecție împotriva DDoS furnizate de furnizorii de internet) și zeci sau sute de puncte simplificate de prezență doar cu switch-uri L2 și servere.
Și ce se întâmplă cu protecția în acest caz?
Să luăm, de exemplu, atacul de tip DNS Amplification DDoS. Pericolul acestuia constă în faptul că se generează o cantitate mare de trafic, care pur și simplu "blochează" 100% din toate uplink-urile dumneavoastră.
Ce avem în cazul designului nostru.

dacă folosiți AnyCast, atunci traficul este distribuit între punctele de prezență. Dacă lățimea de bandă totală este de terabiți, atunci acest lucru în sine (cu toate că au existat recent câteva atacuri cu trafic malițios de ordinea terabitului) vă protejează de "supraîncărcarea" uplink-urilor.

dacă totuși unele uplink-uri s-au "blocat", pur și simplu scoateți acest loc din funcțiune (opriți anunțarea prefixului).

de asemenea, puteți crește proporția de trafic livrat din centrele dumneavoastră de date "complete" (și, prin urmare, protejate), astfel îndepărtând o parte semnificativă din traficul malițios de la punctele de prezență neprotejate.
Și un mic comentariu pentru acest exemplu. Dacă o cantitate suficientă de trafic o livrați prin IX-uri, atunci acest lucru reduce, de asemenea, predispoziția dumneavoastră la astfel de atacuri.

Configurarea BGP

Aici sunt două subiecte.

Conectivitate
Configurarea BGP

Despre conectivitate am mai discutat puțin în partea 1. Esența este ca traficul către clienții dumneavoastră să circule pe calea optimă. Deși optimizarea nu se referă întotdeauna doar la latență, de obicei, latența scăzută este principala măsură a optimizării. Pentru unele companii, acest aspect 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 dvs. sunt importante intervalele de timp mai mici de o milisecundă, atunci este clar că nu poate fi vorba despre internet în general.

Exemplu 2
Dacă sunteți o companie de jocuri și pentru dvs. sunt importante zeci de milisecunde, atunci, desigur, conectivitatea este foarte importantă pentru dvs.

Exemplul 3
De asemenea, trebuie să înțelegem că, din cauza proprietăților protocolului TCP, viteza de transfer a datelor într-o singură sesiune TCP depinde și de RTT (Round Trip Time). Rețelele CDN sunt construite, printre altele, pentru a rezolva această problemă, apropiind serverele de livrare a conținutului de consumatorul acestuia.

Cercetarea conectivității este un subiect interesant, demn de o articolee separată sau de 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 aduce doar un mic exemplu.
Să presupunem că data center-ul dvs. este situat în Moscova și aveți o singură legătură – Rostelecom (AS12389). În acest caz (single homed), BGP nu vă este necesar, iar ca adrese publice, cel mai probabil, folosiți un pool de adrese de la Rostelecom.
Să presupunem că oferiți un anumit serviciu și aveți un număr suficient de clienți din Ucraina, iar aceștia se plâng de întârzieri mari. După o cercetare, ați descoperit că adresele IP ale unor clienți se află în rețeaua 37.52.0.0/21.
Executând un traceroute, ați observat că traficul trece prin AS1299 (Telia), iar executând un ping, ați obținut un RTT mediu de 70 – 80 de milisecunde. Puteți vedea acest lucru și pe looking glass-ul Rostelecom-ului.
Folosind utilitarul whois (pe site-ul ripe.net sau pe un utilitar local), puteți determina cu ușurință că blocul 37.52.0.0/21 aparține AS6849 (Ukrtelecom).
Mai departe, accesând bgp.he.net veți vedea că AS6849 nu are relații cu AS12389 (aceștia nu sunt nici clienți, nici legături între ei, de asemenea, nu au nici pirat). Dar dacă vă uitați la lista de perechi pentru AS6849, veți vedea, de exemplu, AS29226 (Mastertel) și AS31133 (Megafon).
Găsind looking glass-ul acestor furnizori, puteți compara calea și RTT. De exemplu, pentru Mastertel RTT va fi deja de aproximativ 30 de milisecunde.
Așadar, dacă diferența dintre 80 și 30 de milisecunde este semnificativă pentru serviciul dvs., atunci, poate, ar trebui să vă gândiți la conectivitate, să obțineți un număr AS de la RIPE, un pool de adrese și să conectați legături suplimentare și/sau să creați puncte de prezență pe IX-uri.

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

Acest document conține recomandări pentru configurarea BGP. Deși aceste recomandări au fost elaborate pe baza «celor mai bune practici» ale furnizorilor, ele sunt cu siguranță utile și ar trebui să facă parte din hardening-ul pe care l-am discutat în prima parte.

Protecția DOS/DDOS

În prezent, atacurile DOS/DDOS au devenit o realitate cotidiană pentru multe companii. De fapt, într-o formă sau alta, sunteți atacați destul de des. Faptul că nu observați acest lucru arată doar că nu a fost organizat încă un atac direcționat împotriva dvs. și că măsurile de protecție pe care le folosiți, chiar și fără să vă dați seama de ele (diferitele protecții încorporate ale sistemelor de operare), sunt suficiente pentru a minimiza degradarea serviciului oferit pentru dvs. și clienții dvs.

Există resurse online care, pe baza jurnalelor de la echipamente, desenează î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ă înțelegeți ce tipuri de atacuri DOS/DDOS există (vedeți, de exemplu,

Adică avem trei tipuri de atacuri: aici sau aici)

atacuri volumetrice

atacuri de protocol
atacuri de aplicație
Dacă vă puteți proteja singuri împotriva ultimelor două tipuri de atacuri, folosind, de exemplu, firewall-uri, de atacurile care vizează «supraîncărcarea» uplink-urilor dvs. nu vă puteți proteja singuri (bineînțeles, dacă capacitatea totală a canalelor dvs. de internet nu se măsoară în terabiți, și mai bine, în zeci de terabiți).

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

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

Exemplu
În timpul atacului, va trebui în acest caz să sacrificați parțial conectivitatea.
Dar

acest lucru este doar temporar în cazul unui atac. Puteți, în cazul unui atac, să reconfigurați manual sau automat BGP, astfel încât traficul să fie dirijat doar prin furnizorul care vă oferă „umbrela”. După încheierea atacului, puteți restabili rutarea în starea anterioară.

nu este obligatoriu să traduceți tot traficul. De exemplu, dacă observați că prin anumite uplink-uri sau prin peer-ing nu există atacuri (sau traficul este nesemnificativ), puteți continua să anunțați prefixelor cu atribute competitive către acești vecini BGP.

Protecția împotriva „atacurilor de protocol” și „atacurilor de aplicație” o puteți încredința partenerilor.
Iată aici puteți citi o cercetare bună (traducere). Deși este un articol de acum doi ani, vă va oferi o idee despre abordările pe care le puteți adopta pentru a vă proteja împotriva atacurilor DDOS.

În principiu, puteți să vă limitați la aceasta, lăsându-vă complet protecția în mâinile unui furnizor extern. Există avantaje în această soluție, dar și un dezavantaj evident. Este vorba, din nou, în funcție de ce se ocupă compania dumneavoastră, de supraviețuirea afacerii. Și a încredința astfel de lucruri unor organizații externe…

Prin urmare, să vedem cum putem organiza a doua și a treia linie de apărare (ca supliment la protecția furnizorului).

Așadar, 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ă” de DDOS cu ajutorul unuia dintre furnizori. Să presupunem că acest furnizor folosește Arbor pentru filtrarea traficului și filtre la limita 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 echipamentul de filtrare. Prin urmare, în condiții normale, traficul nu este filtrat.
Să presupunem că se desfășoară un atac SYN flood. Chiar dacă ați comandat un serviciu prin care, în cazul unui atac, traficul este redirecționat automat pentru filtrare, acest lucru nu se întâmplă imediat. Pe parcursul unui minut sau mai mult, rămâneți sub atac. Și acest lucru poate duce la defectarea echipamentului dvs. sau la degradarea serviciului. În acest caz, limitarea traficului la nivelul rutării de frontieră, deși va face ca unele sesiuni TCP să nu se stabilească în acest timp, va salva infrastructura dumneavoastră de probleme și mai mari.

Exemplu 2
Un număr anormal de mare de pachete SYN poate fi nu doar rezultatul unui atac SYN flood. Să presupunem că oferiți un serviciu în care puteți avea simultan aproximativ 100.000 de conexiuni TCP (într-un singur data center).
Să presupunem că, ca urmare a unei probleme scurte cu unul dintre principalii dvs. furnizori, a fost întreruptă jumătate din sesiuni. Dacă aplicația dvs. este proiectată astfel încât să încerce imediat (sau după un interval de timp uniform pentru toate sesiunile) să restabilească conexiunea, atunci veți primi simultan cel puțin 50.000 de pachete SYN.
Dacă, deasupra acestor sesiuni, de exemplu, ar trebui să funcționeze un ssl/tls handshake, care presupune schimbul de certificate, din punctul de vedere al epuizării resurselor pentru echilibratorul dvs. de sarcină, acest lucru va fi un 'DDoS' mult mai puternic decât un simplu SYN flood. S-ar părea că echilibratoarele ar trebui să gestioneze astfel de evenimente, dar… din păcate, ne-am confruntat cu această problemă în mod direct.
Și, desigur, un policer pe routerul de frontieră vă va salva echipamentul și în acest caz.

Nivelul trei de protecție împotriva DDoS/DOS este setările unei firewall.

Aici puteți limita atacurile de tipul doi și trei. Î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ă muncă, filtrând cât mai mult în primele două linii de apărare. Și iată de ce.
Ați avut vreodată situația în care, în timp ce generați trafic pentru a verifica, de exemplu, cât de rezistentă este sistemul de operare al serverelor dvs. la atacuri DDOS, ați "ucis" firewall-ul încărcându-l la 100%, folosind un trafic de intensitate normală? Dacă nu, poate că este doar pentru că nu ați încercat?
În general, firewall-ul, așa cum am menționat, este ceva complex și funcționează bine cu vulnerabilitățile cunoscute și soluțiile testate, dar dacă trimiteți ceva neobișnuit, un fel de gunoi sau pachete cu antete incorecte, aveți o probabilitate semnificativă (având în vedere experiența mea) de a bloca chiar și echipamente de top. De aceea, în etapa 2, folosiți doar traficul care trebuie să intre în rețeaua dvs. prin intermediul ACL-urilor obișnuite (la nivel L3/L4).