Os endereços IP são "triviais para forjar"?

Eu estava lendo algumas das notas no novo serviço DNS público do Google :

• Benefícios de desempenho
• Benefícios de segurança

Notei na seção de segurança este parágrafo:

Até que uma solução padrão de todo o sistema para vulnerabilidades de DNS seja implementada universalmente, como o protocolo DNSSEC2, os resolvedores de DNS abertos precisam tomar medidas independentes para mitigar ameaças conhecidas. Muitas técnicas foram propostas; consulte IETF RFC 4542: Medidas para tornar o DNS mais resiliente contra respostas forjadas para obter uma visão geral da maioria delas. No DNS público do Google, implementamos e recomendamos as seguintes abordagens:

• Provisionar em excesso recursos da máquina para proteger contra ataques diretos de DoS aos próprios resolvedores. Como os endereços IP são triviais para os atacantes forjarem, é impossível bloquear as consultas com base no endereço IP ou na sub-rede; a única maneira eficaz de lidar com esses ataques é simplesmente absorver a carga.

Essa é uma realização deprimente; mesmo no estouro de pilha / falha no servidor / superusuário, frequentemente usamos endereços IP como base para proibições e blocos de todos os tipos.

Pensar que um invasor "talentoso" poderia usar trivialmente o endereço IP que quiser e sintetizar quantos endereços IP falsos únicos desejarem é realmente assustador!

Então, minha (s) pergunta (s):

• É realmente que fácil para um atacante de forjar um endereço IP em estado selvagem?
• Em caso afirmativo, quais mitigações são possíveis?

Como afirmado por muitos outros, os cabeçalhos de IP são triviais, desde que não se importe em receber uma resposta. É por isso que é visto principalmente com o UDP, pois o TCP requer um handshake de três vias. Uma exceção notável é o flood SYN , que usa o TCP e tenta amarrar recursos em um host de recebimento; novamente, como as respostas são descartadas, o endereço de origem não importa.

Um efeito colateral particularmente desagradável da capacidade dos invasores de falsificar endereços de origem é um ataque de retroespalhamento . Há uma excelente descrição aqui , mas brevemente, é o inverso de um ataque DDoS tradicional:

1. Obtenha o controle de uma botnet.
2. Configure todos os seus nós para usar o mesmo endereço IP de origem para pacotes maliciosos. Este endereço IP será sua eventual vítima.
3. Envie pacotes de todos os seus nós controlados para vários endereços na Internet, visando portas que geralmente não estão abertas ou conectando-se a portas válidas (TCP / 80) que afirmam fazer parte de uma transação já existente.

Em qualquer um dos casos mencionados em (3), muitos hosts responderão com um ICMP inacessível ou uma redefinição de TCP, direcionada ao endereço de origem do pacote malicioso . O atacante agora tem potencialmente milhares de máquinas descomprometidas na rede realizando um ataque DDoS à vítima escolhida, através do uso de um endereço IP de origem falsificado.

Em termos de mitigação, esse risco é realmente aquele que somente os ISPs (e particularmente os ISPs que fornecem acesso ao cliente, em vez de trânsito) podem lidar. Existem dois métodos principais para fazer isso:

1. Filtragem de ingresso - assegurando que os pacotes que chegam à sua rede sejam originários de intervalos de endereços que ficam do outro lado da interface de entrada. Muitos fornecedores de roteadores implementam recursos como encaminhamento de caminho reverso unicast , que usam as tabelas de roteamento e encaminhamento do roteador para verificar se o próximo salto do endereço de origem de um pacote recebido é a interface de entrada. Isso é melhor executado no primeiro salto de camada 3 da rede (ou seja, seu gateway padrão).

2. Filtragem de saída - garantindo que os pacotes que saem da sua rede sejam apenas de origem dos intervalos de endereços que você possui. Esse é o complemento natural da filtragem de entrada e é essencialmente parte de ser um 'bom vizinho'; garantindo que, mesmo que sua rede seja comprometida por tráfego malicioso, esse tráfego não seja encaminhado para as redes com as quais você faz parceria.

Ambas as técnicas são mais eficazes e facilmente implementadas quando feitas em redes de "borda" ou "acesso", onde os clientes interagem com o provedor. A implementação da filtragem de entrada / saída acima da camada de acesso se torna mais difícil, devido à complexidade de vários caminhos e roteamento assimétrico.

Eu já vi essas técnicas (principalmente a filtragem de entrada) usadas com grande efeito em uma rede corporativa. Talvez alguém com mais experiência no provedor de serviços possa fornecer mais informações sobre os desafios da implantação da filtragem de entrada / saída na Internet em geral. Eu imagino que o suporte a hardware / firmware seja um grande desafio, além de ser incapaz de forçar os fornecedores upstream de outros países a implementar políticas semelhantes ...

É realmente fácil para um invasor forjar um endereço IP na natureza?

