Curso Completo de Preparação para Certificação Fortinet FCP Network Security Text Lesson

Módulo 3 — Firewall Policies e NAT

Preparação FCP FortiGate 7.6: aulas + 10 labs práticos + exame final, com nota no certificado.

Módulo 3 — Firewall Policies e NAT

Objetivos de aprendizagem

Compreender o papel das firewall policies no FortiGate e a lógica de correspondência por ordem (top-down, first-match).

Criar e reutilizar objetos: addresses, address groups, services e schedules.

Distinguir o modo NGFW policy-based do NGFW profile-based e perceber quando usar cada um.

Configurar source NAT (SNAT) com IP pools e overload, e destination NAT (DNAT) com VIP.

Entender o conceito de Central NAT e como difere do NAT por política.

Diagnosticar a correspondência de políticas com diagnose firewall iprope lookup e configurar logging por política.

1. O que é uma firewall policy

A firewall policy é a regra que determina se o tráfego entre duas interfaces (ou zonas) é permitido, negado, e que inspeção/transformação sofre. Cada política define, no mínimo, um conjunto de critérios de correspondência — interface de entrada, interface de saída, origem, destino, serviço, schedule — e uma ação (accept ou deny). Em políticas accept ativam-se ainda NAT, security profiles, logging e moldagem de tráfego.

No FortiOS 7.6, sem uma política explícita que permita o fluxo, o tráfego é descartado pela implicit deny (a política oculta de ID 0 no fim da lista). Tudo o que não for explicitamente permitido é bloqueado.

2. Ordem e correspondência das políticas

O FortiGate avalia as políticas de cima para baixo dentro do mesmo par de interfaces e aplica a primeira que corresponde (first-match). Assim que há correspondência, a avaliação pára — as políticas seguintes nunca são consultadas para esse fluxo. Por isso, regras mais específicas devem ficar acima de regras mais genéricas; caso contrário, a regra genérica "captura" o tráfego primeiro.

A ordem é controlada pela sequence (posição na lista), não pelo policy ID. Mover uma política altera a sequência sem mudar o ID.

config firewall policy

    edit 0

        set name "LAN-to-WAN"

        set srcintf "port3"

        set dstintf "port1"

        set srcaddr "LAN_NET"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "HTTP" "HTTPS" "DNS"

        set nat enable

        set logtraffic all

    next

end



# Reordenar: colocar a política 5 antes da política 2

config firewall policy

    move 5 before 2

end

Nota. Quando se cria uma política com edit 0, o FortiGate atribui automaticamente o próximo ID livre. O policy ID é apenas um identificador estável; a ordem de avaliação depende sempre da posição na lista.

3. Objetos: addresses, groups, services, schedules

Objetos são blocos reutilizáveis que tornam as políticas legíveis e fáceis de manter. Em vez de escrever sub-redes ou portas diretamente na política, referencia-se um objeto nomeado. Alterar o objeto propaga a mudança a todas as políticas que o usam.

Addresses — sub-redes, ranges, FQDN, geografia, etc.

Address groups — agrupam vários addresses para referência única.

Services — protocolo + porta(s); existem serviços pré-definidos (HTTP, HTTPS, DNS) e personalizados.

Schedules — janelas temporais (recurring ou one-time) que limitam quando a política está ativa.

config firewall address

    edit "LAN_NET"

        set subnet 10.0.10.0 255.255.255.0

    next

    edit "Servidor_Web"

        set subnet 10.0.10.50 255.255.255.255

    next

end



config firewall addrgrp

    edit "Servidores_Internos"

        set member "Servidor_Web" "LAN_NET"

    next

end



config firewall service custom

    edit "App_TCP_8443"

        set tcp-portrange 8443

    next

end



config firewall schedule recurring

    edit "Horario_Laboral"

        set day monday tuesday wednesday thursday friday

        set start 08:00

        set end 18:00

    next

end

4. NGFW policy-based vs profile-based

O FortiGate opera num de dois modos de inspeção, definido por VDOM:

Profile-based (predefinição): cada política accept recebe os seus security profiles (AntiVirus, Web Filter, Application Control, IPS, etc.). A inspeção aplicada depende da política que correspondeu ao fluxo.

Policy-based: a application control e o URL filtering são avaliados centralmente, antes da correspondência da security policy, permitindo escrever regras diretamente por aplicação/categoria. Requer obrigatoriamente Central NAT e inspeção SSL definida ao nível do modo, não da política.

config system settings

    set ngfw-mode policy-based

    set policy-offload-level dos-offload

end

Recomendação. Para a maioria das implementações FCP, o modo profile-based é o predefinido e o mais flexível política-a-política. Usa policy-based quando a gestão por aplicação/categoria centralizada compensar a obrigatoriedade de Central NAT.

5. Source NAT: IP pools e overload

