NTP: belasting NTP-server meten met Wireshark

Het Network Time Protocol (NTP) is een onderbelicht maar belangrijk internetprotocol. Wireshark biedt een nieuwe functie om de latentie van een NTP-server te achterhalen. Dat klinkt als een niche onderwerp, maar is zowel voor bedrijven als thuisgebruikers handig.

De voorgeschiedenis: servers voor het Network Time Protocol (NTP) waren altijd al interessant. Voor de eerste stappen is een Raspberry Pi met een DCF77- of GPS-ontvanger al voldoende. Een dergelijke combinatie kan bij een lokaal netwerk voor de precieze tijd zorgen. Die kun je ook mee laten doen aan het NTP-pool-project, zodat zijn tijd ook aan andere internetdeelnemers kan worden geleverd.

Maar wat als een Raspberry Pi crasht door de tig-duizend time-requests of hij door de belasting alleen vertraagde antwoorden geeft – ook al zijn die nog acceptabel? Hoe houdt een commerciële NTP-­appliance zoals van specialist Meinberg zich onder die condities? Of een krachtigere server?

Zoeken op internet of zelf aan het rekenen slaan zal je niet veel helpen, je moet dat zelf analyseren. Bij dergelijke netwerkanalyses is Wireshark daar meestal de juiste tool voor. Met die tool kun je door de uitgebreide analysemogelijkheden elk netwerkprotocol scheiden van de grote datastroom. Maar zelfs na lang zoeken vonden we in Wireshark 2 eigenlijk geen functie die simpel en meteen het tijdverschil kan geven tussen een NTP-request en het bijbehorende antwoord.

Waarom de juiste tijd zo belangrijk is

Er hangen meer dingen van de juiste tijd af dan je wellicht zou denken. Als de tijd opeens vijf jaar vooruit zou springen, dan zouden alle TLS-certificaten bijvoorbeeld meteen verlopen zijn. Waarschijnlijk zouden ook veel wachtwoorden niet meer gelden en VPN-tunnels bestaan dan niet meer. Cronjobs verwijderen logs en ook back-ups en andere dingen komen in de war.

Daarom is bij bedrijfsomgevingen het advies redelijk eenduidig: een systeembeheerder moet minstens drie NTP-servers met onafhankelijke tijdbronnen als DCF77, Galileo en GPS gebruiken. Alleen dan is gegarandeerd dat bij het uitvallen van één van de drie servers de andere twee altijd nog steeds gewoon de juiste tijd doorgeven. Als bij slechts twee NTP-servers dan één van de twee een verkeerde tijd levert, weten de NTP-clients in die situatie niet welke van de twee de juiste tijd heeft. Je moet binnen een bedrijfsnetwerk ook met NTP-authenticatie werken om je te wapenen tegen het vervalsen van de tijd. Omdat NTP via het toestandsloze User Datagram Protocol (UDP) verloopt, kan een man-in-the-middle-aanval ongemerkt de tijd vervalsen. En dat kan niet als je de NTP-bron authentiseert en alle apparaten binnen je netwerk je NTP-­server gebruiken in plaats van bronnen op internet.

Voor privégebruik lijkt het misschien alleen leuk om een eigen server te gebruiken. Maar ook daar verhindert een eigen NTP-server aanvallen en verstoringen door een verkeerde tijd. Dan krijgen bijvoorbeeld IoT-apparaten die geen eigen interne klok hebben, toch de juiste tijd, ook als de internetverbinding uitvalt. Dat is belangrijk voor home-automation en het automatisch openen en sluiten van deuren. Op weberblog.net/ntp staan een aantal posts over het opzetten van een eigen NTP-server en een vergelijking met commerciële producten, naast andere details over het onderwerp NTP – zowel voor privé als bedrijfsmatig gebruik.

Beide typen berichten (NTP-request en -antwoord) zijn bij Wireshark te herkennen aan de hand van de ntp.flags.mode (meer over het protocol). Client-messages zijn gekenmerkt door ntp.flags.mode == 3 en server-messages met ntp.flags.mode == 4. Daarbij is de verstreken tijd tussen het versturen van de vraag en het ontvangen van het antwoord van belang. Het probleem daarbij is dat die twee logisch bij elkaar horende pakketten bij een trace eigenlijk zelden op volgorde voorkomen.

Daarom is ook de algemene functie ‘Delta Time’, die de tijdafstand tussen twee pakketten aangeeft, niet bruikbaar. Daar heb je alleen wat aan als de vraag en het antwoord in een tracefile na elkaar volgen. Er waren al wel adequate functies voor DNS (dns.time) en voor HTTP (http.time), maar blijkbaar nog niet voor NTP. Dat was een goede reden eens contact op te nemen met de Wireshark-ontwikkelaars om een feature-­request te sturen. We hadden geen idee hoe moeilijk dat zou zijn, omdat we zelf geen programmeur zijn en naast het idee en een beschrijving er niet veel aan toe kunnen voegen. Het was maar te hopen dat iemand uit de community dat probleem op zou pikken.

