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
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.
Mir leuchtet nicht ganz ein, warum man die Zeit mit HTTPS abfragen möchte. Ist die aktuelle Uhrzeit geheim?
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.
# 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.
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. |
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.
---- 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. ----
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.
> 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.
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 ;)
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.
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.
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?
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...
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.
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...
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.
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 :)
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.