Wanneer het op DNS aankomt, heeft Cricket Liu letterlijk het boek geschreven. Hij is co-auteur van alle vijf edities van O’Reilly’s boek “DNS and BIND”, dat algemeen wordt beschouwd als de definitieve gids voor alles wat met het domeinnaamsysteem te maken heeft. Cricket is momenteel chief infrastructure officer bij Infoblox.

DNS is duidelijk een essentieel onderdeel van computernetwerken, maar er zijn momenten waarop deze tools kunnen worden gebruikt voor misdrijven. In het New Tech Forum van deze week kijkt Cricket naar het groeiende probleem van DNS-gebaseerde DDoS-aanvallen en hoe daarmee om te gaan. — Paul Venezia

DNS-gebaseerde DDoS-aanvallen: Hoe ze werken en hoe ze te stoppen

De DNS-gebaseerde DDoS (distributed denial-of-service attack) is een van de meest voorkomende destructieve aanvallen op het internet geworden. Maar hoe werken ze? En wat kunnen we doen om ons ertegen te verdedigen?

In dit artikel beschrijf ik hoe DDoS-aanvallen zowel de DNS-infrastructuur als het doelwit gebruiken. Ik zal ook laten zien wat u kunt doen om uzelf en anderen te beschermen.

De grote spoof

Het genereren van een DDoS-aanval met behulp van DNS-infrastructuur is opmerkelijk eenvoudig: De aanvallers sturen queries naar naamservers over het hele internet, en die naamservers sturen antwoorden terug. In plaats van de query’s vanaf hun eigen IP-adressen te versturen, spoofen de aanvallers echter het adres van hun doelwit — dat kan een webserver zijn, een router, een andere naamserver, of zo ongeveer elk knooppunt op het internet.

Het spoofen van DNS-query’s is bijzonder eenvoudig omdat ze gewoonlijk via UDP (het verbindingsloze User Datagram Protocol) worden verzonden. Het verzenden van een DNS-query vanaf een willekeurig IP-adres is ongeveer net zo eenvoudig en heeft ongeveer hetzelfde effect als iemand anders zijn retouradres op een ansichtkaart schrijven.

Het vervalsen van queries is echter niet genoeg om een doelwit uit te schakelen. Als de antwoorden op die queries niet groter waren dan de queries zelf, zou een aanvaller het doelwit net zo goed kunnen overspoelen met gefingeerde queries. Nee, om de schade aan het doel te maximaliseren, moet elke query een zeer groot antwoord teruggeven. Het blijkt dat dit heel eenvoudig te installeren is.

Sinds de komst van EDNS0, een set uitbreidingen voor DNS die in 1999 werd geïntroduceerd, kunnen DNS-berichten op basis van UDP veel gegevens dragen. Een antwoord kan tot 4.096 bytes groot zijn. De meeste query’s zijn daarentegen minder dan 100 bytes lang.

Er was een tijd dat het relatief moeilijk was om een antwoord te vinden dat zo groot was in de naamruimte van het internet. Maar nu organisaties zijn begonnen met DNSSEC, de DNS Security Extensions, is het veel gemakkelijker. DNSSEC slaat cryptografische sleutels en digitale handtekeningen op in records in de namespace. Deze zijn positief enorm.

U kunt een voorbeeld zien van een reactie van de isc.org-zone die DNSSEC-records bevat op mijn blog. De grootte van het antwoord is 4.077 bytes, vergeleken met een query van slechts 44 bytes.

Nu, stel je voor dat aanvallers vanaf het hele internet die gespoofde query vanaf het IP-adres van je webserver naar de isc.org-naamservers sturen. Voor elke 44 byte query, ontvangt uw Web server een 4,077 byte antwoord, voor een versterkingsfactor van bijna 93 keer.

Laten we een snelle berekening doen om uit te vinden hoe erg dit kan worden. Stel dat elke aanvaller een relatief bescheiden 1Mbps verbinding met het Internet heeft. Hij kan ongeveer 2.840 44-byte queries per seconde over die verbinding sturen. Deze query stroom zou resulteren in bijna 93Mbps aan antwoorden die jouw webserver bereiken. Elke 11 aanvallers vertegenwoordigen 1Gbps.

Waar zouden asociale aanvallers 10 vrienden vinden om hen te helpen een aanval uit te voeren? Eigenlijk hebben ze die niet nodig. Ze gebruiken een botnet van duizenden computers.

Het uiteindelijke effect is verwoestend. In hun driemaandelijkse wereldwijde DDoS-aanvalsrapport meldde Prolexic (een DDoS-mitigatiebedrijf) een recente DNS-gebaseerde aanval tegen een klant met een snelheid van meer dan 167 Gbps. Prolexic meldde verder dat de gemiddelde bandbreedte van DDoS-aanvallen in één kwartaal met 718 procent was toegenomen tot 48 Gbps.

