NTP server beveiligen tegen DDoS-versterking

NTP server beveiligen: configuratie, controles en maatregelen tegen misbruik

Een NTP-server is een tijdserver die via het Network Time Protocol klokken synchroniseert. Bij verkeerde instellingen kan hij onbedoeld meewerken aan een DDoS-aanval door vervalste verzoeken te beantwoorden. Een NTP server beveiligen begint daarom bij toegangsregels, beheerfuncties en UDP-poort 123. Zo kan een server correcte tijd leveren, terwijl dezelfde server ongewenst verkeer naar een slachtoffer stuurt.

Publieke bereikbaarheid blijft een aandachtspunt bij cloudservers, routers en oudere netwerkapparaten. Bovendien kan een nieuwe firewallregel een eerder afgeschermde tijdservice alsnog bereikbaar maken. Controleer dus zowel de NTP-software als de netwerklaag, inclusief IPv6. Misbruik vereist namelijk niet altijd een gestolen wachtwoord of geïnstalleerde malware.

Deze beheerdershandleiding behandelt risicovolle instellingen, configuratievoorbeelden en veilige controles vanaf een toegestaan extern netwerk. Vervolgens leer je pakketmetingen beoordelen en onderscheid maken tussen een reflector en een slachtoffer. De voorbeelden richten zich op klassieke ntpd, chrony en Linux-firewalls. Daarbij krijg je ook grenzen mee: één geslaagde test bewijst geen volledige bescherming.

Wanneer kan jouw NTP-server als reflector worden misbruikt?

Een NTP-server kan als reflector dienen wanneer hij verzoeken uit een ongewenst netwerk ontvangt en daarop antwoorden verstuurt. Voor sterke vergroting van het verkeer spelen vooral oude beheerfuncties een rol, zoals monlist. Publieke bereikbaarheid alleen bewijst dus geen groot versterkingsrisico. Wil je een NTP server beveiligen, beoordeel dan bereikbaarheid, beschikbare functies en antwoordvolume afzonderlijk.

Waarom maakt UDP-poort 123 bronvervalsing mogelijk?

UDP is een transportprotocol dat datagrammen verstuurt zonder vooraf een verbinding met de ontvanger op te bouwen. NTP gebruikt normaal UDP-poort 123 aan de serverkant. Anders dan bij een TCP-handshake hoeft de aanvrager daardoor niet eerst te bewijzen dat hij het bronadres ontvangt. De tijdserver stuurt zijn antwoord naar het adres in het ontvangen pakket.

IP spoofing is het vervalsen van het bron-IP-adres in netwerkpakketten. Bij reflectiemisbruik vult de aanvaller het adres van het slachtoffer in, waardoor de NTP-server het antwoord daarheen stuurt. Een uitleg van vervalste bronadressen en hun risico’s helpt dit mechanisme herkennen. Het slachtoffer hoeft zelf geen NTP-server te draaien.

Het pakketpad bestaat uit 3 rollen: aanvaller, reflector en slachtoffer. De aanvaller stuurt een vervalst verzoek naar de reflector; de reflector stuurt vervolgens een antwoord naar het slachtoffer. Bij versterking via misbruikte tijdservers kunnen kleine verzoeken grotere antwoorden uitlokken. Deze handleiding richt zich op het sluiten en controleren van die mogelijkheid. Lees voor achtergrond over de werking en risico’s van NTP amplification de bijbehorende uitleg.

Wat maken monlist en MON_GETLIST risicovol?

Monlist is een historische beheerfunctie die informatie over recent waargenomen NTP-clients teruggeeft. Oudere implementaties konden daarmee gegevens over maximaal 600 recente clients beantwoorden. MON_GETLIST verwijst naar opdrachten binnen dit oude beheermechanisme. Omdat één aanvraag meerdere antwoordpakketten kan opleveren, verschilt het risico sterk van een normaal tijdantwoord.

Historisch speelde dit mechanisme een rol bij grote NTP-reflectieaanvallen rond 2013 en 2014. De bruikbare versterking hing af van software, gevulde clientlijsten en pakketgroottes. Vermijd een universeel vermenigvuldigingsgetal voor iedere NTP-server. Ook een leeg of klein antwoord kan veranderen nadat de server meer clients heeft gezien.

