Når det drejer sig om DNS, har Cricket Liu bogstaveligt talt skrevet bogen. Han har været medforfatter til alle fem udgaver af O’Reillys bog “DNS and BIND”, som generelt betragtes som den definitive guide om alt, hvad der har med domænenavnsystemet at gøre. Cricket er i øjeblikket chef for infrastrukturen hos Infoblox.
DNS er helt klart en vigtig komponent i computernetværk, men der er tidspunkter, hvor disse værktøjer kan bruges til at begå ulovligheder. I denne uges New Tech Forum tager Cricket et kig på det voksende problem med DNS-baserede DDoS-angreb, og hvordan man håndterer dem. — Paul Venezia
DNS-baserede DDoS-angreb: Hvordan de virker, og hvordan man stopper dem
DNS-baserede DDoS-angreb (distributed denial-of-service attack) er blevet et af de mest almindelige destruktive angreb på internettet. Men hvordan virker de? Og hvad kan vi gøre for at forsvare os mod dem?
I denne artikel vil jeg beskrive, hvordan DDoS-angreb både udnytter og er rettet mod DNS-infrastrukturen. Jeg viser dig også, hvad du kan gøre for at beskytte dig selv og andre.
Den store spoof
Det er bemærkelsesværdigt enkelt at generere et DDoS-angreb ved hjælp af DNS-infrastruktur: Angriberne sender forespørgsler til navneservere på hele internettet, og disse navneservere returnerer svar. I stedet for at sende forespørgslerne fra deres egne IP-adresser forfalsker angriberne imidlertid adressen på deres mål – som kan være en webserver, en router, en anden navneserver eller næsten enhver anden knude på internettet.
Det er særlig nemt at forfalske DNS-forespørgsler, fordi de normalt sendes via UDP (den forbindelsesløse User Datagram Protocol). At sende en DNS-forespørgsel fra en vilkårlig IP-adresse er omtrent lige så enkelt og har nogenlunde samme effekt som at skrive en andens afsenderadresse på et postkort.
Spoofing af forespørgsler er dog ikke nok til at sætte et mål ud af spillet. Hvis svarene på disse forespørgsler ikke var større end selve forespørgslerne, ville en angriber gøre lige så godt i at oversvømme målet med spoofede forespørgsler. Nej, for at maksimere skaden på målet skal hver forespørgsel returnere et meget stort svar. Det viser sig, at det er meget let at iværksætte.
Siden fremkomsten af EDNS0, et sæt udvidelser til DNS, der blev indført tilbage i 1999, har UDP-baserede DNS-meddelelser kunnet transportere masser af data. Et svar kan være så stort som 4.096 bytes. De fleste forespørgsler er derimod mindre end 100 bytes lange.
Engang var det relativt svært at finde et så stort svar i internettets navnerum. Men nu, hvor organisationer er begyndt at implementere DNSSEC, DNS Security Extensions, er det meget nemmere. DNSSEC gemmer kryptografiske nøgler og digitale signaturer i poster i navnerummet. Disse er positivt enormt store.
Du kan se et eksempel på et svar fra isc.org-zonen, der indeholder DNSSEC-poster, på min blog. Svaret er på 4.077 bytes, sammenlignet med en forespørgsel på kun 44 bytes.
Forestil dig nu angribere fra hele internettet, der sender denne spoofede forespørgsel fra din webservers IP-adresse til isc.org-navneserverne. For hver forespørgsel på 44 byte modtager din webserver et svar på 4.077 byte, hvilket giver en forstærkningsfaktor på næsten 93 gange.
Lad os lave en hurtig beregning for at finde ud af, hvor slemt det kan blive. Lad os sige, at hver angriber har en relativt beskeden 1 Mbps-forbindelse til internettet. Han kan sende ca. 2.840 44-byte forespørgsler over denne forbindelse i sekundet. Denne forespørgselsstrøm vil resultere i næsten 93 Mbps svar, der når frem til din webserver. Hver 11 angribere repræsenterer 1 Gbps.
Hvor ville antisociale angribere finde 10 venner til at hjælpe dem med at udføre et angreb? Faktisk har de ikke brug for nogen. De bruger et botnet bestående af tusindvis af computere.
Den endelige effekt er ødelæggende. I sin kvartalsvise globale rapport om DDoS-angreb rapporterede Prolexic (et DDoS-afværgefirma) om et nyligt DNS-baseret angreb mod en kunde, som nåede op på 167 Gbps. Prolexic rapporterede endvidere, at den gennemsnitlige båndbredde for DDoS-angreb var steget med 718 procent til 48 Gbps i et enkelt kvartal.
Men vent! Kunne man ikke ændre isc.org-navneserverne til at erkende, at de bliver spurgt igen og igen efter de samme data fra den samme IP-adresse? Kunne de ikke afværge angrebet?
Det kan de helt sikkert. Men isc.org-navneserverne er ikke de eneste, som en angriber kan bruge til at forstærke sin trafik. Selvfølgelig er der andre autoritative navneservere, som angriberen kan bruge, men endnu værre er åbne rekursive navneservere.
En åben rekursiv navneserver er simpelthen en navneserver, der behandler rekursive forespørgsler fra en hvilken som helst IP-adresse. Jeg kan sende den denne forespørgsel efter isc.org-data til den, og den vil svare mig, og du kan gøre det samme.
Der burde ikke være mange åbne rekursive navneservere på internettet. En rekursiv navneserver har til opgave at slå data op i internettets navnerum på vegne af DNS-klienter, som f.eks. dem på din bærbare computer eller smartphone. De netværksadministratorer, der opretter rekursive navneservere (f.eks. din it-afdeling), har normalt til hensigt, at de skal bruges af et bestemt fællesskab (f.eks. dig og dine kolleger). Medmindre de kører tjenester som OpenDNS eller Google Public DNS, er det ikke deres hensigt, at de skal bruges af borgerne i Moldova. Så offentligt indstillede, sikkerhedsbevidste og især kompetente administratorer konfigurerer adgangskontrol på deres rekursive navneservere for at begrænse brugen af dem til autoriserede systemer.
Hvor stort et problem kan åbne rekursive navneservere være i betragtning heraf? Ret stort. Open Resolver Project har samlet en liste over 33 millioner åbne rekursive navneservere. Hackere kan sende spoofede forespørgsler til så mange af disse, som de vil, for at spytte isc.org-data ud til din webserver, navneserver eller grænserouter, indtil den kvæles.
Det er sådan, DNS-baserede DDoS-angreb fungerer. Heldigvis har vi et par måder at bekæmpe dem på.
Sådan klarer du stormen
Den første opgave er at instrumentere din DNS-infrastruktur, så du ved, hvornår du er under angreb. Alt for mange organisationer har ingen idé om, hvad deres forespørgselsbelastning er, så de ville aldrig vide, om de overhovedet blev angrebet.
Det kan være så enkelt som at bruge BIND’s indbyggede statistikunderstøttelse til at bestemme din forespørgselsbelastning. BIND-navneserveren vil dumpe data til sin statistikfil, når du f.eks. kører rndc stats, eller ved et konfigurerbart statistikinterval. Du kan undersøge statistikkerne for forespørgselshastighed, socketfejl og andre indikationer på et angreb. Du skal ikke bekymre dig, hvis du ikke er sikker på, hvordan et angreb ser ud endnu – en del af målet med at overvåge DNS er at etablere en baseline, så du kan identificere, hvad der er unormalt.
Næst skal du kigge på din internetvendte infrastruktur. Begræns dig ikke til dine eksterne autoritative navneservere, men undersøg også din switch- og routerinfrastruktur, dine firewalls og dine forbindelser til internettet. Identificer eventuelle single points of failure. Bestem, om du nemt (og omkostningseffektivt) kan fjerne dem.
Hvis det er muligt, skal du overveje en bred geografisk fordeling af dine eksterne autoritative navneservere. Dette hjælper naturligvis med at undgå enkeltstående fejlpunkter, men det hjælper også, når du ikke er under angreb. En rekursiv navneserver, der løser et domænenavn i en af dine zoner, vil forsøge at forespørge den autoritative navneserver, der ligger tættest på den, så geografisk fordeling har tendens til at give bedre ydeevne for dine kunder og korrespondenter. Hvis dine kunder er samlet i bestemte geografiske områder, skal du forsøge at placere en autoritativ navneserver i nærheden af dem for at give de hurtigste svar.
Den mest grundlæggende måde at bekæmpe DoS-angreb på er måske at overprovisionere din infrastruktur. Den gode nyhed er, at det ikke nødvendigvis er dyrt at overprovisionere dine navneservere; en dygtig navneserver kan håndtere titusindvis eller endog hundredtusindvis af forespørgsler i sekundet. Er du ikke sikker på, hvilken kapacitet dine navneservere har? Du kan bruge forespørgselsværktøjer som f.eks. dnsperf til at teste dine navneserveres ydeevne – helst ved hjælp af en testplatform, der ligner dine produktionsnavneservere i et laboratorium, i stedet for selve produktionsserverne.
Det er subjektivt at beslutte, hvor meget du skal overprovisionere dine navneservere: Hvad er din online-tilstedeværelse værd? Er der andre komponenter i din internetvendte infrastruktur, der vil fejle før navneserverne? Det er naturligvis dumdristigt at bruge penge på at opbygge en førsteklasses DNS-infrastruktur bag en grænse-router eller firewall, der vil fejle, længe før dine navneservere overhovedet får sved på panden.
Hvis penge ikke er noget problem, kan det være nyttigt at vide, at moderne DDoS-angreb mod DNS-infrastruktur kan overstige 100 Gbps.
Anvendelse af Anycast kan også hjælpe med at modstå et DDoS-angreb. Anycast er en teknik, der gør det muligt for flere servere at dele en enkelt IP-adresse, og den fungerer særligt godt med DNS. Faktisk har internettets rodnavneservere i årevis brugt Anycast til at levere rodzonedata i hele verden, samtidig med at listen over rødder stadig passer ind i en enkelt UDP-baseret DNS-meddelelse.
For at implementere Anycast skal de værter, der understøtter dine navneservere, køre en dynamisk routingprotokol, f.eks. OSPF eller BGP. Routingprocessen annoncerer en rute til sine naboroutere til en ny, virtuel IP-adresse, som din navneserver lytter på. Routingprocessen skal også være intelligent nok til at stoppe med at annoncere denne rute, hvis den lokale navneserver holder op med at svare. Du kan lime din routing-dæmon til navneserverens tilstand ved hjælp af kode af din egen konstruktion — eller du kan købe et produkt, der tager sig af det for dig. Infoblox’ NIOS indeholder, ikke tilfældigvis, Anycast-understøttelse.
Hvordan forsvarer Anycast sig mod DDoS-angreb? Jo, lad os sige, at du har seks eksterne navneservere i to Anycast-grupper (dvs. at tre deler én Anycast-IP-adresse og tre deler en anden). Hver gruppe indeholder et medlem i USA, et i Europa og et i Asien. En vært, der iværksætter et DDoS-angreb mod dig, kan kun sende trafik til – og dermed kun angribe – ét medlem af en af grupperne fra et hvilket som helst sted på internettet på et tidspunkt. Medmindre angriberne kan skaffe nok trafik fra Nordamerika, Europa og Asien på samme tid til at oversvømme din infrastruktur, vil det ikke lykkes.
Endeligt er der en måde, hvorpå du kan drage fordel af en bred geografisk fordeling og Anycast på samme tid, uden at det kræver store investeringer: Brug en cloud-baseret DNS-udbyder. Virksomheder som Dyn og Neustar driver deres egne Anycast-navneservere i datacentre rundt om i verden. Du betaler dem for at være vært for dine zoner og besvare forespørgsler om dine data. Og du kan fortsat bevare den direkte kontrol over dine zonedata ved at bede en udbyder om at konfigurere sine navneservere som sekundære servere for dine zoner og indlæse dataene fra en hovednavneserver, som du selv udpeger og administrerer internt. Du skal blot sikre dig, at du kører master-serveren skjult (dvs. uden NS-rekord, der peger på den), ellers risikerer du, at en angriber vil tage sigte på den som et enkelt fejlpunkt.
Et enkelt advarselssignal, når du bruger cloud-baserede DNS-udbydere: De fleste fakturerer dig i det mindste delvist på grundlag af det antal forespørgsler, som deres navneservere modtager om data i dine zoner. Ved et DDoS-angreb kan disse forespørgsler stige drastisk (helt uden for din kontrol og slet ikke til din fordel), så sørg for, at de har en bestemmelse til at håndtere DDoS-angreb uden at vælte omkostningerne ved trafikken over på dig.
Sådan undgår du at blive medskyldig i DDoS-angreb
Nu ved du, hvordan du kan konfigurere din DNS-infrastruktur til at modstå et DDoS-angreb. Det er dog næsten lige så vigtigt at sikre, at du ikke bliver medskyldig i et DDoS-angreb mod en anden person.
Huskede du beskrivelsen af, hvordan DNS-servere kan forstærke trafikken? Angribere kan bruge både åbne rekursive navneservere og autoritative navneservere som forstærkere og sende spoofede forespørgsler, der får navneserverne til at sende svar, der er mere end 100 gange så store som forespørgslen, til vilkårlige mål på internettet. Nu ønsker du naturligvis ikke at være målet for et sådant angreb, men du ønsker heller ikke at være medskyldig. Angrebet bruger både dine navneserveres ressourcer og din båndbredde. Hvis målet træffer foranstaltninger til at blokere trafikken fra din navneserver til sit netværk, vil målet efter angrebet måske ikke kunne opløse domænenavne i dine zoner.
Hvis du kører en åben rekursiv navneserver, er løsningen enkel: Lad være. Der er meget få organisationer, der har nogen som helst begrundelse for at køre en navneserver, der er åben for rekursive forespørgsler. Google Public DNS og OpenDNS er to af dem, som jeg kommer til at tænke på, men hvis du læser dette, er det nok ikke dem, du er. Resten af os bør anvende adgangskontrol på vores rekursive navneservere for at sikre, at kun autoriserede forespørgere bruger dem. Det betyder sandsynligvis, at vi skal begrænse DNS-forespørgsler til IP-adresser på vores interne netværk, hvilket er let at gøre på enhver navneserverimplementering, der er noget værd. (Microsoft DNS Server understøtter ikke IPadressebaseret adgangskontrol af forespørgsler. Læs hvad du vil i det.)
Men hvad nu hvis du kører en autoritativ navneserver? Du kan naturligvis ikke begrænse de IP-adresser, som du accepterer forespørgsler fra – eller i hvert fald ikke særlig meget (du kan afvise forespørgsler fra tydeligvis falske IP-adresser, f.eks. RFC 1918-adresser). Men du kan begrænse svarene.
To mangeårige internet-“white hats”, Paul Vixie og Vernon Schryver, indså, at DDoS-angreb, der bruger autoritative navneservere til forstærkning, udviser visse forespørgselsmønstre. Navnlig sender angriberne navneservere den samme forespørgsel fra den samme forfalskede IP-adresse (eller adresseblok) igen og igen for at opnå maksimal forstærkning. Ingen velfungerende rekursiv navneserver ville gøre det. Den ville have lagret svaret i cachen og ikke spurgt igen, før den tid, der er gået, før de pågældende poster i svaret har været i live.
Vixie og Schryver fandt på en smart mekanisme, kaldet Response Rate Limiting (RRL), som gør det muligt for en autoritativ navneserver at spore, hvor ofte den har sendt det samme svar til den samme forespørgeren. Hvis denne frekvens overskrider en konfigurerbar tærskel, holder navneserveren op med at sende det pågældende svar til forespørgeren i en bestemt periode. Hvis forespørgeren holder op med at sende det samme spørgsmål til den autoritative navneserver, holder den autoritative navneserver op med at sende dette svar til den autoritative navneserver. Resultatet er, at den autoritative navneserver aldrig vil sende et svar til en forespørger med en hastighed, der er højere end tærsklen, hvilket gør den ubrugelig i et DDoS-angreb.
RRL blev indarbejdet i BIND-navneservere i version 9.9.4, og et par andre navneserverimplementeringer understøtter det nu, herunder NSD og Knot. Efterhånden som folk opgraderer deres navneservere til nyere versioner eller nye implementeringer, der understøtter RRL, skulle dette gradvist gøre det vanskeligere for angribere at bruge DNS-infrastruktur som forstærkere.
Jeg håber, at denne diskussion har hjulpet dig med at forstå, hvordan DNS-infrastrukturen både er målrettet mod og udnyttes i DDoS-angreb, og hvordan du bedst kan modstå DDoS-angreb og sikre, at dine navneservere ikke, uden at du ved det, deltager i et sådant.
New Tech Forum giver dig mulighed for at udforske og diskutere ny virksomhedsteknologi i en hidtil uset dybde og bredde. Udvælgelsen er subjektiv og baseret på vores valg af de teknologier, som vi mener er vigtige og af størst interesse for InfoWorlds læsere. InfoWorld accepterer ikke markedsføringsmateriale til offentliggørelse og forbeholder sig ret til at redigere alt bidraget indhold. Send alle henvendelser til [email protected].
Denne artikel, “Den ultimative guide til forebyggelse af DNS-baserede DDoS-angreb”, blev oprindeligt offentliggjort på InfoWorld.com. Følg InfoWorld.com på Twitter for at få de seneste nyheder om erhvervsteknologi.