Maar wacht! Kunnen de isc.org nameservers niet zodanig worden aangepast dat ze herkennen dat ze keer op keer om dezelfde gegevens worden gevraagd, vanaf hetzelfde IP-adres? Kunnen ze de aanval niet onderdrukken?

Dat kunnen ze zeker. Maar de isc.org nameservers zijn niet de enige die een aanvaller kan gebruiken om zijn verkeer te versterken. Zeker, er zijn andere gezaghebbende nameservers die de aanvaller kan gebruiken, maar nog erger zijn open recursieve nameservers.

Een open recursieve nameserver is gewoon een nameserver die recursieve queries van elk IP-adres verwerkt. Ik kan het die query sturen voor isc.org gegevens en het zal mij antwoorden, en u kunt hetzelfde doen.

Er zouden niet veel open recursieve naamservers op het Internet moeten zijn. De functie van een recursieve naamserver is het opzoeken van gegevens in de naamruimte van het internet namens DNS-clients, zoals die op uw laptop of smartphone. De netwerkbeheerders die recursieve naamservers instellen (zoals uw IT-afdeling), zijn meestal bedoeld voor gebruik door een bepaalde gemeenschap (bijvoorbeeld u en uw collega’s). Tenzij ze services zoals OpenDNS of Google Public DNS draaien, is het niet hun bedoeling dat ze door de burgers van Moldavië worden gebruikt. Dus instellingen van beheerders met een open geest, oog voor veiligheid en vooral bekwame beheerders configureren toegangscontroles op hun recursieve naamservers om het gebruik ervan te beperken tot geautoriseerde systemen.

Hoe groot kan het probleem van open recursieve naamservers zijn? Behoorlijk groot. Het Open Resolver Project heeft een lijst van 33 miljoen open recursieve naamservers verzameld. Hackers kunnen vervalste query’s op zoveel mogelijk van deze afvuren als ze willen om isc.org-gegevens op uw webserver, naamserver of grensrouter te spuwen totdat deze stikt.

Dat is hoe DNS-gebaseerde DDoS-aanvallen werken. Gelukkig zijn er een paar manieren om ze te bestrijden.

Hoe de storm te doorstaan

Het eerste wat we moeten doen is uw DNS-infrastructuur van instrumenten voorzien, zodat u weet wanneer u wordt aangevallen. Te veel organisaties hebben geen idee wat hun querybelasting is, dus ze zouden nooit weten of ze überhaupt werden aangevallen.

Het bepalen van uw querybelasting kan zo eenvoudig zijn als het gebruik van de ingebouwde statistische ondersteuning van BIND. De BIND naamserver zal gegevens naar zijn statistiekenbestand dumpen wanneer u bijvoorbeeld rndc stats uitvoert, of met een in te stellen statistiekeninterval. U kunt de statistieken onderzoeken op query rate, socket errors, en andere aanwijzingen voor een aanval. U hoeft zich geen zorgen te maken als u nog niet zeker weet hoe een aanval eruitziet. DNS-bewaking is onder andere bedoeld om een basislijn vast te stellen, zodat u kunt bepalen wat abnormaal is.

Naar aanleiding hiervan bekijkt u uw infrastructuur die op internet is gericht. Beperk u niet tot uw externe autoritatieve naamservers, maar onderzoek ook uw switch- en routerinfrastructuur, uw firewalls en uw verbindingen met het internet. Identificeer eventuele single points of failure. Bepaal of u deze gemakkelijk (en kosteneffectief) kunt elimineren.

Overweeg indien mogelijk een brede geografische spreiding van uw externe autoratieve naamservers. Dit helpt natuurlijk om single points of failure te voorkomen, maar het helpt ook als u niet wordt aangevallen. Een recursieve naamserver die een domeinnaam in een van uw zones omzet, zal proberen de gezaghebbende naamserver te vragen die zich het dichtst in de buurt bevindt, dus geografische spreiding zal over het algemeen betere prestaties leveren voor uw klanten en correspondenten. Als uw klanten in bepaalde geografische gebieden zijn geclusterd, probeer dan een gezaghebbende naamserver in hun buurt te plaatsen om de snelste antwoorden te geven.

De meest eenvoudige manier om DoS-aanvallen te bestrijden is misschien wel om uw infrastructuur te overprovisioneren. Het goede nieuws is dat het overprovisioneren van uw naamservers niet per se duur hoeft te zijn; een capabele naamserver kan tienduizenden of zelfs honderdduizenden query’s per seconde verwerken. Weet u niet zeker wat de capaciteit van uw naamservers is? U kunt queryhulpmiddelen zoals dnsperf gebruiken om de prestaties van uw naamservers te testen – bij voorkeur met behulp van een testplatform dat vergelijkbaar is met uw productienaamservers in een lab in plaats van de productieservers zelf.

