Sophos Firewall v22 MR2: funções, correções e upgrade

A Sophos lançou o Sophos Firewall OS 22.0 MR2 Build 546 a 14 de julho de 2026. Esta maintenance release é menor do que uma major release, mas oferece muito mais do que um simples pacote de correções: traz controlo da criptografia pós-quântica, uma deteção mais precisa de aplicações de inteligência artificial generativa, uma nova extensão para Chromebook, uma predefinição STAS menos disruptiva e cadeias de confiança Let’s Encrypt atualizadas. Ao mesmo tempo, a Sophos corrige 53 problemas documentados nas áreas de firewall, HA, IPsec, autenticação, logging, WAF, reporting e outros componentes.

O MR2 é, portanto, sobretudo uma versão orientada para a operação e a estabilidade. As novas funções são interessantes, mas, para muitos ambientes de produção, os crashes de kernel, as causas de failsafe, os problemas de HA e os erros de VPN corrigidos são o motivo mais importante para atualizar.

Detetar e controlar a criptografia pós-quântica

A nova função de segurança mais marcante diz respeito à Post-Quantum Cryptography (PQC). Trata-se de métodos criptográficos concebidos para resistir a ataques de futuros computadores quânticos suficientemente potentes. O risco atual não se limita à possibilidade de um computador deste tipo ficar disponível um dia. Para dados especialmente sensíveis, o princípio harvest now, decrypt later já é relevante: o tráfego encriptado é registado e armazenado para poder ser desencriptado mais tarde com tecnologia mais potente.

O SFOS 22.0 MR2 deteta métodos de troca de chaves puros e híbridos baseados em ML-KEM. Em 2024, o National Institute of Standards and Technology normalizou este método como FIPS 203. O método baseia-se no problema matemático Module Learning With Errors. O NIST define três conjuntos de parâmetros, ML-KEM-512, ML-KEM-768 e ML-KEM-1024, com diferentes características de segurança e desempenho.

O ML-KEM não encripta diretamente o tráfego web subsequente. É um Key Encapsulation Mechanism utilizado para estabelecer um segredo partilhado entre o cliente e o servidor através de um canal público. A partir desse segredo são depois derivadas as chaves de sessão simétricas utilizadas para encriptar e autenticar eficientemente os dados propriamente ditos.

Numa troca de chaves PQC pura, a segurança da negociação depende exclusivamente do método pós-quântico. As implementações TLS atuais utilizam com maior frequência métodos híbridos, nos quais o ML-KEM é combinado com um método clássico como o X25519. O objetivo de uma negociação híbrida corretamente concebida é manter a sessão protegida enquanto pelo menos um dos dois componentes permanecer seguro. No entanto, esta é uma propriedade da combinação concreta e não está automaticamente garantida em qualquer método híbrido. Esta abordagem reduz o risco de depender por completo de um método criptográfico relativamente novo numa fase inicial da migração.

A Sophos publica agora os nomes dos padrões detetados: TLS 1.3 PQC ML-KEM-512, ML-KEM-768, ML-KEM-1024, X25519 ML-KEM-768 e Hybrid Key Share. Os IDs concretos das assinaturas IPS continuam sem estar documentados publicamente.

Deteção e controlo de políticas através do IPS

Com TLS 1.3, o cliente anuncia os grupos de troca de chaves suportados logo no ClientHello. Estes metadados são transmitidos antes de a sessão de aplicação encriptada ser estabelecida. Assim, o IPS consegue, em princípio, reconhecer a utilização de um método PQC ou híbrido na negociação TLS sem ter de desencriptar o conteúdo HTTP posterior.

A Sophos disponibiliza novos padrões IPS para este efeito. Para que sejam efetivamente avaliados, o IPS Protection tem de estar ativo, tem de existir uma licença Network Protection válida e a política IPS correspondente tem de estar atribuída a uma regra de firewall. Numa política própria, é possível definir ações para as assinaturas correspondentes, como:

permitir,
registar,
descartar pacotes individuais ou toda a sessão,
terminar a sessão TCP através de um reset ou
desativar a assinatura.

As assinaturas PQC introduzidas no MR2 estão desativadas por predefinição. Isto faz sentido, porque os browsers, plataformas cloud, CDN e bibliotecas TLS atuais utilizam cada vez mais métodos PQC híbridos no funcionamento normal. Se a Sophos fornecesse imediatamente estas assinaturas com uma ação predefinida de bloqueio, poderia interromper ligações web e API legítimas. No primeiro tópico de feedback, a Sophos também justifica a predefinição desativada com a utilização crescente de PQC-TLS e o risco de gerar um grande número de alertas desnecessários.

Eu não ativaria imediatamente as novas assinaturas em modo de bloqueio. É mais sensato criar uma política IPS separada para um grupo de teste limitado e, numa primeira fase, apenas registar as correspondências. Depois, o Log Viewer permite analisar que browsers, aplicações e destinos utilizam ML-KEM. Só quando estiver claro que política criptográfica deve ser aplicada e que serviços legítimos seriam afetados é que utilizaria Drop session ou Reset. PQC não é automaticamente suspeita – na maioria dos casos, uma correspondência mostra apenas que uma aplicação já utiliza métodos TLS modernos.

Controlo da negociação TLS através do Web Protection

Além do IPS, o Web Protection intervém diretamente nos métodos TLS que podem ser negociados. A Sophos indica que as sessões web não podem negociar algoritmos PQC que a firewall não suporte. É uma tarefa diferente da simples deteção através do IPS: o IPS classifica a negociação visível e aplica uma ação de política, enquanto o Web Protection deve garantir que uma sessão web protegida apenas é estabelecida com um método criptográfico suportado pelo caminho de processamento do SFOS.

Isto é particularmente importante com TLS Inspection. Neste caso, a firewall não é apenas um componente passivo no caminho dos dados: tem de terminar a sessão TLS, verificar ou voltar a emitir certificados e negociar parâmetros criptográficos compatíveis de ambos os lados. Por isso, um algoritmo suportado pelo browser e pelo servidor de destino não é automaticamente adequado para todos os Inspection Engines intermédios.

A troca de chaves PQC também altera tecnicamente a negociação TLS. As key shares híbridas são maiores do que os valores X25519 clássicos e podem fazer com que um ClientHello seja distribuído por vários pacotes. Estas ligações são válidas de acordo com TLS, mas podem exigir visivelmente mais de middleboxes, proxies ou Inspection Engines mais antigos e não atualizados. O novo suporte do MR2 não é, portanto, apenas uma assinatura adicional, mas também uma adaptação de compatibilidade para uma stack TLS em transformação.

Atualmente, a Sophos não documenta em detalhe se o Web Protection termina a sessão perante um método PQC não suportado, se recorre a um método clássico ou se reage de forma diferente consoante o caminho de processamento. Por isso, não se deve deduzir um comportamento específico de fallback a partir do anúncio da versão. Apenas uma coisa é clara: as negociações PQC não suportadas não devem passar de forma descontrolada pela camada de proteção.

Depois do upgrade, sobretudo os ambientes com TLS Inspection devem testar os seguintes pontos:

Testar as versões atuais do Chrome, Edge, Firefox e Safari com os serviços SaaS e cloud mais utilizados.
Aceder aos mesmos destinos uma vez através de uma regra com TLS Inspection e outra vez sem TLS Inspection.
Verificar exceções de TLS Inspection, erros de certificado e páginas de bloqueio.
Analisar os logs de IPS e Web Protection à procura de novas mensagens PQC, erros de handshake e resets.
Testar separadamente aplicações críticas para a empresa com bibliotecas TLS, clientes API ou runtimes Java próprios.
Em caso de problemas, utilizar Packet Capture para verificar se já é o handshake TLS que falha ou se apenas a sessão de aplicação protegida é interrompida.
Só depois decidir se é necessária uma ação explícita Allow, Drop ou Reset.

