Configurei meu DC (Controlador de Domínio; Windows 2016) conforme descritoaquipara obter seu tempo no meu Sophos-UTM. Então configurei o GPO conforme descrito lá. Mas depois disso e de uma reinicialização do servidor notei que quando executo o comando w32tm /query /statusque em Origem está o Relógio CMOS Local listado, mas aqui o IP do meu Sophos-UTM deve estar listado ou estou errado? Nas capturas de tela do meu link acima, quando o autor dele executa o mesmo comando, está listado o ip correto de sua configuração. Então, o que está errado aqui?
Todas as portas necessárias (UDP 123) são abertas e acessíveis. Eu testei e examinei minhas configurações de firewall. Para fins de teste, executo este comando no DC:w32tm /stripchart /computer:IP-OF-SOPHOS-UTM /dataonly /samples:5
Com esse comando eu recebo 5 Timestamp-Samples do Sophos-UTM, então minhas regras de firewall estão funcionando e a configuração está correta. Eu vi isso nos logs também.
Este DC é uma máquina virtual, rodando em vSphere ESXi (versão gratuita 7.0.1). A sincronização de horário entre ESXi-Host e Guest está desabilitada conforme descrito emDocumentação oficial do VMware.
Aqui está a saída do comandow32tm /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)
Saída do 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)
Saída do 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)
Saída do comandow32tm /resync /rediscover
Resynchronize command is sent to the local computer.
The computer was not synchronized because no time data was available.
Comportamento muito estranho. Alguém aí, que tem uma solução para isso?
Responder1
Encontradoa soluçãopara o problema, depois de muitas horas de pesquisa.. No meu caso foi o Hewlett Packard Switch HPE OfficeConnect 1820
Um recurso dos modelos HP Procurve mais recentes (série 18xx, como 1810G etc.) é chamado de "Auto DoS". Você pode encontrá-lo na seção “Segurança” e depois em “Segurança Avançada”.
Se você ativar o recurso Auto DoS, o tráfego será bloqueado com base em uma destas condições:
a porta de origem (TCP/UDP) é idêntica à porta de destino (NTP, SYSLOG, etc)
a porta de origem (TCP/UDP) é 'privilegiada', portanto, na faixa de 1 -1023.
Isso causará todos os tipos de problemas, mas primeiro isto: "Por que diabos um dispositivo da Camada 2 está filtrando na Camada 3?". Isso é simplesmente uma loucura.
O NTP não funciona mais. O tráfego syslog não chegará. O tráfego VPN pode não chegar.
Esse problema me custou muito tempo para resolver. Primeiro culpei nosso Firewall, mas o tráfego real chegou à porta de tronco marcada no switch afetado. De alguma forma, o tráfego não foi enviado para a porta do switch na qual o dispositivo de destino estava conectado.
Produtos afetados:
HP ProCurve 1810G - J9449A (8 portas) e J9450A (24 portas)
Portanto, depois de desativar a função Auto DoS Protection, ela funciona conforme o esperado. Como Fonte no Windows agora está o IP correto listado e não o Relógio CMOS Local e agora vejo o tráfego no tcpdump. Portanto, esta pode ser a solução para outras pessoas, se usarem um switch HP.
Depois de mais pesquisas parece que apenas a opção Prevent UDP Blat Attackdeve ser desativada. Como mencionadoaqui, Prevent UDP Blat Attack – UDP Source and Destination Port match. Então, depois de analisar o tcpdump, vi que meu UTM e o Windows Server usam a porta 123, então não é de admirar por que essa opção bloqueia o tráfego....
Aqui está uma captura de tela da configuração final.
