Sophos Firewall Configuration Viewer: auditar e comparar configurações

Sophos Firewall Configuration Viewer: auditar e comparar configurações

14 min read
Network Sophos

Olá a todos,

se alguma vez geriste uma Sophos Firewall num ambiente de negócio real, conheces o dilema: a configuração é a “single source of truth”. Mas no momento em que queres revê-la fora da web UI, documentá-la como deve ser, ou comparar um antes/depois de um change, torna-se rapidamente penoso.

Sim, podes tirar screenshots. Sim, podes exportar regras individuais. Mas assim que entras em mudanças maiores (migração WAN, novos VLANs, limpeza de objetos, reestruturação da lógica de NAT, “só rapidamente” ajustar umas VPNs), queres essencialmente duas coisas:

  1. Uma configuração legível.
  2. Uma comparação que não seja “fazer diff ao XML e chorar”.

É exatamente aqui que o Sophos Firewall Configuration Viewer entra.

Esta ferramenta não te tira responsabilidade. Continuas a ter de desenhar uma configuração limpa e testar mudanças corretamente. Mas remove algo que no dia a dia consome um tempo absurdo: o problema do formato. Transforma um export tecnicamente correto mas horrível de ler numa vista com a qual consegues realmente trabalhar.

E sim, sou bastante picuinhas com isto. Quando planeio um change, não quero apenas saber que algo mudou. Quero saber o que exatamente mudou, e se toquei acidentalmente nalgum objeto, regra NAT ou definição de VPN pelo caminho. O viewer é um ajudante surpreendentemente pragmático para isso.

O que é o Sophos Firewall Configuration Viewer?

O Sophos Firewall Configuration Viewer é uma ferramenta baseada em browser que converte configurações de Sophos Firewall para um formato legível por humanos. Podes usá-lo para:

  • filtrar, ordenar e pesquisar a configuração
  • pesquisar objetos/hosts/FQDNs específicos e ver onde são referenciados
  • comparar duas configurações (Added/Modified/Removed)
  • exportar resultados como um relatório HTML

Importante: é uma ferramenta standalone que abres simplesmente no browser. Não precisas de instalar nada e podes usá-la a partir de praticamente qualquer portátil de admin. É uma das razões porque gosto tanto: encaixa-se nos workflows existentes sem fricção.

Por baixo, trabalha com o que a Sophos já te dá: o export da configuração em XML (tipicamente Entities.xml). A diferença está na apresentação. Em vez de ficares a olhar para estruturas XML, tens uma vista que parece mais uma documentação bem organizada.

E não é só “view”. Na prática, três capacidades aparecem continuamente:

  1. Ler: uma vista estruturada da config, filtrável.
  2. Pesquisa/Referências: encontrar objetos e ver onde são usados.
  3. Comparar: antes/depois ou Firewall A vs Firewall B.

O ponto mais importante para segurança e privacidade: a Sophos sublinha que os dados são processados localmente no teu browser e que nada é “carregado” para fora. Parsing, análise e geração de relatórios devem ficar no teu dispositivo.

Encontras a ferramenta aqui: Sophos Firewall Configuration Viewer

Se preferires primeiro um walkthrough rápido, aqui está o TechVid da Sophos:

Um caso real numa PME

Sexta-feira, 15:30. Uma empresa com cerca de 80 colaboradores: nova ligação à Internet, novos IPs públicos e, em paralelo, um pequeno projeto (novo CRM, novas sub-redes). O pedido de change está bem escrito: que regras NAT, que endpoints VPN e que regras de firewall precisam de ajustes.

Na realidade, acontece o de sempre:

  • Um objeto como WAN_Public_IPs é referenciado por três regras NAT, duas regras de “business application” e uma regra WAF “histórica” que ninguém olha há anos.
  • Um objeto FQDN de um SaaS foi colocado num grupo algures no tempo e agora aparece em dez regras, mas só duas continuam relevantes.
  • Queres fazer limpeza, mas não queres a chamada de segunda-feira de manhã: “Desde o change, o X deixou de funcionar.”

É aqui que o Configuration Viewer poupa tempo a sério.

O meu workflow típico nestas situações:

  1. Exportar antes (guardar uma baseline)
  2. Implementar o change
  3. Exportar depois
  4. Fazer um diff no viewer e anexar o HTML ao ticket
  5. Antes de apagar objetos: usar o Usage Reference para verificar onde são realmente usados

Isto não é apenas conveniência. Torna as mudanças rastreáveis. E é exatamente isso que auditorias, aprovações internas e o teu eu do futuro querem.

Como usar a ferramenta na prática

1) Exportar a configuração (Full ou Selective)

