Como ter certeza de que o tempo em si não mente se você tem um milhão de dispositivos grandes e pequenos se comunicando via TCP/IP? Afinal, cada um deles tem um relógio, e a hora deve estar correta para todos eles. Este problema não pode ser contornado sem o NTP.
Vamos imaginar por um minuto que num segmento da infraestrutura de TI industrial haja dificuldades com a sincronização de serviços ao longo do tempo. Imediatamente a pilha de cluster de software empresarial começa a falhar, os domínios se desintegram, os nós mestres e de espera se esforçam, sem sucesso, para restaurar o status quo.
Também é possível que um invasor tente deliberadamente interromper o horário por meio de um ataque MiTM ou DDOS. Nessa situação, tudo pode acontecer:
- As senhas das contas de usuário expirarão;
- Os certificados X.509 expirarão;
- A autenticação de dois fatores TOTP irá parar de funcionar;
- os backups ficarão desatualizados e o sistema os excluirá;
- O DNSSec irá quebrar.
É claro que todo departamento de TI está interessado na operação confiável dos serviços de sincronização de horário, e seria bom se eles fossem confiáveis e seguros na operação industrial.
Quebre o NTP em 25 minutos
Protocolos de rede - a geração millennials tem uma peculiaridade: eles têm sido e já não servem para nada, mas substituí-los não é tão fácil, mesmo quando se acumula uma massa crítica de entusiastas e de financiamento.
A principal reclamação sobre o NTP clássico é a falta de mecanismos confiáveis de proteção contra ataques de intrusos. Várias tentativas foram feitas para resolver este problema. Para conseguir isso, primeiro implementamos um mecanismo de chave pré-compartilhada (PSK) para troca de chaves simétricas.
Infelizmente, esse método não valeu a pena por um motivo simples: ele não é bem dimensionado. A configuração manual é necessária no lado do cliente, dependendo do servidor. Isso significa que você simplesmente não pode adicionar outro cliente assim. Se algo mudar no servidor NTP, todos os clientes deverão ser reconfigurados.
Então eles criaram o AutoKey, mas imediatamente descobriram uma série de vulnerabilidades sérias no design do próprio algoritmo e tiveram que abandoná-lo. Acontece que a semente contém apenas 32 bits, é muito pequena e não contém complexidade computacional suficiente para um ataque frontal.
- ID da chave - chave simétrica de 32 bits;
- MAC (código de autenticação de mensagem) - soma de verificação do pacote NTP;
A chave automática é calculada da seguinte forma.
Autokey=H(Sender-IP||Receiver-IP||KeyID||Cookie)Onde H() é uma função hash criptográfica.
A mesma função é usada para calcular a soma de verificação dos pacotes.
MAC=H(Autokey||NTP packet)Acontece que toda a integridade das verificações de pacotes depende da autenticidade dos cookies. Depois de obtê-los, você pode restaurar a chave automática e falsificar o MAC. No entanto, o servidor NTP usa uma semente ao gerá-los. É aqui que reside o problema.
Cookie=MSB_32(H(Client IP||Server IP||0||Server Seed))A função MSB_32 corta os 5 bits mais significativos do resultado do cálculo de hash md32. O cookie do cliente não muda enquanto os parâmetros do servidor permanecerem inalterados. Então, o invasor só poderá restaurar o número inicial e gerar cookies de forma independente.
Primeiro, você precisa se conectar ao servidor NTP como cliente e receber cookies. Depois disso, usando um método de força bruta, o invasor restaura o número inicial seguindo um algoritmo simples.
Algoritmo para atacar o cálculo do número inicial pelo método de força bruta.
for i=0:2^32 − 1 do
Ci=H(Server-IP||Client-IP||0||i)
if Ci=Cookie then
return i
end if
end forOs endereços IP são conhecidos, então resta criar 2 ^ 32 hashes até que o cookie criado corresponda ao recebido do servidor NTP. Em uma estação doméstica normal com Intel Core i5, isso levará 25 minutos.
NTS - novo Autokey
Era impossível suportar tais falhas de segurança no Autokey, e em 2012 apareceu protocolo. Para comprometer o nome, eles decidiram mudar a marca, então o Autokey v.2 foi apelidado de Network Time Security.
O protocolo NTS é uma extensão da segurança NTP e atualmente suporta apenas o modo unicast. Ele fornece forte proteção criptográfica contra manipulação de pacotes, evita espionagem, é bem dimensionado, é resiliente à perda de pacotes de rede e resulta na menor quantidade de perda de precisão incorrida durante a segurança da conexão.
Uma conexão NTS consiste em dois estágios que utilizam protocolos de camada inferior. Sobre o primeiro Nesta fase, o cliente e o servidor concordam com vários parâmetros de conexão e trocam cookies contendo chaves com todo o conjunto de dados que os acompanha. Sobre segundo Neste estágio, a sessão NTS protegida real ocorre entre o cliente e o servidor NTP.
O NTS consiste em dois protocolos de camada inferior: Network Time Security Key Exchange (NTS-KE), que inicia uma conexão segura por TLS, e NTPv4, a encarnação mais recente do protocolo NTP. Um pouco mais sobre isso abaixo.
Primeira etapa - NTS KE
Nesta fase, o cliente NTP inicia uma sessão TLS 1.2/1.3 através de uma conexão TCP separada com o servidor NTS KE. Durante esta sessão acontece o seguinte.
- As partes determinam os parâmetros algoritmo para a segunda etapa.
- As partes definem um segundo protocolo de camada inferior, mas no momento apenas o NTPv4 é suportado.
- As partes determinam o endereço IP e a porta do servidor NTP.
- O servidor NTS KE emite cookies em NTPv4.
- As partes extraem um par de chaves simétricas (C2S e S2C) do material do cookie.
Essa abordagem tem a grande vantagem de que toda a carga de transmissão de informações secretas sobre os parâmetros de conexão recai sobre o protocolo TLS comprovado e confiável. Isso elimina a necessidade de reinventar sua própria roda para um handshake NTP seguro.
Segunda etapa - NTP sob proteção NTS
Na segunda etapa, o cliente sincroniza a hora com segurança com o servidor NTP. Para tanto, transmite quatro extensões especiais (campos de extensão) na estrutura de pacotes NTPv4.
- A extensão de identificador exclusivo contém um nonce aleatório para evitar ataques de repetição.
- A extensão de cookie NTS contém um dos cookies NTP disponíveis para o cliente. Como apenas o cliente possui as chaves AAED C2S e S2C simétricas, o servidor NTP deve extraí-las do material do cookie.
- A extensão NTS Cookie Placeholder é uma forma de um cliente solicitar cookies adicionais do servidor. Esta extensão é necessária para garantir que a resposta do servidor NTP não seja muito mais longa que a solicitação. Isso ajuda a prevenir ataques de amplificação.
- Autenticador NTS e campos de extensão criptografados A extensão contém a cifra AAED com a chave C2S, cabeçalho NTP, carimbos de data e hora e o EF acima como dados de acompanhamento. Sem esta extensão é possível falsificar carimbos de data/hora.
Ao receber uma solicitação de um cliente, o servidor verifica a autenticidade do pacote NTP. Para fazer isso, ele deve descriptografar os cookies, extrair o algoritmo e as chaves AAED. Depois de verificar com êxito a validade do pacote NTP, o servidor responde ao cliente no seguinte formato.
- A Extensão de Identificador Único é uma cópia espelhada da solicitação do cliente, uma medida contra ataques de repetição.
- Extensão de Cookies NTS mais cookies para continuar a sessão.
- Autenticador NTS e campos de extensão criptografados A extensão contém a cifra AEAD com uma chave S2C.
O segundo handshake pode ser repetido várias vezes, ignorando a primeira etapa, pois cada solicitação e resposta fornece cookies adicionais ao cliente. Isso tem a vantagem de que as operações TLS de computação e transmissão de dados PKI, relativamente intensivas em recursos, são divididas pelo número de solicitações repetidas. Isso é especialmente conveniente para cronometristas FPGA especializados, quando todas as funcionalidades principais podem ser empacotadas em diversas funções do campo da criptografia simétrica, transferindo toda a pilha TLS para outro dispositivo.
NTPSec
O que há de especial no NTP? Apesar de o autor do projeto, Dave Mills, ter tentado documentar seu código da melhor maneira possível, é raro um programador ser capaz de compreender os meandros dos algoritmos de sincronização de tempo que têm 35 anos. Parte do código foi escrito antes da era POSIX, e a API Unix era muito diferente da usada hoje. Além disso, é necessário conhecimento de estatísticas para limpar o sinal de interferências em linhas ruidosas.
O NTS não foi a primeira tentativa de consertar o NTP. Depois que os invasores aprenderam a explorar as vulnerabilidades do NTP para amplificar os ataques DDoS, ficou claro que eram necessárias mudanças radicais. E enquanto os rascunhos do NTS estavam sendo preparados e finalizados, a Fundação Nacional de Ciência dos EUA, no final de 2014, atribuiu urgentemente uma subvenção para a modernização do NTP.
O grupo de trabalho não era liderado por qualquer pessoa, mas - um dos fundadores e pilares da comunidade Open Source e autor do livro . A primeira coisa que Eric e seus amigos tentaram fazer foi mover o código NTP da plataforma BitKeeper para o git, mas não funcionou dessa forma. O líder do projeto, Harlan Stenn, foi contra esta decisão e as negociações foram paralisadas. Então foi decidido bifurcar o código do projeto e nasceu o NTPSec.
Experiência sólida, incluindo trabalho em GPSD, formação matemática e habilidade mágica de leitura de códigos antigos - Eric Raymond foi exatamente o hacker que conseguiu realizar tal projeto. A equipe encontrou um especialista em migração de código e em apenas 10 semanas o NTP no GitLab. O trabalho estava a todo vapor.
A equipe de Eric Raymond assumiu a tarefa da mesma forma que Auguste Rodin fez com um bloco de pedra. Ao remover 175 KLOC de código antigo, eles conseguiram reduzir significativamente a superfície de ataque, fechando muitas falhas de segurança.
Aqui está uma lista incompleta daqueles incluídos na distribuição:
- Refclock indocumentado, desatualizado, desatualizado ou quebrado.
- Biblioteca ICS não utilizada.
- libopts/autógeno.
- Código antigo para Windows.
- ntpdc.
- Chave automática.
- O código ntpq C foi reescrito em Python.
- O código C sntp/ntpdig foi reescrito em Python.
Além de limpar o código, o projeto tinha outras tarefas. Aqui está uma lista parcial de conquistas:
- A proteção do código contra buffer overflow foi significativamente melhorada. Para evitar estouros de buffer, todas as funções de string inseguras (strcpy/strcat/strtok/sprintf/vsprintf/gets) foram substituídas por versões seguras que implementam limites de tamanho de buffer.
- Adicionado suporte NTS.
- Precisão de intervalo de tempo aprimorada dez vezes ao vincular hardware físico. Isso se deve ao fato de que os relógios dos computadores modernos se tornaram muito mais precisos do que aqueles quando o NTP nasceu. Os maiores beneficiários disso foram o GPSDO e os rádios com horário dedicado.
- O número de linguagens de programação foi reduzido para duas. Em vez de scripts Perl, awk e até mesmo S, agora é tudo Python. Devido a isso, há mais oportunidades para reutilização de código.
- Em vez de macarrão de scripts de autotools, o projeto começou a usar um sistema de construção de software .
- Documentação do projeto atualizada e reorganizada. A partir de uma coleção de documentos contraditórios e às vezes arcaicos, criaram uma documentação bastante transitável. Cada opção de linha de comando e cada entidade de configuração agora possuem uma única versão da verdade. Além disso, as páginas de manual e a documentação da web agora são criadas a partir dos mesmos arquivos principais.
O NTPSec está disponível para diversas distribuições Linux. No momento, a última versão estável é 1.1.8, para Gentoo Linux é a penúltima.
(1:696)$ sudo emerge -av ntpsec
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] net-misc/ntpsec-1.1.7-r1::gentoo USE="samba seccomp -debug -doc -early -gdb -heat -libbsd -nist -ntpviz -rclock_arbiter -rclock_generic -rclock_gpsd -rclock_hpgps -rclock_jjy -rclock_local -rclock_modem -rclock_neoclock -rclock_nmea -rclock_oncore -rclock_pps -rclock_shm -rclock_spectracom -rclock_trimble -rclock_truetime -rclock_zyfer -smear -tests" PYTHON_TARGETS="python3_6" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
Cronia
Houve outra tentativa de substituir o antigo NTP por uma alternativa mais segura. O Chrony, ao contrário do NTPSec, foi escrito desde o início e projetado para operar de maneira confiável sob uma ampla variedade de condições, incluindo conexões de rede instáveis, disponibilidade ou congestionamento parcial da rede e mudanças de temperatura. Além disso, o chrony tem outras vantagens:
- o chrony pode sincronizar o relógio do sistema mais rapidamente e com maior precisão;
- chrony é menor, consome menos memória e acessa a CPU somente quando necessário. Esta é uma grande vantagem para poupar recursos e energia;
- chrony oferece suporte a carimbos de data e hora de hardware no Linux, permitindo uma sincronização extremamente precisa em redes locais.
No entanto, o chrony carece de alguns dos recursos do antigo NTP, como transmissão e cliente/servidor multicast. Além disso, o NTP clássico oferece suporte a um maior número de sistemas operacionais e plataformas.
Para desabilitar a funcionalidade do servidor e das solicitações NTP para o processo chronyd, basta escrever a porta 0 no arquivo chrony.conf. Isto é feito nos casos em que não há necessidade de manter o tempo para clientes ou pares NTP. Desde a versão 2.0, a porta do servidor NTP é aberta somente quando o acesso é permitido por uma diretiva de permissão ou comando apropriado, ou um par NTP é configurado, ou uma diretiva de transmissão é usada.
O programa consiste em dois módulos.
- chronyd é um serviço executado em segundo plano. Ele recebe informações sobre a diferença entre o relógio do sistema e o servidor de horário externo e ajusta a hora local. Ele também implementa o protocolo NTP e pode atuar como cliente ou servidor.
- chronyc é um utilitário de linha de comando para monitoramento e controle de programas. Usado para ajustar vários parâmetros de serviço, por exemplo, permitindo adicionar ou remover servidores NTP enquanto o chronyd continua em execução.
Desde a versão 7 do RedHat Linux chrony como um serviço de sincronização de horário. O pacote também está disponível para outras distribuições Linux. A versão estável mais recente é a 3.5, preparando-se para o lançamento da v4.0.
(1:712)$ sudo emerge -av chrony
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary N ] net-misc/chrony-3.5-r2::gentoo USE="adns caps cmdmon ipv6 ntp phc readline refclock rtc seccomp (-html) -libedit -pps (-selinux)" 246 KiB
Total: 1 package (1 new, 1 binary), Size of downloads: 246 KiB
Would you like to merge these packages? [Yes/No]
Como configurar seu próprio servidor chrony remoto na Internet para sincronizar o horário em uma rede de escritório. Abaixo está um exemplo de configuração de um VPS.
Exemplo de configuração do Chrony no RHEL/CentOS no VPS
Vamos agora praticar um pouco e configurar nosso próprio servidor NTP em um VPS. É muito simples, basta escolher o tarifário adequado no site do RuVDS, obter um servidor pronto e digitar uma dezena de comandos simples. Para nossos propósitos, esta opção é bastante adequada.
Vamos prosseguir com a configuração do serviço e primeiro instalar o pacote chrony.
[root@server ~]$ yum install chronyRHEL 8/CentOS 8 usa um gerenciador de pacotes diferente.
[root@server ~]$ dnf install chronyApós instalar o chrony, você precisa iniciar e ativar o serviço.
[root@server ~]$ systemctl enable chrony --nowSe desejar, você pode fazer alterações em /etc/chrony.conf, substituindo os servidores NPT pelos locais mais próximos para reduzir o tempo de resposta.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.ru.pool.ntp.org iburst
server 1.ru.pool.ntp.org iburst
server 2.ru.pool.ntp.org iburst
server 3.ru.pool.ntp.org iburst
A seguir, configuramos a sincronização do servidor NTP com os nós do pool especificado.
[root@server ~]$ timedatectl set-ntp true
[root@server ~]$ systemctl restart chronyd.service
Também é necessário abrir a porta NTP para o exterior, caso contrário o firewall bloqueará as conexões de entrada dos nós clientes.
[root@server ~]$ firewall-cmd --add-service=ntp --permanent
[root@server ~]$ firewall-cmd --reload
Do lado do cliente, basta definir o fuso horário corretamente.
[root@client ~]$ timedatectl set-timezone Europe/MoscowO arquivo /etc/chrony.conf especifica o IP ou nome do host do nosso servidor VPS executando o servidor NTP chrony.
server my.vps.serverE por fim, iniciando a sincronização de horário no cliente.
[root@client ~]$ systemctl enable --now chronyd
[root@client ~]$ timedatectl set-ntp true
Da próxima vez, direi quais opções existem para sincronizar o horário sem a Internet.
Fonte: habr.com