Inteligência artificial generativa com Synchronized Application Control

O MR2 melhora a categorização de aplicações de inteligência artificial generativa. A limitação decisiva já está no nome da função: a visibilidade adicional é fornecida através do Synchronized Application Control. O Sophos Endpoint deteta aplicações localmente e partilha esta informação com a firewall através do Security Heartbeat. Em seguida, o SFOS consegue atribuir a aplicação com maior precisão no reporting e nas regras de Application Control.

Isto ajuda com aplicações que comunicam através de protocolos web genéricos, CDN partilhadas ou destinos variáveis e que, apenas com base nas assinaturas de firewall tradicionais, são difíceis de identificar de forma inequívoca. Uma categoria mais precisa facilita, por exemplo, a distinção entre aplicações web normais e ferramentas GenAI, bem como a avaliação dos utilizadores ou equipamentos que recorrem a essas aplicações.

No entanto, a função não é um sistema CASB ou DLP universal. Não é feita qualquer análise automática do conteúdo confidencial dos prompts e, sem um Sophos Endpoint compatível, não está disponível a mesma visibilidade das aplicações. Em ambientes Microsoft Defender ou com endpoints mistos, os controlos DNS, web, TLS, proxy ou SSE/CASB continuam, portanto, a ser relevantes.

Uma política útil requer mais do que a nova categoria:

O Sophos Endpoint e o Security Heartbeat têm de estar corretamente ligados.
As aplicações desconhecidas no Synchronized Application Control têm de ser classificadas regularmente.
As regras de firewall precisam de uma política Application Control adequada e de logging ativado.
É necessário definir os serviços GenAI permitidos, as contas empresariais e os requisitos de proteção de dados.
Os dados sensíveis exigem controlos DLP, browser, endpoint ou SaaS adicionais.

Um bloqueio generalizado de todas as aplicações GenAI raramente é a melhor primeira medida. Uma política faseada é mais sensata: permitir os serviços empresariais aprovados, registar ou bloquear serviços desconhecidos ou não verificados e avaliar a utilização com base nos requisitos reais da empresa.

O procedimento prático para o grupo piloto, o Application Filter, o bloqueio e a validação é explicado em Detetar e controlar IA generativa no Sophos Firewall.

Autenticação: Chromebook, STAS e eDirectory

O MR2 altera três áreas tecnicamente diferentes da identificação de utilizadores. Na operação diária, todas dizem respeito ao mesmo ponto crítico: se a firewall reconhece um utilizador de forma fiável e lhe atribui a política correta.

Chromebook User ID com Manifest V3

A nova Sophos Chromebook User ID Extension suporta o Chrome Manifest V3. O Manifest V3 é a plataforma atual de extensões do Chrome e altera, entre outros aspetos, as permissões, os processos em segundo plano e a forma como as extensões processam eventos de rede. Sem a nova versão, a anterior extensão Sophos deixaria, a longo prazo, de receber atualizações regulares.

Segundo a Sophos, não está prevista uma atualização in-place. É necessário desinstalar a extensão antiga e instalar a nova. Em ambientes Chromebook geridos, isto deve ser feito na consola de administração Google ou na solução de Endpoint Management utilizada:

Remover a antiga Sophos Chromebook User ID Extension da instalação forçada.
Adicionar a nova versão Manifest V3 e atribuí-la aos grupos de destino.
Iniciar sessão com um utilizador de teste.
Verificar na firewall se o nome de utilizador e o endereço IP estão corretamente associados.
Acionar uma política de firewall ou web baseada no utilizador e verificar o resultado no Log Viewer.

A ordem é importante. Se a extensão antiga for removida antes da distribuição da nova versão, a associação de utilizadores fica temporariamente indisponível. Nesse caso, as regras podem recorrer a uma política de fallback mais geral ou bloquear o acesso.

A configuração completa de Device Access, certificado, regras de firewall, política JSON e API Controls encontra-se em Configurar o Chromebook SSO com o Google Workspace.

