Userbase

duizend schreef: Probleem opgelost waarvan ik niet eens wist dat ik het had ...

Zoals hierboven gezegd: toch nagaan of de Fritzbox zelf zonder problemen de tijd kan binnenhalen via NTP. Anders sync je met een klok die mogelijks ook niet correct is.

Vermoedelijk zal NTP wel werken want Fritzbox zal quasi zeker de Linux implementatie van de client gebruiken die (uiteraard) wel random source poorten gebruikt, maar best toch checken.

Mooi voorbeeld van hoe Linux weer de problemen van Windows mag komen opkuisen.

Mijn Windows tijd is nu correct met world clock.
Dus ofwel synct de FB wel.
Ofwel blijft de tijd van de FB “van zijn eigen” correct.

Problem solved

Net antwoord gekregen van EDPnet support

Op uw verzoek hebben wij de poort 123 gedeblokkeerd.

En inderdaad, de time sync met bv. time.windows.com werkt nu ook.

Enkel bij jou dan toch.

Ik heb in verleden alleszins al tijd verspilt met de oorzaak te vinden, maar het probleem ligt dus bij edpnet. Ik ben hierdoor ook al tegen authenticatie problemen gelopen. Als je dan geen deftige foutmelding krijgt, ben je wel even zoet.

dragonflo schreef:maar het probleem ligt dus bij edpnet.

Of bij Windows, ligt er gewoon aan hoe je het bekijkt.

johan.devos schreef:Net antwoord gekregen van EDPnet support

Op uw verzoek hebben wij de poort 123 gedeblokkeerd.

Huh... waarom blokkeerd EDPnet dergelijke poort in de eerste plaats

DarkV schreef:Huh... waarom blokkeerd EDPnet dergelijke poort in de eerste plaats

Port 123 wordt erg veel misbruikt voor DDOS aanvallen.

NTP is een standaard protocol dat gewoon moet werken... daar moet EDPnet gewoon afblijven.

Desnoods monitoren ze hun klanten op het misbruik ervan maar het standaard dicht zetten zonder meer is gewoon not-done.

Welja, een ISP is vrij om zo'n zaken te blokkeren, nergens is er een wettelijke vereiste van het tegendeel.

Maar je kan niet ontkennen dat NTP een essentiële service is bij het gebruik van het internet. Zonder NTP kan het voor bepaalde toestellen (ook consumer-range) moeilijk zijn om de juiste tijd aan te houden, wat dan weer tot gevolg kan hebben dat ze TLS certificaten niet kunnen valideren, wat dan weer tot gevolg kan hebben dat ze niet kunnen updaten, wat dan weer tot grotere veiligheidsrisico's kan leiden dan degene die EDPnet probeert te voorkomen met het blokkeren van poort 123.

EDPnet zou gerust zelf een NTP server voorzien voor haar klanten en deze enkel openstellen voor IP's binnen hun netwerk, zodat er tenminste een alternatief is als men poort 123 blokkeert (ook al is dat ook het gevolg van een gebrekkige Windows-implementatie). Maarja, voor zo'n goedkope provider zal een NTP-service voorzien wel al te veel gevraagd zijn?

Moet je eens bij telenet of proximus vragen om bepaalde poorten of verkeer te unblocken...

Bij edpnet regel je dat met een ticket
bij telenet of proximus verstaat de helpdesk niet eens wat je wil en als je al iemand met kennis kan vinden zal er toch niets veranderen in hun policy

Dat ze dan gewoon de NTP servers van Windows en de Belgian pool open zetten… gewoon NTP grofweg blokkeren blijft gewoon absurd (evenals de reden waarom… of heeft EDPnet zoveel klanten die DDOS attacks uitvoeren in een Botnet ?)

Ik heb ook een datumprobleem op mijn privé pc die niet elke dag aanstaat (edpnet provider). Op mijn werklaptop (thuiswerk) heb ik het probleem niet. Zal eens op mijn fritzbox als timeserver de fritzbox zelf opgeven wat hier als tip gegeven werd. Snap wel niet waarom het op het ene toestel mis gaat en op het andere niet beide op thuisnetwerk.

fredo66 schreef: Zal eens op mijn fritzbox als timeserver de fritzbox zelf opgeven wat hier als tip gegeven werd.

De tip die hier gegeven werd, was in Windows de FritzBox als timeserver opgeven.

• - De FritzBox zelf syncroniseert met de externe timeserver die ingesteld staat (vb be.pool.ntp.org).
  - de Windows PC syncroniseert dan met de Fritz!Box.

fredo66 schreef:Ik heb ook een datumprobleem op mijn privé pc die niet elke dag aanstaat (edpnet provider).
Op mijn werklaptop (thuiswerk) heb ik het probleem niet.
Snap wel niet waarom het op het ene toestel mis gaat en op het andere niet beide op thuisnetwerk.

