01 - NTP (Network Time Protocol - 123)

video explicativo

Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

NTP (Network Time Protocol)

1. Definição e Importância

O NTP (Network Time Protocol) é o protocolo padronizado para sincronização de relógios em redes de computadores. Especificado na RFC 5905 (NTPv4), opera sobre UDP na porta 123. Seu objetivo é manter os relógios de hosts distribuídos com diferença de no máximo alguns milissegundos em relação a uma referência precisa.

A sincronização de tempo é fundamental em infraestruturas modernas por motivos críticos:

Logs correlacionáveis: sem tempo sincronizado, é impossível correlacionar eventos entre servidores (security forensics, debugging distribuído).
Validade de certificados TLS: certificados têm validade temporal; relógios errados causam falhas de validação.
DNSSEC: assinaturas têm timestamps de validade; relógios errados quebram a validação.
Kerberos: protocolo de autenticação com tickets de curtíssima duração (5-10 min); dessincronização de minutos quebra autenticação.
Bancos de dados distribuídos: timestamps em transações; dessincronização causa conflitos.

2. Hierarquia de Stratum

O NTP organiza servidores em uma hierarquia chamada stratum, onde cada nível é mais distante da fonte de tempo de referência:

Stratum	Descrição	Exemplo
0	Fontes de referência (relógios atômicos, GPS, rádio)	GPS, Galileo, DCF77, WWVB
1	Servidores diretamente conectados a stratum 0	time.google.com
2-15	Servidores sincronizados a stratum inferior	ISPs, universidades
16	Não sincronizado	Indefinido/inválido

Stratum 0 não é acessível via rede — são dispositivos físicos (receptores GPS, relógios atômicos de césio, sinais de rádio como DCF77 na Europa). Servidores stratum 1 recebem o tempo diretamente desses dispositivos via interface serial, PPS (Pulse Per Second), etc.

Servidores de stratum mais alto são menos precisos: stratum 1 tem precisão de microssegundos; stratum 2 de milissegundos; stratum 3 de dezenas de milissegundos. A partir de stratum 15, o NTP considera inválido (stratum 16 = "não sincronizado").

Pool NTP (ntp.org)

Para evitar que todos consultem os poucos servidores stratum 1, existe o NTP Pool Project (pool.ntp.org), uma malha global de voluntários que oferecem servidores NTP sob DNS round-robin:

0.br.pool.ntp.org
1.br.pool.ntp.org
2.br.pool.ntp.org
3.br.pool.ntp.org

Cada hostname retorna IPs diferentes de servidores voluntários no Brasil. Para uso geral, basta apontar para pool.ntp.org.

3. Algoritmo de Sincronização

O NTP não é simplesmente "setar o relógio" para o valor recebido. Ele calcula o offset (diferença entre o relógio local e o de referência) e o delay (tempo de ida e volta do pacote), usando 4 timestamps em cada mensagem:

T1: Origem envia pacote (timestamp no cliente)
T2: Destino recebe pacote (timestamp no servidor)
T3: Destino envia resposta  (timestamp no servidor)
T4: Origem recebe resposta  (timestamp no cliente)

Cálculos:

Offset = ((T2 - T1) + (T3 - T4)) / 2
Delay  = (T4 - T1) - (T3 - T2)

Para compensar o tempo de viagem da rede, o offset é a média entre o tempo de ida e o tempo de volta. Se a rede for simétrica (ida = volta), o offset é preciso. Em redes assimétricas (ex: ADSL), o NTP acumula erro proporcional à assimetria.

Dispersão (Dispersion)

A dispersão mede a variação estatística dos offsets medidos em consultas sucessivas. É a incerteza acumulada do tempo. Servidores NTP rejeitam fontes com alta dispersão (instáveis).

Filtragem de Marzullo

Quando há múltiplas fontes, o NTP usa o algoritmo de Marzullo para identificar e descartar fontes ruins ("falsetickers") e manter apenas as concordantes ("truechimers"). Tipicamente são usadas 4-5 fontes para garantir sobrevivência à falha de 1 ou 2.

4. Implementações

ntpd (NTP Classic, ISC)

A implementação de referência histórica (RFC 5905). Mantida pela Network Time Foundation. Robusta, mas com arquitetura antiga (single-threaded). Vulnerabilidades históricas (CVE-2014-9295 em 2014 permitia amplificação DDoS de 556x).

chronyd (Chrony)

Implementação moderna (desenvolvida por Miroslav Lichvar na Red Hat), com várias vantagens:

Sincroniza mais rápido após boot.
Funciona melhor em redes intermitentes (Wi-Fi, mobile).
Suporta hardware timestamping para precisão sub-microssegundo.
Pequeno footprint.

Padrão em RHEL 7+, Fedora, CentOS 8, Ubuntu (a partir de 18.04). Recomendado para novos deployments.

systemd-timesyncd

Implementação minimalista, parte do systemd. Faz apenas client NTP simples, sem servir tempo a outros hosts. Bom para desktops e containers.

openntpd

Implementação da OpenBSD com foco em segurança (privilégios reduzidos, sandbox). Menos preciso que ntpd/chronyd.

5. Configuração Prática

chrony (Linux moderno)

# /etc/chrony/chrony.conf
server 0.br.pool.ntp.org iburst
server 1.br.pool.ntp.org iburst
server 2.br.pool.ntp.org iburst
server 3.br.pool.ntp.org iburst

# Permitir servir para rede local (quando servidor)
allow 192.168.1.0/24

