Guia da porta NTP: sincronização de tempo no UDP 123

Um cliente NTP envia periodicamente uma solicitação para um ou mais servidores de horário através de UDP 123. O servidor retorna carimbos de data e hora que permitem ao cliente estimar o deslocamento, o atraso e o jitter, e então o cliente ajusta seu relógio local sem fazer saltos perturbadores, a menos que o desvio seja muito grande.

As implantações NTP geralmente são organizadas em estratos. Stratum 0 é um relógio de referência como GPS ou uma fonte atômica. Os servidores do estrato 1 conectam-se diretamente a essas referências e os servidores do estrato inferior distribuem o tempo ainda mais na rede. A maioria das organizações deve usar fontes upstream confiáveis ​​e fornecer NTP interno aos seus próprios sistemas.

Um cliente NTP precisa de acesso de saída ao UDP 123 para suas fontes de tempo configuradas. Um servidor NTP precisa de UDP 123 de entrada dos clientes que deve servir. Essas são questões de firewall diferentes, e misturá-las é uma fonte comum de falha na sincronização de horário.

Estações de trabalho e servidores de aplicativos geralmente atuam apenas como clientes. Controladores de domínio, dispositivos de horário de rede, infraestrutura de monitoramento e hubs de horário internos podem atuar como servidores para o restante da frota.

Permitir UDP 123 de saída de sistemas que precisam sincronizar com fontes de horário externas ou internas confiáveis. Permitir UDP 123 de entrada apenas em servidores que fornecem NTP intencionalmente a clientes conhecidos.

Não exponha um servidor NTP amplamente à Internet, a menos que ele seja intencionalmente operado como um serviço de horário público com capacidade, limitação de taxa, monitoramento e controles de abuso. O NTP público mal configurado pode ser abusado para ataques de reflexão e amplificação.

Antes de permitir o UDP 123, decida quais sistemas são clientes, quais sistemas são servidores e quais fontes de tempo upstream são confiáveis. Confirme se o seu ambiente usa chrony, systemd-timesyncd, ntpd, Windows Time Service, uma hierarquia de domínio ou um dispositivo dedicado.

Um verificador de porta pode ajudar na acessibilidade, mas a sincronização de horário também deve ser verificada no nível do protocolo e do relógio. Use dados chronyc, ntpq, w32tm, timedatectl ou monitoramento para confirmar deslocamento, estrato, seleção de fonte e desvio.

Em domínios do Windows, o Windows Time Service geralmente sincroniza membros do domínio por meio da hierarquia de domínio, com o emulador PDC configurado em fontes upstream confiáveis. Servidores Windows autônomos podem ser configurados com w32tm e regras de firewall para UDP 123 quando cumprirem o horário.

No Linux, chrony é comum em distribuições modernas, enquanto ntpd e systemd-timesyncd também aparecem. Configure pools confiáveis ​​ou servidores internos, permita UDP 123 somente onde o host fornecer tempo e monitore o deslocamento e a integridade da origem.

Em dispositivos de rede, aponte switches, roteadores, firewalls e dispositivos em fontes NTP internas sempre que possível. O tempo preciso do dispositivo torna os registros, certificados, VPNs e investigações de incidentes muito mais confiáveis.

Comece verificando se o UDP 123 pode ser alcançado entre o cliente e o servidor de horário pretendido. Em seguida, verifique a sincronização real com rastreamento chronyc, fontes chronyc, ntpq -p, timedatectl timesync-status ou w32tm /query /status dependendo da plataforma.

Se você operar um servidor NTP, teste em uma rede cliente conhecida e confirme se redes não autorizadas não podem consultá-lo. Para serviços voltados para a Internet, observe o volume de solicitações e os padrões de resposta, pois a acessibilidade por si só não prova uma configuração segura.

Se o NTP não estiver sincronizando, o cliente pode ser bloqueado no UDP 123, usando o servidor errado, rejeitando uma fonte devido ao deslocamento alto ou incapaz de resolver o nome do host do servidor de horário. As máquinas virtuais também podem oscilar se o tempo do host, as ferramentas convidadas e o NTP estiverem brigando entre si.

Se um servidor estiver acessível, mas os clientes ainda se desviarem, inspecione o estrato, o status do salto, a seleção da fonte, o estado do firewall, o comportamento do NAT e se vários sistemas de tempo estão configurados ao mesmo tempo. Para domínios do Windows, verifique a hierarquia de tempo do domínio antes de alterar cada host individualmente.

Restrinja quem pode consultar seus servidores NTP, desative comandos obsoletos de alta amplificação, mantenha o software NTP corrigido e monitore picos de tráfego incomuns. Prefira a distribuição interna de tempo a permitir que cada host consulte servidores públicos aleatórios.

Para ambientes importantes, use diversas fontes de tempo confiáveis, alerte sobre deslocamento excessivo, documente o caminho de tempo oficial e inclua sincronização de tempo nas verificações de resposta a incidentes. O mau momento pode quebrar certificados, autenticação, correlação de log e trabalhos agendados.