STAS deixa de bloquear por predefinição durante a verificação de identidade

Com a Sophos Transparent Authentication Suite (STAS), quando encontra um cliente novo ou alterado, a firewall consulta que utilizador do Active Directory está associado a um endereço IP. A definição Restrict client traffic during identity probe determina se o cliente já pode enviar tráfego enquanto esta verificação decorre.

Com o MR2, o valor predefinido passa para No. O tráfego pode, portanto, continuar enquanto a firewall verifica o utilizador e o endereço de destino. Isto reduz breves interrupções que se podem notar sobretudo em novas sessões, mudanças de utilizador, roaming ou respostas atrasadas do STAS Collector.

O ganho de comodidade implica um compromisso: durante a verificação, a firewall tem de trabalhar com o contexto de identidade disponível nesse momento. Em ambientes com regras baseadas em utilizadores muito rigorosas, deve verificar-se que política é aplicada durante esta breve janela. Após a atualização, não se deve assumir que as configurações existentes adotam automaticamente o mesmo valor. É necessário verificar o valor atual, o comportamento pretendido e os logs reais.

Novell eDirectory termina com o SFOS 23.0

O MR2 também apresenta um aviso de End-of-Life para o Novell eDirectory Authentication Server. O suporte termina com o SFOS 23.0. No MR2, o eDirectory continua a funcionar; a mensagem é um aviso prévio e não a remoção imediata da função.

Não vamos sentir falta desta integração. O Novell eDirectory já não é utilizado por nenhum dos nossos clientes e há muito que deixou de ter relevância em novos projetos. Os poucos ambientes que ainda o utilizam têm até ao SFOS 23.0 para migrar para uma fonte de identidade suportada. Além do Authentication Server, é necessário verificar os grupos importados, as regras de firewall, as permissões VPN, as políticas web, o Captive Portal e os reports baseados em utilizadores.

O guia Migrar o eDirectory antes do SFOS 23 explica como migrar de forma controlada a fonte de identidade de destino, os grupos e os serviços, mantendo um caminho de reversão.

Let’s Encrypt e operação de certificados

O SFOS 22.0 MR2 atualiza o suporte para novos certificados root e intermediate da Let’s Encrypt. Passam a ser consideradas as cadeias YE Root, YE1, YE2, YR Root, YR1 e YR2. Assim, a Sophos Firewall prepara a emissão e renovação automáticas de certificados para as cadeias Let’s Encrypt atuais e futuras.

Isto é relevante porque um pedido ACME correto, por si só, não é suficiente. A firewall, a contraparte e os clientes também têm de conseguir construir e validar corretamente a cadeia do certificado emitido. Caso contrário, trust stores desatualizados podem causar erros de certificado aparentemente inexplicáveis, apesar de o certificado leaf ser válido.

As notificações por email da Let’s Encrypt passam também a incluir o hostname e o número de série da firewall. Em ambientes com vários equipamentos, torna-se assim mais fácil perceber rapidamente que equipamento originou uma renovação, um erro ou outra mensagem de certificado. No entanto, o número de série é um dado relevante para o inventário; as notificações devem, por isso, ser enviadas apenas para destinatários e caixas de correio controlados.

Depois do upgrade, vale a pena realizar um teste completo aos certificados:

Verificar o estado ACME e a data da próxima renovação.
Verificar hostname, resolução DNS e acessibilidade do challenge.
Validar a cadeia de certificados no browser ou com um teste TLS externo.
Analisar separadamente os certificados de WAF, WebAdmin, User Portal e VPN.
Verificar a receção da nova notificação por email e a lista de destinatários.

Config Studio 2.6 alarga a análise e a migração

Em paralelo com o MR2, a Sophos destaca o Firewall Config Studio 2.6. A ferramenta funciona no browser fora da firewall e, por isso, tecnicamente não é uma função WebAdmin integrada na Build 546. No entanto, complementa a operação precisamente nos pontos em que o SFOS continua a oferecer possibilidades limitadas de análise e comparação.

