Verificação de encaminhamento de caminho reverso da Unicast para VPNs
Entendendo o Unicast RPF (switches)
Para se proteger contra spoofing de IP, e alguns tipos de ataques de negação de serviço (DoS) e negação de serviço distribuído (DDoS), o encaminhamento de caminho reverso (RPF) unicast verifica se os pacotes estão chegando de um caminho legítimo. Ele faz isso verificando o endereço fonte de cada pacote que chega em uma interface de entrada não confiável e, comparando-o com a entrada da tabela de encaminhamento para seu endereço de origem. Se o pacote for de um caminho válido, ou seja, aquele que o remetente usaria para chegar ao destino, o dispositivo encaminha o pacote para o endereço de destino. Se não for de um caminho válido, o dispositivo descarta o pacote. A menos que seja protegido contra, a spoofing de IP pode ser uma maneira eficaz para os intrusos passarem pacotes IP para um destino como tráfego genuíno, quando na verdade os pacotes não são realmente destinados ao destino.
O Unicast RPF é compatível com as famílias de protocolo IPv4 e IPv6, bem como para a família de endereços de rede privada virtual (VPN). O RPF unicast não é suportado em interfaces configuradas como fontes de túnel. Isso afeta apenas os pacotes de trânsito que saem do túnel.
Existem dois modos de RPF unicast, modo rigoroso e modo solto. O padrão é um modo rigoroso, o que significa que o switch encaminha um pacote apenas se a interface de recebimento for o melhor caminho de retorno para o endereço fonte unicast do pacote. O modo rigoroso é especialmente útil em interfaces não confiáveis (onde usuários ou processos não confiáveis podem colocar pacotes no segmento de rede) e para interfaces simétricas roteadas (ver Quando habilitar o Unicast RPF.) Para obter mais informações sobre O RPF unicast rigoroso, consulte RFC 3704, Filtragem de entrada para redes multihomed em http://www.ietf.org/rfc/rfc3704.txt.
Para habilitar RPF unicast de modo rigoroso em uma interface de borda do cliente selecionada:
[editar interfaces]user@switch# set interface-name unit 0 family inet rpf-check
O outro modo é o modo frouxo, o que significa que o sistema verifica se o pacote tem um endereço de origem com um prefixo correspondente na tabela de roteamento, mas não verifica se a interface de recebimento é o melhor caminho de retorno para o endereço fonte unicast do pacote.
Para habilitar o modo RPF frouxo unicast, digite:
[editar interfaces]user@switch# set interface-name unit 0 family inet rpf-check mode loose
- Visão geral do Unicast RPF para switches
- Implementação do Unicast RPF
- Quando habilitar o RPF unicast
- Quando não habilitar o Unicast RPF
- Limitações da implementação de RPF da Unicast nos switches EX3200, EX4200 e EX4300
Visão geral do Unicast RPF para switches
O RPF Unicast funciona como um filtro de entrada que reduz o encaminhamento de pacotes IP que podem estar falsificando um endereço. Por padrão, o RPF unicast é desativado nas interfaces do switch. O switch oferece suporte apenas ao método de caminhos ativos para determinar o melhor caminho de retorno para um endereço de origem unicast. O método de caminhos ativos apresenta a melhor entrada de caminho reverso na tabela de encaminhamento. Ele não considera rotas alternativas especificadas usando métodos específicos de protocolo de roteamento ao determinar o melhor caminho de retorno.
Se a tabela de encaminhamento lista a interface de recebimento como a interface a ser usada para encaminhar o pacote de volta à sua fonte unicast, essa será a melhor interface de caminho de retorno.
Implementação do Unicast RPF
- Filtragem de pacotes Unicast RPF
- Solicitações de Bootstrap Protocol (BOOTP) e DHCP
- Manuseio padrão de rota
Filtragem de pacotes Unicast RPF
Quando você habilita o RPF unicast no switch, o switch lida com o tráfego da seguinte maneira:
Se o switch receber um pacote na interface que é o melhor caminho de retorno para o endereço de origem unicast desse pacote, o switch encaminha o pacote.
Se o melhor caminho de retorno do switch para o endereço de origem unicast do pacote não for a interface de recebimento, o switch descarta o pacote.
Se o switch receber um pacote que tenha um endereço IP de origem que não tenha uma entrada de roteamento na tabela de encaminhamento, o switch descarta o pacote.
Solicitações de Bootstrap Protocol (BOOTP) e DHCP
Os pacotes de solicitação de boottrap (BOOTP) e DHCP são enviados com um endereço MAC transmitido e, portanto, o switch não realiza verificações de RPF unicast neles. O switch encaminha todos os pacotes BOOTP e pacotes de solicitação de DHCP sem realizar verificações de RPF unicast.
Manuseio padrão de rota
Se o melhor caminho de retorno à fonte for a rota padrão (0.0.0.0) e os pontos de rota padrão para reject, o switch descarta os pacotes. Se a rota padrão aponta para uma interface de rede válida, o switch realiza uma verificação de RPF unicast normal nos pacotes.
No EX4300, a rota padrão não é usada quando o switch está configurado no modo RPF rigoroso unicast.
Quando habilitar o RPF unicast
Habilite o RPF unicast quando quiser garantir que o tráfego que chega em uma interface de rede venha de uma fonte que reside em uma rede que a interface pode alcançar. Você pode habilitar RPF unicast em interfaces não confiáveis para filtrar pacotes falsificados. Por exemplo, um aplicativo comum para RPF unicast é para ajudar a defender uma rede empresarial contra ataques DoS/DDoS vindos da Internet.
Habilite o RPF unicast apenas em interfaces simétricas roteadas, e o mais próximo possível da fonte de tráfego interrompe o tráfego falsificado antes que ele possa proliferar ou alcançar interfaces que não tenham RPF unicast habilitado. Como o RPF unicast é habilitado globalmente nos switches EX3200, EX4200 e EX4300, garanta que todas as interfaces sejam roteadas simetricamente antes de habilitar o RPF unicast nesses switches, como mostrado na Figura 1. Habilitar o RPF unicast em interfaces assimétricas resulta em pacotes de fontes legítimas sendo filtrados. Uma interface simétrica usa a mesma rota em ambas as direções entre a fonte e o destino.
O RPF Unicast é habilitado globalmente nos switches EX3200, EX4200 e EX4300 para, com esses dispositivos, ter certeza de que todas as interfaces são roteadas simetricamente antes de habilitar o RPF unicast nesses switches. Habilitar o RPF unicast em interfaces assimétricas resulta em pacotes de fontes legítimas sendo filtrados.
roteadas
As interfaces de switch a seguir são mais propensas a serem roteadas simetricamente e, portanto, são candidatos para habilitação de RPF unicast:
A borda do provedor de serviços para um cliente
A vantagem do cliente para um provedor de serviços
Um único ponto de acesso fora da rede (geralmente no perímetro da rede)
Uma rede terminal que tem apenas um link
Nos switches EX3200, EX4200 e EX4300, recomendamos que você habilite o RPF unicast explicitamente em todas as interfaces ou apenas em uma interface. Para evitar possíveis confusões, não a habilite apenas em algumas interfaces:
Habilitar RPF unicast explicitamente em apenas uma interface torna mais fácil se você optar por desabilitar no futuro, porque você deve desativar explicitamente o RPF unicast em cada interface em que você a habilitou explicitamente. Se você ativar explicitamente o RPF unicast em duas interfaces e desabitá-lo em apenas uma interface, o RPF unicast ainda está implícito habilitado globalmente no switch. A desvantagem dessa abordagem é que o switch exibe a bandeira que indica que o RPF unicast é habilitado apenas em interfaces nas quais o RPF unicast está explicitamente habilitado, portanto, embora o RPF unicast esteja habilitado em todas as interfaces, esse status não é exibido.
Habilitar o RPF unicast explicitamente em todas as interfaces torna mais fácil saber se o RPF unicast está habilitado no switch porque cada interface mostra o status correto. (Apenas interfaces nas quais você habilita explicitamente o RPF unicast exibem a bandeira que indica que o RPF unicast está habilitado.) A desvantagem dessa abordagem é que, se você quiser desativar o RPF unicast, você deve desabilitar explicitamente em todas as interfaces. Se o RPF unicast estiver habilitado em qualquer interface, ele será implícito habilitado em todas as interfaces.
Quando não habilitar o Unicast RPF
Normalmente, você não habilitará RPF unicast se:
As interfaces dos switches são multihomed.
Interfaces de switch são interfaces confiáveis.
O BGP está transportando prefixos e alguns desses prefixos não são anunciados ou não são aceitos pelo ISP sob sua política. (O efeito neste caso é o mesmo que filtrar uma interface usando uma lista de acesso incompleta.)
As interfaces de switch enfrentam o núcleo da rede. As interfaces voltadas para o núcleo geralmente são roteadas assimétricamente.
Uma interface roteada assimétrica usa diferentes caminhos para enviar e receber pacotes entre a fonte e o destino, conforme mostrado na Figura 2. Isso significa que, se uma interface receber um pacote, essa interface não corresponderá à entrada da tabela de encaminhamento como o melhor caminho de retorno de volta à fonte. Se a interface de recebimento não for o melhor caminho de retorno para a fonte de um pacote, o RPF unicast faz com que o switch descarte o pacote, embora venha de uma fonte válida.
roteadas assimétricas
Não habilite RPF unicast nos switches EX3200, EX4200 e EX4300 se alguma interface de switch for roteada assimétricamente, porque o RPF unicast é habilitado globalmente em todas as interfaces desses switches. Todas as interfaces de switch devem ser roteadas simetricamente para que você habilite RPF unicast sem o risco do switch descartar o tráfego que você deseja encaminhar.
Limitações da implementação de RPF da Unicast nos switches EX3200, EX4200 e EX4300
Nos switches EX3200, EX4200 e EX4300, o switch implementa o RPF unicast globalmente. Você não pode habilitar RPF unicast por interface. O RPF Unicast é desativado globalmente por padrão.
Quando você habilita o RPF unicast em qualquer interface, ele é habilitado automaticamente em todas as interfaces de switch, incluindo grupos de agregação de links (LAGs), interfaces integradas de roteamento e ponte (IRB) e interfaces VLAN roteadas (RVIs).
Quando você desativa RPF unicast na interface (ou interfaces) em que você habilita rPF unicast, ele é desativado automaticamente em todas as interfaces do switch.
Você deve desabilitar explicitamente o RPF unicast em cada interface em que foi explicitamente habilitado ou o RPF unicast permanece habilitado em todas as interfaces do switch.
Os switches QFX, switches OCX e switches EX3200 e EX4200 não executam filtragem de RPF unicast no tráfego multicaminho de igual custo (ECMP). A verificação de RPF unicast examina apenas um caminho de retorno melhor para a fonte do pacote, mas o tráfego ECMP emprega um bloco de endereços que consiste em vários caminhos. Usar RPF unicast para filtrar o tráfego de ECMP nesses switches pode resultar no descarte de pacotes de switch que você deseja encaminhar porque o filtro RPF unicast não examina todo o bloco de endereçoS ECMP.
Veja também
Exemplo: Configuração do Unicast RPF (em um roteador)
Este exemplo mostra como ajudar a defender interfaces de entrada contra ataques de negação de serviço (DoS) e negação de serviço distribuída (DDoS), configurando RPF unicast em uma interface de borda do cliente para filtrar o tráfego de entrada.
Requisitos
Nenhuma configuração especial além da inicialização do dispositivo é necessária.
Visão geral
Neste exemplo, o Dispositivo A está usando o OSPF para anunciar um prefixo para o link que se conecta ao dispositivo D. O dispositivo B tem RPF unicast configurado. O OSPF é habilitado nos links entre o Dispositivo B e o Dispositivo C e os links entre o Dispositivo A e o Dispositivo C, mas não nos links entre o Dispositivo A e o Dispositivo B. Portanto, o dispositivo B aprende sobre a rota para o Dispositivo D através do Dispositivo C.
Se a filtragem de entrada for usada em um ambiente onde o DHCP ou BOOTP for usado, deve ser garantido que os pacotes com endereço fonte de 0,0.0.0.0 e um endereço de destino de 255.255.255.255 podem alcançar o agente de retransmissão em roteadores quando apropriado.
Este exemplo também inclui um filtro de falha. Quando um pacote falha na verificação de RPF unicast, o filtro de falha é avaliado para determinar se o pacote deve ser aceito de qualquer maneira. O filtro de falha neste exemplo permite que as interfaces do dispositivo B aceitem pacotes de protocolo de configuração dinâmica de host (DHCP). O filtro aceita todos os pacotes com um endereço de origem de 0,0.0.0 e um endereço de destino de 255.255.255.255.255.
Configuração
Configuração rápida da CLI
Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.
Dispositivo A
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set interfaces fe-0/0/2 unit 5 family inet address 10.0.0.5/30 set interfaces fe-0/0/1 unit 17 family inet address 10.0.0.17/30 set interfaces fe-0/1/1 unit 25 family inet address 10.0.0.25/30 set interfaces fe-1/1/1 unit 29 family inet address 10.0.0.29/30 set protocols ospf export send-direct set protocols ospf area 0.0.0.0 interface fe-0/1/1.25 set protocols ospf area 0.0.0.0 interface fe-1/1/1.29 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from route-filter 10.0.0.16/30 exact set policy-options policy-statement send-direct then accept
Dispositivo B
set interfaces fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-1/1/1 unit 6 family inet address 10.0.0.6/30 set interfaces fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/1 unit 9 family inet address 10.0.0.9/30 set interfaces fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp set interfaces fe-0/1/0 unit 13 family inet address 10.0.0.13/30 set protocols ospf area 0.0.0.0 interface fe-0/1/1.9 set protocols ospf area 0.0.0.0 interface fe-0/1/0.13 set routing-options forwarding-table unicast-reverse-path active-paths set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32 set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32 set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic set firewall filter rpf-special-case-dhcp term allow-dhcp then accept set firewall filter rpf-special-case-dhcp term default then log set firewall filter rpf-special-case-dhcp term default then reject
Dispositivo C
set interfaces fe-1/2/0 unit 10 family inet address 10.0.0.10/30 set interfaces fe-0/0/2 unit 14 family inet address 10.0.0.14/30 set interfaces fe-1/0/2 unit 21 family inet address 10.0.0.21/30 set interfaces fe-1/2/2 unit 26 family inet address 10.0.0.26/30 set interfaces fe-1/2/1 unit 30 family inet address 10.0.0.30/30 set protocols ospf area 0.0.0.0 interface fe-1/2/0.10 set protocols ospf area 0.0.0.0 interface fe-0/0/2.14 set protocols ospf area 0.0.0.0 interface fe-1/2/2.26 set protocols ospf area 0.0.0.0 interface fe-1/2/1.30
Dispositivo D
set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30
Dispositivo E
set interfaces fe-1/2/0 unit 22 family inet address 10.0.0.22/30
Configuração do dispositivo A
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.
Para configurar o dispositivo A:
Configure as interfaces.
[edit interfaces] user@A# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30 user@A# set fe-0/0/2 unit 5 family inet address 10.0.0.5/30 user@A# set fe-0/0/1 unit 17 family inet address 10.0.0.17/30 user@A# set fe-0/1/1 unit 25 family inet address 10.0.0.25/30 user@A# set fe-1/1/1 unit 29 family inet address 10.0.0.29/30
Configure OSPF.
[edit protocols ospf] user@A# set export send-direct user@A# set area 0.0.0.0 interface fe-0/1/1.25 user@A# set area 0.0.0.0 interface fe-1/1/1.29
Configure a política de roteamento.
[edit policy-options policy-statement send-direct] user@A# set from protocol direct user@A# set from route-filter 10.0.0.16/30 exact user@A# set then accept
Se você terminar de configurar o Dispositivo A, confirme a configuração.
[edit] user@A# commit
Configuração do dispositivo B
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração.
Para configurar o dispositivo B:
Configure as interfaces.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30 user@B# set fe-1/1/1 unit 6 family inet address 10.0.0.6/30 user@B# set fe-0/1/1 unit 9 family inet address 10.0.0.9/30 user@B# set fe-0/1/0 unit 13 family inet address 10.0.0.13/30
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@B# set interface fe-0/1/1.9 user@B# set interface fe-0/1/0.13
Configure o RPF unicast e aplique o filtro de falha opcional.
[edit interfaces] user@B# set fe-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-1/1/1 unit 6 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/1 unit 9 family inet rpf-check fail-filter rpf-special-case-dhcp user@B# set fe-0/1/0 unit 13 family inet rpf-check fail-filter rpf-special-case-dhcp
(Opcional) Configure o filtro de falha que é avaliado se um pacote falhar na verificação do RPF.
[edit firewall filter rpf-special-case-dhcp] user@B# set term allow-dhcp from source-address 0.0.0.0/32 user@B# set term allow-dhcp from destination-address 255.255.255.255/32 user@B# set term allow-dhcp then count rpf-dhcp-traffic user@B# set term allow-dhcp then accept user@B# set term default then log user@B# set term default then reject
(Opcional) Configure apenas caminhos ativos a serem considerados na verificação de RPF.
Esse é o comportamento padrão.
[edit routing-options forwarding-table] user@B# set unicast-reverse-path active-paths
Se você terminar de configurar o Dispositivo B, confirme a configuração.
[edit] user@B# commit
Resultados
Confirme sua configuração emitindo os show firewallcomandos show routing-optionsshow interfacesshow protocolse show policy-options os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
Dispositivo A
user@A# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
fe-0/0/2 {
unit 5 {
family inet {
address 10.0.0.5/30;
}
}
}
fe-0/0/1 {
unit 17 {
family inet {
address 10.0.0.17/30;
}
}
}
fe-0/1/1 {
unit 25 {
family inet {
address 10.0.0.25/30;
}
}
}
fe-1/1/1 {
unit 29 {
family inet {
address 10.0.0.29/30;
}
}
}
user@A# show protocols
ospf {
export send-direct;
area 0.0.0.0 {
interface fe-0/1/1.25;
interface fe-1/1/1.29;
}
}
user@A# show policy-options
policy-statement send-direct {
from {
protocol direct;
route-filter 10.0.0.16/30 exact;
}
then accept;
}
Dispositivo B
user@B# show firewall
filter rpf-special-case-dhcp {
term allow-dhcp {
from {
source-address {
0.0.0.0/32;
}
destination-address {
255.255.255.255/32;
}
}
then {
count rpf-dhcp-traffic;
accept;
}
}
term default {
then {
log;
reject;
}
}
}
user@B# show interfaces
fe-1/2/0 {
unit 2 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.2/30;
}
}
}
fe-1/1/1 {
unit 6 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.6/30;
}
}
}
fe-0/1/1 {
unit 9 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.9/30;
}
}
}
fe-0/1/0 {
unit 13 {
family inet {
rpf-check fail-filter rpf-special-case-dhcp;
address 10.0.0.13/30;
}
}
}
user@B# show protocols
ospf {
area 0.0.0.0 {
interface fe-0/1/1.9;
interface fe-0/1/0.13;
}
}
user@B# show routing-options
forwarding-table {
unicast-reverse-path active-paths;
}
Insira as configurações no Dispositivo C, Dispositivo D e Dispositivo E, conforme mostrado na configuração rápida da CLI.
Verificação
Confirme se a configuração está funcionando corretamente.
- Confirme que o Unicast RPF está habilitado
- Confirme que os endereços de origem estão bloqueados
- Confirme que os endereços de origem estão desbloqueados
Confirme que o Unicast RPF está habilitado
Propósito
Certifique-se de que as interfaces do dispositivo B tenham RPF unicast habilitado.
Ação
user@B> show interfaces fe-0/1/0.13 extensive
Logical interface fe-0/1/0.13 (Index 73) (SNMP ifIndex 553) (Generation 208)
Flags: SNMP-Traps 0x4000 Encapsulation: ENET2
Traffic statistics:
Input bytes : 999390
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Local statistics:
Input bytes : 998994
Output bytes : 1230122
Input packets: 12563
Output packets: 12613
Transit statistics:
Input bytes : 396 0 bps
Output bytes : 0 0 bps
Input packets: 0 0 pps
Output packets: 0 0 pps
Protocol inet, MTU: 1500, Generation: 289, Route table: 22
Flags: Sendbcast-pkt-to-re, uRPF
RPF Failures: Packets: 0, Bytes: 0
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.0.12/30, Local: 10.0.0.13, Broadcast: 10.0.0.15, Generation: 241
Significado
A bandeira uRPF confirma que o RPF unicast está habilitado nesta interface.
Confirme que os endereços de origem estão bloqueados
Propósito
Use o comando para garantir que o ping dispositivo B bloqueie o tráfego de endereços de origem inesperados.
Ação
Do dispositivo A, ping interfaces do dispositivo B, usando 10.0.0.17 como endereço fonte.
user@A> ping 10.0.0.6 source 10.0.0.17 PING 10.0.0.6 (10.0.0.6): 56 data bytes ^C --- 10.0.0.6 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
Significado
Como esperado, a operação de ping falha.
Confirme que os endereços de origem estão desbloqueados
Propósito
Use o comando para garantir que o ping dispositivo B não bloqueie o tráfego quando a verificação de RPF for desativada.
Ação
Desativar a verificação de RPF em uma das interfaces.
Reexame a operação de ping.
user@B> deactivate interfaces fe-1/1/1.6 family inet rpf-check user@A> ping 10.0.0.6 source 10.0.0.17 PING 10.0.0.2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=63 time=1.316 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.263 ms ^C --- 10.0.0.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.263/1.289/1.316/0.027 ms
Significado
Como esperado, a operação de ping tem sucesso.
