Reverse Path Forwarding (RPF) no Firewall Fortigate

Já parou para pensar em como o Firewall Fortigate mitiga um ataque de Spoofing de IP (no qual é uma técnica que cyber criminosos utilizam forjando um IP de origem para obter acesso não autorizado à ambientes de TI), permitindo assim a execução de ações maliciosas?

Essas ações maliciosas podem variar de infecção dos dispositivos com malware, roubo de dados sensíveis e também interrupções de servidores, podendo gerar danos irreversíveis às organizações.

Mas sem enrolações, primeiramente pretendo repassar o básico do que realmente precisa saber, principalmente se você pretende realizar a prova FCP - FortiGate 7.4 Administrator da Fortinet (que substitui a NSE 4), onde é um assunto está previsto na prova no tópico de Routing. Após, para quem se interessa, irei detalhar um pouco mais com o uso de Laboratório.

O que é o Reverse Path Forwarding?

O RPF é um mecanismo de segurança que protege contra ataques de Anti Spoofing (conforme falado antes, falsificação de IP). O RFP verificará o endereço IP de origem em busca de uma rota válida para este IP (isso na tabela de roteamento do Fortigate). Essa checagem é feita somente no primeiro pacote de uma nova sessão criada (e não no reply). A ação que o Firewall irá tomar com este pacote dependerá do Modo RPF configurado.

No Fortigate existem dois modos do RPF, o Feasible Mode (que é o default) e o Strict Mode.

No Feasible Mode, o pacote é aceito desde que haja uma rota ativa para o IP de origem através de alguma interface de entrada (ingress interface). Não é apenas a best route que é considerada, todas as interfaces e todas as rotas são checadas durante o RPF check.

No Strict Mode, apenas as rotas da interface do tráfego de entrada será checada (best route), ou seja, o pacote será dropado caso a best route do IP de origem do pacote não seja a própria interface ingress.

Em resumo, digamos que chegue um pacote com o IP de origem 10.10.10.1/24 na porta 1 do Fortigate, considerando que a tabela de roteamento do Firewall esteja assim:

Routing table for VRF=0

S* 0.0.0.0/0 [5/0] via 192.168.100.1, port1, [1/0]

S 10.10.10.0/24 [10/0] via 172.16.3.2, port3, [1/0]

No Feasible Mode ele irá aceitar esse pacote, pois no momento que o Fortigate faz um route lookup para o IP de origem, tem uma rota válida para esta rede, por mais que a rota para 10.10.10.0/24 esteja ativa em outra interface (port3) que não seja a interface de ingress do tráfego.

No Strict Mode, o Firewall irá dropar o pacote, pois a interface de ingress do tráfego é a port1, e a best route para a rede 10.10.10.0/24 é a port3, independentemente da rota default na porta 1.

Como ativar o Strict Mode?

via CLI:

	# config system settings
	# set strict-src-check enable

Por default, ele vem como "set strict-src-check disable", que é o Feasible Mode.

Como desativar o RPF no Fortigate?

Dependendo do escopo da sua rede, talvez seja necessário desativar o RPF.

Como por exemplo num caso de roteamento assimétrico, o pacote chegar por uma interface e sair por outra, devido a rotas com custos diferentes.

São duas as formas de desativar o RPF:

1 - Ativando o roteamento assimétrico:

via CLI:

# config system settings
# set asymroute enable

2 - Desativando o RPF check direto na interface de ingress do tráfego (que por default vem ativo): via CLI:

# config system interface
# edit "port x"
# set src-check disable

Vamos finalizar com um exemplo de uma questão sample do NSE 4, onde o enunciado diz que um usuário que está no IP 192.168.32.15 está tentando acessar o web server que possuí o IP 172.16.32.254:

OBS.: consideramos o "Loose RPF" como o default "Feasible Mode"

Como o RPF irá atuar neste caso?

Neste caso, a rota default do Firewall está apontando para a port1, que é a porta que será gerado o tráfego de entrada que vem do user 192.168.32.15. Como é uma rota default, e não há mais nenhuma outra rota mais específica para 192.168.32.15 na tabela de roteamento, o Firewall irá aceitar o tráfego tanto no Feasible Mode, quanto no Strict Mode. Portanto o correto é a A e B.

