Protocolo de tempo de rede - Network Time Protocol

O Network Time Protocol ( NTP ) é um protocolo de rede para sincronização de relógio entre sistemas de computador em redes de dados de latência variável comutadas por pacotes . Em operação desde antes de 1985, o NTP é um dos protocolos de Internet mais antigos em uso atualmente. O NTP foi projetado por David L. Mills, da University of Delaware .

O NTP se destina a sincronizar todos os computadores participantes em alguns milissegundos do Tempo Universal Coordenado (UTC). Ele usa o algoritmo de interseção , uma versão modificada do algoritmo de Marzullo , para selecionar servidores de tempo precisos e é projetado para mitigar os efeitos da latência variável da rede . O NTP geralmente pode manter o tempo dentro de dezenas de milissegundos na Internet pública e pode atingir uma precisão melhor do que um milissegundo em redes locais sob condições ideais. Rotas assimétricas e congestionamento de rede podem causar erros de 100 ms ou mais.

O protocolo é geralmente descrito em termos de um modelo cliente-servidor , mas pode ser facilmente usado em relacionamentos ponto a ponto em que ambos os pontos consideram o outro como uma fonte de tempo potencial. As implementações enviam e recebem carimbos de data / hora usando o User Datagram Protocol (UDP) na porta número 123. Eles também podem usar broadcast ou multicast , onde os clientes ouvem passivamente as atualizações de tempo após uma troca inicial de calibração de ida e volta. O NTP fornece um aviso de qualquer ajuste de segundo intercalado iminente , mas nenhuma informação sobre fusos horários locais ou horário de verão é transmitida.

O protocolo atual é a versão 4 (NTPv4), que é um padrão proposto conforme documentado na RFC  5905 . É compatível com a versão 3, especificada na RFC  1305 .

Network Time Security (NTS), uma versão segura do NTP com TLS e AEAD é atualmente um padrão proposto e documentado no RFC  8915 .

História

O NTP foi projetado por David L. Mills .

Em 1979, a tecnologia de sincronização de tempo de rede foi usada no que foi possivelmente a primeira demonstração pública de serviços de Internet rodando em uma rede de satélites transatlântica, na National Computer Conference em Nova York. A tecnologia foi posteriormente descrita na Nota de Engenharia da Internet (IEN) 173 de 1981 e um protocolo público foi desenvolvido a partir dela, documentado na RFC  778 . A tecnologia foi implantada pela primeira vez em uma rede local como parte do protocolo de roteamento Hello e implementada no roteador Fuzzball , um sistema operacional experimental usado em prototipagem de rede, onde funcionou por muitos anos.

Outras ferramentas de rede relacionadas estavam disponíveis naquela época e agora. Eles incluem os protocolos Daytime e Time para registrar a hora dos eventos, bem como as mensagens de Timestamp ICMP e a opção IP Timestamp ( RFC  781 ). Os sistemas de sincronização mais completos, embora sem a análise de dados do NTP e os algoritmos de disciplinamento do relógio, incluem o daemon Unix cronometrado , que usa um algoritmo de eleição para indicar um servidor para todos os clientes; e o Digital Time Synchronization Service (DTSS), que usa uma hierarquia de servidores semelhante ao modelo NTP stratum.

Em 1985, o NTP versão 0 (NTPv0) foi implementado no Fuzzball e no Unix, e o cabeçalho do pacote NTP e o atraso de ida e volta e os cálculos de deslocamento, que persistiram no NTPv4, foram documentados no RFC  958 . Apesar dos computadores e redes relativamente lentos disponíveis na época, a precisão de mais de 100 milissegundos era geralmente obtida em links de extensão do Atlântico, com precisão de dezenas de milissegundos em redes Ethernet .

Em 1988, uma especificação muito mais completa do protocolo NTPv1, com algoritmos associados, foi publicada na RFC  1059 . Ele se baseou nos resultados experimentais e no algoritmo de filtro de relógio documentado no RFC  956 e foi a primeira versão a descrever os modos cliente-servidor e ponto a ponto . Em 1991, a arquitetura, o protocolo e os algoritmos do NTPv1 chamaram a atenção de uma comunidade de engenharia mais ampla com a publicação de um artigo de David L. Mills no IEEE Transactions on Communications .