As funções mais importantes da versão 2.6 são:

Merge templates: Uma configuração baseline pode ser combinada com um modelo específico do setor ou da utilização. Isto acelera rollouts normalizados, mas não substitui a verificação de objetos, interfaces ou regras em conflito.
Enhanced Global Search: Os objetos podem ser pesquisados globalmente e abertos diretamente no local onde são utilizados. Isto é especialmente útil em conjuntos de regras grandes e na limpeza de dependências pouco claras.
Improved Configuration Report: As regras de firewall, NAT e TLS não mostram apenas os nomes dos objetos referenciados, mas também os respetivos valores e detalhes. As reviews tornam-se assim mais compreensíveis sem ser necessário abrir cada objeto separadamente.
Migration Insights: Após uma conversão, o Config Studio mostra a percentagem migrada com sucesso. Este valor é uma orientação, não uma validação: VPN, autenticação, certificados e funções específicas do fabricante que não tenham sido transferidas continuam a exigir verificação manual.
Multi-file Configuration Diff: É possível comparar vários estados da configuração. Desta forma, consegue-se perceber entre que backups surgiu uma alteração, um erro ou um desvio indesejado.
Compatibilidade de backup e restauro: A ferramenta ajuda a verificar se é possível restaurar um backup noutro modelo Sophos Firewall.
Referência de Flexi Port e velocidade das portas: É possível comparar layouts de portas, módulos Flexi e velocidades suportadas até 25, 40 ou 100 Gbit/s antes de migrações de hardware.

O Config Studio 2.6 já foi analisado em detalhe no artigo Sophos Firewall Config Studio 2.6: migração incorporada. O workflow prático para Report, Compare, Editor e reimportação controlada encontra-se em Utilizar o Sophos Firewall Config Studio.

Os 53 problemas corrigidos na Build 546

A Sophos indica mais de 50 correções de estabilidade, fiabilidade e segurança. A seguinte classificação inclui todos os 53 IDs das release notes oficiais. A lista não substitui uma avaliação de suporte individual, mas mostra que função foi afetada e por que motivo a correção é relevante para a operação.

Firewall, kernel, HA e estabilidade do sistema

NC-180331 – Gestão incorreta da memória em algif_aead e algif_skcipher: Corrige uma vulnerabilidade do kernel Linux em componentes criptográficos.
NC-181331 – Uma partição de configuração cheia colocava a firewall em modo failsafe: Reduz o risco de uma falha operacional por esgotamento do espaço de configuração.
NC-180974 – Um crash de kernel em sdwan_profile acionava um failover HA: Estabiliza ambientes SD-WAN e evita mudanças de função desnecessárias no cluster.
NC-178354 – Crash de kernel durante o matching de regras SD-WAN: Impede crashes durante a avaliação de regras SD-WAN.
NC-178413 – Um valor vazio em Services causava um erro ipset e o modo failsafe: Processa de forma mais robusta objetos de serviço danificados ou incompletos.
NC-177934 – A firewall entrava em modo failsafe após o upgrade para SFOS 22.0 GA: Corrige uma consequência direta do upgrade em builds v22 anteriores.
NC-177441 – O equipamento HA inicialmente primário entrava em modo failsafe após o upgrade para SFOS 22.0 GA: Melhora a estabilidade de arranque do nó primário após o upgrade.
NC-177467 – O equipamento auxiliar não arrancava devido a um número muito elevado de ligações SSH simultâneas não autenticadas: Importante para sistemas HA expostos ou muito analisados; esta correção específica está a ser observada com atenção no primeiro feedback do MR2 para XGS 5500 HA.
NC-173031 – As Application Policies importadas não eram sincronizadas automaticamente com o equipamento auxiliar: Garante estados de política mais consistentes nos dois nós HA.
NC-177536 – O upgrade de firmware para SFOS 22.0 GA falhava no equipamento HA primário: Estabiliza o caminho de upgrade em clusters HA.
NC-178745 – Um equipamento HA reiniciava automaticamente por falta de memória: Reduz reinícios não planeados causados pela área de logging.
NC-180110 – O equipamento HA primário entrava em modo failsafe porque o daemon de logging não arrancava: Impede que um erro de arranque do logging retire todo o nó primário de serviço.
NC-180933 – Os administradores não conseguiam iniciar sessão na consola WebAdmin: Repõe o acesso administrativo à GUI.
NC-177769 – O serviço eBPF deixava de responder após uma atualização de padrões: Estabiliza o caminho de dados acelerado após atualizações de assinaturas.
NC-180152 – As atualizações de interfaces demoravam mais no SFOS 22.0 GA do que no 21.5: Reduz os atrasos na aplicação de alterações de interfaces.
NC-179462 – Avisos repetidos durante a leitura de estatísticas de hardware: Elimina ruído desnecessário nos logs de appliances XGS.

