Afstudeeronderzoek: De impact van scanning op autoritatieve nameservers

Dit onderzoek werd uitgevoerd bij SIDN Labs in het kader van een master thesis aan de Universiteit van Münster in Duitsland.

DNS-verkeer is normaal gesproken het resultaat van acties van gebruikers, bijvoorbeeld wanneer ze een website bezoeken of een e-mail versturen. Maar – zoals bijna alles waarbij gebruik wordt gemaakt van computers en het internet – het kan ook worden geautomatiseerd. Dit wordt vaak gedaan om data over grote aantallen domeinnamen te vergaren voor onderzoeksdoeleinden en voor 'domaining' – het controleren van de beschikbaarheid van een lijst domeinnamen. Hier bestaat opensourcesoftware voor en daarmee kun je op een doorsneecomputer gemakkelijk miljoenen namen controleren, wat grote verkeersdrukte kan veroorzaken.

Dit roept de vraag op wat we te weten kunnen komen over DNS-scanning: hoe populair is het, wie doet het, en waarom? En uiteindelijk: vormt het een gevaar voor de DNS-infrastructuur?

Voornaamste conclusies

• Scans kunnen worden gevonden door te zoeken naar uitschieters in het resolververkeer.

• De meeste scans worden uitgevoerd vanuit de netwerken van hosting- of cloudproviders, maar ze kunnen ook worden aangetroffen in verkeer dat afkomstig is van talloze publieke resolvers, onderzoeksnetwerken en andere ondernemingen.

• We schatten dat zo'n 30% van het totale verkeer naar de .nl-servers wordt veroorzaakt door scanning.

Achtergrond

Domeinnamen zijn een kostbaar bezit geworden en worden soms voor duizenden of miljoenen euro's gekocht en verkocht. Dit heeft ze aantrekkelijk gemaakt voor 'domainers', die systematisch domeinnamen zoeken, opkopen en met winst verkopen.

Anderzijds is het DNS een kritiek onderdeel van de infrastructuur van het internet en weten welke subdomeinen er zijn, kan nuttig zijn voor hackers of penetratietesten. Het al dan niet bestaan van DNS-records en hun data wordt ook gebruikt in onderzoek (OpenINTEL, DNSdb), bijvoorbeeld om meer inzicht te krijgen in de implementatie van nieuw protocollen.

Het is welbekend onder DNS-operators dat scanning een veelvoorkomende activiteit is, die ook door academische organisaties wordt uitgevoerd (SIDN zelf doet dat bijvoorbeeld met DMAP). In algemene zin is het niet bekend op welke schaal scanning plaatsvindt en is het onduidelijk hoeveel partijen wat voor soort scans uitvoeren, welke data uit welke bronnen ze daarvoor gebruiken, en wat dat betekent voor de DNS-infrastructuur. We hopen met dit onderzoek deze leemte in te vullen en inzicht te verschaffen in de vormen en omvang van scans en het gedrag van resolvers in het algemeen.

We maakten gebruik van querydata die door ENTRADA verzameld werden bij alle autoritatieve nameservers voor .nl. In dit onderzoek worden dus passieve DNS-metingen gebruikt om actieve DNS-metingen te detecteren.

Scans zoeken

Om scans te identificeren, was een definitie van wat een scan precies is en enige handmatig onderzoek van de data nodig. Uiteraard is domaining een vorm van scanning, oftewel, het systematisch opvragen van grote aantallen namen. Andere vormen zijn onder meer monitoring, maar ook bulkmailing, omdat dit niet altijd van andere vormen kan worden onderscheiden. Elk significant verkeer met betrekking tot gegenereerde domeinnamen wordt beschouwd als scanning.

We verwachten van DNS-query's dat ze een bepaald patroon volgen, zoals het protocol dat voorschrijft. Zo behoort een resolver een query waarvan het oorspronkelijke antwoord niet in een enkel UDP-pakket past, opnieuw te proberen via TCP en moet een resolver een antwoord enige tijd opslaan in de cache om te voorkomen dat een query te vaak wordt herhaald. Andere patronen ontstaan door de inhoud van het verkeer. Een resolver die clients bedient, zal populaire namen bijvoorbeeld honderden keren opvragen, terwijl minder populaire namen misschien maar 1 keer worden opgevraagd.

