Sophos Firewall: boas práticas de segurança de rede

Durante muito tempo, as firewalls foram o local onde se bloqueavam ataques. Hoje, elas próprias são um dos alvos mais atrativos. Isto é lógico: uma firewall está numa posição privilegiada entre Internet, redes de filiais, serviços cloud, acessos VPN e aplicações internas. Quem encontra aqui uma vulnerabilidade, uma palavra-passe fraca ou uma configuração incorreta já não está à porta, mas muitas vezes dentro do edifício.

Por isso, já não basta olhar para uma firewall apenas como um motor de policies para regras Allow e Deny. A segurança de rede moderna precisa de três pilares: hardening, protection e detection and response. É necessário reduzir a superfície de ataque antes de um ataque, bloquear corretamente durante o ataque e depois perceber rapidamente o que aconteceu.

Trabalho há muitos anos com ambientes Sophos Firewall de dimensões e setores muito diferentes. As recomendações seguintes não são, por isso, uma lista teórica de funcionalidades, mas sim aquilo que se tem comprovado repetidamente em ambientes reais de clientes, migrações, auditorias e casos de suporte.

Porque as firewalls estão tanto em foco

Uma firewall é um alvo valioso para atacantes porque é exposta, privilegiada e muitas vezes crítica para o negócio. Além disso, muitos ambientes operam firewalls, portais VPN ou acessos de gestão remota durante anos. Nem todos estão devidamente corrigidos, nem todas as superfícies de gestão estão realmente isoladas e nem todos os logins estão protegidos por multi-factor authentication.

Na prática, surgem sobretudo três causas recorrentes em ataques bem-sucedidos:

• Vulnerabilidades em firewalls e sistemas edge, especialmente quando patches são instalados tarde ou não são instalados.
• Credenciais comprometidas e ataques de identidade, frequentemente sem MFA ou com uma configuração MFA fraca. O Sophos Active Adversary Report 2026 identifica causas relacionadas com identidade como root cause em 67.32% dos casos analisados.
• Sistemas expostos, como RDP, portais VPN, User Portals ou interfaces de administração diretamente acessíveis a partir da Internet.

A ideia principal é esta: muitos ataques hoje já não são “intrusões” espetaculares. Muitas vezes, os atacantes simplesmente iniciam sessão. Se uma conta de utilizador, uma palavra-passe de admin ou um acesso VPN estiver comprometido, o primeiro passo parece inicialmente utilização legítima para a firewall.

Os três pilares da segurança de rede moderna

A Sophos descreve a proteção de redes modernas como um espectro de proativo a reativo:

1. Hardening: reduzir a superfície de ataque, remover sistemas obsoletos, usar produtos seguros, verificar configurações e limitar acessos.
2. Protection: bloquear ataques, controlar tráfego cifrado e usar Web, IPS, Zero-Day e Application Control de forma sensata.
3. Detection and Response: detetar anomalias, isolar dispositivos comprometidos, correlacionar dados de ameaça e responder automaticamente.

Muitas firewalls são tradicionalmente fortes no segundo pilar. Bloqueiam tráfego, inspecionam pacotes, reconhecem padrões conhecidos e aplicam policies. Isso é importante, mas já não é suficiente. Se a própria firewall estiver mal configurada, se Remote Access funcionar sem MFA ou se um sistema sem patch continuar produtivo, existe um problema estrutural que nenhuma regra IPS isolada resolve de forma limpa.

A minha experiência mostra que os melhores resultados não vêm de uma única função mágica, mas de uma configuração base limpa, revisões regulares e uma firewall integrada no processo de segurança global.

Pilar 1: Hardening antes do ataque

Hardening é a parte do trabalho de segurança que raramente recebe aplausos, mas que faz a diferença num incidente. Trata-se de reduzir superfície de ataque, sistemas antigos, caminhos de gestão abertos e dependência de reações manuais.

Reduzir infraestrutura e remover sistemas antigos

A forma mais simples de reduzir uma superfície de ataque é por vezes a mais desconfortável: desligar coisas. Cada appliance antiga, serviço VPN esquecido, portal de gestão e servidor sem suporte é um ponto de ataque adicional. São especialmente críticos os sistemas na borda da rede ou que permitem indiretamente acesso privilegiado a redes internas.

Para admins Sophos Firewall, isto significa concretamente:

• Verificar regularmente quais firewalls, REDs, gateways VPN, controladores WLAN, reverse proxies e componentes Remote Access ainda estão produtivos.
• Remover sistemas end-of-life ou end-of-support de posições privilegiadas.
• Consolidar funções quando isso reduz complexidade: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting e central management devem estar alinhados da forma mais limpa possível.
• Documentar quais serviços têm realmente de estar acessíveis a partir da Internet.

O objetivo não é colocar o máximo possível num produto. O objetivo é evitar legacy invisível. Uma infraestrutura pequena, atual e bem controlada é quase sempre mais segura do que um ambiente grande, historicamente crescido, com muitas exceções do tipo “sempre foi assim”.

Proteger consistentemente o acesso de gestão

Uma das best practices mais importantes é simples: a Web Admin Console e o User Portal não devem estar desnecessariamente acessíveis a partir da WAN. Se a administração remota for necessária, deve ocorrer através do Sophos Central, de uma rede de gestão dedicada, ZTNA ou outro caminho controlado.

Em ambientes de clientes vejo repetidamente que o problema não é a técnica de ataque mais complexa, mas um acesso admin antigo, um portal crescido historicamente ou uma exceção “temporária” que nunca foi removida. Esses pontos pertencem a uma revisão regular da firewall.

Os seguintes pontos devem ser verificados em qualquer ambiente Sophos Firewall:

• Ativar MFA para administradores, especialmente para o admin predefinido e todas as contas com direitos extensos.
• Impor MFA para logins VPN e de portais se estes acessos ainda forem usados.
• Evitar acesso WAN à Admin Console e ao User Portal ou restringi-lo fortemente a redes de origem dedicadas.
• Configurar regras de palavra-passe fortes para utilizadores e administradores.
• Proteger SSH, idealmente com autenticação por chave pública e sem ampla exposição WAN.
• Ativar backups centrais e proteger o acesso a backups, porque backups de configuração podem conter informação sensível.
• Ativar notificações e logging para que eventos relevantes de segurança não se percam na operação diária.

O ponto dos backups é frequentemente subestimado. Um backup de firewall não contém apenas definições inofensivas, mas informação sobre redes, regras, certificados, VPNs e estruturas internas. Por isso, os backups devem ser cifrados, armazenados de forma controlada e testados regularmente.

Definir Device Access e Local Service ACL conscientemente

Quando se fala de acesso WAN, no Sophos Firewall é preciso falar concretamente de Device Access e Local Service ACL. Na matriz Device Access define-se por zona quais serviços locais da firewall são acessíveis: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, portais VPN e outros serviços.

A best practice é simples, mas eficaz: a partir da zona WAN só deve estar acessível o que é realmente necessário. Acesso admin, SSH e User Portal não devem estar amplamente expostos na Internet. Se forem necessárias exceções, estas devem ser limitadas através de Local Service ACL Exception Rules a endereços IP de origem concretos ou redes de gestão.

Regras por país como proteção mínima

Se endereços IP de origem fixos não forem realistas, recomendo trabalhar pelo menos com regras por país. Acesso apenas a partir de poucos países relevantes continua a ser muito melhor do que acessibilidade mundial. Em alternativa, podem bloquear-se países com os quais a empresa não tem relação e onde colaboradores ou admins normalmente não se encontram. Isto não substitui MFA, roles fortes e ACLs limpas, mas reduz ruído desnecessário e muitas tentativas automatizadas.

Do meu ponto de vista, este é um dos primeiros pontos em qualquer firewall review. Muitas configurações arriscadas não surgem por má intenção, mas porque um serviço foi aberto temporariamente para uma migração, um caso de suporte ou um teste e nunca voltou a ser fechado. Precisamente estes detalhes distinguem uma firewall que apenas funciona de uma firewall operada corretamente.

Verificar Login Security e roles admin

MFA é importante, mas a camada de login é mais do que um segundo fator. Administradores devem usar contas próprias e rastreáveis, e não trabalhar permanentemente com um full admin partilhado. Direitos baseados em roles ajudam a separar acesso de suporte, reporting ou helpdesk da administração real da firewall.

Também devem ser limitadas tentativas de login falhadas, sessões devem terminar corretamente e acessos admin devem ser restringidos a redes definidas. Um login disclaimer pode ser juridicamente útil em alguns ambientes, mas não substitui controlos técnicos reais. Mais importantes são políticas de palavra-passe fortes, sessões inativas curtas, proteção brute-force e least privilege.

Evitar patch fatigue: Hotfixes têm de agir rapidamente

Patching é um daqueles temas em que teoria e prática estão muito distantes. Claro que qualquer admin sabe que atualizações firmware são importantes. Na realidade, porém, significam janelas de manutenção, avaliação de risco, planeamento HA, comunicação com departamentos de negócio e por vezes downtime. Isto leva a patch fatigue: updates são adiados porque dão trabalho.

É aqui que o fator tempo se torna perigoso. Ataques de identidade são hoje a root cause dominante, mas exploração de vulnerabilidades continua a ser um vetor real, especialmente em sistemas edge como firewalls, VPNs e outros serviços próximos da Internet. O Sophos Active Adversary Report 2026 cita como exemplo CVE-2024-40766 em SonicOS, visível em grande parte dos casos de exploit confirmados no conjunto de dados. Ao mesmo tempo, o tempo mediano entre advisory ou patch do fabricante e exploração observada foi de 322 dias. É um sinal claro: patch fatigue não é um problema operacional abstrato, mas uma janela de ataque.

Sophos Firewall dá aqui um passo importante: Automated Hotfixes permitem live patches de segurança sem janela de manutenção clássica. Para admins, isto é extremamente valioso, porque o efeito crítico de proteção não espera pela próxima janela disponível.

Ainda assim, Hotfixes não substituem uma estratégia de update limpa. Fecham a lacuna perigosa entre vulnerabilidade descoberta e firmware upgrade regular. A best practice é portanto:

• Manter Hotfixes ativados.
• Verificar regularmente versões firmware e documentar a preparação de firmware update.
• Ler previamente caminhos de upgrade e compatibilidade.
• Preparar backups e plano de rollback.
• Planear clusters HA e sites remotos separadamente.

Não tratar VPN como prova de confiança

Remote Access VPN foi o standard durante anos. O problema: VPN clássica pensa muitas vezes em redes, não em aplicações. Quem se liga com sucesso encontra-se, do ponto de vista de muitos ambientes, já numa zona de confiança. Se o endpoint estiver comprometido ou credenciais forem roubadas, um atacante pode mover-se a partir daí.

Zero Trust Network Access (ZTNA) não resolve isto por magia, mas por um princípio melhor: Trust nothing, verify everything. O acesso não é concedido genericamente a uma rede, mas avaliado por utilizador, dispositivo, estado e aplicação. Um dispositivo deve estar saudável e compliant, a identidade deve ser verificada e a policy decide granularmente que aplicação é acessível.

ZTNA não é uma decisão automática Sophos

O ponto importante é este: ZTNA não é uma decisão que tenha automaticamente de significar Sophos ZTNA. Conforme o ambiente, fornecedores especializados ZTNA, SSE ou SASE podem estar funcionalmente mais avançados, oferecer melhores integrações ou encaixar melhor na organização. O que conta não é o nome do fabricante, mas se identidade, postura do dispositivo, acesso aplicacional, logging e operação funcionam juntos de forma limpa.

Esta é também a minha postura geral em projetos Sophos: não escolho automaticamente Sophos para todos os temas. Se uma solução third-party para ZTNA, SSE, Threat Intelligence, SIEM ou NDR encaixar melhor tecnicamente, essa é a melhor recomendação. Uma boa arquitetura de segurança não nasce de máxima dependência de fabricante, mas de componentes bem integrados com responsabilidades claras.

Em ambientes puramente Sophos, a integração pode ainda ser interessante, porque ZTNA, Endpoint, Firewall e Sophos Central podem ser usados em conjunto. Um dispositivo comprometido ou não conforme pode perder acesso sem que um admin tenha primeiro de reconstruir regras de firewall manualmente. Vale também a pena olhar para o ZTNA Gateway no Sophos Firewall. Em ambientes mistos ou maiores, porém, deve comparar-se conscientemente e não definir automaticamente o fabricante da firewall existente como plataforma ZTNA.

Quem ainda depende muito de SSL VPN ou IPsec Remote Access deve verificar pelo menos estes pontos:

• Impor MFA para cada acesso Remote Access.
• Remover utilizadores VPN antigos ou não usados.
• Controlar importação de grupos de AD ou Entra ID para que Remote Access não seja ativado involuntariamente.
• Reduzir Split-Tunnel, redes permitidas e permissões ao mínimo.
• Planear migração gradual para uma solução ZTNA, SSE ou SASE adequada, especialmente para web apps internas, RDP, SSH, portais de administração e aplicações de negócio.

Segmentação contra Lateral Movement

Quando atacantes entram com credenciais válidas ou por um serviço exposto, a segmentação interna decide até onde conseguem mover-se. Uma firewall não deve ser apenas gateway perimetral, mas separar zonas internas corretamente: utilizadores, servidores, management, IoT, rede guest, produção, backup e sistemas especialmente críticos não devem estar cegamente no mesmo modelo de confiança.

Na prática, isto significa construir VLANs e zonas não apenas por organização, mas protegê-las com regras reais de firewall. Entre redes de utilizadores e servidores só devem ser permitidas as aplicações necessárias. Acessos de management pertencem a redes admin dedicadas. Redes IoT e de impressoras não devem comunicar livremente com servidores. Backups e domain controllers merecem regras especialmente restritivas e bom logging.

Aqui fecha-se o ciclo com a afirmação “os atacantes fazem login”. Se uma conta comprometida tiver acesso a uma aplicação, mas não a toda a rede, um incidente não se torna automaticamente uma compromissão completa.

Em novos projetos, planeio segmentação o mais cedo possível. Depois ainda é possível, mas muito mais difícil, porque aplicações, exceções e dependências históricas têm primeiro de ser desenredadas.

Tornar configurações incorretas visíveis

Uma firewall pode ser tecnicamente muito poderosa e mesmo assim tornar-se perigosa por configuração errada. Regras demasiado amplas, objetos “Any”, autenticação fraca, policies IPS em falta, pattern updates desativados ou portais abertos são exemplos típicos. O difícil é que, em ambientes crescidos ao longo do tempo, estes riscos nem sempre se veem de imediato.

O Sophos Firewall Health Check aborda exatamente este problema. Verifica dezenas de definições contra best practices e benchmarks e mostra no Control Center onde configurações são arriscadas ou desviam de standards recomendados. Os resultados são priorizados por risco, conduzem diretamente às definições afetadas e podem ser corrigidos ou conscientemente ignorados conforme a situação.

O Health Check é especialmente útil para processos operacionais recorrentes:

• depois de um novo rollout de firewall,
• depois de grandes alterações de regras,
• antes e depois de firmware upgrades,
• antes de auditorias,
• depois de migrações de hardware antigo,
• como controlo trimestral regular.

Mas também é importante: um Health Check não substitui o pensamento dos admins. Nem todas as recomendações servem para todos os ambientes. Alguns pontos têm razões de compliance ou operação, outros são falhas claras de segurança. O essencial é avaliar desvios conscientemente e não os deixar crescer despercebidos.

Do meu ponto de vista, o Health Check é especialmente forte como ferramenta operacional contínua. Não é apenas algo para o primeiro go-live, mas um bom ponto de partida para revisões trimestrais, preparação de auditorias e limpeza de regras antigas.

Secure by Design: reforçar a própria firewall

Do meu ponto de vista, não precisamos apenas de produtos de segurança, mas de produtos de segurança seguros. É uma diferença importante. Uma firewall não deve apenas bloquear ataques contra outros sistemas, mas deve estar ela própria reforçada contra ataques.

No Sophos Firewall, isto inclui vários níveis:

• Kernel reforçado e arquitetura modernizada: a arquitetura Xstream mais recente aposta mais em isolamento, modularização, containerização e separação de privilégios. Isto reduz certas classes de vulnerabilidades e limita impactos através de melhor isolamento. Acrescem mitigations contra vulnerabilidades side-channel e CPU. Isto torna a plataforma mais robusta, mas não imune a vulnerabilidades.
• Automated Hotfixes: correções de segurança podem ser distribuídas muito rapidamente e sem janela de manutenção clássica.
• Remote Integrity Monitoring: o Sophos XDR Linux Sensor integrado pode monitorizar integridade do sistema em tempo real, como alterações de configuração não autorizadas, Rule Exports, execução suspeita de programas ou File Tampering. Isto só é valioso se a função estiver ativada, licenciada, ligada e também monitorizada em operação.
• Gestão Central segura: administração pode ocorrer via Sophos Central sem expor portas de gestão amplamente à Internet.
• Health Check: configurações de risco tornam-se diretamente visíveis.
• Backups cifrados: dados de configuração são transmitidos e armazenados protegidos.

Além disso, a Sophos aposta na monitorização proativa da base instalada de firewalls. Telemetria de firewalls pode ajudar a detetar mais cedo indícios de ataques ou manipulações. Quando um padrão se torna visível, a Sophos pode apoiar especificamente clientes ou parceiros e distribuir Hotfixes rapidamente e em larga escala.

Estes pontos são menos espetaculares no dia a dia do que uma nova regra de firewall ou um ataque bloqueado no log. A longo prazo, porém, são decisivos. Um produto reforçado reduz a probabilidade de a própria firewall se tornar o ponto de entrada. Mas não substitui um processo de patch limpo, monitoring ou revisão regular de configuração.

O que esperar de um fabricante de firewalls

Secure by Design não é apenas uma propriedade do produto, mas também uma questão de fabricante. Clientes devem esperar que fabricantes tratem vulnerabilidades com transparência, comuniquem claramente informação de lifecycle, distribuam security fixes rapidamente e construam produtos de forma a que configurações erradas e componentes comprometidos sejam visíveis o mais cedo possível.

A responsabilidade é partilhada. Fabricantes devem entregar produtos seguros e reagir de forma transparente. Clientes devem instalar updates, substituir sistemas EOL, usar MFA e verificar a operação regularmente. Ambos pertencem ao mesmo quadro.

Pilar 2: Protection durante o ataque

Hardening é a base. Depois, a firewall deve continuar a fazer aquilo para que é usada: controlar tráfego e bloquear ataques. No Sophos Firewall, isto inclui, entre outros, IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection e Threat Intelligence Feeds.

A Sophos apoia-se fortemente na arquitetura Xstream. Tráfego confiável pode ser processado de forma mais eficiente, tarefas intensivas como operações crypto passam por caminhos otimizados, e fica mais reserva de performance para tráfego de maior risco, como Deep Packet Inspection, TLS Inspection e Zero-Day Protection.

TLS Inspection é um bom exemplo do equilíbrio entre segurança e operação. Sem desencriptação, grande parte do tráfego moderno fica invisível. Com regras TLS mal planeadas, porém, surgem casos de suporte, problemas de certificados ou gargalos de performance. A best practice não é “desencriptar tudo às cegas”, mas classificar corretamente:

• primeiro grupos de utilizadores e servidores críticos,
• excluir corretamente banking, health, privacy e categorias problemáticas conhecidas,
• testar páginas de bloqueio e aviso,
• documentar distribuição de certificados,
• avaliar logs ativamente.

A minha recomendação é não iniciar TLS Inspection como projeto tudo-ou-nada. Melhor é um rollout limpo com grupos de utilizadores claros, exceções, janelas de teste e análise de logs. Assim aumenta a visibilidade sem sobrecarregar o helpdesk no primeiro dia.

Threat Feeds também pertencem a esta área de proteção. Estes feeds ajudam a bloquear IPs, domínios ou URLs maliciosos conhecidos diretamente na fronteira da rede. Em versões mais recentes do Sophos Firewall, estão muito mais integrados em Active Threat Response e mecanismos de proteção.

Threat Feeds tornam-se especialmente interessantes quando não se usam apenas listas genéricas, mas feeds third-party curados com contexto atual. Um exemplo é Cybora.io, onde IPs e domínios maliciosos de diferentes fontes e telemetria de firewalls são consolidados em feeds utilizáveis. Descrevi em mais detalhe como estes feeds podem ser usados em firewalls no artigo Threat Intelligence Feeds para a firewall.

Também aqui se aplica: Threat Feeds devem ser testados e observados. Feeds demasiado agressivos, processos de allowlist em falta ou responsabilidades pouco claras podem bloquear tráfego legítimo e causar mais danos do que benefícios em operação. Bons feeds não substituem uma revisão de regras, são um componente adicional com tuning próprio.

Também não se devem esquecer os hardenings clássicos de SFOS: Spoof Protection, definições DoS adequadas e Geo-IP-Blocking podem reduzir acessos simples, ruidosos ou claramente indesejados. Isto não substitui uma policy limpa, mas retira ruído desnecessário à firewall e bloqueia caminhos de ataque que em muitos ambientes não têm finalidade legítima.

Aqui recomendo uma abordagem pragmática: controlar primeiro os grandes riscos, depois afinar gradualmente as funções de proteção e provar com logs o que funciona realmente. Uma policy sobrecarregada que já ninguém compreende não é ganho de segurança a longo prazo.

Pilar 3: Detection and Response após o primeiro sinal

A parte mais interessante da segurança de rede moderna é a resposta. Uma firewall não deve trabalhar isoladamente, mas usar sinais de Endpoint, Server, NDR, MDR, XDR e Threat Intelligence. A Sophos pode tirar partido de vantagens de ecossistema, mas apenas se estas integrações se adequarem realmente ao ambiente.

Ecossistemas só ajudam quando encaixam

Synchronized Security e Security Heartbeat são boas ideias: a firewall pode considerar o estado dos endpoints e limitar ou bloquear comunicação de dispositivos comprometidos. Na realidade, porém, cada vez mais empresas usam Microsoft Defender ou outras soluções endpoint. Então esta parte do ecossistema Sophos funciona apenas de forma limitada ou não funciona. Por isso não se deve escolher automaticamente tudo do mesmo fabricante só porque é oferecido como ecossistema integrado.

A minha recomendação é clara: decisivo é o que se adequa à empresa e pode ser implementado corretamente. Se Microsoft Defender, outro EDR, um NDR third-party ou um SIEM externo forem a melhor base, a firewall deve ser integrada de forma limpa nessa arquitetura. Mais importante do que cross-selling é que logs cheguem ao sítio certo, alertas sejam compreendidos e alguém verifique regularmente o que os sistemas reportam. Sem análise de logs, tuning e processo de incidentes, mesmo a melhor integração ajuda pouco.

Com Active Threat Response, ameaças detetadas podem ser traduzidas automaticamente em decisões de rede. E com NDR Essentials, a firewall obtém visibilidade adicional sobre tráfego de rede suspeito, também onde não está instalado um agente endpoint clássico.

Automação precisa de runbooks

Automação precisa de guardrails. Deve estar claro que sinais podem bloquear automaticamente, quem remove um isolamento, como false positives são tratados e como esses processos são testados. Sem runbooks, responsabilidades e exercícios regulares, ninguém sabe num incidente se um bloqueio foi intencional, correto ou demasiado agressivo.

O que acontece num incidente? Um dispositivo comprometido pode ser isolado, comunicação C2 interrompida, exfiltração bloqueada e um analista MDR ou XDR pode acionar Active Threat Response sem primeiro construir manualmente uma regra na firewall. Isto é especialmente valioso quando um ataque é detetado fora do horário normal.

Para admins, uma coisa é particularmente importante: a resposta tem de ser suficientemente rápida. Se um analista MDR ou XDR tiver primeiro de telefonar, escrever um ticket e depois um admin local tiver de criar manualmente uma regra na sexta à noite, o tempo de resposta é demasiado longo. Resposta automatizada não significa substituir pessoas. Significa que a primeira contenção acontece imediatamente e a equipa pode investigar depois de forma limpa.

