Sophos Firewall v23: novidades e funcionalidades

O Sophos Firewall v23 aborda várias tarefas que consomem tempo na administração diária de firewalls: pesquisar regras, identificar corretamente os utilizadores, planear atualizações e perceber por que motivo ocorreu a comutação de um cluster. Esta nova versão principal traz uma API REST e um assistente de IA, além de melhorias para WAF, DNS e DHCP.

Estado da versão: À semelhança dos anos anteriores, a próxima versão principal começa com uma fase Early Access do Sophos Firewall v23 por volta de outubro, tendo começado este ano logo a 28 de setembro de 2026. Este artigo baseia-se na EAP1. Algumas funcionalidades e detalhes ainda podem mudar até à versão final.

Algumas novidades estão disponíveis diretamente na firewall; outras exigem o Sophos Fusion ou software adicional. Há um requisito particularmente importante para o planeamento: a nova identificação de utilizadores através de Synchronized Security exige Sophos Endpoint nos dispositivos em causa e uma licença Endpoint adequada. Quem utiliza até agora apenas o Microsoft Defender ou outra solução de proteção de endpoints não obtém esta função apenas com a atualização da firewall; teria de implementar e licenciar adicionalmente o Sophos Endpoint. Quando já existem licenças Sophos, o esforço adicional depende do contrato em vigor. Explicamos os requisitos das restantes funções nas secções respetivas.

IA e automatização

API REST: automatizar a configuração da firewall

A nova API REST permite que scripts e ferramentas de gestão leiam e alterem a configuração diretamente na firewall. A autenticação é feita através de chaves de API. Uma especificação em formato OpenAPI 3.0 documenta as chamadas e os campos de dados disponíveis, facilitando a integração da interface em ferramentas existentes. O acesso é feito à própria firewall e é independente da API do Sophos Central usada para exportar e importar configurações.

Distribuir definições comuns por várias firewalls já era uma ideia central do Sophos Central Firewall Management. Os grupos de firewalls e as políticas de nível superior deveriam permitir gerir estas alterações centralmente. Na nossa experiência, porém, isso só funciona parcialmente da forma necessária para uma operação fiável. Para alterações recorrentes, preferimos por isso scripts e processos próprios, cujo funcionamento e resultado podemos controlar. A nova API REST é precisamente um complemento útil para esse fim.

Um exemplo são os objetos de rede de um novo servidor, necessários nas firewalls de várias localizações. Um script pode primeiro verificar se o objeto já existe, efetuar apenas a alteração necessária e depois voltar a ler o valor guardado. O registo mostra que firewalls foram atualizadas com sucesso e onde é preciso intervir. Isto é particularmente útil se uma localização estiver inacessível durante a alteração e tiver de ser atualizada mais tarde.

As chaves de API são geridas em Administration > API access. Herdam as permissões do administrador associado. Por isso, recomenda-se uma conta própria com um perfil de permissões adequado para automatizações. Os endereços de origem permitidos e o acesso de gestão também têm de estar configurados corretamente. O acesso deve ficar limitado aos sistemas que dele necessitam efetivamente para as suas tarefas de gestão.

Allowed IP hosts: Também na v23 só é possível autorizar endereços IP ou redes. Continua a não ser possível usar um FQDN, ou seja, um nome DNS completo. Isso não é problemático para um servidor de automatização com um IP de saída fixo. Mas, se o script for executado por trás de uma ligação cujo IP público muda, não basta indicar o respetivo nome DNS como origem autorizada. Nesse caso é necessário, por exemplo, um ponto de saída fixo ou um acesso VPN controlado. Teríamos gostado de mais flexibilidade precisamente numa interface destinada a facilitar a automatização.

O REST API guide abre na interface WebAdmin em Administration > API access. O link fica acima da lista de chaves de API, à direita, mesmo ao lado de OpenAPI.yaml. A referência pública da API do Sophos Firewall descreve os endpoints, os campos de dados e os primeiros passos da autenticação. Para uma implementação concreta, prevalece o ficheiro OpenAPI da build instalada na firewall. Antes de substituir automatizações XML existentes, deve verificar-se se todas as funções necessárias estão cobertas. O tratamento de erros, os registos e um procedimento de reversão testado continuam a ser essenciais mesmo com uma API moderna.

Assistente de IA para regras de firewall

O novo assistente do Sophos Fusion responde a perguntas sobre regras de firewall. Coloca os rascunhos de regras desativados no fim da tabela; a aprovação continua a caber ao administrador.

