Considerações de segurança do IPv6 que você não deve ignorar

É tentador tratar o IPv6 como um substituto direto do IPv4 que apenas tem um espaço de endereços maior. Em termos de segurança, algumas diferenças reais merecem ser compreendidas, em vez de presumir que tudo do IPv4 se aplica sem alterações.

A lista de bloqueio precisa ser construída separadamente, e não apenas ficar maior

O IPv6 tem suas próprias faixas privadas, de loopback e link-local, estruturadas de forma diferente das equivalentes do IPv4. Uma verificação de segurança que só sabe interpretar e filtrar faixas IPv4 deixará todas essas passarem em silêncio no lado do IPv6, não porque o IPv6 seja menos seguro, mas porque as proteções equivalentes simplesmente nunca foram construídas para ele.

Endereços IPv4 mapeados: um ponto cego fácil de ignorar

O IPv6 tem uma notação para embutir um endereço IPv4 dentro de um endereço IPv6, como ::ffff:127.0.0.1, que se refere ao mesmo endereço de loopback que o simples 127.0.0.1, apenas escrito na forma IPv6. Uma verificação que filtra corretamente o loopback IPv4, mas não desembrulha essa forma embutida, aprovará um endereço funcionalmente idêntico a um que ela bloquearia sem hesitar.

• Qualquer sistema que compare endereços resolvidos com uma lista de bloqueio precisa de uma lógica realmente separada e completa para IPv6, e não da suposição de que as regras do IPv4 se estendem automaticamente.
• Endereços IPv6 mapeados de IPv4 precisam ser desembrulhados e verificados especificamente contra as regras do IPv4, e não avaliados como endereços IPv6 opacos.
• Sistemas dual-stack (a maioria dos modernos) precisam que as duas verificações sejam aplicadas de forma consistente, já que o atacante simplesmente usará a família de endereços em que a verificação mais fraca estiver.

Nada disso é motivo para evitar o IPv6: uma adoção mais ampla geralmente é algo bom, e a superfície de ataque específica do IPv6 não é, por natureza, maior que a do IPv4. É um motivo para garantir que a lógica de segurança que lida com endereços tenha sido de fato construída e testada para as duas famílias de endereços, e não para uma delas com a outra acrescentada depois, como um complemento.

O NAT64 acrescenta uma segunda camada de tradução que vale conhecer

Algumas redes somente IPv6 usam NAT64 e DNS64 para que seus clientes ainda alcancem a internet exclusivamente IPv4: o DNS64 sintetiza na hora um registro AAAA para um domínio que só tem um registro A, embutindo o endereço IPv4 em um prefixo especial (64:ff9b::/96 é o padrão conhecido), e o NAT64 traduz de volta para o IPv4 real, na borda da rede, o tráfego destinado a esse endereço sintético. É um mecanismo legítimo e útil, mas isso significa que um endereço dentro dessa faixa específica não é um endereço IPv6 puro a ser avaliado por si só: é o IPv4 usando uma fantasia de IPv6 e precisa ser desembrulhado e verificado contra as regras do IPv4 da mesma forma que um endereço IPv4 mapeado.

Testar a lógica de segurança significa de fato testar as duas famílias

É fácil os testes automatizados penderem em silêncio para o IPv4: a maioria dos domínios de exemplo, das massas de teste e das verificações manuais rápidas o adota por padrão, sem que ninguém tenha decidido isso deliberadamente. Uma suíte de testes para qualquer código que resolva e filtre endereços só é tão confiável quanto a sua cobertura de IPv6: casos para as faixas privadas, de loopback e link-local acima, para um endereço IPv4 mapeado e para um endereço sintetizado no estilo NAT64 merecem, cada um, as suas próprias asserções explícitas, e não apenas “provavelmente funciona do mesmo jeito”. O código de segurança que trata endereços é exatamente o tipo de lógica em que um caminho não testado e um caminho quebrado são indistinguíveis até que um atacante encontre a diferença primeiro.