De sleutel tot het detecteren van scans is het herkennen van patronen in normaal verkeer die niet voorkomen in verkeer dat wordt veroorzaakt door scans. Van domainers verwachten we dat ze grote aantallen verschillende domeinnamen opvragen zonder redundante query's. Door per IP-bronadres te bekijken welk deel van de query's vraagt naar een naam die nog niet eerder is opgevraagd, dit voor elke bron uit te drukken in een percentage en dan een histogram van die bronnen te maken, komen we tot figuur 1.

Figuur 1: Aantal resolvers met elk 'distinct name percentage' (histogram, doosdiagram). Distinct name percentage: het percentage unieke query's, oftewel query's die betrekking hebben op domeinnamen die niet eerder door deze resolver zijn opgevraagd.

Als we de resolvers die voor bijna 100% niet-herhaalde namen versturen (helemaal rechts in figuur 1) nader bekijken, blijkt het om scans te gaan. Hun verkeer volgt ook vaak een bepaalde volgorde, bijvoorbeeld dat eerst de populairste of de kortste namen worden opgevraagd of dat de namen in alfabetische volgorde staan. In deze gevallen is het aannemelijk dat we te maken hebben met een scan.

Door het querygedrag van een groot aantal verschillende bronnen te bestuderen, kunnen we nieuwe ideeën opdoen over de patronen die duiden op scangedrag. Bijvoorbeeld:

• Een extreem hoog of laag aantal herhaalde namen, terwijl in normaal verkeer alleen bepaalde namen vaak worden herhaald

• Een hoog totaal aantal query's, zoals meerdere miljoenen, terwijl de meeste resolvers er minder dan 500.000 per dag versturen

• Een ongebruikelijk percentage NX-domeinen, dat voor normaal verkeer ongeveer 5 tot 10% bedraagt maar voor diverse scans vrijwel 0 of 100% kan zijn

• Ongebruikelijke spreiding van query's over de 24 uren van de dag, met bijvoorbeeld onverklaarbare pieken

• Query's in batches: veel verzoeken binnen een paar milliseconden gevolgd door perioden waarin geen enkele query wordt verstuurd

• Opmerkelijk gebruik van querytypen, bijvoorbeeld alleen query's op A-records of query's op 4 verschillende recordtypen met precies 25% van de query's per type, terwijl publieke resolvers altijd een 'lange staart' van ongebruikelijke querytypen hebben

• Afwijkingen in andere kenmerken, zoals de spreiding van de beginletters van domeinnamen, de lengte van de namen, of het aantal query's voor de meest opgevraagde namen