Bij klassieke ntpd verdween het oude monlist-mechanisme vanaf versie 4.2.7p26 uit de ontwikkeltak. Distributies kunnen beveiligingscorrecties echter terugporteren naar oudere versienummers. Controleer bijgevolg ook pakketupdates en beschikbare functies, niet uitsluitend het weergegeven nummer. Chrony gebruikt dit oude ntpd-beheermechanisme niet, maar vraagt nog steeds om passende toegangsregels.

Risicovolle NTP-instellingen en passende maatregelen

Risicovolle functies en controles per NTP-implementatie

Instelling of functie	Risico op misbruik	Aanbevolen maatregel	Controle na aanpassing
Oude ntpd-monlistfunctie	Grote beheerantwoorden	Ondersteunde versie; monitor uitschakelen waar passend	Versiecontrole; geen oud beheerantwoord
ntpd zonder noquery	Externe statusvragen	noquery voor niet-vertrouwde adressen	Externe beheerquery geweigerd
ntpd zonder nomodify	Ongewenste beheerwijzigingen	nomodify op toegangsregels	Beheerrechten en configuratiecontrole
chrony met brede allow-regel	Tijdservice voor ongewenste clients	Alleen bedoelde subnetten toestaan	Toegestane en externe clienttest
Publieke chrony-commandopoort	Onnodige beheerblootstelling	cmdport 0 indien niet nodig	Geen UDP-listener op poort 323
IPv6 zonder toegangsfilter	Omzeiling van IPv4-beperking	Gelijkwaardig IPv6-beleid	Afzonderlijke IPv6-test
Onbeperkte UDP-antwoorden	Bandbreedteverbruik	Toegangsfilter; passende snelheidslimiet	Verkeer en legitieme synchronisatie

Een NTP server beveiligen vraagt aandacht voor oude beheerfuncties, te ruime clienttoegang en ontbrekende filters op één adresfamilie. Kies maatregelen op basis van de implementatie: ntpd-regels passen niet in chrony. Daarnaast verschilt een interne tijdserver van een bewust publieke dienst. Een laptop die alleen tijd ophaalt heeft meestal geen reden om externe clients te bedienen.

Welke toegang heeft jouw server werkelijk nodig?

Leg eerst vast welke rol de machine vervult: uitsluitend client, interne tijdserver of publieke tijdserver. Voor een interne server kan bijvoorbeeld alleen 10.20.30.0/24 toegang nodig hebben. Dat subnet bevat 256 IPv4-adressen; het voorbeeld geeft geen reden om alle particuliere netwerken toe te laten. Beperk ook beheertoegang tot de bedoelde beheeromgeving.

Inventariseer vervolgens alle plekken waar verkeer de dienst kan bereiken. Denk aan een hostfirewall, een cloudfilter, portforwarding en een tweede netwerkinterface. Zo kan een server achter NAT toch publiek antwoorden wanneer een router UDP-poort 123 doorstuurt. Een geblokkeerd IPv4-adres zegt bovendien niets over het rechtstreeks bereikbare IPv6-adres.

Voor een kleine interne omgeving is netwerkafscherming vaak eenvoudiger dan een complexe publieke configuratie. Een beheerde tijdvoorziening kan daarnaast beter passen wanneer niemand updates en monitoring kan onderhouden. Daartegenover geeft een eigen tijdserver meer controle over lokale beschikbaarheid en toegangsbeleid. Kies niet automatisch de oplossing met de meeste instellingen.

Welke beperkingen bieden geen volledige bescherming?

Een snelheidslimiet beperkt verkeer, maar bepaalt niet of de aanvrager legitiem is. Ook normale clients kunnen bij herstart tegelijk synchroniseren. Kies geen willekeurige grens van bijvoorbeeld 1 pakket per seconde voor een hele organisatie. Meet eerst het normale patroon en bepaal of de limiet per bron of voor alle clients samen geldt.

