Anatomia atacurilor de refuz al serviciului; Testarea în practică

Cum și în ce puncte din sistem poate apărea un atac de refuz de serviciu? Nu numai că primim un răspuns din acest articol, ci și despre instrumentele pe care le putem folosi pentru a testa atacurile DoS, DDoS.

Articolul meu încearcă să prezinte fundalul tehnic al atacurilor Denial of Service (DoS). Pe de o parte, mă ocup de ceea ce înțelegem prin atacuri DoS și DDoS (DoS distribuite). Mai târziu, aventurându-mă puțin mai adânc, voi explica de ce aceste atacuri sunt posibile și cum funcționează tehnic. În cele din urmă, facem un bilanț al modalităților posibile de a ne apăra, evidențiind cele mai inovatoare soluții disponibile.

Atacurile prin refuz de serviciu sunt atunci când unul sau mai mulți atacatori fac ca serviciile pe care utilizatorii doresc să le acceseze să nu fie disponibile pentru clienți. Interesant, dacă un atacator execută un atac, acesta se face de obicei prin rularea dispozitivului de atac (care este un software special conceput) împreună într-o manieră coordonată. Cel mai memorabil exemplu în acest sens este LOIC creat de grupul Anonymous (derivat din acronimul „Low Orbit Ion Cannon”), care a lansat un atac asupra Bisericii Scientologiei, RIAA (American Publishers Association) și organizațiilor care atacă Wikileaks.

În continuare, vom vorbi despre serviciile de rețea și de ce acestea pot deveni indisponibile. Acest lucru se poate datora, printre altele, faptului că solicitările trimise prin rețea nu ajung la server sau nu pot fi procesate de server. Cauzele pot include lățimea de bandă, un dispozitiv de rețea intermediar sau supraîncărcarea intermitentă a serverului sau blocarea și oprirea unor programe (server web, manager de baze de date, aplicație web) care rulează pe server. Procesăm natura atacurilor în ordinea corespunzătoare. Pentru a nu rămâne doar la nivelul explicației teoretice, pentru fiecare subiect am descris instrumente cu ajutorul cărora cititorul poate testa rezistența propriei aplicații și a infrastructurii la atacurile DoS și DDoS.

Atacul la nivelul rețelei este posibil prin faptul că cea mai utilizată în prezent combinația de protocol de rețea, TCP/IP, se bazează pe construirea unui fel de canal de comunicație (socket TCP) între server și client. Procedând astfel, așa-numitul. Strângere de mână TCP cu 3 căi are loc. Dar ce se întâmplă dacă clientul nu trimite niciodată pachetul TCP în al treilea pas? Resursele (memoria, timpul procesorului) sunt alocate socketului creat atât pe server, cât și pe unele dintre dispozitivele de rețea intermediare. Acestea sunt eliberate numai când expiră expirarea setată și serverul eliberează resurse. La nivel de infrastructură, acesta arată astfel: infrastructura Internetului este situată între clienți (de exemplu atacatori) și server, routerul (routerele) ISP care furnizează adresa IP a serverului și compania sau organizația care operează serverul într-un mod bun în cazul în care operează, de asemenea, un firewall, IDS și, eventual, IPS. Oricare dintre acestea poate fi afectat de un refuz de serviciu și poate deveni un blocaj.

refuz

Un program numit hping3, care în practică poate fi limitat doar de lățimea de bandă atunci când este apelat cu parametrizarea adecvată (–flood). O modalitate evidentă de a vă proteja este de a crește resursele disponibile sau de a reduce latența pentru conexiunile TCP semi-deschise. Dispozitivele de rețea moderne fac acest lucru posibil. Se poate vedea că cu această metodă putem crește necesarul de resurse al atacului, dar nu realizăm o schimbare de amploare. O schimbare de amploare necesită o soluție mai îndrăzneață, pe care o voi acoperi spre sfârșitul articolului. Blocarea adreselor sursă împotriva atacatorilor inteligenți nu este o soluție bună în practică, deoarece adresa IP sursă din pachetele IP poate fi falsificată. Un atacator ar putea exploata acest lucru în scopul său inițial, deoarece dacă adresa sursă este falsificată în mod constant la un anumit IP sau interval de adrese, va fi interzisă. Respectivul hping3 poate falsifica și o adresă sursă, dar este bine de știut că routerele mai inteligente nu vor permite pachetele IP de ieșire care nu provin din intervalul corespunzător adresei sursă din pachetul IP.

Mai jos sunt descrise două opțiuni mai complicate, care încearcă să profite de erorile care pot apărea la procesarea cererilor HTTP. Ambele trucuri au ca scop să încerce să prelungească procesarea unei cereri HTTP cât mai mult posibil. Fiecare solicitare HTTP conține un antet, care poate conține informații și specificații legate de procesarea acesteia, în plus, solicitările POST conțin și date într-un format specific, care trebuie procesate de server pentru a servi cererea.