Em 1989, foi publicada a RFC  1119 definindo o NTPv2 por meio de uma máquina de estados , com pseudocódigo para descrever seu funcionamento. Ele introduziu um protocolo de gerenciamento e um esquema de autenticação criptográfica que sobreviveram no NTPv4, junto com a maior parte do algoritmo. No entanto, o design do NTPv2 foi criticado por falta de correção formal pela comunidade DTSS, e o procedimento de seleção do relógio foi modificado para incorporar o algoritmo de Marzullo para NTPv3 em diante.

Em 1992, o RFC  1305 definiu o NTPv3. A RFC incluiu uma análise de todas as fontes de erro, desde o clock de referência até o cliente final, o que possibilitou o cálculo de uma métrica que ajuda a escolher o melhor servidor onde vários candidatos parecem discordar. O modo de transmissão foi introduzido.

Nos anos subsequentes, conforme novos recursos foram adicionados e melhorias no algoritmo foram feitas, tornou-se aparente que uma nova versão do protocolo era necessária. Em 2010, o RFC  5905 foi publicado contendo uma especificação proposta para NTPv4. O protocolo mudou significativamente desde então e, em 2014, um RFC atualizado ainda não foi publicado. Após a aposentadoria de Mills da University of Delaware , a implementação de referência é mantida atualmente como um projeto de código aberto liderado por Harlan Stenn.

Strata de relógio

O Relógio Mestre Alternativo do Observatório Naval dos EUA na Base Aérea de Schriever (Colorado) é uma fonte de estrato 0 para NTP
As setas amarelas indicam uma conexão direta; setas vermelhas indicam uma conexão de rede.

O NTP usa um sistema hierárquico e em camadas de fontes de tempo. Cada nível dessa hierarquia é denominado estrato e recebe um número começando com zero para o relógio de referência no topo. Um servidor sincronizado com um servidor stratum n é executado no stratum n + 1. O número representa a distância do relógio de referência e é usado para evitar dependências cíclicas na hierarquia. O estrato nem sempre é uma indicação de qualidade ou confiabilidade; é comum encontrar fontes de tempo do estrato 3 com melhor qualidade do que outras fontes de tempo do estrato 2. Uma breve descrição dos estratos 0, 1, 2 e 3 é fornecida abaixo.

Estrato 0
Estes são dispositivos de cronometragem de alta precisão, como relógios atômicos , GPS ou outros relógios de rádio . Eles geram um sinal de pulso por segundo muito preciso que dispara uma interrupção e um registro de data e hora em um computador conectado. Os dispositivos Stratum 0 também são conhecidos como relógios de referência. Os servidores NTP não podem se anunciar como estrato 0. Um campo estrato definido como 0 no pacote NTP indica um estrato não especificado.
Estrato 1
Esses são computadores cujo horário do sistema é sincronizado com alguns microssegundos de seus dispositivos stratum 0 anexados. Os servidores Stratum 1 podem fazer peering com outros servidores Stratum 1 para verificação de integridade e backup. Eles também são chamados de servidores de horário primários.
Estrato 2
Esses são computadores sincronizados em uma rede para servidores stratum 1. Freqüentemente, um computador do estrato 2 consulta vários servidores do estrato 1. Os computadores Stratum 2 também podem fazer peering com outros computadores stratum 2 para fornecer um tempo mais estável e robusto para todos os dispositivos no grupo de pares.
Estrato 3
Esses são computadores sincronizados com servidores stratum 2. Eles empregam os mesmos algoritmos para peering e amostragem de dados do estrato 2 e podem atuar como servidores para computadores do estrato 4 e assim por diante.

O limite superior do estrato é 15; stratum 16 é usado para indicar que um dispositivo não está sincronizado. Os algoritmos NTP em cada computador interagem para construir uma árvore de abrangência do caminho mais curto Bellman-Ford , para minimizar o atraso de ida e volta acumulado para os servidores do estrato 1 para todos os clientes.

Além do stratum, o protocolo é capaz de identificar a fonte de sincronização para cada servidor em termos de um identificador de referência (refid).

Códigos de identificadores de referência de tempo comuns (refid)
Refid Fonte do relógio
VAI Satélite de ambiente de órbita geosíncrona
GPS Sistema de Posicionamento Global
GAROTA Sistema de Posicionamento Galileo
PPS Pulso por segundo genérico
IRIG Grupo de Instrumentação Interfaixa
WWVB LF Radio WWVB Fort Collins, Colorado 60 kHz
DCF LF Radio DCF77 Mainflingen, DE 77,5 kHz
HBG LF Radio HBG Prangins, HB 75 kHz (operação interrompida)
MSF LF Radio MSF Anthorn, Reino Unido 60 kHz
JJY Rádio LF JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC Estação MF Radio Loran-C , 100
TDF Rádio MF Allouis, FR 162 kHz
CHU HF Radio CHU Ottawa, Ontário
WWV HF Radio WWV Fort Collins, Colorado
WWVH HF Radio WWVH Kauai, Hawaii
NIST Modem de telefone NIST
ATOS Modem de telefone NIST
USNO Modem de telefone USNO
PTB Modem telefônico padrão PTB alemão
SRA Fontes de referência múltipla
XFAC Associação Inter Face Alterada (endereço IP alterado ou perdido)
PASSO Mudança de tempo da etapa, o deslocamento é menor do que o limite de pânico (1000 s), mas maior do que o limite da etapa (125 ms)

Timestamps

Os carimbos de data / hora de 64 bits usados ​​pelo NTP consistem em uma parte de 32 bits para segundos e uma parte de 32 bits para segundos fracionários, dando uma escala de tempo que rola a cada 2 32 segundos (136 anos) e uma resolução teórica de 2 −32 segundos (233 picossegundos). O NTP usa uma época de 1º de janeiro de 1900. Portanto, o primeiro rollover ocorre em 7 de fevereiro de 2036.

O NTPv4 apresenta um formato de data de 128 bits: 64 bits para o segundo e 64 bits para o segundo fracionário. Os 32 bits mais significativos desse formato é o Era Number, que resolve a ambigüidade de rollover na maioria dos casos. De acordo com Mills, "O valor de 64 bits para a fração é suficiente para resolver a quantidade de tempo que um fóton leva para passar um elétron na velocidade da luz. O segundo valor de 64 bits é suficiente para fornecer uma representação de tempo inequívoca até que o universo escurece. "

Algoritmo de sincronização de relógio

Tempo de atraso de ida e volta δ

Um cliente NTP típico regularmente pesquisas de um ou mais servidores NTP. O cliente deve calcular seu deslocamento de tempo e atraso de ida e volta . O deslocamento de tempo θ, a diferença no tempo absoluto entre os dois relógios, é definido por

e o atraso de ida e volta δ por
Onde
  • t 0 é o carimbo de data / hora do cliente da transmissão do pacote de solicitação,
  • t 1 é o carimbo de data / hora do servidor de recepção do pacote de solicitação,
  • t 2 é o carimbo de data / hora do servidor da transmissão do pacote de resposta e
  • t 3 é o carimbo de data / hora do cliente da recepção do pacote de resposta.

Para derivar a expressão para o deslocamento, observe que, para o pacote de solicitação,

e para o pacote de resposta,
Resolver para θ resulta na definição do deslocamento de tempo.

Os valores de θ e δ são passados ​​por filtros e submetidos à análise estatística. Os valores discrepantes são descartados e uma estimativa do deslocamento de tempo é derivada dos três melhores candidatos restantes. A frequência do clock é então ajustada para reduzir o deslocamento gradualmente, criando um loop de feedback .

A sincronização precisa é obtida quando as rotas de entrada e saída entre o cliente e o servidor têm atraso nominal simétrico. Se as rotas não têm um atraso nominal comum, existe uma tendência sistemática de metade da diferença entre os tempos de viagem para frente e para trás.

Implementações de software

O utilitário de protocolo de gerenciamento NTP ntpq sendo usado para consultar o estado de um servidor stratum 2.

Implementação de referência

