17 de julho de 2026 · Fortinet · Perimeter · Schwachstellenmanagement · IT-Sicherheit

Quando a firewall aplica o próprio patch: upgrades do FortiOS

O FortiOS atualiza-se automaticamente e, em certos casos, até de forma forçada. O que desencadeia os upgrades, que exceções valem e como pode reagir.

Uma firewall reinicia durante a noite, de manhã está a correr outra versão de firmware, e ninguém da equipa instalou qualquer atualização. Em sistemas FortiGate, este é um comportamento documentado. No blog técnico da boll foi publicado em 17 de julho de 2026, sob o título «Your FortiGate Updated Itself – But You Don’t Know Why?», um resumo de como isso acontece. Confrontámos as afirmações com a documentação do fabricante.

Em resumo: existem dois mecanismos. Um deles pode ser desativado; o outro, não.

Mecanismo 1: o upgrade automático de patches

Desde o FortiOS 7.2.1 é possível configurar um FortiGate para instalar novos patch releases por conta própria. Antes da 7.4.5, a função vinha ativada de fábrica apenas nos modelos de entrada. Com o FortiOS 7.4.5, a Fortinet mudou isso: segundo a documentação do fabricante, a partir dessa versão os upgrades automáticos de firmware vêm ativados por predefinição «em todos os modelos FortiGate, incluindo FortiGate VMs» («on all FortiGate models, including FortiGate VMs»). Quem abre a interface web pela primeira vez após a atualização para a 7.4.5 tem de confirmar isso com «I acknowledge» – um clique que facilmente passa despercebido no dia a dia.

Importante para contextualizar: a função atualiza apenas dentro do ramo de versão em uso. De um 7.4.x vem um 7.4.x mais recente, nunca um 7.6.x. Trata-se, portanto, de patches, não de saltos de versão.

O comportamento pode ser controlado na interface em «System > Firmware & Registration» ou via CLI em config system fortiguard. Aí define-se se a função está ativa, em que dias da semana a instalação é permitida ou quantos dias se espera após a publicação de um patch (predefinição segundo a documentação: três dias), e em que janela horária isso acontece. A predefinição é das 2h às 4h, hora local; o momento exato é escolhido aleatoriamente dentro da janela. Após a instalação, é enviado um e-mail à conta FortiCloud na qual o equipamento está registado – não necessariamente à pessoa que hoje é responsável pela firewall.

Mecanismo 2: o upgrade forçado

O segundo mecanismo é o verdadeiro motivo do artigo da boll. A Fortinet chama-lhe «Required firmware upgrade»; a boll fala em «Forced Upgrade». Entra em ação quando uma de duas condições se verifica:

  • A licença de firmware é inválida. A Fortinet fala de uma licença «Firmware & General Updates (FMWR)» inválida; a boll, de forma mais genérica, da falta de um contrato FortiCare válido.
  • O ramo de versão atingiu o seu End of Engineering Support (EOES). Ou seja, os equipamentos correm numa versão secundária para a qual o fabricante já não realiza desenvolvimento.

Nesses casos, o FortiGate verifica diariamente se há um patch mais recente no próprio ramo de versão e agenda a instalação por conta própria. Também aqui fica restrito ao patch dentro da versão secundária; se o caminho de upgrade passar por versões intermédias, estas são percorridas em sequência.

Quanto à questão de a partir de quando isto vale, as fontes não coincidem totalmente. A boll e a página «New Features» da Fortinet sobre o FortiOS 8.0 citam 7.4.8 e 7.6.4; o guia de administração 8.0 cita 7.4.9 e 7.6.4. O FortiOS 8.0.0 é afetado em qualquer caso. Quem está na 7.4.8 ou na 7.6.4, ou em versão mais recente, deve contar com o mecanismo.

A diferença decisiva em relação ao upgrade automático: um upgrade forçado não pode ser cancelado depois de agendado. A interface desativa o botão de cancelamento, e a consola informa, em essência, que o upgrade é forçado e não pode ser cancelado. Só é possível adiá-lo com execute auto-upgrade delay-installation. A boll indica um adiamento de sete dias. O guia de administração do FortiOS 8.0 confirma o adiamento fixo de sete dias e acrescenta dois detalhes: o comando pode ser repetido quantas vezes se quiser, mas não no dia em que a instalação está agendada.