É uma abordagem sensata à colaboração com IA. Um pedido como «Criar um rascunho que permita acesso HTTPS da rede dos colaboradores ao servidor Web interno» pode adiantar trabalho. Antes da ativação, ainda assim, é preciso esclarecer a que objetos concretos se refere, se o acesso deve ser limitado a certos utilizadores e que verificações de segurança são necessárias.

A posição da regra é especialmente importante. Uma autorização tecnicamente correta pode não ter efeito se outra regra for aplicada primeiro. Inversamente, uma regra demasiado abrangente colocada no topo pode permitir mais tráfego do que o previsto. O assistente não toma, portanto, a decisão de segurança pelo administrador. O seu valor está em preparar o trabalho sobre as regras e facilitar a identificação de relações.

Permitir ou bloquear serviços de IA de forma seletiva

Para controlar a utilização de IA surgem a categoria Web Generative AI e filtros de aplicações relacionados com o Sophos AI Defense.

Em Diagnostics > URL category lookup é possível consultar a classificação de um domínio. Para openai.com, a firewall apresenta a categoria Generative AI. Isto ajuda na resolução de problemas: se um serviço de IA for bloqueado inesperadamente, pode verificar-se primeiro a sua categoria e depois a política Web aplicável.

Para uma empresa, uma configuração útil começa com uma decisão simples: que serviços de IA são aprovados para cada tipo de trabalho? Uma equipa de desenvolvimento pode precisar de ferramentas diferentes das da contabilidade. Só depois é possível definir uma política de rede adequada.

Um domínio permitido, no entanto, nada diz sobre a informação que pode ser introduzida no serviço. O controlo de acesso e a proteção de dados são tarefas distintas. Mesmo num serviço aprovado são necessárias regras para dados de clientes, código-fonte e documentos confidenciais. Os filtros de rede podem apoiar essas regras organizacionais, mas não substituem a análise do conteúdo de cada prompt.

Gestão de regras e utilização da interface

Nova tabela para regras de firewall

A vista em Rules and policies > Firewall rules foi profundamente revista. Em vez de pastas expansíveis, a Sophos apresenta agora as regras numa tabela contínua. O agrupamento mantém-se, mas surge na coluna Group. Acrescem pesquisa de texto livre, filtros e uma vista de colunas personalizável.

Isto resolve uma irritação da interface anterior: depois de editar e guardar uma regra de firewall, o grupo voltava a fechar-se. Para editar imediatamente a regra seguinte do mesmo grupo, era preciso abrir de novo a pasta. Ao fazer várias alterações seguidas, isso era desnecessariamente trabalhoso. Com a pertença ao grupo numa coluna, deixa de ser necessário expandir repetidamente as pastas.

Selecionar e ordenar colunas

O ícone de engrenagem acima da tabela, à direita, permite escolher as colunas visíveis. É possível ocultar informações desnecessárias, mostrar detalhes adicionais e alterar a ordem das colunas. As colunas também podem ser fixadas. Assim, por exemplo, o nome da regra permanece visível ao percorrer uma tabela larga.

Um detalhe particularmente positivo: no nosso teste, a vista escolhida manteve-se guardada depois de terminar a sessão e voltar a iniciá-la. Não é preciso reconstruir a vista em cada acesso.

Para uma vista rápida, o nome, grupo, ação, estado e tráfego são muitas vezes suficientes. Na resolução de problemas, por outro lado, interessam as redes de origem e destino, os serviços e os registos. Se, por exemplo, for necessário remover o acesso a um antigo servidor de aplicações, convém ver lado a lado os destinos das regras afetadas. Não ter de abrir cada regra individualmente poupa tempo e facilita a comparação.

Estão disponíveis as seguintes colunas. Os nomes correspondem à interface inglesa; para facilitar a leitura, estão agrupados aqui por tema:

• Regra e vista geral: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Redes e serviços: Src networks, Src zones, Dst zones, Dst networks, Services.
• Utilizadores e registos: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Funções de proteção e políticas: Email, Web policy, IPS policy, Application policy.
• Largura de banda e priorização: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Exceções: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

A vista antiga continua disponível por enquanto

O botão New design ainda permite regressar à vista anterior. Quem não se adaptar à nova tabela tem, por enquanto, uma alternativa. Ainda não se sabe durante quanto tempo a Sophos disponibilizará as duas vistas em paralelo.

Regras NAT: continuam sem agrupamento nem clonagem

Infelizmente, a Sophos não aplicou a nova vista às regras NAT. Estas continuam a ser tratadas de forma diferente na v23: não é possível agrupar nem clonar regras NAT. As regras de firewall podem ser clonadas, mas essa função continua ausente para NAT.

