He configurado mi DC (Controlador de dominio; Windows 2016) como se describeaquípara obtener su tiempo de mi Sophos-UTM. Entonces configuré el GPO como se describe allí. Pero después de eso y de reiniciar el servidor, noté que cuando ejecuto el comando w32tm /query /status, en Fuente aparece el Reloj CMOS local, pero aquí debería aparecer la IP de mi Sophos-UTM o ¿me equivoco? En las capturas de pantalla de mi enlace anterior, cuando el autor ejecuta el mismo comando, aparece la IP correcta de su configuración. Entonces, ¿qué está pasando aquí?
Todos los puertos necesarios (UDP 123) son abiertos y accesibles. Lo probé y revisé mis configuraciones de firewall. Para fines de prueba, ejecuto este comando en el DC:w32tm /stripchart /computer:IP-OF-SOPHOS-UTM /dataonly /samples:5
Con ese comando obtengo 5 muestras de marca de tiempo de Sophos-UTM, por lo que mis reglas de firewall están funcionando y la configuración allí es correcta. También vi esto en los registros.
Este DC es una máquina virtual que se ejecuta en vSphere ESXi (versión gratuita 7.0.1). La sincronización de hora entre ESXi-Host y Guest está deshabilitada como se describe enDocumentación oficial de vmWare.
Aquí está el resultado del comando.w32tm /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)
Salida del comandow32tm /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)
Salida del comandow32tm /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)
Salida del comandow32tm /resync /rediscover
Resynchronize command is sent to the local computer.
The computer was not synchronized because no time data was available.
Comportamiento muy extraño. ¿Alguien por ahí que tenga una solución para esto?
Respuesta1
Encontróla soluciónpara el problema, después de muchas horas de investigación. En mi caso fue el Hewlett Packard Switch HPE OfficeConnect 1820
Una característica de los modelos HP Procurve más recientes (serie 18xx, como 1810G, etc.) se llama "Auto DoS". Puedes encontrarlo en la sección "Seguridad" y luego en "Seguridad avanzada".
Si habilita la función Auto DoS, el tráfico se bloquea según una de estas condiciones:
el puerto de origen (TCP/UDP) es idéntico al puerto de destino (NTP, SYSLOG, etc.)
el puerto de origen (TCP/UDP) es "privilegiado", por lo que está en el rango de 1 -1023.
Esto causará todo tipo de problemas, pero primero esto: "¿Por qué diablos un dispositivo de Capa 2 filtra en la Capa 3?". Esto es simplemente una locura.
NTP ya no funciona. El tráfico de Syslog no llegará. Es posible que el tráfico VPN no llegue.
Este problema me costó mucho tiempo resolverlo. Primero culpé a nuestro Firewall, pero el tráfico real llegó al puerto troncal etiquetado en el conmutador afectado. De alguna manera, el tráfico no se envió al puerto del conmutador al que estaba conectado el dispositivo de destino.
Productos afectados:
HP ProCurve 1810G - J9449A ( 8 puertos ) y J9450A ( 24 puertos )
Entonces, después de deshabilitar la función Auto DoS Protection, funciona como se esperaba. Como la fuente en Windows ahora es la IP correcta en la lista y no el reloj CMOS local, ahora veo el tráfico en tcpdump. Entonces, esta podría ser la solución para otras personas, si usan un conmutador HP.
Después de más investigaciones parece que sólo Prevent UDP Blat Attackse debe desactivar la opción. Como se mencionóaquí, Prevent UDP Blat Attack – UDP Source and Destination Port match. Entonces, después de mirar tcpdump, vi que mi UTM y Windows Server usaban el puerto 123, así que no es de extrañar por qué esta opción bloquea el tráfico...
Aquí una captura de pantalla de la configuración final.