NTP-authenticatie en Network Time Security beschermen de vertrouwensrelatie rond tijdsynchronisatie, maar vervangen geen netwerkfilter. Een NTP server beveiligen vraagt ook bij beveiligde tijdsynchronisatie om controle van open poorten. Controleer afzonderlijk de NTP-poort en eventuele aanvullende diensten. Voor Network Time Security gebruikt de sleuteluitwisseling gewoonlijk TCP-poort 4460, naast het NTP-verkeer zelf.

Let op: Een open UDP-poort 123 bewijst geen monlist-kwetsbaarheid. Een geweigerde monlist-aanvraag bewijst evenmin dat je IPv6-regels, beheerpoorten en uitgaand verkeer veilig hebt ingesteld.

Hoe kun je een NTP-server beveiligen met passende configuratie?

Je kunt een NTP server beveiligen door alleen bedoelde clients toe te laten, externe beheerquery’s te blokkeren en ondersteunde software te gebruiken. Pas de regels toe in het configuratiebestand van de daadwerkelijk actieve daemon. Controleer daarna de ingelezen configuratie en de synchronisatie. De onderstaande voorbeelden beschrijven afgebakende situaties, geen universeel bestand voor iedere distributie.

Hoe beveilig je een klassieke ntpd-server?

Voor een bewust bereikbare klassieke ntpd-tijdserver beperken de volgende regels beheerquery’s en wijzigingen voor onbekende clients. Gewone tijdantwoorden blijven mogelijk, omdat noquery niet hetzelfde betekent als ignore. De configuratie bevat afzonderlijke regels voor IPv4 en IPv6. Lokale beheerquery’s krijgen via de loopbackregels een uitzondering.

restrict default kod limited nomodify noquery
restrict -6 default kod limited nomodify noquery
restrict 127.0.0.1
restrict -6 ::1

Nomodify verbiedt configuratiewijzigingen via het beheerprotocol; noquery blokkeert status- en beheerquery’s. Limited activeert snelheidsbeperking binnen ntpd, terwijl kod bij overschrijding bepaalde afwijzingsantwoorden mogelijk maakt. Deze regels sluiten de tijdservice niet voor het internet. Wil je een interne NTP server beveiligen, gebruik dan aanvullend een firewall die uitsluitend de bedoelde clients doorlaat.

Bij oude ntpd-versies kan disable monitor het historische monitoringsmechanisme uitschakelen. Let daarbij op de wisselwerking met limited: monitoring ondersteunt in sommige versies ook de snelheidsbeperking. Combineer die instellingen niet blind als twee onafhankelijke beschermlagen. Een ondersteunde pakketversie, externe noquery-beperking en netwerkafscherming vormen een duidelijker uitgangspunt.

Controleer bestaande restrict-regels voordat je wijzigingen toevoegt. Specifiekere regels kunnen namelijk andere rechten geven dan de standaardregel. Ook pool- en bronregels verdienen aandacht wanneer de server tijd bij dynamische bronnen ophaalt. Test na herstart zowel één toegestane client als de verbinding met de ingestelde upstreamtijdbronnen.

Hoe beveilig je een NTP-server met chrony?

Een NTP server beveiligen met chrony begint bij de clienttoegang: zonder allow-configuratie bedient chrony standaard geen NTP-clients. Voor een interne tijdserver op het voorbeeldnetwerk 10.20.30.0/24 kun je onderstaande regels gebruiken, naast bestaande tijdbronnen. De eerste regel sluit andere clienttoegang; de tweede staat het bedoelde subnet toe. De derde sluit de UDP-commandopoort, normaal poort 323.

deny all
allow 10.20.30.0/24
cmdport 0

Controleer ook configuratiebestanden die chrony via include- of confdir-instellingen inleest. Een aanvullende brede allow-regel kan immers meer toegang geven dan bedoeld. Cmdport 0 schakelt de UDP-beheerlistener uit, maar laat lokaal beheer via de Unix-socket mogelijk. Hierdoor kun je de dienst blijven controleren zonder een netwerkbeheerpoort te publiceren.

Voor een machine die uitsluitend NTP-client is, kan port 0 de NTP-serverfunctie uitschakelen. Uitgaande synchronisatie blijft dan mogelijk, terwijl de machine geen tijdservice voor andere clients aanbiedt. Gebruik deze instelling niet op een interne tijdserver die juist clients moet bedienen. Controleer de configuratie vóór herstart met chronyd -p en daarna met chronyc tracking.

