Como monitorar um FortiGate com o PRTG: o passo a passo

O chamado nunca chega escrito como “o firewall está com problema”. Chega como “a internet está lenta”, “o sistema caiu de novo”, “o pessoal de fora não consegue conectar”. Alguém dá um ping no gateway, o gateway responde, e a caçada começa em todo lugar menos no equipamento por onde aquele tráfego todo estava passando.

Um firewall raramente morre de forma limpa. Ele satura. A memória enche, a tabela de sessões estoura, a inspeção de conteúdo começa a engasgar, e nada disso aparece para quem olha só se o equipamento responde. Responder, ele responde.

Este guia mostra como sair dessa cegueira em um FortiGate usando o PRTG, com o passo a passo de ponta a ponta: o que configurar no firewall, o que adicionar no monitoramento e como calibrar para o alerta valer alguma coisa. Tudo o que está aqui funciona na versão gratuita.

O que dá para enxergar num FortiGate

Antes de configurar, vale saber o que você está indo buscar. O equipamento entrega duas famílias de informação por dois caminhos diferentes, e é a soma das duas que fecha a visibilidade.

Conserve mode. O FortiOS tem um mecanismo de autopreservação com esse nome. Quando a memória livre cai abaixo de um limite, o equipamento entra nesse estado e passa a proteger a si mesmo, recusando novas sessões que exigem inspeção por proxy, como antivírus e filtro web, conforme a configuração. O tráfego simples continua passando. Para o usuário, isso não parece um firewall em apuros: parece um site que não abre, um download que trava na metade, um anexo que não desce.

Memória e CPU. A memória é o que leva ao conserve mode, e sobe de forma lenta o bastante para ser o melhor alerta antecipado do equipamento. Já a CPU pede cuidado na leitura, porque pico de CPU em firewall é rotina. O que interessa é CPU alta sustentada, não o pico de dois minutos às 9h.

Tabela de sessões. O número de conexões simultâneas que o equipamento está mantendo. Cada modelo tem um teto, e chegar perto dele derruba conexão nova sem derrubar as antigas, o que produz o sintoma mais confuso possível: quem já estava conectado continua trabalhando, quem tenta entrar agora não consegue, e ninguém acredita que seja a mesma causa.

Túneis VPN. Numa empresa com filial ou home office, é a operação inteira. Um túnel IPsec que cai às 3h e volta às 3h04 não gera chamado nenhum, mas explica três integrações que falharam no relatório do mês.

Tráfego por interface. Quanto passa em cada link, separado por entrada e saída. É o que responde se a WAN secundária assumiu de madrugada, se o link contratado está saturando no horário de pico ou se aquele backup noturno está comendo a banda inteira.

Saúde física do equipamento. Temperatura, rotação de ventoinha e estado das fontes, nos modelos que têm esses sensores. Firewall em rack apertado morre de calor antes de morrer de carga, e esse é o tipo de falha que avisa com dias de antecedência.

Cluster de HA. Se o par está sincronizado e quem está ativo. Um failover silencioso é bom sinal no momento em que acontece e péssimo sinal se ninguém percebeu, porque a empresa passou a operar sem redundância sem saber.

Disco e logs. O espaço da mídia onde o FortiGate grava log. Disco cheio no firewall não derruba o tráfego, mas faz você perder justamente o registro de que precisaria no dia do incidente.

Cada coisa vem por um caminho

Os dois sensores nativos do PRTG falam com o FortiGate pela REST API do FortiOS e cobrem a saúde do equipamento e o resumo das VPNs. Todo o resto vem por SNMP, lendo a FORTINET-FORTIGATE-MIB e a MIB padrão de interfaces. Nenhum dos dois caminhos substitui o outro.

