När det gäller DNS har Cricket Liu bokstavligen skrivit boken. Han har varit medförfattare till alla fem upplagor av O’Reillys bok ”DNS and BIND”, som allmänt anses vara den definitiva guiden om allt som har med domännamnssystemet att göra. Cricket är för närvarande infrastrukturchef på Infoblox.
DNS är helt klart en kritisk komponent i datornätverk, men det finns tillfällen då dessa verktyg kan användas för illgärningar. I veckans New Tech Forum tar Cricket en titt på det växande problemet med DNS-baserade DDoS-attacker och hur man hanterar dem. — Paul Venezia
DNS-baserade DDoS-attacker: Hur de fungerar och hur man stoppar dem
DNS-baserade DDoS (distributed denial-of-service attack) har blivit en av de vanligaste destruktiva attackerna på Internet. Men hur fungerar de egentligen? Och vad kan vi göra för att försvara oss mot dem?
I den här artikeln beskriver jag hur DDoS-attacker både utnyttjar och riktar sig mot DNS-infrastruktur. Jag visar också vad du kan göra för att skydda dig själv och andra.
Den stora spoofen
Att generera en DDoS-attack med hjälp av DNS-infrastruktur är anmärkningsvärt enkelt: Angriparna skickar förfrågningar till namnservrar över hela Internet, och dessa namnservrar returnerar svar. Istället för att skicka frågorna från sina egna IP-adresser förfalskar angriparna adressen till sitt mål – som kan vara en webbserver, en router, en annan namnserver eller nästan vilken nod som helst på Internet.
Det är särskilt lätt att förfalskat skicka DNS-frågor eftersom de vanligtvis överförs via UDP (det anslutningslösa User Datagram Protocol). Att skicka en DNS-förfrågan från en godtycklig IP-adress är ungefär lika enkelt och har ungefär samma effekt som att skriva någon annans returadress på ett vykort.
Det räcker dock inte att förfalska förfrågningar för att göra en måltavla oduglig. Om svaren på dessa förfrågningar inte är större än själva förfrågningarna skulle en angripare göra lika bra i att översvämma målet med förfalskade förfrågningar. Nej, för att maximera skadan på målet bör varje fråga ge ett mycket stort svar. Det visar sig att det är mycket lätt att sätta igång.
Sedan EDNS0, en uppsättning tillägg till DNS som introducerades 1999, har UDP-baserade DNS-meddelanden kunnat bära mängder av data. Ett svar kan vara så stort som 4 096 bytes. De flesta förfrågningar är däremot mindre än 100 byte långa.
En gång i tiden var det relativt svårt att hitta ett så stort svar i Internets namnområde. Men nu när organisationer har börjat använda DNSSEC, DNS Security Extensions, är det mycket lättare. DNSSEC lagrar kryptografiska nycklar och digitala signaturer i poster i namnområdet. Dessa är rent ut sagt enorma.
Du kan se ett exempel på ett svar från zonen isc.org som innehåller DNSSEC-poster på min blogg. Svaret är 4 077 byte stort, jämfört med en förfrågan på bara 44 byte.
Föreställ dig angripare från hela Internet som skickar en förfalskad förfrågan från din webbservers IP-adress till isc.org:s namnservrar. För varje fråga på 44 byte får din webbserver ett svar på 4 077 byte, vilket ger en förstärkningsfaktor på nästan 93 gånger.
Vi kan göra en snabb beräkning för att räkna ut hur illa det här kan bli. Säg att varje angripare har en relativt blygsam 1 Mbps-anslutning till Internet. Han kan skicka cirka 2 840 44-byte-förfrågningar över den länken per sekund. Denna frågeström skulle resultera i nästan 93 Mbit/s svar som når din webbserver. Var 11:e angripare representerar 1 Gbps.
Var skulle antisociala angripare hitta 10 vänner som hjälper dem att genomföra en attack? Egentligen behöver de inga. De använder ett botnät med tusentals datorer.
Den slutliga effekten är förödande. I sin kvartalsvisa globala rapport om DDoS-attacker rapporterade Prolexic (ett företag som arbetar med DDoS-begränsning) om en nyligen genomförd DNS-baserad attack mot en kund som översteg 167 Gbps. Prolexic rapporterade vidare att den genomsnittliga bandbredden för DDoS-attacker ökade med 718 procent till 48 Gbps under ett enda kvartal.
Men vänta! Skulle inte namnservrarna för isc.org kunna ändras så att de känner igen att de gång på gång blir tillfrågade om samma data från samma IP-adress? Skulle de inte kunna stoppa attacken?
Det kan de säkert. Men namnservrarna isc.org är inte de enda som en angripare kan använda för att förstärka sin trafik. Visst finns det andra auktoritativa namnservrar som angriparen kan använda, men ännu värre är öppna rekursiva namnservrar.
En öppen rekursiv namnserver är helt enkelt en namnserver som behandlar rekursiva förfrågningar från vilken IP-adress som helst. Jag kan skicka en förfrågan om isc.org-data till den och den kommer att svara mig, och du kan göra detsamma.
Det borde inte finnas så många öppna rekursiva namnservrar på Internet. En rekursiv namnservers funktion är att söka upp data i Internets namnområde på uppdrag av DNS-klienter, t.ex. de som finns på din bärbara dator eller smartphone. De nätverksadministratörer som konfigurerar rekursiva namnservrar (t.ex. din IT-avdelning) avser vanligtvis att de ska användas av en viss grupp (t.ex. dig och dina arbetskamrater). Om de inte kör tjänster som OpenDNS eller Google Public DNS är det inte meningen att de ska användas av medborgarna i Moldavien. Därför konfigurerar allmänintresserade, säkerhetsmedvetna och framför allt kompetenta administratörer åtkomstkontroller på sina rekursiva namnservrar för att begränsa användningen av dem till auktoriserade system.
Med tanke på detta, hur stort problem kan öppna rekursiva namnservrar vara? Ganska stort. Open Resolver Project har samlat in en lista över 33 miljoner öppna rekursiva namnservrar. Hackare kan skicka falska förfrågningar till så många av dessa som de vill för att sprida isc.org-data till din webbserver, namnserver eller gränsrouter tills den kvävs.
Det är så DNS-baserade DDoS-attacker fungerar. Som tur är har vi några sätt att bekämpa dem.
Så här klarar du stormen
Den första åtgärden är att instrumentera din DNS-infrastruktur, så att du vet när du är utsatt för en attack. Alltför många organisationer har ingen aning om hur stor deras förfrågningsbelastning är, så de skulle aldrig veta om de blev attackerade överhuvudtaget.
Det kan vara så enkelt att bestämma din förfrågningsbelastning som att använda BIND:s inbyggda statistikstöd. BIND-namnservern dumpar data till sin statistikfil när du kör rndc stats, till exempel, eller vid ett konfigurerbart statistikintervall. Du kan undersöka statistiken med avseende på frågefrekvens, socketfel och andra indikationer på en attack. Oroa dig inte om du inte är säker på hur en attack kommer att se ut ännu – en del av målet med att övervaka DNS är att etablera en baslinje, så att du kan identifiera vad som är onormalt.
Nästan, ta en titt på din infrastruktur som vetter mot Internet. Begränsa dig inte till dina externa auktoritativa namnservrar, utan granska din switch- och routerinfrastruktur, dina brandväggar och dina anslutningar till Internet. Identifiera eventuella enskilda felpunkter. Bestäm om du enkelt (och kostnadseffektivt) kan eliminera dem.
Om möjligt bör du överväga en bred geografisk spridning av dina externa auktoritativa namnservrar. Detta hjälper naturligtvis till att undvika enstaka felpunkter, men det hjälper också när du inte blir attackerad. En rekursiv namnserver som löser upp ett domännamn i en av dina zoner kommer att försöka fråga den auktoritativa namnserver som ligger närmast den, så geografisk fördelning tenderar att ge bättre prestanda för dina kunder och korrespondenter. Om dina kunder är samlade i vissa geografiska områden bör du försöka placera en auktoritativ namnserver nära dem för att ge snabbast möjliga svar.
Det kanske mest grundläggande sättet att bekämpa DoS-attacker är att överförsörja din infrastruktur. Den goda nyheten är att det inte nödvändigtvis är dyrt att överförsörja dina namnservrar; en duglig namnserver kan hantera tiotusentals eller till och med hundratusentals förfrågningar per sekund. Är du inte säker på vilken kapacitet dina namnservrar har? Du kan använda frågeverktyg som dnsperf för att testa dina namnservatorers prestanda – helst med hjälp av en testplattform som liknar dina produktionsnamnsservrar i ett labb snarare än själva produktionsservrarna.
Det är subjektivt att avgöra hur mycket du ska överförsörja dina namnservrar: Vad är din närvaro på nätet värd? Finns det andra komponenter i din Internet-infrastruktur som kommer att gå sönder före namnservrarna? Det är naturligtvis dumdristigt att spendera pengar på att bygga en förstklassig DNS-infrastruktur bakom en gränsrouter eller brandvägg som kommer att misslyckas långt innan dina namnservrar ens får svettas.
Om pengar inte spelar någon roll kan det vara bra att veta att de senaste DDoS-attackerna mot DNS-infrastruktur kan överstiga 100 Gbps.
Användning av Anycast kan också hjälpa till att motstå en DDoS-attack. Anycast är en teknik som gör det möjligt för flera servrar att dela en enda IP-adress, och den fungerar särskilt bra med DNS. Faktum är att Internets rotnamnsservrar har använt Anycast i flera år för att tillhandahålla rotzondata över hela världen samtidigt som listan över rötter får plats i ett enda UDP-baserat DNS-meddelande.
För att kunna använda Anycast måste värddatorerna som stöder dina namnservrar köra ett dynamiskt routningsprotokoll, till exempel OSPF eller BGP. Routingprocessen kommer att annonsera en rutt till sina grannroutrar till en ny, virtuell IP-adress som din namnserver lyssnar på. Routingprocessen måste också vara tillräckligt smart för att sluta annonsera rutten om den lokala namnservern slutar svara. Du kan limma din routningsdemon till din namnservers hälsa med hjälp av egen kod – eller så kan du köpa en produkt som tar hand om det åt dig. Infoblox NIOS innehåller, inte av en slump, stöd för Anycast.
Hur försvarar sig Anycast mot DDoS-attacker? Säg att du har sex externa namnservrar i två Anycast-grupper (dvs. tre delar en Anycast-IP-adress och tre delar en annan). Varje grupp innehåller en medlem i USA, en i Europa och en i Asien. En värd som genomför en DDoS-attack mot dig kan bara skicka trafik till – och därmed bara attackera – en medlem i någon av grupperna från någon punkt på Internet åt gången. Om angriparna inte kan få tillräckligt med trafik från Nordamerika, Europa och Asien samtidigt för att överösa din infrastruktur, kommer de inte att lyckas.
Till sist finns det ett sätt att dra nytta av en bred geografisk spridning och Anycast samtidigt, utan stora investeringar: Använd en molnbaserad DNS-leverantör. Företag som Dyn och Neustar driver egna Anycast-namnservrar i datacenter runt om i världen. Du betalar dem för att vara värd för dina zoner och svara på frågor om dina data. Du kan fortsätta att ha direkt kontroll över dina zondata genom att be leverantören att konfigurera sina namnservrar som sekundära för dina zoner och läsa in data från en huvudnamnserver som du utser och hanterar internt. Se bara till att du kör master-serveren dold (det vill säga utan någon NS-post som pekar på den), annars riskerar du att en angripare kommer att använda den som en enda felpunkt.
Ett ord av försiktighet när du använder molnbaserade DNS-leverantörer: De flesta fakturerar dig åtminstone delvis baserat på antalet förfrågningar som deras namnservrar får om data i dina zoner. Vid en DDoS-attack kan dessa förfrågningar öka dramatiskt (helt utanför din kontroll och inte alls till din fördel), så se till att de har en bestämmelse för att hantera DDoS-attacker utan att föra över kostnaden för trafiken på dig.
Hur du undviker att bli medbrottsling vid DDoS-attacker
Nu vet du hur du kan konfigurera din DNS-infrastruktur så att den står emot en DDoS-attack. Det är dock nästan lika viktigt att se till att du inte blir medbrottsling i en DDoS-attack mot någon annan.
Håller du ihåg beskrivningen av hur DNS-servrar kan förstärka trafiken? Angripare kan använda både öppna rekursiva namnservrar och auktoritativa namnservrar som förstärkare och skicka förfalskade förfrågningar som får namnservrarna att skicka svar som är mer än 100 gånger så stora som förfrågan till godtyckliga mål på Internet. Du vill naturligtvis inte bli måltavla för en sådan attack, men du vill inte heller vara medbrottsling. Attacken använder både dina namnservatorers resurser och din bandbredd. Om målet vidtar åtgärder för att blockera trafiken från din namnserver till sitt nätverk kan det hända att målet inte kan lösa domännamn i dina zoner när attacken är avslutad.
Om du kör en öppen rekursiv namnserver är lösningen enkel: Gör det inte. Det finns mycket få organisationer som har någon motivering för att köra en namnserver som är öppen för rekursiva förfrågningar. Google Public DNS och OpenDNS är två som jag kommer att tänka på, men om du läser det här gissar jag att du förmodligen inte tillhör dem. Resten av oss bör tillämpa åtkomstkontroller för våra rekursiva namnservrar för att se till att endast auktoriserade frågeställare använder dem. Det innebär förmodligen att vi måste begränsa DNS-frågorna till IP-adresser i våra interna nätverk, vilket är lätt att göra på alla namnserverimplementationer som är värda sitt salt. (Microsofts DNS-server har inte stöd för IP-adressbaserade åtkomstkontroller för frågor. Läs vad du vill om det.)
Men vad händer om du kör en auktoritativ namnserver? Du kan naturligtvis inte begränsa de IP-adresser från vilka du accepterar förfrågningar – eller inte särskilt mycket i alla fall (du kan neka förfrågningar från uppenbart falska IP-adresser, t.ex. RFC 1918-adresser). Men du kan begränsa svaren.
Två mångåriga Internet-”vita hattar”, Paul Vixie och Vernon Schryver, insåg att DDoS-attacker som använder auktoritativa namnservrar för förstärkning uppvisar vissa frågemönster. I synnerhet skickar angriparna samma förfrågan till namnservrarna från samma förfalskade IP-adress (eller adressblock) om och om igen, för att få maximal förstärkning. Ingen välskött rekursiv namnserver skulle göra det. Den skulle ha lagrat svaret i cacheminnet och inte frågat igen förrän tiden för att leva för posterna i svaret hade gått ut.
Vixie och Schryver kom på en smart mekanism, kallad Response Rate Limiting (RRL), som gör det möjligt för en auktoritativ namnserver att spåra hur ofta den har skickat samma svar till samma frågeställare. Om denna frekvens överskrider ett konfigurerbart tröskelvärde slutar namnservern att skicka svaret till frågeställaren under en viss period. Om frågeställaren slutar att skicka samma fråga till den auktoritativa namnservern slutar den auktoritativa namnservern att skicka det svaret. Resultatet är att den auktoritativa namnservern aldrig kommer att skicka något svar till en frågeställare med en hastighet som är högre än tröskelvärdet, vilket gör den oanvändbar vid en DDoS-attack.
RRL införlivades i BIND:s namnservrar i version 9.9.4, och några andra namnserverimplementationer har nu stöd för det, bland annat NSD och Knot. I takt med att folk uppgraderar sina namnservrar till nyare versioner eller nya implementationer med stöd för RRL bör detta gradvis göra det svårare för angripare att använda DNS-infrastruktur som förstärkare.
Jag hoppas att den här diskussionen har hjälpt dig att förstå hur DNS-infrastrukturen både är riktad mot och utnyttjas i DDoS-attacker och hur du bäst kan motstå DDoS-attacker och se till att dina namnservrar inte, utan att du vet om det, deltar i en sådan.
New Tech Forum ger dig möjlighet att utforska och diskutera framväxande företagsteknik på ett aldrig tidigare skådat djup och i en aldrig tidigare skådad bredd. Urvalet är subjektivt, baserat på vårt urval av de tekniker som vi anser vara viktiga och av störst intresse för InfoWorlds läsare. InfoWorld accepterar inte marknadsföringsmaterial för publicering och förbehåller sig rätten att redigera allt bidragande innehåll. Skicka alla förfrågningar till [email protected].
Denna artikel, ”The ultimate guide to preventing DNS-based DDoS attacks”, publicerades ursprungligen på InfoWorld.com. Följ InfoWorld.com på Twitter för de senaste nyheterna om affärsteknik.