Regras de firewall, tráfego de utilizadores e routing

NC-181741 – O tráfego de utilizadores não autenticados era descartado de hora a hora: Evita interrupções regulares em ambientes com tráfego não autenticado.
NC-178903 – Os utilizadores SATC perdiam o acesso à Internet após o upgrade para SFOS 22.0 GA: Repõe o acesso baseado em utilizadores com o Sophos Authentication Thin Client.
NC-178141 – Determinadas mensagens de erro ICMP eram descartadas pela Local ACL após o upgrade GA: Melhora o Path MTU Discovery e a análise de erros nos quais o ICMP é tecnicamente necessário.
NC-178197 – O tráfego de aplicações parava temporariamente com uma Bandwidth Policy baseada em aplicações: Estabiliza o QoS de regras que controlam a largura de banda com base nas aplicações detetadas.
NC-180226 – A GUI não apresentava qualquer erro perante um endereço MAC duplicado em Spoof protection trusted MAC: Evita configurações incorretas silenciosas na lista de exceções de Spoof Protection.
NC-181299 – A base de dados GeoIP atribuía um IP ao Reino Unido em vez da Alemanha: Corrige a atribuição de país para regras e reports GeoIP.

IPsec e VPN

NC-180433 – Multicast através de um túnel VPN provocava crashes repetidos da firewall: Importante para cenários de routing, streaming ou discovery com multicast através de IPsec.
NC-178121 – As ligações IPsec site-to-site ficavam na posição errada do grupo de failover após drag-and-drop: Garante que a prioridade configurada para os túneis é mantida.
NC-171719 – Problema de routing SD-WAN com tráfego ESP: Melhora a seleção de caminho para IPsec/ESP nativo em cenários SD-WAN.
NC-180520 – O gateway XFRM permanecia inacessível com aceleração IPsec, alias IP e entrada de ESP através de outra porta WAN: Corrige um caso especial complexo em ambientes multi-WAN com túneis IPsec acelerados.
NC-176855 – Baixo throughput IPv6 através de IPsec route-based: Melhora o desempenho IPv6 em arquiteturas VPN baseadas em túneis.
NC-181687 – A criação de uma política SSL VPN terminava com um erro interno do servidor: Repõe a criação de políticas na nova arquitetura de control plane e HA.
NC-175860 – O Remote Access IPsec falhava após um failover HA quando o Appliance Certificate tinha sido gerado novamente: Estabiliza ligações de acesso remoto dependentes de certificados durante mudanças de função.

Autenticação, Central e gestão de configurações