Beslissen over hoeveel u uw naamservers moet overprovisioneren, is subjectief: Wat is uw online aanwezigheid waard? Zijn er andere onderdelen van uw op het internet gerichte infrastructuur die eerder zullen falen dan de naamservers? Het is natuurlijk roekeloos om geld uit te geven aan het bouwen van eersteklas DNS-infrastructuur achter een grensrouter of firewall die het zal begeven voordat uw naamservers zelfs maar een zweetdruppel uitbreken.

Als geld geen bezwaar is, is het misschien handig om te weten dat state-of-the-art DDoS-aanvallen tegen DNS-infrastructuur meer dan 100 Gbps kunnen bedragen.

Het gebruik van Anycast kan ook helpen een DDoS-aanval te weerstaan. Anycast is een techniek waarmee meerdere servers een enkel IP-adres kunnen delen, en het werkt bijzonder goed met DNS. In feite hebben de rootnaamservers van het Internet jarenlang Anycast gebruikt om rootzonegegevens over de hele wereld te leveren, terwijl de lijst van roots nog steeds in een enkel op UDP gebaseerd DNS-bericht past.

Om Anycast in te zetten, moeten de hosts die uw naamservers ondersteunen een dynamisch routeringsprotocol uitvoeren, zoals OSPF of BGP. Het routeringsproces zal aan zijn buurrouters een route naar een nieuw, virtueel IP-adres adverteren waarop uw naamserver luistert. Het routeringsproces moet ook slim genoeg zijn om te stoppen met het adverteren van die route als de lokale naamserver niet meer reageert. U kunt uw routeringsdaemon aan de gezondheid van uw naamserver lijmen met zelfgemaakte code — of u kunt een product kopen dat dit voor u regelt. Infoblox’s NIOS, niet toevallig, bevat Anycast ondersteuning.

Hoe verdedigt Anycast zich tegen DDoS aanvallen? Stel, u hebt zes externe naamservers in twee Anycast-groepen (dat wil zeggen, drie delen één Anycast IP-adres en drie delen een ander). Elke groep bevat één lid in de Verenigde Staten, één in Europa en één in Azië. Een host die een DDoS-aanval tegen u uitvoert, kan slechts verkeer verzenden naar – en dus slechts aanvallen op – één lid van een van beide groepen vanaf een willekeurig punt op het internet. Tenzij aanvallers genoeg verkeer uit Noord-Amerika, Europa en Azië tegelijk kunnen sturen om uw infrastructuur te overspoelen, zullen ze niet slagen.

Eindelijk is er een manier waarop u kunt profiteren van brede geografische spreiding en Anycast op hetzelfde moment, zonder aanzienlijke investeringen: Gebruik een cloud-gebaseerde DNS provider. Bedrijven zoals Dyn en Neustar beheren hun eigen Anycast-naamservers in datacentra over de hele wereld. U betaalt hen om uw zones te hosten en query’s voor uw gegevens te beantwoorden. En u kunt directe controle over uw zonegegevens blijven houden door een provider te vragen zijn naamservers als secundaire servers voor uw zones te configureren, waarbij de gegevens worden geladen vanaf een hoofdnaamserver die u zelf aanwijst en beheert. Zorg er wel voor dat u de master hidden draait (dat wil zeggen, zonder NS-record dat ernaar wijst), anders loopt u het risico dat een aanvaller deze als single point of failure beschouwt.

Eén woord van voorzichtigheid bij het gebruik van cloud-gebaseerde DNS-providers: De meeste factureren u ten minste gedeeltelijk op basis van het aantal query’s dat hun naamservers ontvangen voor gegevens in uw zones. Bij een DDoS-aanval kunnen die query’s dramatisch toenemen (volledig buiten uw macht en helemaal niet in uw voordeel), dus zorg ervoor dat ze een voorziening hebben voor het afhandelen van DDoS-aanvallen zonder de kosten van het verkeer aan u door te berekenen.

Hoe te voorkomen dat u medeplichtig wordt aan DDoS-aanvallen

Nu weet u hoe u uw DNS-infrastructuur moet configureren om een DDoS-aanval te weerstaan. Het is echter bijna net zo belangrijk om ervoor te zorgen dat u niet medeplichtig wordt aan een DDoS-aanval tegen iemand anders.

