Afstudeeronderzoek: Een dag in het leven van NTP: een analyse van verkeer via de NTP-pool
Uit uitgebreide analyse blijkt dat NTP Pool een cruciale service levert aan gebruikers, maar dat er dringend behoefte is aan meer servers
Kies jouw kleur
Veel bezocht
Veelgestelde vragen
Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).
Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.
Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.
Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.
Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.
Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.
Uit uitgebreide analyse blijkt dat NTP Pool een cruciale service levert aan gebruikers, maar dat er dringend behoefte is aan meer servers
De oorspronkelijke blog is in het Engels. Dit is de Nederlandse vertaling. Exacte tijdsbepaling is van cruciaal belang voor het functioneren van applicaties en protocollen in gedistribueerde netwerken en dat geldt al helemaal voor het internet. Het standaardprotocol voor de tijdsynchronisatie tussen servers en peers op het internet is het Network Time Protocol (NTP). NTP wordt gewoonlijk niet geauthentiseerd en is daarom gevoelig voor aanvallen, ook al zijn er allerlei uitbreidingen en toevoegingen om het protocol veiliger te maken. Er zijn meerdere publieke tijdproviders die NTP-servers beschikbaar stellen die clients kunnen gebruiken om de tijd te synchroniseren. Een daarvan is het uit vrijwilligers bestaande NTP Pool Project. Dit project maakt gebruikt van DNS om clients toe te wijzen aan de dichtstbijzijnde NTP-server.
SIDN Labs werkt met meerdere NTP-servers mee aan het NTP Pool Project. Een van die servers is door middel van anycast actief op 30 locaties en bedient miljoenen clients. Er is nog niet veel onderzoek gedaan naar de kenmerken van verkeer dat binnenkomt op een publieke NTP-server. Het analyseren van het verkeer dat binnenkomt op de anycast-NTP-server van SIDN in de NTP-pool kan een positieve bijdrage leveren door licht te werpen op de kenmerken van inkomend verkeer. Dit kan bijvoorbeeld nuttige informatie opleveren over de soorten clients die van de NTP-dienst gebruik maken, de catchments van de anycast-locaties, de aanwezigheid van onregelmatigheden in het NTP-verkeer, enzovoort. Deze informatie kan veel vertellen over de huidige staat van het NTP-ecosysteem.
Het Network Time Protocol (NTP) wordt gebruikt om "de tijdregistratie tussen een aantal gedistribueerde tijdservers en clients te synchroniseren" [RFC 5905] en is het protocol dat op het internet standaard wordt gebruikt voor tijdsynchronisatie. NTP werkt boven op het Internet Protocol (IP) en User Datagram Protocol (UDP) en is essentieel voor de gedistribueerde werking van machines in netwerken.
De NTP-architectuur heeft een boomstructuur waarin elk niveau een stratum is (genummerd vanaf 1) dat bestaat uit servers. De nauwkeurigheid van een server hangt samen met hoe hoog deze zich in de boom bevindt: een server op een hoger niveau (die dus een lager stratumnummer heeft) is nauwkeuriger dan een server op een lager niveau, als gevolg van netwerkpaden en lokale klokinstabiliteit. Servers in stratum 1 (primaire servers) synchroniseren hun tijd rechtstreeks met een autoritatieve bron zoals een atoomklok of GPS, servers in stratum 2 (secundaire servers) synchroniseren de tijd met de servers in stratum 1, en ga zo maar door. De andere kant van het NTP-ecosysteem bestaat uit clients die gebruik maken van NTP-servers om hun klokken mee gelijk te zetten. De clients die gebruik maken van NTP zijn uitermate divers en variëren van servers en computers tot IoT-apparaten en mobiele telefoons.
Het NTP Pool Project is een tijdprovider die de tijd verstrekt aan naar schatting 5 tot 15 miljoen clients. De NTP-pool bestaat uit een bestand van meer dan 4.500 servers over de hele wereld en is de standaard tijdprovider voor een groot aantal leveranciers, waaronder Android, Linux, Asus, enzovoort. In tegenstelling tot andere publieke tijdproviders host het project geen eigen servers, maar houdt het een lijst bij van door vrijwilligers beheerde servers met de bedoeling het gemakkelijker te maken om via DNS toegang tot deze servers te krijgen.
SIDN Labs draagt bij aan de NTP-pool door servers beschikbaar te stellen die een enorme populariteit genieten binnen de pool en miljoenen clients over de hele wereld bedienen. Een van deze servers, any.time.nl, bedient zowel IPv4- als IPv6-clients en wordt door middel van anycast op 30 locaties ingezet.
Het is dus de bedoeling om het NTP-verkeer te karakteriseren dat binnenkomt op één anycast-server die deel uitmaakt van de NTP-pool. Dit gebeurt door 24 uur lang gegevens te verzamelen op alle 30 locaties van de NTP-server. Vervolgens worden de verzamelde gegevens gecentraliseerd, voorbewerkt om relevante velden te extraheren, verrijkt met informatie over de geolocatie en geanalyseerd om waardevolle inzichten in het NTP-ecosysteem te verkrijgen.
De dataset die voor dit onderzoek is gebruikt, bestaat uit packet captures van alle 30 anycast NTP-servers in het bestand van de NTP-pool. De servers ontvangen verkeer van clients die de NTP-pool gebruiken als hun NTP-provider.
Het NTP-verkeer dat op 22 en 23 juni op de servers binnenkwam, werd 24 uur lang vastgelegd met behulp van tcpdump. Uit de vastgelegde PCAP-bestanden werden relevante IP-, UDP- en NTP-gegevens geëxtraheerd en vervolgens verrijkt met informatie over de geolocatie van de clients, zoals stad, land, AS-nummer en fysieke IP-coördinaten. Die informatie was afkomstig uit de op dat moment meest recente geolocatiedatabases van Maxmind. Vervolgens werden de IP-adressen in de verzamelde bestanden geanonimiseerd met behulp van het crypto-Pan-algoritme. Deze anonimisering was in lijn met het privacybeleid van SIDN en goedgekeurd door SIDN's privacyboard.
In totaal werd ongeveer 4,7 TB aan gegevens verzameld, die verspreid over de 30 servers 13,67 miljard NTP-query's en -antwoorden bevatten. Daaronder bevonden zich 7,28 miljard clientquery's van ~158,7 miljoen unieke clients. Het gros hiervan was IPv4-verkeer (97,3%) en de rest was IPv6.
Totaal aantal query's | 7.283.163.487 |
Totaal aantal clients | 158.711.167 |
IPv4-clients | 132.123.933 |
IPv6-clients | 26.587.234 |
We analyseerden het gebruik van de NTP-servers om te achterhalen welke server/anycast-locatie binnen het NTP-ecosysteem het meest in trek was. Deze analyse geeft een idee van de onderliggende clientspreiding op het internet. Om het gebruik van NTP-servers te bepalen, werden de geaggregeerde gegevens ingedeeld in ontvangen query's per server.
Het is duidelijk dat vooral de anycast-locaties in Azië in trek zijn binnen de NTP-pool. De servers {bom1-1, bom1-2} bedienen samen meer dan 1,59 miljard clientquery's van 28,4 miljoen clients. Dit komt neer op zo'n 22% van het totale verkeer dat op any.time.nl binnenkomt. Andere servers in Azië ontvangen eveneens aanzienlijk meer verkeer dan hun tegenhangers in Noord-Amerika en Europa, zoals blijkt uit het aantal query's dat binnenkwam op nrt1-{1-8}, icn1-1 en sin1-{1-2}.
De NTP-server sea1-1 komt naar voren als een van de meest gebruikte servers in Noord-Amerika met ongeveer evenveel inkomend verkeer als bom1-{1-2}. Gerekend over alle 7 Noord-Amerikaanse locaties is sea1-1 goed voor 49,3% van het verkeer. Over het totale verkeer op alle 30 locaties is dat 10,5%. Een nadere blik op de geografische spreiding van de clients die deze server gebruiken, onthult dat het merendeel van het verkeer dat op deze server binnenkomt afkomstig is uit China. In de waargenomen periode ontving sea1-1 meer dan 5 keer zoveel verkeer uit China als uit de Verenigde Staten en Canada.
We analyseerden het servergebruik ook door te kijken naar het aantal query's dat elke anycast-server per uur ontving. De bovenstaande afbeelding toont voor elke NTP-server het aantal query's per uur. De Y-as heeft een logaritmische schaal om de onderlinge verschillen in queryaantallen beter weer te geven.
Aan het begin tekenen zich enkele patronen af, vooral met betrekking tot de Aziatische NTP-servers. In de nachtelijke uren is er een duidelijke dip in het aantal query's waar te nemen. Dit suggereert dat het aantal clients dat 's nachts NTP-query's verstuurt lager ligt dan overdag. Het verkeer op de Europese en Amerikaanse locaties blijft daarentegen de hele dag door vrij constant. Deze waarneming is in overeenstemming met eerdere onderzoeken naar dag- en nachtpatronen van internetverkeer.
Een ander belangrijk aspect van de implementatie van anycast betreft de catchments van anycast-locaties. In RFC 4786 Operation of Anycast Services wordt een anycast-catchment gedefinieerd als "het topologische gebied van een netwerk waarbinnen pakketten die aan een anycast-adres zijn gericht naar één bepaalde node worden gerouteerd". Het bestuderen van de catchments van een implementatie geeft dus een beeld van het onderliggende routeringsgedrag op het internet en kan helpen om de anycast-implementatie te finetunen zodat clients efficiënt worden bediend.
De meest recente catchments van anycast-locaties vind je hier: http://dnstest.nl/anycast2020/heatmaps/
Anycast-catchments zijn niet statisch en het catchment van een locatie kan op verschillende manieren worden beïnvloed. Zo hebben de catchments van sommige locaties inmiddels verbeteringen ondergaan en ontvangen ze nu alleen nog verkeer uit eigen land.
Figuur 3: Aantal query's per land.
China heeft het grootste aantal clients (28 miljoen), op de voet gevolgd door Brazilië, India, de VS en Zuid-Korea. De clients in China genereren maar liefst 3,5 miljard query's, wat neerkomt op een gemiddelde van 126 query's per client. Hoewel China maar 8 miljoen clients meer heeft dan Brazilië, genereren die clients 7,8 keer zoveel query's als de clients in Brazilië. Maar hoewel Brazilië 2,2 miljoen clients meer heeft dan India, worden er in India toch 1,3 keer zoveel query's gegenereerd als in Brazilië. In vergelijking met de andere toplanden heeft Brazilië in het algemeen een laag gemiddeld aantal query's per client. Dit houdt in dat Brazilië weliswaar het op een na grootste aantal clients heeft, maar dat die clients niet zoveel query's genereren als clients in andere landen. Ook Japan heeft een hoge querydichtheid die gegenereerd wordt door een relatief klein aantal clients. Van alle landen in de top 10 heeft Japan het op een na hoogste gemiddelde aantal query's per client: bijna 50. Alleen in China ligt het gemiddelde hoger.
NTP-versie | Aantal query's | % van totaal aantal query's | % IPv4 query's | % IPv6 query's | Aantal clients |
---|---|---|---|---|---|
4 | 5.942.781.255 | 81,59 | 98,07 | 1,92 | 45.037.414 |
3 | 1.292.326.962 | 17,74 | 93,63 | 6,36 | 127.218.626 |
1 | 43.996.867 | 0,6 | 99,99 | 0,005 | 6.967.648 |
2 | 2.535.364 | 0,03 | 99,7 | 0,29 | 37.055 |
NULL | 1.420.042 | 0,02 | 99,99 | ≈0 | 39.905 |
0 | 86.725 | 0,001 | 99,99 | 0,002 | 4.723 |
6 | 8.737 | 0,0001 | 98,24 | 1,75 | 1.180 |
7 | 4.397 | ≈0 | 99,97 | 0,02 | 926 |
5 | 3.138 | ≈0 | 98,94 | 1,05 | 810 |
De bovenstaande tabel laat de verdeling van NTP-versies onder clients zien, inclusief het percentage IPv4- en IPv6-query's en het aantal clients voor elke NTP-versie. Zoals verwacht is NTP-versie 4 de versie die het meest door clients wordt gebruikt: 81% van het totaal aantal query's gebruikt versie 4. De RFC met betrekking tot NTPv4 werd voorgesteld in 2010 en aangenomen in 2011. In deze nieuwste versie van NTP zijn veel beveiligingsproblemen opgelost die aanwezig waren in eerdere versies van het protocol. In een vergelijkbaar onderzoek naar de kenmerken van NTP-verkeer dat enkele jaren geleden werd uitgevoerd, werd geconstateerd dat clients in Azië voornamelijk NTPv3 gebruikten (68%). Dat aantal is echter gedaald: in onze dataset maakte maar 17% nog steeds gebruik van NTPv3. 82% van de clients in Azië gebruikt nu NTPv4 en voor de andere continenten gelden vergelijkbare percentages. Al met al vertoont de NTPv4-adoptie dus een stijgende lijn en dat is een goede zaak, omdat het betekent dat clients de meest recente NTP-versie gebruiken.
Verder stuurden meer dan 7.000 clients meer dan 100.000 query's met de ongeldige NTP-versienummers 0, 5, 6 en 7. De meeste clients die ongeldige NTP-versienummers gebruiken, lijken zich te bevinden in de VS en Canada, met meer dan 48.000 query's uit de VS en 16.000 query's uit Canada. Het gebruik van dergelijke NTP-versienummers is in strijd met de protocolspecificatie. Ook waren er bijna 40.000 clients die NTP-pakketten verstuurden waarin geen NTP-versie was gespecificeerd of een 'malformed' pakket waaruit de NTP-versie niet kon worden geëxtraheerd. Deze query's worden in de bovenstaande tabel weergegeven als NTP-versie 'NULL'. Op alle NTP-servers bij elkaar kwamen meer dan 1 miljoen van dit soort query's binnen. Het merendeel van het verkeer met NTP-versie NULL kwam uit Brazilië, India, de VS, Argentinië en Spanje. Deze 5 landen produceerden samen meer dan 900.000 van de 1 miljoen query's. De NTP-versiegegevens laten dus zien dat hoewel de meeste clients zich aan de protocolspecificaties houden, er nog steeds op grote schaal gebruik wordt gemaakt van oudere NTP-versies (met name NTPv3).
We pasten passieve fingerprinting toe aan de hand van de IP-TTL-waarden (time-to-live) in de NTP-pakketten van de clients om meer inzicht te krijgen in de besturingssystemen en NTP-softwarestacks die door clients worden gebruikt. Hoewel de verkregen informatie misschien niet in alle gevallen accuraat is, geeft deze een rudimentair inzicht in de kenmerken van clients. De onderstaande tabel toont de verdeling van de waargenomen TTL-waarden voor IPv4-clients. Zoals verwacht hebben de meeste clients (89%) een op Linux gebaseerd besturingssysteem, dat standaard een TTL-waarde van 64 heeft. Dat komt doordat apparaten zoals routers, firewalls, Android-telefoons, IoT-apparaten, enzovoort allemaal gebaseerd zijn op de Linuxkernel en waarschijnlijk de meerderheid uitmaken van de NTP-clients van de NTP-pool. Een op grote schaal gebruikt besturingssysteem als Windows beschikt namelijk over een eigen NTP-dienst die de standaardprovider is voor alle op Windows gebaseerde apparaten. Dit verklaart het gebrek aan Windows-apparaten in deze dataset.
TTL | Aantal query's | % van totaal aantal query's |
---|---|---|
64 | 6.341.304.476 | 89,48 |
255 | 691.301.924 | 9,75 |
128 | 52.525.409 | 0,74 |
32 | 1.439.713 | 0,02 |
IP-adres van de client | Query's | Tijdskader | Query's per seconde | Reacties | % Reacties per seconde | Land |
---|---|---|---|---|---|---|
192.33.151.159 | 8.713.100 | 87830 | 99,20 | 5.974 | 0,068 | KR |
25.193.210.30 | 7.571.623 | 87551 | 86,48 | 84 | 0,001 | PH |
5.52.96.86 | 6.313.197 | 87838 | 71,87 | 227 | 0,0035 | KR |
178.20.203.52 | 5.501.880 | 85854 | 64,08 | 1.067 | 0,019 | JP |
95.8.85.197 | 5.490.735 | 87838 | 62,50 | 0 | 0 | ZA |
217.18.48.60 | 4.843.415 | 87838 | 55,14 | 2.299 | 0,047 | KR |
16.230.152.164 | 4.183.282 | 61968 | 67,50 | 4.579 | 0,1 | IN |
192.115.161.111 | 3.048.685 | 87838 | 34,70 | 0 | 0 | KR |
10.104.238.155 | 2.614.373 | 85183 | 30,69 | 1.377 | 0,05 | SG |
10.224.182.21 | 2.572.870 | 87838 | 29,2 | 344 | 0,013 | KR |
NTP-serveroperators constateren vaak dat NTP-clients meer query's naar servers sturen dan zou moeten. Dit suggereert dat clients zich niet houden aan de waarde in de pollinterval of KoD-pakketten. Om dit fenomeen nader te onderzoeken en malafide clients op te sporen, analyseerden we hoeveel query's elk client-IP verstuurt en hoelang het client-IP zichtbaar blijft. De bovenstaande tabel toont de top 10 van IP's wat betreft het aantal verstuurde query's en de tijd (in seconden) dat de adressen zichtbaar blijven. Zoals eerder vermeld, zijn alle IP-adressen geanonimiseerd. Het bovenste IP verstuurde gedurende de gehele waargenomen dag in totaal 8,7 miljoen query's, met een gemiddeld aantal query's per seconde van bijna 100. Dat is een stuk hoger dan de laagste NTP-minpoll-instelling van 4, die neerkomt op 1 query per 16 seconden. Het werkelijke aantal query's dat van het bovenste IP is ontvangen, komt neer op 1.600 keer zoveel query's als de client mag verzenden. Dat is duidelijk geen normaal clientgedrag. Een mogelijke verklaring voor het excessieve aantal query's zou kunnen zijn dat de client-IP's toebehoren aan ISP's die gebruik maken van Carrier-Grade NAT (CGNAT). Het gebruik van CGNAT komt met name veel voor op continenten zoals Azië, waar het grote aantal gebruikers ISP's dwingt CGNAT te gebruiken om te voorkomen dat ze zonder publieke IPv4-adressen komen te zitten. CGNAT is een techniek waarbij achter één publiek IP grote aantallen gebruikers schuilgaan. In dit geval kunnen er wel duizenden clients achter één en hetzelfde IP zitten, die allemaal NTP-query's versturen. Als we kijken naar de pollinterval die de servers specificeren in de antwoorden aan deze IP's, is 4 de meest gebruikte waarde en specificeren de NTP-servers voor sommige IP's zelfs een pollinterval van 17. Als een IP een antwoord krijgt met een pollinterval van 17, mag het minimaal 1,5 dag geen NTP-query's meer versturen. Maar het is duidelijk dat client-IP's zich weinig aantrekken van de waarden voor de pollinterval die in de antwoorden zijn gespecificeerd, zoals blijkt uit het aantal query's dat naar NTP-servers wordt verstuurd. Als CGNAT of een andere NAT-techniek wordt gebruikt, kan het zijn dat het NAT-apparaat niet de mogelijkheid heeft om rekening te houden met de pollinterval, aangezien het enkel de verzoeken van de clients erachter doorstuurt. Niettemin is het overduidelijk dat clients excessieve aantallen query's naar NTP-servers versturen, ook al is er in het antwoord dat naar de client wordt verzonden een maximale pollinterval gespecificeerd. Dit betekent dat clients in termen van het versturen van gepaste aantallen query's niet handelen in overeenstemming met de RFC.
Het is belangrijk om te vermelden dat de IP's zelf geanonimiseerd zijn, maar dat de geolocaties en ASN-informatie aan de dataset zijn toegevoegd voordat de anonimisering werd uitgevoerd. Het bovenste IP behoort toe aan LG DACOM Corporation in Zuid-Korea. De WHOIS-informatie voor dit AS-nummer leert dat het hier gaat om een van Korea's grootste exploitanten van een telecomnetwerk. We kunnen daarom redelijkerwijs concluderen dat dit IP waarschijnlijk een publiek NAT-IP is dat door enorme aantallen mobiele clients wordt gebruikt om de tijd te synchroniseren. Iets dergelijks geldt voor het tweede IP, dat toebehoort aan het AS-nummer van een ISP in de Filipijnen. Dit IP is dus het NAT-IP van de gebruikers van de ISP. Van de 10 IP's die de meeste query's versturen, bevinden zich er 9 in Azië, waaronder 5 in Zuid-Korea. De enige uitzondering is een IP in Zuid-Afrika. Nadat we het AS-nummer van dit IP hadden geïdentificeerd, kwamen we met behulp van WHOIS uit bij de website van het bedrijf. Het Zuid-Afrikaanse IP behoort toe aan de exploitant van een populair mobiel netwerk, net zoals het eerste IP. De IP's op de derde en tiende plaats, allebei Zuid-Koreaans, zijn ook van een netwerkexploitant, te weten Korean Telecommunications Authority (KT), terwijl het vierde adres (uit Japan) toebehoort aan NTT. In feite behoren alle IP's in de top 10 toe aan ISP's en exploitanten van mobiele netwerken. We kunnen er dan ook zeker vanuit gaan dat al die IP's niet van de clients zelf zijn, maar dat het gaat om NAT-IP's waarachter vele duizenden clients schuilgaan.
NTP is gebruikt bij meerdere DDoS-amplificatie- en reflectieaanvallen. Dit komt doordat NTP, net als DNS, hoofdzakelijk een op UDP gebaseerd protocol is, waardoor aanvallers in staat zijn om query's te spoofen. Bovendien bevat NTP bepaalde query's die antwoorden retourneren waarvan de pakketgrootte veel groter is dan de verzoeken, zoals monlist, peerlist enzovoort. Hierdoor kunnen aanvallers kleine gespoofte verzoeken met het IP-adres van een slachtoffer creëren en deze verzoeken naar publieke NTP-servers sturen. De publieke servers sturen dan grote antwoorden naar het slachtoffer, dat wordt overspoeld met grote hoeveelheden ongevraagd verkeer, die een DDoS- of DoS-aanval vormen.
De query's monlist en peerlist zijn query's die speciaal voor serverbeheerders in het protocol zijn ingebouwd om problemen op te lossen of diagnostische informatie van hun NTP-servers te verkrijgen. Anders dan bij het client-servermodel, waarbij een client een pakket verzendt met NTP mode 3, maken deze query's gebruik van NTP mode 7, die in de RFC wordt omschreven als "gereserveerd voor privégebruik". Het is dus niet echt de bedoeling dat NTP mode 7 door clients wordt gebruikt om te communiceren met een publieke server. Toen op NTP gebaseerde DDoS-aanvallen op hun hoogtepunt waren, waren er echter honderdduizenden publieke NTP-servers die publiek gebruik van mode 7 ondersteunden. Na verloop van tijd begonnen serverbeheerders mode 7 uit te schakelen voor publieke clients, zodat hun servers niet kwetsbaar waren. Niettemin zijn er nog steeds kwetsbare NTP-servers en kwaadwillende actoren die erop uit zijn om bij allerlei aanvallen misbruik van deze servers te maken.
IP-adres van de client | Query's | Anycast-site | Land |
88.162.105.2 | 999 | mia1-1 | US |
195.158.75.168 | 507 | sjc1-1 | US |
212.252.246.84 | 258 | lhr1-1 | FR |
195.158.90.138 | 257 | sjc1-1 | US |
84.67.213.125 | 144 | cdg1-1 | GB |
194.111.154.223 | 142 | ord1-1 | US |
217.57.175.119 | 124 | sin1-1 | LA |
217.57.175.119 | 106 | sin1-2 | LA |
189.184.250.159 | 67 | mia1-1 | US |
88.53.68.117 | 65 | mia1-1 | BR |
Aangezien de problematische query's een aparte NTP-bedieningsmodus (mode 7) gebruiken, is het vrij eenvoudig om clients te identificeren die deze query's naar any.time.nl sturen. In de verzamelde dataset werden in totaal 8.136 query's verzonden door 1.021 clients verspreid over de 30 servers. De bovenstaande tabel toont de 10 IP’s die de meeste mode-7-query’s verstuurden, samen met de anycast-site die de IP’s bereikten en het land waar het IP vandaan komt. Hoewel IP 88.162.105.2 (geanonimiseerd) bijna 1.000 query's naar de locatie mia1-1-verstuurde, blijkt uit nadere analyse van de query's dat het IP ook 3 tot 5 query's naar elk van de andere 29 locaties verstuurde. Dat is geen normaal gedrag: als een client eenmaal naar een bepaalde locatie is gerouteerd, behoren volgende query's naar die locatie te worden verstuurd. Natuurlijk zijn er soms uitzonderingen waarin clients ook query's naar andere locaties in hetzelfde land kunnen versturen, zoals bij sin1-1 en sin1-2. Op het eerste gezicht lijkt dit op verdacht gedrag en typisch iets voor een scanner. Uit analyse van de temporele spreiding van mode-7-query's afkomstig van de IP's in kwestie blijkt dat de IP's de mode-7-query's in afzonderlijke bursts versturen. Sommige IP's, zoals 195.158.90.138, zijn de hele dag maar één keer actief, terwijl andere, zoals 195.158.75.168, 2 bursts in 24 uur versturen. Verder zijn er, anders dan bij een normaal patroon van clientverkeer, perioden waarin de verdachte IP's geen enkel verzoek versturen. In combinatie met het feit dat de reputatiescores voor het AS-nummer van de IP's een hoge mate van spam-activiteit laten zien, suggereert dit dat de IP's in kwestie toebehoren aan scanners die de IPv4-ruimte afzoeken op kwetsbare NTP-servers.
Aangezien NTP net als DNS een van de kernprotocollen van het internet is en daarmee cruciaal voor het functioneren van apparaten, zijn de gegevens die in mijn onderzoek zijn verzameld in zoverre waardevol dat ze een grondige analyse van de staat van het huidige NTP-ecosysteem mogelijk maken. Uitgebreide analyse van de gegevens laat zien dat de NTP-pool gebruikers een cruciale dienst verleent, maar grote behoefte heeft aan meer servers voor het afhandelen van NTP-verkeer buiten Noord-Amerika en Europa, met name in Azië en Afrika. De anycast-server van SIDN levert een essentiële bijdrage met betrekking tot het aanpakken van dit gebrek aan servers. Er zijn dringend meer van dit soort initiatieven nodig. De implementatie van anycast blijkt uitermate geschikt te zijn om de vraag van clients in het huidige NTP-ecosysteem af te handelen, vooral omdat hiermee locaties worden bediend die niet veel andere NTP-serveropties tot hun beschikking hebben. Mijn resultaten laten ook zien dat hoewel de adoptie van de meest recente NTP-versie is toegenomen in vergelijking met voorgaande jaren, een aanzienlijk deel van de clients nog steeds met verouderde NTP-versies werkt. Veel clients gedragen zich niet in lijn met de RFC en specificeren gereserveerde of onjuiste waarden in NTP-pakketten. Verder wordt het gebruik van NTP actief belemmerd door de architecturale ontwerpen die door veel ISP's en netwerkproviders worden gebruikt en waardoor servers worden overspoeld door excessieve aantallen NTP-query's. Een ander probleem is dat met de huidige architectuur de ingebouwde frequentielimieten voor servers niet effectief zijn en afbreuk doen aan hoe de client het gebruik van het protocol ervaart. Tot slot leidde analyse van in de dataset aangetroffen sporen van kwaadaardig verkeer tot de conclusie dat NTP nog steeds een rendabele aanvalsvector is en serverbeheerders stappen dienen te ondernemen om hun implementaties te beschermen.
De volledige versie van mijn afstudeeronderzoek is beschikbaar op de website van SIDN Labs. Hierin vind je een veel gedetailleerdere analyse van de waarnemingen en wordt ingegaan op diverse andere punten. Een interessant eerder onderzoek op het gebied van de karakterisering van NTP-verkeer is Masters of Time: An Overview of the NTP Ecosystem door Rytilahti e.a.
Artikel door:
Deel dit artikel