Forum: Mikrocontroller und Digitale Elektronik NTP Server funktioniert nicht mehr


von Thomas S. (thomas_s72)


Lesenswert?

Guten Tag,
seit ca. 10 Jahren habe ich den Pollin Net-IO mit abgewandelter Radig 
Software am Laufen, wurde hier ja schon öfters diskutiert. Der steuert 
einige Dinge im Hause entsprechend der Zeit. Das ging jahrelang 
wunderbar, auf einmal stellte nun ich fest, dass die Uhrzeit wegläuft.

Tests ergaben, dass NTP mit Server 192.53.103.108 nicht mehr 
funktionierte. Hä?? Was soll das. Hab dann das Tool ntpquery 
heruntergeladen, da funktioniert es wunderbar (auf Port 123).

Hab dann einfach einen anderen NTP Server eingetragen und es 
funktioniert wieder. Kann jemand das erklären? Die Funtion ist seit 
einigen Tagen (oder Wochen??) weg.
Mir ist es eigentlich wurscht welcher Server genutzt wird, mich 
interessiert nur, warum das nach Jahren nicht mehr funktioniert.
Eventuell hat jemand da eine Erklärung.

Schönen Sonntag noch,
Gruß
Thomas

von Dieter (Gast)


Lesenswert?

So ein Problem kenne ich auch. Da scheint den betreffenden Handelnden in 
Verbindung mit http und https ein entscheidender dummer Fehler 
unterlaufen zu sein.

Wenn das Zeitfenster für die Abfrage zu klein gewählt wurde, ist 
jedesmal der Schlüssel https abgelaufen. Es handelt sich um ein 
typisches Henne und Ei Problem.

Damit es korrekt funktioniert, müßte man einen NTP Server immer zuerst 
mit http ansprechen können, dieser mit http antworten (wenn der erste 
Versuch mit https fehl schlug), dann mit dieser Zeit einen Versuch über 
https starten, und erst dann die neue Zeit übernehmen.

von Stefan F. (Gast)


Lesenswert?

Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen 
möchte. Ist die aktuelle Uhrzeit geheim?

von Dieter (Gast)


Lesenswert?

Stefanus F. schrieb:
> Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen
> möchte. Ist die aktuelle Uhrzeit geheim?

Nicht geheim, sondern das sollte der Authentisierung, ob es wirklich vom 
Zeitserver die Antort käme, dienen. Mit der Zwangs-https wird das so 
über das Knie gebrochen, dass es nicht mehr funktioniert.

von Stratum1 (Gast)


Lesenswert?

# ntpd -dnqNp 192.53.103.108
ntpd: sending query to 192.53.103.108
ntpd: reply from 192.53.103.108: offset:-5.726613 delay:0.687121 
status:0x24 strat:1 refid:0x004d485

Ganz ohne Authentisierung!

https ist also Kaese.

von Kaj (Gast)


Lesenswert?

Stefanus F. schrieb:
> Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen
> möchte. Ist die aktuelle Uhrzeit geheim?

https://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns
1
Several security concerns arose in late 2014. Previously, researchers
2
became aware that NTP servers can be susceptible to man-in-the-middle
3
attacks unless packets are cryptographically signed for authentication.
4
[...]
5
NTP message spoofing can be used to move clocks on client computers
6
and allow a number of attacks based on bypassing of cryptographic key
7
expiration. Some of the services affected by fake NTP messages identified
8
are TLS, DNSSEC, various caching schemes (such as DNS cache), BGP, Bitcoin
9
and a number of persistent login schemes.

von Stefan F. (Gast)


Lesenswert?

Krass, was sich die Hacker alles einfallen. Immer wenn ich das Gefühl 
habe, einigermaßen zu wissen, worauf man als Softwareentwickler alles 
achten muss, kommst so ein Klopper und ich fühle mich wieder dumm.

von +/- (Gast)


Lesenswert?

----
Stratum1 schrieb:
> # ntpd -dnqNp 192.53.103.108
> ntpd: sending query to 192.53.103.108
> ntpd: reply from 192.53.103.108: offset:-5.726613 delay:0.687121