O SNAT traduz o endereço de origem do tráfego que sai (tipicamente da LAN para a Internet). Quando se ativa set nat enable numa política sem IP pool, o FortiGate usa o IP da interface de saída (use outgoing interface address). Para usar outro endereço ou um conjunto, define-se um IP pool.

O tipo overload é PAT (Port Address Translation) — muitos hosts internos partilham um ou poucos IPs públicos, distinguidos pela porta de origem. É o equivalente ao "NAT clássico" de saída.

config firewall ippool

    edit "Pool_Saida"

        set type overload

        set startip 203.0.113.10

        set endip 203.0.113.10

    next

end



config firewall policy

    edit 1

        set srcintf "port3"

        set dstintf "port1"

        set srcaddr "LAN_NET"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "ALL"

        set nat enable

        set ippool enable

        set poolname "Pool_Saida"

    next

end

Outros tipos de pool: one-to-one (mapeamento fixo 1:1, sem PAT), fixed-port-range e port-block-allocation (atribuem blocos de portas por host, úteis para CGNAT e rastreabilidade).

6. Destination NAT com VIP

O DNAT publica um serviço interno para o exterior. Cria-se um Virtual IP (VIP) que mapeia um IP externo (e opcionalmente uma porta) para o IP/porta interno; depois referencia-se o VIP como destino numa política de entrada. Não se ativa nat na política de DNAT — o VIP já faz a tradução do destino.

config firewall vip

    edit "VIP_Web"

        set extip 203.0.113.20

        set mappedip "10.0.10.50"

        set extintf "port1"

        set portforward enable

        set protocol tcp

        set extport 443

        set mappedport 8443

    next

end



config firewall policy

    edit 2

        set name "WAN-to-Web"

        set srcintf "port1"

        set dstintf "port3"

        set srcaddr "all"

        set dstaddr "VIP_Web"

        set action accept

        set schedule "always"

        set service "HTTPS"

        set logtraffic all

    next

end

Importante. No dstaddr usa-se o VIP, não o IP interno real. O service da política deve corresponder à porta externa do VIP (aqui 443), pois a tradução de porta ocorre depois da correspondência da política.

7. Central NAT

No modo predefinido, o NAT é configurado dentro de cada política (NAT por política). Com Central NAT ativo, o SNAT e o DNAT passam a ser geridos em tabelas separadas (Central SNAT e DNAT & Virtual IPs), independentes das políticas de segurança. As políticas tratam só de permitir/negar; a tradução é resolvida pelas regras centrais por ordem de correspondência. É obrigatório no modo policy-based.

config system settings

    set central-nat enable

end



config firewall central-snat-map

    edit 1

        set srcintf "port3"

        set dstintf "port1"

        set orig-addr "LAN_NET"

        set dst-addr "all"

        set nat-ippool "Pool_Saida"

        set protocol 6

    next

end

8. Policy lookup e logging por política

Para confirmar qual política tratará um fluxo específico — sem gerar tráfego real — usa-se a ferramenta de policy lookup. A GUI tem o "Policy Lookup"; na CLI, o motor de correspondência é o iprope.

# Qual política corresponde a este fluxo?

diagnose firewall iprope lookup 10.0.10.50 51000 203.0.113.20 443 6 port3



# Listar a tabela de políticas e contadores de acertos

diagnose firewall iprope list

get firewall policy

O logging define-se por política com logtraffic: all (regista início e fim de sessão), utm (só quando um security profile dispara um evento) ou disable. Para tráfego negado, é útil ativar o registo na implicit deny de forma a ver o que está a ser bloqueado.

config firewall policy

    edit 1

        set logtraffic all

        set logtraffic-start enable

    next

end

Erros comuns

Ordem errada das políticas. Colocar uma regra genérica (ex.: service ALL) acima de uma específica faz com que a específica nunca seja avaliada (first-match).

Confundir policy ID com sequência. A avaliação segue a posição na lista; usa move para reordenar, não a renumeração de IDs.

Ativar NAT numa política de DNAT/VIP. O VIP já traduz o destino; ativar nat aplica SNAT desnecessário e pode quebrar o fluxo de retorno.

Service na política de VIP a apontar para a porta interna. Deve corresponder à extport (porta externa), não à mappedport.

Esquecer que Central NAT desliga o NAT por política. Com Central NAT ativo, o set nat enable da política deixa de ser usado; a tradução vem do central-snat-map.

Não rever a implicit deny. Tráfego "que não funciona" sem log nenhum costuma estar a cair na deny oculta — ativar o seu registo revela a causa.

Lab associado

Aplica estes conceitos num FortiGate VM 7.6: cria objetos, escreve políticas LAN→WAN com SNAT por IP pool overload, publica um servidor interno com VIP/DNAT, experimenta o Central NAT e valida tudo com diagnose firewall iprope lookup e logs por política.

🧪 Abrir este Lab na plataforma LAB
Abre com sessão automática (SSO). Incluído no curso — sem custo de créditos.

Módulo 3 — Firewall Policies e NAT