A falsificação de ICMP é prática?

Quão prática é a falsificação de ICMP?

cenário 1: em um ambiente NAT, como o NAT controla as sessões ICMP (não tecnicamente as sessões, pois não é orientado à conexão?) Para resposta ECHO / ECHO, o Windows usa o mesmo identificador (0x1) e número de sequência com incremento de 256 para cada pacote . Se dois hosts estão executando ping no mesmo servidor externo, como o NAT diferencia os pacotes ICMP de entrada? Se a rede interna não filtrar o endereço de origem, quão difícil é forjar uma resposta de ECHO? caso de uso: icmp ping usado para monitoramento, um balanceador de carga pode executar ações incorretas / desnecessárias ao receber respostas forjadas de ICMP (destino inacessível, alta latência etc.)

cenário 2: algum dispositivo IPS, como o GFW, inspeciona pacotes no caminho de trânsito. Quão prático é forjar mensagens de erro ICMP que matam uma conexão furtiva. Em vez de enviar o TCP RST, ele envia a porta de destino inacessível / pacote muito grande (isso pode ficar interessante :)) com o IP de origem forjado (o IP legítimo do outro lado ou alguns saltos mais adiante). Mantenha o rastreamento do cabeçalho IP original e os primeiros 64 bytes podem ser caros, mas com o poder de computação disponível hoje, é factível?

Basicamente, dentro ou fora da NAT, qual a probabilidade de o ICMP forjado causar danos / confusões? Eu não estou falando sobre inundação do ICMP.

BTW, o NAT pode manipular qualquer protocolo IP diferente de TCP / UDP? Na verdade, não sei exatamente como ele lida com diferentes tipos de ICMP.

A RFC 5508 "Requisitos comportamentais da NAT para ICMP" diz (seção 3.1):

O mapeamento de consulta ICMP por dispositivos NAT é necessário para que os aplicativos atuais baseados em consulta ICMP funcionem. Isso implica em um dispositivo NAT para encaminhar de forma transparente pacotes de consulta ICMP iniciados a partir dos nós por trás do NAT e as respostas a esses pacotes de consulta na direção oposta. Conforme especificado em [NAT-TRAD], isso requer a conversão do cabeçalho IP. Um dispositivo NAPT converte ainda o ID de consulta do ICMP e a soma de verificação associada no cabeçalho do ICMP antes do encaminhamento.

Portanto, um dispositivo NAT pode realmente colocar um valor exclusivo no campo Identificador ao encaminhar uma solicitação para o exterior. Duas máquinas internas usando o mesmo identificador não são problema, o dispositivo NAT usará dois valores diferentes e lembre-se da combinação do ID original e do endereço IP interno.

Algumas informações (antigas) específicas da Cisco podem ser encontradas aqui: http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=3 . Esta página também inclui uma lista de protocolos / aplicativos suportados para NAT.

Se uma mensagem ICMP for enviada para notificar um erro causado por uma conexão TCP, a mensagem ICMP deverá incluir o cabeçalho e parte da carga útil do segmento TCP que acionou o erro. Isso é necessário para permitir que o host receptor identifique a conexão TCP.

Um dispositivo NAT pode fazer exatamente o mesmo para descobrir para onde enviar os erros ICMP que recebe. Se houver um mapeamento correspondente ao cabeçalho TCP na carga útil do ICMP, ele saberá para onde enviar a mensagem do ICMP.

Um invasor que deseja falsificar um erro ICMP precisaria conhecer os endereços IP e as portas de origem e destino para criar sua mensagem. Como a carga útil da mensagem ICMP também conterá um número de sequência TCP, o terminal TCP também poderá verificar se esse número de sequência é válido (ou seja, enviado e ainda não foi aceito). Isso dificultará muito a falsificação, mas essa validação pode não ser implementada em todos os sistemas.

Você provavelmente deveria dar uma boa olhada na RFC 5927 "ICMP Attacks against TCP".

Em qualquer implementação moderna de stateful de NAT, o rastreamento de conexão é geralmente uma parte fundamental para facilitar isso. Não há realmente nenhuma limitação sobre quais protocolos IP podem ser manipulados pelo NAT - o Linux Netfilter pode enviar NAT para qualquer protocolo IP, mas obviamente, com a limitação de que, se não houver tratamento especial para esse protocolo (ou seja, discriminadores adicionais), apenas um host interno será será capaz de se comunicar com um host externo específico de cada vez.

No caso do ICMP echo request, é altamente improvável que o campo identificador e carimbo de data / hora corresponda ao de outro host que executa ping no mesmo ponto de extremidade remoto - portanto, desde que a implementação de rastreamento de NAT / conexão seja capaz de utilizar esses dados, ele pode diferenciar entre os dois. Para destination unreachableo dispositivo NAT, seria necessário rastrear os dados da carga útil (ou seja, os primeiros 8 bytes) para garantir a validade da mensagem de erro do ICMP - mas, mesmo assim, o ponto final do host definitivamente deveria estar validando essa mensagem.

De um modo geral, assumindo uma pilha de rede compatível com RFC, as mensagens ICMP falsificadas não devem ser um problema devido ao fato de vários campos serem únicos ... A menos que o invasor seja um homem direto no meio, nesse ponto eles podem interferir livremente - é claro, é por isso que existem coisas como IPsec, TCP-MD5 e TCP-AO.

Nota: embora existam várias RFCs relacionadas ao NAT, isso não deve ser considerado um padrão acordado da maneira que são os protocolos de roteamento.