Een DNS-reflective attack wordt in veel distributed denial-of-service (DDoS) aanvallen gebruikt om een internetpijp plat te leggen. De aanval bestaat uit twee stappen: de aanvaller stuurt een groot aantal verzoeken naar een of meer legitieme DNS-servers terwijl hij een gespoofed bron-IP van het beoogde slachtoffer gebruikt. De DNS-server die de semi-legitieme verzoeken ontvangt, antwoordt naar het gespoofde IP, en lanceert zo onbewust een aanval op het beoogde slachtoffer met antwoorden op verzoeken die het slachtoffer nooit heeft verzonden.

Het internet staat vol met DNS-servers die als open-resolvers worden aangeboden en elk verzoek beantwoorden dat naar hen wordt verzonden, sommige rapporten noemen miljoenen als het aantal. Dit enorme aantal maakt het erg moeilijk om de aanval vooraf te identificeren met behulp van IP-reputatie. Bovendien zijn de servers in feite legitieme servers die gewoonlijk legitiem verkeer verzenden, waardoor elke IP-reputatiedienst in verwarring kan raken over het al dan niet kwaadaardige karakter ervan.

De meeste DNS-query’s worden verzonden via UDP, een protocol dat geen bron-IP-validatie mogelijk maakt. Daarom gaat de tussenliggende DNS-server ervan uit dat de verzoeken afkomstig zijn van het slachtoffer en stuurt hij de antwoorden terug. De IP-spoofing maakt het voor de slachtoffer server uiterst moeilijk om de aanvaller te detecteren, aangezien het lijkt alsof hij wordt aangevallen door een legitieme DNS server, en het IP van de aanvaller volledig verborgen is. IP-spoofing maakt ook IP-reputatiediensten ongeldig, die, als ze niet goed zijn geschreven, een slechte reputatie kunnen toekennen aan een legitieme DNS-server. Het verwijdert ook elke haalbaarheid voor beveiligingsverwachters die de aanvalsbron proberen te identificeren.

Een ander voordeel voor spoofing is de mogelijkheid om elke server of service aan te vallen. De aanvaller kan het IP en de poort van de publieke server van het slachtoffer gebruiken om er zeker van te zijn dat de aanval naar elke service wordt gestuurd, niet alleen een DNS service. Het verkeer zal er gewoon uitzien als een heleboel gegevens en de server zal de gegevens moeten ontleden en onderzoeken om er zeker van te zijn dat het geen legitiem verkeer is.

Merk op dat de IP-spoofing ook een beperking van deze aanval is – als IP-spoofing niet mogelijk is, kan de aanval niet worden gelanceerd omdat er geen manier is om de antwoorden naar het IP van het slachtoffer te sturen. Dit is het geval met de Mirai-bots die draaien op IoT-apparaten achter een router die NAT uitvoert. Recente Mirai-infectietactieken richten zich echter op de thuisrouters zelf, waardoor de NAT-beperking wordt omzeild.

Het nieuwste en grootste voordeel dat bijdraagt aan het destructieve potentieel van reflectieve DNS-floods is versterking, die kan worden bereikt met behulp van DNS-extensies (EDNS0, gedefinieerd in RFC 2671) en DNSSec. EDNS0 staat toe dat de DNS-respons groter is dan de oorspronkelijke 512 toegestaan, terwijl DNSSec authenticatie van de respons mogelijk maakt om cache-poisoning te voorkomen. DNSSec heeft EDNS0 nodig om te werken omdat het cryptografische gegevens aan het antwoord toevoegt. Aangezien DNSSec populair wordt in het huidige beveiligingsbewuste internet, zorgt het ervoor dat steeds meer DNS-servers EDNS0 ondersteunen en stelt het een aanvaller in staat om grote antwoorden op hun verzoeken te krijgen.

De mogelijke grootte van het antwoord – tot 4096 bytes, stelt de aanvaller in staat om een klein aantal korte verzoeken te verzenden, terwijl de antwoorden die door de DNS-server worden verzonden, sterk worden versterkt, waardoor de internetpijp van het slachtoffer wordt uitgeput. Aanvallers kunnen de DNS-server bestuderen en uitvinden welke legitieme query’s tot grote antwoorden kunnen leiden, en ook DNSSec gebruiken om ze nog groter te maken met cryptografische gegevens. In veel gevallen kan het antwoord oplopen tot het maximum van 4096 bytes, wat een versterkingsfactor van x100 voor het oorspronkelijke verzoek oplevert.

Met de grote internetverbindingen van tegenwoordig kan een 100 M-verbinding met het internet een bescheiden aanval op zichzelf versturen en toch enige schade aan een normale site aanrichten. Als de aanvaller echter de mogelijkheid heeft om dit enorme antwoord van 4096 bytes te gebruiken voor zijn verzoek van 44 bytes en het 100x te versterken, zal de slachtoffer server 10G aan aanvalsverkeer ontvangen, boven zijn normale verkeersbandbreedte. Zulk verkeer zal elke normale dienst onmiddellijk buiten werking stellen. Stel je voor wat er kan worden bereikt met een botnet van zelfs maar een paar van dergelijke bots.

Bijkomend bij de grootte van het antwoord, komt het feit dat dergelijke antwoorden niet in een normaal IP pakket passen. In gevallen als deze gebruiken servers de IP-fragmentatie optie, waarmee ze het bericht in meerdere pakketten kunnen verdelen. Het gebruik van gefragmenteerd verkeer in de aanval maakt de aanval nog moeilijker – de mitigator moet de laag 4 gegevens van het eerste pakket (UDP poorten) opslaan in een tabel en deze toepassen op de rest van de pakketten van hetzelfde bericht. Veel netwerkentiteiten zijn snel uitgeput door veel gefragmenteerd verkeer, wat deze aanval nog efficiënter maakt.

Radware’s YouTube DNS amplification attack Video illustreert grafisch de structuur en flow van een Reflective DNS-aanval.

Nadat we alle ins en outs van de DNS-reflective-aanval hebben geleerd, blijft er nog één ding over – hoe kunnen we een organisatie tegen een dergelijke aanval beschermen en de aanval mitigeren? In tegenstelling tot de complexiteit van de aanval zelf, heeft dit probleem een bekende oplossing – om een DNS-reflectieaanval te beperken, moet u een goede detector ter plaatse hebben om de aanval snel te detecteren en downtime te voorkomen. De detector moet slim genoeg zijn om te begrijpen dat de aanval die hij ziet, de internetverbinding verzadigt en dat het verkeer moet worden omgeleid naar een cloud scrubbing center. Zodra het verkeer is omgeleid naar cloud scrubbing, wordt het opgeschoond en naar de site gestuurd.

De scrubbing zelf hangt af van de hoeveelheid soortgelijk verkeer dat als legitiem wordt beschouwd – ziet de site veel UDP-verkeer? DNS verkeer? Gefragmenteerd verkeer? En zo ja, wat onderscheidt het van het aanvalsverkeer? Het gebruik van een geautomatiseerde techniek om het legitieme en het aanvalsverkeer te scheiden zal u een goede en snelle cloud mitigation geven en ook, enige gemoedsrust.

Voor meer informatie, bekijk mijn vorige blog: DNS en DNS-aanvallen

Lees “Een veilige omgeving creëren voor onderbeveiligde API’s” voor meer informatie.

Download nu