Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Sicherheit von freien Zeit-Servern: Chrony schlägt ntpd

20 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von XYZ am Di, 3. Oktober 2017 um 10:27 #

> Projekt wird von Red Hat unterstützt und in den Red Hat-Produkten verwendet.

systemctl enable systemd-timesyncd.service

Wozu ein weiteres Projekt und wozu die Unterstützung in Red Hat, wenn sie eigens dafür das systemd entwickelt haben ? Da ist doch schon alles enthalten... Man braucht weder ntpd nachinstallieren bzw. chrony nutzen...

  • 1
    Von whatever am Di, 3. Oktober 2017 um 10:45 #

    systemd-timesyncd ist ein SNTP-Client, kein NTP-Server.

    • 2
      Von Patricia Klar am Di, 3. Oktober 2017 um 20:53 #

      systemd-timesyncd ist ein SNTP-Client, kein NTP-Server.

      Verwirr doch diese »ichbinLinuxexperteweilichUbuntuinstallierenkann« mit deinen richtigen Aussagen nicht.
      Dieser Mensch war froh, dass er seinen Satz einigermaßen verständlich absetzen konnte.

    1
    Von man-draker am Di, 3. Oktober 2017 um 10:56 #

    Du übersiehst da wohl einen wichtigen Aspekt:
    "Im Vergleich zu einem "echten" NTP-Server ist in diesem Dienst nur die Clientfunktionalität umgesetzt."
    Quelle: Zeit per Systemd mit timesyncd synchronisieren

    Und der Review nennt zumindest auch Fehler in der Serverkomponente.

    Wer nur Clients betreibt und diese auch mit systemd, für den ist dein Vorschlag sicher eine Option. (Wobei der entsprechende Dienst von systemd im Zweifel noch nicht überprüft wurde.)

    • 1
      Von gundl am Di, 3. Oktober 2017 um 14:48 #

      Ich wage auch zu bezweifeln das der systemd eine gute Wahl ist wenn Sicherheut relevant ist. Einfach weil die Art wie dort mit Sicherheitsfehlern umgegangen wird nicht gerade hinreichend Professionalität erwarten lässt.

      • 1
        Von b.hopp am Di, 3. Oktober 2017 um 16:46 #

        Hallo, da möchte ich 100% zustimmen! In unserer Kölner LUG durfte ich mich dank genau dieser Argumente schon als Ewiggestriger anpöbeln lassen. Ich finde den Umgang mit Bugs wichtig, und die Entwickler von systemd haben sich hierbei bislang nicht mit Ruhm bekleckert :-)
        viele Grüße!

        • 1
          Von Helge Weiß am Mi, 4. Oktober 2017 um 09:48 #

          die Entwickler von systemd haben sich hierbei bislang nicht mit Ruhm bekleckert

          Du bist ein Ewiggestriger, denn sonst würdest deiner Behauptung zumindest etwas Recherche angedeihen lassen.
          Wie viele Sicherheitsrelevante Bugs - die auch wirklich auszunutzen waren - gab es im gesamten Entwicklungszeitraum von systemd und welcher dieser Bugs wurde nicht zeitnah gefixt?

        1
        Von Helge Weiß am Mi, 4. Oktober 2017 um 09:51 #

        Ich wage auch zu bezweifeln das der systemd eine gute Wahl ist wenn Sicherheut relevant ist.

        Und jetzt möchte ich bitte valide Quellen zu deiner Behauptung sehen!

        • 0
          Von schmidicom am Mi, 4. Oktober 2017 um 11:04 #

          Er spielt vermutlich auf das inzwischen geänderte Verhalten von systemd an welches eintrat wenn in einem systemweiten Service-Unit, laut Meinung der systemd-Entwickler, ein "ungültiger" Benutzer angegeben wurde. Eine Designentscheidung welche ich ebenfalls als suboptimal angesehen habe aber trotzdem verstehe ich für meinen Teil unter einem Bug eigentlich etwas anderes.

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Okt 2017 um 11:06.
          • 1
            Von Helge Weiß am Mi, 4. Oktober 2017 um 11:41 #

            trotzdem verstehe ich für meinen Teil unter einem Bug eigentlich etwas anderes.

            Wie bereits richtig erwähnt, ist dies eine Designentscheidung und kein Bug!
            Doch diese Möchtegern-Auskenner schrieben allerdings etwas von Sicherheitsrelevantem Bug und dazu hätte ich gern die Quellen.

            • 0
              Von schmidicom am Mi, 4. Oktober 2017 um 11:59 #

              ...schrieben allerdings etwas von Sicherheitsrelevantem Bug und dazu hätte ich gern die Quellen.
              Weil es zu einer CVE hochgeschaukelt wurde: CVE-2017-1000082

              Dieser Beitrag wurde 2 mal editiert. Zuletzt am 04. Okt 2017 um 13:08.
              • 1
                Von devent am Mi, 4. Oktober 2017 um 16:44 #

                Ich weiß wirklich nicht wieso immer diese Aufregung um poettering. Es ist kein Bug in Systemd, weil das Verhalten so gewollt und dokumentiert ist.

                https://github.com/systemd/systemd/issues/6237#issuecomment-312481714

                That's exactly what happens, and what I wrote above: if the username is valid but the user doesn't exist we'll let the unit fail on start. If the username is already invalid syntax-wise we'll log about it but proceed.

                https://github.com/systemd/systemd/issues/6237#issuecomment-312461325

                Part of this behavior is actually documented in systemd.unit(5): "Unit files may contain additional options on top of those listed here. If systemd encounters an unknown option, it will write a warning log message but continue loading the unit."

        1
        Von Blackhole am Mi, 4. Oktober 2017 um 11:52 #

        Beweis durch Behauptung? Oder was soll das hier sein?

1
Von statistik am Di, 3. Oktober 2017 um 10:41 #

Diese Studien -- beziehen die sich auf ein Jahr oder unterschiedliche Zeiträume oder die gesamte Projekrlaufzeit der Projekte?

Dann entwickel ich jetzt nämlich nen superntpd und mach sofort ne Studie bevor jemand eine Sicherheitslücke findet. Dann hab ich den sichersten Zeitserver entwickelt den es je gab.

2
Von needle am Di, 3. Oktober 2017 um 15:43 #

OpenNTPD, ein Server und Client. http://www.openntpd.org. Die liefern auch ganz andere bekannte und weniger bekannte Software OpenSSH und libressl. Merkwürdig dass dieser nicht erwähnt wurde, vor allem ist das Paket in fast allen wichtigen RPM Repositories vorhanden.

mfg
needle

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung