Wir probieren einige NTP-Konfigurationen in der Datei ntp.conf aus und möchten sicher sein, ob der NTP-Server gesichert ist oder nicht.
Befolgen Sie die hier gegebene Empfehlung: https://support.ntp.org/Support/AccessRestrictions#Section_6.5.1.2.1.
wir fügten hinzu :
IPV4: restrict -4 default limited kod nomodify notrap nopeer noquery
IPv6: restrict -6 default limited kod nomodify notrap nopeer noquery
Nun lautet die Frage: Basierend auf der in der Dokumentation geschriebenen Zeile:
Da Sie anderen gestatten, die Uhrzeit von Ihrem ntpd abzurufen, gestatten Sie ihnen auch, Ihre Serverstatusinformationen anzuzeigen (auch wenn dadurch Informationen zu Ihrem Betriebssystem und Ihrer ntpd-Version preisgegeben werden können)?
Wie können wir sicher sein, ob der Server seinen Status oder andere Betriebssysteminformationen sendet oder nicht?
Was ist außerdem der Unterschied, wenn wir der Einschränkung keine Option „noquery“ hinzufügen, und wie können wir mit und ohne Option „noquery“ testen, d. h., ob das Hinzufügen einer solchen Option Auswirkungen hat oder nicht? (Wir möchten aus Sicherheitsgründen testen.)
Können wir Wireshark verwenden, um Status- oder Betriebssysteminformationen abzurufen und unsere Konfigurationsoptionen zu testen?
Antwort1
Die Referenzimplementierung von ntpd stellt viele ihrer Implementierungsvariablen über die Programme bereitntpq(Undntpdcwas nur der Autor zu schätzen weiß). Diese verwenden ein Steuerprotokoll in speziellen NTP-Paketen. Es ist möglich, dass der Steuerkanal die NTP-Konfiguration ändern kann, obwohl dies in der modernen Ära, in der Sie die Bereitstellung von Konfigurationsdateien für eine beliebige Anzahl von Hosts automatisieren können, selten verwendet wird.
Risiken bei der Wartung von ntpd sind in erster LinieVerhinderung der IP-Amplifikation an gefälschte Adressen, und schützen Sie Ihre Zeitsynchronisierungskonfiguration vor Änderungen durch nicht autorisierte IP-Adressen in den Netzwerken.
Wie immer mildert das Patchen einige Mängel. Ein Amplification-Angriff über die Funktion „monlist“ führte zuCVE-2013-5211. Dies hätte schon vor Jahren ein Update sein sollen, aber überprüfen Sie dasalleIhrer Hosts befinden sich auf einer unterstützten Distribution und werden von einem Betreuer betreut.
Die ganze Aufmerksamkeit, die wir der Monlist gewidmet haben, führte zu einigen Tools, mit denen man ganz einfach danach suchen kann. Zum Beispiel:Nmap-Skript NTP-Monlist.
Die vollständige Liste der Funktionen finden Sie imfür ntpq dokumentierte Befehle. Diese Zeilen in der „Wählen Sie Ihre eigene Konfiguration“ des Wikis unterscheiden sich durch noquery, das alle NTPQ-Abfragen vollständig ablehnt. Der Zeitdienst läuft weiter. Beispielsweise würde dieses NMAP-Skript nichts zurückgeben. Im Gegensatz dazu nomodfyist dies eine Zugriffsregel, die nur die Befehle steuert, die die Konfiguration ändern. nomodifySollte eindeutig stark eingeschränkt werden, möglicherweise nur auf den lokalen Host.
Vergleichen Sie sie mit Beispielkonfigurationen an anderer Stelle, beispielsweise aus dem Paket Ihrer bevorzugten Distribution.Ntp.conf von RHEL 7schlägt Folgendes als Ausgangspunkt für die Zugriffskontrolle vor:
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict ::1
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Disable the monitoring facility to prevent amplification attacks using ntpdc
# monlist command when default restrict does not include the noquery flag. See
# CVE-2013-5211 for more details.
# Note: Monitoring will not be disabled with the limited restriction flag.
disable monitor
Beachten Sie die Monlist-Abschwächung, auch wenn NTPD inzwischen gepatcht ist. Außerdem kann die Standardeinstellung für Remote-Hosts nicht abgefragt oder geändert werden. Mit einer leichten Änderung könnte dies zu einem NTP-Host führen, der bereit ist, das öffentliche Internet zu bedienen.
Sobald Sie wissen, welche ntp.conf Sie möchten, stellen Sie diese natürlich bereit. Automatisieren Sie die Konfiguration von NTP-Servern und erhalten Sie eine sinnvolle Konfiguration in den Vorlagenbildern aller Hosts.
Diese ganze Monlist-Diskussion geht nicht auf Ihre ursprüngliche Frage zur Betriebssystem- und Plattformidentifizierung über NTP ein. Laut NTPQ-Dokumenten können diese Build-Informationen über den readvarSteuerungsbefehl in Systemvariablen erscheinen. Wie bei einem Remote-Server: ntpq -c readvar time.example.net. Allerdings müssen hier einige Implementierungsdetails entschlüsselt werden, z. B. welche Zuordnungs-ID der betreffende NTP-Host ist.
Persönlich bin ich nicht sehr besorgt darüber, Build-Informationen über ntpd preiszugeben. Wenn jemand erfährt, dass mein ntpd und ein Teil der Zustandsmaschine auf dem neuesten Stand sind, kann er damit nicht viel anfangen. Ein Angreifer würde gefälschte NTP-Pakete an jeden Host senden, den er erreichen kann, in der Hoffnung auf Verstärkung.