NC-180824 – Novos utilizadores AD num grupo AD secundário não conseguiam iniciar sessão no VPN Portal: Corrige o tratamento de memberships em grupos aninhados ou secundários no acesso ao portal.
NC-176806 – O Microsoft Entra ID SSO falhava devido à falta de CA intermediate: Melhora a validação de certificados nos inícios de sessão Entra ID.
NC-160157 – Last access time permanecia após a eliminação do utilizador e aparecia no utilizador recém-criado: Evita dados históricos de acesso enganadores depois de voltar a criar uma conta.
NC-181175 – Um Group Policy Push do Sophos Central ficava em pending e não era aplicado: Corrige alterações de grupos bloqueadas na gestão central.
NC-180513 – A importação de configurações a partir da vista Sophos Central não funcionava após o upgrade para MR1: Repõe o caminho de importação através do Central.
NC-181904 – Não era possível libertar emails da quarentena através do Sophos Central: Corrige o conhecido workflow do Central; o WebAdmin local era anteriormente a solução prática.

A Central Firewall Task Queue deve continuar a ser verificada após a atualização. A correção de um erro do produto não garante que tasks antigas bloqueadas ou estados de grupo inconsistentes desapareçam automaticamente.

Logging e reporting

NC-181520 – O Log Viewer era demasiado lento: Melhora o tempo de resposta durante pesquisas e análise de erros.
NC-172912 – O System Graph apresentava oscilações visuais: Estabiliza a apresentação das métricas do sistema.
NC-172020 – Firewalls sem reporting on-box enviavam PDFs vazios do Traffic Dashboard: Evita reports diários sem conteúdo.
NC-169646 – Os PDFs on-demand continham gráficos e tabelas incorretos no Chrome: Corrige a geração de reports através do browser.
NC-155252 – Um I/O de disco elevado provocava picos de CPU e interrupções da Internet até um minuto: Uma correção de estabilidade especialmente relevante para sistemas com utilização intensiva de reporting e logging.

Os NC-178745 e NC-180110 da lista de estabilidade também dizem respeito ao Logging Framework, mas, devido ao reinício e ao modo failsafe, respetivamente, tinham efeitos diretos em todo o equipamento.

Email, antivírus e Security Heartbeat

NC-180066 – As atualizações de padrões SAVI e AVIRA falhavam e paravam o serviço antivírus: Garante que um erro de padrões não termina todo o serviço AV.
NC-177930 – Os emails ficavam no spool devido a um crash do mailpoller: Evita o bloqueio da entrega de email no modo MTA.
NC-171602 – As notificações da firewall não passavam na verificação DKIM: Melhora a entrega de emails de sistema assinados.
NC-176012 – Era comunicado um Heartbeat em falta quando dois endpoints utilizavam a mesma docking station ou interface USB: Reduz falsos alertas Heartbeat quando diferentes equipamentos utilizam hardware partilhado.

Quem utiliza o MTA Mode deve testar o mail spool, a quarentena, o DKIM e a libertação pelo Central após a atualização, seguindo os passos do artigo Sophos Firewall Mail Protection no MTA Mode.

WAF, Web Protection e RED

NC-180200 – O WAF parava durante a sincronização noturna da licença na Home Edition: Evita interrupções regulares do WAF em instalações Home Edition.
NC-177457 – Com o debugging WAF ativado, a palavra-passe ficava visível em reverseproxy.log: Corrige uma exposição sensível em texto simples no log de debug. Ainda assim, os logs de debug antigos devem ser verificados e protegidos ou eliminados de acordo com as diretrizes aplicáveis.
NC-176788 – ResponseFieldSize voltava à predefinição quando se alterava o certificado numa regra WAF: Mantém um limite de tamanho definido de forma deliberada durante alterações de certificados.
NC-167019 – O Snort causava uma carga elevada de CPU com tráfego Veeam sem exceção: Reduz picos de carga no tráfego de backup; ainda assim, as exceções existentes devem ser verificadas quanto à sua necessidade.
NC-178906 – A firewall entrava em modo failsafe com Failed to start Red server service: Estabiliza o serviço RED Server e evita um estado failsafe em todo o equipamento.

Firmware, DDNS e interface de utilizador

