[GTER] NTP como amplificador de ataques

[Antonio M. Moreiras]

sobre ntpd versus ntpdate:

- os relógios dos computadores são ruins, atrasam ou adiantam, têm erros
de frequência...

- o ntpd funciona criando uma espécie de relógio virtual no computador,
e ajusta a frequencia desse relógio pra que ele esteja sempre certo...

- o ntpdate só acerta a hora de tempos em tempos, não acerta a
frequência do relógio

- fala-se há anos de se descontinuar o ntpdate, e o ntpd é realmente
superior em resultados...

- recomendamos usar o ntpd (falando em nome da equipe do NTP.br do NIC.br)


sobre a configuração do ntpd:

- é muito ruim que o ntpd seja servidor e cliente ao mesmo tempo, você
tem razão... mas você pode bloquear consultas externas

- o uso de "restrict default ignore", pelo menos nas versões de ntp que
testei, impedia também as próprias consultas do ntpd para suas fontes de
tempo e exigia que se colocasse uma clausula "restrict" pra cada
servidor consultado... pode-se usar, mas faz o ntp.conf ficar grande e
complicado... não tenho bem certeza se isso é um bug, ou uma "feature"
ruim...

- "disable monitor" resolve o problema pras consultas "monlist" que
estão sendo usadas em ataques

- "restrict default noquery" bloqueia outras consultas administrativas
como "ntpq -p" ou "ntpq -c rl"... essas consultas fazem sentido pra
servidores NTP, elas permitem avaliar como um determinado servidor está
configurado e se está bem sincronizado... se você tem um servidor NTP
público (como os do NTP.br) destinado pra uso de qualquer um na
Internet, é importante que os clientes possam fazer essas consultas...
mas antevejo problemas futuros aqui (essas consultas também podem ser
usadas pra amplificação)...  se seu servidor é pra uso só dentro da sua
empresa, isso não é importante e vc pode deixar o "noquery" ativo... se
você tem só um cliente ntp, deixe o "noquery" ativo

- ninguém ainda descobriu um jeito de usar as consultas simples de tempo
pra ataques... então não há mal em deixar consultas de tempo abertas...
mas se também não há utilidade nisso, de um ponto de vista de segurança,
é melhor não permiti-las: se você usa o ntpd só como cliente crie um
filtro (iptables, pf, etc) pra não permitir consultas originando-se
externamente para sua porta 123 upd (libere apenas os pacotes vindos das
suas referências ntp, ou use um firewall stateful, que permite respostas
dos servidores às suas consultas)

[]s
Moreiras.


On 15/01/14 12:38, Paulo Fragoso wrote:
> Olá Moreiras,
> 
> Em um curso de IPv6 em Recife comentei que não deixava habilitado NTPd
> nos meus appliance (FreeBSD em CF), eram uns 150 na época, todos rodavam
> um ntpdate de hora em hora, conseguia então uma boa sincronização nesta
> rede responsável pelos clientes banda larga.
> 
> A vantagem é que não tenho um servidor escutando a porta 123 em todos os
> pontos appliences remotos o tempo todo.
> 
> Uma alternativa no NTPd seria utilizar:
> 
> restrict default ignore
> 
> em todos os NTPd clientes, liberando apenas os servidores utilizados
> para sincronização.
> 
> Paulo.