O hardening (fortalecimento) de NTP (Network Time Protocol - Protocolo de Tempo da Rede) em sistemas web é essencial para garantir a integridade de logs, certificados SSL/TLS, sessões de usuário e auditorias, evitando ataques de amplificação DDoS e manipulação de tempo. O protocolo utiliza a porta UDP 123 e com NTS utiliza a porta 4460.
Muitas vezes, até uma simples atualização do sistema pode falhar caso o relógio não estiver sincronizado com os servidores. Em uma rede interna, os access points podem não fornecer internet caso o relógio não esteja sincronizado com o servidor ou se o servidor estiver com a hora errada.
A segurança e sincronização de horários tornou-se crítica atualmente. Hoje, a sincronização de tempo não serve apenas para "deixar o relógio certo", mas é um requisito de segurança e funcionamento para quase tudo em uma rede moderna.
Deixo alguns exemplos de falhas de segurança dependentes do tempo (relógio certo):
1- Certificados
Se o servidor estiver com a data errada, mesmo que por poucos minutos, ele pode considerar um certificado válido como expirado ou vice-versa, derrubando sites, VPNs e conexões seguras.
2- Protocolos de Autenticação
Sistemas como Active Directory (Kerberos), dependendo das configurações, podem parar de funcionar se a diferença entre o cliente e o servidor for maior do que 5 minutos, impedindo o login de usuários.
3- Análise de Logs e Perícia
Se cada dispositivo tiver um horário diferente é impossível reconstruir a linha do tempo do evento (ex: "O ataque começou no Switch às 10:00, mas o servidor diz que foi às 10:05").
4- Wi-Fi e Roaming
Em redes com múltiplos Access Points (APs) a sincronização é vital para o Roaming (passar de um AP para outro sem cair). Protocolos como 802.11r usam chaves temporais. Se o AP 1 e o AP 2 estiverem dessincronizados o dispositivo do usuário pode ser desconectado ao tentar trocar do AP 1 para o AP 2 (ou vice-versa), ou seja, o usuário estará caminhando pela empresa/universidade/campus/etc e perderá o acesso à internet.
Ao final tem um link para instalação e configuração do Chrony para quem não o tenha instalado e configurado.
CONFIGURANDO
NTP ou Chrony (use um ou outro).
NTP
No Linux (geralmente /etc/ntp.conf), aplique restrições rígidas para evitar que seu servidor seja usado em ataques de reflexão:
$ sudo vim /etc/ntp.conf
Coloque dentro:
# Restringe acesso padrao restrict default kod nomodify notrap nopeer noquery # IPv4 restrict -6 default kod nomodify notrap nopeer noquery # IPv6 # # Permite localhost restrict 127.0.0.1 restrict -6 ::1 # # Permite upstream de confiança (ex: ntp.br) restrict pool ntp.br nomodify notrap noquery server a.st1.ntp.br iburst nts server b.st1.ntp.br iburst nts server c.st1.ntp.br iburst nts server d.st1.ntp.br iburst nts # # Desabilita monitoramento (desabilita o 'comando' monlist usado para ataques DDoS) disable monitor
Salve e saia.
Reinicie o serviço:
$ sudo systemctl restart ntp
Ou
$ sudo systemctl restart ntpd
CHRONY
Para quem tiver o Chrony instalado não necessita configurar o NTP, pois este deve estar desabilitado ou desinstalado para não dar conflito.
No chrony.conf verifique e/ou adicione:
# Rede(s) permitida(s) allow 192.168.1/24 # Fontes de tempo server a.st1.ntp.br iburst nts server b.st1.ntp.br iburst nts server c.st1.ntp.br iburst nts server d.st1.ntp.br iburst nts # Estratégia de segurança padrão do Chrony: # 1. Não precisa de 'restrict default' (bloqueio é o padrão) # 2. Localhost já é permitido para o chronyc via socket # 3. Ratelimit para evitar abusos (similar ao kod e limited do NTP) ratelimit interval 3 burst 16 # Salva a derivação do relógio driftfile /var/lib/chrony/drift # Desativar completamente a porta de comandos via rede cmdport 0
Salve e saia.
Reinicie:
$ sudo systemctl restart chrony
- O Chrony suporta NTS nativamente. Basta adicionar a opção nts ao final da linha do servidor;
- O Chrony bloqueia tudo por padrão. Você não precisa configurar "regras de negação" para o público. Ele só responderá a quem estiver na lista allow;
- O Chrony já permite acesso via localhost (127.0.0.1/::1);
- O Chrony é imune ao ataque monlist que afetava o NTP antigo, pois não possui esse comando;
- Para os servidores do NTP.br (que suportam NTS), a autenticação já está "embutida" no protocolo, precisando somente do parâmetro nts.
CONCLUSÃO
Boas práticas
Use múltiplas fontes: Configure pelo menos 4 servidores NTP.
Isolamento: Utilize um servidor NTP interno, por exemplo, o Chrony, sincronizado com os servidores https://ntp.br/.
NTS: Considere o uso de NTS para autenticação criptográfica moderna.
Autenticação NTP: Use chaves simétricas para garantir que o servidor Web sincronize somente com servidores NTP autorizados (O Chrony usa Network Time Security (NTS) nativo que é mais seguro).
Caso tenha firewall (IPTables, NFTables, PFSense, UFW, etc), libere a porta 4460 para o NTS funcionar.
Exemplos:
$ sudo ufw allow out 4460/tcp
$ sudo iptables -A OUTPUT -p tcp --dport 4460 -j ACCEPT
No nftables.conf:
table inet filter {
chain output {
type filter hook output priority 0; policy drop;
# Tráfego para sincronização de tempo (NTP.br)
tcp dport 4460 accept comment "NTS Key Exchange"
udp dport 123 accept comment "NTP Traffic"
# Permitir tráfego já estabelecido
ct state established,related accept
}
}Passo a Passo no pfSense:
Vá em Firewall > Rules.
Selecione a aba da interface onde seu servidor está (geralmente LAN).
Clique em Add (seta para cima) para criar uma nova regra:
Action: Pass
Interface: LAN
Address Family: IPv4 (ou IPv4+IPv6 se usar ambos)
Protocol: TCP
Source: O IP fixo do seu servidor (recomendado) ou LAN net.
Destination: Any (ou crie um Alias com os IPs do NTP.br para ser mais rígido).
Destination Port Range: From 4460 to 4460.
Description: Permitir NTS Key Exchange (Chrony)
Clique em Save e depois em Apply Changes.
Muitas vezes, além da regra de porta, o pfSense pode ter o pacote pfBlockerNG ou Snort/Suricata instalado. Se eles estiverem ativos, podem estar identificando o tráfego na porta 4460 como "não padrão" e descartando a conexão.
Testando no Chrony
Após aplicar as regras e reiniciar o firewall, teste novamente a conectividade.
Reinicie o Chrony:
$ sudo systemctl restart chrony
Teste de rede:
$ nc -zv a.st1.ntp.br 4460
(Deve retornar Connection to ... succeeded).
Caso retornar algo como:
KeyID 0/KLen 0: A conexão segura não foi estabelecida.
Verifique o handshake:
$ sudo chronyc authdata
Atmp (Attempts): O número 2 em Last Atmp mostra que o Chrony tentou, mas não obteve sucesso recente em renovar os cookies de segurança.
Todos os servidores agora devem exibir KeyID maior que 0 e KLen como 256.
Comandos úteis Chrony:
$ sudo systemctl restart chrony
$ sudo service chrony restart
$ sudo chronyc sources
$ sudo chronyc authdata
$ sudo chronyc tracking
$ nc -zv time.cloudflare.com 4460
$ nc -zv nts.netnod.se 4460
$ nc -zv a.st1.ntp.br 4460
$ sudo journalctl -u chrony | grep -i nts
$ ping -s 1400 a.st1.ntp.br
Se você quiser ver em tempo real o que seu Linux está fazendo ao reiniciar, abra um segundo terminal e deixe rodando:
$ sudo journalctl -f -u chrony
Instalação e configuração do Chrony:
Guia de configuração NTS no Linux com Chrony:
