Sophos Firewall: sem CVEs, mas com bugs (v21.5 a v22)

Quando se trabalha hoje no ambiente de firewalls, normalmente há que lidar com um de dois grandes males: ou se vive sob stress constante por causa de vulnerabilidades críticas (CVEs, como acontece atualmente com a Fortinet) e se passam noites a aplicar patches, ou os sistemas colocam tantos obstáculos no funcionamento normal, com firmware instável e bugs irritantes (como acontece agora com a Sophos), que quase não sobra tempo para mais nada.

No meu trabalho na empresa, é precisamente a segunda situação que nos atinge em cheio - um stress que, naturalmente, às vezes também levo para casa. O nosso ponto de dor atual tem nome: Sophos Firewall.

Enquanto concorrentes como a Fortinet parecem disparar novos advisories PSIRT todas as semanas e obrigam os administradores a rodar ao ritmo dos patches, a Sophos consome-nos imenso tempo. Não por causa de falhas com grandes manchetes, mas por causa de bugs banais, embora críticos, no dia a dia do sistema.

Disclaimer, para isto não soar a comparação injusta: tenho plena consciência de que a Fortinet também lida com bugs sérios (por exemplo, Conserve Mode e memory leaks no FortiOS 7.2/7.4/7.6) e de que a Sophos também já teve CVEs graves no passado. Mas, na fase atual v21.5/v22, é exatamente esta constelação que nos aperta: de um lado, patching constante de CVEs; na Sophos, trabalho de Ops desnecessário por problemas de estabilidade.

Contexto de versões (TL;DR)

Para ficar claro que não estou a falar de uma v19 empoeirada, mas daquilo que muitos usam neste momento como “atual”:

• SFOS 21.5 GA (02.06.2025): Release Notes: SFOS 21.5
• SFOS 21.5 MR2 (Build 323, 18.02.2026): segundo as Release Notes, a 21.5 mais recente neste período.
• SFOS 22.0 GA (dezembro de 2025) e v22 GA Re-Release (Build 411, 20.01.2026): Release Notes: SFOS 22.0

Isto são GA e Maintenance Releases, não “random Nightlies”.

Para que a comparação não seja apenas uma sensação, aqui fica um breve reality check.

Fortinet: CVEs do FortiOS desde novembro de 2025 (estado em 26.02.2026)

Período: 01.11.2025 a 26.02.2026 (Published Date). Fonte: Fortinet PSIRT Advisories (visão geral PSIRT).

Não listo aqui “tudo da Fortinet” de propósito, mas sim os advisories relevantes para FortiOS/FortiGate neste período, porque é isso que dói na prática: tens de aplicar patches, planear e testar.

CVSS não é tudo, mas torna visível o contraste operacional: um Medium com 5.x é muitas vezes planeável; um 9.x rapidamente vira um “drop everything and patch”.

Publicados em 10 de fevereiro de 2026 (vários advisories no mesmo dia)

• FG-IR-25-667 (CVE-2025-55018, CVSSv3 5.2): request smuggling na GUI do FortiOS. Também é desagradável por envolver “unlogged requests”.
• FG-IR-25-795 (CVE-2025-64157, CVSSv3 6.7): problema de Format-String no modo CAPWAP Fast-Failover (Admin/Config como trigger).
• FG-IR-25-1052 (CVE-2026-22153, CVSSv3 7.5): LDAP Authentication Bypass em Agentless VPN/FSSO (workaround comum na prática: desativar unauthenticated bind no servidor LDAP).
• FG-IR-25-934 (CVE-2025-68686, CVSSv3 5.3): SSL VPN Symlink Persistence Patch Bypass. Importante para enquadrar: segundo o advisory, primeiro é necessária uma compromissão por outra vulnerabilidade ao nível do filesystem.
• FG-IR-25-384 (CVE-2025-62439, CVSSv3 3.8): Policy Bypass no FSSO Terminal Services Agent (o fix é uma combinação de versão FortiOS e versão mínima do TS Agent).

Janeiro de 2026

• FG-IR-26-060 (CVE-2026-24858, CVSSv3 9.4), published 27.01.2026: Administrative FortiCloud SSO Auth Bypass. O advisory também descreve exploitation in the wild e contramedidas concretas.
• FG-IR-25-084 (CVE-2025-25249, CVSSv3 7.4), published 13.01.2026: heap-based buffer overflow no daemon cw_acd (FortiOS/FortiSwitchManager).

Publicados em 09 de dezembro de 2025

• FG-IR-25-647 (CVE-2025-59718, CVE-2025-59719, CVSSv3 9.1): FortiCloud SSO Login Auth Bypass via crafted SAML Message (não é necessariamente default, mas existe no terreno).
• FG-IR-25-411 (CVE-2025-62631, CVSSv3 5.3): insufficient session expiration em SSL VPN (edge case de duração da sessão/mudança de password).
• FG-IR-24-268 (CVE-2024-47570, CVSSv3 6.3): sensitive information acaba em REST API Logs (se REST-API-Logging estiver ativo).
• FG-IR-24-133 (CVE-2024-40593, CVSSv3 5.9): private key pode ser lida por Admin (erro de key management, corrigível por patch level).

Publicados em 18 de novembro de 2025

• FG-IR-25-358 (CVE-2025-53843, CVSSv3 6.9): CAPWAP daemon stack buffer overflow.
• FG-IR-25-632 (CVE-2025-58413, CVSSv3 6.9): mais um CAPWAP daemon stack buffer overflow.
• FG-IR-25-545 (CVE-2025-54821, CVSSv3 1.8): trusted hosts bypass via SSH (CLI edge case).

Sim: é muita coisa. E sim: isto pode ser gerido com processos (patch window, staging, change management, janelas de manutenção).

E depois vem o outro lado.

Sophos: sem manchetes, mas a operação está a arder

Na Sophos, naturalmente, também falamos de security. Mas o que neste momento nos consome tempo são simplesmente bugs.

Temos atualmente na empresa muito trabalho desnecessário porque a firewall simplesmente causa problemas. E a certa altura dás por ti a fazer uma pergunta que, na verdade, é absurda:

O que prefiro: uma firewall com uma vulnerabilidade, mas que funciona de forma estável, ou uma firewall sem grandes manchetes de CVE que, depois do boot, já não sobe?

Isto não é um debate académico. Isto é Operations. Uma vulnerabilidade teórica que talvez um dia possa ser explorada é, tristemente, quase preferível a um cliente cuja rede fica novamente várias horas completamente down por causa de um bug banal.

Os nossos pain points atuais (sim, todos ao mesmo tempo)

E para deixar claro: estes são apenas os bugs que tivemos várias vezes nos últimos meses e em sistemas diferentes. É simplesmente desgastante e frustrante quando a operação vira projeto. Sobretudo quando se entra outra vez no carrossel do suporte Sophos e ali se finge muitas vezes que somos “o primeiro e único cliente no mundo com exatamente este problema”. Não, não somos.

• A firewall às vezes não arranca corretamente depois de um boot.
• O cluster HA desfaz-se ou comporta-se como Split-Brain.
• O logging torna-se subitamente pouco fiável (ou desaparece por completo).
• Certificados Let’s Encrypt não são renovados e alguém tem de intervir manualmente à noite.
• Uma interface falta ou deixa de estar visível na GUI.
• SSDs morrem (hardware avariado).
• O login WebAdmin entra em greve total - já não se consegue autenticar, muitas vezes só um reboot ajuda.
• Interfaces desaparecem subitamente da config.
• A Log-Disk enche, o que provoca mensagens de erro ou faz parar diretamente serviços afetados.

O que a Community diz sobre isto (não estão sozinhos!)

Quando se olha para a Sophos Community (estado no início de 2026), o quadro da qualidade em queda infelizmente confirma-se. Aos nossos problemas juntam-se, em v21.5 / v22, outros showstoppers pesados para outros utilizadores:

• Perfis SSL-VPN quebrados (v22.0 Build 411): alguns utilizadores relatam que, após upgrade para a v22 mais recente, a criação de perfis SSL-VPN falha. Em parte tiveram de fazer rollback para v21.5, porque a nova versão era simplesmente demasiado propensa a erros.
• SNAT / acesso a webserver quebrado (v22.0 Build 365): há relatos de que, após update, o acesso externo a webservers internos quebra. Muitas vezes o routing de internet falha por completo até se repor manualmente o SNAT para a opção Standard-MASQ.
• CLI Spam / “Invalid rule id”: na consola surgem massas de avisos como “Invalid rule id or family for update”. Parece ser “apenas” um erro de apresentação, mas inunda os logs sem sentido.

E o amargo nisto tudo: cada uma destas coisas não é apenas irritante, é um risco enorme. Se faltam logs, voas às cegas. Se o HA oscila, perdes confiança no failover. Se certificados não são renovados, inventas workarounds. E workarounds são o terreno fértil para incidentes futuros.

Sophos Bugs (v21.5 a v22): aquilo que contribui diretamente para os sintomas

Menciono aqui de propósito NC-IDs concretos das Release Notes oficiais ou Known Issues oficialmente documentados, para que, como admin, possas verificar tudo de forma limpa.

TL;DR: sintoma -> o que aparece nas notes

Uma história irritada do dia a dia operacional

Estamos sentados de manhã e fazemos aquilo que se faz sempre: tratar tickets, planear changes, ler o monitoring.

E então a firewall bate à porta sem bater.

Não com uma CVE, não com um “Critical Advisory”. Apenas com o quotidiano.

Primeiro café, primeiro restart e a pergunta na cabeça: ela volta a arrancar ou não?

Se correr bem, arranca. Se correr mal, fica algures entre “Failsafe” e “está viva, mas não processa tráfego”. E enquanto ainda pensas se vais mesmo precisar outra vez da consola, abre-se o capítulo seguinte.

HA. O teu airbag. E por vezes parece que o airbag dispara enquanto estacionas.

Depois vem o logging. Todos sabemos: se não vês o que acontece, não consegues controlar. E, de repente, faltam logs, os reports estão vazios ou um serviço desaparece. Ficas ali sem saber se tens um problema de segurança, um problema de qualidade de dados ou ambos.

E depois chega o showstopper: WAF, Reverse Proxy, Let’s Encrypt.

Nem queres ser fancy. Só queres que os certificados sejam renovados e que os teus websites não gritem “connection refused” às 02:13.

E, como bónus, há uma interface “desaparecida”. Não desapareceu de verdade, apenas desapareceu na UI. O tráfego talvez até continue a passar, mas tu não vês aquilo que precisas de debugar.

A certa altura fazes a pergunta que, na verdade, é absurda:

O que prefiro: uma firewall com uma vulnerabilidade, mas estável, ou uma firewall sem grandes manchetes de CVE que, operacionalmente, me abre novos buracos no chão todas as semanas?

1) Boot, reboot, upgrade: “ainda vive, mas não trabalha”

Quando uma firewall não arranca bem depois de um boot, isso não é simplesmente “uptime”. É um dia perdido mais risco, porque numa situação dessas acabas por fazer coisas que normalmente nunca farias.

Alguns exemplos das SFOS 21.5 Release Notes:

• Failsafe no restart: NC-151715 (Firmware Management): o auxiliary device entrou em Failsafe ao reiniciar; o restart falhou.
• Tráfego para após upgrade: NC-152641 (Firmware Management): depois do upgrade (21.0 MR1 Build 237), deixou de haver processamento de tráfego (SWAP Memory Config Changes).
• Kernel Panic: NC-123910 (Firewall): kernel panic issue.

E sim: o SFOS 22.0 acrescenta ainda um fator de upgrade. A Sophos indica nas Release Notes que a v22 traz alterações arquiteturais e que, em casos raros, podem ser necessários passos manuais adicionais. É exatamente esse tipo de edge case de upgrade que dói em operação.

2) HA: o airbag que dispara ao estacionar

HA é a tua rede de segurança. E é precisamente por isso que dói tanto quando os edge cases escalam aí.

Das Release Notes do SFOS 21.5 (seleção):

• HA Event Tracking para em restarts simultâneos: NC-142962 (HA).
• Firmware Upload no passivo fica preso: NC-132291 (HA).
• Failover leva a restart loop: NC-147307 (HA) (nas notes explicitamente, por exemplo, XGS 2300).
• Sync falha depois de Power Outage: NC-147739 (HA).
• HA Status flapped, crash dump em Dedicated Link: NC-149039 (HA).

3) Logging e reporting: quando voas às cegas

Para mim, este é o ponto central de por que “bugs” não são simplesmente “operação”. Quando logging/reporting falha, isso é um problema de segurança.

Das Release Notes do SFOS 21.5 (seleção):

• Logging/Reporting para esporadicamente; Garner coredump frequente: NC-158526 (Logging Framework).
• Garner e fwcm-heartbeatd param: NC-160962 (Logging Framework).
• Depois do upgrade: sem reports: NC-157663 (Logging Framework).
• Log Viewer perde events por DB Corruption: NC-169237 (Logging Framework).
• Syslog fd corruption, dados vão para o FD errado: NC-135594 (Logging Framework).

Além disso, na Sophos Known Issues List (KIL) há alguns pontos que, no dia a dia, doem da mesma forma:

• Log Viewer não mostra dados novos (active.db em falta): NC-175936 (Logging Framework). Em alguns sistemas 21.5.1, a active.db em /tmp/eventlogs/ pode faltar. O Log Viewer “congela”, embora o tráfego e as funções de segurança continuem a correr. Segundo a KIL, isto está corrigido na v22 e deverá entrar num fix de 21.5 MR2.
• False Positive “advanced threat detected” em HA: NC-170292 (Logging Framework). O Sophos Central pode enviar um alerta em deployments HA, incluindo raw logs na descrição. Workaround segundo a KIL: reiniciar o serviço Garner. KBA: https://support.sophos.com/support/s/article/KBA-000043672?language=en_US
• ReportDB_v9 mostra STOPPED (parece dramático, mas não é): NC-166381 (Reporting). Depois de upgrade para v21.0 GA ou posterior, o serviço aparece como STOPPED após um período muito específico. Segundo a KIL, isto é expected e não tem impacto operacional, porque diz respeito apenas ao legacy reporting anterior à v21.

E aqui entra o “fator Sophos Central”: se usas o Central como Single Pane of Glass, um problema de logging dói a dobrar. Se a pipeline local de logging (Garner/DB) cai, o upload para Central Firewall Reporting (CFR) também pode parar ou ficar preso. E o CFR, por si só, nem sempre é “realtime”. Ou seja: no pior caso, não faltam apenas os logs locais, falta também exatamente a visão central em que querias confiar no dia a dia.

4) WAF e Let’s Encrypt: serviço público, mas sem drama, por favor

Quando certificados não são renovados e o Reverse Proxy enlouquece, isso não é “um pequeno bug”. É impacto direto no cliente.

Nas SFOS 21.5 Release Notes encontras uma família inteira de problemas WAF/Let’s Encrypt:

• Criação de certificado Let’s Encrypt falha: NC-148937 (WAF).
• LE Request falha porque falta Auto-Firewall-Rule: NC-152022 (WAF).
• Invalid LE Config faz o Reverse Proxy reiniciar constantemente: NC-140663 (WAF).
• ACME não emite certificados para IPs: NC-141062 (WAF).
• WAF Rule alterna automaticamente entre on/off: NC-152540 (WAF).

Depois há temas que parecem bug, mas são tradeoffs de segurança. Exemplo da KIL:

• Encoded slashes (%2F) em URLs: WAF devolve 404: NC-159041 (WAF). Se a tua app usa encoded slashes na URL, o Apache bloqueia isso por defeito (a directive AllowEncodedSlashes está por omissão em No) e vês 404, embora o backend “até tenha” esse caminho. Contexto: encoded slashes podem contornar restrições de caminho (exemplo clássico: .../something%2F..%2Fadmin). Detalhes: https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

E se queres saber como isto se parece no terreno: neste thread da Community, alguém descreve que, depois de upgrade para 21.5.x, certificados Auto-Renew tinham “desaparecido”, o WAF não arrancava e websites morriam com ERR_CONNECTION_REFUSED. A solução acabou por ser limpar as Web Protection Rules e apagar LE CSRs corrompidos; depois voltou a funcionar. (Thread: WAF/Let’s Encrypt nach Upgrade, ERR_CONNECTION_REFUSED).

E por vezes nem é um “bug”, mas processo: na Sophos Community também houve casos em que os Let’s Encrypt Terms of Service apareciam no WebAdmin como expirados e tinham de ser aceites novamente. (Thread: Let’s Encrypt Terms of Service have expired).

Outro clássico de “armadilha de upgrade” da Known Issues List: um upgrade pode falhar se já existir um certificado onboard com o mesmo nome de novos certificados Let’s Encrypt introduzidos no CA Store (NC-146082).

5) “Uma interface falta” (ou só está invisível)

Este é o tipo de bug que soa seco numa Release Note, mas que na prática te obriga a voar às cegas.

Documentado oficialmente como Known Issue:

Se uma interface física ou lógica no SFOS 21.5 GA e posteriores tiver uma designação que termine com 10 ou mais números (exemplo nas notes: VLAN_1234567890), então, no WebAdmin em Network > Interfaces, interfaces físicas podem não aparecer ou interfaces lógicas podem não ser expandidas. Importante: segundo as Release Notes, a função não é afetada, apenas a apresentação na WebAdmin Console.

Balanço intermédio (até aqui): boot/upgrade, HA, logging/reporting, WAF/Let’s Encrypt e até a UI podem atrapalhar-te ao mesmo tempo. A partir daqui vêm os temas que primeiro parecem “detalhes de rede”, mas que são igualmente caros em operação: Entra SSO, interoperabilidade VPN e traffic drops aparentemente aleatórios.

6) Identity/SSO (Entra) e Captive Portal: quando o acesso parece “random”

Esta é a categoria de bugs especialmente traiçoeira em operação. Para o utilizador parece “a minha conta está estranha”. Para ti parece “é só SSO”. Na verdade, muitas vezes é a firewall no meio.

Alguns temas abertos da KIL quando Microsoft Entra ID (Azure AD) está no mix:

• Sophos Connect VPN: Conditional Access não totalmente suportado: NC-167126 (Authentication). Depois do primeiro MFA challenge no primeiro login, os Conditional-Access-Checks não são necessariamente aplicados em cada ligação posterior. Segundo a KIL, nova policy enforcement só acontece quando o utilizador termina sessão manualmente no Sophos Connect Client.
• VPN SSO: UPN e Email diferentes, login falha: NC-157635 (Authentication). Quando Email-ID e UPN no Entra são diferentes, os utilizadores conseguem aceder ao VPN Portal, mas não ao SSL VPN ou ao IPsec Portal. Causa segundo a KIL: o OAuth Header fornece Email, que depois é interpretado como UPN.
• Captive Portal: Entra SSO Users precisam da Primary Group na rule: NC-167130 (Authentication). O acesso à internet só funciona se usares a Primary Group no Firewall Rule Match (Secondary Groups não contam aqui). Fix segundo a KIL nas “next maintenance releases”; workaround: fazer match explícito da Primary Group ou usar regras baseadas em utilizador.
• Erros ocasionais “no permission” com Entra SSO: NC-167128 (Authentication). Pode ocorrer quando Entra ID Auth e On-Prem AD Auth são usados em paralelo (Token-Reuse). Workarounds segundo a KIL: apagar cookies do browser ou “force re-logon” no Sophos Connect Client. Em alternativa, usar uma única forma de autenticação de modo consistente.

7) VPN/IPsec Interop: upgrades falham muitas vezes no “outro lado”

Dois temas da KIL que não começaram apenas com a 21.5, mas continuam relevantes em 21.5/v22 quando tens clientes antigos ou peers no terreno:

• IPsec IKEv2: túnel não sobe (Fragmentation/PMTU): NC-136352 (IPsec). A partir da 20.0 MR1, o perfil IKEv2 por defeito pode gerar pacotes maiores (mais campos default), por vezes acima de 1500 bytes. Se fragmentação/PMTU no caminho estiver mal (fragments são dropped), o túnel S2S não sobe. Mitigação segundo a KIL: reduzir os DH Groups no perfil IPsec (mínimo 4) ou configurar exatamente o(s) grupo(s) usado(s) pelo peer.
• SSL VPN/OpenVPN 2.6.0: incompatibilidade com clientes EoL/UTM9: NC-128116 (SSLVPN). A partir da 20.0 MR1, o OpenVPN está em 2.6.0. Com isso, quebram, entre outros, Site-to-site SSL VPNs com versões antigas de SFOS (18.5 e anteriores), clientes SSL VPN legacy (EoL) e UTM9 OS. Recomendação segundo a KIL: atualizar ambos os lados ou migrar para IPsec/RED; no acesso remoto: usar Sophos Connect ou clientes OpenVPN atuais.

8) Traffic drops sem regra clara: Accurate ECN como causa desagradável

Quando o tráfego parece cair de forma “random”, procuras primeiro em regras, IPS, TLS Inspection e routing. E depois de upgrades de firmware há outro clássico: a IPS engine (Snort) ou as assinaturas ficam mais rigorosas, bloqueiam tráfego legítimo e não encontras logo um evento de log claro. Depois passas horas a debugar “routing” ou “regras”, quando no fim é trabalho de policy ou tuning.

Na KIL existe também um candidato que te pode ocupar durante muito tempo se não o tiveres no radar:

• Tráfego é dropped por causa de Accurate ECN Bits: NC-169842 (Firewall). Accurate ECN define TCP Bits (ECE/CWR/NS) de outra forma (RFC 7560). Segundo a KIL, o kernel interpreta isso como “reserved bit set” e descarta o tráfego. Para isolar, ajuda olhar para o lado do cliente: na prática, isto pode aparecer mais em kernels Linux recentes ou clientes Apple, porque tendem a usar RFC 7560/Accurate ECN de forma mais ativa (“por que só os MacBooks caem?”). RFC: https://www.rfc-editor.org/rfc/rfc7560

9) v22 GA Re-Release Build 411: por que isto foi necessário

Em 20 de janeiro de 2026, a Sophos lançou novamente a v22 GA como Re-Release (Build 411) para corrigir “rare and isolated issues”. A lista lê-se como um best-of de “trabalho desnecessário na change window” (fonte: blogpost da Sophos Community sobre o Re-Release):

• NC-171003: WebAdmin inacessível via Bridge Interface com VLAN filtering.
• NC-170987: CLI Spam Log “Invalid rule id or family for update”.
• NC-170970: DNAT Traffic falha quando a DNAT Rule tem um outbound interface específico.
• NC-171600: SSL/TLS Widget e Session Chart Data errados/vazios.
• NC-172197: impossível adicionar configuração SNMP.

Blogpost: v22 GA re-release (Build 411) is now available.

O dano real: bugs tornam a segurança mais cara

O ponto não é “bugs são piores do que CVEs” ou o contrário.

O ponto é: se a tua operação treme, a segurança fica automaticamente pior.

• Fazes upgrades mais tarde porque tens medo do próximo regression bug.
• Desligas funcionalidades (“não precisamos disto agora”) porque dão trabalho.
• Perdes observability (logs), logo perdes velocidade de reação.
• Investes tempo em apagar fogos em vez de segmentação, backups e regras limpas.

E há um ponto completamente subestimado na prática: Time-to-Resolution. Numa CVE, normalmente tens advisory, mitigation e fix. Num bug, o ónus da prova cai rapidamente no admin: tcpdump, CTR-Logs, Advanced-Shell-Export, “já reiniciou?” - enquanto a produção arde. Só depois entras no carrossel do suporte: escalar, esperar por um hotfix ou pelo próximo MR. Isso consome tempo de Ops adicional que não estava planeado.

É por isso que a pergunta “Prefiro uma falha, mas estável?” é humana, mas na verdade é o desvio errado:

Não é apenas “a falha” que é um problema de segurança. Também “a firewall instável” é um problema de segurança.

O que tiramos daqui (para não escalar por completo)

Algumas coisas que nos ajudam a limitar a loucura sem reinventar a roda todas as semanas:

Upgrade-Preflight (antes de começar)

• Tratar backups como restore: exportar configuração, guardar offline, testar restore pelo menos uma vez.
• HA-Status “verde” não chega - testem o failover! Segundo a GUI, no nosso caso o sync estava ok e o heartbeat limpo. Mas, no caso real, a Auxiliary Appliance não assumiu o failover corretamente. Um visto verde no WebAdmin infelizmente não é garantia de que funcione na change window.
• Verificar logging: syslog/collector externo recebe events, sem lacunas, hora/NTP correta.
• Verificar certificados/WAF: datas de expiração, validação Let’s Encrypt, certificado fallback como plano B.
• Testar SSO/VPN de verdade: Entra Login, Captive Portal, Sophos Connect, SSL VPN, IPsec S2S (incluindo failover) são casos de teste próprios.
• Break-Glass ready: consola/out-of-band, admins locais, firmware images para rollback.
• Não esquecer o Dual-Boot (e não o sobrestimar): a Sophos tem duas partições de firmware. Quando um upgrade corre mal, o rollback para 21.5 muitas vezes é apenas um reboot com seleção da outra partição. Mas também há casos em que a segunda partição não arranca corretamente e só um reimage ajuda (algo que o suporte, pelo menos na sensação, pede muito depressa). E mesmo um reimage nem sempre resolve a causa real.

Durante o upgrade (quando HA está em jogo)

• Primeiro Passive/Secondary, depois failover, depois Active.
• Depois de cada passo, validar rapidamente: tráfego, VPN, DNS, logging, WAF/Reverse Proxy.

Em operação contínua

• Testar HA, não apenas configurar: failover drills e critérios claros para quando separar um cluster.
• Tratar logging como produto: alarmes para lacunas nos logs, service health, export de emergência via CLI quando a UI falha.
• Monitorizar certificados ativamente: renewal não é “nice to have”, é risco operacional. Tratar alterações de ToS como changes.
• Health Check como indicação, não como KPI: na v22, a Sophos introduziu o Health Check (detalhes no meu artigo Sophos Firewall v22 Health Check - visão geral completa). É bom como checklist de best practices, mas por vezes parece “colocar o interruptor do ecossistema em verde”. Exemplo prático: muitos ativam o login disclaimer apenas para que o visto no Health Check fique verde. O que me falta ali são indicadores operacionais duros, como “a Logging/Reporting-DB está saudável?” ou “como está o SSD?” - precisamente porque algumas appliances tiveram problemas de storage mais cedo do que o esperado.

Conclusão: quando a ferramenta se torna um risco

No fim do dia, estamos todos no mesmo barco. Gerimos infraestrutura crítica e precisamos de poder confiar que as ferramentas que deveriam proteger-nos do caos não são elas próprias a causa do caos. Com a qualidade atual do firmware (v21.5 / v22), a Sophos tem claramente trabalhos de casa enormes para fazer. A confiança em “releases estáveis” levou uma pancada forte, tanto para nós como para muitos outros na Community.

Não quero uma firewall que seja “segura ou estável”. Quero - não, eu preciso - de uma firewall que seja ambas as coisas.

Até a Sophos voltar a controlar estas falhas de qualidade, só nos resta uma coisa em Operations: ser ainda mais disciplinados, deixar de confiar cegamente em “vistos verdes” na UI e tratar bugs banais no planeamento de deployment com a mesma seriedade que CVEs críticas.

Até à próxima,
Joe