[Analiză tehnică] Detaliat și ușor de înțeles: Introducere în atacul atacului în rețea și apărare

Atacurile DDoS (Distributed Denial of Service) sunt unele dintre cele mai puternice și dificile de apărat, deoarece scopul principal al atacurilor DDoS este de a împiedica o țintă desemnată să ofere servicii normale sau chiar să dispară de pe Internet.

DDoS pot fi împărțite pur și simplu în trei categorii, în funcție de modul în care sunt inițiate.

Prima categorie câștigă prin forțăPachete masive de date inundă toate colțurile Internetului, blocând intrarea în IDC, făcând inutile diverse sisteme hardware puternice de apărare și procese rapide și eficiente de urgență. Exemple tipice ale acestui tip de atac sunt ICMP Flood și UDP Flood, care acum sunt rare.

A doua categorie câștigă prin istețime, inteligent și imperceptibil, trimiterea unui pachet la fiecare câteva minute sau chiar necesită doar un pachet poate face ca serverul de configurare luxos să nu mai răspundă. Acest tip de atac este lansat în principal prin exploatarea vulnerabilităților din protocoale sau software, cum ar fi atacurile Slowloris, atacurile de coliziune hash etc., și necesită coincidențe specifice de mediu.

A treia categorie este o combinație a celor două de mai susNu doar că profită de defectele protocolului și sistemului, dar are și o cantitate mare de trafic, cum ar fi atacul SYN Flood și atacul DNS Query Flood, care este metoda actuală de atac principală.

Acest articol va descrie aceste metode de atac cele mai comune și reprezentative una câte una și va prezenta opțiunile lor de apărare.

SYN Flood este unul dintre cele mai clasice atacuri DDoS de pe Internet, apărând pentru prima dată în jurul anului 1999, Yahoo fiind cea mai faimoasă victimă la acea vreme. Atacurile SYN Flood exploatează defecte TCP triple handshake care pot face serverul țintă nereceptiv și greu de urmărit, la un cost mic.

Procesul standard de strângere de mână TCP în trei direcții este următorul:

• Clientul trimite un pachet TCP care conține flag-ul SYN, SYN este sincronizat, iar pachetul de sincronizare indică portul folosit de client și numărul de serie inițial al conexiunii TCP.
• După primirea pachetului SYN de la client, serverul va returna un pachet SYN+ACK (adică confirmarea confirmării), indicând că cererea clientului este acceptată, iar numărul inițial de serie TCP este adăugat automat cu 1.
• Clientul returnează, de asemenea, un mesaj de confirmare ACK către server, iar numărul de serie TCP este de asemenea adăugat cu 1.
  

După acești trei pași, se stabilește conexiunea TCP. Pentru a asigura o transmisie fiabilă, protocolul TCP a configurat unele mecanisme de gestionare a excepțiilor în timpul celor trei handshake-uri. În al treilea pas, dacă serverul nu primește pachetul final de confirmare ACK de la client, serverul va rămâne în starea SYN_RECV, va adăuga adresa IP a clientului pe lista de așteptare și va retrimite pachetul SYN+ACK în al doilea pas. Repostările se fac de obicei de 3-5 ori, iar lista de așteptare este interogată o singură dată la intervale de aproximativ 30 de secunde pentru a reîncerca toți clienții. Pe de altă parte, după ce serverul trimite pachetul SYN+ACK, el alocă în prealabil resurse pentru a stoca informații pentru conexiunea TCP viitoare, care sunt păstrate în așteptarea reîncercării. Mai important, dacă resursele serverului sunt limitate, starea SYN_RECV care poate fi menținută nu va mai accepta noi pachete SYN după ce depășește limita, adică noile conexiuni TCP vor fi respinse.

SYN Flood folosește setările protocolului TCP de mai sus pentru a atinge scopul atacului. Atacatorii maschează un număr mare de adrese IP pentru a trimite pachete SYN către server, iar deoarece adresele IP falsificate sunt aproape imposibil de existat, aproape niciun dispozitiv nu va returna vreun răspuns serverului. Ca urmare, serverul menține o listă de așteptare uriașă și încearcă din nou să trimită pachete SYN+ACK, ceea ce consumă multe resurse și nu poate fi eliberat. Mai important, coada SYN_RECV a serverului atacat este umplută cu pachete malițioase, iar noile cereri SYN nu mai sunt acceptate, iar utilizatorii legitimi nu pot finaliza trei handshake-uri pentru a stabili conexiuni TCP. Cu alte cuvinte, serverul a fost refuzat de serviciul de către SYN Flood.

Dacă ești interesat de SYN Flood, poți arunca o privire la http://www.icylife.net/yunshu/show.php?id=367, pe care l-am scris în 2006 și care ulterior a făcut mai multe modificări, a corectat bug-uri și a redus agresivitatea, fiind folosit exclusiv pentru testare.