Anmerkung, obacht bei dem Aufruf ;)

ntpd -dnqNp , das q Flag sagt ihm zwar sich nach der Abfrage zu beenden, 
verpfuscht aber ggf. vom Aufrufer ungewollt andere Parameter.

Grad hier in meinem log entdeckt

ntpd[19754]: frequency initialized 0.000 PPM from /etc/ntp/drift

und eine zuvor per Fuß gemachte adjtimex Frequenzkorrektur ist futsch :)

Wenn ntp nicht dauernd als deamon läuft (ntpd) weils zum Beispiel ein 
Rechner ist der überwiegend offline läuft (oder auch weil man alle 
Schotten dicht gemacht hat) ist ntpdate (-q) besser.

Jdf läßt ntpdate augenscheinlich mit adjtimex vorgenommene 
Freqreunzkorrekturen unverändert.


----

von Stratum1 (Gast)


Lesenswert?

Jeder ordentliche NTP-Deamon laesst sich von Zeitangaben ausserhalb
eines gewissen Horizonts nicht beeindrucken und verwirft sie.
Um Zertifikate auslaufen zu lassen wird dieser Bereich nicht reichen.
Die Gefahr ist also nur auf dem Papier.

Ausser mit einem "Holzhammer": ntpdate.

Der kommt auch eher nach dem Auspacken frischer Hardware
und wird ueblicherweise von Hand gestartet und das Ergebnis
geprueft.

von Stratum1 (Gast)


Lesenswert?

> und eine zuvor per Fuß gemachte adjtimex Frequenzkorrektur ist futsch :)

Tja, Pech gehabt.

Meine Zeitreferenz hat ca. 0.2 s Abweichung per Woche.
Da brauch ich kein adjtime.

von +/- (Gast)


Lesenswert?

Stratum1 schrieb:
>> und eine zuvor per Fuß gemachte adjtimex Frequenzkorrektur ist futsch :)
>
> Tja, Pech gehabt.
>
> Meine Zeitreferenz hat ca. 0.2 s Abweichung per Woche.
> Da brauch ich kein adjtime.


Du lagst doch bald 6 Sekunden daneben :)

> ntpd: reply from 192.53.103.108: offset:-5.726613 delay:0.687121


Hier eiert die Uhr recht konstant, letzte 12 Std.

server 130.133.1.10 offset 0.001058 sec
server 130.133.1.10 offset -0.000663 sec
server 130.133.1.10 offset -0.000867 sec
server 130.133.1.10 offset -0.001849 sec
server 130.133.1.10 offset -0.000479 sec
server 130.133.1.10 offset 0.000049 sec
server 130.133.1.10 offset -0.001505 sec
server 130.133.1.10 offset 0.000144 sec
server 130.133.1.10 offset -0.000889 sec
server 130.133.1.10 offset -0.000842 sec
server 130.133.1.10 offset 0.000318 sec
server 130.133.1.10 offset 0.000345 sec


adjtimex -p|grep freq
    frequency: 805984


just for fun ;)

von Stratum1 (Gast)


Lesenswert?

Das war ja auch nur das Schlaufon.
Das kanns halt freilaufend nicht besser.

Das hat keine Verbindung in mein internes Netz.
Und: Das ist auch besser so.

von Manfred (Gast)


Lesenswert?

Thomas S. schrieb:
> Tests ergaben, dass NTP mit Server 192.53.103.108 nicht mehr
> funktionierte.

Das ist ptbtime, die haben vor wenigen Monaten etwas verbastelt, gab 
auch hier ein Problem.

Schaue mal bei Meinberg: 
https://www.meinberg.de/german/info/ntp-w32time.htm

Das bezieht sich zwar auf Windows, dürfte aber genau Dein Problem 
abbilden: " .. reagieren NTP-Server möglicherweise nicht auf diese Art 
der von w32time gesendeten Anfragen. w32time sendet hier Pakete im 
symmetrisch aktivem statt im client Modus an einen NTP-Server ..".

Wie man den Anfragetyp bei Deinem Gerät umstellt, musst Du selbst 
beforschen.

von de.pool.ntp.org (Gast)