A implementação de referência do NTP , junto com o protocolo, tem sido continuamente desenvolvida por mais de 20 anos. A compatibilidade com versões anteriores foi mantida à medida que novos recursos foram adicionados. Ele contém vários algoritmos sensíveis, especialmente para disciplinar o relógio, que podem se comportar mal quando sincronizados com servidores que usam algoritmos diferentes. O software foi adaptado para quase todas as plataformas de computação, incluindo computadores pessoais. Ele é executado como um daemon chamado ntpd no Unix ou como um serviço no Windows. Relógios de referência são suportados e seus deslocamentos são filtrados e analisados ​​da mesma maneira que servidores remotos, embora eles geralmente sejam consultados com mais freqüência. Esta implementação foi auditada em 2017, encontrando vários problemas de segurança em potencial.

SNTP

O SNTP ( Simple Network Time Protocol ) é uma implementação menos complexa do NTP, usando o mesmo protocolo, mas sem exigir o armazenamento do estado por longos períodos de tempo. Ele é usado em alguns sistemas embarcados e em aplicações onde a capacidade total de NTP não é necessária.

Hora do Windows

Todas as versões do Microsoft Windows desde o Windows 2000 incluem o serviço Windows Time (W32Time), que tem a capacidade de sincronizar o relógio do computador com um servidor NTP.

O W32Time foi originalmente implementado para o propósito do protocolo de autenticação Kerberos versão 5, que exigia tempo dentro de 5 minutos do valor correto para evitar ataques de repetição . A versão no Windows 2000 e no Windows XP apenas implementa SNTP e viola vários aspectos do padrão NTP versão 3.

A partir do Windows Server 2003 e do Windows Vista , o W32Time tornou-se compatível com um subconjunto significativo do NTPv3. A Microsoft afirma que o W32Time não pode manter a sincronização de tempo com precisão de um segundo de forma confiável. Se desejar maior precisão, a Microsoft recomenda o uso de uma versão mais recente do Windows ou implementação de NTP diferente.

A partir do Windows 10 versão 1607 e do Windows Server 2016 , o W32Time pode ser configurado para atingir uma precisão de tempo de 1 s, 50 ms ou 1 ms sob certas condições operacionais especificadas.

OpenNTPD

Em 2004, Henning Brauer apresentou o OpenNTPD , uma implementação de NTP com foco em segurança e abrangendo um design separado por privilégios. Embora seja mais voltado para as necessidades genéricas mais simples dos usuários do OpenBSD , ele também inclui algumas melhorias de segurança de protocolo ao mesmo tempo em que é compatível com os servidores NTP existentes. Uma versão portátil está disponível nos repositórios de pacotes do Linux.

Ntimed

Um novo cliente NTP, ntimed , foi iniciado por Poul-Henning Kamp em 2014 e abandonado em 2015. A nova implementação foi patrocinada pela Linux Foundation como uma substituição para a implementação de referência, pois foi determinado que seria mais fácil escrever uma nova implementação do zero do que reduzir o tamanho da implementação de referência. Embora não tenha sido lançado oficialmente, o ntimed pode sincronizar relógios de maneira confiável.

NTPsec

O NTPsec é uma bifurcação da implementação de referência que tem sua segurança sistematicamente reforçada . O ponto de bifurcação foi em junho de 2015 e foi em resposta a uma série de compromissos em 2014. O primeiro lançamento de produção lançado em outubro de 2017. Entre a remoção de recursos inseguros, a remoção do suporte para hardware obsoleto e a remoção do suporte para variantes obsoletas do Unix, O NTPsec conseguiu eliminar 75% da base de código original, tornando o restante mais auditável. Uma auditoria de 2017 do código mostrou oito problemas de segurança, incluindo dois que não estavam presentes na implementação de referência original, mas o NTPsec não sofreu de oito outros problemas que permaneceram na implementação de referência.

chrony

chronyc, mostrando fontes e informações de atividades. Janela de terminal no Arch Linux