Fiind cel mai de bază și de bază serviciu al Internetului, DNS este, în mod firesc, una dintre țintele importante ale atacurilor DDoS. Dezactivarea unui serviciu DNS poate afecta indirect întreaga afacere a unei companii sau un serviciu de rețea într-o regiune. Acum ceva timp, popularul grup de hackeri anonymous a anunțat, de asemenea, că va ataca 13 servere DNS de pe Internetul global, dar în cele din urmă nu a reușit.

Atacurile UDP sunt cea mai ușoară metodă de a iniția trafic masiv, iar falsificarea IP din surse aleatorii este dificil de urmărit. Totuși, filtrarea este mai ușoară deoarece majoritatea IP-urilor nu oferă servicii UDP, așa că poți pur și simplu să elimini traficul UDP. Prin urmare, atacurile de trafic pur UDP sunt relativ rare acum și sunt înlocuite de atacuri DNS Query Flood purtate de protocolul UDP. Pe scurt, atacurile DDoS lansate cu cât protocolul este mai înalt, cu atât este mai dificil de apărat, deoarece cu cât protocolul este mai ridicat, cu atât este mai legat de afaceri și sistemul de apărare este mai complex.

DNS Query Flood apare atunci când un atacator manipulează un număr mare de mașini sockpuppet pentru a lansa un număr mare de cereri de interogare a numelui de domeniu către țintă. Pentru a preveni filtrarea bazată pe ACL, aleatorietatea pachetelor trebuie îmbunătățită. O practică comună este falsificarea aleatorie a adresei IP sursă, falsificarea aleatorie a portului sursă și a altor parametri la nivelul UDP. La stratul protocolului DNS, ID-ul interogării este falsificat aleatoriu împreună cu numele domeniului care urmează să fie rezolvat. Pe lângă prevenirea filtrării, nume de domenii falsificate aleatorii care trebuie rezolvate pot reduce și probabilitatea de a ajunge la cache-ul DNS și pot consuma cât mai multe resurse CPU ale serverului DNS.

Referitor la codul pentru DNS Query Flood, am scris un cod în iulie 2011 pentru a testa performanța serverului, iar linkul este http://www.icylife.net/yunshu/show.php?id=832. În mod similar, acest cod este artificial mai puțin agresiv și este folosit doar pentru scopuri de testare.

SYN Flood și DNS Query Flood descrise mai sus pot fi apărate eficient în această etapă, iar adevărata bătaie de cap pentru marii producători și companiile de internet sunt atacurile HTTP Flood. HTTP Flood este un atac asupra unui serviciu web asupra unui protocol de nivel șapte. Marele său prejudiciu se manifestă în principal prin trei aspecte: inițiere convenabilă, filtrare dificilă și impact de amploare.

Atât SYN Flood, cât și DNS Query Flood cer atacatorilor să controleze un număr mare de boți cu privilegii root. Este nevoie de timp și efort pentru a colecta un număr mare de privilegii root, iar în timpul atacului, mașina păpușă se reface lentă din cauza pierderii rapide de resurse de către atacator din cauza traficului anormal descoperit de administrator, ceea ce duce la o reducere semnificativă a intensității atacului și nu poate fi susținută pe termen lung. Atacurile HTTP Flood sunt diferite, atacatorii nu trebuie să controleze un număr mare de boți, ci folosesc scanere de porturi pentru a găsi proxy-uri HTTP anonime sau proxi-uri SOCKS pe Internet, prin care atacatorul inițiază cereri HTTP către ținta atacului. Proxy-urile anonime sunt o resursă relativ bogată și nu este dificil să obții proxy-uri în câteva zile, așa că atacurile sunt ușor de inițiat și pot dura mult timp.

Pe de altă parte, atacurile HTTP flood sunt lansate la nivelul HTTP, care imită viguros comportamentul de solicitare a paginilor web al utilizatorilor obișnuiți, strâns legat de afacerea site-urilor, ceea ce face dificilă pentru furnizorii de securitate să ofere o soluție comună care să nu afecteze experiența utilizatorului. Reguli care funcționează bine într-un singur loc, schimbarea scenariilor poate duce la un număr mare de omor din culpă.

În cele din urmă, atacurile HTTP flood pot provoca reacții serioase în lanț, nu doar provocând un răspuns lent direct din partea front-end-ului web atacat, ci și atacând indirect serviciile logice Java și alte niveluri de business și baze de date back-end, crescând presiunea acestora și afectând chiar serverele de stocare a jurnalelor.