Claro, se não me interessa receber respostas, posso enviar pacotes com muita facilidade usando qualquer endereço de origem que eu queira. Como muitos ISPs realmente não têm boas regras de saída, tudo o que forjar geralmente será entregue.

Se o invasor realmente precisar de comunicação bidirecional, isso se tornará muito difícil. Se eles precisam de comunicação bidirecional, é mais fácil simplesmente usar algum tipo de proxy. O que é muito fácil de configurar, se você souber o que está fazendo.

A proibição de pessoas por endereço IP é moderadamente eficaz no SF / SO / SU, pois o site usa http / https, o que requer comunicação bidirecional.

Pequena prova de conceito para a resposta de Zordeche (com ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Em outro console:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Então, sim, trivial, mas você não recebe as respostas conforme mencionado anteriormente, a menos que tenha acesso a 11.10.10.20 ou tenha um sniffer em algum lugar entre www.google.com e 11.10.10.20 (e seria preciso estar bem na frente) de ambos os lados, já que você não pode prever a rota dos pacotes). Além disso, o ISP (gateway do spoofer) pode não deixar esse pacote sair se houver algum tipo de inspeção de IP em andamento e verificar que a fonte cheira mal.

É fácil criar endereços IP para o tráfego UDP unidirecional . Para pacotes TCP, você só pode forjar para obter conexões TCP semi-abertas com pacotes SYN. Essa é a base de um tipo de ataque do DOS também. Mas você não pode forjar uma conexão HTTP com um endereço falsificado (por exemplo, se estiver filtrando sessões para usar o mesmo endereço IP). Embora sim, você pode falsificar um endereço IP nos pacotes, é útil apenas para certos tipos de ataques de negação de serviço.

O artigo do GOOG discutia explicitamente o DNS. O DNS usa pacotes UDP e TCP. Os UDP podem ser forjados, mas não o TCP. O TCP requer um handshake de três vias . Se o endereço IP de um pacote TCP forjar, o computador de falsificação não receberá a resposta e a conexão falhará. O UDP, como mencionado em outras respostas, é 'dispara e esquece' e não requer comunicação de resposta. Os ataques de DoS vêm quase exclusivamente na forma de pacotes UDP por esse motivo.

No contexto de Stack Overflow e sites de família, a questão levantada por Takaun Daikon é muito válida. Existem várias maneiras de obter um novo endereço IP do provedor de serviços de Internet. Alterar um endereço MAC é claramente o mais fácil e funciona para muitos ISPs. Além disso, muitas pessoas que estão fazendo bobagem podem estar usando um proxy público ou TOR. Bloquear claramente o IP de origem desses pacotes apenas bloqueará o nó de terminação proxy ou TOR.

Então, o bloqueio de endereços IP é válido? Inferno, sim, é. Mas você vai acabar com erros. Você bloqueará alguns IPs que realmente não são a fonte do problema (por exemplo, proxies) e também terá pessoas evitando seus bloqueios alterando os IPs. A pessoa que tiver azar o suficiente para obter o IP banido posteriormente não poderá acessar a família de sites SO. Mas a taxa de erro deve ser pequena. A menos que você esteja bloqueando grandes conjuntos de IPs. Mas se você está bloqueando um ou dois por dia, deve ficar bem.

Você pode querer introduzir um esquema um pouco mais sofisticado no qual bloqueia, mas apenas por um período, como um ano. Se a sua rede é capaz de limitar a largura de banda ou limitar a conexão, você também pode considerar um esquema em que duchas que executam o Apache Benchmarks em seu site são colocadas em uma gaiola com largura de banda muito limitada.

A falsificação de IP continuará porque os ISPs são preguiçosos.

Meu ISP sabe muito bem que estou em um endereço específico ou, pelo menos, na sub-rede em que estou. No entanto, eu posso usar qualquer endereço de origem. Por que é que? Simplesmente, custo.

Se eu falsificar alguns endereços aqui e ali, não custa nada ao meu ISP. Se todos os usuários do meu provedor de serviços de Internet falsificassem um pacote entre 1h e 2h, ainda assim não haveria um sinal no radar. No entanto, quando uma botnet envia muitos pacotes falsificados de muitos hosts em muitos ISPs, a máquina ou a rede de destino cai.

A realidade financeira é que, a menos que você seja atacado, a falsificação não custa nada. Custa dinheiro para implementar a filtragem perto do cliente, e quem gasta o dinheiro obtém muito pouco retorno além de saber que são bons cidadãos da rede.

UDP e ICMP são mais fáceis de falsificar, mas o TCP também é possível. Requer um sistema operacional remoto inseguro, que usa números de sequência previsíveis para explorar. Às vezes, são as máquinas de balanceamento de carga que alteram os números de sequência e os tornam previsíveis. Portanto, o TCP é possível - mas mais difícil.