chrony vem por padrão nas distribuições do Red Hat e está disponível nos repositórios do Ubuntu . O chrony é destinado a computadores comuns, que são instáveis, entram no modo de hibernação ou têm conexão intermitente com a Internet. O chrony também foi projetado para máquinas virtuais, um ambiente muito mais instável. É caracterizado por baixo consumo de recursos (custo) e suporta hardware de protocolo de tempo de precisão para maior precisão de carimbo de data / hora. Possui dois componentes principais: chronyd, um daemon que é executado quando o computador é inicializado, e chronyc, uma interface de linha de comando para o usuário para sua configuração. Foi avaliado como muito seguro e com poucos incidentes, sua vantagem é a versatilidade de seu código, escrito do zero para evitar complexidade desnecessária. Suporte para Network Time Security (NTS) foi adicionado na versão 4.0. chrony está disponível sob a GNU General Public License versão 2 , foi criado por Richard Curnow em 1997 e atualmente é mantido por Miroslav Lichvar .

Segundos bissextos

No dia de um evento de segundo bissexto , o ntpd recebe notificação de um arquivo de configuração, um relógio de referência anexado ou um servidor remoto. Embora o relógio NTP seja realmente parado durante o evento, devido ao requisito de que o tempo deve parecer estritamente crescente , quaisquer processos que consultem a hora do sistema fazem com que ele aumente em uma pequena quantidade, preservando a ordem dos eventos. Se um segundo bissexto negativo se tornasse necessário, ele seria excluído com a sequência 23:59:58, 00:00:00, pulando 23:59:59.

Uma implementação alternativa, chamada de smearing de salto, consiste em introduzir o segundo bissexto de forma incremental durante um período de 24 horas, do meio-dia ao meio-dia no horário UTC. Esta implementação é usada pelo Google (tanto internamente quanto em seus servidores NTP públicos) e pelo Amazon AWS.

Preocupações com segurança

Apenas alguns outros problemas de segurança foram identificados na implementação de referência da base de código NTP, mas aqueles que apareceram em 2009 foram motivo de preocupação significativa. O protocolo vem passando por revisão e revisão ao longo de toda sua história. A base de código para a implementação de referência passou por auditorias de segurança de várias fontes por vários anos.

Uma exploração de estouro de buffer de pilha foi descoberta e corrigida em 2014. A Apple estava preocupada o suficiente com essa vulnerabilidade que usou seu recurso de atualização automática pela primeira vez. Alguns erros de implementação são básicos, como uma instrução de retorno ausente em uma rotina, que pode levar ao acesso ilimitado aos sistemas que estão executando algumas versões do NTP no daemon raiz. Os sistemas que não usam o daemon root, como o BSD, não estão sujeitos a essa falha.

Uma auditoria de segurança de 2017 de três implementações de NTP, conduzida em nome da Iniciativa de Infraestrutura Básica da Linux Foundation, sugeriu que tanto o NTP quanto o NTPsec eram mais problemáticos do que o Chrony do ponto de vista da segurança.

Os servidores NTP podem ser suscetíveis a ataques man-in-the-middle, a menos que os pacotes sejam assinados criptograficamente para autenticação. A sobrecarga computacional envolvida pode tornar isso impraticável em servidores ocupados, especialmente durante ataques de negação de serviço . A falsificação de mensagens NTP de um ataque man-in-the-middle pode ser usada para mover relógios em computadores clientes e permitir uma série de ataques com base no desvio da expiração da chave criptográfica. Alguns dos serviços afetados por mensagens NTP falsas identificadas são TLS , DNSSEC , vários esquemas de cache (como cache DNS), BGP, Bitcoin e vários esquemas de login persistentes.

O NTP tem sido usado em ataques distribuídos de negação de serviço . Uma pequena consulta é enviada a um servidor NTP com o endereço de retorno falsificado para ser o endereço de destino. Semelhante ao ataque de amplificação de DNS , o servidor responde com uma resposta muito maior que permite a um invasor aumentar substancialmente a quantidade de dados enviados ao alvo. Para evitar a participação em um ataque, o software do servidor NTP pode ser atualizado ou os servidores podem ser configurados para ignorar consultas externas.

Para melhorar a segurança do NTP, uma versão segura chamada Network Time Security (NTS) foi desenvolvida e atualmente é suportada por vários servidores de horário.

Veja também

Notas

Referências

Leitura adicional

links externos