Considerações para a filtragem do protocolo ICMPv6

Com o crescimento da Internet e a possibilidade de navegar na Web, antes exclusivo das Universidades e Centros de Pesquisa, agora com o surgimento dos pequenos provedores regionais de acesso à Internet (ISP) em meados da década de 90, cada usuário recebia um endereço IPv4 público nas residências. Os usuários residenciais ainda não conheciam o NAT, e tinham uma conexão direta fim-a-fim, sem tradução de endereços e sem o compartilhamento do mesmo IP por muitos assinantes, como temos hoje.

Nessa mesma época começavam a surgir os ataques de negação de serviço (Denied of Service) que exploravam os dispositivos conectados nas redes, como por exemplo, os do tipo smurf attack, onde pacotes ICMP Echo Request eram enviados a endereços de broadcast. Esse tipo de exploração ficou conhecido como ataque de amplificação, com o objetivo de paralisar uma rede local.

Outro grande incidente com repercussão histórica foi o Ping da Morte (Ping of Death) que explorava falhas na implementação do protocolo IP em diversos sistemas operacionais especialmente o Windows 95, onde o atacante criava um pacote ICMP Echo Request com tamanho maior do que o permitido pelo padrão IP (65.535 bytes).

Ao longo do tempo, criou-se um movimento de que o “ping era perigoso”. Nesse contexto, muitos começaram a adotar a prática de bloqueio generalizado do ICMP e por muitos anos foi considerado uma “boa prática” de segurança.

Contudo, essa decisão foi baseada mais em um pânico ou medo do que em análise técnica. Como consequência, se tornou difícil distinguir agora entre uma falha de conectividade ou filtragem do tráfego ICMP na rede, criando-se assim, redes invisíveis, para dificultar o mapeamento da rede interna, onde o diagnóstico se tornou ineficiente.

Muitos scripts de firewalls (iptables, ipchains) e tutoriais começaram agora a divulgar a prática de incluir o bloqueio total do protocolo ICMP, sem explicar as consequências técnicas.A força dessa cultura foi tão intensa que ainda hoje, depois de 30 anos, ainda vemos muita gente bloqueando totalmente o ICMP na sua rede, de forma a criar uma falsa sensação de segurança.

ICMPv6: Mais do que um substituto do ICMP do IPv4

No IPv4, a descoberta de vizinhos em uma rede local era feita por meio do protocolo ARP (Address Resolution Protocol), definido na RFC 826. Este protocolo opera com mensagens broadcast, ou seja, enviadas a todos os dispositivos da rede.

Ao contrário do que muitos pensam, o IPv6 não é apenas uma versão expandida do IPv4. Ele reestrutura muitos dos princípios da comunicação em rede inserindo agora o ICMPv6 que recebeu novas funções, mais encorpado e forte, e não mais um substituto do seu antecessor, o ICMP. Algumas funções agora compreendem:

• Descoberta de vizinhos e roteadores: via NDP (RFC 4861).         
• Autoconfiguração de endereços: via            SLAAC (RFC 4862).
• Descoberta de MTU: fundamental já que o IPv6 não permite fragmentação intermediária.
             

Com o IPv6, eliminou-se completamente o uso de broadcast, substituindo-o por um modelo muito mais controlado e eficiente baseado em multicast como substituto.

O Neighbor Discovery Protocol (NDP), definido na RFC 4861, substitui as funções do ARP e vai além, oferecendo, descoberta de vizinhos e roteadores e também a detecção de endereço duplicado (DAD).

As mensagens de NDP são transportadas dentro do ICMPv6 e utilizam endereços multicast específicos (prefixo FF02::/16), otimizando o tráfego de descoberta na rede. Isso evita os problemas do broadcast ao segmentar a comunicação apenas aos dispositivos interessados.

Essas abordagens reduzem drasticamente a carga de rede e permitem implementações mais escaláveis e seguras, favorecendo dispositivos com recursos limitados (como sensores IoT) e ambientes como data centers e redes corporativas.

Impactos em bloquear o ICMPv6