A anti-falsificação de DNS se concentra principalmente no lado da segurança, para impedir que alguém envie uma resposta falsa a um resolvedor recursivo. Os aspectos de inundação do UDP não são específicos do DNS, exceto uma única consulta pequena (digamos, para '.') Causará uma resposta bastante grande. Assim, cria um bom vetor de amplificação. Existem muitos outros protocolos UDP por aí que funcionam, mas o DNS está em uso em todos os lugares e é fácil encontrar máquinas para amplificar ataques.

O DNSSEC torna isso ainda pior, com pacotes UDP que podem atingir 4k de tamanho.

Os endereços IP de Um ou Mais Servidores Cisco ICM NT são triviais para forjar no que diz respeito aos ataques do DOS (D) baseados no DNS, porque são tipicamente um caso de pacotes UDP de ignorar e esquecer. Para o tráfego HTTP, esse não é o caso, portanto, você precisa estar na mesma rede local que o servidor da Web (inteiramente possível, é claro, dependendo de onde seu site está hospedado) ou controlar os roteadores intermediários.

Você pode enviar uma carta a qualquer pessoa e, se não colocar um endereço de retorno no envelope (ou colocar o errado), eles poderão contratar todos os filtros de lixo eletrônico do mundo e não filtrar sua mensagem sem abrir (processamento ) isto.

No entanto, se o remetente desejar uma resposta, é melhor o endereço de retorno estar correto ou teria que haver um mecanismo da camada de aplicativo para obter o endereço correto. Então, posso fazer você pensar que está abrindo uma carta de Nana, mas mesmo que eu o engane com o conteúdo da carta, você não enviará a Nana um cheque para CASH para algum endereço na Nigéria (a menos que Nana seja nigeriana) ) Portanto, desafio / resposta é uma defesa eficaz, desde que você também não esteja sendo o Homem do Meio.

Posso definir o endereço IP de origem que eu quiser em um datagrama.
Se meu provedor de serviços de Internet deixaria esse pacote sair para o ambiente selvagem é outra questão.

Embora essa seja certamente uma realidade que precisa ser tratada, o problema subjacente é realmente não técnico: pessoas com intenção maliciosa tentando fazer coisas maliciosas. A solução real, portanto, deve ser também não técnica.

Acho que o Stackoverflow fez é EXATAMENTE a solução certa para lidar com a segunda linha de defesa: as técnicas para restringir os possíveis usuários de spam por meio de diferentes maneiras de limitar suas habilidades de interagir com a plataforma antes de atingir algum nível de 'credibilidade'.

Essas técnicas não apenas ajudam a melhorar a qualidade geral do site, como também incentivam os usuários a se envolverem e fornecerem respostas mais credíveis / confiáveis.

Do ponto de vista técnico, a melhor coisa a fazer seria fazer o que o Google sugere: apenas seja eficiente em absorver / lidar com a carga adicional.

Ótimo trabalho e continue melhorando!

O UDP é a principal parte do motivo disso ser fácil - na verdade, o Skype e o Slingbox exploram a capacidade de forjar endereços IP facilmente no UDP para ' perfurar ' o NAT e permitir fácil ponto a ponto.

O TCP é mais difícil, pois requer um ciclo completo de SYN / ACK, mas você ainda pode inundar o servidor com pacotes SYN suspensos, que vão para endereços IP a muitos saltos de distância e, basicamente, amarram um grande número de roteadores no processo.

Como mencionado acima, o uso de proxies é trivial e há um número muito grande de proxies anônimos abertos disponíveis.

Mesmo sem usar um proxy, posso definir o endereço MAC no meu firewall para qualquer novo valor arbitrário, redefinir meu modem a cabo e meu ISP me atribuirá um novo endereço IP brilhante.

E isso é apenas para iniciantes. Existem muitas outras maneiras de contornar as proibições de IP.

Em caso afirmativo, quais mitigações são possíveis?

Não há muito o que fazer no lado receptor.

O ISP do falsificador deve filtrar o tráfego de saída para que seus clientes não possam falsificar IPs de redes diferentes.

Como são poucas as linhas na configuração do roteador, não há uma boa desculpa para não fazê-lo.

Existe uma maneira de rastrear o invasor, mas isso requer a cooperação de seus fornecedores upstream: http://www.cymru.com/Documents/dos-and-vip.html

Como outros já apontaram, o UDP é bastante trivial de falsificar, o TCP nem tanto.

A defesa preferida, mas infelizmente não universalmente implantada, são os filtros de saída.

Para ISPs que executam serviços DSL etc, cada linha virtual deve ser configurada com ip verify unicast reverse-path(ou qualquer que seja o equivalente que não seja da Cisco) que bloqueia qualquer pacote cujo endereço IP de origem não esteja nos intervalos conhecidos por serem roteados nessa linha.

Lembro-me de programar soquetes no final dos anos 90 com o que provavelmente era o Visual Basic, e poderíamos definir o IP de origem em nossa conexão. Lembro-me vagamente de que, quando tentamos, o netstat -an mostrou o IP de origem real, mas os logs do Apache mostraram o IP falsificado; e acho que o Apache estava entregando o IP falsificado aos módulos perl e assim por diante.