Você deve ter encontrado o DHCP ao configurar um roteador. Mas você sabe sobre os perigos que sua configuração incorreta no servidor da empresa pode esconder em si? Usando-o, um invasor pode não apenas desabilitar o servidor DHCP, mas também implementar um ataque MitM para interceptar dados importantes. Neste artigo, mostrarei dois vetores de ataque contra o DHCP e darei dicas sobre como protegê-lo.

TEORIA
Ao proteger uma rede contra ataques DHCP, é muito importante entendermos as complexidades da interação entre um servidor DHCP e um cliente. Por exemplo, qual é a relação entre o valor do endereço MAC no cabeçalho Ethernet e o valor CHADDR no cabeçalho DHCP ou quais mensagens são enviadas apenas pelo servidor DHCP para o endereço do cliente e não vice-versa. Mas as primeiras coisas primeiro. Primeiro, vamos dar uma olhada rápida nas mensagens DHCP básicas e na estrutura do próprio cabeçalho DHCP.

mensagens DHCP
O cliente e o servidor DHCP precisam apenas trocar quatro mensagens para obter um endereço IP e outros parâmetros de rede. Um cliente configurado para obter um endereço IP envia automaticamente uma mensagem DHCPDISCOVER para a rede (255.255.255.255) e endereços de transmissão de link (FF:FF:FF:FF:FF) para descobrir servidores DHCP. O cabeçalho IP especifica 0.0.0.0 no campo de endereço de origem do pacote IP porque o cliente ainda não recebeu esse parâmetro. O endereço MAC do cliente é indicado no campo de origem da mensagem na camada de enlace de dados.

Ao receber uma mensagem DHCPDISCOVER de um cliente em potencial, o servidor DHCP oferece um endereço IP gratuito. Esta mensagem, endereçada do servidor para o cliente, é denominada DHCPOFFER. Durante o período de oferta, o endereço é reservado pelo servidor DHCP e não é oferecido a outros clientes.

Suponha que o cliente tenha recebido uma mensagem DHCPOFFER de um servidor DHCP. Em seguida, ele envia uma mensagem de broadcast DHCPREQUEST contendo o endereço IP do servidor que emitiu a oferta. Essa mensagem de difusão informa a outros servidores DHCP que o cliente já aceitou uma oferta de um dos servidores. Nesse caso, os servidores DHCP restantes liberam os endereços IP reservados, podendo posteriormente ser oferecidos a outros clientes.

Quando o servidor recebe uma mensagem DHCPREQUEST, ele especifica o endereço IP escolhido pelo cliente em uma mensagem DHCPACK e a envia de volta ao cliente.

O cliente recebeu todos os parâmetros de rede necessários e, com isso, o processo de interação é considerado concluído. Mas, além dessas quatro mensagens principais, há algumas importantes:
DHCPNACK é uma mensagem enviada de um servidor para um cliente para notificar que uma concessão de endereço IP foi negada;
DHCPRELEASE é uma mensagem do cliente para o servidor que notifica o servidor de que o cliente não deseja mais usar o endereço IP atual e o servidor pode "retornar" esse endereço ao pool de endereços IP livres.
Compreendeu as principais mensagens. Agora vamos resumir um pouco: mensagens como DHCPOFFER, DHCPACK e DHCPNAK são enviadas apenas pelo servidor para o endereço do cliente. Vamos lembrar. Vamos precisar dessas informações um pouco mais tarde.

Estrutura do cabeçalho DHCP
Agora vamos dar uma breve olhada no cabeçalho DHCP encapsulado em datagramas UDP. A propósito, esqueci de falar sobre a camada de transporte: se estamos falando de DHCP, o servidor e o cliente usam as 67ª e 68ª portas UDP, respectivamente.