Tot onze grote verrassing verliep dat (na een paar weken wachten) echter geheel anders: er namen met­een drie respectabele ‘Core Developers’ deel aan de discussie en die zagen in het idee de antwoordtijden te analyseren meteen ook een bredere toepassing: ‘Nice feature, we need this for many more protocols, but let’s start with ntp.’
Zo gezegd zo gedaan: een van de volgende ‘auto­mated builds’, oftewel een testversie, kreeg al de analyse­functie ‘ntp.delta_time’. Wow! En sinds versie 3.0 behoort die tot de standaardfuncties van Wire­shark. We konden nu eindelijk de responstijden van onze NTP-servers in de NTP-pool vergelijken.

Het analyseren van de NTP-delta-time is daarbij op meerdere plekken te gebruiken: Wireshark laat in het algemeen extra berekende waarden zien bij ‘Packet Details’ tussen rechthoekige haakjes. Via een gebruikersgedefinieerde kolom met het veld ‘ntp.delta_time’ is die aan de pakketlijst toe te voegen – heel handig voor het overzicht. En met het commando ‘I/O-Graph’ in het menu ‘Statistics’ kun je de data grafisch laten weergeven. Met hulp van de Y-as en de Y-velden geeft Wireshark de responstijden van een NTP-server op de tijd-as weer. Een beeld zegt tenslotte meer dan duizend woorden.

De oudere Delta-Time-functies kun je gewoon blijven gebruiken. Is je DNS-resolver aan de langzame kant? Kijk dan eens naar ‘dns.time’. Worden de webpagina’s van je oude Raspberry Pi met een slakkengang opgebouwd? Ga eens te rade bij ‘http.time’. En omdat de eerste steen gelegd is, kunnen in de toekomst meer protocollen van dergelijke functies voorzien worden.

Linksonder toont Wireshark de berekende Delta Time tussen een NTP-request en -respons. Rechtsboven staan de resultaten in een extra kolom.

De NTP-pool

Het project pool.ntp.org is een vrijwillig samenwerkingsverband van meerdere honderden NTP-servers. Het gaat daarbij om een virtueel cluster van een groot aantal servers die NTP-diensten aanbieden. Om een NTP-server aan de pool toe te voegen, moet hij wel via een statisch openbaar IP-adres bereikbaar zijn. Een voor de pool geschakelde load-balancer regelt dan met de round-­robin-methode naar welke van de vele IP-adressen een DNS-request naar nl.pool.ntp.org of be.pool.ntp.org gaat verwijzen.

Veel Linux-distributies gebruiken de pool standaard, en daardoor dan ook veel Internet-of-Things-­apparaten zoals je router en smart-tv. Privégebruikers met een statisch IP-adres en systeembeheerders van een bedrijf met de benodigde resources zijn welkom om aan de pool deel te nemen en daarmee het community-concept van internet te promoten. Vooral in België zijn meer servers nodig.

De antwoordtijden van NTP-servers variëren tussen de 6 tot 10 milliseconden, maar dat kan oplopen tot wel 50 milliseconden als de server het druk heeft.

Als je de pakketten niet op de ntp-client logt, wijken de gemeten waarden wel af van de daadwerkelijke tijdsduur. Die discrepantie wordt des te groter naarmate het station waar je de data van logt verder van de client verwijderd is. Maar als het om een inschatting van de performance van een server gaat, speelt dat geen rol. In plaats daarvan moet je zo dicht mogelijk bij de server zelf meten om latentie­schommelingen door extra netwerkelementen als routers te minimaliseren.

Ook de kwaliteit van de opgeslagen tracefile is van belang. Als je betrouwbare packet-captures nodig hebt, die alle pakketten een voor een in de juiste volgorde bevatten met een nauwkeurig tijdstempel, dan kom je niet om een professionele netwerk-tap heen. Daar is bijvoorbeeld de ProfiShark 1G geschikt voor. Die gebruikt USB 3.0 om traces op de pc op te slaan – hij gebruikt dan verder dus geen andere netwerkpoorten en vormt ook geen extra belasting voor de netwerkkaart van de pc.

Bij de jaarlijkse Wireshark-conferentie eind 2018 (SharkFest), kwamen we in gesprek met een paar Core-­ontwikkelaars. Ze waren allemaal erg geïnteresseerd en gemotiveerd om Wireshark voorwaarts te stuwen. Aan de andere kant kunnen ze allemaal niet weten met welke details de Wireshark-gebruikers zich bezighouden. De algemene teneur was dan ook dat als gewone systeembeheerders als jij en wij nog ideeën of feature-requests hebben, dan graag! De ontwikkelaars kunnen niet wachten om nieuwe functies te implementeren en bugs te verhelpen. We zullen zelf in de toekomst in elk geval sneller aan de bel trekken bij ontbrekende functies of incomplete protocol­analyses.

(Johannes Weber en Noud van Kruysbergen, c’t magazine)