NC-170200 – Várias tentativas de upgrade em poucos minutos faziam falhar os upgrades de firmware: Torna o Firmware Management mais robusto; ainda assim, devem evitar-se arranques paralelos ou repetidos em rápida sucessão.
NC-180219 – O Cloudflare DDNS deixava de funcionar após o upgrade para SFOS 22.0 MR1: Repõe as atualizações de DNS dinâmico para Cloudflare.
NC-181575 – O campo da hora em Schedules era apresentado incorretamente: Evita interpretações erradas ao editar regras programadas.
NC-171424 – Depois de eliminar a única exceção na última página, a lista Web Exceptions aparecia vazia: Volta corretamente à página anterior, em vez de mostrar uma configuração aparentemente vazia.

Planear o upgrade e validar o MR2

A Sophos suporta o upgrade para v22 MR2 a partir de todas as versões suportadas das séries v21.5, v21 e v20. A imagem de firmware pode ser obtida manualmente através do Sophos Central; a disponibilização automática aos equipamentos ligados será feita de forma faseada ao longo das próximas semanas. Segundo a Sophos, a atualização está disponível sem custos adicionais de firmware para firewalls licenciadas com suporte Enhanced ou Enhanced Plus.

Apesar da longa lista de correções, o MR2 não deve ser instalado em todos os sistemas ao mesmo tempo sem testes. O tópico público de feedback só foi aberto no dia do lançamento. As primeiras contribuições perguntam especificamente pela estabilidade do XGS 5500 em funcionamento HA active-passive e pela correção NC-177467. Isto ainda não representa um novo erro confirmado no MR2, mas é um bom motivo para atualizar de forma faseada os sistemas HA e as localizações críticas para a empresa.

Antes da atualização

Verificar o caminho de upgrade suportado e o estado da licença.
Criar um backup completo e encriptado e mantê-lo disponível externamente.
Executar a verificação de upgrade para SFOS 22.
Avaliar os resultados pendentes do Sophos Firewall Health Check.
Verificar o estado HA, o estado dos SSD, o espaço livre nas partições e o estado dos padrões.
Documentar funções críticas: WAN, SD-WAN, IPsec, SSL VPN, WAF, MTA, DDNS, autenticação e Central Management.
Preparar a janela de manutenção, o acesso à consola local e a decisão de rollback.

Depois da atualização

Verificar a Build 22.0 MR2 546, o estado do sistema e os hotfixes ativos.
Em HA, verificar ambos os nós, a sincronização, as funções e o failover.
Testar WAN, DNS, DHCP/DDNS, SD-WAN e acesso à Internet.
Verificar VPN site-to-site e Remote Access, incluindo IPv6 e failover.
Validar AD, Entra ID, STAS, SATC e início de sessão no portal com utilizadores de teste.
Verificar WAF, Let’s Encrypt, MTA, quarentena e notificações.
Verificar a Central Task Queue e as alterações de grupos aplicadas mais recentemente.
Procurar no Log Viewer novos erros, avisos de failsafe, reinícios de serviços e mensagens PQC.
Atualizar outros equipamentos apenas depois de um período de observação estável.

O processo completo de backup, janela de manutenção e verificação posterior está descrito em Preparar uma atualização de firmware da Sophos Firewall.

Conclusão

A Sophos Firewall v22 MR2 é uma maintenance release útil com uma combinação invulgarmente ampla. A criptografia pós-quântica e a melhor categorização GenAI mostram a direção em que evoluem o controlo da rede e das aplicações. Chromebook Manifest V3, STAS e Let’s Encrypt são menos espetaculares, mas resolvem problemas concretos de lifecycle e operação.

O motivo mais forte para instalar a Build 546 continua a ser a estabilidade: foram corrigidos vários crashes de kernel, estados failsafe, problemas de HA, erros de VPN, uma palavra-passe em texto simples no log de debug WAF e falhas relevantes em logging, reporting, antivírus e email. Precisamente devido à profundidade destas intervenções, a atualização não deve ser tratada como um simples clique. Backup, rollout faseado e verificações funcionais direcionadas continuam a ser indispensáveis.