Como prevenir ataques de falsificação de IP
Onde a filtragem de origem deve ser aplicada, quando verificações rigorosas de caminho reverso quebram tráfego válido e por que autenticação e IPv6 exigem atenção separada.
Verificar a rota de uma entrega e decidir quem pode entrar são tarefas separadas. Validação de origem e autenticação precisam de controles próprios.
Uma recepção pode verificar se uma entrega veio por uma rota esperada. A pessoa que a recebe ainda precisa decidir quem pode entrar no edifício. As redes têm uma divisão de trabalho semelhante: validar de onde o tráfego afirma vir e depois autenticar o acesso ao serviço.
Coloque a primeira verificação perto da origem
Um operador de rede sabe quais faixas de endereços devem chegar pela conexão de um cliente. Pacotes que afirmam ter uma origem não relacionada podem ser rejeitados ali, antes de avançarem. Essa é a abordagem de validação de origem descrita na BCP 38.
Em uma rede corporativa, verifique tanto o tráfego que sai em direção à Internet quanto o que chega de fora. O mesmo limite é uma saída de uma rede e uma entrada para outra. Defina as origens esperadas para cada conexão, incluindo faixas legitimamente delegadas, em vez de aplicar uma regra geral igual em todos os lugares.
Uma verificação de faixa não identifica a pessoa por trás de um pacote. Ela também pode deixar espaço para falsificação dentro de uma faixa permitida. Trate-a como um controle de limite útil, não como um certificado de identidade.
Faça as verificações de caminho reverso corresponderem às rotas reais
O encaminhamento unicast por caminho reverso, ou uRPF, compara a origem de um pacote com as informações de roteamento. No modo estrito, a interface de entrada precisa corresponder ao caminho de retorno selecionado. Isso pode funcionar bem quando os caminhos são previsíveis.
Porém, o tráfego legítimo pode chegar por uma conexão enquanto a melhor rota de retorno usa outra. Isso acontece com roteamento assimétrico e redes que usam vários provedores. Nesse caso, verificações estritas podem descartar tráfego válido. A RFC 3704 explica essas compensações. Abordagens de caminho viável consideram alternativas permitidas; verificações flexíveis geralmente perguntam apenas se existe uma rota, portanto fornecem um teste mais fraco. Escolha e verifique o modo em relação à topologia real, incluindo o failover.
Autentique o serviço e o usuário
Mantenha as restrições de endereço onde elas forem úteis, mas não as transforme na única prova de identidade para acessos sensíveis. Use TLS devidamente validado para serviços web e protocolos autenticados apropriados para administração e pares de rede. A autenticação das contas e as permissões continuam tendo suas próprias funções.
A TLS 1.3 autentica o servidor, também pode autenticar o cliente e protege o tráfego da aplicação. Ela não certifica todos os endereços IP de origem nem impede que uma inundação esgote um enlace. Criptografia e validação de origem protegem coisas diferentes.
Reduza as oportunidades de reflexão
Se você opera DNS recursivo, restrinja a recursão aos clientes que pretende atender. Isso é diferente do DNS autoritativo, que pode precisar responder publicamente pelos seus domínios. A RFC 5358 explica por que a recursão aberta pode transformar um servidor em um refletor.
Verifique outros serviços expostos em busca de alcançabilidade desnecessária e respostas grandes demais. Planeje a assistência upstream contra DDoS antes de um incidente: a filtragem no próprio servidor não consegue restaurar uma conexão que já foi saturada antes de o tráfego chegar até ele.
O IPv6 também exige essas decisões
Migrar para IPv6 não ativa automaticamente a criptografia nem impede a falsificação de origem. O IPsec exige configuração deliberada e gerenciamento de chaves, e pode ser usado com as duas versões do IP. A orientação de segurança operacional do IPv6 discute os controles realmente necessários. Em uma rede dual stack, avalie e teste os dois caminhos.
Verifique se a proteção funciona sem interromper o serviço
Registre as faixas e rotas esperadas, teste o tráfego autorizado e o failover e depois examine os descartes e a saúde do serviço. Um sistema de detecção de intrusão pode alertar sobre padrões; bloquear exige uma função de prevenção ou a resposta de um operador. Os logs devem ajudar a explicar o que aconteceu, não transformar uma origem declarada em uma identidade presumida.
Como usuário comum da Internet, concentre-se em atualizações, conexões autenticadas e segurança das contas. Pergunte ao seu provedor sobre filtragem de origem, se necessário; você não pode corrigir a validação de pacotes upstream a partir de um navegador. Para conhecer o contexto, leia como funciona uma origem falsificada ou qual padrão de ataque cada controle aborda.