Módulo 9 — Logging, Monitorização e Troubleshooting

Módulo 9 — Logging, Monitorização e Troubleshooting

Objetivos de aprendizagem

• Distinguir os tipos de log do FortiGate (Traffic, Event, Security) e os respetivos destinos (memória, disco, FortiAnalyzer, syslog).


• Configurar logtraffic nas firewall policies e perceber o impacto de all vs utm vs disable.


• Usar o FortiView e os logs da GUI para análise em tempo real.


• Capturar tráfego com o packet sniffer (diagnose sniffer packet) e seguir o caminho de um pacote com o debug flow (diagnose debug flow).


• Inspecionar a tabela de sessões (diagnose sys session) e diagnosticar problemas de conectividade ligados a políticas, NAT, rotas e RPF.


• Avaliar os recursos do sistema (CPU, memória, conntrack) com get system performance status e diagnose sys top.

1. Tipos de log e destinos

O FortiOS produz três grandes famílias de logs. Traffic logs registam sessões que atravessam o firewall (origem, destino, política, bytes, ação). Event logs registam atividade do próprio sistema (admin, HA, VPN, routing, sistema). Security logs resultam dos security profiles (antivirus, web filter, IPS, application control) e só existem quando há inspeção UTM.

Cada família pode ser enviada para vários destinos em simultâneo, cada um com a sua própria severidade mínima:

• Memória — volátil, perde-se no reboot. Útil em VMs e modelos sem disco.


• Disco — persistente; nem todos os modelos têm. Permite relatórios locais.


• FortiAnalyzer / FortiManager — destino recomendado para retenção, correlação e relatórios centralizados.


• Syslog — para SIEM de terceiros.

config log memory setting

    set status enable

end



config log disk setting

    set status enable

    set diskfull overwrite

end



config log fortianalyzer setting

    set status enable

    set server 10.10.1.50

    set upload-option realtime

    set reliable enable

end



config log syslogd setting

    set status enable

    set server 10.10.1.60

    set port 514

    set facility local7

end

O filtro de severidade controla o volume. O nível escolhido inclui esse nível e todos os mais graves (a escala vai de emergency a debug):

config log fortianalyzer filter

    set severity information

    set forward-traffic enable

    set local-traffic disable

end

2. logtraffic nas firewall policies

Não há logging de tráfego sem o ativar na política. O campo logtraffic aceita três valores:

• all — regista todas as sessões aceites por aquela política (início e/ou fim).


• utm — regista apenas sessões em que um security profile gerou um evento. É o valor por defeito quando se aplica inspeção.


• disable — sem logging de tráfego nessa política.

config firewall policy

    edit 5

        set name "LAN-to-Internet"

        set srcintf "port2"

        set dstintf "port1"

        set srcaddr "LAN_subnet"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "ALL"

        set nat enable

        set logtraffic all

        set logtraffic-start enable

    end

end

A política implícita de negação (Implicit Deny, ID 0) também pode registar o tráfego bloqueado — útil para perceber o que está a ser descartado:

config firewall policy

    edit 0

        set logtraffic all

    end

end

3. FortiView e logs na GUI

O FortiView (em Dashboard > FortiView Monitors) é a vista visual em tempo real das sessões: por origem, destino, aplicação, política, país ou ameaça. Permite drill-down de uma origem até às sessões individuais e ao log que as gerou. Os monitores precisam de logs (memória, disco ou FortiAnalyzer) como fonte de dados. Em Log & Report consultam-se Forward Traffic, Local Traffic, eventos e logs de segurança, com filtros por campo.

4. Packet sniffer — diagnose sniffer packet

É o tcpdump do FortiGate. A sintaxe é diagnose sniffer packet <interface> '<filtro>' <verbosity> <count> <timestamp>. Usa any para todas as interfaces. Níveis de verbosity úteis: 4 (cabeçalho + interface), 6 (cabeçalho + payload + interface).

# Ver tráfego ICMP de/para 10.0.1.20 em todas as interfaces, com interface e timestamp

