Como prevenir ataques de falsificação de IP
Onde deve ser aplicada a filtragem de origem, quando as verificações rigorosas do caminho inverso quebram tráfego válido e por que razão a autenticação e o IPv6 exigem atenção separada.
Verificar o percurso de uma entrega e decidir quem pode entrar são tarefas separadas. A validação da origem e a autenticação precisam dos seus próprios controlos.
Um balcão de receção pode verificar se uma entrega veio por um percurso esperado. A pessoa que a recebe continua a ter de decidir quem pode entrar no edifício. As redes têm uma divisão de tarefas 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 que intervalos de endereços devem chegar através da ligação de um cliente. Os pacotes que afirmam ter uma origem não relacionada podem ser rejeitados nesse ponto, antes de seguirem viagem. Esta é a abordagem de validação da origem descrita na BCP 38.
Numa rede empresarial, verifique tanto o tráfego que sai para a Internet como o tráfego que chega do exterior. O mesmo limite é uma saída de uma rede e uma entrada para outra. Defina as origens esperadas para cada ligação, incluindo intervalos legitimamente delegados, em vez de aplicar uma regra geral a todos os casos.
Uma verificação de intervalos não identifica a pessoa por detrás de um pacote. Também pode deixar margem para falsificação dentro de um intervalo permitido. Trate-a como um controlo de fronteira útil, não como um certificado de identidade.
Faça as verificações do caminho inverso corresponderem às rotas reais
O encaminhamento unicast pelo caminho inverso, ou uRPF, compara a origem de um pacote com a informação de encaminhamento. No modo estrito, a interface de entrada tem de corresponder ao caminho de retorno selecionado. Isto pode funcionar bem quando os caminhos são previsíveis.
No entanto, o tráfego legítimo pode chegar através de uma ligação enquanto a melhor rota de retorno utiliza outra. Isto acontece com encaminhamento assimétrico e em redes que utilizam vários fornecedores. As verificações estritas podem então descartar tráfego válido. A RFC 3704 explica estas contrapartidas. As abordagens de caminhos viáveis consideram alternativas permitidas; as verificações permissivas perguntam geralmente se existe uma rota, pelo que fornecem um teste mais fraco. Escolha e verifique o modo de acordo com a topologia real, incluindo a comutação em caso de falha.
Autentique o serviço e o utilizador
Mantenha as restrições de endereços onde forem úteis, mas não faça delas a única prova de identidade para acesso sensível. Utilize TLS devidamente validado para serviços Web e protocolos autenticados adequados para administração e pares de rede. A autenticação das contas e as permissões continuam a ter as suas próprias funções.
O TLS 1.3 autentica o servidor, pode também autenticar o cliente e protege o tráfego da aplicação. Não certifica todos os endereços IP de origem nem impede que uma inundação esgote uma ligação. A encriptação e a validação da origem protegem coisas diferentes.
Reduza as oportunidades de reflexão
Se operar DNS recursivo, restrinja a recursão aos clientes que pretende servir. Isto é diferente do DNS autoritativo, que pode precisar de responder publicamente pelos seus domínios. A RFC 5358 explica por que razão a recursão aberta pode transformar um servidor num refletor.
Verifique outros serviços expostos à procura de acessibilidade desnecessária e respostas excessivamente grandes. Planeie o apoio DDoS a montante antes de um incidente: a filtragem no seu próprio servidor não consegue restaurar uma ligação que já tenha ficado saturada antes de o tráfego lá chegar.
O IPv6 também exige estas decisões
A passagem para IPv6 não ativa automaticamente a encriptação nem impede a falsificação da origem. O IPsec exige configuração deliberada e gestão de chaves e pode ser utilizado com ambas as versões IP. As orientações de segurança operacional do IPv6 discutem os controlos efetivamente necessários. Numa rede dual-stack, avalie e teste ambos os caminhos.
Verifique se a proteção funciona sem quebrar o serviço
Registe os intervalos e as rotas esperados, teste o tráfego autorizado e a comutação em caso de falha e, depois, examine as rejeições e o estado do serviço. Um sistema de deteção de intrusões pode alertar para padrões; o bloqueio exige uma função de prevenção ou a resposta de um operador. Os registos devem ajudar a explicar o que aconteceu, não transformar uma origem declarada numa identidade presumida.
Enquanto utilizador normal da Internet, concentre-se nas atualizações, nas ligações autenticadas e na segurança das contas. Pergunte ao seu fornecedor sobre filtragem de origem, se necessário; não pode corrigir a validação de pacotes a montante a partir de um navegador. Para conhecer o contexto, leia como funciona uma origem falsificada ou que padrão de ataque cada controlo aborda.