Vamos passar pelos campos de cabeçalho mais interessantes para nós:
Op Code é um campo que indica o tipo de mensagem. Se uma solicitação for feita do cliente para o servidor, esse campo será definido como 0x01 e vice-versa - 0x02;
htype - tipo de endereço operando na camada de enlace. Para Ethernet, este campo é definido como 0x01;
hlen - especifica o comprimento do endereço da camada de enlace em bytes (0x06 para Ethernet);
xid - identificador de transação para correspondência de solicitações e respostas entre eles;
seg - exibe o tempo em segundos decorrido desde que o cliente começou a receber ou atualizar um endereço IP;
CIADDR é o endereço IP do cliente. Este campo é preenchido se o cliente já tiver um endereço IP atribuído e precisar renovar seu aluguel;
YIADDR - o servidor preenche este campo com o valor do endereço IP que oferece ao cliente;
SIADDR - endereço IP do servidor DHCP, ao enviar mensagens de resposta DHCPOFFER e DHCPACK para o cliente;
GIADDR é o endereço IP do agente de retransmissão (roteador) que separa as redes nas quais o cliente e o servidor DHCP estão localizados;
CHADDR é um campo que indica o endereço MAC do cliente. Damos especial atenção a este campo;
Opção é um campo de comprimento variável que especifica opções adicionais (por exemplo, máscara de sub-rede, endereços de servidor DNS, endereço de gateway padrão, tempo de concessão de endereço).
Acho que está tudo claro aqui. Agora vamos falar sobre o campo CHADDR, que enfatizei acima. É lógico supor que o valor nos campos CHADDR do cabeçalho DHCP e o endereço MAC de origem no cabeçalho Ethernet (de mensagens do cliente para o servidor) serão idênticos.

Na interação cliente-servidor normal, esse é o caso. Tomamos nota e passamos para a parte prática.

TESTE DE DHCP PARA RESISTÊNCIA
estante de laboratório
Juntei tudo o que precisava que estava à mão:
roteador Cisco 2821;
Comutador Cisco Catalyst 2960;
PC cliente com Kali Linux.

Iniciei o DHCP no roteador com a emissão de endereços do pool 192.168.1.2–254. Um switch com uma configuração vazia, como fora da caixa.

FALTA DE DHCP
Antes de realizar o ataque DHCP Starvation, quero fazer uma pequena revisão. Sabemos que o servidor DHCP mantém uma tabela de correspondência entre endereços IP emitidos para clientes e seus endereços MAC, e que um endereço IP já emitido não pode ser oferecido a outro cliente novamente. A essência do ataque DHCP Starvation é "esgotar" o servidor DHCP enviando pacotes DHCPDISCOVER falsos com endereços MAC de origem aleatória. O servidor responderá a esses pacotes e reservará endereços IP gratuitos do pool, pelo que por algum tempo (enquanto o ataque estiver na fase ativa) não poderá emitir endereços IP para usuários comuns. Usaremos Yersinia

como uma ferramenta de ataque (a ferramenta tem o nome de uma bactéria). Além do DHCP, ele também pode atacar vários outros protocolos da camada de enlace.

Vamos selecionar o protocolo DHCP, especificar a opção de envio do pacote DISCOVER e começar a enviar pacotes DHCPDISCOVER falsos.

Embora haja uma inundação de pacotes, vamos examinar o pool de endereços DHCP.

Absolutamente todos os endereços do intervalo 192.168.1.2–254 foram reservados pelo servidor DHCP e, enquanto a inundação continuar, o servidor não poderá emitir endereços de seu pool para novos clientes. O servidor está esgotado.

A propósito, tal inundação pode causar uma negação de serviço para o servidor DHCP. Vamos ver a carga no roteador:

O processador está meio carregado. E isso é apenas de pacotes DHCPDISCOVER (ok, outro STP com CDP a cada dois segundos).