O que você quer ver	De onde vem
Conserve mode, CPU, memória, sessões, taxa de sessões, uptime	Sensor nativo FortiGate System Statistics (REST API)
Clientes SSL VPN e contagem de túneis IPsec no ar e fora	Sensor nativo FortiGate VPN Overview (REST API)
Tráfego de cada interface, entrada e saída	SNMP, sensor SNMP Traffic por interface
Estado de cada túnel IPsec, individualizado	SNMP, tabela de túneis da MIB do FortiGate
Temperatura, ventoinha e fontes	SNMP, tabela de sensores de hardware
Estado do cluster de HA e sincronismo	SNMP, grupo de HA da MIB
Uso de disco e de log	SNMP, grupo de sistema da MIB
Contadores de antivírus, IPS e políticas	SNMP, grupos correspondentes da MIB

O passo a passo abaixo monta os dois caminhos na ordem: primeiro a API, que é o que dá o diagnóstico de saúde, depois o SNMP, que é o que dá o resto.

Antes de começar

Você vai precisar de acesso administrativo ao FortiGate, do endereço IP do servidor ou probe do PRTG que vai consultar o equipamento, e do acesso HTTPS liberado na interface do firewall que fala com esse servidor. Os passos abaixo seguem o FortiOS 7.x; em versões anteriores os menus mudam de lugar, mas a lógica é a mesma.

Ainda não tem o PRTG? A versão gratuita libera 100 sensores de forma permanente, sem prazo de validade, e um FortiGate monitorado com cuidado ocupa menos de dez deles. Dá para instalar, configurar este guia inteiro e ver o resultado sem gastar nada — o caminho da instalação está em como instalar o PRTG e monitorar a rede em 5 minutos, e a lógica de como distribuir os 100 sensores entre o que é crítico está em PRTG gratuito: como montar seu monitoramento com 100 sensores.

Passo 1: criar o usuário de API somente leitura no FortiGate

Os dois sensores nativos do PRTG falam com o FortiGate pela REST API do FortiOS, e para isso precisam de um token. Esse token nasce de um usuário específico, que não deve ser o seu admin.

Comece pelo perfil de permissão. Em System > Admin Profiles > Create New, crie um perfil chamado algo como prtg_readonly e deixe todas as permissões em Read (ou None no que não interessa). Monitoramento lê, não escreve, e um perfil somente leitura garante que um token vazado não vire uma mudança de regra no firewall.

Depois vá em System > Administrators > Create New > REST API Admin e preencha:

• Username: prtg_api (ou o padrão de nomenclatura da sua empresa)
• Administrator Profile: o perfil somente leitura criado acima
• PKI Group: desabilitado, se você não usa certificados de cliente
• Trusted Hosts: o IP do servidor PRTG com máscara /32

O campo de trusted hosts é o mais importante da tela. Sem ele, o token funciona de qualquer origem que alcance a interface de administração. Com ele, só o seu servidor de monitoramento consegue usá-lo.

Ao confirmar, o FortiGate gera e exibe o token de API uma única vez. Copie antes de fechar a janela: não há como visualizá-lo de novo, só gerar outro.

Passo 2: criar o dispositivo e guardar o token no PRTG

No PRTG, um firewall é um dispositivo dentro de um grupo. Se ele ainda não existe, abra o grupo onde ele deve morar, use Add Device e preencha o Device Name e o IPv4 Address/DNS Name com o IP de gerenciamento do FortiGate. Nada mais é obrigatório nessa tela.

Com o dispositivo criado, abra a aba Settings dele e desça até a seção Credentials for FortiGate. Ela vem marcada como inherit from seguido do nome do grupo pai: desmarque essa herança para liberar os campos. São dois.

API Token recebe o token que o FortiGate gerou no Passo 1.

Port é o campo que derruba a maioria das instalações e que nenhum tutorial menciona. Ele precisa ser a porta HTTPS de administração do seu FortiGate, não a porta do serviço monitorado. O padrão do PRTG é 443, mas muita empresa troca a porta de administração do firewall justamente por segurança. Num ambiente que monitoramos, esse campo está em 9999. Se o token estiver correto e o sensor mesmo assim falhar na criação, é quase sempre aqui.