Seria especialmente útil ao publicar vários serviços semelhantes. Se outro servidor Web precisar de um encaminhamento quase igual, seria natural copiar uma regra NAT existente e ajustar o destino e o serviço. Em vez disso, é preciso criar a regra novamente. Isso demora mais tempo e aumenta o risco de deixar alguma das outras definições involuntariamente diferente.

Já tínhamos mencionado estes pedidos no artigo sobre o Sophos Firewall v22. A nova vista das regras de firewall é um avanço bem-vindo. É por isso ainda mais lamentável que a gestão NAT continue atrasada nestas funções básicas de utilização.

WebAdmin, número de série e estado do cluster

A interface WebAdmin utiliza HTTP/2 para acelerar a transferência dos elementos das páginas. Além disso, o número de série e o estado do cluster HA permanecem visíveis ao mudar entre páginas de definições.

O HTTP/2 pode ajudar a carregar páginas com muitos elementos, sobretudo em ligações com maior latência. Mas a rapidez percebida numa vista concreta também depende do processamento na firewall. Uma consulta lenta à base de dados ou o armazenamento de uma configuração complexa não se torna rápido apenas por mudar o protocolo de transporte. No meu primeiro teste, a melhoria de velocidade foi reduzida: guardar uma regra de firewall continuou a demorar vários segundos.

A identidade visível do dispositivo tem uma vantagem imediata: com várias sessões de firewall abertas, é mais fácil confirmar em que sistema se está a trabalhar. Antes de alterar um cluster HA, também vale a pena verificar o papel e o estado dos dispositivos envolvidos.

Quem presta suporte a vários ambientes de clientes quase idênticos conhece a breve incerteza antes de guardar uma alteração. Um número de série sempre visível facilita a comparação com o ticket sem sair da página de definições atual. É uma pequena mudança com uma utilidade muito concreta.

Alta disponibilidade: detetar mais depressa e comutar de forma mais precisa

Estado do hardware como fator de comutação

Além de ligações e serviços, o cluster HA monitoriza agora o estado de certos componentes de hardware, incluindo o SSD. Se o estado deste piorar, o cluster pode comutar para a outra firewall.

Um cluster HA só consegue responder de forma útil se detetar uma falha. Um dispositivo pode continuar acessível pelas suas interfaces de rede apesar de já ter problemas internos. A perspetiva adicional sobre o hardware é, por isso, relevante para a operação.

Um SSD defeituoso pode, por exemplo, prejudicar operações de escrita enquanto a ligação HA continua a funcionar. A monitorização apenas das ligações não detetaria o estado do disco. A monitorização adicional do hardware pode intervir antes de um nó fragilizado falhar completamente.

Mesmo após essa comutação, a causa tem de ser investigada. O segundo nó mantém o serviço, mas não repara o SSD defeituoso. O procedimento operacional inclui, por isso, verificar o dispositivo afetado, avaliar a redundância restante e, se necessário, substituir o hardware.

Janela de deteção mais curta

Com a monitorização acelerada, o cluster HA deteta a falha da outra firewall em 300 ms, em vez dos anteriores quatro segundos.

Os 300 ms referem-se ao tempo até a firewall detetar a falha do outro dispositivo do cluster. Antes de uma aplicação voltar a funcionar normalmente, podem ser necessários outros passos: a firewall restante tem de assumir a operação, os equipamentos de rede vizinhos têm de encaminhar o tráfego pelo caminho certo e as ligações existentes têm de continuar ou ser restabelecidas.

Por isso, um teste representativo deve observar mais do que um ping. Uma chamada telefónica em curso, uma transferência de ficheiros e uma ligação VPN revelam efeitos diferentes. Só essas medições mostram se a comutação é suficientemente rápida para os processos da organização.

Menos comutações indevidas sob carga elevada

As duas firewalls trocam regularmente breves mensagens de estado, os chamados HA heartbeats. Essas mensagens são agora prioritárias e processadas separadamente do tráfego de dados normal.

Isto responde a um problema sob carga elevada: se um sistema estiver muito ocupado, uma resposta atrasada pode parecer uma falha. Uma comutação provocada por esse atraso cria ainda mais instabilidade num ambiente já exigente.

Por isso, ambas as situações importam nos testes de aceitação: o cluster deteta uma falha real e permanece estável sob carga elevada quando nenhum dispositivo falhou? Um teste funcional sem carga só responde à primeira parte desta pergunta.

Segurança DNS, hotfixes e firmware

DNS over HTTPS e DNSSEC

A firewall pode agora enviar consultas DNS cifradas por HTTPS para um resolvedor e validar respostas DNS com DNSSEC. Também é mais fácil ativar o Sophos DNS Protection.