DHCP não autorizado ou falsificação de DHCP
O segundo vetor de ataque DHCP requer a implantação de um servidor DHCP não autorizado. Isso é necessário para emitir parâmetros de rede falsos para os clientes (em particular, o endereço do gateway padrão) e conduzir o MitM. Do ponto de vista de um invasor, a melhor coisa a fazer é “colocar” primeiro um servidor DHCP legítimo, o que fizemos acima.

Yersinia tem uma função para implantar tal servidor DHCP - criando um servidor DHCP não autorizado. Como parâmetros, especificaremos o endereço do servidor falso em nome do qual os parâmetros de rede serão emitidos, o intervalo de endereços, seu tempo de concessão (quanto maior, melhor), a máscara de sub-rede e, o mais importante, o endereço do gateway padrão - o PC que irá farejar o tráfego do usuário.

Resta apenas mudar a interface de rede do PC ouvinte para o modo de encaminhamento e, em seguida, é uma questão de técnica: os dispositivos clientes configurados para receber endereços IP automaticamente enviarão mensagens de transmissão DHCPDISCOVER e receberão parâmetros de rede de um servidor DHCP falso em resposta.

E é assim que se parece o despejo do tráfego ICMP na máquina atacante e o esquema de ataque MitM em nossa rede de laboratório.

NEUTRALIZAMOS ATAQUES AO PROTOCOLO DHCP
Agora vamos ver as tecnologias de segurança que impedem ataques DHCP. Convencionalmente, eles podem ser divididos em dois vetores: proteção contra DHCP Starvation e DHCP Spoofing.

Na maioria das vezes, a tecnologia DHCP Snooping cuida da neutralização de ataques ao protocolo DHCP, e a segurança da porta deve ser usada como uma adição obrigatória a ela. Ambas as tecnologias são usadas em switches.

Portas confiáveis ​​e não confiáveis
O conceito de portas confiáveis ​​e não confiáveis ​​o ajudará a esquecer o súbito aparecimento de um falso servidor DHCP na rede. A porta confiável permite o encaminhamento de mensagens DHCP do servidor. Lembre-se das mensagens DHCPOFFER, DHCPACK e DHCPNAK sobre as quais falamos no início? Um servidor DHCP falso não poderá oferecer suas opções falsas aos clientes enviando tais mensagens se estiver atrás de uma porta não confiável.

Portas confiáveis ​​são aquelas que estão diretamente conectadas ao servidor DHCP ou que "olham" em sua direção. Assim, os não confiáveis ​​são todo o resto. Em nossa rede de laboratório, apenas uma porta será confiável - G0 / 1.

Depois de habilitar o DHCP Snooping, todas as portas se tornam não confiáveis ​​por padrão. Portanto, você deve especificar explicitamente uma porta confiável para o switch. Mas antes disso, ative globalmente o DHCP Snooping e especifique em qual VLAN ele funcionará. Eu tenho uma configuração de switch padrão e todas as portas pertencem à primeira VLAN.

Como teste, vamos desligar nosso servidor DHCP, descartar o endereço que ele forneceu e tentar obter um endereço IP de um servidor DHCP falso. Aqui está o que acontece na máquina atacante: o falso DHCP vê as mensagens de descoberta do cliente e tenta diligentemente oferecer suas falsas opções de rede, mas o cliente não responde às respostas.

E tudo porque o switch descarta mensagens DHCPOFFER em uma porta não confiável, e é por isso que o cliente não vê uma oferta falsa.

taxa de limite
Outro recurso muito útil do DHCP Snooping é a restrição de envio de mensagens DHCP. Esse limite permite que uma certa quantidade de tráfego DHCP por segundo seja enviada pela porta do switch.

Para habilitar esse recurso, vamos selecionar todo o intervalo de portas não confiáveis ​​e definir o limite para dez pacotes por segundo. A Cisco não recomenda mais de 100 pacotes por segundo, mas dez são suficientes para nossa bancada de testes. É importante não cortar tráfego inofensivo de clientes.