Interesant este că HTTP Flood are și un poreclă istorică numită atac CC. CC este o abreviere pentru Challenge Collapsar, care este un dispozitiv de protecție DDoS de la o companie de securitate cunoscută din China. Judecând după situația actuală, nu doar Collapsar, ci tot echipamentul hardware de apărare este încă contestat, iar riscul nu a fost eliminat.

Când vine vorba de atacuri, prima reacție este trafic masiv și pachete masive. Dar există un atac care face opusul, cunoscut ca fiind lent, astfel încât unele ținte de atac sunt ucise fără să știe cum mor, care este atacul de conexiune lentă, cel mai reprezentativ fiind Slowloris inventat de rsnake.

Protocolul HTTP prevede ca cererile HTTP să se termine cu \r\n\r\n, indicând că clientul a terminat de trimis și serverul a început procesarea. Deci ce se întâmplă dacă nu trimiți niciodată \r\n\r\n? Slowloris folosește acest lucru în avantajul său în atacurile DDoS. Atacatorul setează Connection pe Keep-Alive în antetul cererii HTTP, cere serverului web să păstreze conexiunea TCP nedeconectată și apoi trimite încet un format cheie-valoare către server la fiecare câteva minute, cum ar fi a:b\r\n, făcând serverul să creadă că antetul HTTP nu a fost primit și să aștepte. Dacă un atacator folosește multithreading sau un puppet pentru a face același lucru, containerul web al serverului va fi rapid copleșit de atacator și nu va mai accepta cereri noi.

Curând, au început să apară diverse variante ale Slowloris. De exemplu, metoda POST trimite date către serverul web, umple un conținut mare de lungime de conținut, dar lent octet cu octet, conținut real de date POST etc. Referitor la atacul Slowloris, rsnake oferă și un cod de test, vezi http://ha.ckers.org/slowloris/slowloris.pl.

Cele de mai sus introduc mai multe metode de atac de bază, oricare dintre ele putând fi folosite pentru a ataca rețeaua și chiar pentru a învinge site-uri uriașe precum Alibaba, Baidu și Tencent. Dar asta nu e tot, niveluri diferite de atacatori pot lansa atacuri DDoS complet diferite, iar folosirea lor este același lucru.

Atacatorii avansați nu folosesc niciodată un singur vector pentru a ataca, ci îi combină flexibil în funcție de mediul țintă. Flood-ul SYN obișnuit este ușor de filtrat de dispozitivele de curățare a traficului prin detectare inversă, cookie-uri SYN și alte mijloace tehnice, dar dacă pachetele SYN+ACK sunt amestecate în SYN Flood, astfel încât fiecare pachet SYN falsificat are un pachet de confirmare client falsificat corespunzător, corespunzătorul aici se referă la adresa IP sursă, portul sursă, IP-ul destinației, portul destinație, dimensiunea ferestrei TCP, TTL etc. sunt toate în linie cu caracteristicile aceleiași gazde și ale aceluiași flux TCP. Presiunea asupra performanței detecției inverse și cookie-urilor SYN ale echipamentelor de curățare a fluxului va crește semnificativ. De fapt, pachetele de date SYN și diverși alți biți de steag au efecte speciale de atac, care nu sunt introduse aici. Există, de asemenea, tehnici unice pentru DNS Query Flood.

În primul rând, DNS-ul poate fi împărțit în DNS obișnuit și DNS de domeniu autorizat, atacând DNS-ul obișnuit, adresa IP trebuie falsificată aleatoriu, iar serverul necesită rezoluție recursivă; Totuși, atunci când se atacă DNS-ul domeniului autorizat, adresa IP sursă falsificată nu ar trebui să fie pur aleatorie, ci să fie adresele DNS ale ISP-urilor din întreaga lume colectate în avans, pentru a obține efectul maxim de atac, astfel încât dispozitivul de curățare a traficului să fie în situația jenantă de a adăuga sau nu a adăuga lista neagră IP. Adăugarea ei va duce la un număr mare de omucideri din culpă, iar dacă nu adaugi o listă neagră, fiecare pachet trebuie testat invers, ceea ce crește presiunea performanței.

Pe de altă parte, după cum s-a menționat anterior, pentru a crește presiunea curățării dispozitivului, este necesar să se randomizeze numele de domeniu solicitat fără a accesa cache-ul, dar trebuie menționat că numele de domeniu care urmează să fie rezolvat trebuie să aibă o anumită regularitate în falsificare, cum ar fi falsificarea doar a unei anumite părți a numelui de domeniu și solidificarea unei părți pentru a sparge lista albă setată de dispozitivul de curățare. Motivul este simplu: serverele Tencent pot rezolva doar numele de domenii Tencent, iar numele de domenii complet aleatorii pot fi eliminate direct și trebuie consolidate. Dar dacă este complet reparat, este ușor de aruncat direct, deci trebuie falsificat.