Se você monitora vários FortiGate de clientes diferentes, inverta a lógica: ponha a credencial no grupo que representa aquele cliente e deixe os dispositivos herdarem. O token mora em um lugar só, e trocá-lo depois não vira caça a sensores espalhados.

Passo 3: adicionar os dois sensores nativos

Com a credencial no lugar, clique com o botão direito no dispositivo e escolha Add Sensor (o mesmo existe em Sensors > Add Sensor, e aí você seleciona o dispositivo antes).

A tela de escolha oferece três filtros — Monitor What?, Target System Type? e Technology Used? —, mas o caminho curto é a caixa de busca: digite FortiGate e os dois tipos aparecem.

FortiGate System Statistics. Um sensor só, que entrega conserve mode, uso de CPU, uso de memória, total de sessões, taxa de sessões e uptime. O canal de conserve mode usa um lookup: inativo aparece como Up, ativo aparece como Down. É esse o canal que você quer em qualquer painel de firewall.

FortiGate VPN Overview. Entrega a quantidade de clientes SSL VPN conectados e a contagem de túneis IPsec no ar e fora. Na tela de configuração ele aceita dois ajustes úteis: o Virtual Domain (VDOM) a consultar, se o equipamento estiver dividido em domínios virtuais, e Ignored VPNs, uma por linha, respeitando maiúsculas e minúsculas, para não alertar por túneis de teste ou de contingência desligados.

Ainda na tela de configuração, ajuste o Scanning Interval para 5 minutos, que é o intervalo recomendado pela Paessler para os dois. Um minuto não avisa mais cedo de nada que importe nesse equipamento e só multiplica requisição. Logo abaixo fica If a Sensor Scan Fails, e o padrão — colocar em aviso por um intervalo antes de declarar down — é o que evita alerta por uma consulta perdida.

Um detalhe que economiza tempo: tutoriais antigos em inglês mandam habilitar recursos experimentais em Setup > System Administration > Monitoring antes de achar esses sensores. Isso valia para versões antigas do PRTG, quando os dois eram beta. No manual atual eles não aparecem mais com essa marcação, e só vale conferir essa opção se a busca não retornar nada.

Passo 4: ligar o SNMP para ver o tráfego das interfaces

Aqui está a parte que a maioria dos tutoriais não conta: os dois sensores nativos não medem tráfego por interface. Nenhum dos dois responde “quanto está passando no link principal agora” ou “a WAN secundária assumiu ontem à noite?”. Para isso, o caminho é SNMP, e são dois lados de novo.

No FortiGate

Habilite o SNMP em System > SNMP. Use SNMPv3, com autenticação e criptografia, em vez de v2c: a community do v2c trafega em texto claro, e num equipamento de borda isso não se justifica. Crie o usuário com nível de segurança auth-priv e anote as duas senhas, porque você vai repeti-las do outro lado.

Pela CLI, o equivalente fica assim (a sintaxe varia um pouco entre versões do FortiOS, confira na sua):

config system snmp sysinfo
    set status enable
end

config system snmp user
    edit "prtg_v3"
        set security-level auth-priv
        set auth-proto sha256
        set auth-pwd <senha-de-autenticacao>
        set priv-proto aes256
        set priv-pwd <senha-de-criptografia>
        set queries enable
    next
end

config system interface
    edit "port1"
        append allowaccess snmp
    next
end

Troque port1 pela interface por onde o PRTG alcança o firewall. Sem esse último bloco, o SNMP fica habilitado no equipamento e mesmo assim não responde.

No PRTG

Volte à aba Settings do dispositivo, agora na seção Credentials for SNMP Devices, e desmarque a herança. Em SNMP Version, troque o padrão SNMP v2c por SNMP v3. A tela muda e passa a pedir os campos do usuário que você acabou de criar: User Name, Authentication Type (o sha256 do comando acima), Password, Encryption Type (o aes256), Data Encryption Key e Context Name, que fica vazio no FortiGate. Confira ainda SNMP Port, normalmente 161, e o Timeout (Sec.).

