Como você lida com pares de NTP não confiáveis?

Question

Eu executei o lynis 1.5.6 e recebi a seguinte mensagem de log.

Performing test ID TIME-3120 (Check unreliable NTP peers)
Test: Checking unreliable ntp peers
Result: Found one or more unreliable peers (marked with a minus or dash sign)
Unreliable peer: 50.7.96.4
Suggestion: Check ntpq peers output for unreliable ntp peers and correct/replace them [TIME-3120]

eu corri

sudo ntpq -i e dá os comandos explicados aqui . No entanto, não diz como corrigir ou substituir um par.

Eu fiz as alterações sugeridas aqui , mas ainda recebo a sugestão de lynis. Eu olhei em / var / log / ntpstats e não havia nada lá. Eu dei o par não confiável como 50.7.0.147 que é Comunicações Abovenet de acordo com isc.sans.edu.

Esta sugestão de lynis pode ser ignorada?

    

Answer 1

Você pode ignorar esse aviso. Para ser honesto, não é uma descrição precisa dos códigos de status dos pares. Um menos não significa que o servidor não é confiável. Isso significa que o par foi descartado pelo algoritmo de cluster. Este é um produto normal do algoritmo de seleção de relógio.

A outra resposta sugere o uso de servidores do projeto do pool. O projeto do pool monitora os servidores e remove aqueles que estão com problemas. No entanto, não eliminará servidores com um código de status de peer negativo para você. Além disso, como cliente, você não tem controle sobre quais servidores o projeto do pool atribui aleatoriamente a você. Dada uma lista decente de pares, é muito provável que um servidor seja rejeitado pelo algoritmo de clustering. Isso pode ser por vários motivos, como picos de latência ou mudanças de temperatura. Aqui está o meu quadro de avisos ntpqq da máquina que acabei de inicializar. Eu tenho meu servidor ntp local (stratum 1 GPS), outro servidor de estrato 1 que está perto de mim e quatro servidores que o projeto do pool selecionou aleatoriamente para mim aleatoriamente.

 dfc@jumbo:~$ ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
 *ronin.llamahaus .GPS.            1 u   58   64    7    0.187   -0.168   0.789
 +clock1.alb1.ino .CDMA.           1 u   59   64    7   37.231    6.703   3.304
 +pool-test.ntp.o 204.123.2.5      2 u   60   64    7   77.727    1.775   1.139
 -defiance.terran 209.118.204.201  3 u   59   64    7   50.638   10.097   1.630
 -ponderosa.piney 209.51.161.238   2 u   57   64    7   37.756    9.511   2.780
 +greenwix.netlob 216.218.254.202  2 u   56   64    7   87.031   -2.368   1.846

Existem dois servidores com um sinal de menos na frente deles, são servidores de pool. ntp não selecionou aqueles para sincronizar o tempo com. O servidor com a estrela é o par com o qual estou sincronizado e os servidores com os sinais de mais eram os outros candidatos.

TLDR: Ignore o aviso de lynis. Confira a documentação do ntp.org se você quiser ler mais sobre os códigos de status do peer

    

Answer 2

Quantos colegas você está usando? Se você usa três (ou mais) servidores, então o NTP tem a inteligência para saber se um está fora de sincronia com os outros e ele irá parar de usá-lo até se tornar "sadio" novamente.

Eu sugeriria escolher servidores aqui:

link

Provavelmente, não há nada que você possa fazer sobre um servidor se comportar mal se você não controlá-lo. Basta escolher um servidor diferente.