As duas tecnologias DNS resolvem problemas diferentes. DNS over HTTPS, ou DoH, cifra o transporte até ao resolvedor. O DNSSEC serve para validar dados DNS assinados. Uma ligação cifrada, por si só, não confirma a autenticidade de uma resposta DNS; e uma assinatura válida não esconde a consulta de observadores no percurso de transporte.

Antes da implementação, deve compreender-se o percurso DNS existente. O cliente consulta a firewall, um servidor DNS Windows interno ou diretamente um resolvedor público? Os espaços de nomes internos têm de continuar a ser resolvidos no local certo. Para isso, por exemplo, as DNS Request Routes continuam a ser relevantes.

Os browsers com as suas próprias definições DoH também merecem atenção. Se um cliente utilizar outro resolvedor, o seu percurso DNS real pode não corresponder à configuração central pretendida. Um teste funcional deve, por isso, abranger nomes internos, resolução externa e as decisões de filtragem desejadas.

Hotfixes e atualizações de segurança visíveis

Ao analisar a interface, reparámos noutra mudança: em Backup & firmware volta a existir uma área própria para hotfixes. O separador chama-se Hotfix: Security updates. Anteriormente, a definição dos hotfixes situava-se na área Firmware. Aí era possível escolher, através de uma caixa de seleção, se os hotfixes importantes deveriam ser instalados automaticamente. Depois de essa definição ter desaparecido da interface, os hotfixes voltam agora a ter um lugar visível.

A nova vista mostra o estado das atualizações de segurança. O antigo interruptor de ativação não aparece no ecrã apresentado. A ausência temporária dessa definição também não significa que a firewall tenha deixado de receber hotfixes: a instalação automática continua a existir.

Para que servem os hotfixes

Os hotfixes são correções específicas para problemas urgentes, sobretudo vulnerabilidades de segurança. Podem ser distribuídos fora das versões regulares de firmware. Assim, uma correção importante não tem de esperar pelo próximo maintenance release nem pelo planeamento de uma atualização completa de firmware na empresa.

Se, por exemplo, for descoberta uma vulnerabilidade num serviço de gestão, um hotfix adequado pode corrigir o componente afetado. A instalação automática reduz o tempo entre a disponibilização da correção e a sua aplicação na firewall. Está ativada por predefinição e deve continuar ativa na operação normal. Os hotfixes, contudo, não substituem as atualizações regulares de firmware: estas também trazem outras correções de erros, alterações em componentes e novas funcionalidades.

Consultar diretamente o estado dos patches

A interface mostra agora as vulnerabilidades corrigidas pelos hotfixes instalados. Cada entrada inclui o identificador CVE, a gravidade, a data de instalação e um link para o respetivo aviso de segurança. Estas informações também estão disponíveis nos relatórios.

Isto ajuda a responder a uma pergunta operacional frequente: uma vulnerabilidade específica já foi tratada nesta firewall concreta? O número da versão do firmware nem sempre conta toda a história quando também são distribuídos hotfixes.

Se um cliente perguntar sobre um novo aviso de segurança, o estado local pode ser demonstrado com maior precisão. Em vez de inferir a proteção apenas a partir da versão de firmware, pode consultar-se a CVE relevante e a data de instalação do hotfix e documentá-las no ticket.

Para efeitos de documentação, o estado dos patches apresentado deve ser avaliado juntamente com o aviso correspondente. Uma correção instalada responde à questão sobre essa correção específica. Não prova que todo o sistema esteja configurado com segurança nem que se possa excluir um ataque anterior. Para isso continuam a ser necessários uma revisão da configuração, uma análise dos registos e, se necessário, uma investigação.

Atualizações recorrentes de firmware

No Sophos Fusion é possível definir janelas de manutenção recorrentes em que as firewalls instalam automaticamente novas versões de firmware. Os dispositivos não têm de ser todos atualizados ao mesmo tempo. É possível atualizar primeiro firewalls selecionadas e deixar as restantes para depois. Pode haver definições diferentes para dispositivos individuais, por exemplo quando uma localização precisa da sua própria janela de manutenção.

Isto é especialmente útil em empresas com várias delegações. Por exemplo, a firewall de um pequeno escritório recebe a atualização primeiro. Depois verificam-se aí as ligações VPN, os inícios de sessão dos utilizadores e os serviços publicados. Só quando essas verificações forem bem-sucedidas avançam as restantes localizações. Assim, não é necessário iniciar cada instalação individualmente, mas mantém-se o controlo sobre a sequência.

Antes disso, deve estar definido quem verifica os resultados e interrompe as atualizações seguintes em caso de problemas. Uma instalação automática não substitui uma cópia de segurança nem um procedimento de reversão preparado. As nossas instruções sobre atualizações de firmware e cópia de segurança e restauro descrevem os passos necessários.