Exporta diretamente a partir da firewall:

  • WebAdmin: Backup & Firmware > Import / Export
  • Exportar Export full configuration (tudo) ou Export selective configuration (áreas específicas, opcionalmente com “Include dependent entity”)

A Sophos gera a configuração como um ficheiro .tar que fazes download.

Alguns detalhes que contam na prática:

  • Full export é o meu default para change management (baseline/diff). Levas tudo e reduces o risco de falhar dependências.
  • Selective export é ótimo quando queres rever uma área específica (por exemplo só interfaces + routing) ou quando precisas de partilhar algo com terceiros (ISP/vendor) e queres minimizar o que expões.
  • Include dependent entity é muitas vezes crítico em exports seletivos: se exportas regras de firewall, normalmente queres também os objetos de rede/serviço referenciados. Caso contrário, o export fica incompleto e perdes contexto.

Pro tip para comparações: para “Compare”, exporta sempre duas configurações com a mesma seleção (Full vs Full, ou Selective vs Selective com as mesmas caixas). Se comparares Full com Selective, o diff vai parecer dramático, mas na prática é maioritariamente inútil.

2) Extrair o TAR e encontrar Entities.xml

Do .tar, extrai o ficheiro Entities.xml (dependendo do export, também pode aparecer como entities.xml).

Em macOS/Linux:

tar -xvf backup.tar
ls -la

No Windows, podes fazer isto com ferramentas como o 7-Zip.

Se (como eu) não queres que estes backups fiquem a apodrecer na pasta Downloads, cria uma diretoria temporária de trabalho. Exemplo em macOS/Linux:

WORKDIR="$(mktemp -d)"
tar -xvf backup.tar -C "$WORKDIR"
ls -la "$WORKDIR"

No fim, podes apagar a diretoria. Parece básico, mas é exatamente este tipo de higiene que impede configs sensíveis de ficarem por aí semanas.

Para o teu radar de segurança: segundo a documentação da Sophos, um export sem conteúdo sensível (por exemplo apenas interfaces) muitas vezes contém apenas Entities.xml. Quando inclui informação sensível (por exemplo utilizadores), o TAR pode incluir também ficheiros como hashFile.json e propertyfile.

Na prática: trata o TAR inteiro como confidencial.

3) Tornar uma configuração “legível”

No viewer, escolhe “Single configuration” (ou semelhante) e faz upload do Entities.xml. Vais obter uma vista renderizada da configuração.

Dependendo do tamanho, o carregamento pode demorar alguns segundos. Depois disso, tens algo que muitas vezes me falta na web UI: uma vista de “documentação” da config, sem clicar por dezenas de menus.

O que mais gosto: podes filtrar agressivamente do lado esquerdo. Se o teu change é sobre routing/NAT, não queres estar a fazer scroll por cada definição de relatórios, cada toggle de logging e cada feature secundária. Ativas apenas as secções que te interessam agora.

Combinações de filtros típicas no dia a dia:

  • apenas regras de firewall + NAT
  • apenas interfaces + routing
  • apenas VPN

Quando audito ou assumo um ambiente pela primeira vez, costumo seguir esta ordem:

  1. Interfaces/zonas (o que é interno, o que é externo?)
  2. Routing/SD-WAN (como é que o tráfego sai, de onde vêm as rotas de retorno?)
  3. NAT (o que é publicado, o que é reescrito?)
  4. Regras de firewall (que fluxos estão realmente permitidos?)
  5. VPN (site-to-site e remote access, dependendo do setup)

Não é a única ordem possível, mas evita avaliar regras sem entender a topologia.

E se precisares de algo para documentação ou aprovação: podes exportar um relatório HTML a qualquer momento.

Gosto de usar isso como “pacote de review”: exportar HTML, anexar ao ticket de change (ou guardar internamente numa pasta de documentação segura), e alguém consegue rever a configuração sem precisar de acesso à firewall. Isto é muito útil para o princípio dos quatro olhos, aprovações internas e auditorias externas.

4) Usage Reference: “Onde é que este objeto é realmente usado?”

Para mim, esta é a killer feature.

As configs da Sophos dependem muito de objetos: hosts, redes, serviços, FQDNs, grupos. Isto é ótimo porque podes reutilizar as coisas com limpeza. O lado negativo: ao fim de alguns anos, muitas vezes já não é óbvio onde um objeto está referenciado.

E é exatamente aí que acontecem os erros clássicos:

  • alguém apaga um objeto “porque parece antigo” e só mais tarde descobre que ainda era usado numa regra NAT
  • alguém altera um objeto (por exemplo alarga um intervalo IP) e muda involuntariamente várias policies ao mesmo tempo