Welke firewallregels beschermen een interne NTP-server?

Een NTP server beveiligen met een hostfirewall geeft een tweede grens naast de daemonconfiguratie. Onderstaand iptables-voorbeeld is bedoeld voor een IPv4-tijdserver die alleen 10.20.30.0/24 bedient. De aparte keten laat bestaand antwoordverkeer door en weigert nieuwe verzoeken uit andere netwerken. Voer deze regels eenmalig uit in een gecontroleerde omgeving met hersteltoegang.

iptables -N NTP_IN
iptables -A NTP_IN -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A NTP_IN -s 10.20.30.0/24 -j ACCEPT
iptables -A NTP_IN -j DROP
iptables -I INPUT 1 -p udp --dport 123 -j NTP_IN

De conntrack-regel voorkomt dat normale upstreamantwoorden onbedoeld stranden wanneer de lokale NTP-client poort 123 gebruikt. Deze uitzondering vertrouwt op de verbindingstoestand en vervangt geen controle op vervalste bronadressen. Inspecteer daarnaast de plaatsing tegenover bestaande firewallregels. Maak vervolgens een gelijkwaardig IPv6-beleid, of blokkeer daar NTP-clienttoegang wanneer die niet nodig is.

Gebruik bij firewalld, nftables of cloudfilters de bestaande beheerroute in plaats van losse iptables-regels ernaast. Anders kan een herstart de bescherming verwijderen of kan een beheerlaag de regels overschrijven. Sla de uiteindelijke regels volgens het platformbeleid op. Controleer tenslotte de daadwerkelijk actieve regels, niet alleen het configuratiebestand op schijf.

Hoe controleer je of je beveiligde NTP-server publiek antwoordt?

Een NTP server beveiligen omvat ook een controle vanaf een toegestaan extern netwerk. Gebruik daarvoor kleine, normale tijdverzoeken en beperkte beheerquery’s. Combineer die controle met lokale listenerinformatie en een korte pakketopname. Zo onderscheid je een open tijdservice van open beheerfuncties. Test IPv4 en IPv6 apart, zonder bronadressen te vervalsen of grote antwoordreeksen op te wekken.

Welke tests zijn veilig voor een thuislab?

Gebruik twee eigen machines of virtuele machines: één tijdserver en één testclient. Een afgeschermd lab helpt voorkomen dat experimenteel verkeer andere systemen raakt. Begin op de server met ss -lunp en controleer welke daemon op UDP-poort 123 luistert. Kijk tevens naar poort 323 wanneer chrony actief is.

Een beperkte statusquery voor klassieke ntpd is ntpq -n -c rv 10.20.30.10. Het voorbeeldadres hoort hier bij de eigen labserver binnen het toegestane subnet. Toegang tot de tijdservice betekent niet automatisch toegang tot beheerquery’s. Met de bovenstaande ntpd-regels weigert de server deze query ook vanuit dat subnet, tenzij een specifieke beheeruitzondering bestaat. Dezelfde soort query hoort vanaf een niet-toegestaan netwerk geen beheerinformatie op te leveren. Let wel: ntpq test het ntpd-beheerprotocol en is geen algemene test voor iedere NTP-implementatie.

Voor een normale tijdquery kan ntpdig 10.20.30.10 dienen, wanneer dit hulpprogramma beschikbaar is. Gebruik geen opties die de lokale klok wijzigen. Het resultaat toont of de server een bruikbaar tijdantwoord geeft, maar bewijst geen weerstand tegen alle versterkingsvormen. Voer geen monlist-belastingtest uit op willekeurige publieke adressen.

Hoe lees je pakketten en antwoordgroottes?

Maak op de eigen server een begrensde opname met tcpdump -ni any -nn -c 20 ‘udp port 123’. De optie -c 20 stopt na 20 passende pakketten. Houd wel rekening met andere clients die tegelijk verkeer sturen. In Wireshark beperkt het filter udp.port == 123 de weergave tot NTP-poortverkeer.