Esta automação é especialmente valiosa em equipas IT pequenas. Nem todas as empresas têm um especialista de firewall disponível 24/7. Quando Endpoint, Firewall, NDR, MDR e SIEM trabalham em conjunto de forma sensata entre fabricantes, ganha-se tempo, e tempo é muitas vezes o fator mais importante durante ataques ativos.

Checklist prática para admins Sophos Firewall

Quem quer reforçar hoje um Sophos Firewall pode começar por esta lista:

Verificar imediatamente

• Os Hotfixes estão ativados?
• MFA está ativo para administradores?
• Web Admin Console e User Portal estão acessíveis a partir da WAN?
• SSL VPN ou IPsec Remote Access estão protegidos com MFA?
• Ainda existem contas admin locais não usadas?
• Backups estão planeados, cifrados e testados?
• Device Access e Local Service ACL estão reduzidos ao mínimo?
• Serviços acessíveis via WAN estão limitados pelo menos a países relevantes ou redes de origem conhecidas?
• Pattern updates e versões firmware estão atuais?

Nas próximas semanas

• Executar Health Check e priorizar findings.
• Verificar regras antigas de firewall com “Any” em origem, destino ou serviço.
• Verificar roles admin, Login Security, session timeouts e proteção brute-force.
• Inventariar serviços expostos como RDP, SSH, servidores web, portais e regras NAT.
• Verificar zonas internas e regras VLAN contra lateral movement.
• Comparar opções ZTNA, SSE ou SASE para aplicações Remote Access típicas.
• Verificar Threat Feeds e DNS Protection.
• Ativar Spoof Protection, proteção DoS e Geo-IP-Blocking conforme o risco.
• Testar TLS Inspection de forma estruturada e implementar gradualmente.

Planear estrategicamente

• Substituir sistemas end-of-life.
• Alinhar de forma sensata operação de firewall, VPN, DNS, SD-WAN e ZTNA/SSE.
• Standardizar gestão central, reporting e alerting, por exemplo via Sophos Central, SIEM ou plataformas de segurança existentes.
• Definir export Syslog/SIEM e retenção de logs para análises forenses.
• Integrar sinais MDR/XDR/NDR no processo de incidentes.
• Introduzir revisões recorrentes de firewall hardening.

Conclusão

Network Security Best Practices não são um projeto único, mas um modelo operacional. Precisamente porque firewalls no perímetro da rede são tão privilegiadas, têm de ser regularmente reforçadas, corrigidas, verificadas e integradas na deteção.

A minha recomendação após muitos anos com Sophos Firewall é clara: uma firewall moderna tem de ser mais do que um produto de proteção. O que conta é design seguro, configurações incorretas visíveis, correções de segurança rápidas e uma resposta que, em caso de incidente, funcione com Endpoint, NDR, XDR e MDR.

Ou de forma prática: se uma firewall é tão antiga que pertence mais a um museu do que a um rack, não é apenas um risco operacional. É uma superfície de ataque. E é precisamente essa superfície de ataque que mantenho tão pequena quanto possível.

Suporte da Avanet

Se for necessário apoio no hardening de um Sophos Firewall, a Avanet pode ajudar. Como especialista Sophos de longa data, apoio equipas IT com auditorias de firewall, revisões Health Check, limpeza de regras, planeamento Remote Access e ZTNA/SSE, estratégias de update e formações.

Um olhar externo sobre acessos de gestão, configuração VPN, regras antigas, serviços expostos via WAN e estado de updates compensa muitas vezes. Muitos riscos não surgem de uma única definição errada, mas de exceções crescidas ao longo do tempo que ninguém questiona no dia a dia.

Em caso de interesse, basta uma breve mensagem através do formulário de contacto. Depois pode clarificar-se em conjunto se uma revisão compacta da firewall, uma auditoria ou uma formação faz mais sentido para o ambiente em causa.

FAQ

Links adicionais

• Avanet Blog: Sophos Firewall v22: visão geral e todas as novidades
• Avanet Blog: Threat Intelligence Feeds para a firewall
• Avanet Blog: Sophos ZTNA Gateway no Sophos Firewall
• Avanet Blog: Sophos NDR - eliminar pontos cegos na rede
• Avanet KB: Sophos Firewall Firmware Update - preparação e best practices

Fontes

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report