Mas em que cenário o pacote seria aceito em Feasible Mode e dropado no Strict Mode?

Utilizando deste mesmo exemplo, digamos que um pacote IP que foi spoofed com a origem 172.16.32.10 chega na port1 do Firewall. No Feasible Mode, conforme falamos acima, por mais que a best route da rede 172.16.32.10 é via port2, ele vai aceitar o tráfego vindo desta rede na port1.

No Strict Mode o pacote seria dropado, pois a best route para a rede 172.16.32.0/24 é a port2 (rota diretamente conectada), e a interface ingress do tráfego foi a port1.

Exemplo Prático:

Para quem deseja ir em frente sobre o assunto, vamos à um exemplo prático com a utilização de um Laboratório, com a seguinte topologia:

A comunicação ocorrerá da seguinte forma: o "CPE" cujo IP é 10.1.1.2 irá mandar uma sessão telnet (porta 23) para o IP 200.200.200.2 (que é o Firewall). No Firewall, possuí um VIP configurado, para redirecionar todo o pacote que chega na port2 do Firewall, com destino a porta 23 (telnet), irá encaminhar para o Server 192.168.10.2. Configuração VIP:

Conforme topologia, a rede 192.168.10.0/24 está atrás do "SW-LAN", onde no Firewall há uma rota com dst 192.168.10.0/24 e gw 10.10.10.2 para o Firewall alcançar esta rede.

Mas e o telnet a partir do "CPE" para o "Server" irá funcionar? O RPF não irá dropar?

A comunicação irá funcionar tanto no Feasible Mode quanto no Strict Mode. O IP de origem do tráfego será o IP do "CPE" 10.1.1.2, e como a rota default do Firewall está apontando para a port2, que será a interface ingress do tráfego, ela acaba sendo a best route para a rede 10.1.1.0/30, pois não há outra rota na tabela de roteamento para esta rede.

Simulando um ataque de IP Spoofing:

Agora vamos simular um ataque de IP Spoofing e analisar o comportamento do RPF. Para isso, foi criado um NAT no router denominado "ROUTER-SPOOFING-ATTACK", utilizando o IP 192.168.10.3/24 como outside do NAT, ou seja, a mesma rede do "Server". Configuração do "ROUTER-SPOOFING-ATTACK":

interface Ethernet0/2
 ip address 192.168.10.3 255.255.255.0 secondary <<- ip outside NAT
 ip address 200.200.200.1 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
end
!
ip nat inside source static 10.1.1.2 192.168.10.3  <-- static NAT

Portanto, todo o tráfego que vier do "CPE" irá ser mascarado para o IP 192.168.10.3. Agora digamos que por algum motivo, na configuração da policy do Firewall que permite essa comunicação com o "Server", o NAT esteja habilitado, conforme abaixo:

Como o RPF irá agir em cada caso?

Feasible Mode: irá permitir o tráfego, pois no route lookup o Firewall identifica que há uma rota para a rede 192.168.10.0/24 via port1. Por mais que o tráfego de entrada seja na port2, no Feasible Mode não é necessário que seja a best route (que nesse caso a best route é via port1).

Podemos observar que a porta foi "open" entre o "CPE" e o "Server", estabelecendo assim a comunicação.

Strict Mode: agora configurando o RPF no Strict Mode, o Firewall irá dropar o tráfego, pois no route lookup o Firewall identifica que há uma rota para a rede 192.168.10.0/24 via port1, que no caso é a best route, e o tráfego de entrada está sendo via port2.

Realizando um debug flow packet, podemos observar que o pacote é dropado nos logs, não estabelecendo a comunicação. No debug flow packet, podemos analisar com o retorno "reverse path check fail (by strict-src-check)".

Acredito que com esse conteúdo conseguimos abordar em grande parte o conhecimento necessário sobre o RPF. E aí, o que você achou? Ficou fácil de entender? Teria algo a acrescentar?

Caso tenha alguma contribuição ou sugestão, comenta aqui!

Link's Úteis:

Technical Note : Reverse Path Forwarding ... - Fortinet Community

Routing concepts | FortiGate / FortiOS 7.4.3 | Fortinet Document Library