Een normaal NTP-basispakket bevat 48 bytes aan NTP-inhoud. Zonder opties, uitbreidingsvelden of authenticatie komen daar bij IPv4 8 bytes UDP en 20 bytes IP bij. Het totaal is dan 76 bytes op IP-niveau per pakket. Bij IPv6 levert dezelfde basisinhoud 48 + 8 + 40 = 96 bytes op.

In een eenvoudig labvoorbeeld verstuur je 1 IPv4-verzoek en ontvang je 1 even groot basisantwoord. De berekening is 76 bytes heen + 76 bytes terug = 152 bytes totaal op IP-niveau. De antwoord-verzoekverhouding is daarbij 76 / 76 = 1. Ethernetheaders en eventuele extra NTP-velden vallen buiten deze voorbeeldberekening.

Een tijdserver hoeft niet overgenomen te zijn om schade te veroorzaken. De beslissende vraag is wie antwoorden kan uitlokken en waar die antwoorden terechtkomen.

Voor versterking tel je alle antwoordpakketten bij één verzoek op en deel je dat volume door de verzoekgrootte. Vergelijk daarbij dezelfde meetlaag aan beide kanten. Pakketfragmentatie en opnameverlies kunnen anders een verkeerde verhouding suggereren. Grote antwoorden op beheerquery’s vragen nader onderzoek, maar een gelijk groot tijdantwoord maakt de dienst nog niet wenselijk openbaar.

Welke verkeerspatronen wijzen op reflectiemisbruik?

NetFlow en IPFIX beschrijven netwerkstromen, waaronder adressen, poorten en aantallen bytes. sFlow gebruikt steekproeven van pakketten en tellers, waardoor kleine stromen buiten beeld kunnen blijven. Zoek naar een plotselinge stijging van uitgaand UDP-verkeer met bronpoort 123. Combineer bijvoorbeeld 5 minuten verkeersgegevens met dezelfde periode uit een pakketopname.

• Uitgaande NTP-bytes nemen sterk toe zonder geplande uitbreiding van het clientnetwerk.
• Veel antwoorden gaan naar adressen die geen bekende tijdclients zijn.
• Eén klein inkomend verzoek leidt tot meerdere uitgaande antwoordpakketten.
• Beheerquery’s verschijnen vanuit externe netwerken die geen beheertoegang nodig hebben.
• IPv6-verkeer groeit terwijl de IPv4-filtering geen afwijkingen laat zien.
• De netwerkbelasting stijgt, maar CPU-gebruik en aanmeldlogs blijven grotendeels normaal.

Deze signalen vormen een detectiechecklist, geen bewijs van een volledige serverinbraak. Een legitieme uitbreiding kan bijvoorbeeld ook meer tijdverkeer veroorzaken. Onderzoek bronnetwerken, pakkettypen en de wijzigingshistorie samen. Bij twijfel helpt onderzoek naar aanwijzingen voor bronadresvervalsing om netwerkwaarnemingen beter te duiden.

Wat doe je wanneer jouw NTP-server in DDoS-verkeer opduikt?

Bepaal eerst of jouw NTP-server antwoorden verstuurt als reflector of juist ongewenste antwoorden ontvangt als slachtoffer. Bij reflectormisbruik moet je de NTP server beveiligen door direct onnodige publieke toegang te blokkeren. Bewaar ook beperkte netwerkgegevens. Bij een slachtoffer ligt de eerste prioriteit bij filtering vóór de overbelaste verbinding. Start daarnaast apart onderzoek wanneer aanwijzingen bestaan voor accountmisbruik, gewijzigde bestanden of andere toegang.

1. Leg het tijdstip, de betrokken IP-adressen en de richting van UDP-poort 123 vast.
2. Bewaar waar mogelijk een begrensde pakketopname en relevante flowgegevens voordat je configuraties wijzigt, zonder noodzakelijke blokkering te vertragen.
3. Blokkeer ongewenste NTP-clienttoegang wanneer jouw server als reflector antwoordt.
4. Vraag je netwerkprovider om upstreamfiltering wanneer inkomend verkeer jouw verbinding verzadigt.
5. Werk de NTP-software bij en controleer beheerrechten, toegangsregels en IPv6.
6. Test toegestane synchronisatie en controleer daarna opnieuw uitgaande en inkomende verkeersvolumes.