Herinnert u zich de beschrijving van hoe DNS-servers verkeer kunnen versterken? Aanvallers kunnen zowel open recursieve naamservers als gezaghebbende naamservers gebruiken als versterkers, waarbij ze vervalste query’s verzenden die ervoor zorgen dat de naamservers antwoorden sturen die meer dan 100 keer zo groot zijn als de query naar willekeurige doelwitten op het internet. Nu wilt u natuurlijk niet het doelwit van zo’n aanval zijn, maar u wilt ook niet medeplichtig zijn. De aanval gebruikt zowel de bronnen van uw naamservers als uw bandbreedte. Als het doelwit maatregelen neemt om verkeer van uw naamserver naar zijn netwerk te blokkeren, is het mogelijk dat het doelwit na afloop van de aanval niet in staat is domeinnamen in uw zones om te zetten.

Als u een open recursieve naamserver draait, is de oplossing eenvoudig: Doe het niet. Er zijn maar heel weinig organisaties die het rechtvaardigen om een naamserver te draaien die openstaat voor recursieve query’s. Google Public DNS en OpenDNS zijn er twee die me te binnen schieten, maar als je dit leest, denk ik dat je daar waarschijnlijk niet toe behoort. De rest van ons zou toegangscontrole moeten toepassen op onze recursieve naamservers om er zeker van te zijn dat alleen geautoriseerde queriers ze gebruiken. Dat betekent waarschijnlijk dat DNS-queries beperkt moeten worden tot IP-adressen op onze interne netwerken, wat eenvoudig te doen is op elke naamserverimplementatie die de moeite waard is. (De Microsoft DNS Server ondersteunt geen op IP-adres gebaseerde toegangscontrole op queries. Lees wat je wilt.)

Maar wat als je een autoratieve naamserver draait? Het is duidelijk dat je de IP adressen waarvan je queries accepteert niet kunt beperken — of toch niet erg veel (je zou queries kunnen weigeren van duidelijk nep IP adressen, zoals RFC 1918 adressen). Maar je kunt wel antwoorden beperken.

Twee oude internet “white hats”, Paul Vixie en Vernon Schryver, realiseerden zich dat DDoS-aanvallen die autoritatieve naamservers gebruiken voor versterking bepaalde query-patronen vertonen. In het bijzonder sturen aanvallers naamservers steeds weer dezelfde query vanaf hetzelfde gespoofde IP-adres (of adresblok), op zoek naar maximale amplificatie. Geen enkele goed opgevoede recursieve naamserver zou dat doen. Hij zou het antwoord in de cache hebben opgeslagen en niet opnieuw vragen totdat de tijd om te leven van de records in het antwoord is verstreken.

Vixie en Schryver kwamen met een slim mechanisme, Response Rate Limiting (RRL) genaamd, waarmee een gezaghebbende naamserver kan bijhouden hoe vaak hij hetzelfde antwoord aan dezelfde querier heeft gezonden. Als die frequentie een instelbare drempel overschrijdt, stopt de naamserver gedurende een bepaalde periode met het verzenden van dat antwoord naar de querier. Als de querier stopt met de gezaghebbende naamserver met dezelfde vraag te bestoken, stopt de gezaghebbende naamserver met het onderdrukken van dat antwoord. Het resultaat is dat de autoritatieve naamserver nooit een antwoord naar een querier zal sturen met een snelheid die hoger is dan de drempel, waardoor deze nutteloos is bij een DDoS-aanval.

RRL werd in BIND-naamservers opgenomen in versie 9.9.4, en een paar andere naamserver-implementaties ondersteunen het nu, inclusief NSD en Knot. Naarmate mensen hun naamservers upgraden naar nieuwere versies of nieuwe implementaties die RRL ondersteunen, zou dit het voor aanvallers geleidelijk moeilijker moeten maken om DNS-infrastructuur als versterker te gebruiken.

Ik hoop dat deze discussie u heeft geholpen te begrijpen hoe de DNS-infrastructuur zowel doelwit is van DDoS-aanvallen als hoe deze wordt uitgebuit, en hoe u DDoS-aanvallen het beste kunt weerstaan en ervoor kunt zorgen dat uw naamservers niet, zonder dat u het weet, deelnemen aan een DDoS-aanval.

New Tech Forum biedt een middel om opkomende bedrijfstechnologie in ongekende diepte en breedte te verkennen en te bespreken. De selectie is subjectief, gebaseerd op onze keuze van de technologieën waarvan wij denken dat ze belangrijk en van het grootste belang zijn voor InfoWorld lezers. InfoWorld aanvaardt geen marketingmateriaal voor publicatie en behoudt zich het recht voor om alle bijgedragen inhoud te redigeren. Stuur alle vragen naar [email protected].

Dit artikel, “De ultieme gids voor het voorkomen van DNS-gebaseerde DDoS-aanvallen”, is oorspronkelijk gepubliceerd op InfoWorld.com. Volg InfoWorld.com op Twitter voor het laatste zakelijke technologienieuws.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.