O estado atual é apresentado por execute auto-upgrade status. Aí constam, entre outras coisas, o estado do contrato, se a imagem em execução chegou ao fim de vida e – quando for o caso – a indicação «Enabled (Forced)» juntamente com a janela horária agendada.

As exceções – e porque nem todas protegem

A boll cita três configurações em que o upgrade forçado não entra em ação. A documentação do fabricante confirma-as, mas descreve-as com mais precisão – e os detalhes mudam a mensagem:

  • Gestão pelo FortiManager. Um FortiGate ligado ao FortiManager não se atualiza sozinho. Se for ligado ao FortiManager quando um upgrade forçado já estiver agendado, esse upgrade é cancelado.
  • Membro de uma Security Fabric. Também aqui não ocorre upgrade automático. Inversamente: se um upgrade forçado já estiver agendado, o equipamento não pode aderir a uma Fabric.
  • Membro secundário de um cluster HA. Esta é a exceção mais fácil de ser mal compreendida. O equipamento secundário não inicia um upgrade próprio – mas recebe o novo firmware através de um upgrade de cluster desencadeado pelo equipamento primário. O cluster como um todo é, portanto, atualizado.

Uma quarta exceção consta apenas da documentação do fabricante: em builds especiais («special builds»), o upgrade forçado não entra em ação.

Ganho de segurança versus change control

O fabricante justifica o mecanismo com a proteção dos equipamentos, e o argumento sustenta-se: uma firewall sem contrato de firmware ou num ramo de versão sem desenvolvimento é um sistema de perímetro que já não recebe correções.

Para a operação, mesmo assim, é uma intervenção no controlo de mudanças. Uma troca de firmware significa um reinício, ou seja, num equipamento isolado, uma queda das ligações. Pode alterar comportamentos dos quais dependem conjuntos de regras, extremidades remotas de VPN ou sistemas ligados. E acontece num momento que não foi definido pelo seu processo de mudanças, mas pelo próprio equipamento.

A boa notícia: os dois gatilhos são previsíveis. O fim de uma licença e uma data de EOES são conhecidos com muita antecedência.

O que deve fazer agora

  • Levantar a situação atual. Verifique em cada equipamento, com execute auto-upgrade status, se o upgrade automático está ativo e se um upgrade forçado já foi agendado.
  • Prazos de contrato e datas de EOES no inventário. A data de fim da licença de firmware e o fim do suporte do ramo de versão devem constar como campos no registo de ativos, com responsável e antecedência – não na memória de colaboradores individuais.
  • Associar a janela horária à sua janela de manutenção. Defina dias da semana e janela horária de modo que um upgrade automático caia numa janela de manutenção anunciada, e documente a configuração.
  • Testar os patches primeiro em laboratório. Um equipamento de teste ou uma instância virtual no mesmo ramo de versão mostra, antes do equipamento de produção, se um patch afeta o conjunto de regras, a VPN ou a autenticação.
  • Encaminhar a notificação para o sítio certo. Os e-mails vão para a conta FortiCloud registada. Verifique se alguém ainda lê essa caixa de correio hoje.
  • Saber que exceção se aplica ao seu caso. Quem gere via FortiManager está isento do upgrade forçado – e por isso tem de manter ativamente o nível de patches por conta própria. Quem opera um cluster HA não está isento.
  • Entender o adiamento como ferramenta, não como solução. Sete dias dão tempo para concluir um teste ou combinar uma janela. Não substituem nem o contrato nem a migração para um ramo de versão suportado.

Como a sector7 apoia

No âmbito dos nossos serviços geridos, operamos firewalls e VPN com gestão de patches, de configuração e de mudanças, e atualizamos os sistemas de forma planeada e documentada, em vez de ad hoc; anunciamos as janelas de manutenção e programamo-las fora do horário de expediente. Mais sobre isso em Serviços geridos e suporte e Cibersegurança.

Fontes

Vamos falar sobre a sua situação.

Marcar uma conversa+49 212 240915 0