{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS \u00een ajutor: cum realiz\u0103m teste de stres \u0219i de \u00eenc\u0103rcare","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nCompania Variti dezvolt\u0103 solu\u021bii de protec\u021bie \u00eempotriva botilor \u0219i atacurilor DDoS, precum \u0219i teste de stres \u0219i de sarcin\u0103. La conferin\u021ba HighLoad++ 2018, am discutat despre cum s\u0103 protej\u0103m resursele de diferite tipuri de atacuri. Pe scurt: izola\u021bi p\u0103r\u021bile sistemului, utiliza\u021bi servicii cloud \u0219i CDN \u0219i actualiza\u021bi-v\u0103 regulat. Dar f\u0103r\u0103 companii specializate \u00een securitate, nu ve\u021bi face fa\u021b\u0103 \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\n\u00cenainte de a citi textul, pute\u021bi consulta un rezumat scurt pe site-ul conferin\u021bei<\/a><\/noindex>.
\nDac\u0103 nu v\u0103 place s\u0103 citi\u021bi sau dori\u021bi pur \u0219i simplu s\u0103 viziona\u021bi un videoclip, \u00eenregistrarea prezent\u0103rii noastre se afl\u0103 mai jos sub spoiler.<\/p>\n

\u00cenregistrarea video a prezent\u0103rii<\/b>

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Multe companii deja \u0219tiu s\u0103 efectueze teste de sarcin\u0103, dar nu toate fac teste de stres. Unii dintre clien\u021bii no\u0219tri cred c\u0103 site-ul lor este invulnerabil, deoarece au un sistem highload, care \u00eei protejeaz\u0103 bine de atacuri. Noi \u00eens\u0103 demonstr\u0103m c\u0103 nu este chiar a\u0219a.
\nDesigur, \u00eenainte de a efectua testele, ob\u021binem permisiunea de la client, cu semn\u0103tur\u0103 \u0219i \u0219tampil\u0103, iar cu ajutorul nostru nu se poate efectua o atac DDoS \u00eempotriva nim\u0103nui. Testarea se realizeaz\u0103 \u00een timpul selectat de client, c\u00e2nd traficul pe resursa sa este minim, iar problemele de acces nu afecteaz\u0103 clien\u021bii. \u00cen plus, deoarece \u00een timpul test\u0103rii pot ap\u0103rea probleme, avem un contact permanent cu clientul. Acest lucru ne permite nu doar s\u0103 raport\u0103m rezultatele atinse, ci \u0219i s\u0103 facem modific\u0103ri pe parcursul test\u0103rii. La finalizarea test\u0103rii, \u00eentotdeauna \u00eentocmim un raport, \u00een care men\u021bion\u0103m deficien\u021bele descoperite \u0219i oferim recomand\u0103ri pentru remedierea punctelor slabe ale site-ului. <\/p>\n

Cum lucr\u0103m<\/h3>\n

\n\u00cen timpul test\u0103rii, emul\u0103m un botnet. Deoarece lucr\u0103m cu clien\u021bi care nu se afl\u0103 \u00een re\u021belele noastre, pentru a evita ca testul s\u0103 se termine \u00een prima minut\u0103 din cauza activ\u0103rii limitelor sau protec\u021biei, furniz\u0103m sarcina nu dintr-o singur\u0103 adres\u0103 IP, ci din propria noastr\u0103 subre\u021bea. \u00cen plus, pentru a genera o sarcin\u0103 semnificativ\u0103, avem propriul server de testare destul de puternic.<\/p>\n

Postulate<\/h3>\n

<\/p>\n

Mult nu \u00eenseamn\u0103 neap\u0103rat bine<\/b>
\nCu c\u00e2t putem reduce sarcina p\u00e2n\u0103 la punctul de e\u0219ec al resursei, cu at\u00e2t mai bine. Dac\u0103 reu\u0219im s\u0103 facem ca site-ul s\u0103 \u00eenceteze s\u0103 func\u021bioneze de la o solicitare pe secund\u0103 sau chiar de la o solicitare pe minut, este minunat. Pentru c\u0103, conform legii lui Murphy, utilizatorii sau atacatorii vor c\u0103dea \u00eent\u00e2mpl\u0103tor exact pe aceast\u0103 vulnerabilitate. <\/p><\/blockquote>\n

E\u0219ecul par\u021bial este mai bun dec\u00e2t cel complet<\/b>
\n\u00centotdeauna recomand\u0103m s\u0103 facem sistemele heterogene. \u0218i trebuie s\u0103 le separ\u0103m la nivel fizic, nu doar prin containerizare. \u00cen cazul separ\u0103rii fizice, chiar dac\u0103 ceva pe site e\u0219ueaz\u0103, exist\u0103 o mare probabilitate ca acesta s\u0103 nu \u00eenceteze complet s\u0103 func\u021bioneze, iar utilizatorii s\u0103 aib\u0103 acces cel pu\u021bin la o parte din func\u021bionalitate.<\/p><\/blockquote>\n

Arhitectura corect\u0103 este fundamentul rezisten\u021bei<\/b>
\nRezisten\u021ba resursei \u0219i capacitatea sa de a rezista atacurilor \u0219i sarcinilor trebuie s\u0103 fie integrate \u00een etapa de proiectare, de fapt, \u00eenc\u0103 de la desenarea primelor diagrame \u00een caiet. Pentru c\u0103 dac\u0103 se strecoar\u0103 erori fatale, este posibil s\u0103 le corect\u0103m ulterior, dar este foarte greu.<\/p><\/blockquote>\n

Nu doar codul, ci \u0219i configura\u021bia trebuie s\u0103 fie bun\u0103<\/b>
\nMul\u021bi cred c\u0103 o echip\u0103 bun\u0103 de dezvoltare este o garan\u021bie a rezisten\u021bei serviciului. O echip\u0103 bun\u0103 de dezvoltare este \u00eentr-adev\u0103r necesar\u0103, dar trebuie s\u0103 existe \u0219i o bun\u0103 operare, un bun DevOps. Cu alte cuvinte, sunt necesari speciali\u0219ti care s\u0103 configureze corect Linux-ul \u0219i re\u021beaua, s\u0103 scrie corect configura\u021biile \u00een nginx, s\u0103 stabileasc\u0103 limitele etc. Altfel, resursa va func\u021biona bine doar \u00een test, iar \u00een produc\u021bie, la un moment dat, totul se va strica.<\/p><\/blockquote>\n

Diferen\u021bele dintre testarea de sarcin\u0103 \u0219i testarea de stres<\/b>
\nTestarea de sarcin\u0103 permite identificarea limitelor de func\u021bionare ale sistemului. Testarea de stres este destinat\u0103 identific\u0103rii punctelor slabe ale sistemului \u0219i este utilizat\u0103 pentru a \u201esparge\u201d acest sistem \u0219i a observa cum se va comporta \u00een timpul e\u0219ecului unor p\u0103r\u021bi. \u00cen acest timp, caracteristica sarcinii r\u0103m\u00e2ne de obicei necunoscut\u0103 pentru client p\u00e2n\u0103 la \u00eenceputul test\u0103rii de stres.<\/p><\/blockquote>\n

<\/p>\n

Tr\u0103s\u0103turi distinctive ale atacurilor L7<\/h3>\n

\nTipurile de sarcin\u0103 le \u00eemp\u0103r\u021bim de obicei \u00een sarcini de nivel L7 \u0219i L3&4. L7 este sarcina la nivel de aplica\u021bie, de cele mai multe ori se refer\u0103 doar la HTTP, dar noi \u00een\u021belegem orice sarcin\u0103 la nivelul protocolului TCP.
\nAtacurile L7 au anumite tr\u0103s\u0103turi distinctive. \u00cen primul r\u00e2nd, acestea vizeaz\u0103 direct aplica\u021bia, ceea ce face dificil\u0103 stoparea lor prin mijloace de re\u021bea. Aceste atacuri implic\u0103 logic\u0103 \u0219i, datorit\u0103 acestui lucru, consum\u0103 foarte eficient CPU, memorie, disc, baz\u0103 de date \u0219i alte resurse, chiar \u0219i cu un trafic redus.<\/p>\n

Inunda\u021bie HTTP<\/h3>\n

\n\u00cen cazul oric\u0103rui atac, este mai u\u0219or s\u0103 generezi \u00eenc\u0103rcare dec\u00e2t s\u0103 o gestionezi, iar \u00een cazul L7, acest lucru este de asemenea adev\u0103rat. Traficul atacului nu este \u00eentotdeauna u\u0219or de distins de cel legitim \u0219i cel mai adesea acest lucru se poate face \u00een func\u021bie de frecven\u021b\u0103, dar dac\u0103 totul este planificat corect, este imposibil s\u0103 \u00een\u021belegi din jurnale unde este atacul \u0219i unde sunt cererile legitime.
\nCa prim exemplu, s\u0103 analiz\u0103m atacul Inunda\u021bie HTTP. Din grafic se poate observa c\u0103, de obicei, aceste atacuri sunt foarte puternice, \u00een exemplul de mai jos, num\u0103rul maxim de cereri a dep\u0103\u0219it 600 de mii pe minut.<\/p>\n

\"DDoS
\n
\nInunda\u021bia HTTP este cea mai simpl\u0103 modalitate de a crea \u00eenc\u0103rcare. De obicei, se folose\u0219te un instrument de testare a \u00eenc\u0103rc\u0103rii, cum ar fi ApacheBench, \u0219i se stabilesc o cerere \u0219i o \u021bint\u0103. Cu o abordare at\u00e2t de simpl\u0103, riscul de a \u00eent\u00e2mpina probleme cu caching-ul serverului este ridicat, dar acesta poate fi evitat cu u\u0219urin\u021b\u0103. De exemplu, ad\u0103ug\u00e2nd \u0219iruri aleatorii \u00een cerere, ceea ce va obliga serverul s\u0103 livreze constant pagina proasp\u0103t\u0103.
\nDe asemenea, nu trebuie uitat de user-agent \u00een procesul de generare a \u00eenc\u0103rc\u0103rii. Multe user-agent-uri ale instrumentelor populare de testare sunt filtrate de administratori de sistem, \u0219i \u00een acest caz, \u00eenc\u0103rcarea poate s\u0103 nu ajung\u0103 deloc la backend. Rezultatul poate fi semnificativ \u00eembun\u0103t\u0103\u021bit prin inserarea unui antet valid din browser \u00een cerere.
\n\u00cen ciuda simplit\u0103\u021bii atacului, inunda\u021biile HTTP au \u0219i dezavantajele lor. \u00cen primul r\u00e2nd, pentru a genera \u00eenc\u0103rcare sunt necesare resurse mari. \u00cen al doilea r\u00e2nd, aceste atacuri sunt foarte u\u0219or de detectat, mai ales dac\u0103 vin dintr-o singur\u0103 adres\u0103. Drept urmare, cererile \u00eencep imediat s\u0103 fie filtrate fie de administratorii de sistem, fie chiar la nivelul furnizorului. <\/p>\n

Ce s\u0103 cau\u021bi<\/h3>\n

\nPentru a reduce num\u0103rul de cereri pe secund\u0103 f\u0103r\u0103 a pierde din eficien\u021b\u0103, trebuie s\u0103 ne folosim imagina\u021bia \u0219i s\u0103 investig\u0103m site-ul. Astfel, putem solicita nu doar canalul sau serverul, ci \u0219i p\u0103r\u021bi separate ale aplica\u021biei, cum ar fi bazele de date sau sistemele de fi\u0219iere. De asemenea, putem c\u0103uta zone pe site care efectueaz\u0103 calcule complexe: calculatoare, pagini de recomandare de produse etc. \u00cen cele din urm\u0103, se \u00eent\u00e2mpl\u0103 adesea ca pe site s\u0103 existe un script PHP care genereaz\u0103 o pagin\u0103 din c\u00e2teva sute de mii de linii. Un astfel de script poate suprasolicita semnificativ serverul \u0219i poate deveni o \u021bint\u0103 pentru un atac.<\/p>\n

Unde s\u0103 c\u0103ut\u0103m<\/h3>\n

\nC\u00e2nd scan\u0103m resursa \u00eenainte de a desf\u0103\u0219ura testarea, ne uit\u0103m, desigur, la site-ul \u00eensu\u0219i. C\u0103ut\u0103m diverse c\u00e2mpuri de introducere, fi\u0219iere mari \u2013 \u00een general, tot ce ar putea crea probleme resursei \u0219i ar putea \u00eencetini func\u021bionarea acesteia. Aici ne ajut\u0103 simplele instrumente de dezvoltare din Google Chrome \u0219i Firefox, care arat\u0103 timpii de r\u0103spuns ai paginii.
\nDe asemenea, scan\u0103m subdomeniile. De exemplu, exist\u0103 un magazin online, abc.com, care are un subdomeniu admin.abc.com. Probabil este o interfa\u021b\u0103 de administrare cu autentificare, dar dac\u0103 \u00eei aducem o sarcin\u0103, aceasta poate crea probleme pentru resursa principal\u0103.
\nSite-ul poate avea un subdomeniu api.abc.com. Probabil acesta este un resource pentru aplica\u021bii mobile. Aplica\u021bia poate fi g\u0103sit\u0103 \u00een App Store sau Google Play, se poate stabili un hotspot special, modifica API-ul \u0219i \u00eenregistra conturi de testare. Problema este c\u0103, de cele mai multe ori, oamenii cred c\u0103 tot ce este protejat prin autentificare este invulnerabil la atacuri de tip denial of service. De parc\u0103 autentificarea este cel mai bun CAPTCHA, dar nu este adev\u0103rat. Crearea a 10-20 de conturi de testare este u\u0219oar\u0103, iar odat\u0103 ce le avem, ob\u021binem acces la func\u021bionalit\u0103\u021bi complexe \u0219i necorectate.
\nDesigur, ne uit\u0103m la istoric, la robots.txt \u0219i WebArchive, ViewDNS, c\u0103ut\u0103m versiuni vechi ale resursei. Uneori se \u00eent\u00e2mpl\u0103 ca dezvoltatorii s\u0103 lanseze, s\u0103 zicem, mail2.yandex.net, iar o versiune veche, mail.yandex.net, s\u0103 r\u0103m\u00e2n\u0103. Acest mail.yandex.net \u00eenceteaz\u0103 s\u0103 fie suportat, resursele de dezvoltare nu mai sunt alocate pentru el, dar continu\u0103 s\u0103 consume baza de date. Prin urmare, cu ajutorul versiunii vechi putem folosi eficient resursele backend-ului \u0219i tot ceea ce se afl\u0103 \u00een spatele structur\u0103rii. Desigur, asta nu se \u00eent\u00e2mpl\u0103 \u00eentotdeauna, dar ne confrunt\u0103m cu astfel de situa\u021bii destul de des.
\nDesigur, analiz\u0103m to\u021bi parametrii cererii, structura cookie-urilor. Putem, de exemplu, s\u0103 \u00eencarc\u0103m \u00een JSON un array \u00een interiorul cookie-ului cu o anumit\u0103 valoare, s\u0103 cre\u0103m o ierarhie mare \u0219i s\u0103 facem ca resursa s\u0103 func\u021bioneze extrem de lent.<\/p>\n

\u00cenc\u0103rcare \u00een c\u0103utare<\/h3>\n

\nPrimul lucru care \u00eemi vine \u00een minte c\u00e2nd analizez un site este s\u0103 \u00eencarc baza de date, av\u00e2nd \u00een vedere c\u0103 c\u0103utarea exist\u0103 aproape pe toate site-urile, iar majoritatea dintre ele, din p\u0103cate, sunt prost protejate. De ceva vreme, dezvoltatorii nu acord\u0103 suficient\u0103 aten\u021bie c\u0103ut\u0103rii. Totu\u0219i, exist\u0103 o recomandare: nu face\u021bi cereri repetitive, deoarece s-ar putea s\u0103 v\u0103 confrunta\u021bi cu cache, la fel ca \u00een cazul unui atac HTTP flood.
\nDe asemenea, a face cereri aleatorii \u00een baza de date nu este \u00eentotdeauna eficient. Mult mai bine este s\u0103 crea\u021bi o list\u0103 de cuvinte cheie relevante pentru c\u0103utare. Dac\u0103 revenim la exemplul unui magazin online: s\u0103 presupunem c\u0103 site-ul vinde anvelope auto \u0219i permite stabilirea razei anvelopelor, tipului de ma\u0219in\u0103 \u0219i altor parametrii. Prin urmare, combina\u021biile de cuvinte relevante fac ca baza de date s\u0103 func\u021bioneze \u00een condi\u021bii mult mai complexe.
\n\u00cen plus, este recomandat s\u0103 folosi\u021bi paginarea: c\u0103utarea este mult mai dificil\u0103 atunci c\u00e2nd trebuie s\u0103 ofere \u00eenainte penultima pagin\u0103 a rezultatelor dec\u00e2t prima. Asta \u00eenseamn\u0103 c\u0103 prin paginare pute\u021bi diversifica pu\u021bin \u00eenc\u0103rcarea.
\n\u00cen exemplul de mai jos, ilustr\u0103m \u00eenc\u0103rcarea \u00een c\u0103utare. Se observ\u0103 c\u0103 \u00eenc\u0103 din prima secund\u0103 a testului cu zece cereri pe secund\u0103, site-ul s-a pr\u0103bu\u0219it \u0219i nu a mai r\u0103spuns.<\/p>\n

\"DDoS
\n<\/p>\n

Dac\u0103 nu exist\u0103 c\u0103utare?<\/h3>\n

\nDac\u0103 nu exist\u0103 c\u0103utare, nu \u00eenseamn\u0103 c\u0103 site-ul nu con\u021bine alte c\u00e2mpuri vulnerabile. Un astfel de c\u00e2mp ar putea fi autentificarea. \u00cen prezent, dezvoltatorii iubesc s\u0103 fac\u0103 hash-uri complexe pentru a proteja baza de date a logins-urilor \u00eempotriva atacurilor cu tabele rainbow. Acest lucru este bine, dar aceste hash-uri consum\u0103 resurse mari de CPU. Un flux mare de autentific\u0103ri false duce la e\u0219ecul procesorului, iar ca urmare, la final, site-ul nu mai func\u021bioneaz\u0103.
\nPrezen\u021ba pe site a diferitelor formulare pentru comentarii \u0219i feedback este un motiv bun pentru a trimite texte foarte mari sau pur \u0219i simplu pentru a genera spam \u00een mas\u0103. Uneori, site-urile accept\u0103 fi\u0219iere \u00eenc\u0103rcate, inclusiv \u00een format gzip. \u00cen acest caz, lu\u0103m un fi\u0219ier de 1TB, \u00eel comprim\u0103m cu gzip la c\u00e2\u021biva octe\u021bi sau kiloocte\u021bi \u0219i \u00eel trimitem pe site. Apoi este dezarhivat, cre\u00e2nd un efect foarte interesant. <\/p>\n

Rest API<\/h3>\n

\nAr fi bine s\u0103 acord\u0103m pu\u021bin aten\u021bie unor servicii care sunt foarte populare \u00een prezent, cum ar fi Rest API. Protejarea unui Rest API este mult mai complicat\u0103 dec\u00e2t protejarea unui site obi\u0219nuit. Chiar \u0219i cele mai banale metode de protec\u021bie \u00eempotriva atacurilor brute force \u0219i a altor activit\u0103\u021bi ilegitime nu func\u021bioneaz\u0103 pentru Rest API.
\nRest API este foarte u\u0219or de compromis, deoarece se conecteaz\u0103 direct la baza de date. \u00cen acest caz, oprirea unui astfel de serviciu are consecin\u021be destul de grave pentru afacere. Problema este c\u0103 de obicei Rest API este legat nu doar de site-ul principal, ci \u0219i de aplica\u021bia mobil\u0103, de diverse resurse interne de afaceri. \u0218i dac\u0103 toate acestea cedeaz\u0103, efectul este de multe ori mai pronun\u021bat dec\u00e2t \u00een cazul unei c\u0103deri simple a unui site. <\/p>\n

\u00cenc\u0103rc\u0103tura pe con\u021binut greu<\/h3>\n

\nDac\u0103 ni se ofer\u0103 s\u0103 test\u0103m o aplica\u021bie obi\u0219nuit\u0103 de tip single-page, un landing page, sau un site de vizit\u0103, care nu are func\u021bionalit\u0103\u021bi complexe, c\u0103ut\u0103m con\u021binut greu. De exemplu, imagini mari livrate de server, fi\u0219iere binare, documenta\u021bie PDF \u2014 \u00eencerc\u0103m s\u0103 desc\u0103rc\u0103m toate acestea. Astfel de teste solicit\u0103 bine sistemul de fi\u0219iere \u0219i blocheaz\u0103 canalele, fiind astfel eficiente. Adic\u0103, chiar dac\u0103 nu reu\u0219i\u021bi s\u0103 d\u0103una\u021bi serverului, desc\u0103rc\u00e2nd un fi\u0219ier mare la viteze mici, pur \u0219i simplu ve\u021bi aglomera canalul serverului \u021bint\u0103, iar astfel ve\u021bi genera un refuz de serviciu.
\nDintr-un astfel de test se observ\u0103 c\u0103 la o vitez\u0103 de 30 RPS site-ul nu a mai r\u0103spuns, sau a returnat erori de tip 500.<\/p>\n

\"DDoS
\n
\nNu trebuie s\u0103 uit\u0103m de configurarea serverelor. Adesea putem observa c\u0103 o persoan\u0103 a cump\u0103rat o ma\u0219in\u0103 virtual\u0103, a instalat Apache pe aceasta, a configurat totul din set\u0103rile implicite, a plasat aplica\u021bia PHP, iar mai jos putem vedea rezultatul. <\/p>\n

\"DDoS
\n
\nAici \u00eenc\u0103rc\u0103tura a mers \u00een r\u0103d\u0103cin\u0103 \u0219i a fost de doar 10 RPS. Am a\u0219teptat 5 minute \u0219i serverul a cedat. De fapt, nu se \u0219tie precis de ce a cedat, dar se presupune c\u0103 pur \u0219i simplu a consumat toat\u0103 memoria \u0219i de aceea nu a mai r\u0103spuns.<\/p>\n

Wave based<\/h3>\n

\n\u00cen ultimii ani, atacurile de tip wave au devenit destul de populare. Acest lucru se datoreaz\u0103 faptului c\u0103 multe organiza\u021bii achizi\u021bioneaz\u0103 diverse echipamente pentru protec\u021bia \u00eempotriva DDoS, care necesit\u0103 o anumit\u0103 perioad\u0103 pentru acumularea de statistici pentru a \u00eencepe filtrarea atacului. Cu alte cuvinte, ele nu filtreaz\u0103 atacul \u00een primele 30-40 de secunde, deoarece acumuleaz\u0103 date \u0219i se antreneaz\u0103. \u00cen consecin\u021b\u0103, \u00een aceste 30-40 de secunde, se poate lansa at\u00e2t de mult\u0103 trafic pe site \u00eenc\u00e2t resursa va r\u0103m\u00e2ne inaccesibil\u0103 o perioad\u0103 lung\u0103 de timp, p\u00e2n\u0103 c\u00e2nd toate cererile sunt procesate.
\n\u00cen cazul atacului de mai jos, intervalul a fost de 10 minute, dup\u0103 care a venit o nou\u0103 por\u021biune modificat\u0103 a atacului.<\/p>\n

\"DDoS
\n
\nAsta \u00eenseamn\u0103 c\u0103 protec\u021bia s-a antrenat, a \u00eenceput filtrarea, dar a venit o nou\u0103 por\u021biune de atac complet diferit\u0103 \u0219i protec\u021bia a \u00eenceput din nou antrenamentul. De fapt, filtrarea \u00eenceteaz\u0103 s\u0103 mai func\u021bioneze, protec\u021bia devine ineficient\u0103 \u0219i site-ul devine inaccesibil.
\nAtacurile de tip wave se caracterizeaz\u0103 prin valori foarte mari la v\u00e2rf, put\u00e2nd atinge sut\u0103 de mii sau milioane de cereri pe secund\u0103, \u00een cazul L7. Dac\u0103 vorbim despre L3&4, atunci acolo pot fi sute de gigabi\u021bi de trafic sau, respectiv, sute de mpps, dac\u0103 ne raport\u0103m la pachete.
\nProblema acestor atacuri const\u0103 \u00een sincronizare. Atacurile vin din botnet-uri, iar pentru a crea un v\u00e2rf de atac foarte mare, este necesar\u0103 o sincronizare ridicat\u0103. Aceast\u0103 coordonare nu reu\u0219e\u0219te \u00eentotdeauna: uneori rezultatul este un v\u00e2rf parabolic, care arat\u0103 destul de lamentabil.<\/p>\n

Nu doar HTTP<\/h3>\n

\nPe l\u00e2ng\u0103 HTTP la nivelul L7, ne place s\u0103 exploat\u0103m \u0219i alte protocoale. De obicei, un site web obi\u0219nuit, \u0219i mai ales un hosting obi\u0219nuit, expune protocoale de email \u0219i MySQL. Protocoalele de email sunt mai pu\u021bin susceptibile la sarcini dec\u00e2t bazele de date, dar pot fi, de asemenea, suprasolicitate suficient de eficient, duc\u00e2nd la un CPU supraaglomerat pe server.
\nAm ob\u021binut rezultate reale prin exploatarea vulnerabilit\u0103\u021bii SSH din 2016. Acum, aceast\u0103 vulnerabilitate este majoritatea corectat\u0103, dar asta nu \u00eenseamn\u0103 c\u0103 nu pot fi generate sarcini pe SSH. Se poate. Pur \u0219i simplu, se genereaz\u0103 o sarcin\u0103 enorm\u0103 de autentific\u0103ri, SSH consum\u0103 aproape tot CPU-ul de pe server, iar site-ul web cedeaz\u0103 deja de la una-dou\u0103 cereri pe secund\u0103. \u00cen consecin\u021b\u0103, aceste una sau dou\u0103 cereri nu pot fi diferen\u021biate din jurnale de o sarcin\u0103 legitim\u0103.
\nR\u0103m\u00e2n relevante \u0219i numeroase conexiuni pe care le deschidem pe servere. \u00cen trecut, Apache a avut aceast\u0103 problem\u0103, iar acum nginx se confrunt\u0103 \u00een mod similar, deoarece este adesea configurat implicit. Num\u0103rul de conexiuni pe care nginx le poate men\u021bine deschise este limitat; astfel, odat\u0103 ce atingem acest num\u0103r de conexiuni, nginx nu accept\u0103 mai multe, iar site-ul nu mai func\u021bioneaz\u0103.
\nCluster-ul nostru de testare dispune de suficient CPU pentru a ataca SSL handshake. \u00cen principiu, dup\u0103 cum arat\u0103 practica, botnet-urile fac \u0219i ele uneori acest lucru. Pe de o parte, este clar c\u0103 f\u0103r\u0103 SSL nu putem evita, datorit\u0103 rezultatelor Google, clasific\u0103rii \u0219i securit\u0103\u021bii. Pe de alt\u0103 parte, SSL, din p\u0103cate, are o problem\u0103 cu CPU. <\/p>\n

L3&4<\/h3>\n

\nC\u00e2nd vorbim de atacuri la nivelurile L3&4, de obicei ne referim la atacuri la nivelul canalului. Aceast\u0103 \u00eenc\u0103rcare este aproape \u00eentotdeauna distinct\u0103 de cea legitim\u0103, cu excep\u021bia cazului atacului SYN-flood. Problema atacurilor SYN-flood pentru m\u0103surile de protec\u021bie const\u0103 \u00een volumul mare. Valoarea maxim\u0103 pentru L3&4 a fost de 1,5-2 Tbps. Un astfel de trafic este foarte greu de gestionat chiar \u0219i pentru companii mari, inclusiv Oracle \u0219i Google.
\nSYN \u0219i SYN-ACK sunt pachete utilizate \u00een timpul stabilirii unei conexiuni. Prin urmare, SYN-flood este greu de distins de \u00eenc\u0103rcarea legitim\u0103: nu este clar dac\u0103 este un SYN care a venit pentru a stabili o conexiune sau o parte a unui flud.<\/p>\n

UDP-flood<\/h3>\n

\nDe obicei, infractorii nu au resursele pe care le avem noi, a\u0219a c\u0103 pentru organizarea atacurilor se poate folosi amplificarea. Adic\u0103, infractorul scaneaz\u0103 internetul \u0219i g\u0103se\u0219te fie servere vulnerabile, fie configurate gre\u0219it, care r\u0103spund, de exemplu, cu trei SYN-ACK la un singur pachet SYN. Schimb\u00e2nd adresa sursei cu cea a serverului \u021bint\u0103, printr-un singur pachet, se poate amplifica puterea, s\u0103 zicem, de trei ori \u0219i redirec\u021biona traficul c\u0103tre victim\u0103.<\/p>\n

\"DDoS
\n
\nProblema amplific\u0103rilor const\u0103 \u00een dificultatea de a le detecta. Unul dintre cele mai recente exemple este cazul bine cunoscut cu memcached vulnerabil. \u00cen plus, acum exist\u0103 foarte multe dispozitive IoT, camere IP, care de obicei sunt configurate implicit gre\u0219it, astfel c\u0103 infractorii folosesc aceste dispozitive pentru a derula atacuri mai des. <\/p>\n

\"DDoS
\n<\/p>\n

SYN-flood complicat<\/h3>\n

\nSYN-flood este, probabil, cea mai interesant\u0103 form\u0103 de atac din perspectiva dezvoltatorului. Problema este c\u0103 de multe ori administratorii de sistem folosesc blocarea pe IP pentru protec\u021bie. Din p\u0103cate, blocarea pe IP afecteaz\u0103 nu doar administratori care ac\u021bioneaz\u0103 conform unor scripturi, ci \u0219i unele sisteme de protec\u021bie foarte costisitoare.
\nAceast\u0103 metod\u0103 poate deveni o catastrof\u0103, deoarece dac\u0103 atacatorii substituie adrese IP<\/a>, compania \u00ee\u0219i va bloca propria subre\u021bea. C\u00e2nd Firewall-ul \u00ee\u0219i blocheaz\u0103 propriul cluster, interac\u021biunile externe se vor pr\u0103bu\u0219i, iar resursa va ceda.
\nAchizi\u021bionarea bloc\u0103rii propriei re\u021bele nu este complicat\u0103. Dac\u0103 \u00een biroul clientului exist\u0103 o re\u021bea WI-Fi sau dac\u0103 func\u021bionalitatea resurselor este evaluat\u0103 prin diferite monitoriz\u0103ri, lu\u0103m adresa IP a acestui sistem de monitorizare sau a clientului Wi-Fi din birou \u0219i o folosim ca surs\u0103. \u00cen acest caz, resursa pare a fi disponibil\u0103, dar adresele IP \u021bint\u0103 sunt blocate. Astfel, re\u021beaua Wi-Fi a conferin\u021bei HighLoad, care prezint\u0103 un nou produs al companiei, poate fi blocat\u0103 \u2014 ceea ce implic\u0103 anumite costuri de afaceri \u0219i economice.
\n\u00cen timpul test\u0103rilor, nu putem folosi amplificarea prin memcached cu resurse externe, deoarece exist\u0103 acorduri pentru transmiterea traficului doar c\u0103tre adrese IP autorizate. Drept urmare, folosim amplificarea prin SYN \u0219i SYN-ACK, c\u00e2nd pentru trimiterea unui SYN, sistemul r\u0103spunde cu dou\u0103-trei SYN-ACK \u0219i, astfel, atacul este multiplicat de dou\u0103-trei ori. <\/p>\n

Instrumente<\/h3>\n

\nUnul dintre principalele instrumente pe care le folosim pentru a genera \u00eenc\u0103rcare la nivel de L7 este Yandex-tank. \u00cen mod special, se folose\u0219te \u201efanfara\u201d Phantom, plus avem c\u00e2teva scripturi pentru generarea gloan\u021belor \u0219i pentru analiza rezultatelor.
\nPentru analiza traficului de re\u021bea se folose\u0219te Tcpdump, iar pentru analiza serverului \u2014 Nmap. Pentru a crea o \u00eenc\u0103rcare la nivel de L3&4 se folose\u0219te OpenSSL \u0219i pu\u021bin\u0103 magie proprie cu biblioteca DPDK. DPDK este o bibliotec\u0103 de la Intel care permite lucrul cu interfa\u021ba de re\u021bea, ocolind stiva Linux, astfel sporind eficien\u021ba. Bine\u00een\u021beles, folosim DPDK nu doar la nivel de L3&4, ci \u0219i la nivel de L7, deoarece permite crearea unui flux de \u00eenc\u0103rcare foarte ridicat, de ordinul milioanelor de cereri pe secund\u0103 de la o singur\u0103 ma\u0219in\u0103.
\nDe asemenea, folosim anumite generatoare de trafic \u0219i instrumente speciale, pe care le scriem pentru teste specifice. Dac\u0103 ne g\u00e2ndim la vulnerabilitatea prin SSH, setul men\u021bionat mai sus nu poate fi exploatat. Dac\u0103 atac\u0103m protocolul de e-mail, folosim utilitarele po\u0219tale sau pur \u0219i simplu scriem scripturi pentru ele.<\/p>\n

\n

Conclusions<\/h3>\n

\n\u00cen concluzie, a\u0219 dori s\u0103 spun:<\/p>\n