# Drift file (compensação do erro do oscilador local)
driftfile /var/lib/chrony/drift

# Hardware timestamping (precisão sub-microssegundo)
hwtimestamp *

# Log
logdir /var/log/chrony
makestep 1.0 3   # corrige grandes offsets no boot (até 3 saltos de 1s)
rtcsync          # sincroniza RTC (BIOS)

ntpd (Linux clássico)

# /etc/ntp.conf
server 0.br.pool.ntp.org iburst
server 1.br.pool.ntp.org iburst
driftfile /var/lib/ntp/ntp.drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

Cisco

ntp server 200.160.7.193
ntp server 200.189.40.8
ntp source Vlan10
ntp update-calendar   # sincroniza hardware clock

Windows (w32time)

w32tm /config /manualpeerlist:"0.br.pool.ntp.org,1.br.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync

Em Active Directory, o PDC emulator da raiz da floresta deve ser sincronizado com fonte externa; demais DCs sincronizam com ele; membros sincronizam com DCs.

6. Diagnóstico

# chrony
chronyc sources -v          # fontes e seus strata
chronyc tracking             # status da sincronização
chronyc sourcestats          # estatísticas por fonte

# ntpd
ntpq -p                      # peers e seus offsets
ntpq -c "rv 0"              # variáveis do sistema
ntpdc -c sysinfo            # info do servidor

Interpretação de `ntpq -p`

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp1.ptb.br    .PTB.            1 u   64  128  377   12.4ms  -0.234ms   0.521
+gps1.example.c .GPS.            1 u   32  128  377    2.1ms  +0.123ms   0.234
-pool-1.example 192.36.143.130   2 u   16  128  377   35.6ms -1.234ms   1.234

Símbolos:

* — fonte atualmente selecionada (synchronizado).
+ — fonte candidata (truechimer).
- — fonte rejeitada por clustering.
x — fonte rejeitada (falseticker).
? — fonte não testada (alcance baixo).

7. Segurança: Amplificação DDoS

O NTP é vulnerável a amplificação DDoS via comando monlist (modo 7), que retorna a lista de até 600 últimos clientes — uma consulta de 8 bytes gera resposta de 4 KB (amplificação ~556x). Ataques de centenas de Gbps foram perpetrados em 2013-2014 usando monlist.

Mitigação:

Desativar monlist: disable monitor em ntp.conf.
Usar restrict ... noquery para limitar quem pode fazer consultas.
Usar chronyd, que não implementa monlist.

8. NTS (Network Time Security)

O NTP clássico não autentica respostas — um atacante on-path pode forjar respostas e dessincronizar o cliente. NTS (RFC 8915, 2020) resolve isso:

Cliente estabelece sessão TLS com servidor NTS (porta 4460 TCP).
Recebe cookies criptográficos.
Usa cookies para autenticar mensagens NTP UDP subsequentes (extensão NTS-KE).

Implementado em ntpd 4.2.8p12+, chrony 4.0+. Em adoção crescente em ambientes de alta segurança (bancos, governo).

Configuração chrony com NTS

# /etc/chrony/chrony.conf
server time.cloudflare.com:4460 nts iburst
server nts.netnod.se nts iburst

# Verificar NTS
chronyc -N authkey
chronyc -N serverstats

9. Boas Práticas

Em Servidores

Apontar para 4 fontes (mínimo) em strata diferentes.
Não depender de uma única fonte (GPS local pode falhar).
Usar hardware timestamping em redes críticas (datacenter financeiro).
Habilitar NTS em ambientes que exigem segurança.

Em Clientes

Em desktops, usar systemd-timesyncd é suficiente.
Em servidores, preferir chronyd (mais robusto).
Não apontar milhões de clientes para servidores stratum 1 (use pool ou servidor interno stratum 2/3).
Configurar tzdata corretamente: NTP opera em UTC; timezone é conversão local.

Em Datacenters

Servidores internos sincronizam com 2-3 servidores NTP locais.
Esses servidores locais sincronizam com fontes externas redundantes (GPS + pool).
Hardware PPS (Pulse Per Second) para precisão sub-microssegundo.
Em clusters de banco de dados distribuído (CockroachDB, Spanner), considerar PTP (Precision Time Protocol, IEEE 1588).

10. Tabela Resumo

Conceito	Valor
RFC	5905 (NTPv4)
Porta	UDP 123
Strata válidos	0 a 15 (16 = não sincronizado)
Protocolo	UDP,~64 bytes por pacote
Modo client-server	Default
Pool público	pool.ntp.org
Implementações	ntpd, chronyd, systemd-timesyncd, openntpd
NTS (segurança)	RFC 8915
PTP (alternativa)	IEEE 1588 (precisão sub-microssegundo)

11. Conclusão

O NTP é uma das peças mais subestimadas da infraestrutura de internet. Sem tempo sincronizado, logs não correlacionam, certificados TLS falham, autenticação Kerberos quebra, DNSSEC falha. Apesar de simples na aparência (cliente consulta servidor, ajusta relógio), o algoritmo interno é sofisticado: compensa delay de rede, filtra fontes ruins, escolhe as melhores, e mantém o relógio estável via drift file. A transição de ntpd para chronyd traz melhorias significativas em robustez e segurança. Para ambientes críticos, NTS agora oferece autenticação criptográfica das respostas, mitigando ataques de manipulação de tempo. Engenheiros de redes devem sempre configurar NTP em todos os hosts como primeira etapa de qualquer deployment — sem ele, todo o resto é sabidamente não confiável.