Identidade e autenticação

Entra ID com Synchronized User ID

Através de Synchronized Security, a firewall também consegue agora identificar utilizadores que trabalham com Entra ID. Assim, dispositivos associados ao AD local e dispositivos com identidade na cloud podem coexistir. A identificação exige Sophos Endpoint nos dispositivos afetados e uma licença Endpoint adequada.

A questão prática é como sabe a firewall qual o utilizador por trás de uma ligação. Um endereço IP, por si só, nem sempre é suficiente para uma regra baseada em utilizadores. Ao passar de um domínio local para uma identidade na cloud, esta associação tem de continuar a funcionar de forma fiável.

Um caso típico é uma empresa que associa os novos portáteis apenas ao Entra ID, enquanto os dispositivos mais antigos continuam no domínio AD local. Para a política Web da contabilidade, esta fase de transição técnica não deve fazer diferença: o que importa é o grupo do utilizador. Esta continuidade é importante numa migração gradual para a cloud.

Para o planeamento, importa distinguir esta funcionalidade do início de sessão com Entra ID já conhecido no Captive Portal. Aqui trata-se da integração com Sophos Endpoint. Por isso, ter um ambiente Entra ID não implica, por si só, que a firewall consiga identificar os utilizadores da forma pretendida. Num projeto-piloto, deve verificar-se que utilizador aparece realmente e que regra de grupo é aplicada a seguir.

Google Workspace como fornecedor de identidade

Os utilizadores podem iniciar sessão com a sua conta Google Workspace no Captive Portal, VPN Portal, Sophos Connect e na interface WebAdmin. O Google Workspace assume o papel de fornecedor de identidade e também pode exigir autenticação multifator no início de sessão.

Para organizações que utilizam o Google como diretório central de utilizadores, trata-se de um complemento importante. As contas e os requisitos de início de sessão devem, tanto quanto possível, ser geridos no mesmo local onde são geridos os restantes acessos da organização.

Uma escola com Google Workspace, por exemplo, não precisa de manter um conjunto separado de palavras-passe na firewall para o acesso VPN dos professores. Isto reduz a administração duplicada e facilita a proteção da autenticação através do fornecedor central de identidade.

Mesmo assim, uma autenticação bem-sucedida é apenas uma parte da integração. Depois, as permissões certas têm de ser atribuídas. Um colaborador comum não pode obter acesso administrativo apenas porque o SSO funciona. Os testes devem, por isso, abranger em conjunto os atributos dos utilizadores, a atribuição a grupos, os serviços permitidos e a revogação de permissões.

Configuração de MFA por e-mail

A firewall pode enviar por e-mail o código QR necessário para configurar a autenticação multifator. Se o registo não for concluído no prazo de 24 horas, o código não utilizado expira. Nas instalações existentes, a configuração anterior através do portal mantém-se inicialmente disponível.

Isto altera o processo de configuração para novos utilizadores. Antes da implementação, devem verificar-se os endereços de e-mail e a entrega das mensagens. Caso contrário, o primeiro início de sessão VPN pode transformar-se num pedido de suporte, apesar de a autenticação estar corretamente configurada.

Um código QR de registo contém informações relevantes para a segurança. Por isso, a caixa de correio que o recebe também tem de estar protegida. A equipa de suporte precisa ainda de um procedimento claro para registos expirados e endereços incorretos. Reenviar um código não pode significar que se dispense a verificação da identidade de quem o pede.

SSO em Chromebooks

Uma nova extensão para Chromebooks permite transmitir o início de sessão do utilizador à firewall sem que este tenha de voltar a autenticar-se no Captive Portal. A extensão suporta todas as versões de SFOS que continuam a ter suporte.

Os inícios de sessão repetidos no portal são particularmente inconvenientes nas escolas. Mas o essencial aí não é apenas o primeiro início de sessão bem-sucedido; também importa a mudança de utilizador e de dispositivo. Um teste com Chromebooks partilhados deve mostrar que uma associação antiga não continua a ser usada após uma mudança de utilizador.

Como a extensão foi concebida para funcionar com várias versões, a sua implementação deve ser planeada separadamente da atualização para v23. Implementar ao mesmo tempo um novo componente de cliente e um novo firmware da firewall dificulta a identificação de eventuais problemas.

Servidores de terminais: associação de utilizadores com XDR Sensor

Para Sophos Authentication for Thin Client, ou SATC, pode ser utilizado um XDR Sensor leve. Ajuda a firewall a atribuir o tráfego de rede num servidor partilhado aos respetivos utilizadores e pode funcionar em conjunto com uma solução de proteção de endpoints existente.

