Ich habe meinen DC (Domänencontroller; Windows 2016) wie beschrieben konfiguriertHierum seine Zeit von meiner Sophos-UTM zu bekommen. Also habe ich das GPO wie dort beschrieben konfiguriert. Aber danach und nach einem Neustart des Servers ist mir aufgefallen, dass, wenn ich den Befehl ausführe, w32tm /query /statusunter Quelle die lokale CMOS-Uhr aufgeführt ist, aber hier sollte die IP von meiner Sophos-UTM aufgeführt sein oder liege ich falsch? In den Screenshots meines obigen Links ist, wenn der Autor denselben Befehl ausführt, die richtige IP aus seiner Konfiguration aufgeführt. Was läuft hier also schief?
Alle benötigten Ports (UDP 123) sind offen und erreichbar. Ich habe es getestet und mir meine Firewall-Konfigurationen angeschaut. Zu Testzwecken führe ich diesen Befehl auf dem DC aus:w32tm /stripchart /computer:IP-OF-SOPHOS-UTM /dataonly /samples:5
Mit diesem Befehl bekomme ich 5 Timestamp-Samples von der Sophos-UTM zurück, meine Firewall-Regeln funktionieren also und die Konfiguration dort ist korrekt. Das habe ich auch in den Logs gesehen.
Dieser DC ist eine virtuelle Maschine, die in vSphere ESXi (kostenlose Version 7.0.1) läuft. Die Zeitsynchronisierung zwischen ESXi-Host und Gast ist deaktiviert, wie inoffizielle vmWare Dokumentation.
Hier ist die Ausgabe des Befehlsw32tm /query /status
Jump indicator: 0 (no warning)
stratum: 1 (primary reference - synchron. via radio clock)
Precision: -6 (15.625ms per tick)
stem delay: 0.0000000s
stem deviation: 10.0000000s
Reference ID: 0x4C4F434C (source name: "LOCL")
Last successful synchronization time: 07.12.2020 15:04:23
Source: Local CMOS Clock
Polling interval: 6 (64s)
Ausgabe des Befehlsw32tm /query /configuration
[Configuration]
EventLogFlags: 2 (Lokal)
AnnounceFlags: 10 (Lokal)
TimeJumpAuditOffset: 28800 (Lokal)
MinPollInterval: 6 (Lokal)
MaxPollInterval: 10 (Lokal)
MaxNegPhaseCorrection: 172800 (Lokal)
MaxPosPhaseCorrection: 172800 (Lokal)
MaxAllowedPhaseOffset: 300 (Lokal)
FrequencyCorrectRate: 4 (Lokal)
PollAdjustFactor: 5 (Lokal)
LargePhaseOffset: 50000000 (Lokal)
SpikeWatchPeriod: 900 (Lokal)
LocalClockDispersion: 10 (Lokal)
HoldPeriod: 5 (Lokal)
PhaseCorrectRate: 7 (Lokal)
UpdateInterval: 100 (Lokal)
[Time-Provider]
NtpClient (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
ResolvePeerBackoffMinutes: 15 (Richtlinie)
ResolvePeerBackoffMaxTimes: 7 (Richtlinie)
CompatibilityFlags: 2147483648 (Lokal)
EventLogFlags: 0 (Richtlinie)
LargeSampleSkew: 3 (Lokal)
SpecialPollInterval: 900 (Richtlinie)
Type: NTP (Richtlinie)
NtpServer: MY-SOPHOS-UTM-IP,0x5 (Richtlinie)
NtpServer (Lokal)
DllName: C:\Windows\SYSTEM32\w32time.DLL (Lokal)
Enabled: 1 (Lokal)
InputProvider: 0 (Lokal)
AllowNonstandardModeCombinations: 1 (Lokal)
VMICTimeProvider (Lokal)
DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal)
Enabled: 1 (Lokal)
InputProvider: 1 (Lokal)
Ausgabe des Befehlsw32tm /query /peers
Number Peers: 1
Peer: MY-SOPHOS-UTM-IP,0x5
Status: Active
Time remaining: 495.5965885s
Mode: 1 (Symmetrically active)
Stratum: 0 (not specified)
Peer Retrieval Interval: 0 (not specified)
Host polling interval: 4 (16s)
Ausgabe des Befehlsw32tm /resync /rediscover
Resynchronize command is sent to the local computer.
The computer was not synchronized because no time data was available.
Sehr merkwürdiges Verhalten. Hat jemand da draußen eine Lösung dafür?
Antwort1
Gefundendie Lösungfür das Problem, nach vielen Stunden der Recherche.. In meinem Fall war es der Hewlett Packard Switch HPE OfficeConnect 1820
Eine Funktion neuerer HP Procurve-Modelle (18xx-Serie, wie 1810G usw.) heißt „Auto DoS“. Sie finden es im Abschnitt „Sicherheit“ und dann „Erweiterte Sicherheit“.
Wenn Sie die Auto-DoS-Funktion aktivieren, wird der Datenverkehr basierend auf einer der folgenden Bedingungen blockiert:
der Quellport (TCP / UDP) ist identisch mit dem Zielport (NTP, SYSLOG, etc.)
der Quellport (TCP/UDP) ist 'privilegiert' also im Bereich von 1 -1023.
Dies wird alle möglichen Probleme verursachen, aber zuerst dies: „Warum um Himmels Willen filtert ein Layer-2-Gerät auf Layer 3?“ Das ist einfach verrückt.
NTP funktioniert nicht mehr. Syslog-Verkehr kommt nicht an. VPN-Verkehr kommt möglicherweise nicht an.
Die Lösung dieses Problems hat mich viel Zeit gekostet. Zuerst habe ich die Schuld unserer Firewall zugeschoben, aber der eigentliche Datenverkehr kam über den getaggten Trunk-Port des betroffenen Switches an. Der Datenverkehr wurde irgendwie nicht an den Switch-Port gesendet, an den das Zielgerät angeschlossen war.
Betroffene Produkte:
HP ProCurve 1810G – J9449A (8 Anschlüsse) und J9450A (24 Anschlüsse)
Nach dem Deaktivieren der Auto-DoS-Schutzfunktion funktioniert es also wie erwartet. Als Quelle in Windows wird jetzt die richtige IP aufgeführt und nicht die lokale CMOS-Uhr, und jetzt sehe ich den Datenverkehr in tcpdump. Dies könnte also möglicherweise die Lösung für andere Leute sein, wenn sie einen HP-Switch verwenden.
Nach weiteren Recherchen scheint es, dass nur die Option Prevent UDP Blat Attackdeaktiviert werden muss. Wie erwähntHier, Prevent UDP Blat Attack – UDP Source and Destination Port match. Nachdem ich also in tcpdump nachgesehen hatte, sah ich, dass sowohl meine UTM als auch der Windows-Server Port 123 verwenden. Kein Wunder also, dass diese Option den Datenverkehr blockiert …
Hier ein Screenshot der endgültigen Konfiguration.