Com a credencial salva, rode um Auto-Discovery no dispositivo: clique com o botão direito nele e escolha a opção de descoberta. O PRTG consulta o firewall e lista as interfaces que encontrou. Não aceite todas — uma interface por link de internet, uma para a rede interna principal e as de túnel que sustentam filial costumam bastar. Cada interface marcada vira um sensor SNMP Traffic com canais de entrada, saída e total.

Se preferir manual, é o mesmo Add Sensor, buscando por SNMP Traffic; o próprio assistente lista as interfaces disponíveis para seleção.

Passo 5: calibrar limiares e dependências

Com os sensores no ar, o monitoramento ainda não está pronto. Falta a parte que decide se ele vai ajudar ou virar ruído.

O sensor de System Statistics já vem com limiares de fábrica: erro em 90% de CPU, erro em 88% e aviso em 82% de memória. São pontos de partida razoáveis, mas o valor certo depende do que aquele equipamento faz. Um FortiGate com inspeção SSL ligada e trinta regras de UTM opera naturalmente mais alto que um fazendo roteamento simples, e vai disparar alerta o dia inteiro nos 90% padrão.

Para mudar, abra a aba Overview do sensor e clique no ícone de engrenagem abaixo do medidor do canal que você quer ajustar. Na tela de edição do canal, marque Enable alerting based on limits e preencha Upper Warning Limit e Upper Error Limit com os valores que o seu histórico justifica. Os campos Warning Limit Message e Error Limit Message valem o minuto que custam: é o texto que chega junto do alerta, e “memória acima do normal, risco de conserve mode” poupa muita investigação às três da manhã.

O conserve mode é a exceção: é binário e não se calibra. Se ativou, é incidente.

Falta a dependência. Quando o firewall satura ou cai, tudo que está atrás dele fica vermelho junto, e uma única causa vira quarenta notificações simultâneas. Na aba Settings do dispositivo, vá até Schedules, Dependencies, and Maintenance Window, desmarque a herança e mude o Dependency Type para Select a sensor. No campo Dependency, aponte o sensor de Ping do próprio firewall. Se o ping cair, os demais sensores entram em paused by dependency em vez de alertar, e sobra um alerta em vez de quarenta. O Dependency Delay (Sec.) segura a retomada por alguns segundos depois que o ping volta, para o equipamento respirar antes de todo mundo consultar de novo.

É o desenho que detalhamos em dependências e análise de causa raiz no monitoramento, e a calibragem dos limiares segue a mesma lógica de alertas inteligentes no PRTG.

Num FortiGate que monitoramos, a tabela de sessões marca pouco mais de mil conexões simultâneas num momento comum de expediente. O máximo registrado no histórico do mesmo canal passa de vinte mil. Nenhum dos dois números significa qualquer coisa sozinho: o primeiro só é “normal” porque existe o segundo para comparar, e o segundo só vira pergunta — campanha de vendas, varredura, máquina infectada? — porque alguém tinha o histórico para olhar. É por isso que limiar de sessões não se copia de manual; sai do comportamento do próprio equipamento.

Quantos sensores isso consome

Fechando a conta do que foi configurado: um sensor de ping, um FortiGate System Statistics, um FortiGate VPN Overview e de dois a quatro sensores SNMP de tráfego, conforme as interfaces que importam. Entre cinco e sete sensores para um firewall com visibilidade de verdade.

Cabe com folga nos 100 da versão gratuita, e é uma das melhores relações entre sensor gasto e problema evitado em qualquer ambiente de PME.

Onde o painel ainda engana

Duas armadilhas sobrevivem mesmo depois de tudo configurado, e vale conhecê-las antes de confiar no verde da tela.