Num servidor de terminais, muitas sessões partilham o mesmo IP do servidor. Uma regra baseada no IP não distingue, por isso, a contabilidade de um colaborador externo no mesmo host. Para regras Web ou de firewall baseadas em utilizadores, é necessária uma associação adicional.

A possibilidade de utilizar um sensor ao lado de um produto de proteção existente é interessante para ambientes mistos. Isso não constitui, no entanto, uma garantia geral de compatibilidade para todas as combinações. É preciso verificar antecipadamente a licença, o sistema operativo e a interoperabilidade suportada. O teste funcional deve incluir pelo menos dois utilizadores com sessões simultâneas sujeitos a regras diferentes. Os efeitos no próprio servidor de terminais devem ser avaliados separadamente das decisões da firewall.

WAF: maior controlo sobre aplicações publicadas

Ações diferentes por caminho URL

O Web Application Firewall passa a ter ações por caminho: Protect, Block, Redirect e Passthrough. A última destina-se a WebSockets sem inspeção WAF.

Com Protect, um caminho continua sujeito à inspeção WAF. Block rejeita o acesso com HTTP 403. Redirect envia o browser para outro endereço. Passthrough é, portanto, uma exceção deliberada para o tráfego WebSocket em causa, não uma etapa adicional de inspeção.

Isto permite adaptar de forma mais precisa o tratamento de uma aplicação à sua estrutura. Após uma mudança de portal, por exemplo, /altes-portal pode redirecionar para /kundenportal, enquanto uma área desativada em /legacy é bloqueada com HTTP 403. A área principal da aplicação mantém-se sob inspeção WAF. Gerir essas decisões no ponto de acesso frontal pode reduzir alterações necessárias no backend.

Nos redirecionamentos, o destino tem de estar correto. Um caminho errado pode interromper processos de início de sessão ou links guardados; um redirecionamento imprudente pode criar ciclos. Numa exceção sem inspeção WAF, é preciso saber que proteção permanece na própria aplicação. Uma ligação funcional não demonstra que exista uma inspeção de segurança equivalente.

Mais caminhos e regras

São possíveis até 128 caminhos por entrada de caminho. O limite de regras WAF é 100 por predefinição e pode ser aumentado para 200.

No planeamento, o limite de regras e a capacidade de processamento devem ser considerados separadamente. Poder configurar mais regras não significa automaticamente que um appliance consiga servir qualquer número de aplicações ativas com o mesmo tempo de resposta. O processamento TLS, a inspeção, os uploads e a velocidade dos servidores backend também determinam os recursos necessários.

Por isso, uma aceitação útil utiliza pedidos típicos das aplicações reais. Uma página de teste estática, por exemplo, representa mal um portal com uploads de ficheiros grandes.

Novo processamento com Apache Event MPM

O WAF passa a usar Apache Event MPM para processar melhor os pedidos simultâneos.

De forma simplificada, o objetivo é aproveitar melhor a capacidade de trabalho enquanto certas ligações aguardam processamento adicional. Com muitos acessos simultâneos, esta distribuição é importante: nem todas as ligações abertas devem ocupar desnecessariamente recursos necessários a outros pedidos. A capacidade do backend continua a ser um limite independente.

O indicador operacional decisivo é o comportamento sob carga. Uma aplicação pode continuar tecnicamente acessível e, ainda assim, responder tão lentamente que os utilizadores desistem do trabalho. Os testes de carga devem, portanto, analisar tempos de resposta e taxas de erro, além do número de ligações bem-sucedidas.

Para uma comparação útil antes e depois, o hardware, o perfil de segurança, o backend e o tráfego de teste devem manter-se iguais. Só então é possível avaliar a diferença que o novo processamento faz na própria instalação. A mudança de arquitetura, por si só, não permite deduzir um valor universal de débito.

DHCP, encaminhamento e serviços de rede

DHCP no novo plano de controlo

O serviço DHCP corre agora no novo plano de controlo e consegue processar intervalos de endereços maiores e mais reservas. Além disso, o tráfego DHCP é inspecionado pela firewall antes de chegar ao serviço, para limitar os efeitos de uma avalanche de pedidos. Definições que antes exigiam a linha de comandos estão agora disponíveis na interface.

Isto afeta uma dependência fundamental da rede. Se os clientes não receberem um endereço, muitos outros serviços também parecem estar com problemas. Por isso, depois de uma atualização, o servidor DHCP merece uma verificação tão deliberada como a VPN ou o acesso à Internet.

O aumento de capacidade é relevante, por exemplo, numa escola em que muitos dispositivos entram no Wi-Fi quase ao mesmo tempo de manhã e pedem um endereço. Para os utilizadores, uma atribuição lenta de endereços parece rapidamente um problema de Wi-Fi. O processamento rápido das leases ajuda num ponto facilmente ignorado na resolução de problemas.