diagnose sniffer packet any 'host 10.0.1.20 and icmp' 4 0 a



# HTTPS para um destino específico, com payload

diagnose sniffer packet port1 'host 8.8.8.8 and tcp port 443' 6 10 a

O argumento de timestamp a dá hora absoluta; l usa o formato local. count a 0 captura indefinidamente (Ctrl+C para parar).

5. Debug flow — diagnose debug flow

Enquanto o sniffer mostra se o pacote chega, o debug flow mostra o que o FortiGate decide sobre ele: que rota escolheu, que política casou, se aplicou NAT, ou porque o descartou. É a ferramenta nº 1 para "porque é que este tráfego não passa".

diagnose debug reset

diagnose debug flow filter addr 10.0.1.20

diagnose debug flow filter proto 1

diagnose debug flow show function-name enable

diagnose debug flow show iprope enable

diagnose debug console timestamp enable

diagnose debug flow trace start 10

diagnose debug enable

Saída típica revela linhas como "find a route", "matched policy 5", "reverse path check fail, drop" ou "no matching policy, drop" — exatamente o que precisamos. No fim, limpar sempre:

diagnose debug flow trace stop

diagnose debug disable

diagnose debug reset

6. Tabela de sessões — diagnose sys session

Cada sessão ativa está na session table. Filtra-se primeiro e só depois se lista, conta ou limpa:

diagnose sys session filter dst 10.0.1.20

diagnose sys session filter proto 6

diagnose sys session list

diagnose sys session stat

# Apagar as sessões que correspondem ao filtro (força re-avaliação da política)

diagnose sys session clear

Na entrada de cada sessão lê-se o estado, a política aplicada (policy_id), o NAT em curso (hook=snat/dnat, par orgin/reply) e os timers. Sessões presas num estado antigo costumam ser sinal de mudança de política ou rota que não foi reavaliada — daí o clear.

7. Troubleshooting de conectividade

Quando o tráfego não passa, segue uma ordem fixa. O FortiGate avalia (1) rota e RPF, depois (2) política, depois (3) NAT e security profiles:

• Rotas: existe caminho para o destino?
  

  get router info routing-table all
  
  get router info routing-table details 10.0.1.20

  
  


• RPF (Reverse Path Forwarding): por defeito em modo strict, o FortiGate descarta um pacote se a melhor rota de volta para a origem não sair pela interface por onde o pacote entrou. É causa frequente de "drop" silencioso em topologias assimétricas/multi-WAN. Visível no debug flow como "reverse path check fail"; ajusta-se com set src-check disable na rota estática ou mudando o modo de RPF.


• Políticas: há uma política que case origem/destino/serviço/interfaces? A ordem importa (top-down).
  

  diagnose firewall iprope lookup 10.0.1.10 5000 8.8.8.8 443 6 port2

  
  


• NAT: confirma na sessão se o source NAT/destination NAT está a ser aplicado como esperado (campos snat/dnat no diagnose sys session list).

O combo decisivo é: sniffer (chega o pacote?) → debug flow (que decisão tomou?) → session (em que estado ficou?).

8. Recursos do sistema

Antes de culpar uma política, confirma que o equipamento não está saturado. get system performance status dá um retrato rápido de CPU, memória, sessões e uptime:

get system performance status

Saída (excerto) com CPU por núcleo, uso de memória e contagem de sessões. Quando a memória sobe, o FortiGate entra em conserve mode e começa a fazer failopen ou fail-close da inspeção — sinal de sobrecarga.

Para ver que processo consome recursos, usa o "top" do FortiOS (R para ordenar por memória, q para sair):

diagnose sys top 5 20

get system performance top   # alias comum em alguns modelos

Cada linha mostra o processo, o PID, o estado (R/S/D), a %CPU e a %memória. Picos persistentes em processos como ipsengine ou scanunitd apontam para inspeção UTM pesada.

Lab associado

Põe em prática a captura de pacotes, o debug flow e a análise da tabela de sessões para diagnosticar uma falha de conectividade real:

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