O Usage Reference no viewer torna estas dependências visíveis. Em vez de procurar na web UI “a olho”, usas a pesquisa/Usage Reference para descobrir onde um objeto ou hostname é referenciado.

Exemplo do TechVid: procuras box e vês imediatamente que policies/regras NAT referenciam o objeto FQDN.

O lado fixe é o fluxo de click-through: saltas da pesquisa diretamente para o objeto e depois vês as referências (por exemplo que policy de firewall ou regra NAT o usa). Quando faço um change de limpeza, muitas vezes exporto esta vista em HTML e anexo ao ticket. Mais tarde fica claro porque apaguei ou alterei um objeto.

Perfeito para:

  • limpeza (remover objetos antigos)
  • planeamento de change (que regras precisam mesmo de ajuste)
  • troubleshooting (porque é que uma regra ainda faz match algures)

5) Comparar duas configurações (Before/After)

Na página inicial da ferramenta podes escolher “Compare” em vez de “View” e fazer upload de dois ficheiros Entities.xml.

Parece simples, mas é um padrão muito poderoso. Eu uso, por exemplo, para:

  • before/after de changes (o meu clássico)
  • comparar test/staging com produção para encontrar drift
  • validação após migrações (nova WAN, nova lógica NAT, nova VPN)

O que gosto no modo compare: não é apenas um diff de texto cru. Tenta agrupar mudanças de forma sensata. Não recebes apenas “algum XML é diferente”, recebes: este objeto foi adicionado, esta regra foi modificada, esta entrada foi removida.

É exatamente o que queres para change management:

  • resumo: o que foi removido, modificado, adicionado?
  • detalhes por objeto/regra
  • XML raw lado a lado (opcional)
  • exportação HTML para ticket/auditoria

O meu workflow pessoal é bastante direto (mas eficaz):

  1. Ler o resumo: as ordens de grandeza fazem sentido? (por exemplo “mudei 3 regras” vs “de repente 200 objetos modified”)
  2. Ir às áreas críticas: interfaces/WAN, routing, NAT, VPN, regras de firewall
  3. Guardar o export HTML enquanto tudo ainda está fresco

Especialmente o passo 1 reduz o stress para mim. Se vejo que apenas os objetos esperados foram afetados, durmo muito melhor no fim de semana.

Se criares o hábito de guardar um diff before/after para changes maiores, vais simplificar muito a tua vida a longo prazo.

Funcionalidades e features em detalhe

Até aqui, a ferramenta já é útil. Mas depois de a usares algumas vezes, percebes: o viewer é menos “nice to have” e mais uma pequena caixa de ferramentas para perguntas típicas de admin. Aqui estão as funcionalidades que uso mesmo muito, com um pouco mais de detalhe.

Human-Readable View: finalmente sem maratona de cliques

Na web UI da Sophos, as definições estão muitas vezes bem organizadas, mas espalhadas por várias páginas. Para tarefas rápidas, serve. Para auditorias e planeamento de changes, é cansativo porque perdes o contexto constantemente.

O viewer transforma isso numa representação compacta. Eu uso para um reality check rápido:

  • que interfaces/zonas existem realmente?
  • que regras NAT publicam que serviços?
  • que regras são demasiado abertas porque no passado “tinha de funcionar”?

Isto não substitui um design limpo, mas torna visível como a firewall está descrita no fim.

Filtros: foco no que conta agora

Os filtros do lado esquerdo parecem simples, mas na prática são ouro. A maioria dos changes não é sobre toda a config, mas sobre uma área (WAN, NAT, VPN, routing).

Se estou a colocar uma nova ligação à Internet em produção, escondo tudo e foco-me em:

  • interfaces/WAN
  • routing/SD-WAN
  • NAT
  • regras de firewall (para os fluxos afetados)

Parece trivial, mas evita que te percas em side quests durante uma review.

Pesquisa: de “box” a “10.20.30.0/24”

A pesquisa é um excelente ponto de entrada quando vens da operação e só tens um sintoma:

  • “O nosso serviço para box.com deixou de funcionar”
  • “A nova rede da filial 10.20.30.0/24 não tem acesso”
  • “Porque é que o SMTP ainda está aberto?”

Pesquisas por nome, IP, FQDN ou objeto e chegas rapidamente ao ponto relevante.

Usage Reference: ver impacto (antes de doer)

O Usage Reference é a função que mais vezes decide se uma limpeza é “corajosa” ou “responsável”. Eu uso principalmente em três casos:

  1. Apagar objetos: primeiro verificar se é referenciado em algum lado.
  2. Alterar objetos: primeiro verificar quantas regras/policies seriam afetadas indiretamente.
  3. Planear changes: primeiro verificar que regras estão realmente ligadas ao mesmo objeto.

