Como o NTP funciona
A lei de Segal declara
Um homem com um relógio sabe que horas são . Um homem com dois relógios nunca tem certeza.
O cientista da computação David L. Mills criou o NTP no início dos anos 80 para sincronizar os relógios do computador com uma referência de tempo padrão. Desde o início do NTP, um grupo de voluntários com o projeto do pool NTP manteve um grande “cluster virtual de servidores de tempo disponível publicamente, fornecendo serviço NTP confiável e fácil de usar para milhões de clientes” em todo o mundo para muitas distribuições Linux e dispositivos de rede.
Conforme detalhado no NTP .org, NTP funciona de forma hierárquica passando o tempo de um estrato para outro. Por exemplo, Stratum 0 serve como um relógio de referência e é o servidor de tempo mais preciso e de maior precisão (por exemplo, relógios atômicos, relógios GPS e relógios de rádio .) Os servidores Stratum 1 tomam seu tempo de servidores Stratum 0 e assim por diante até Stratum 15; Stratum 16 cl ocks não são sincronizados com nenhuma fonte. O tempo em um cliente é estabelecido por meio de uma troca de pacotes com um ou mais servidores stratum. Esses pacotes colocam carimbos de data / hora em cada mensagem e o tempo gasto para transmitir as mensagens são fatores no algoritmo para estabelecer o consenso de tempo que deve estar no cliente.
O NTP pode fornecer uma fonte de tempo precisa por meio de consenso com vários servidores de entrada. Ele também pode identificar quais servidores de horário disponíveis são imprecisos. Um desafio é que o NTP foi construído durante uma época em que a comunidade da Internet era mais amigável. Durante o início do NTP, os servidores NTP não estavam preocupados com a verificação do usuário. No início dos anos 1980, era comum que servidores NTP estivessem disponíveis publicamente como um recurso que os desenvolvedores poderiam usar para solucionar problemas e confirmar sua própria solução NTP.
O protocolo padrão para NTP é o User Datagram Protocol (UDP). Essa decisão de design criou oportunidades de abuso. O UDP, que não tem conexão, é um protocolo de melhor esforço e, portanto, mais suscetível a falsificação e perda de pacotes do que o protocolo de controle de transmissão (TCP). Embora os voluntários do projeto NTP pool tenham continuado a desenvolver o NTP, a motivação de muitos administradores de rede e proprietários de negócios para corrigir seus próprios equipamentos não é tão forte. Desde o seu início, o protocolo de rede NTP foi integrado a inúmeros sistemas, muitos dos quais não foram corrigidos e podem estar executando códigos com 20 revisões ou mais.
Ataques relacionados a vulnerabilidades NTP
Cory Doctorow escreveu recentemente sobre as consequências potenciais de NTP desatualizado para Boing / Boing:
NTP é como praticamente todos os computadores com os quais você interage mantém seu relógio preciso, que é uma função tão fundamental para o funcionamento da Internet que não pode ser exagerado … Além do mais, as vulnerabilidades no NTP transformaram os muitos servidores de tempo da Internet em multiplicadores de força para ataques de negação de serviço, tornando ataques meramente punitivos em ataques quase impossíveis de parar .
O método que está sendo empregado para ataques DDoS recentes não depende de vulnerabilidades, mas de uma configuração ruim. Os serviços NTP estão respondendo a uma solicitação de consulta para uma lista de servidores monitorados. Uma única solicitação pequena com uma origem falsificada pode gerar uma lista de 600 servidores e ser enviada a um destino. Mesmo que não haja vulnerabilidade, quando centenas ou milhares desses servidores estão sendo redirecionados para um alvo inconsciente, as vítimas não se importam com a semântica do problema que está causando dor; eles só querem alívio.
A sincronização de tempo nos sistemas, ou a falta dela, pode ser um fator contribuinte significativo para vulnerabilidades que podem comprometer as funções básicas de um sistema. Além do abuso de NTP que contribui para ataques DDoS, falta de sincronização de tempo em uma rede cria uma oportunidade para ataques de repetição (ou seja, ataques de reprodução) envolvendo o falso ou malévolo atraso repetido de uma transmissão de dados autêntica.
Por exemplo, um ataque de repetição pode ocorrer quando um usuário tenta para fornecer prova de identidade a outro usuário. Um agente mal-intencionado intermediário interceptaria a mensagem e evitaria que ela chegasse ao destino pretendido. O usuário mal-intencionado envia uma solicitação de confirmação de identidade e inclui a prova roubada como uma validação. Se o tempo não for sincronizado, a janela em que a troca é permitida pode ser aumentada além do que é considerado seguro e permite o subterfúgio. Como resultado, os usuários válidos podem ser enganados e pensar que tiveram sucesso apenas confirmou a identidade de um impostor se passando por usuário legítimo. Com toda a justiça, esse tipo de ataque de repetição é incomum e extremamente desafiador de ser executado com sucesso sem acesso à rede, ao caminho de comunicação e a uma máquina comprometida nesse caminho.
Muitos especialistas em segurança, como Shaun Kelly , notaram que o NTP tem sido usado para manipular logs e alterar a hora em um sistema de computador, alterando a sequência de eventos.Quando os relógios não estão sincronizados, os analistas de rede têm muito mais dificuldade em executar a correlação de log entre sistemas diferentes. A manipulação do NTP pode tornar a identificação das atividades de rede e a sequência de eventos que levam a um ataque muito mais difícil de localizar.
Outros aplicativos que podem estar em risco porque o tempo não está funcionando direito incluem negociação de alta velocidade e câmeras de segurança. Muitos algoritmos de criptografia sensíveis ao tempo que envolvem trocas de chaves e tokens também estão em risco devido aos pontos fracos do NTP.
Práticas recomendadas de NTP
O restante deste post detalha as práticas recomendadas para configurar seu próprio servidor NTP e solicitar um servidor NTP público.
Use NTP público para hosts externos. Se for uma empresa está criando recursos, serviços ou outras plataformas incorporadas que devem ser implantadas fora da empresa, os administradores de rede podem querer considerar a solicitação de um servidor NTP público do pool de servidores disponíveis mencionado anteriormente.
É importante observar que a maioria dos servidores NTP públicos especifica regras de engajamento. Se uma empresa tiver vários dispositivos dentro da empresa que usarão NTP, faria sentido configurar sua própria hierarquia para sincronizar em vez de competir pelo acesso aos servidores disponíveis publicamente.
Configure seus próprios servidores internos. Serviço hierárquico NTP para sua rede. É possível comprar dispositivos NTP Stratum 1 ou Stratum 0 para usar internamente por menos do que o custo de um servidor típico. Também é possível configurar um servidor NTP privado a um custo muito baixo. A viabilidade de configurar um servidor NTP comercial pronto para uso (COTS) é evidenciada em um esforço recente para configurar um computador Raspberry Pi como um servidor Stratum-1. Se você decidir configurar você mesmo, considere as seguintes práticas recomendadas:
- Padronizar para o horário UTC. Dentro de uma empresa, padronize todos os sistemas para o horário universal coordenado (UTC). A padronização para UTC simplifica a correlação de log dentro da organização e com partes externas, independentemente do fuso horário em que o dispositivo que está sendo sincronizado está localizado.
- Protegendo o serviço de horário da rede. Restrinja os comandos que podem ser usados nos servidores stratum. Não permita consultas públicas dos servidores stratum. Permitir apenas que redes / hosts conhecidos se comuniquem com seus respectivos servidores stratum.
- Considere a necessidade comercial de criptografia. Muitos administradores tentam proteger suas redes com comunicações criptografadas e autenticação criptografada. Gostaria de introduzir uma nota de cautela aqui porque, embora existam serviços criptográficos associados ao NTP para proteger as comunicações NTP, o uso de criptografia apresenta mais fontes de problemas, como a necessidade de gerenciamento de chaves, e também requer uma sobrecarga computacional maior.
- Lembre-se da Lei de Segal. Idealmente, funcionaria ter três ou mais servidores Stratum 0 ou Stratum 1 e usar esses servidores como mestres primários. Lembre-se da Lei de Segal: ter dois NTP servidores torna difícil saber qual é o exato. Dois servidores Stratum 0 forneceriam um carimbo de data / hora mais preciso porque estão usando uma fonte de tempo considerada definitiva.
A presença de três ou mais fontes de tempo permitiria à rede manter tempo preciso, mesmo se um dos principais principais falhar. Idealmente, os servidores NTP estariam localizados em três locais geograficamente distintos. Esse grupo de mestres primários seria a fonte de tempo para a empresa. Eles seriam considerados mestres ocultos porque forneceriam serviços apenas aos servidores do estrato secundário. Essa configuração permitiria que esses servidores fornecessem tempo para os mestres secundários colocados que estão realmente fornecendo serviços a uma organização. Os mestres primários permanecem ocultos e são acessados apenas pela infraestrutura NTP que fornece serviços em outro lugar. Essa cadeia de suprimentos deve permitir que você forneça o tempo preciso em toda a sua organização e ter várias fontes corroborando uma fonte de tempo precisa.
Locais que têm mais dispositivos que precisam ter seu tempo sincronizado podem adicionar servidores Stratum 2 ou Stratum 3 adicionais e fazer com que eles dependam dos mestres secundários, bem como uns dos outros, para distribuir ainda mais a carga em um sistema e fornecer serviços para um grupo maior de clientes NTP.
Configurando um serviço NTP interno na última revisão de código estável e padronizando seu uso, a viabilidade de ataques de rede baseados em tempo ou processos que dependem do tempo são mais difíceis de cooptar. A identificação da ordem dos eventos em um compromisso torna-se mais fácil porque os tempos nos logs agora podem ser sistemas de registro. Para a aplicação da lei e outras agências investigativas, serviços NTP precisos podem ser muito construtivos na avaliação de evidências e sequenciamento de uma cadeia de eventos.
Resumindo e olhando para o futuro
À medida que os ataques se tornam mais sofisticados, nossa equipe de analistas de rede no CERT encontra cada vez mais serviços voltados para a Internet que não estão bem implantados em uma rede. Como Mark Langston escreveu em sua recente postagem sobre DNS Best Practices, muitos desses serviços constituem a base para a segurança e operação de aplicativos de rede interna e externa.
Este é o último de uma série de postagens de blog que oferecem as melhores práticas nessas estruturas fundamentais para ajudar agências governamentais e outras empresas a lidar com fontes ocultas de vulnerabilidades em suas redes. Nossa líder de equipe, Rachel Kartch, publicou a primeira postagem desta série, Ataques distribuídos de negação de serviço: quatro melhores práticas para prevenção e resposta.