26/11/2020 NTP.

br

([Link]

(/)

IMPRENSA (HTTPS://[Link]/IMPRENSA/)
([Link]       

Home (/) / O NTP (/[Link])

O NTP
NTP significa Network Time Protocol ou Protocolo de Tempo para Redes. É o protocolo que permite a
sincronização dos relógios dos dispositivos de uma rede como servidores, estações de trabalho, roteadores e
outros equipamentos à partir de referências de tempo confiáveis.
OBS: ao longo desta página utiliza-se o comando ntpq da distribuição do NTP para exemplificar o acesso às
variaveis do sistema ligadas a cada conceito. Para mais detalhes sobre essa ferramenta, deve-se acessar a seção
>Configurações Avançadas. ([Link])

Arquitetura do NTP
O Funcionamento do NTP
Troca de Mensagens e Cálculo do Deslocamento
O Algorítmo de Filtro de Relógio
O Algorítimo de Seleção dos Relógios
O Algorítmo de Agrupamento
O Algorítmo de Combinação de Relógios
Disciplina do Relógio Local
Segurança

Arquitetura do NTP
Os servidores NTP formam uma topologia hierárquica, dividida em camadas ou estratos (em inglês: strata)
numerados de 0 (zero) a 16 (dezesseis). O estrato 0 (stratum 0) na verdade não faz parte da rede de servidores
NTP, mas representa a referência primária de tempo, que é geralmente um receptor do Sistema de Posicionamento
Global (GPS) ou um relógio atômico. O estrato 16 indica que um determinado servidor está inoperante.

Figura 1: Topologia em camadas (estratos)

O estrato 0, ou relógio de referência, fornece o tempo correto para o estrato 1, que por sua vez fornece o tempo
para o estrato 2 e assim por diante. O NTP é então, simultaneamente, servidor (fornece o tempo) e cliente
(consulta o tempo). A topologia está ilustrada na Figura 1.

De forma geral, quanto mais perto da raiz, ou seja, do estrato 0, maior a exatidão do tempo. O estrato ao qual o
servidor pertence é a principal métrica utilizada pelo NTP para escolher dentre vários, qual o melhor servidor para
fornecer o tempo.

Por outro lado, normalmente as diferenças de exatidão entre os estratos não são expressivas e há, no momento de
escolher-se um conjunto de servidores de tempo para configurar um determinado cliente, outros fatores a se
considerar, como por exemplo a carga à qual os servidores estão submetidos, e o atraso de rede.

O estrato de um servidor não é uma característica estática. Se houver perda de conexão com as fontes de tempo,
ou outros fatores que modifiquem a topologia da rede, o estrato pode variar.

Ao consultar-se a lista de servidores no daemon NTP, o estrato (st) é informado:

[Link] 1/11
26/11/2020 [Link]

usuario@[Link]:~$ ntpq -c pe
remote refid st t when poll reach delay offset jitter
======================================================================
-servidor1 .IRIG. 1 u 8 32 377 0.407 0.248 0.016
-servidor2 .GPS. 1 u - 32 377 0.474 0.213 0.019
+servidor3 .GPS. 1 u 9 64 377 15.680 -0.005 0.026
+servidor4 .IRIG. 1 u 30 64 377 15.582 0.004 0.100
*servidor5 .GPS. 1 u 10 32 377 0.400 -0.026 0.049
xservidor6 .IRIG. 1 u 26 64 377 7.824 9.923 0.367

As relações entre os diferentes dispositivos NTP são normalmente chamadas de Associações. Elas podem ser:

Permanentes: são criadas por uma configuração ou comando e mantidas sempre.

Priorizáveis (preemptables): são específicas da versão 4 do NTP e criadas por uma configuração ou
comando, podem ser desfeitas no caso de haver um servidor melhor, ou depois de um certo tempo.

Efêmeras ou transitórias: são criadas por solicitação de outro dispositivo NTP e podem ser desfeitas em
caso de erro ou depois de um certo tempo.

São possíveis as seguintes Associações:

Cliente - Servidor: (client - server) É uma assiciação permanente e a forma mais comum de configuração.
Um dispositivo faz o papel de cliente, solicitando informações sobre o tempo a um servidor. O cliente tem
conhecimento das associações com os servidores e do estado da troca de pacotes. Outro dispositivo faz o
papel de servidor, respondendo à solicitação do cliente com informações sobre o tempo. O servidor não
armazena informações sobre o diálogo com o cliente ou sobre sua associação com o mesmo.

No processo, então, o cliente envia um pacote ao servidor a aguarda a resposta, que vem em seguida. Isso pode
ser descrito também como uma operação do tipo pull, dizendo que o cliente busca os dados necessários sobre o
tempo no servidor.
Para configurar o cliente dessa forma é usado o parâmetro server no arquivo de configuração, seguido do nome ou
endereço do servidor. É recomendável também usar adicionalmente o parâmetro iburst no comando, que serve
para acelerar a sincronização inicial.
Um cliente pode criar associações com vários servidores simultaneamente (na verdade é recomendável que seja
assim), e um servidor pode fornecer tempo a diversos clientes simultaneamente.
Um dispositivo (host) NTP normalmente é cliente e servidor ao mesmo tempo.

Modo simétrico: (symmetric mode) Dois ou mais dispositivos NTP podem ser configurados como pares
(peers), de forma que possam tanto buscar o tempo, quanto fornecê-lo, garantindo redundância mútua. Essa
configuração faz sentido para dispositivos no mesmo estrato, configurados também como clientes de um ou
mais servidores. Caso um dos pares perca a referência de seus servidores, os demais pares podem
funcionar como referência de tempo. O modo simétrico pode ser:

Ativo: O dispositivo A configura o dispositivo B como seu par (criando dessa forma uma associação
permanente). Por sua vez, o dispositivo B também configura o dispositivo A como seu par (também
cria uma associação permanente).

Passivo: O dispositivo A configura o dispositivo B como seu par (modo simétrico ativo). Mas o
dispositivo B não tem o dispositivo A na sua lista de servidores ou pares. Ainda assim, ao receber um
pacote de A, o dispositivo B cria uma associação transitória, de forma a poder fornecer ou receber o
tempo de A.

Esse modo é particularmente susceptível a ataques, onde um dispositivo intruso pode estar configurado no modo
simétrico ativo e fornecer informações de tempo falsas para outro. Por isso deve sempre ser usado com
criptografia.

Para configurar um dispositivo no modo simétrico utiliza-se o parâmetro peer , seguido do nome ou IP do par. Com
o modo simétrico não deve-se utilizar os parâmetros burst ou iburst .

Para evitar a falha de segurança descrita no modo simétrico passivo, deve-se sempre manter a autenticação
habilitada. Isso é o padrão do sistema. Para desabilitar a autenticação inclui-se o parâmetro disable auth no
arquivo de configuração: isso não deve ser feito, a menos que se entenda muito bem as conseqüências e haja uma
razão muito forte.

Broadcast ou Multicast: O NTP pode fazer uso de pacotes do tipo broadcast ou multicast para enviar ou
receber informações de tempo. Esse tipo de configuração pode ser vantajosa no caso de redes locais com
poucos servidores alimentando uma grande quantidade de clientes.

O cliente NTP no modo broadcast ou multicast (à partir da versão 4), ao receber o primeiro pacote de um servidor,
busca os dados por um curto período de tempo, como se estivesse no modo cliente - servidor, a fim de conhecer o
atraso envolvido. Ou seja, durante alguns instantes há troca de pacotes entre cliente e servidor, depois disso o
cliente passa apenas a receber os pacotes broadcast ou multicast do servidor.
Para configurar um servidor utiliza-se o parâmetro broadcast, seguido do endereço IP de broadcast da interface de
rede, ou de um endereço multicast. O IANA reservou os endereços multicast [Link] (IPv4) e ff05::101 (IPv6 -
site local) para o NTP, mas outros endereços podem ser utilizados. O parâmetro minpoll controla o tempo entre
pacotes e o parâmetro ttl o número de saltos máximo de cada um deles.
Para configurar o cliente utiliza-se o parâmetro broadcastclient. Na versão 3 do NTP era necessário também
utilizar o parâmetro broadcastdelay para definir o atraso de rede envolvido.
Como no caso do modo simétrico passivo, há aqui uma questão de segurança, porque um intruso pode facilmente
enviar pacotes NTP falsos em modo broadcast. Então a autenticação deve sempre estar habilitada. Isso é o
padrão do sistema. Para desabilitar a autenticação inclui-se o parâmetro disable auth no arquivo de configuração:
isso não deve ser feito, a menos que se entenda muito bem as conseqüências e haja uma razão muito forte.

Ao consultar-se a lista de servidores no NTP, o tipo de conexão (t) é informada. Pode ser local, unicast, multicast ou
broadcast, no exemplo abaixo todas as conexões são unicast:
[Link] 2/11
26/11/2020 [Link]

usuario@[Link]:~$ ntpq -c pe
remote refid st t when poll reach delay offset jitter
======================================================================
-servidor1 .IRIG. 1 u 8 32 377 0.407 0.248 0.016
-servidor2 .GPS. 1 u - 32 377 0.474 0.213 0.019
+servidor3 .GPS. 1 u 9 64 377 15.680 -0.005 0.026
+servidor4 .IRIG. 1 u 30 64 377 15.582 0.004 0.100
*servidor5 .GPS. 1 u 10 32 377 0.400 -0.026 0.049
xservidor6 .IRIG. 1 u 26 64 377 7.824 9.923 0.367

Voltar

O Funcionamento do NTP
Como já visto, NTP é um protocolo de rede que permite a sincronização dos relógios dos dispositivos à partir de
referências de tempo confiáveis. Num primeiro momento isso pode parecer algo tão simples quanto "consultar o
tempo em um servidor" e "ajustar o relógio local" de tempos em tempos. Na verdade, algumas implementações do
SNTP, a versão simplificada do protocolo, fazem isso e apenas isso. Mas o NTP em sua forma completa é muito
mais complexo.

Diversos componentes do sistema colaboram para:

Obter, à partir de diversas amostras, informações de tempo de um determinado servidor, como o

deslocamento, dispersão e variação.

Discernir, dentre um conjunto de servidores, quais fornecem o tempo correto e quais estão mentindo.

Escolher, dentre os servidores que fornecem o tempo correto, qual é a melhor referência.

Disciplinar o relógio local, descobrindo seus principais parâmetros de funcionamento, como precisão,
estabilidade e escorregamento e ajustando-o de forma contínua e gradual, mesmo na ausência temporária
de referências de tempo confiáveis, para que tenha e melhor exatidão possível.

Garantir a monotonicidade do tempo.

Identificar, à partir de métodos criptográficos, servidores de tempo conhecidos e confiáveis, evitando

possíveis ataques.

Formar, em conjunto com outros servidores NTP, uma topologia simples, confiável, robusta e escalável para
a sincronização de tempo.

Figura 2: O funcionamento do NTP (1)

A Figura 2 mostra os principais componentes do NTP, que são apresentados e explicados de uma forma bastante
simplificada no texto a seguir. Para informações mais precisas sobre como são calculadas as várias métricas do
sistema e sobre como devem funcionar os diversos algorítmos, recomenda-se a consulta direta às RFCs e à
documentação oficial.

Voltar

Troca de Mensagens e Cálculo do Deslocamento

As mensagens do NTP são baseadas no protocolo UDP, que é um protocolo não confiável e não orientado à
conexão.

A troca de mensagens entre cliente e servidor permite que o cliente descubra qual seu deslocamento (offset) em
relação ao servidor, ou seja, o quanto seu relógio local difere do relógio do servidor.

Consideremos servidor e cliente com relógios não sincronizados. A troca de mensagens, ilustrada na Figura 3, dá-
se da seguinte forma:

1. O Cliente lê seu relógio, que fornece o tempo a.

2. O Cliente envia a Mensagem 1 com a informação de tempo a para o servidor.
3. O Servidor recebe a Mensagem 1 e nesse instante lê seu relógio, que fornece o instante x. O Servidor
mantém a e x em variáveis.
4. O Servidor após algum tempo lê novamente seu relógio, que fornece o instante y.
5. O Servidor envia a Mensagem 2 com a, x e y para o cliente.
6. O Cliente recebe a Mensagem 2 e nesse instante lê seu relógio, que fornece o instante b.

[Link] 3/11
26/11/2020 [Link]

Figura 3: Troca de mensagens (1)

Ao receber a Mensagem 2, o Cliente passa a conhecer os instantes a, x, y e b. Mas a e b estão numa escala de
tempo, enquanto x e y em outra. O valor do incremento dessas escalas é o mesmo, mas os relógios não estão
sincronizados.

Não é possível, então, calcular o tempo que a Mensagem 1 levou para ser transmitida (T-ida), nem o tempo que a
Mensagem 2 gastou na rede (T-volta). Contudo, o tempo total de ida e volta, ou atraso (também conhecido por
Round Trip Time ou RTT) que é a soma T-ida + T-volta pode ser calculado como:

atraso (delay) = (b-a)-(y-x).

Considerando-se que o tempo de ida é igual ao tempo de volta, pode-se calcular o deslocamento entre o servidor e
o relógio local como como:

deslocamento (offset) = x - (a + atraso/2) =

deslocamento (offset) = (x-a+y-b)/2.

Para facilitar a compreensão, considere-se o seguinte exemplo numérico.

1. O Cliente lê o relógio: a=9.

2. O Cliente envia a Mensagem 1 (a=9).
3. O Servidor recebe a Mensagem 1 (a=9) e lê seu relógio: x=4.
4. O Servidor algum tempo depois lê seu relógio novamente: y=9.
5. O Servidor envia a Mensagem 2 (a=9, x=4, y=9).
6. O Cliente recebe a Mensagem 2 (a=9, x=4, y=9) e lê seu relógio: b=18.

Figura 4: Troca de mensagens - exemplo (1)

Ao olhar a Figura 4, é fácil observar que T-ida=2 e T-volta=2. Contudo, nem o Cliente nem o Servidor têm essa
visão. O Servidor ao final da troca de mensagens descarta todas as informações sobre a mesma. O Cliente
conhece as variáveis a=9, x=4, y=9 e b=18, mas à partir delas é impossível calcular T-ida ou T-volta. Contudo, é
possível calcular o atraso e o deslocamento:

atraso = (b-a)-(y-x) = (18-9)-(9-4) = 9 - 5 = 4.

deslocamento = (x-a+y-b)/2 = (4-9+9-18)/2 = -14/2 = -7.

Um deslocamento de -7 significa que o relógio local do Cliente deve ser atrasado 7 unidades de tempo para se
igualar ao do Servidor.

Note-se que foi assumido alguns parágrafos acima, para se conseguir calcular o deslocamento, que T-ida = T-
volta. Mas isso nem sempre é verdade! Há atrasos estocásticos nas redes devido às filas dos roteadores e
switchs. Numa WAN ou na Internet enlaces de diferentes velocidades e roteamento assimétrico, além de outros
fatores, também causam diferenças entre T-ida e T-volta.

No entanto o NTP funciona exatamente dessa forma, considerando que T-ida = T-volta.

Isso implica num erro. Esse erro, representado na Figura 5, é no pior caso igual à metade do atraso. Ou seja:

deslocamento - atraso/2 <= deslocamento verdadeiro <= deslocamento + atraso/2

Figura 5: Erro do deslocamento por causa da assimetria

Tome-se o seguinte exemplo numérico, ilustrando o pior caso. Os servidores são os mesmos da Figura 4, mas a
primeira mensagem leva um tempo desprezível pra ser enviada, enquanto a segunda demora 4 unidades de
tempo: a=9; x=2; y=7; b=18. Nesse caso T-ida=0 e T-volta=4. O exemplo está ilustrado na Figura 6.

[Link] 4/11
26/11/2020 [Link]

Figura 6: Troca de mensagens - assimetria (1)

Calcula-se o atraso como:

atraso = (b-a)-(y-x) = (18-9)-(7-2) = 9 - 5 = 4.

deslocamento = (x-a+y-b)/2 = (2-9+7-18)/2 = -18/2 = -9.

O deslocamento está errado! Sabe-se que o valor correto é -7, contudo o valor calculado é -9. Isso deve-se a
assimetria da rede, no tocante a T-ida e T-volta.
No entanto, à partir do cálculo do deslocamento e do atraso, e levando em conta a limitação do método, que
considera T-ida=T-volta, sabe-se que o deslocamente verdadeiro está entre:

deslocamento - 2 <= deslocamento verdadeiro <= deslocamento + 2

-9 -2 <= deslocamento verdadeiro <= -9 + 2

-11 <= deslocamento verdadeiro <= -7

Ou seja, dado um deslocamento de -9 e um atraso de 4, sabe-se que o valor verdadeiro do deslocamento é algo
entre -11 e -7, mas não há como ter certeza de qual o valor. Como nesse exemplo o valor correto é conhecido de
antemão, -7, pode-se verificar que o cálculo funciona adequadamente.
Voltar

O Algorítmo de Filtro de Relógio

Através da troca de mensagens, o NTP consegue as informações de atraso e deslocamento de um servidor. Essa
troca de mensagens não é realizada uma única vez. Ela se repete periodicamente, com o período dinamicamente
controlado pelo NTP.

No início da sincronização o cliente NTP faz uma consulta a cada servidor a cada 64s. Esse período varia ao longo
do tempo, geralmente aumenta, até chegar a 1024s (aproximadamente 17min). As variáveis minpoll e maxpoll
definem o mínimo e o máximo, e são representadas em potência de 2. Ou seja, por padrão minpoll = 6 (26=64) e
maxpoll = 10 (210=1024). Numa consulta à lista de servidores NTP, a variável poll representa o período e a
variável when é um contador que indica quantos segundos se passaram desde a última consulta; quando poll =
when uma nova consulta é realizada e a variável when é zerada. Se o parâmetro iburst é utilizado na
configuração de um servidor, a taxa de envio de pacotes é acelerada no início da sincronização, de forma a se
conseguir um conjunto de dados mais depressa. A variável reach representa um registrador de deslocamento de 8
bits, cujo valor é mostrado no formato octal. Um bit 1 significa que o cliente obteve resposta do servidor para uma
consulta. Então o valor 377 = 11.111.111, significa que as últimas 8 consultas ao servidor foram bem sucedidas.

usuario@servidor:~$ ntpq -c pe
remote refid st t when poll reach delay offset jitter
======================================================================
*servidor1 .IRIG. 1 u 93 128 377 0.523 0.020 0.033
+servidor2 .GPS. 1 u 57 128 377 0.488 -0.054 0.025
-servidor3 .IRIG. 1 u 50 128 377 5.151 -0.386 0.382
+servidor4 .IRIG. 1 u 34 64 377 5.163 -0.360 0.559

[Link] 5/11
26/11/2020 [Link]

Figura 7
É importante notar então, que não há apenas um valor de atraso e um de deslocamento para cada servidor, mas
um conjunto deles, provenientes das diversas trocas de mensagem! A partir dessa lista de valores, o Algorítmo de
Filtro de Relógio calcula então um valor de atraso (delay), de deslocamento (offset) e de variação (jitter).

Na verdade, cada amostra é composta de 4 valores: atraso, deslocamento, dispersão e estampa de tempo. A
estampa de tempo indica quando a amostra chegou. A dispersão é o erro estimado do relógio de servidor remoto,
informada pelo servidor na mensagem NTP.

A lista com os valores é ordenada em função do atraso. Considera-se que as amostras com menor atraso são
melhores porque provavelmente não se sujeitaram a filas nos switches e roteadores, de forma que parte das
variações estocásticas de tempo no envio e recebimento das mensagens é evitada com essa escolha.

Os valores mais antigos são descartados, porque o valor de deslocamento pode não mais corresponder à
realidade, já que a exatidão do relógio local varia ao longo do tempo.

Após descartar as amostras antigas, resta uma lista com as amostras mais recentes e ordenadas em função do
atraso. Da primeira entrada dessa lista são retiradas as variáveis atraso e deslocamento para o par cliente servidor
(note-se que para cada par cliente - servidor há uma variável de cada tipo).

A dispersão e a variação são calculadas levando em conta todos os valores da lista.

A Figura 7 ilustra o funcionamento desse algorítmo.

Os valores para cada servidor associado podem ser consultados no NTP como segue:

usuario@[Link]:~$ ntpq
ntpq> pe
remote refid st t when poll reach delay offset jitter
======================================================================
-servidor1 .IRIG. 1 u 8 32 377 0.407 0.248 0.016
-servidor2 .GPS. 1 u - 32 377 0.474 0.213 0.019
+servidor3 .GPS. 1 u 9 64 377 15.680 -0.005 0.026
+servidor4 .IRIG. 1 u 30 64 377 15.582 0.004 0.100
*servidor5 .GPS. 1 u 10 32 377 0.400 -0.026 0.049
xservidor6 .IRIG. 1 u 26 64 377 7.824 9.923 0.367
servidor7 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
-servidor8 .ACTS. 1 u 13 64 377 202.274 2.459 0.309
LOCAL(0) LOCAL(0) 13 l 48 64 377 0.000 0.000 0.001

Detalhando os valores para o primeiro (&1) servidor da lista:

[Link] 6/11
26/11/2020 [Link]

ntpq> rv &1
associd=60217 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=[Link], srcport=123, dstadr=2001:12ff:0:10:61d7:d8b9:f49:c5ee,
dstport=123, leap=00, stratum=2, precision=-21, rootdelay=0.137,
rootdisp=2.853, refid=[Link],
reftime=d93301e7.8d27341e Mon, Jun 22 2015 18:51:35.551,
rec=d9330264.776924cb Mon, Jun 22 2015 18:53:40.466, reach=007,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=40,
flash=400 peer_dist, keyid=0, offset=2.155, delay=1.752,
dispersion=1937.986, jitter=3.222, xleave=0.128,
filtdelay= 1.75 3.03 1.56 0.00 0.00 0.00 0.00 0.00,
filtoffset= 2.15 1.99 -2.40 0.00 0.00 0.00 0.00 0.00,
filtdisp= 0.00 0.96 1.97 16000.0 16000.0 16000.0 16000.0 16000.0

Voltar

O Algorítimo de Seleção dos Relógios

Uma vez que o Algorítmo de Filtro de Relógios tenha calculado os principais parâmetros referentes a cada servidor,
faz-se importante descobrir quais deles são confiáveis e quais não. Os servidores que têm algum erro no tempo
fornecido são chamados de relógios falsos (falsetickers, na literatura em inglês, a tradução é aproximada). Os
servidores que fornecem a hora corretamente são chamados de relógios verdadeiros (truechimmers, em inglês,
uma tradução mais literal seria algo como "badaladores verdadeiros").

Para a seleção dos relógios, o NTP considera como verdadeiro o deslocamento que se encontra dentro de um
determinado intervalo de confiança, representado na Figura 8. Esse intervalo é calculado, para cada associação
com um servidor, como:

intervalo de confiança = (deslocamento/2) + dispersão.

Figura 8

A Seleção de relógios busca um intervalo de intersecção para os valores de deslocamento de cada servidor,
considerados os intervalos de confiança. Os servidores cujos deslocamentos ficam fora da intersecção são
relógios falsos. A Figura 9 ilustra isso para 4 servidores, A, B e C são relógios verdadeiros, e D é um relógio
falso:

Figura 9

Ao consultar-se a lista de servidores do NTP, os relógios falsos são identificados por um "x". No exemplo abaixo, o
servidor6 é um relógio falso (esses símbolos, como o "x", usados para diferenciar os servidores, são chamados
de tally-codes, para mais detalhes deve-se consultar a seção Configurações Avançadas ([Link]).):

[Link] 7/11
26/11/2020 [Link]

usuario@[Link]:~$ ntpq
ntpq> pe
remote refid st t when poll reach delay offset jitter
======================================================================
-servidor1 .IRIG. 1 u 8 32 377 0.407 0.248 0.016
-servidor2 .GPS. 1 u - 32 377 0.474 0.213 0.019
+servidor3 .GPS. 1 u 9 64 377 15.680 -0.005 0.026
+servidor4 .IRIG. 1 u 30 64 377 15.582 0.004 0.100
*servidor5 .GPS. 1 u 10 32 377 0.400 -0.026 0.049
xservidor6 .IRIG. 1 u 26 64 377 7.824 9.923 0.367
servidor7 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
-servidor8 .ACTS. 1 u 13 64 377 202.274 2.459 0.309
LOCAL(0) LOCAL(0) 13 l 48 64 377 0.000 0.000 0.001

Voltar

O Algorítmo de Agrupamento
O algorítmo de Agrupamento trabalha com os servidores que são relógios verdadeiros, utilizando técnicas
estatísticas, com o objetivo de selecionar os melhores dentre eles. Os critérios de seleção utilizados são:

estrato (stratum)
distância para a raiz
variação (jitter)

No processo alguns servidores são descartados, sendo chamados de relógios afastados (outlyers). Os que
permanecem são chamados de relógios sobreviventes (survivors), algumas vezes na literatura em inglês utiliza-se
candidatos (candidates) no mesmo sentido que sobreviventes, por conta do algorítmo utilizado onde, à princípio,
todos os relógios verdadeiros são candidatos, mas apenas alguns sobrevivem.

O melhor dos relógios sobreviventes é considerado como par do sistema (system peer).

Na consulta abaixo, o par do sistema é indicado pelo "*" (em verde); os relógios sobreviventes por "+" (em azul);
e os relógios afastados por "-" (em laranja) (esses símbolos, como o "*", "+" e "-", usados para diferenciar os
servidores, são chamados de tally-codes, para mais detalhes deve-se consultar a seção Configurações Avançadas
([Link]).):

usuario@[Link]:~$ ntpq
ntpq> pe
remote refid st t when poll reach delay offset jitter
======================================================================
-servidor1 .IRIG. 1 u 8 32 377 0.407 0.248 0.016
-servidor2 .GPS. 1 u - 32 377 0.474 0.213 0.019
+servidor3 .GPS. 1 u 9 64 377 15.680 -0.005 0.026
+servidor4 .IRIG. 1 u 30 64 377 15.582 0.004 0.100
*servidor5 .GPS. 1 u 10 32 377 0.400 -0.026 0.049
xservidor6 .IRIG. 1 u 26 64 377 7.824 9.923 0.367
servidor7 .INIT. 16 u - 1024 0 0.000 0.000 4000.00
-servidor8 .ACTS. 1 u 13 64 377 202.274 2.459 0.309
LOCAL(0) LOCAL(0) 13 l 48 64 377 0.000 0.000 0.001

Voltar

O Algorítmo de Combinação de Relógios

Se o algorítmo de Agrupamento encontrar apenas um sobrevivente, ele será o par do sistema e será utilizado
como referência para ajustar o relógio local. Se for usada a palavra chave prefer na configuração de um
servidor e este estiver dentre os sobreviventes, ele será considerado como par do sistema e, mesmo que existam
outros sobreviventes, estes serão ignorados. Nesses casos, o algorítmo de Combinação de Relógios não é
utilizado.

Para os demais casos, quando há mais do que um sobrevivente e nenhum deles foi configurado com a palavra
chave prefer , o algorítmo de Combinação de Relógios calcula uma média ponderada dos deslocamentos dos
relógios, com o objetivo de aumentar a exatidão.

No exemplo abaixo os 3 servidores destacados contribuem para o valor de deslocamento de -0,119ms, mostrado
nas variáveis do sistema.

[Link] 8/11
26/11/2020 [Link]

usuario@[Link]:~$ ntpq

ntpq> pe
remote refid st t when poll reach delay offset jitter
==========================================================================
+servidor1 .IRIG. 1 u 7 16 377 0.410 -0.087 0.022
*servidor2 .GPS. 1 u 7 16 377 0.380 -0.128 0.052
+servidor3 .IRIG. 1 u 5 16 377 14.750 -0.166 0.076
-servidor4 [Link] 2 u 15 16 377 0.449 -0.466 0.009
xservidor5 .IRIG. 1 u 17 64 377 7.772 9.447 0.186
xservidor6 .ACTS. 1 u 52 64 377 193.471 5.779 5.444
-servidor .GPS. 1 u 9 16 377 0.344 -0.486 0.071
-servidor [Link] 2 u 45 64 377 4.437 1.423 0.723

ntpq> rl
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Mon Apr 13 13:39:46 UTC 2015 (1)",
processor="x86_64", system="Linux/3.13.0-36-generic", leap=00, stratum=2,
precision=-23, rootdelay=1.486, rootdisp=12.398, refid=[Link],
reftime=d932ff64.9cf3d965 Mon, Jun 22 2015 18:40:52.613,
clock=d932ff83.82c43efa Mon, Jun 22 2015 18:41:23.510, peer=16741, tc=6,
mintc=3, offset=6.413, frequency=7.053, sys_jitter=0.211,
clk_jitter=4.680, clk_wander=0.844

No exemplo a seguir, apesar de haver 3 sobreviventes, foi usada a palavra chave prefer na configuração do
servidor5. Como ele é um dos sobreviventes, foi escolhido como par do sistema e é o único responsável pelos
parâmetros de sincronização. Nesse caso, o algorítmo de Combinação de Relógios não é utilizado:

usuario@[Link]:~$ ntpq

ntpq> pe

remote refid st t when poll reach delay offset jitter

======================================================================
-servidor1 .IRIG. 1 u 6 32 377 0.364 0.393 0.032
-servidor2 .GPS. 1 u 1 32 377 0.415 0.357 0.012
+servidor3 .GPS. 1 u 40 64 377 19.990 0.002 0.019
+servidor4 .IRIG. 1 u 11 64 377 14.804 0.318 0.172
*servidor5 .GPS. 1 u 5 32 377 0.366 -0.001 0.017
xservidor6 .IRIG. 1 u 19 64 377 7.779 9.969 0.235

ntpq> rl
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Mon Apr 13 13:39:46 UTC 2015 (1)",
processor="x86_64", system="Linux/3.13.0-36-generic", leap=00, stratum=2,
precision=-23, rootdelay=1.486, rootdisp=12.398, refid=[Link],
reftime=d932ff64.9cf3d965 Mon, Jun 22 2015 18:40:52.613,
clock=d932ff83.82c43efa Mon, Jun 22 2015 18:41:23.510, peer=16741, tc=6,
mintc=3, offset=6.413, frequency=7.053, sys_jitter=0.211,
clk_jitter=4.680, clk_wander=0.844

ntpq> rl
assID=0 status=0654 leap_none, sync_ntp, 5 events, event_peer/strat_chg,
version="ntpd 4.2.6p5@1.2349-o Mon Apr 13 13:03:33 UTC 2015 (1)",
processor="i686", system="Linux/2.6.17-12-generic", leap=00, stratum=2,
precision=-20, rootdelay=0.366, rootdispersion=12.913, peer=29992,
refid=servidor5,
reftime=cad07802.aea704bc Mon, Jun 22 2015 18:34:22.682, poll=5,
clock=cad0780b.f47980f5 Mon, Jun 22 2015 18:34:31.954, state=4,
offset=-0.001, frequency=-23.914, noise=0.015, jitter=0.017,
stability=0.037

Voltar

Disciplina do Relógio Local

O processo de disciplina do Relógio Local controla a fase e a freqüência do relógio do sistema. Ele é baseado na
combinação de duas filosofias de controle bastante diferentes entre si: Phase Locked Loop (PLL) e Frequency
Locked Loop (FLL) (traduções desses termos são incomuns, mas poderiam ser Laço Controlado por Fase e Laço
Controlado por Freqüência). Ambas as filosofias implementam controles onde há realimentação, ou seja, onde a
informação de saída é usada novamente na entrada, como simbolizado na Figura 2, no início desse texto.

O controle baseado em fase é melhor para as ocasiões onde há uma grande variação (jitter). Essa abordagem
procura minimizar o erro no tempo, controlando indiretamente a freqüência.

[Link] 9/11
26/11/2020 [Link]

O controle baseado em freqüência é melhor para quando há instabilidades na freqüência (variações mais lentas
que o jitter, conhecidas como wander). A abordagem controla diretamente a freqüência, e indiretamente o erro no
tempo.

O NTP disciplina o relógio local de forma contínua, mesmo em períodos onde não é possível consultar servidores
de tempo. As características do relógio local são medidas e se tornam conhecidas do NTP, o que torna possível
que ele funcione dessa forma. O arquivo indicado pela chave driftfile (geralmente /var/lib/ntp/[Link] )
na configuração armazena o erro esperado de freqüência para o relógio.

Algumas características importantes desse algorítmo:

Saltos no tempo são evitados sempre que possível. O tempo é ajustado para mais ou para menos
gradualmente, variando-se a freqüência do relógio local.

Se uma diferença maior do que 128ms for detectada o NTP considera que o tempo está muito errado, e que
é necessário um salto para frente ou para trás para corrigi-lo. Contudo isso só é feito se essa diferença maior
que 128ms persistir por um período maior que 900s (15min), para evitar que condições de congestionamento
grave mas temporário na rede, que podem levar a medições erradas de tempo, causem inadvertidamente
esse tipo de salto.

Se uma diferença maior que 1000s (~16,7min) for detectada o algorítmo aborta a execução, considerando
que algo muito errado aconteceu. Se houver diferenças dessa ordem ou maiores elas devem ser corrigidas
manualmente antes de se executar o daemon NTP.

Voltar

Segurança
Por segurança no contexto da Tecnologia da Informação entende-se basicamente garantir quatro propriedades da
informação:

integridade,
disponibilidade,
autenticidade e
confidencialidade.

Os algorítmos vistos anteriormente, aliados à correta configuração do sistema, com um número suficiente de fontes
de tempo com referências primárias independentes, garantem de forma satisfatória a integridade e
disponibilidade do serviço de tempo.
Os algorítimos de criptografia abordados neste item visam garantir a autenticidade da informação. Ou seja, têm o
objetivo de assegurar ao cliente de que o servidor é quem ele diz ser.

A confidencialidade não é considerada um problema no contexto do NTP. Ou seja, a informação de tempo sempre
trafega na rede de forma aberta, sem criptografia, mesmo quando uma assinatura cifrada é utilizada para garantir a
autenticidade da informação. As razões principais para o NTP funcionar dessa forma são que:

1. o tempo é uma informação pública, não há razão para esconder essa informação;
2. trabalhar com a informação de tempo cifrada demandaria tempo tanto do servidor quando do cliente e
degradaria o desempenho do sistema, fazendo-o menos exato.

Existem basicamente dois métodos no NTP para realizar a autenticação, chave simétrica (symmetric key) e chave
pública (autokey).

Autenticação por Chave Simétrica (Symmetric key)

A autenticação por chave simétrica é o esquema utilizado originalmente na versão 3 do NTP, mas mantido da
versão 4. Um conjunto de chaves deve ser gerado e compartilhado entre servidor e cliente. O NTP não fornece
meios para a transmissão ou armazenamento seguro das chaves; isso deve ser feito com outros recursos.

Chaves simétricas podem ser usadas para:

autenticar servidores ou pares no modo simétrico ativo;

autenticar pares no modo simétrico passivo ou servidores broadcast ou multicast;
autenticar requisições dos programas de monitoração e controle ntpq e ntpdc .

Quando o daemon NTP é iniciado, ele lê o arquivo de chaves especificado pelo comando keys no arquivo de
configuração e armazena-as num cache. Cada chave deve ser ativada com o comando trustedkey antes de ser
usada. Isso pode ser feito com o programa em funcionamento, utilizando o ntpdc . Os comandos requestkey e
controlkey selecionam as chaves utilizadas para autenticar os programas ntpdc e ntpq .

O arquivo de chaves pode conter várias chaves, uma em cada linha. Cada linha tem 3 colunas. A primeira é o
número da chave, entre 1 e 65535. A segunda é o tipo da chave; recomenda-se utilizar M para MD5, que é
representada por uma seqüência de até 31 caracteres ASCII (A versão 3 do NTP suportava também DES, mas
além de ser pior, há problemas legais nos Estados Unidos, que consideram programas utilizando DES como
munição, proibindo sua exportação). A terceira é a chave em si. Exemplo de arquivo com chaves:

1 M ABCDEFGHIJLMJNOPQRST
2 M ESSAEHUMACHAVEMD5VALIDA
3 M ESSAEHUMACHAVEMD5VALIDATB
15 M 1234ACDAS@#$LKAS)KJDKASH
498 M NTPv4.98

Exemplo de utilização das chaves simétricas na configuração do ntp:

[Link] 10/11
26/11/2020 [Link]

server servidor1.dominio1 key 498

server servidor2.dominio2 key 2
peer servidor3.dominio3 key 3

# caminho para o arquivo com as chaves

keys /etc/[Link]

# define quais chaves são confiáveis

trustedkey 2 15 498

requestkey 15 # chave para utilizar o ntpq

controlkey 15 # chave para utilizar o ntpqc

Autenticação por Chave Pública (Autokey)

Na versão 4 do NTP uma nova forma de autenticação é suportada, baseada em chaves públicas e num protocolo
que foi chamado de autokey. A integridade dos pacotes é verificada através de chaves MD5 e a autenticidade das
fontes de tempo é averiguada por meio de assinaturas digitais e vários esquemas de autenticação. Esquemas de
identificação (identity schemes) baseados em trocas do tipo desafio/resposta são usados para evitar vários tipos de
ataques aos quais o método de chaves simétricas é potencialmente vulnerável.

A autenticação é baseada em grupos de segurança (security groups). Pode-se entender um grupo de segurança
como um conjunto de servidores e clientes NTP que compartilha os mesmos métodos de autenticação, tendo em
sua raiz um ou mais servidores considerados confiáveis, e administrados por uma mesma entidade. Um grupo não
necessariamente precisa ter servidores estrato 1 em sua raiz, mas pode ser cliente de outros grupos de segurança.

O número de opções que há para configurar-se o autokey é assustador. Contudo a configuração necessária para a
maioria das situações é relativamente simples. Pode-se configurar um grupo de segurança com um ou mais
servidores confiáveis (TH - Trusted Hosts) no estrato mais baixo. Elege-se um desses servidores para ser o agente
confiável (TA - trusted agent) e gerar os certificados privados, um certificado público auto assinado, e chaves de
identificação privadas. Se houver mais de um servidor confiável, esses certificados e chaves são copiados para os
demais manualmente.

Os demais clientes e servidores geram chaves privadas e certificados auto assinados considerados não confiáveis.
Cada um deles fornece sua senha ao agente confiável e requisita as chaves e certificados do grupo (isso pode ser
feito por email ou por um formulário web, por exemplo). Para os servidores são fornecidas chaves cifradas. Para os
clientes somente um subconjunto de parâmetros de identificação não criptografados é fornecido.

O autokey se encarrega de resgatar os certificados ao longo da cadeia de servidores NTP até chegar a um servidor
confiável, garantindo que toda a cadeia de servidores é confiável.

Para garantir a integridade dos pacotes assinaturas baseadas no endereço IP são utilizadas. O endereço tem de
ser o mesmo, então, para o cliente e para o servidor, o que significa que a autenticação baseada em chave pública
não funciona em conjunto com NAT.

Mais detalhes de configuração do autokey podem ser obtidos na documentação oficial do NTP.

(1)
Figuras adaptadas de: TORRES JÚNIOR, PEDRO R. Caracterização da Rede de Sincronização na Internet.
Dissertação de Mestrado. 2007. Universidade Federal do Paraná. Curitiba.
Voltar

([Link]

([Link] ([Link] ([Link]

([Link]
([Link] ([Link]
([Link]

([Link] ([Link]
somos/)
O conteúdo publicado no site [Link] está licenciado com a Licença Creative Commons -
Atribuição-CompartilhaIgual 4.0 Internacional ([Link]
sa/4.0/deed.pt_BR) a menos que condições e/ou restrições adicionais específicas estejam
([Link]
sa/4.0/deed.pt_BR) claramente explícitas na página correspondente.
Núcleo de Informação e Coordenação do Ponto BR ([Link]) CNPJ 05.506.560/0001-36

[Link] 11/11