Resumo

  • A RFC 2267 colocou a validação do prefixo de origem na interface do provedor que recebe o tráfego de um cliente, onde os intervalos legítimos daquela rede podiam ser conhecidos localmente.
  • BCP 38 transformou a proposta em uma boa prática em 2000. Um pacote aprovado pelo filtro aponta para uma fronteira de rede, não identifica o computador nem o usuário por trás dele.

O endereço no pacote não identificava quem o escreveu

Um servidor recebe tentativas de conexão que parecem vir de endereços sem caminho de volta. As respostas desaparecem, enquanto o remetente troca o campo de origem. Em outros pacotes, pode surgir o endereço verdadeiro de uma rede sem relação com o ataque. Se o alvo bloquear esse endereço aparente, também pode interromper conexões legítimas do terceiro inocente.

A RFC 2267 descreveu essa assimetria. O destino lê o endereço de origem que veio no pacote, mas não tem como confirmar diretamente quem o escolheu. Melhorias no sistema operacional podem ajudar o servidor a suportar mais tentativas; elas não revelam à vítima se o endereço foi falsificado. O documento tratou a proteção do host como parte da resposta e deslocou uma verificação para mais perto da rede de onde o tráfego saiu.

A interface do cliente era um ponto verificável

Considere um provedor que agrega rotas de várias redes atendidas. Na interface que liga o roteador a um cliente específico, o provedor pode manter a relação entre aquela conexão e os prefixos que ela está autorizada a enviar. O exemplo da RFC encaminha pacotes que usam o prefixo do cliente e rejeita os que alegam outra origem. Também recomenda registrar os pacotes descartados para acompanhar atividade suspeita.

Não é uma consulta a uma base global de titularidade de endereços. Trata-se de uma verificação local: este cliente, por este enlace, pode usar estes prefixos. Antes de o pacote seguir pela rede maior do provedor, o campo de origem é comparado com a política da interface. Se a origem não pertence ao conjunto permitido, a rede que recebe o tráfego pode interrompê-lo perto do ponto de entrada.

A posição do controle muda quem precisa agir. Sem um filtro a montante, a vítima tenta interpretar um campo que o próprio remetente pode ter forjado e corre o risco de penalizar o titular inocente do endereço. Com o filtro na entrada do provedor, a rede que transporta o tráfego do cliente pode rejeitar origens que não cabem naquela conexão. Se ainda houver um ataque com um prefixo permitido, a apuração pode começar por uma rede conhecida, em vez de todo o espaço de endereços da Internet.

Prefixo permitido não é caminho de retorno

A RFC 2267 não confundiu a validação de prefixos com uma checagem da rota reversa. Os autores consideraram verificar se o caminho de volta para o endereço de origem sairia pela mesma interface em que o pacote entrou. Não recomendaram essa regra geral porque a assimetria de rotas na Internet tornaria seu uso problemático. A proposta central compara o prefixo de origem com o que pode ser enviado pela rede conectada à interface.

As duas verificações ocorrem na entrada, mas não fazem a mesma pergunta. A checagem de retorno depende da direção indicada pela tabela de roteamento; o filtro do cliente depende dos prefixos autorizados naquele enlace. A RFC 3704 tratou depois de mecanismos para redes multihomed e atualizou a RFC 2827. Seus modos estrito, viável e flexível de RPF pertencem a uma discussão distinta; não são o objeto deste artigo.

Mobilidade expôs a necessidade de exceções

Um endereço pode ser válido para um nó móvel e, ao mesmo tempo, não estar entre os prefixos esperados na rede onde ele está conectado naquele momento. A RFC 2267 destacou o Mobile IP: um pacote enviado pela rede visitada podia usar como origem o endereço da rede de origem do nó. Um filtro simples no provedor visitado poderia descartá-lo. O memo apontou o túnel reverso, especificado mais tarde na RFC 2344, que leva o pacote ao agente de origem antes de encaminhá-lo à Internet.

O filtro não julga a intenção de quem envia. Ele aplica uma regra local sobre os prefixos permitidos em uma interface. Um serviço legítimo que precise usar outro endereço de origem precisa de um caminho ou de uma política compatível com essa fronteira. As RFCs não dizem que toda mobilidade falha nem que todo uso especial deve ser bloqueado. Elas mostram que uma exceção precisa estar refletida no caminho e na regra operacional.

A recomendação passou a se chamar BCP 38

A RFC 2267 saiu em janeiro de 1998 como documento Informational, sem definir um padrão da Internet. Em maio de 2000, a RFC 2827 a substituiu, manteve o título “Network Ingress Filtering” e recebeu a classificação Best Current Practice, o BCP 38. A recomendação continuou a pedir que provedores filtrassem o tráfego na entrada do cliente, barrando prefixos de origem que aquela rede não usava legitimamente.

A mudança de status do documento não comprova implantação. A RFC 2827 descreve uma prática recomendada, mas não lista quais provedores instalaram filtros, quantas interfaces foram cobertas ou como os pacotes se comportaram. A RFC 2267 diz que alguns operadores já começavam a implementar a técnica, sem apresentar um levantamento. Publicação, política do provedor, regra carregada no roteador, pacote descartado e investigação bem-sucedida são evidências diferentes.

O controle também tem alcance restrito. Ele pode impedir que o cliente use prefixos falsificados fora da lista permitida. Não impede que alguém se passe por outro host dentro da própria faixa autorizada, não bloqueia ataques com endereços válidos e não identifica equipamento, usuário ou intenção. Um log pode mostrar que uma interface rejeitou um pacote suspeito e ajudar a restringir o ponto de investigação; não prova quem o transmitiu.

A mudança histórica foi pequena no mecanismo e importante no lugar em que ele atuava. A vítima deixou de ser o único ponto capaz de reagir a uma origem enganosa. A RFC 2267 colocou uma verificação de prefixo na fronteira entre provedor e cliente, onde a relação podia ser mantida e aplicada localmente. BCP 38 deu à prática uma referência compartilhada. Em cada enlace, o resultado real ainda dependia de uma política correta e de um filtro instalado e ativo.

Fontes

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)