DHCP Starvation, uma solução trivial?

Question

Eu sei que existem muitas soluções para atenuar ataques de privação de DHCP. Mas uma solução realmente simples não seria apenas definir o pool de endereços DHCP para 1.1.1.1 - 254.254.254.254 (ou algum outro pool realmente grande) para que a entidade maliciosa não pudesse passar fome ao pool inteiro dentro de um prazo prático? Por que isso não é feito?

Considere isso no contexto de uma rede sem fio, sem criptografia e sem autenticação (típico de hotspots sem fio públicos gratuitos).

    

Answer 1

Usar o espaço de endereço IP inteiro parece um pouco excessivo. Supondo que você esteja falando sobre um ambiente contido (digamos, por trás de um NAT), você pode usar o 10.0.0.0 \ 8 sem incorrer em problemas relacionados ao roteamento. Desde que a sua rede real (ou seja, o número de máquinas reais) seja pequena, o problema geral de ter um domínio de transmissão potencialmente enorme não é tão relevante e se você definir o tempo de concessão relativamente baixo (alguns minutos) você pode garantir que Não era prático para um único invasor esgotar seu alcance. No entanto, você ainda teria que rechaçar o que poderia ser uma quantidade relativamente grande de tráfego com milhões de solicitações falsas e será tráfego de transmissão lembre-se de que todos os dispositivos genuínos na sua rede também o verão - por isso, muito ruído espúrio para todos a rede tem que lidar com interrupções de. Seus switches começarão a rastrear todas essas combinações de endereços IP \ MAC [falsos] agora, então você está permitindo que o invasor aumente a quantidade de recursos que eles consomem, e esses também são finitos. Para um ataque sério, acho que o código de ataque de exaustão DHCP provavelmente envia solicitações mais rapidamente do que muitos servidores DHCP podem lidar se o escopo for realmente enorme - os recursos físicos (CPU e RAM necessários para manipular as respostas e acompanhar a tabela de concessões ativas) no servidor DHCP pode eventualmente ser consumido se o atacante puder gerar solicitações com rapidez suficiente e o resultado final puder ser pior para você - você agora trocou um ataque de Negação de Serviço por novas conexões com um ataque que pode travar seu servidor DHCP e Switches (e estes podem ser explorados).

Se esta é uma preocupação válida, e você não pode viver com a possibilidade de DoS contra clientes, você deve usar switches que possuam mecanismos para evitar isso - existem mecanismos específicos de mitigação de privação de DHCP, como DHCP Snooping, mas apenas permitindo que os controles limitem A falsificação de endereços MAC geralmente ajudará nisso e também na inundação de tabelas do CAM. A melhor abordagem é habilitar a autenticação de porta, mas isso é difícil de implementar em qualquer ambiente controlado de grande porte e não adianta em um cenário não gerenciado (como um WiFi Hotspot). Não acredito que exista uma solução definitiva para fins gerais, é um caso de equilibrar os riscos das várias opções disponíveis e selecionar aquela que funciona melhor em seu ambiente.

    

Answer 2

Existem muitos problemas com essa abordagem.

Em primeiro lugar, se você fizer o que expressou, estará efetivamente se desligando da Internet, pois esse intervalo inclui (quase) todos os endereços IPv4 possíveis.

Em segundo lugar, ao fazer isso, você está se preparando para ter que lidar com um domínio de transmissão enorme . As práticas recomendadas típicas de rede recomendam o uso de sub-redes pequenas (digamos, aquelas que possuem máscaras de rede com / 22 ou mais) para limitar o tamanho de seus domínios de difusão. Com sub-redes maiores do que isso, o roteamento e o switchgear (dependendo de quão robustos eles são) podem ser sobrecarregados com a necessidade de lidar com o tráfego de broadcast.

    

Answer 3

Mude para o IPv6!

Especialmente se você usa a negociação automática ICMP sem um servidor DHCP. :)

    

Answer 4

Por que não encurtar o tempo de concessão do DHCP tão pouco a ponto de frustrar o invasor com uma batalha perdida:)

    

Answer 5

Não há solução trivial porque não é um problema trivial.

No centro disso, os ataques DoS em uma instalação Ethernet sem fio, sejam eles algo "inteligente" como um ataque de exaustão de escopo DHCP, ou algo "sem cérebro" como um transmissor inundando o espectro usado pelos rádios, não podem ser parou porque os rádios não podem ignorar seletivamente os sinais de qualquer transmissor. O ar é um meio compartilhado, e isso é apenas física.

Em uma Ethernet com fio, você pode desativar a porta na qual as solicitações DHCP excessivas (ou outros tipos de ataques DoS) estão sendo originadas. Falta de desativar o ponto de acesso de onde as solicitações DHCP excessivas estão vindo (e desabilitar todas as unidades móveis associadas a esse AP), não há nada "trivial" que você possa fazer.

    

Answer 6

A melhor maneira de mitigar isso é no nível do switch - verifique se há uma explicação detalhada do ataque e da atenuação: dhcp-starvation-quick-and-dirty

    

Answer 7

Se você fizesse isso, introduziria a necessidade de configurar um grande número de rotas, switches da camada 3, agentes de retransmissão DHCP, listas de controle de acesso, regras de firewall etc. Imagine que meu servidor está em 10.1.1.1, meu gateway está em 10.1.1.2 e meu cliente DHCP está em 167.10.1.250: agora eu preciso de uma maneira de direcionar o tráfego do meu cliente para o meu servidor e para o gateway, para outros clientes que obtêm endereços IP em outra sub-rede, etc. tornar a rede praticamente inutilizável. A gestão de tal rede seria praticamente impossível.