Se fizeres isto de forma consistente, o número de momentos “ah, isto ainda estava ligado a isto” baixa imenso.

Compare + exportação HTML: o meu default para change management

O modo compare é a minha “prova” de que o change correu como planeado.

Na maior parte das vezes faço assim:

  1. Export antes
  2. Export depois
  3. Compare
  4. Guardar o HTML diff e anexar ao ticket

Parece pedante, mas são poucos minutos e pode poupar-te horas de discussão mais tarde quando alguém pergunta o que mudou exatamente. Para equipas, também é um ótimo formato de review: podes pedir a alguém para ler o HTML diff e validar apenas os pontos críticos.

Segurança: o que é bom e quais são os limites

1) Privacy-first é ótimo, mas não é desculpa para descuido

A Sophos afirmar que nada sai do browser é um grande ponto positivo, especialmente para dados de configuração.

Mesmo assim: uma configuração de firewall é quase sempre sensível. Mesmo sem passwords em texto simples, normalmente contém:

  • redes internas, VLANs, esquemas IP
  • definições NAT e endpoints públicos
  • topologias VPN
  • grupos de objetos (muitas vezes mais reveladores do que parece)

2) O export é o verdadeiro risco

O viewer ajuda-te a ler. Mas o risco costuma estar antes e depois:

  • durante o download do TAR
  • durante a extração
  • ao guardar/partilhar relatórios HTML

A Sophos documenta explicitamente que exports com informação sensível podem incluir ficheiros adicionais e que o tema da secure storage master key é relevante para imports.

O meu conselho do dia a dia:

  • manter exports locais por pouco tempo (e limpar depois)
  • não colocar reports em sistemas de tickets “abertos”
  • se trabalhares com terceiros: preferir exports seletivos e partilhar apenas o necessário

3) SSH/Advanced Shell: o viewer só mostra o que está no export

Algo que acontece mais vezes em ambientes reais do que se admite: durante um incidente, alguém faz login por SSH e “corrige rapidamente” algo na Advanced Shell.

O ponto importante não é se isso sobrevive ao próximo reboot ou não. O ponto importante é: se algo não entra no export (Entities.xml), fica invisível no viewer. E isso pode acontecer com ajustes via Advanced Shell/SSH, porque nem sempre aparecem como configuração “normal” no export.

Se tocares em coisas via SSH/Advanced Shell, documenta isso à parte e planeia representar corretamente via configuração no WebAdmin. Caso contrário, o próximo restore, HA failover ou firmware update é quando te morde, ou simplesmente não o vês no diff.

4) Regras práticas que ajudam em produção

  1. Usa um perfil de browser sem um zoo de extensões para tarefas deste género.
  2. Guarda TAR/HTML apenas onde guardarias outras configs confidenciais.
  3. Se tiveres de partilhar: exporta o mínimo (selective) e pensa em dependências.

Conclusão

O Sophos Firewall Configuration Viewer não é uma feature para manchetes. Mas honestamente: ferramentas como esta são as que te libertam as costas no dia a dia.

Ao longo dos anos, vi configurações suficientes em que o stress real não era “tecnologia”, mas rastreabilidade: o que mudou e quando? Este objeto está mesmo sem uso? Tocámos noutra coisa sem querer? Na web UI encontras muita coisa, mas raramente rápido. E ler exports XML diretamente é algo que ninguém faz voluntariamente durante mais de cinco minutos.

O viewer fecha bem essa lacuna. Consigo ler uma configuração com calma, tratá-la como documentação, filtrar o que preciso, verificar referências e, no fim, guardar um HTML diff. Pode soar “nice”, mas em equipa é uma alavanca real: as reviews tornam-se mais fáceis, as auditorias menos dolorosas e tens menos surpresas na segunda-feira de manhã.

Se levares apenas uma coisa daqui: cria um pequeno reflexo.

Antes de changes maiores: exporta uma vez, depois do change exporta novamente, corre o Compare e arquiva o HTML diff. Demora alguns minutos, mas é uma das formas mais fiáveis de combater o “eu acho que só mudámos X”.

E como sempre: o viewer torna as configs mais legíveis, mas não automaticamente mais seguras. O raciocínio continua a ser teu. Só te dá finalmente uma ferramenta que não trabalha contra ti.

Se alguma vez fizeste tweaks “quick and dirty” via SSH na Advanced Shell: lembra-te que isso nem sempre aparece nos backups e, nesse caso, também não será visível no viewer.

Fontes e leituras adicionais

Até à próxima, Joe

© 2026 trueNetLab