DDOS usando o servidor ntp

Question

Eu ouvi falar sobre o novo tipo de DDOS, onde O ntp é usado para reflexão .

Minhas perguntas são bem simples:

1. Você pode, por favor, dar detalhes sobre como eles funcionam e esclarecem? Como o ntp é executado sobre o UDP, suponho que deve haver algum tipo de pacote forjado em algum lugar?

2. Como é possível verificar exaustivamente se algum servidor ntp é vulnerável (e não pode estar envolvido em nenhum ataque)?

3. Se alguma vez nos tornarmos alvo de tal ataque, existe alguma maneira de mitigar?

Como esse tipo de ataque tem sido amplamente usado em 2014, aqui estão mais alguns detalhes:

• Você pode encontrar mais informações sobre este contato .
• "Ontem à noite, 30/01/2014, a partir das 22:15 CET, a rede Witbe em Paris foi gravemente afetada por um ataque DDOS (Distributed Denial of Service) usando amplificação NTP."
• Ouch, 350Gpbs, que prejudica link
• Comportamento genérico sobre os ddos pode ser encontrado aqui: Estou sob DDoS . O que posso fazer?
• O Bbc fala sobre ataques ntp: link
• Só mais uma pergunta: Se eu gravar corretamente, o openntpd escuta por padrão em 127.0.0.1 e o ntpd escuta em 0.0.0.0 - não tenho certeza se todos os servidores ntp envolvidos em ddos de reflexão precisavam publicar o horário publicamente. Acho que alguns administradores não qualificados instalaram o ntp para sincronizar a hora localmente e deixaram os arquivos de configuração padrão.

Uma maneira simples de prevenir e mitigar esse tipo de problema seria ouvir 127.0.0.1 por padrão? Eu acho que isso é verdade para qualquer serviço (bind9, mysql, ...)?

    

Answer 1

Esses ataques existem há muito tempo, eles voltaram a ser populares nos últimos dois meses. Eles funcionam como qualquer ataque de amplificação regular: um host falsifica uma consulta para que o endereço IP de origem pareça ser o host de destino. O servidor NTP envia sua resposta para o endereço falsificado. Como a resposta para tipos de consulta específicos pode ser muito grande e geralmente é UDP, isso pode rapidamente se tornar um problema para o host de destino: ele está sendo sobrecarregado com pacotes NTP.

Infelizmente, isso não é uma vulnerabilidade em servidores NTP, é apenas um recurso que está sendo abusado. Uma coisa a considerar é se você precisa executar servidores NTP que podem ser consultados em toda a Internet. Se isso não for necessário, crie uma lista de acesso ou uma política de firewall para bloquear consultas provenientes de fontes não confiáveis. Então, o que você pode fazer para verificar se seus servidores NTP estão vulneráveis é fazer consultas NTP de fontes não confiáveis e verificar se você obtém uma resposta. Mas infelizmente há um grande número de servidores NTP que são públicos por intenção (por exemplo, todos os servidores em pool.ntp.org ). Se você precisar executar um servidor NTP público, poderá considerar a implementação da taxa de consulta para reduzir o impacto no host de destino em caso de abuso.

Outra parte mais genérica da solução é que as redes precisam implementar o BCP38 , que solicita a filtragem tráfego deixando suas redes, portanto, o envio de pacotes falsificados é impossível. Infelizmente, ainda há um grande número de redes que não implementam esse tipo de filtragem, portanto, todos os ataques com pacotes de origem falsificados (usando qualquer protocolo como NTP, DNS ou chargen) ainda são possíveis.

O que você pode fazer para mitigar esse ataque depende um pouco da sua rede e ferramentas disponíveis, mas uma coisa que você deve considerar é o bloqueio de pacotes NTP recebidos de fontes não confiáveis (verifique quais servidores NTP você está usando). Claro, isso não ajuda se o seu uplink estiver congestionado. Nesse caso, você precisará perguntar ao seu provedor para ajudá-lo a filtrar o tráfego.

    

Answer 2

Minhas respostas:

1. Os ataques usam comandos monlist (que serão mostrados como ntpv2 reservados no tcpdump). Esses comandos não são limitados pela taxa normal de limitação de taxa. Monlist (e outros comandos de monitoramento) só funcionará a partir de IPs com permissão para 'consultar' o seu servidor, portanto adicione 'noquery' aos seus padrões.
2. Experimente um nipdc -nc monlist yourip de um IP externo para ver se o servidor responde.
3. Ratelimite o tráfego ntp recebido. Não no próprio ntpd, mas antes que ele atinja o daemon. Como configurar isso no Linux é discutido em "minha configuração limitadora de taxa" na lista de discussão do pool ntp

Answer 3

1. Can you please give details on how they work and clarify? Since ntp is ran over UDP, I suppose there must be some kind of forged packet somewhere?

O US-CERT tem uma ótima descrição deste ataque em " Alerta (TA14-017A) Ataques de Amplificação baseados em UDP "e" Alerta (TA14-013A) Ataques de Amplificação NTP Usando CVE- 2013-5211 ".

TA14-013A diz melhor:

Description

UDP, by design, is a connection-less protocol that does not validate source IP addresses. Unless the application-layer protocol uses countermeasures such as session initiation, it is very easy to forge the IP packet datagram to include an arbitrary source IP address [7]. When many UDP packets have their source IP address forged to a single address, the server responds to that victim, creating a reflected Denial of Service (DoS) Attack.

Recently, certain UDP protocols have been found to have particular responses to certain commands that are much larger than the initial request. Where before, attackers were limited linearly by the number of packets directly sent to the target to conduct a DoS attack, now a single packet can generate tens or hundreds of times the bandwidth in its response. This is called an amplification attack, and when combined with a reflective DoS attack on a large scale it makes it relatively easy to conduct DDoS attacks.

O gráfico incluído em relação ao "fator de amplificação de largura de banda (BAF)" mostra que o NTP exibe o pior comportamento. Como o NTP é um protocolo extremamente comum, e muitos sistemas operacionais Linux vêm com um servidor NTP ativo, esse problema é particularmente ruim.