Os testes devem abranger novas leases, renovações de leases existentes e endereços reservados. Também devem estar corretos os valores transmitidos, como gateway, servidores DNS e opções DHCP específicas. As definições raramente usadas muitas vezes só se tornam visíveis quando um dispositivo especial reinicia.

A consulta dos endereços atribuídos também foi revista. As opções DHCP são tratadas de forma mais uniforme de acordo com as normas subjacentes. Por isso, as configurações especiais existentes merecem uma comparação direcionada antes e depois de uma atualização.

Entre as definições transferidas para a interface estão os reconhecimentos negativos e a limitação a uma lease por cliente. Um reconhecimento negativo indica a um cliente que não pode usar um endereço solicitado e que tem de negociar novamente a sua configuração de rede. Estas definições devem ser avaliadas segundo o desenho da rede, sobretudo quando existem vários serviços DHCP.

Refletor mDNS para Bonjour e descoberta de dispositivos

Com o refletor mDNS, os dispositivos também podem descobrir serviços noutras redes selecionadas. Funciona com IPv4 e IPv6. Para a ligação posterior ao dispositivo encontrado continua a ser necessária uma regra de firewall adequada.

Isto é relevante, por exemplo, quando as impressoras e os colaboradores estão em VLANs diferentes. A impressora pode ter um endereço correto e estar acessível em princípio, mas não aparecer na descoberta automática de dispositivos. A descoberta do serviço e a ligação de dados subsequente são dois passos distintos.

Na configuração, devem permitir-se apenas os pares de redes e serviços necessários. Uma rede de convidados não precisa de descobrir todos os dispositivos da infraestrutura interna. Depois da configuração, devem testar-se tanto o comportamento desejado como os limites: a impressora prevista é encontrada e utilizável, enquanto outros serviços internos permanecem inacessíveis.

Motor de encaminhamento e BFD experimental

A firewall utiliza uma versão atualizada do software de encaminhamento FRR. Os vários protocolos de encaminhamento podem ser geridos numa consola comum. Junta-se suporte experimental para BFD em BGP e rotas estáticas em firewalls independentes.

BFD, ou Bidirectional Forwarding Detection, serve para detetar rapidamente a falha de uma ligação entre vizinhos de encaminhamento. É uma tarefa diferente da mudança de papéis num cluster HA de firewalls. Detetar falhas mais depressa pode ajudar a transferir o tráfego mais cedo para um caminho alternativo.

Intervalos de monitorização muito curtos não são um objetivo em si. Se o equipamento remoto ou o caminho de transporte não responder de forma fiável sob carga, uma definição agressiva pode provocar mudanças de estado desnecessárias. O caráter experimental deve, por isso, ser levado a sério e BFD avaliado inicialmente num ambiente de testes adequado.

É relevante, por exemplo, em duas ligações encaminhadas entre localizações: se a interface local continuar ativa apesar de o vizinho já não estar acessível pelo caminho preferencial, o estado da ligação não basta para detetar a falha. Uma integração BFD adequada pode ajudar a identificá-la mais cedo nesta arquitetura.

IPv6 IPoE e 4in6

A firewall suporta mais variantes de ligação através de IPv6 IPoE e túneis 4in6. Inclui-se o serviço de Internet japonês Xpass.

Com 4in6, o tráfego IPv4 é transportado por uma ligação IPv6. Estas funcionalidades são sobretudo relevantes quando o fornecedor de Internet exige precisamente este modelo de ligação. Numa ligação convencional, não constituem por si só um motivo para reformular a configuração WAN.

As melhorias também abrangem endereços dinâmicos, endpoints de túneis e MTU/MSS. A interação entre estes elementos é importante para diagnosticar problemas: estabelecer um túnel com êxito não garante que pacotes grandes ou todas as aplicações funcionem corretamente. Os parâmetros do fornecedor, a resolução de nomes e os tamanhos de pacote devem, por isso, ser verificados em conjunto.

Implementação na IONOS Cloud

O Sophos Firewall pode agora funcionar também na IONOS Cloud com a imagem oficial de SFOS. A instalação é manual através de uma imagem própria, e não de uma entrada pronta no Marketplace.

No planeamento da arquitetura, continua a ser necessário definir como ligar as redes públicas e internas, como proteger o acesso de gestão e quem é responsável pelo ciclo de vida da máquina virtual. Um local de instalação suportado não responde às questões de redundância, recuperação e monitorização.

Em particular, o modelo operacional não deve pressupor tacitamente funcionalidades de um serviço de cloud totalmente gerido. Uma firewall virtual também precisa de manutenção planeada e cópias de segurança verificáveis.