Prelungirea trimiterii antetului HTTP face ca serverul web să aștepte mult timp pentru un instrument numit Slowloris (http://ha.ckers.org/slowloris/), care este un program scris în perl. Scopul trucului este să faci cereri HTTP neterminate către server, trimitând din când în când un alt fragment din antet, astfel încât să nu rămână răbdarea suficient de rapidă. Dacă ar fi să testăm acest tip de atac, este de remarcat faptul că diferite implementări ale serverului web pot procesa cereri HTTP diferite în mod diferit. De exemplu, înainte ca o solicitare GET să fie finalizată, un anumit tip de server web poate să nu aloce efectiv resursele alocate pentru a servi acea solicitare. În schimb, dacă, de exemplu, solicitările POST sunt tratate diferit, resursele pot fi epuizate. Unelte similare sunt PyLoris, QSlowloris și slowhttptest.

Un instrument numit RUDY (r-u-dead-yet) (http://www.hybridsec.com/tools/rudy/) este de fapt un program scris în python. Solicitările HTTP POST trimit porțiunea de conținut încet, bucată cu bucată, către server, determinându-l să aștepte. Instrumentul poate fi parametrizat din linia de comandă și din fișierul de configurare, ceea ce face chiar mai convenabil recunoașterea parametrilor POST prin introducerea unei adrese URL și selectarea pe care să o încercați dintr-un meniu.

Aplicațiile web în sine pot fi vulnerabile la atacurile DoS dacă acceptă funcții care pot pune o sarcină semnificativă pe sistemele back-end. De exemplu, vă puteți gândi la interogări complexe sau procesare intensivă I/O de stocare. Dacă un atacator poate identifica o astfel de caracteristică, poate provoca cu ușurință probleme grave operatorilor de server. În unele aplicații, înregistrarea necorespunzătoare poate cauza probleme utilizatorilor serviciului. De exemplu, dacă fișierele jurnal se află pe serverul de aplicații și pool-ul de stocare devine plin, sistemul de operare care rulează aplicația poate deveni permanent inoperabil. Această problemă poate părea banală la început, dar pe baza experienței practice, aplicațiile web care rulează live de mult timp pot conține, de asemenea, astfel de erori. Apache JMeter este excelent pentru testarea unor astfel de probleme.

După probleme, să ne ocupăm, de asemenea, pe scurt de opțiunile de apărare. În teorie, nu există o apărare perfectă, deoarece în practică putem crește doar cerințele de resurse pentru ca atacatorul să atace cu succes. Dispozitivele de rețea moderne pot include protecție împotriva DoS, de exemplu, o strângere de mână TCP cu 3 căi poate fi gestionată de un router: de exemplu, conexiunile TCP întredeschise nu sunt încă redirecționate către serverul real. Când vă gândiți la asta, este ușor să vedeți că atacul obligă resursele pe dispozitivul defensiv, astfel încât resursele cheltuite pentru apărare pot fi, de asemenea, epuizate. Protecția bazată pe blocarea IP sursă deja menționată poate fi găsită și în multe firewall-uri, în practică caz ​​în care adresele IP suspecte pot fi blocate pentru o perioadă scurtă de timp. Aici problema poate fi legată de detectarea activității suspecte și de momentul interzicerii. În practică, dispozitivele cu adrese IP care desfășoară activități normale pot fi, de asemenea, interzise dacă încearcă să se conecteze la server „de prea multe ori” la un anumit interval de timp. Din acest motiv, interdicția este de obicei utilizată pentru o perioadă scurtă de timp. În acest caz, putem lua în considerare considerațiile atacatorului: într-un interval de timp, lansează doar un IP sursă care nu declanșează încă interdicția și crește numărul de IP-uri sursă până când atacul are succes.

Pentru soluția inovatoare deja citată, imaginați-vă că un atacator nu numai că poate utiliza mai multe adrese IP sursă, dar putem face și apărarea distribuită. Dacă traficul de la clienți este direcționat printr-un „nor” al unui număr mare de dispozitive de rețea speciale, iar elementele cloud-ului sunt capabile individual să detecteze și să se apere împotriva atacurilor, sarcina atacatorului poate fi îngreunată. Astfel, un atacator ar trebui să oprească întregul nor în loc de un număr mic de routere, firewall-uri și servere pentru ca atacul să aibă succes. O astfel de infrastructură nu este evident utilă pentru toate companiile, dar există furnizori de servicii (Verizon - Terremark, Verisign, CloudFlare, Incapsula) care pot oferi o astfel de protecție.

În cele din urmă, aș dori să vorbesc despre propria mea experiență cu testarea vulnerabilității DoS. Infrastructura oricărui furnizor de cloud poate fi acum utilizată ca o soluție evidentă pentru modelarea unui număr mare de atacatori. Personal, am experiență practică cu serviciul cloud Amazon EC2. Aici, după introducerea unui număr de înregistrare și a unui card de credit, putem simula botnet-urile atacatorilor cu 20 de mașini virtuale (140 gazde în total) pe regiune în 7 regiuni (europene, 3 nord-americane, sud-americane, două asiatice). Desigur, trebuie remarcat faptul că în regiunile îndepărtate, lățimea de bandă poate fi mai mică, iar latența rețelei poate fi mai mare, dar experiența a arătat că simularea atacurilor pe scară largă poate fi rezolvată de ceva timp și în detrimentul a câteva sute de dolari. .