Når det kommer til DNS, skrev Cricket Liu bogstaveligt talt bogen. Han har været medforfatter til alle fem udgaver af O'Reillys "DNS and BIND" -bog, som generelt betragtes som den endelige vejledning om alle ting, der vedrører Domain Name System. Cricket er i øjeblikket Chief Infrastructure Officer hos Infoblox.
DNS er helt klart en kritisk komponent i computernetværk, men der er tidspunkter, hvor disse værktøjer kan bruges til fejlbehæftelse. I denne uges New Tech Forum ser Cricket på det voksende problem med DNS-baserede DDoS-angreb, og hvordan man håndterer dem. - Paul Venezia
DNS-baserede DDoS-angreb: Hvordan de fungerer, og hvordan man stopper dem
Det DNS-baserede DDoS (distribueret denial-of-service-angreb) er blevet et af de mest almindelige destruktive angreb på Internettet. Men hvordan fungerer 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 målretter mod DNS-infrastruktur. Jeg viser dig også, hvad du kan gøre for at beskytte dig selv og andre.
Den store spoof
Generering af et DDoS-angreb ved hjælp af DNS-infrastruktur er bemærkelsesværdigt simpelt: Angriberne sender forespørgsler til navneservere over Internettet, og disse navneservere returnerer svar. I stedet for at sende forespørgslerne fra deres egne IP-adresser, falsk angriberne dog adressen på deres mål - som kunne være en webserver, en router, en anden navneserver eller næsten enhver node på Internettet.
Spoofing DNS-forespørgsler er særlig let, fordi de normalt overføres til UDP (den forbindelsesløse User Datagram Protocol). At sende en DNS-forespørgsel fra en vilkårlig IP-adresse er omtrent lige så enkel og har nogenlunde samme effekt som at skrive en andens returadresse på et postkort.
Spoofing-forespørgsler er dog ikke nok til at gøre et mål uarbejdsdygtigt. Hvis svarene på disse forespørgsler ikke var større end selve forespørgslerne, ville en angriber gøre lige så godt for at oversvømme målet med falske 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 igangsætte.
Siden fremkomsten af EDNS0, et sæt udvidelser til DNS, der blev introduceret tilbage i 1999, har UDP-baserede DNS-meddelelser været i stand til at overføre masser af data. Et svar kan være så stort som 4.096 bytes. De fleste forespørgsler er derimod mindre end 100 byte lange.
Engang var det relativt vanskeligt at finde et så stort svar i Internets navneområde. Men nu hvor organisationer er begyndt at implementere DNSSEC, DNS Security Extensions, er det meget lettere. DNSSEC gemmer kryptografiske nøgler og digitale signaturer i poster i navneområdet. Disse er positivt enorm.
Du kan se et eksempel på et svar fra isc.org-zonen, der indeholder DNSSEC-poster på min blog. Svarets størrelse er 4.077 bytes sammenlignet med en forespørgsel på kun 44 byte.
Nu sender billedangribere fra hele Internettet den falske forespørgsel fra din webserver's IP-adresse til isc.org-navneserverne. For hver forespørgsel på 44 byte modtager din webserver et 4.077-byte-svar til en forstærkningsfaktor på næsten 93 gange.
Lad os lave en hurtig beregning for at finde ud af, hvor dårligt dette kan blive. Sig, at hver angriber har en relativt beskeden 1 Mbps forbindelse til Internettet. Han kan sende omkring 2.840 44-byte-forespørgsler på tværs af dette link pr. Sekund. Denne forespørgselsstrøm ville resultere i svar på næsten 93 Mbps til din webserver. Hver 11 angribere repræsenterer 1Gbps.
Hvor ville antisociale angribere finde 10 venner til at hjælpe dem med at udføre et angreb? Faktisk behøver de ikke noget. De bruger et botnet på tusinder af computere.
Den ultimative effekt er ødelæggende. I deres kvartalsvise globale DDoS Attack Report rapporterede Prolexic (et DDoS-afbødende firma) et nyligt DNS-baseret angreb mod en kunde, der toppede 167Gbps. Prolexic rapporterede endvidere, at den gennemsnitlige DDoS-angrebsbåndbredde steg 718 procent til 48 Gbps i et enkelt kvartal.
Men vent! Kunne isc.org navneservere ikke ændres for at genkende, at de bliver spurgt igen og igen for de samme data fra den samme IP-adresse? Kunne de ikke kvæle angrebet?
Det kan de bestemt. Men isc.org navneservere er ikke de eneste, som en angriber kan bruge til at forstærke sin trafik. Sikker på, at der er andre autoritative navneservere, som angriberen kunne bruge, men endnu værre er åbne rekursive navneservere.
En åben rekursiv navneserver er simpelthen en navneserver, der behandler rekursive forespørgsler fra enhver IP-adresse. Jeg kan sende den forespørgsel efter isc.org-data, 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 navneserverfunktion er at finde data i Internets navneområde på vegne af DNS-klienter, som dem på din bærbare computer eller smartphone. Netværksadministratorerne, der opretter rekursive navneservere (såsom din IT-afdeling), har normalt til hensigt at bruge dem til et bestemt samfund (for eksempel dig og dine medarbejdere). Medmindre de kører tjenester som OpenDNS eller Google Public DNS, betyder det ikke, at de skal bruges af borgerne i Moldova. Så offentlig åndelig, sikkerhedsindstillet og især kompetent administratorer konfigurerer adgangskontrol på deres rekursive navneservere for at begrænse deres anvendelse til autoriserede systemer.
I betragtning af det, hvor stort et problem kan åbne rekursive navneservere være? Ret stor. Open Resolver Project har samlet en liste over 33 millioner åbne rekursive navneservere. Hackere kan affyre falske forespørgsler på så mange af disse, som de kan lide at spytte isc.org-data på din webserver, navneserver eller border router, indtil de kvæles.
Sådan fungerer DNS-baserede DDoS-angreb. Heldigvis har vi et par måder at bekæmpe dem på.
Sådan vejrer du stormen
Den første forretningsorden er at instrumentere din DNS-infrastruktur, så du ved, hvornår du er under angreb. For mange organisationer har ingen idé om, hvad deres forespørgsel er, så de ville aldrig vide, om de blev angrebet i første omgang.
At bestemme din forespørgselsbelastning kan være så simpelt som at bruge BINDs indbyggede statistiske support. BIND-navneserveren vil dumpe data til sin statistikfil, når du kører rndc-statistik,for eksempel eller med et konfigurerbart statistikinterval. Du kan undersøge statistikkerne for forespørgselshastighed, socketfejl og andre indikationer på et angreb. Bare rolig, hvis du ikke er sikker på, hvordan et angreb vil se ud endnu - en del af målet med overvågning af DNS er at etablere en baseline, så du kan identificere, hvad der er unormalt.
Se derefter på din internetvendte infrastruktur. Begræns ikke dig selv til dine eksterne autoritative navneservere; undersøge din switch- og routerinfrastruktur, dine firewalls og dine forbindelser til internettet. Identificer eventuelle enkelte fejlpunkter. Find ud af, om du let (og omkostningseffektivt) kan fjerne dem.
Overvej, hvis det er muligt, en bred geografisk fordeling af dine eksterne autoritative navneservere. Dette hjælper selvfølgelig med at undgå enkelte 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 er tættest på den, så geografisk distribution vil have tendens til at give dine kunder og korrespondenter bedre ydelse. Hvis dine kunder er grupperet i bestemte geografiske områder, skal du prøve at placere en autoritativ navneserver i nærheden af dem for at give de hurtigste svar.
Måske er den mest basale måde at bekæmpe DoS-angreb på at overprovisere din infrastruktur. Den gode nyhed er, at overprovisionering af dine navneservere ikke nødvendigvis er dyrt; en kapabel navneserver kan håndtere titusindvis eller endda hundreder af tusinder af forespørgsler pr. sekund. Er du ikke sikker på, hvad dine navneserveres kapacitet er? Du kan muligvis bruge forespørgselsværktøjer som dnsperf til at teste dine navneserveres ydeevne - helst ved hjælp af en testplatform, der ligner dine produktionsnavneservere i et laboratorium snarere end selve produktionsserverne.
At beslutte, hvor meget dine navneservere skal overproviseres, er subjektivt: Hvad er din online tilstedeværelse værd? Er der andre komponenter i din internetvendte infrastruktur, der fejler før navneserverne? Det er åbenlyst dårligt at bruge penge på at opbygge førsteklasses DNS-infrastruktur bag en grænseruter eller firewall, der fejler i god tid, før dine navneservere endda sveder.
Hvis penge ikke er noget objekt, kan det være nyttigt at vide, at avancerede DDoS-angreb mod DNS-infrastruktur kan overstige 100 Gbps.
Brug 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 det fungerer især godt med DNS. Faktisk har Internets rodnavneservere brugt Anycast i årevis til at levere rodzonedata over hele kloden, mens de stadig tillader listen over rødder at passe ind i en enkelt UDP-baseret DNS-besked.
For at implementere Anycast skal værterne, der understøtter dine navneservere, køre en dynamisk routingsprotokol som OSPF eller BGP. Rutningsprocessen vil annoncere for sine nabo-routere om en rute til en ny, virtuel IP-adresse, som din navneserver lytter til. Routingprocessen skal også være smart nok til at stoppe med at annoncere for denne rute, hvis den lokale navneserver holder op med at svare. Du kan klæbe din routing-dæmon til din navneserveres sundhed ved hjælp af din egen konstruktions kode - eller du kan købe et produkt, der tager sig af det for dig. Infobloxs NIOS inkluderer ikke tilfældigt Anycast support.
Hvordan forsvarer Anycast mod DDoS-angreb? Nå, sig, at du har seks eksterne navneservere i to Anycast-grupper (det vil sige tre, der deler en Anycast-IP-adresse og tre, der deler en anden). Hver gruppe indeholder et medlem i USA, et i Europa og et i Asien. En vært, der monterer et DDoS-angreb mod dig, kan kun sende trafik til - og dermed kun angribe - et medlem af hver gruppe fra ethvert tidspunkt på Internettet ad gangen. Medmindre angribere kan skaffe nok trafik fra Nordamerika, Europa og Asien samtidigt til at oversvømme din infrastruktur, vil de ikke lykkes.
Endelig er der en måde, du kan drage fordel af bred geografisk distribution og Anycast på samme tid uden betydeligt kapitaludlæg: Brug en skybaseret DNS-udbyder. Virksomheder som Dyn og Neustar kører egne Anycast-navneservere i datacentre over hele verden. Du betaler dem for at være vært for dine zoner og besvare spørgsmål til dine data. Og du kan fortsætte med at opretholde direkte kontrol over dine zondata ved at bede en udbyder om at konfigurere sine navneservere som sekundære til dine zoner ved at indlæse dataene fra en masternavneserver, du udpeger og administrerer internt. Bare vær sikker på at du kører masteren skjult (det vil sige uden NS-post, der peger på den), ellers risikerer du, at en angriber målretter den som et enkelt fejlpunkt.
Et ord med forsigtighed, når du bruger skybaserede DNS-udbydere: De fleste fakturerer dig i det mindste delvis baseret på antallet af forespørgsler, som deres navneservere modtager for data i dine zoner. I et DDoS-angreb kan disse forespørgsler stige dramatisk (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 overføre omkostningerne ved trafikken til dig.
Sådan undgår du at blive en medskyldig i DDoS-angreb
Nu ved du, hvordan du konfigurerer din DNS-infrastruktur til at modstå et DDoS-angreb. Det er dog næsten lige så vigtigt at sikre, at du ikke er medskyldig i et DDoS-angreb mod en anden.
Husk 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 falske forespørgsler, der får navneserverne til at sende svar mere end 100 gange så store som forespørgslen til vilkårlige mål på Internettet. Nu vil du selvfølgelig ikke være mål for et sådant angreb, men du vil heller ikke være en medskyldig. Angrebet bruger dine navneserveres ressourcer såvel som din båndbredde. Hvis målet træffer foranstaltninger for at blokere trafik fra din navneserver til sit netværk, kan målet efter angrebet slutter muligvis ikke løse domænenavne i dine zoner.
Hvis du kører en åben rekursiv navneserver, er løsningen enkel: Gør det ikke. Der er meget få organisationer, der har nogen begrundelse for at køre en navneserver, der er åben for rekursive forespørgsler. Google Public DNS og OpenDNS er to, der kommer til at tænke på, men hvis du læser dette, gætter jeg på, at du sandsynligvis ikke er dem. Resten af os skal anvende adgangskontrol til vores rekursive navneservere for at sikre, at kun autoriserede forespørgsler bruger dem. Det betyder sandsynligvis at begrænse DNS-forespørgsler til IP-adresser på vores interne netværk, hvilket er let at gøre på enhver implementering af navneserveren, der er værd at saltet. (Microsoft DNS-server understøtter ikke IP-adressebaseret adgangskontrol på forespørgsler. Læs hvad du vil i det.)
Men hvad hvis du kører en autoritativ navneserver? Det er klart, at du ikke kan begrænse de IP-adresser, hvorfra du accepterer forespørgsler - eller ikke meget, alligevel (du nægter muligvis forespørgsler fra åbenlyst falske IP-adresser, såsom RFC 1918-adresser). Men du kan begrænse svarene.
To mangeårige internet "hvide hatte", Paul Vixie og Vernon Schryver, indså DDoS-angreb, der bruger autoritative navneservere til forstærkning, viser visse forespørgselsmønstre. Især angribere sender navneservere den samme forespørgsel fra den samme falske IP-adresse (eller adresseblok) igen og igen og søger maksimal forstærkning. Ingen velopdragen rekursivt navneserver ville gøre det. Det ville have cachet svaret og ikke spurgt igen, før tiden for at leve af optegnelserne i svaret var forløbet.
