DNS amplificatie-aanvallen straks niet meer te stoppen zonder BCP 38
Twee weken geleden publiceerden de Universiteit van Amsterdam en NLnet Labs een gezamelijk rapport over de effectiviteit van maatregelen tegen DNS amplificatie-aanvallen. Javy de Koning en Thijs Rozekrans simuleerden bij NLnet Labs een ANY-gebaseerde aanval en onderzochten hoe Response Rate Limiting (RRL) het beste ingezet kan worden om een dergelijke aanval te pareren. Daarnaast keken zij naar de effectiviteit van RRL bij geavanceerdere aanvallen en bespreken ze DNS dampening als alternatief verdedigingsmechanisme.
De DNS amplificatie-aanval, een specifieke vorm van de Denial-of-Service aanval, maakt gebruik van het feit dat een kleine DNS query een veel grotere response als antwoord kan genereren. Omdat DNS standaard gebruik maakt van het snelle maar stateless UDP-protocol kan het afzender-adres makkelijk worden vervalst (IP address spoofing). Door vanuit een botnet een grote hoeveelheid DNS queries naar een of meer name-servers te sturen, kan via die servers een DDoS-aanval (Distributed Denial-of-Service) worden uitgevoerd.
DNSSEC
Hoewel DNS amplificatie-aanvallen niet afhankelijk zijn van DNSSEC, introduceert deze beveiligingstechnologie voor DNS wel een nieuwe mogelijkheid om amplificatie-aanvallen in te zetten. Een kwaadwillende stuurt immers een relatief kleine query naar een name-server, en krijgt vervolgens een hele zwik records met bijbehorende handtekeningen terug.
Hoe groot die versterking precies is, hangt helemaal af van het type aanval en de DNSSEC-ondertekening. Een 1024-bits ZSK (Zone Signing Key) voegt per RRset bijvoorbeeld een RRSIG record toe van 156+ bytes,
rekent Matthijs Mekking van NLnet Labs voor.Een ANY-gebaseerde aanval doet dat dus voor elke RRset. In een NXDOMAIN query zit normaal gesproken alleen een SOA RR. Voor DNSSEC komen daar maximaal twee NSEC RR's of drie NSEC3 RR's bij. En al die records zijn voorzien van een handtekening. Zo kom je voor een NXDOMAIN/NSEC-aanval al gauw op 488+ extra bytes. Voor NSEC3 zijn dat er dan 672+.
Daarbij benadrukt Mekking dat owner en signer name, next name, salt, hash en bitmap in deze berekening niet eens zijn meegenomen. Afhankelijk van de zone name, de grootte van het ongetekende antwoord en de grootte van je sleutels komt er in de antwoorden dus een significant aantal bytes bij. De precieze amplificatie is door alle variatie lastig aan te geven. Maar DNSSEC is niet de oorzaak van deze aanvallen; DNS-gebaseerde DDoS-aanvallen kon men hiervoor ook al uitvoeren.
ANY-gebaseerde aanvallen
Alternatief is bijvoorbeeld om gebruik te maken van de ANY query; deze levert alle records op die op dat moment bij de betreffende name-server bekend zijn. Deze queries worden met name door de qmail MTA (Message Transfer Agent) gebruikt om meerdere record typen tegelijk op te vragen, of voor 'zone health checks' waarbij wordt gecontroleerd op de aanwezigheid van belangrijke records als SOA, NS, MX, A en AAAA.
Hoewel ANY queries alleen voor enkele specifieke toepassingen worden ingezet, vindt De Koning het een slecht idee om ANY queries over UDP te blokkeren. Daarmee los je dit probleem niet op. Het is voor een aanvaller heel eenvoudig om over te stappen naar een andere type query zoals DNSKEY. Dan zou je ANY queries beter individueel en apart van andere query typen een rate limit kunnen geven. Op die manier kun je ANY-gebaseerde aanvallen pareren, terwijl ANY queries wel beschikbaar blijven voor het oplossen van DNS-problemen.
Address spoofing
Het grote onderliggende probleem — namelijk dat het stateless UDP-protocol IP address spoofing mogelijk maakt — zou je kunnen omzeilen door voor DNS een ander protocol in te zetten. De handshake van TCP (Transmission Control Protocol) of STCP (Scalable TCP) voorkomt immers dat opgeblazen antwoorden naar een vervalste afzender worden "terug"gestuurd. DNS maakt vooral gebruik van UDP omdat dit een veel betere performance oplevert,
zegt Rozekrans. Voor TCP en STCP moet je een 'state' bijhouden voor elke client. Bovendien kan een stateful protocol nieuwe problemen introduceren, zoals bijvoorbeeld een TCP SYN flood aanval.
Mekking verwacht dan ook niet dat DNS naar een ander protocol zal overschakelen. Sowieso zal DNS backward compatible moeten zijn met de huidige implementaties op UDP. Dat betekent dat DNS amplificatie-aanvallen zich in dat scenario gewoon op dat domein zullen afspelen.
Response Rate Limiting
De auteurs hebben zich in hun rapport specifiek gericht op RRL (Response Rate Limiting) als belangrijkste verdedigingsmechanisme. Daarbij worden de antwoorden naar een client-adres beperkt als deze vele malen hetzelfde antwoord leveren. Om fouten van de eerste soort (foutief-positief) te voorkomen, waarbij legitieme queries ook niet meer beantwoord worden, wordt RRL vaak gecombineerd met SLIP. Daarbij worden worden clients niet volledig geblokkeerd maar worden ze voor een bepaald gedeelte van hun queries doorverwezen naar het TCP-protocol. Op die manier wordt de amplificatie-factor uit de aanval gehaald.
De grootte van een SLIP response (een vraag aan de gebruiker om het opnieuw te proberen over TCP) is nagenoeg gelijk aan die van het request,
legt De Koning uit. Daarmee is het voor de aanvaller dus niet meer mogelijk om een amplificatie te genereren, en kan kan hij het botnet dus beter inzetten voor een rechtstreekse DDoS-aanval. Amplificatie is dus voorwaarde voor deze aanval.
Een SLIP-antwoord is even groot als de query,
vult Mekking aan, alleen het TC-bit (Truncated) is gezet. Een aanval kan in principe nog steeds, maar wordt op deze manier duurder voor de aanvaller. In het algemeen geldt dat hoe kleiner de amplificatie is, des te meer resources het de aanvaller zelf kost, en des te minder aantrekkelijk het wordt om zo'n aanval uit te voeren.
DNS dampening
Een meer dynamisch alternatief voor RRL is DNS dampening. Daarbij wordt niet naar de uitgaande responses maar naar de binnenkomende requests gekeken. Deze worden per client-adres en per query type gescoord. Wordt een bepaalde drempel overschreden, dan worden alle queries genegeerd. De score neemt exponentieel af over de tijd, zodat de responses zich vanzelf weer herstellen.
De auteurs van het rapport besteden echter maar beperkt aandacht aan DNS dampening. Deze technologie bevat op dit moment geen mogelijkheden om foutief-positieven te voorkomen. Het lijkt ons vrij eenvoudig om een mechanisme als SLIP toe te voegen aan DNS dampening,
zegt Rozekrans. Op die manier kunnen foutief-positieve blokkeringen worden voorkomen.
Mekking vindt RRL echter een verfijnder technologie. DNS dampening blokkeert alle antwoorden naar een bepaald adresblok. RRL blokkeert alleen de antwoorden die bij een specifieke aanval horen. Bij een ANY-aanval zijn gebruikers met RRL immers nog steeds in staat om antwoorden op reguliere queries over UDP te krijgen.
Beste verdediging
Volgens Mekking is RRL op dit moment de beste verdediging die we tegen DNS amplificatie-aanvallen hebben. En dat in combinatie met 50% SLIP. Dat is een verstandige afweging tussen het aantal TCP-sessies dat je name-server aankan enerzijds en het aantal foutief-positieven dat je accepteert als je onder vuur ligt anderzjds.
100% SLIP kan men gebruiken als men er honderd procent zeker van wil zijn dat alle legitieme requests beantwoord worden,
vult De Koning aan. Maar 50% SLIP lijkt inderdaad een goede default-instelling. Als we er van uit gaan dat een legitieme client zijn UDP request in totaal drie keer probeert, is er een kans van 87,5% [100% * (1 - 0,5*0,5*0,5)] dat deze beantwoord zal worden met de vraag om opnieuw verbinding te zoeken over TCP.
Bij deze beste oplossing moet wel de kanttekening worden gemaakt dat deze maar beperkt houdbaar is. De auteurs geven aan dat alleen eenvoudige DNS amplificatie-aanvallen op deze manier kunnen worden voorkomen. Zodra aanvallers meerdere name-servers inzetten kunnen de afzonderlijke servers op geen enkele manier meer zien dat ze deelnemen in een dubbel gedistribueerde aanval: gedistribueerd zowel over de aanvallende clients (een botnet) als over de name-servers die als relay fungeren. Het gedistribueerde verkeer in een lage frequentie is immers niet te onderscheiden van legitiem DNS-verkeer.
Een toekomstbestendige oplossing
De beste verdediging om DNS amplificatie-aanvallen te voorkomen is tegelijkertijd (technisch) de meest simpele oplossing. BCP 38 (Best Current Practice), ook wel bekend onder de naam Ingress filtering, schrijft voor dat elke Internet Service Provider (ISP) zijn uitgaande internet-verkeer zou moeten filteren op afzender-adres. Pakketten die niet uit zijn IP-netwerk afkomstig kunnen (mogen) zijn, moeten geblokkeerd worden. Op die manier worden besmette clients die deeluitmaken van een botnet al bij de bron geblokkeerd. Praktisch gezien is dit niet veel meer dan het instellen daarvan in de firewall policies.
Dat deze oplossing in de praktijk geen navolging vindt, heeft alles te maken met de verschillende allocatie van kosten en opbrengsten. BCP 38 is ontworpen om anderen te beschermen tegen spoofing-aanvallen die vanuit jouw netwerk afkomstig zijn door de source-adressen te valideren,
aldus De Koning. De implementatie en het onderhoud van BCP 38 kost een ISP geld, maar levert hem en zijn klanten zelf niets op.
BCP 38 wordt niet geïmplementeerd omdat daar geen prikkel voor is,
vult Mekking aan. Er kunnen weliswaar geen reflectieve aanvallen meer vanuit jouw netwerk worden uitgevoerd, maar je bent zelf nog steeds wel kwetsbaar voor dergelijke aanvallen die bij een ander vandaan komen. BCP 38 is mijns inziens de beste oplossing tegen DNS amplificatie-aanvallen. De vraag is dan ook hoe we de implementatie daarvan kunnen stimuleren. Dat is een discussie die nu gevoerd moet worden.