Lesenswert?

Thomas S. schrieb:

> Tests ergaben, dass NTP mit Server 192.53.103.108 nicht mehr

Hmm, ist das eigentlich OK die Stratum-1 Server der PTB mit dem 
InternetofShittyThings zu belästigen?

Ich meine das skaliert so nicht richtig, oder ist 192.53.103.108 eine 
anycast Addresse?

von c-hater (Gast)


Lesenswert?

Dieter schrieb:

> So ein Problem kenne ich auch. Da scheint den betreffenden Handelnden in
> Verbindung mit http und https ein entscheidender dummer Fehler
> unterlaufen zu sein.

Kaum. NTP wird klassisch über Port 123 UDP abgewickelt. Nix TCP und 
schon garnix HTTP oder gar HTTPS.

Aber ja: irgendwas läuft derzeit bei vielen ntp-Servern schief. Die sind 
teilweise einfach nicht mehr bereit, per Port 123 UDP zu kommunizieren. 
Da hat wohl mal wieder irgendein "Sicherheitsupdate" das Kind mit dem 
Bade ausgeschüttet, d.h.: mehr Schaden angerichtet, als die angeblich 
gefixte "Sicherheitslücke" jemals hätte anrichten können...

Irgendwie auch eine Form von DDOS...

von Ralf D. (doeblitz)


Lesenswert?

c-hater schrieb:
[...]
> Aber ja: irgendwas läuft derzeit bei vielen ntp-Servern schief.

Nö, die laufen genau so, wie sie sollen.

> Die sind
> teilweise einfach nicht mehr bereit, per Port 123 UDP zu kommunizieren.

Eben. Die sollen im Regelfall nämlich nicht öffentlich verfügbar sein.

> Da hat wohl mal wieder irgendein "Sicherheitsupdate" das Kind mit dem
> Bade ausgeschüttet, d.h.: mehr Schaden angerichtet, als die angeblich
> gefixte "Sicherheitslücke" jemals hätte anrichten können...

Falsch. Die entsprechenden Hinwiese von BSI etc. kamen aufgrund realer 
DDOS-Angriffe, bei denen offene NTP-Server für Reflection-Attacks 
genutzt wurden.

Wenn man NTP-Server offen betreiben will, dann sollte man auch 
entsprechende Maßnahmen gegen solchen Mißbrauch einsetzen, u.a. 
Rate-Limiting. Das haben nur leider sehr wenig "Admins" gemacht, die 
meisten davon haben den Kram wohl einfach so offen gelassen ohne sich um 
das Mißbrauchspotential zu kümmern. Daher die gut nachvollziehbare Bitte 
des BSI, den Dienst entweder abzusichern oder nicht öffentlich 
anzubieten.

von MaWin (Gast)


Lesenswert?

Stefanus F. schrieb:
> Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen
> möchte. Ist die aktuelle Uhrzeit geheim?

Genau solche Gründe sind es weshalb es immer wieder Probleme mit der 
Sicherheit von Systemen gibt. "Was soll an der Uhrzeit geheim sein?".

Der Angreifer muss nur wissen das in der Vergangenheit oder Zukunft der 
Türöffner automatisch das Gebäude für Besucher freigibt. Wenn man jetzt 
am Sonntag Nacht die Zeit solange vorstellt bis es Montag 8Uhr ist, hat 
man freien Zugang zum Gebäude...

Und jetzt kannst dir nochmal die Frage stellen weshalb man HTTPS 
verwenden sollte...

von Stefan F. (Gast)


Lesenswert?

MaWin schrieb:
> Stefanus F. schrieb:
>> Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen
>> möchte. Ist die aktuelle Uhrzeit geheim?
>
> Genau solche Gründe sind es weshalb es immer wieder Probleme mit der
> Sicherheit von Systemen gibt. "Was soll an der Uhrzeit geheim sein?".
>
> Der Angreifer muss nur wissen das in der Vergangenheit oder Zukunft der
> Türöffner automatisch das Gebäude für Besucher freigibt. Wenn man jetzt
> am Sonntag Nacht die Zeit solange vorstellt bis es Montag 8Uhr ist, hat
> man freien Zugang zum Gebäude...
>
> Und jetzt kannst dir nochmal die Frage stellen weshalb man HTTPS
> verwenden sollte...

