Construindo um servidor de horário local

1

Estou tentando instalar um servidor de horário em uma máquina Ubuntu local, para que outros servidores da minha rede possam sincronizá-lo. Decidimos instalar nosso próprio servidor de horário, em vez de permitir que cada servidor seja atualizado de um servidor externo, para minimizar o risco de segurança.

  • Alguma idéia de qual é o melhor servidor para instalar?
  • Há algum problema de segurança conhecido?
  • De onde o servidor deve atualizar? Existe um servidor de horário bem confiável lá fora?

Gostaria de receber ajuda ou links de referência!

Obrigado,

Udi

    
por Adam Matan 02.08.2009 / 13:31

3 respostas

3

Alguns guias que uso ao configurar redes NTP:

  • É uma boa ideia configurar pelo menos dois servidores de tempo na sua rede. Configure-os como peers (a linha "peer [ipaddress]" no ntp.conf) e, se possível, forneça a eles diferentes hosts NTP externos para sincronizar.
  • Configure seus clientes para usar todos os seus servidores de tempo. No caso de alguém ir embora, eles ainda terão um bom tempo e não sairão de sincronia durante a interrupção do evento.
  • Use o Autokey ou a criptografia de chave simétrica entre seus servidores de mesmo nível.
  • Configure linhas acl apropriadas em seu arquivo ntp.conf, permitindo que os peers conversem entre si, mas todos os outros clientes obtêm apenas informações NTP e nenhum dado de controle.

O primeiro ponto é dar a resiliência de sua rede diante de interrupções na Internet. Quando a conexão com a internet é interrompida, seus servidores de mesmo nível mantêm um tempo consensual entre si e nunca saem de sincronia. O que significa que seus clientes não ficarão fora de sincronia. Se o tempo é importante para você, isso é uma coisa muito boa.

Quanto às opções de ACL, a configuração de padrões razoáveis ajudará a evitar que o mal aconteça:

restrict default ignore #deny access to general internet, just 'cause
restrict 192.168.0.0 255.255.0.0 nomodify nopeer # allow restricted access to internal
restrict 192.168.202.202 #allow TimeHost1 full access
restrict 192.168.202.203 #allow TimeHost2 full access
restrict 192.168.200.158 nopeer #allow the admin workstation to make changes

Isso permitirá que os clientes usem ferramentas como o ntpq para diagnosticar problemas de NTP, mas não permitirão que nada mude.

Quanto ao autokey vs. chave simétrica, isso depende de quão robusta você deseja sua rede. Definir valores de ACL apropriados deve fornecer resistência ao mal, mas isso forneceria uma camada adicional de proteção contra falsificação. Dos dois, o autokey é mais fácil de configurar, mas o simétrico é mais novo e mais robusto.

    
por 02.08.2009 / 18:44
9

O pacote padrão ntp (também pode ser ntp-server ou ntp-simple) em qualquer máquina linux física está bem. Não use uma VM.

Muitas pessoas alegam que há vazamento de informações quando outras pessoas podem saber que horas você tem, no entanto muitos outros serviços perdem tempo e você recebe um benefício quando todos os logs são sincronizados em caso de problemas . A configuração debian padrão impede que os usuários remotos façam qualquer coisa, exceto sincronizar o tempo e é o suficiente.

Quanto ao que atualizar do pool.ntp.org é a resposta, use o pool apropriado para o seu país, se possível. Esta também é quase sempre a configuração padrão para o linux ntp.

    
por 02.08.2009 / 13:35
0

Eu recomendaria o OpenNTPd (portátil).

De seu manifesto:

Current NTP daemons are complex and difficult to configure and/or have questionable licenses. Because of this, only a limited number of systems run NTP, resulting in many machines that are off by months and even years. Our goal is to make NTP ubiquitous by providing a free simple implementation that is secure and easy to configure.

  • Be as secure as possible. Code carefully, do strict validity checks especially in the network input path, and use bounded buffer operations. Use privilege separation to mitigate the effects of possible security bugs.
  • Provide a lean implementation, sufficient for a majority. Don't try to support each and every obscure usage case, but cover the typical ones.
  • Try to "Just Work" in the background.
  • Work with just a minimum of configuration.
  • Reach a reasonable accuracy. We are not after the last microseconds.
    
por 03.08.2009 / 11:08