În al doilea rând, atacurile asupra DNS nu ar trebui să se concentreze exclusiv pe porturile UDP, care sunt de asemenea servicii standard conform protocolului DNS. În cazul unui atac, atât atacurile UDP cât și cele TCP pot fi efectuate simultan.

Obiectivul HTTP Flood este să pătrundă prin cache-ul din frontend și să ajungă direct la serverul web prin setările câmpului din antetul HTTP. În plus, HTTP Flood este de asemenea foarte critic pentru selecția țintelor, iar atacatorii obișnuiți vor alege pagini care necesită multe interogări de date, cum ar fi căutarea, ca țintă de atac, ceea ce este foarte corect și poate consuma cât mai multe resurse ale serverului. Dar acest atac este ușor de identificat prin curățarea echipamentelor prin identificarea uman-mașină, așa că cum să rezolvăm această problemă? Este foarte simplu, încearcă să alegi pagini la care utilizatorii obișnuiți au acces și prin aplicație, în general, diverse API-uri web. Utilizatorii obișnuiți și traficul malițios provin din aplicație, iar diferența dintre om și mașină este foarte mică, fiind dificil de distins între integrarea de bază.

Fiecare conexiune TCP există atât pe partea de server, cât și pe ea însăși, și trebuie să consume resurse pentru a menține starea TCP, astfel încât conexiunea nu poate fi menținută prea mult. Dacă acest lucru poate fi rezolvat, agresivitatea va fi mult amplificată, adică Slowloris poate lansa atacuri fără stare, poate captura numărul de serie TCP și confirma menținerea conexiunilor TCP pe client prin sniffing, iar nucleul sistemului nu trebuie să acorde atenție diferitelor schimbări de stare ale TCP, iar un notebook poate genera până la 65.535 conexiuni TCP.

Descrierile anterioare sunt toate îmbunătățiri tehnice ale atacurilor. Pe partea umană, există și alte mijloace. Dacă SYN Flood trimite un număr mare de pachete și este însoțit de conexiuni lente Slowloris, câți oameni vor descoperi secretul? Chiar dacă serverul cade, pot fi găsite doar atacuri SYN, încercând să întărească curățarea stratului TCP și ignorând comportamentul stratului aplicației. Toate tipurile de atacuri pot funcționa împreună pentru a obține efectul maxim. Alegerea momentului de atac este, de asemenea, un punct cheie, cum ar fi alegerea personalului de întreținere când ia prânzul, când personalul de întreținere rămâne blocat pe drum după ce termină munca sau când nu există semnal pe placa de rețea wireless din metrou și când întreprinderea țintă organizează un eveniment de amploare și traficul crește.

Acesta este un atac pur, deci nu se oferă cod sau explicații detaliate.

Metodele anterioare de atac necesită mai mult sau mai puțin câțiva boți, chiar și HTTP Flood necesită căutarea unui număr mare de proxy-uri anonime. Dacă are loc un atac, trebuie doar să dai niște instrucțiuni, iar mașina va veni automat să-l execute, ceea ce este soluția perfectă. Acest atac a apărut deja, și asta din partea rețelelor P2P.

După cum știm cu toții, utilizatorii și traficul P2P de pe Internet reprezintă un număr extrem de mare. Dacă toate merg într-un loc desemnat pentru a descărca date și a conecta mii de adrese IP reale, niciun dispozitiv nu poate suporta asta. Luați BT download ca exemplu: falsificarea torrentelor unor videoclipuri populare și postarea lor pe motoarele de căutare este suficientă pentru a induce în eroare mulți utilizatori și trafic, dar acesta este doar un atac de bază.

Atacurile avansate P2P sunt o falsificare directă a serverelor de management al resurselor. De exemplu, clientul Thunder va încărca resursele găsite pe serverul de management al resurselor și apoi le va trimite altor utilizatori care trebuie să descarce aceleași resurse, astfel încât un link să fie publicat. Prin inversarea protocolului, atacatorii colectează o cantitate mare de informații populare despre resurse și le distribuie prin centrul de management al resurselor, care poate fi răspândit instantaneu în întreaga rețea P2P. Ce este și mai înfricoșător este că acest atac nu poate fi oprit, nici măcar de către atacator însuși, iar atacul continuă până când oficialul P2P găsește problema și actualizează serverul, iar utilizatorul descărcat repornește software-ul descărcat.

Asta e tot ce există despre introducerea atacurilor DDoS și nu vreau să merg mai departe — este suficient să înțelegem că atât de multă apărare este suficientă.

În general, atacurile DDoS pot fi dextere și grațioase. Frumusețea aplicării constă în unitatea minții.