Alertas de ameaças e alterações menores

Alertas NDR sem isolamento automático

As deteções de NDR Essentials e NDR Active Threat Intelligence podem gerar um alerta sem isolar automaticamente da rede o endpoint afetado.

Isto separa mais claramente a deteção da resposta. Pode ajudar na introdução de novas fontes de deteção: avalia-se primeiro a qualidade dos alertas e depois define-se que eventos devem acionar um bloqueio. O nosso artigo sobre NDR Active Threat Intelligence explica as diferenças entre os métodos.

Um alerta isolado só é útil se for tratado. É preciso definir responsáveis, tempo de resposta e via de escalamento. Também se devem verificar separadamente as ações de bloqueio que continuam configuradas em Active Threat Response. Uma alteração nos alertas não significa que todas as ações de proteção tenham sido desativadas.

Listas de conteúdo de e-mail e categorias Web

Outras alterações dizem respeito a referências baseadas em ID para listas de conteúdo de e-mail e ao controlo de versões das categorias Web.

Nas listas de conteúdo de e-mail, as Content Control Lists, a referência fica separada do nome visível. O nome ajuda as pessoas a orientarem-se; um ID estável assegura uma associação inequívoca. Já o controlo de versões das categorias Web diz respeito ao alinhamento, em segundo plano, das definições de categorias utilizadas com a Sophos.

Estes pontos são menos visíveis do que uma interface nova, mas fazem parte de um panorama completo da versão. Nas alterações e restauros de configuração, importa que uma política continue a utilizar o objeto pretendido. No filtro Web, as páginas de teste conhecidas, tanto permitidas como bloqueadas, devem continuar a receber a decisão esperada depois de uma atualização.

O eDirectory deixa de ser suportado

O Sophos Firewall v23 deixa de suportar o tipo de servidor eDirectory nativo. Uma ligação eDirectory ainda existente impede, por isso, a atualização. Como alternativas existem Entra ID SSO, Active Directory, RADIUS ou uma ligação LDAP ao servidor eDirectory atual.

Importa distinguir autenticação de identificação automática de utilizadores: o LDAP pode autenticar utilizadores no diretório existente, mas não substitui o SSO nativo do eDirectory. A ligação eDirectory anterior também não é mantida ao restaurar uma cópia de segurança ou importar uma configuração.

Descrevemos a migração e os seus efeitos sobre utilizadores, grupos e serviços no nosso guia Sophos Firewall: migrar o eDirectory antes do SFOS 23.

Conclusão

Para mim, a API REST é uma das novidades mais úteis do Sophos Firewall v23. Facilita alterações recorrentes e cria uma boa base para analisar configurações com ferramentas próprias. As API também ajudam na análise com IA: as regras e os objetos podem ser lidos de forma estruturada, comparados e examinados quanto a anomalias. Continua a caber a um administrador decidir que alterações resultam daí. Mas a recolha e preparação dessas informações, por si só, já pode poupar muito trabalho manual.

Também gosto da nova vista geral das regras de firewall. A pertença ao grupo como coluna, os detalhes livremente selecionáveis e a vista permanentemente guardada tornam o trabalho mais agradável. É pena que essa revisão não tenha chegado às regras NAT. Precisamente aí continuam a faltar o agrupamento e a clonagem, embora essas funções fossem úteis ao construir e manter configurações maiores.

Gostaria ainda de ver mais funções do Sophos Firewall Config Studio diretamente na firewall: comparar várias versões de configuração, combinar modelos de configuração e criar relatórios que, nas regras de firewall, NAT e TLS, também mostrem os valores dos objetos referenciados. Estas ferramentas ajudam a compreender e preparar alterações. Por enquanto, continuam reservadas ao Config Studio separado.

Quanto à velocidade, no meu primeiro teste não notei qualquer melhoria substancial. Guardar uma regra de firewall continua a demorar vários segundos. Numa única alteração, isso pesa pouco. Mas, ao reorganizar um conjunto de regras e editar muitas regras seguidas, os tempos de espera acumulam-se e interrompem repetidamente o fluxo de trabalho. As melhorias na interface são bem-vindas. Para a operação diária, gostaria sobretudo que as tarefas frequentes fossem mais rápidas e que as regras de firewall e NAT pudessem ser geridas de forma mais uniforme.

FAQ

Fontes

• Sophos Firewall v23: anúncio da versão, publicado em 28 de setembro de 2026.
• Sophos Firewall OS v23: Key New Features, guia técnico das funcionalidades, datado de 28 de setembro de 2026.
• Sophos Firewall v23: comentários e experiências, comentários contínuos da comunidade.