Când vine vorba de DNS, Cricket Liu a scris literalmente cartea. El a fost coautor al tuturor celor cinci ediții ale cărții „DNS și BIND” de la O’Reilly, care este în general considerată ca fiind ghidul definitiv pentru tot ceea ce ține de sistemul de nume de domeniu. Cricket este în prezent ofițer șef de infrastructură la Infoblox.
DNS este în mod clar o componentă critică a rețelelor de calculatoare, dar există momente în care aceste instrumente pot fi folosite în scopuri necorespunzătoare. În cadrul Forumului New Tech din această săptămână, Cricket analizează problema tot mai mare a atacurilor DDoS bazate pe DNS și cum să le facem față. — Paul Venezia
Atacuri DDoS bazate pe DNS: Cum funcționează și cum să le oprim
Atacurile DDoS (distributed denial-of-service attack) bazate pe DNS au devenit unul dintre cele mai frecvente atacuri distructive de pe internet. Dar cum funcționează acestea? Și ce putem face pentru a ne apăra împotriva lor?
În acest articol, voi descrie modul în care atacurile DDoS exploatează și vizează infrastructura DNS. De asemenea, vă voi arăta ce puteți face pentru a vă proteja pe dvs. și pe alții.
Marele spoof
Generarea unui atac DDoS folosind infrastructura DNS este remarcabil de simplă: Atacatorii trimit interogări către serverele de nume de pe internet, iar aceste servere de nume trimit răspunsuri. Totuși, în loc să trimită interogările de la propriile adrese IP, atacatorii falsifică adresa țintei lor – care ar putea fi un server web, un router, un alt server de nume sau aproape orice nod de pe internet.
Falsificarea interogărilor DNS este deosebit de ușoară deoarece acestea sunt de obicei transmise prin UDP (protocolul fără conexiune User Datagram Protocol). Trimiterea unei interogări DNS de la o adresă IP arbitrară este la fel de simplă și are aproximativ același efect ca și cum ai scrie adresa de retur a altcuiva pe o carte poștală.
Falsificarea interogărilor nu este, totuși, suficientă pentru a incapacita o țintă. Dacă răspunsurile la aceste interogări nu sunt mai mari decât interogările însele, un atacator ar face la fel de bine să inunde ținta cu interogări falsificate. Nu, pentru a maximiza daunele aduse țintei, fiecare interogare ar trebui să returneze un răspuns foarte mare. Se pare că acest lucru este foarte ușor de instigat.
De la apariția EDNS0, un set de extensii la DNS introduse în 1999, mesajele DNS bazate pe UDP au putut transporta o mulțime de date. Un răspuns poate avea o dimensiune de până la 4.096 de octeți. Cele mai multe interogări, pe de altă parte, au o lungime mai mică de 100 de octeți.
Cândva, era relativ dificil să găsești un răspuns atât de mare în spațiul de nume al internetului. Dar acum că organizațiile au început să implementeze DNSSEC, extensiile de securitate DNS, este mult mai ușor. DNSSEC stochează chei criptografice și semnături digitale în înregistrările din spațiul de nume. Acestea sunt în mod pozitiv enorme.
Puteți vedea un exemplu de răspuns din zona isc.org care conține înregistrări DNSSEC pe blogul meu. Dimensiunea răspunsului este de 4.077 de octeți, în comparație cu o interogare de doar 44 de octeți.
Acum, imaginați-vă atacatori de pe tot internetul trimițând acea interogare falsificată de la adresa IP a serverului dvs. web către serverele de nume isc.org. Pentru fiecare interogare de 44 de octeți, serverul dvs. web primește un răspuns de 4.077 de octeți, pentru un factor de amplificare de aproape 93 de ori.
Să facem un calcul rapid pentru a ne da seama cât de grav ar putea deveni acest lucru. Să spunem că fiecare atacator are o conexiune relativ modestă de 1Mbps la internet. El poate trimite aproximativ 2.840 de interogări de 44 de octeți prin această legătură pe secundă. Acest flux de interogări ar avea ca rezultat răspunsuri în valoare de aproape 93Mbps care ajung la serverul dvs. web. Fiecare 11 atacatori reprezintă 1Gbps.
De unde ar putea atacatorii antisociali să găsească 10 prieteni care să îi ajute să efectueze un atac? De fapt, ei nu au nevoie de niciunul. Ei vor folosi un botnet de mii de calculatoare.
Efectul final este devastator. În raportul său trimestrial privind atacurile DDoS globale, Prolexic (o companie de atenuare a atacurilor DDoS) a raportat un atac recent împotriva unui client, bazat pe DNS, care a depășit 167 Gbps. Prolexic a mai raportat că lățimea de bandă medie a atacurilor DDoS a crescut cu 718%, ajungând la 48Gbps într-un singur trimestru.
Dar așteptați! Nu ar putea serverele de nume isc.org să fie modificate pentru a recunoaște că sunt interogate iar și iar pentru aceleași date, de la aceeași adresă IP? Nu ar putea ele să înăbușe atacul?
Cert este că pot. Dar serverele de nume isc.org nu sunt singurele pe care un atacator le poate folosi pentru a-și amplifica traficul. Sigur, există și alte servere de nume autoritare pe care atacatorul le-ar putea folosi, dar și mai rău sunt serverele de nume recursive deschise.
Un server de nume recursiv deschis este pur și simplu un server de nume care va procesa interogări recursive de la orice adresă IP. Eu îi pot trimite acea interogare pentru datele isc.org și îmi va răspunde, iar dumneavoastră puteți face același lucru.
Nu ar trebui să existe multe servere de nume recursive deschise pe internet. Funcția unui server de nume recursiv este de a căuta date în spațiul de nume al internetului în numele clienților DNS, cum ar fi cei de pe laptopul sau smartphone-ul dumneavoastră. Administratorii de rețea care configurează serverele de nume recursive (cum ar fi departamentul IT) le folosesc de obicei pentru a fi utilizate de o anumită comunitate (de exemplu, dumneavoastră și colegii dumneavoastră de serviciu). Cu excepția cazului în care rulează servicii cum ar fi OpenDNS sau Google Public DNS, ei nu intenționează ca acestea să fie folosite de cetățenii din Moldova. Așadar, administratorii cu spirit public, preocupați de securitate și, mai ales, competenți, configurează controale de acces pe serverele lor de nume recursive pentru a limita utilizarea lor la sistemele autorizate.
Din acest motiv, cât de mare ar putea fi o problemă a serverelor de nume recursive deschise? Destul de mare. Proiectul Open Resolver a colectat o listă de 33 de milioane de servere de nume recursive deschise. Hackerii pot lansa interogări falsificate către cât de multe dintre acestea doresc pentru a arunca date isc.org către serverul dvs. web, serverul de nume sau routerul de frontieră până când acesta se sufocă.
Așa funcționează atacurile DDoS bazate pe DNS. Din fericire, avem câteva modalități de a le combate.
Cum să rezistați furtunii
Primul ordin de zi este instrumentarea infrastructurii DNS, astfel încât să știți când sunteți atacat. Prea multe organizații nu au nici o idee despre încărcătura lor de interogare, astfel încât nu vor ști niciodată dacă sunt atacate în primul rând.
Determinarea încărcăturii de interogare poate fi la fel de simplă ca și utilizarea suportului statistic încorporat al BIND. Serverul de nume BIND va descărca date în fișierul său de statistici atunci când rulați rndc stats, de exemplu, sau la un interval de statistici configurabil. Puteți examina statisticile pentru rata de interogare, erori de socket și alte indicii ale unui atac. Nu vă faceți griji dacă nu sunteți sigur cum va arăta încă un atac – o parte din scopul monitorizării DNS este de a stabili o linie de bază, astfel încât să puteți identifica ceea ce este anormal.
În continuare, aruncați o privire la infrastructura dvs. care se confruntă cu Internetul. Nu vă limitați la serverele de nume autoritare externe; examinați infrastructura de switch-uri și routere, firewall-urile și conexiunile dvs. la Internet. Identificați orice punct unic de eșec. Determinați dacă le puteți elimina cu ușurință (și în mod eficient din punct de vedere al costurilor).
Dacă este posibil, luați în considerare o distribuție geografică largă a serverelor dvs. de nume autoritare externe. Acest lucru ajută la evitarea punctelor unice de eșec, bineînțeles, dar ajută și atunci când nu sunteți atacat. Un server de nume recursiv care rezolvă un nume de domeniu într-una din zonele dvs. va încerca să interogheze serverul de nume autoritar cel mai apropiat de acesta, astfel încât distribuția geografică va tinde să ofere o performanță mai bună clienților și corespondenților dvs. Dacă clienții dvs. sunt grupați în anumite zone geografice, încercați să plasați un server de nume autoritar în apropierea acestora pentru a oferi cele mai rapide răspunsuri.
Poate cea mai elementară modalitate de a combate atacurile DoS este să vă supraaprovizionați infrastructura. Vestea bună este că supraaprovizionarea serverelor dvs. de nume nu este neapărat costisitoare; un server de nume capabil poate gestiona zeci sau chiar sute de mii de interogări pe secundă. Nu sunteți sigur care este capacitatea serverelor dvs. de nume? Ați putea folosi instrumente de interogare precum dnsperf pentru a testa performanța serverelor dvs. de nume – de preferință folosind o platformă de testare similară cu serverele dvs. de nume de producție într-un laborator, mai degrabă decât serverele de producție propriu-zise.
Decizia de a decide cât de mult să vă supraaprovizionați serverele de nume este subiectivă: Care este valoarea prezenței dumneavoastră online? Există alte componente ale infrastructurii dvs. orientate spre Internet care vor ceda înaintea serverelor de nume? Evident, este nesăbuit să cheltuiți bani pentru a construi o infrastructură DNS de primă clasă în spatele unui router de frontieră sau firewall care va ceda cu mult înainte ca serverele dvs. de nume să transpire.
Dacă banii nu sunt o problemă, ar putea fi util să știți că atacurile DDoS de ultimă generație împotriva infrastructurii DNS pot depăși 100Gbps.
Utilizarea Anycast poate ajuta, de asemenea, la rezistența la un atac DDoS. Anycast este o tehnică care permite mai multor servere să împartă o singură adresă IP și funcționează deosebit de bine cu DNS. De fapt, serverele de nume rădăcină ale internetului folosesc Anycast de ani de zile pentru a furniza date de zonă rădăcină pe tot globul, permițând în același timp ca lista rădăcinilor să încapă într-un singur mesaj DNS bazat pe UDP.
Pentru a implementa Anycast, gazdele care susțin serverele dvs. de nume vor trebui să ruleze un protocol de rutare dinamic, cum ar fi OSPF sau BGP. Procesul de rutare va anunța către routerele sale vecine o rută către o nouă adresă IP virtuală pe care serverul dvs. de nume ascultă. De asemenea, procesul de rutare trebuie să fie suficient de inteligent pentru a nu mai anunța această rută în cazul în care serverul de nume local nu mai răspunde. Puteți lipi demonul de rutare de starea de sănătate a serverului de nume folosind un cod de construcție proprie – sau puteți cumpăra un produs care să se ocupe de acest lucru pentru dumneavoastră. NIOS de la Infoblox, nu întâmplător, include suport Anycast.
Cum se apără Anycast împotriva atacurilor DDoS? Ei bine, să spunem că aveți șase servere de nume externe în două grupuri Anycast (adică trei care împart o adresă IP Anycast și trei care împart alta). Fiecare grup conține un membru în Statele Unite, unul în Europa și unul în Asia. O gazdă care organizează un atac DDoS împotriva dvs. poate trimite trafic numai către – și, prin urmare, poate ataca numai un singur membru al oricăruia dintre aceste grupuri din orice punct al internetului la un moment dat. Cu excepția cazului în care atacatorii pot proveni suficient de mult trafic din America de Nord, Europa și Asia simultan pentru a vă inunda infrastructura, nu vor reuși.
În cele din urmă, există o modalitate prin care puteți profita de distribuția geografică largă și de Anycast în același timp, fără cheltuieli de capital semnificative: Utilizați un furnizor DNS bazat pe cloud. Companii precum Dyn și Neustar rulează servere de nume Anycast proprii în centre de date din întreaga lume. Le plătiți pentru a vă găzdui zonele și pentru a răspunde la interogările pentru datele dumneavoastră. Și puteți continua să păstrați controlul direct asupra datelor din zonele dumneavoastră, solicitând unui furnizor să își configureze serverele de nume ca secundare pentru zonele dumneavoastră, încărcând datele de la un server de nume principal pe care îl desemnați și îl gestionați intern. Asigurați-vă doar că rulați serverul principal ascuns (adică fără nicio înregistrare NS care să arate spre el), altfel riscați ca un atacator să îl vizeze ca punct unic de eșec.
Un singur cuvânt de precauție atunci când folosiți furnizori DNS în cloud: Cei mai mulți vă facturează cel puțin parțial pe baza numărului de interogări pe care le primesc serverele lor de nume pentru datele din zonele dumneavoastră. Într-un atac DDoS, aceste interogări ar putea crește dramatic (complet în afara controlului dvs. și deloc în beneficiul dvs.), așa că asigurați-vă că au o prevedere pentru a face față atacurilor DDoS fără a vă transfera costul traficului.
Cum să evitați să deveniți complice la atacurile DDoS
Acum știți cum să vă configurați infrastructura DNS pentru a rezista unui atac DDoS. Este aproape la fel de important, însă, să vă asigurați că nu sunteți complice la un atac DDoS împotriva altcuiva.
Îți amintești descrierea modului în care serverele DNS pot amplifica traficul? Atacatorii pot folosi atât serverele de nume recursive deschise, cât și serverele de nume autoritare ca amplificatori, trimițând interogări falsificate care determină serverele de nume să trimită răspunsuri de peste 100 de ori mai mari decât interogarea către ținte arbitrare de pe internet. Bineînțeles că nu vreți să fiți ținta unui astfel de atac, dar nici nu vreți să fiți complice. Atacul folosește resursele serverelor dvs. de nume, precum și lățimea de bandă. Dacă ținta ia măsuri pentru a bloca traficul dinspre serverul dvs. de nume către rețeaua sa, atunci, după ce atacul se termină, este posibil ca ținta să nu poată rezolva numele de domenii din zonele dvs.
Dacă folosiți un server de nume recursiv deschis, soluția este simplă: Nu o faceți. Există foarte puține organizații care au vreo justificare pentru a rula un server de nume deschis la interogări recursive. Google Public DNS și OpenDNS sunt două care îmi vin în minte, dar dacă citiți aceste rânduri, bănuiesc că probabil nu sunteți ei. Restul dintre noi ar trebui să aplicăm controale de acces la serverele noastre de nume recursive pentru a ne asigura că doar interogatorii autorizați le folosesc. Acest lucru înseamnă, probabil, să limităm interogările DNS la adresele IP din rețelele noastre interne, ceea ce este ușor de făcut pe orice implementare de server de nume care merită. (Serverul Microsoft DNS nu acceptă controale de acces bazate pe adrese IP pentru interogări. Citiți ce vreți în asta.)
Dar ce se întâmplă dacă executați un server de nume autoritar? Evident, nu puteți limita adresele IP de la care veți accepta interogări – sau nu foarte mult, oricum (ați putea refuza interogări de la adrese IP evident false, cum ar fi adresele RFC 1918). Dar puteți limita răspunsurile.
Două „pălării albe” de lungă durată de pe internet, Paul Vixie și Vernon Schryver, au realizat că atacurile DDoS care folosesc serverele de nume autoritare pentru amplificare prezintă anumite modele de interogare. În special, atacatorii trimit serverelor de nume aceeași interogare de la aceeași adresă IP falsificată (sau bloc de adrese) la nesfârșit, căutând o amplificare maximă. Niciun server de nume recursiv bine comportat nu ar face acest lucru. Acesta ar fi pus în cache răspunsul și nu ar fi întrebat din nou până la expirarea timpului de viață al înregistrărilor din răspuns.
Vixie și Schryver au venit cu un mecanism inteligent, numit Limitarea ratei de răspuns (Response Rate Limiting – RRL), care permite unui server de nume autoritar să urmărească de câte ori a trimis același răspuns aceluiași interogator. În cazul în care această rată depășește un anumit prag configurabil, serverul de nume va înceta să mai trimită acel răspuns către interogator pentru o perioadă determinată. În cazul în care interogatorul încetează să mai adreseze aceeași întrebare serverului de nume care face autoritate, serverul de nume care face autoritate va înceta să mai respingă acel răspuns. Rezultatul este că serverul de nume autoritar nu va trimite niciodată vreun răspuns la un interogator cu o rată mai mare decât pragul, ceea ce îl face inutil în cazul unui atac DDoS.
RRL a fost încorporat în serverele de nume BIND în versiunea 9.9.4, iar alte câteva implementări de servere de nume îl acceptă acum, inclusiv NSD și Knot. Pe măsură ce oamenii își actualizează serverele de nume la versiuni mai noi sau la noi implementări care acceptă RRL, acest lucru ar trebui să îngreuneze treptat dificultatea atacatorilor de a folosi infrastructura DNS ca amplificator.
Sper că această discuție v-a ajutat să înțelegeți modul în care infrastructura DNS este vizată și exploatată în atacurile DDoS și cum puteți rezista cel mai bine atacurilor DDoS și să vă asigurați că serverele dvs. de nume nu participă, fără să știți, la unul dintre ele.
New Tech Forum oferă un mijloc de a explora și de a discuta despre tehnologia emergentă a întreprinderilor într-o profunzime și o amploare fără precedent. Selecția este subiectivă, bazată pe alegerea noastră a tehnologiilor pe care le considerăm importante și de cel mai mare interes pentru cititorii InfoWorld. InfoWorld nu acceptă materiale de marketing pentru publicare și își rezervă dreptul de a edita toate contribuțiile de conținut. Trimiteți toate solicitările la [email protected].
Acest articol, „Ghidul suprem pentru prevenirea atacurilor DDoS bazate pe DNS”, a fost publicat inițial la InfoWorld.com. Pentru cele mai recente știri despre tehnologia de afaceri, urmăriți InfoWorld.com pe Twitter.
.