A primeira: túnel “up” não significa tráfego passando. A fase 2 do IPsec pode estar estabelecida com a rota do outro lado quebrada, e o contador de túneis no ar vai dizer que está tudo bem enquanto o ERP da filial não responde. O sensor de VPN confirma que o túnel existe. Quem confirma que ele serve para alguma coisa é um sensor apontado para um serviço do outro lado do túnel.

A segunda é derivada: o sensor nativo conta túneis, sem dizer qual deles caiu. Com dois túneis, o número resolve. Com quinze, “14 up, 1 down” vira investigação manual às três da manhã. Ambientes com muitas filiais precisam de sensores individuais por túnel, o que muda a conta de sensores do tópico anterior.

Nada disso é exclusivo da Fortinet. Um SonicWall, um pfSense ou um roteador de operadora têm os mesmos pontos cegos com outros nomes, e quando a suspeita recai sobre o link em si, a leitura correta está em como monitorar o link de internet e provar a queda.

Quando vale passar isso para frente

Configurar os sensores é a parte de meia hora. O que consome tempo depois é o resto: revisar limiar quando o ambiente muda, investigar o alerta às três da manhã, entender se aquele pico de sessões foi campanha de vendas ou máquina infectada, manter a documentação de qual token está em qual cliente.

É esse trabalho que a Global Data, empresa de TI em São Paulo, assume como Gold Partner Paessler no monitoramento com PRTG: do dimensionamento e da calibragem inicial à operação contínua. Quando o ambiente precisa de olhos fora do horário comercial e de alguém que responda, ele vira o nosso monitoramento e NOC 24x7.

O ponto

Se o seu monitoramento de firewall hoje é um ping, ele responde à única pergunta que o firewall quase nunca faz. Comece pelo conserve mode e pela memória, acrescente o tráfego por interface via SNMP, individualize os túneis que sustentam filial e deixe o alerta de disponibilidade em último lugar. Quando ele dispara, a empresa já parou há dez minutos.

Perguntas frequentes

Como monitorar um FortiGate com o PRTG?

Crie no FortiGate um usuário de API REST com perfil somente leitura e trusted host restrito ao IP do servidor PRTG, copie o token gerado e cole-o nas credenciais do dispositivo no PRTG. Depois adicione os sensores FortiGate System Statistics e FortiGate VPN Overview, e complemente com sensores SNMP de tráfego para as interfaces que importam.

O que é o conserve mode do FortiGate?

É o modo de autopreservação que o FortiOS ativa quando a memória livre cai abaixo de um limite. Nele, o equipamento passa a recusar sessões que dependem de inspeção por proxy, como antivírus e filtro web. O tráfego simples continua passando, o que faz o problema parecer lentidão de internet em vez de falha do firewall.

Dá para monitorar o FortiGate na versão gratuita do PRTG?

Sim. Os sensores nativos de FortiGate e os sensores SNMP de tráfego funcionam na licença gratuita de 100 sensores. Um FortiGate bem monitorado consome de cinco a sete sensores, incluindo ping, saúde do equipamento, VPN e o tráfego das interfaces principais.

Os sensores nativos monitoram o tráfego das interfaces?

Não. Eles cobrem a saúde do equipamento e o estado das VPNs, não a banda. Para acompanhar consumo por interface, uso da WAN principal e secundária ou a troca de link, é preciso adicionar sensores SNMP de tráfego, um por interface relevante.

Preciso liberar acesso administrativo total no firewall?

Não, e não é recomendável. O usuário de API deve ter perfil somente leitura e trusted hosts restritos ao endereço do servidor de monitoramento. No SNMP, use v3 com autenticação e criptografia, evitando a community em texto claro do v2c.

Vocês configuram o monitoramento do firewall da nossa empresa?

Sim. Avaliamos o ambiente, definimos o que monitorar em cada equipamento de borda, calibramos os limiares para a realidade daquela operação e desenhamos as dependências e o escalonamento dos alertas. Solicite uma avaliação do seu ambiente para começar.