Hora de experimentos novamente: vamos iniciar a distribuição DoS de mensagens DHCPDISCOVER e ver o que acontece. Não precisamos esperar muito: o log do console chega instantaneamente e nos notifica que dez pacotes DHCP foram recebidos na porta F0 / 2 e a porta está definida para o estado desabilitado por erro. A porta F0/2 caiu. É necessária uma intervenção adicional do administrador para restaurar a funcionalidade da porta.

A taxa de limite é útil porque evita que um invasor execute uma negação de serviço ou "devora" rapidamente um pool de endereços enviando um grande número de solicitações de DHCP.

Verifique o endereço MAC
O recurso de verificação de endereço MAC é ativado por padrão quando o DHCP Snooping está ativado. Mas se por algum motivo estiver inativo, aqui está a sintaxe para habilitá-lo.

Anteriormente, concentrei-me no campo CHADDR do cabeçalho DHCP e no endereço MAC de origem do cabeçalho Ethernet e disse que durante a interação normal do cliente e do servidor, os valores nesses campos são idênticos. Quando a função Verify MAC-Address está habilitada, o switch verifica esses dois campos e, se os endereços MAC forem diferentes, os descarta.

A propósito, os recursos da CPU do roteador são usados ​​​​para verificar o endereço MAC, que, obviamente, é várias vezes mais lento do que quando os pacotes são processados ​​\u200b\u200bpor chips ASIC. Durante a operação normal da rede, isso não afeta visivelmente de forma alguma, mas vamos simular esta situação: um ataque de esgotamento de DHCP foi iniciado, o que gera um grande número de pacotes DHCPDISCOVER. Cada um deles será verificado pelo processador do switch para correspondência de endereços MAC.

Um minuto após o ataque, a CPU do switch estava 95% carregada devido ao grande volume de pacotes DHCP que precisava processar. É para evitar tais situações que vale a pena usar a função Limit Rate - a porta simplesmente cairá quando o número permitido de pacotes por segundo for excedido.

Segurança Portuária
O último recurso de segurança do switch sobre o qual quero falar. Não pertence à tecnologia DHCP Snooping, mas desempenha um papel importante na proteção da rede contra ataques ao protocolo DHCP. Port Security permite que você especifique os endereços MAC dos hosts que têm permissão para transmitir dados através da porta. O endereço MAC de origem no cabeçalho Ethernet é usado para verificação e, como resultado, será tomada a decisão de passar pela porta.

Vamos configurar todas as portas não confiáveis ​​para aprender dinamicamente apenas um endereço MAC e salvá-los na configuração atual do switch. Vamos especificar o modo de resposta a uma violação das regras de segurança de desligamento - desligando a porta. Mas antes disso, as portas precisam ser alteradas para o modo de acesso.

Se iniciarmos o flood novamente com mensagens DHCPDISCOVER, onde o valor do endereço MAC de origem é único em cada quadro Ethernet, então a porta irá instantaneamente para o modo err-disable (assim como com Limit Rate), já que a regra que criamos para lembrar apenas um endereço MAC permitido na porta do switch será violada.

Você pode ver a tabela mantida pelo switch, que mostra a correspondência dos endereços MAC aprendidos em cada interface.

Não é difícil para um invasor esgotar um servidor DHCP alterando o endereço MAC de uma placa de rede. Sim, tempo suficiente, mas eficaz. E com a segurança de porta habilitada no switch, tais táticas estarão fadadas ao fracasso.

CONCLUSÕES​
Pode parecer que os ataques DHCP não são tão relevantes hoje. Na minha opinião, qualquer ataque será relevante na ausência da devida atenção à proteção da rede, e ainda mais se o equipamento de rede funcionar com as configurações padrão.

As tecnologias para proteger a rede contra ataques ao protocolo DHCP descritas no artigo não se tornam individualmente uma barreira intransponível para o invasor. Portanto, é sua aplicação complexa que dará proteção adequada ao DHCP.