Com o tradicional ICMP em IPv4, a prática de bloqueio não tinha um impacto tão alto, mesmo sabendo que não era uma prática correta. Agora, bloquear totalmente o ICMPv6 pode causar uma série de falhas e problemas na rede como por exemplo:

• Interrupção do SLAAC: hosts não recebem automaticamente o prefixo de rede.
• Quebra do NDP: sem isso, não há resolução de endereços MAC.
• Impossibilidade de detectar MTU adequada.
• Falha na Detecção de endereço duplicado (DAD).

Em ambientes corporativos ou acadêmicos com redes dual-stack, falhas intermitentes e difíceis de diagnosticar podem ter como única causa o bloqueio indevido do ICMPv6.

Laboratório de provas de filtragem segura de ICMPv6 utilizando Containerlab

Con la finalidad de analizar el comportamiento de ataques basados en mensajes ICMPv6, se creó una topología de red basada en la herramienta Containerlab, considerando los siguientes RFCs:

RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats“, donde se describen tres entornos de redes a considerar, según niveles de confianza.

A RFC 4890 fornece uma base sólida para filtragem segura e funcional de ICMPv6. Em vez de bloquear tudo, ela recomenda uma abordagem baseada em se conhecer os tipos e códigos de mensagens tais como:

• Type 133: Router Solicitation
• Type 134: Router Advertisement
• Type 135/136: Neighbor Solicitation/Advertisement
• Type 2: Packet Too Big
• Type 1: Destination Unreachable

El laboratorio de pruebas propuesto simula un entorno de red corporativo, que integra las herramientas THC IPv6 en IPv6 toolkit para los ejemplos de ataques y los dispositivos de red Nokia SRL Linux y Aruba-CX OS, lo que permitió la configuración de los siguientes mecanismos de protección.

Emprego de mecanismos de proteção especializados:

• RA Guard: bloqueia RA maliciosos em portas não autorizadas.
• ND Snooping:             analisa mensagens NS/NA para prevenir spoofing.
• DHCPv6 Guard: previne servidores DHCPv6 falsos.
• ACLs baseadas em tipo/código/porta VLAN.
• Rate-limiting inteligente: evita floods sem bloquear funcionalidade.

Las pruebas realizadas permitieron analizar diferentes vectores de ataques y determinar una combinación eficiente de los mecanismos antes descritos para un correcto filtrado de mensajes ICMPv6.

Você pode rever a apresentação do Fórum do LACNIC 43 no Youtube: https://youtu.be/jRLBx-2Layw

Considerações Finais

Bloquear o ICMPv4 foi uma reação histórica em prover uma segurança temporária em um momento onde a Internet estava começando a chegar nas residências dos usuários. Com o tempo e os hábitos adquiridos, persistir nessa mesma lógica com o ICMPv6 é um erro técnico e operacional. Mais do que nunca, precisamos nos basear em segurança com conhecimento de boas práticas com fundamento técnico, e não em medo.

En base a los resultados obtenidos, Containerlab demostró ser una herramienta versátil y 100% funcional, para la creación de laboratorios de pruebas controlados para la simulación de ataques sin comprometer entornos reales. Así mismo, la captura y análisis de tráfico de red es parte fundamental para la inspección de campos de encabezado y la posterior definición de reglas de filtrado seguras sin entorpecer el normal funcionamiento de ICMPv6. 

Nesse artigo, que é um resumo do que foi apresentado no Fórum Técnico do LACNIC 43, vimos que ICMPv6 é essencial hoje e presente nas redes de computadores, onde a segurança não está mais no conceito de bloqueios, mas sim no controle e filtragem de maneira inteligente.

Referências

• [RFC 792] – Internet Control Message Protocol.
• [RFC 4443] – ICMPv6.
• [RFC 4861] – Neighbor Discovery for IPv6.
• [RFC 4890] – Filtering            Recommendations.
• RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats“
• [RFC 8200] – IPv6 Specification.
• [RFC 4862] – IPv6 Stateless Address Autoconfiguration.
• IETF v6ops WG documents and BCOPs.
• ContainerLab – https://containerlab.dev/
• Tutorial y Laboratórios  – https://github.com/ernestosanchezv/icmpv6filter