• Onjuiste patronen in technische velden (niet-willekeurige query-ID's, niet-willekeurige bronpoorten)

• Schending van conventies of standaarden, zoals onze nameservers vragen om recursie (die autoritatieve nameservers niet uitvoeren), ongeldige query's versturen, meer query's versturen dan toegestaan, dubbele query's versturen, of afgekapte query's niet opnieuw versturen via TCP

Deze patronen komen zowel voort uit de inhoud van de query's als uit de implementaties van de resolvers. Hoewel het eerste inzicht geeft in de intentie, zijn beide relevant, omdat scans vaak pragmatisch zijn en met eenvoudigere software of configuraties werken dan echte recursieve resolvers.

De meeste patronen kunnen worden weergegeven met behulp van histogrammen of met spreidingsdiagrammen zoals figuur 2, waarin elke query is afgebeeld als een stip, de tijd is uitgezet op de x-as en de opgevraagde naam op de y-as, en het querytype is aangegeven met een kleur.

Figuur 2: Scanverkeer is vaak in alfabetische volgorde (diagonale lijnen) en heeft betrekking op specifieke recordtypen (kleur).

Een spreidingsdiagram legt niet alleen de alfabetische volgorde van query's bloot, maar kan ook onregelmatigheden in het queryvolume of de querytypen aan het licht brengen. Het verkeer in het bovenstaande spreidingsdiagram vertoont bijvoorbeeld duidelijk oplopende diagonale lijnen, wat betekent dat de namen werden opgevraagd in de volgorde A-Z, waarbij SOA-query's (donkergroen) later werden verstuurd dan A-query's (paars).

Scans kunnen met 1 maar ook met honderden IP-adressen werken en zelfs gebruikmaken van open resolvers. Ze vallen op 1 of meerdere manieren op, meestal omdat scanverkeer homogener is dan normale query's. Scans zijn moeilijker te herkennen in gemengd verkeer zoals afkomstig van open resolvers.

Het grotere plaatje

In dit onderzoek werden data van 2 verschillende dagen gebruikt: de ene dag voor verkenning en het ontwerpen van de methoden en de andere dag voor een evaluatie die zo onafhankelijk van de eerder geziene data was als mogelijk, om de resultaten te bevestigen.

Het is duidelijk dat dit tot intrigerende analyses kan leiden en veel resultaten kan opleveren. Maar als we een diepgaander inzicht willen krijgen, grotere patronen willen ontdekken en statistieken willen genereren, is het niet genoeg om alleen maar naar voorbeelden te kijken.

Om patronen in de resolverpopulatie te ontdekken, gebruiken we feature vectors die patronen beschrijven die lijken op die hierboven zijn genoemd. Deze features bevatten beschrijvingen van:

• Percentage query's met unieke namen, NX-antwoorden, verschillende querytypen, Punycode, TCP en andere kenmerken

• Lengte van opgevraagde domeinnamen

• Spreiding over de tijd

• Aantal query's per naam

• Queryherhalingen

• En nog veel meer features

We maken gebruik van clustering om groepen vergelijkbare resolvers te vinden, oftewel vergelijkbare vormen van scanning of zelfs bronnen die samen een scan uitvoeren. Het belangrijkste is dat de feature space ons in staat stelt om voorheen ongezien gedrag te detecteren, groepen te onderscheiden en met behulp van gangbare machine learning algoritmen tot een classificatie te komen.

We verwerkten alleen resolvers die meer dan 10.000 query's verzonden, omdat kleinere zelfs handmatig al lastig te classificeren zijn en waarschijnlijk toch geen scans uitvoeren. Wat veel van de features betreft, is het gedrag van de resolvers die eerder in verband werden gebracht met scanning veel diverser (grotere afwijking in de featuredimensies) dan dat van resolvers die niet in verband zijn gebracht met scanning, wat weer minder divers is dan de totale populatie. In figuur 3 zie je een voorbeeld van een feature – de standaardafwijking over de lijst van aantallen die aangeven hoe vaak elke domeinnaam werd opgevraagd – berekend voor 40 willekeurig gekozen bronnen van elk van de 3 typen: scannende bronnen, niet-scannende bronnen en ongelabelde bronnen. Het merendeel van de overige features laat een vergelijkbaar patroon zien, waarbij de standaardafwijking van als scan bestempelde monsters over het algemeen veel groter is dan die van de niet als scan bestempelde monsters.

Figuur 3: Strookdiagram van featurewaarden met voor elke domeinnaam de afwijking van de queryaantallen. Kleur = classificatielabel.

We kunnen ook zien dat elk kenmerk op zichzelf niet voldoende is voor classificatie, omdat er nog steeds een grote overlap is tussen featurewaarden van verschillende klassen. Het is daarom noodzakelijk om meerdere features te gebruiken. Onze interesse ligt bij het achterhalen van verschillende groepen en vormen, en dus passen we met behulp van k-Means clustering op de features toe, na ze te hebben gewogen op basis van de relevantie voor de use case.

We kenden gewichten toe door de relevantie van features te beoordelen en ze vervolgens in 1 van de 5 groepen met exponentieel verdubbelend gewicht of in de groep met uitgesloten features te plaatsen. We voerden tests uit om te bevestigen dat ons vermogen om nauwkeurig onderscheid te maken tussen scans en niet-scans niet significant kon worden verbeterd door een gewicht te veranderen, zodat we een stabiele weging verkregen. De volgende features bleken het meest relevant te zijn:

• Percentage unieke namen

• Percentage query's met respectievelijk responscode 0 en geen respons

• Gemiddelde domeinnaamlengte

• Percentage herhalingen

• Ongebruikelijke spreidingen in tijd, querytypen of beginletters van namen

Figuur 4 toont de feature space en clusters, teruggebracht tot 2 dimensies met behulp van t-SNE. Deze visualisatie laat zien dat het algoritme de verschillende resolvers in afzonderlijke groepen kan opdelen, net zoals een mens groepen punten in de visualisatie kan onderscheiden. Vervolgens inspecteren we elke groep handmatig om scans te identificeren.

Figuur 4: Visualisatie van de feature space teruggebracht tot 2 dimensies. Elk punt is een resolver en elke kleur een cluster.

Resultaten

Naast domaining vonden we nog veel meer vormen van scanning in het verkeer. Bij een aanzienlijk deel gaat het om scanning/enumeratie van subdomeinen, waarbij wordt geprobeerd de subdomeinen van bekende 2LD's te raden, vaak door gebruik te maken van lijsten van veelvoorkomende 3LD's. Dit zou niet zichtbaar moeten zijn op TLD-niveau, omdat het 2LD maar 1 keer hoeft te worden opgevraagd om de nameservers van het 2LD te achterhalen. Gebrekkige of ontoereikende caching kan ertoe leiden dat er toch herhaalde query's naar ons worden gestuurd. Dit zien we vooral in het verkeer dat afkomstig is van open recursieve resolvers. Daartegenover wordt domaining meestal uitgevoerd vanuit de netwerken van hosting-/cloudproviders met behulp van exclusieve IP-adressen.

Andere geïdentificeerde vormen van scanning zijn onder meer monitoring en scannen op vergelijkbare namen. Dit kan worden gedaan om handelsmerken te beschermen of om phishingdomeinen te identificeren. Ook werden er scans voor wetenschappelijke doeleinden aangetroffen van onder meer OpenINTEL, SIDN zelf (DMAP) en TU München. De verwachting was dat er webscraping te zien zou zijn, maar die hebben we niet kunnen identificeren.

Impact op onze nameservers

In totaal werd tijdens het onderzoek ongeveer 12% van al het verkeer gelabeld, waardoor we schatten dat 10 tot 50% van het verkeer verband hield met scanning. Er was een scanoperatie van een subdomein die op zichzelf al verantwoordelijk was voor 4% van het verkeer (250 miljoen query's), terwijl andere scans meestal niet boven de 30 miljoen query's uitkomen. Extrapolatie van de gelabelde data suggereert dat op een gemiddelde dag zo'n 30% van al het verkeer voortkomt uit scanning.

Er zijn ook uitzonderlijke dagen: de DNS-statistieken van de website van SIDN Labs laten een verstoring zien in het verkeer op 21 mei van dit jaar en de reden hiervoor kan eenvoudig worden geïdentificeerd als een scan van zeer grote omvang. Hoewel dit resulteerde in 2,6 miljard extra query's, kon er geen significante toename in de verwerkingstijden van query's worden waargenomen. Hieruit leiden we af dat omvangrijke scans geen nadelige invloed hebben op de serverprestaties en dat rate limiting een effectief mitigatiemiddel is.

Conclusie

Helaas is er niet eerder onderzoek gedaan naar scans in DNS-verkeer, dus er zijn geen cijfers beschikbaar ter vergelijking. Dit onderzoek laat nog veel vragen onbeantwoord en roept veel nieuwe vragen op, maar de resultaten bieden geruststelling dat regelmatige DNS-scanning geen probleem vormt voor de beschikbaarheid van de autoritatieve nameservers van SIDN en waarschijnlijk ook niet voor andere TLD's. Meer informatie over dit onderzoek kun je vinden in mijn master thesis.