Hoe onderscheid je een reflector van een slachtoffer?

Veel uitgaande pakketten met bronpoort 123 passen bij een server die NTP-antwoorden verstuurt. Veel inkomende pakketten met bronpoort 123 passen bij ontvangen antwoorden van andere tijdservers. Bestemmingspoorten kunnen echter variëren, omdat het antwoord het bronpoortveld van het verzoek volgt. Gebruik niet uitsluitend één poortnummer als beslisregel.

Volg een eenvoudige beslisroute: verstuurt jouw machine antwoorden naar ongewenste adressen, sluit dan de reflectormogelijkheid. Ontvangt jouw aansluiting vooral antwoorden van meerdere externe servers, schakel dan de provider in. Zie je beide richtingen, onderzoek beide rollen afzonderlijk. Een machine kan immers zelf reflector zijn terwijl het netwerk tegelijk ander DDoS-verkeer ontvangt.

Lokale filtering beschermt de dienst, maar herstelt geen internetverbinding die vóór de firewall al volloopt. Daarvoor moet de provider het verkeer eerder tegenhouden of omleiden. Spreek vooraf af wie incidentmeldingen behandelt en welke gegevens nodig zijn. Een contactlijst met 2 bereikbare escalatieroutes is bruikbaarder dan een noodplan zonder verantwoordelijke.

Wat betekenen meldingen over ‘NTP gehackt’?

De melding ‘NTP gehackt’ kan betekenen dat iemand reflectiemisbruik heeft waargenomen, zonder dat de aanvaller toegang tot het systeem kreeg. De server kan uitsluitend zijn ingestelde antwoordfunctie hebben uitgevoerd. Dat onderscheid voorkomt onnodige aannames over malware of gestolen accounts. Toch vereist de melding directe controle van configuratie, verkeer en softwareonderhoud.

Onderzoek volledige compromittering wanneer je onverwachte beheeraccounts, gewijzigde starttaken of onbekende processen aantreft. Kijk ook naar pakketintegriteit en wijzigingen buiten de NTP-configuratie. Bewaar dan bewijs voordat je opnieuw installeert of bestanden verwijdert. Alleen een grote hoeveelheid UDP-antwoorden rechtvaardigt nog niet de conclusie dat ransomware of andere malware actief is.

Vuistregel: Behandel ongewenste NTP-antwoorden eerst als blootgestelde dienstverlening, tenzij afzonderlijke aanwijzingen op systeeminbraak wijzen.

Waar passen BCP38 en bronadresfilters in het noodplan?

BCP38, beschreven in RFC 2827, behandelt netwerkfiltering tegen verkeer met ongeldige of vervalste bronadressen. Een netwerk laat daarbij alleen bronadressen toe die op de betreffende aansluiting horen. Aan de klantzijde hoort zo’n controle bij uitgaand verkeer richting de provider. Deze maatregel bemoeilijkt het verzenden van vervalste verzoeken vanuit dat netwerk.

Bronadresfiltering op jouw eigen netwerk voorkomt niet dat een ander netwerk vervalste verzoeken naar jouw server stuurt. Je moet de NTP server beveiligen met eigen toegangsregels en onderhoud, ook wanneer jouw netwerk bronvalidatie toepast. Vraag de provider wel naar bronvalidatie en incidentondersteuning. Bij meerdere uplinks verdienen routes extra aandacht, omdat te strikte controles legitiem asymmetrisch verkeer kunnen blokkeren.

Leg na herstel een nieuwe verkeersbasislijn vast en vergelijk bijvoorbeeld opeenvolgende vensters van 5 minuten. Controleer vervolgens of legitieme clients blijven synchroniseren zonder opnieuw brede toegang te openen. Documenteer iedere tijdelijke uitzondering met eigenaar en einddatum. Daarmee voorkom je dat een noodmaatregel later een blijvende opening wordt.

Veilige tijdservice begint bij aantoonbare grenzen