Werklaptop zal waarschijnlijk al het verkeer in een tunnel naar het werk sturen

ik gebruik inderdaad meestal vpn maar die start ik manueel op na de opstart van windows.

Als je werk computer deel is van een Domain dan synct deze de tijd met je Domain controller en niet via EDPnet

philippe_d schreef:De tip die hier gegeven werd, was in Windows de FritzBox als timeserver opgeven.

• - De FritzBox zelf syncroniseert met de externe timeserver die ingesteld staat (vb be.pool.ntp.org).
  - de Windows PC syncroniseert dan met de Fritz!Box.

Wat los je daarmee op als EDPnet gewoon NTP niet toelaat ?

DarkV schreef: Wat los je daarmee op als EDPnet gewoon NTP niet toelaat ?

Het is poort 123 inbound die gefilterd wordt door EDPnet, waarschijnlijk om te vermijden dat er publiek toegankelijke NTP servers draaien binnen EDPnet. Outbound 123 gaat blijkbaar wel. Op zich geen probleem, tenzij je een NTP client hebt die bizarre dingen doet zoals poort 123 ook als source gebruiken voor NTP queries, aka de standaard Windows client.

De NTP client van Fritzbox zelf is wellicht de standaard ntpd van Linux, en die gebruikt - zoals het hoort - random source poorten ipv 123. Bijgevolg kan de NTP client van de Fritzbox wel de tijd juist zetten op de router.

Vervolgens kan de Windows client die source poort 123 gebruikt wel de Fritzbox waarmee hij rechtstreeks verbonden is als NTP server gebruiken, die query gebeurt binnen het Fritzbox LAN waar 123 niet gefilterd wordt en niet op het netwerk van EDPnet.

Ik vraag me eigenlijk af waar ze deze filter toepassen.
Op niveau van de modem lijkt me niet.

Als je de gevolgen van een UDP 123 aanval wil beperken moet je die filter toepassen op de grote routers.
Het zou ook kunnen dat al het verkeer daarna nog via firewalls moet alvorens het naar de klant gaat, maar dat lijkt mij te duur en onhaalbaar. Daarnaast moet de capaciteit richting de firewalls ook voldoende zijn.

Ik denk dat ze zo een blokkade toepassen via BGP flowspec op de grote routers.
Met flowspec kan je ook gaan limiteren op packets per seconde (PPS) ipv alles te droppen.
Wanneer je gaat limiteren op PPS betekent dat uitsluitend (de brakke implementatie van) NTP voor windows niet zal werken tijdens een aanval op UDP123, of gedurende de periode wanneer de vooringestelde PPS is overschreden voor die bepaalde prefix.

Je kan ook de IP adressen achter time.windows.com herrouteren naar een eigen server en daar NTP op draaien voor je klanten.

CCatalyst schreef:De NTP client van Fritzbox zelf is wellicht de standaard ntpd van Linux, en die gebruikt - zoals het hoort - random source poorten ipv 123.

Welke source port je gebruikt heeft op zich toch geen enkele betekenis... of laat EDPnet dan enkel > 1024 toe (wat mij nutteloos lijkt).

DarkV schreef:Welke source port je gebruikt heeft op zich toch geen enkele betekenis... of laat EDPnet dan enkel > 1024 toe (wat mij nutteloos lijkt).

Als de Windows client source poort 123 gebruikt - en eventuele NAT behoudt die, waarop de kans wel groot is in die lage range + mogelijkheid van P-t-P NTP - dan stuurt de bevraagde NTP server zijn reply voor de Windows-machine uiteraard terug naar poort... 123. EDPnet ziet dan een inbound pakket naar poort 123 => must filter (tenzij men de klantendienst voor een exceptie vraagt wat blijkbaar kan).

Als ik het goed begrijp is het dus ook geen algemene filter < 1024, maar een specifieke filter voor 123 nav de golf van NTP-amplification attacks van het vorige decennium.

Om toch nog effe op de commentaren te reageren die stellen "waarom doet een bank moeilijk over 6 min":

In de security protocollen die veelgebruikt zijn is 5 min het standaard tijdverschil waarmee 2 toestellen nog met mekaar kunnen/mogen communiceren.
Banken gaan daar bv zeer gevoelig aan zijn.
Vergeet niet dat je pc ook vaak tokens etc moet genereren (denk aan 2FA), en dat die nog gevoeliger zijn: de totp standaard wisselt om de 30 sec, gelukkig houden de meeste server rekening met wat marge, en laten ze een aantal voorbije (en ook volgende) tokens ook toe, om wat marge te hebben.
Maar 5 min is dus een eeuwigheid in de wereld van het secure web.