Ich hab's ja schon verstanden. Es geht nicht darum, die Uhrzeit als 
Geheimnis zu bewahren, sondern die Vertrauenswürdigkeit der Daten durch 
Prüfung der Identität zu bestätigen.

von MaWin (Gast)


Lesenswert?

Stefanus F. schrieb:
> MaWin schrieb:
>> Stefanus F. schrieb:
>>> Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen
>>> möchte. Ist die aktuelle Uhrzeit geheim?
>>
>> Genau solche Gründe sind es weshalb es immer wieder Probleme mit der
>> Sicherheit von Systemen gibt. "Was soll an der Uhrzeit geheim sein?".
>>
>> Der Angreifer muss nur wissen das in der Vergangenheit oder Zukunft der
>> Türöffner automatisch das Gebäude für Besucher freigibt. Wenn man jetzt
>> am Sonntag Nacht die Zeit solange vorstellt bis es Montag 8Uhr ist, hat
>> man freien Zugang zum Gebäude...
>>
>> Und jetzt kannst dir nochmal die Frage stellen weshalb man HTTPS
>> verwenden sollte...
>
> Ich hab's ja schon verstanden. Es geht nicht darum, die Uhrzeit als
> Geheimnis zu bewahren, sondern die Vertrauenswürdigkeit der Daten durch
> Prüfung der Identität zu bestätigen.

Genau. Aber das ist halt in allem so! Selbst bei Webseiten welche weder 
ein Forular haben noch Cookies setzt. Sollte die Webseite nicht SSL 
sein, können böse Buben den Firmennamen ändern und so manipulierte 
Seiteninhalte weitersenden. Es gab mal den Aufschrei warum man alle 
Seiten verschlüsseln soll und ob es nicht ausreicht das nur diese, 
welche Nutzereingaben haben, SSL nutzen sollen. Genau deshalb. Es geht 
ja auch darum dass die Firma ihre Daten vertrauenswürdig und 
manipulationssicherer ausliefert.

Deshalb sollte man auch keine ESPs ohne SLL als Webserver ins Netz 
lassen :)

von +/- (Gast)


Lesenswert?

Ralf D. schrieb:

> Nö, die laufen genau so, wie sie sollen.
>
>> Die sind
>> teilweise einfach nicht mehr bereit, per Port 123 UDP zu kommunizieren.
>
> Eben. Die sollen im Regelfall nämlich nicht öffentlich verfügbar sein.
>

Klar sind die öffentlich zu erreichen sonst bräuchte man das ja nicht 
zur Verfügung stellen das ist doch absicht das sie zugänglich sind und 
bleiben.

RFC 868 wird nicht mehr unterstützt,
SNTP RFC 2030 geht problemlos.

Beide laufen über Port 123 UDP o. TCP
probiers ggf. mal aus mit dem alten rdate

rdate  -n      Use SNTP (RFC 2030) instead of the RFC 868 time protocol.
(-p  just print don't set)

rdate -np 192.53.103.108
Mon Sep 17 10:37:42 CEST 2018

rdate -p 192.53.103.108  schlägt bei der ptb heutzutage fehl



----
Die fu-berlin unterstützt das bisweilen weiterhin

rdate -p time.fu-berlin.de
Mon Sep 17 10:39:27 CEST 2018
rdate -np time.fu-berlin.de
Mon Sep 17 10:39:31 CEST 2018

von +/- (Gast)


Lesenswert?

ergänzend

> SNTP RFC 2030 geht problemlos.

Das wäre dann wohl clientseitig (hier)
Simple Network Time Protocol (SNTP) version 4 for IPv4, IPv6 and OSI.



ntpq findet sich noch auf dem Rechner,


ntpq
ntpq> host ptbtime1.ptb.de
current host set to ptbtime1.ptb.de
ntpq> ntpversion
NTP version being claimed is 2


---
time.fu-berlin.de  sagt auch NTPv2

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.