Een NTP server beveiligen betekent aantonen welke clients tijd ontvangen, welke beheervragen de daemon weigert en welke netwerkpaden openstaan. Het veiligste beleid volgt de functie van de machine: alleen client, interne tijdserver of publieke dienstverlening. Verwijder eerst onnodige bereikbaarheid voordat je ingewikkelde snelheidslimieten toevoegt. Controleer daarna de werking vanaf zowel toegestane als niet-toegestane netwerken.

De bruikbare eindtoestand bestaat uit ondersteunde software, beperkte beheerfuncties en filters voor IPv4 én IPv6. Daarnaast moet monitoring ongewenste antwoordstromen zichtbaar maken. Bewaar bijvoorbeeld een testverslag met 3 onderdelen: actieve configuratie, externe testuitkomst en verkeer tijdens die test. Zo kun je na een update of migratie dezelfde controle herhalen.

Wij zouden een interne tijdserver eerst afschermen en pas daarna uitzonderingen bespreken. In onze afweging geeft een kleine, verklaarbare toegangsset meer houvast dan meerdere limieten waarvan niemand de werking kan uitleggen. Dat is de beheerderskeuze die wij bij Virus.NL vooropzetten.

Veelgestelde vragen

Wil je een NTP server beveiligen, dan helpen deze antwoorden bij het kiezen van instellingen en controles. Gebruik ze naast de configuratievoorbeelden, omdat iedere serverrol andere toegangsgrenzen vraagt.

Welke NTP-instellingen zijn risicovol?

Risicovol zijn oude monlist-functies, externe beheerquery’s, brede clienttoegang en ontbrekende IPv6-filters. Bij ntpd verdienen restrict-regels aandacht; bij chrony vooral allow-regels en de commandopoort. Controleer bovendien UDP-poort 123 op de host, router en cloudlaag. Publieke bereikbaarheid betekent niet automatisch sterke versterking, maar vergroot wel de groep die antwoorden kan uitlokken.

Welke configuratievoorbeelden helpen een NTP-server te beveiligen?

Voor klassieke ntpd beperken noquery en nomodify externe beheerfuncties; limited ondersteunt snelheidsbeperking. Bij chrony begrenzen deny all en een specifieke allow-regel de clienttoegang, terwijl cmdport 0 de UDP-commandopoort sluit. Voor uitsluitend clientgebruik kan port 0 passen. Combineer deze instellingen met netwerkfilters en controleer na herstart of toegestane synchronisatie nog werkt.

Hoe test je of een NTP-server publiek misbruikt kan worden?

Test vanaf een extern netwerk waarvoor je toestemming hebt en verstuur slechts enkele normale tijd- en beheerquery’s. Leg tegelijk pakketten vast op de eigen server. Controleer bereikbaarheid, antwoordtype en antwoordvolume voor IPv4 en IPv6 afzonderlijk. Gebruik geen vervalste bronadressen of grote monlist-tests op productiesystemen, omdat je daarmee zelf ongewenst verkeer kunt veroorzaken.

Wat betekent het als men zoekt op ‘NTP gehackt’?

‘NTP gehackt’ kan verwijzen naar reflectiemisbruik van een verkeerd ingestelde tijdserver, zonder volledige systeemovername. Een aanvaller laat dan antwoorden naar een slachtoffer sturen via vervalste bronadressen. Onderzoek een inbraak afzonderlijk wanneer accounts, bestanden of processen afwijken. De zoekterm zelf maakt geen onderscheid tussen een open dienst, een softwarelek en gestolen toegang.

Kun je een publieke NTP-server beveiligen zonder alle clients te blokkeren?

Ja, een bewust publieke NTP-server kan tijdantwoorden blijven geven terwijl hij beheerquery’s weigert. Gebruik ondersteunde software, beperk beheerpoorten en monitor antwoordvolumes. Publieke dienstverlening houdt echter restbelasting door onbekende clients mogelijk. Bespreek capaciteit en upstreamfiltering met de provider; een lokale firewall kan een al verzadigde aansluiting niet vrijmaken.

Een NTP server beveiligen blijft een terugkerende taak: controleer de serverrol en test na wijzigingen opnieuw de bijbehorende toegangsgrenzen. Leg de uitkomsten vast in een DDoS-checklist met een uitvoerbaar noodplan, zodat je bij afwijkend verkeer weet wie welke maatregel neemt.