Testar com sucesso uma regra de Sophos Firewall

Uma regra de firewall não deve apenas ser salva, mas também testada especificamente. Especialmente em casos de filtragem da web, inspeção TLS, NAT, IPS ou correspondência de utilizador, uma regra pode parecer correta visualmente e ainda assim não funcionar conforme o esperado.

Diversas ferramentas podem ser usadas para testes:

• Log Viewer para eventos reais e decisões de regras
• Live Connections para sessões atualmente estabelecidas, interfaces, Rule ID, NAT ID e gateway
• Policy tester para web, firewall e lógica de política SSL/TLS
• Captura de pacotes para fluxo real de pacotes
• tcpdump para capturas mais longas, ficheiros PCAP e casos de suporte

A ordem correta é importante: primeiro verifica-se se o teste está bem definido e se a regra gera registos. Log Viewer mostra então qual decisão a firewall realmente registou. Policy tester ajuda com a lógica de política esperada, mas não testa o fluxo real de pacotes. Packet Capture é a melhor evidência quando o encaminhamento, NAT, VLAN, VPN, o provedor ou um sistema de destino pode estar envolvido. Se o teste precisar ser executado por mais tempo, um ficheiro PCAP for necessário ou a captura precisar ser avaliada pelo suporte Sophos, tcpdump na Sophos Firewall é a melhor ferramenta.

Um bom teste de regras não responde apenas se uma regra “funciona”. Ele mostra qual Rule ID realmente correspondeu, qual NAT ID participou, se funções de segurança estavam envolvidas e se as viagens de ida e volta seguem o mesmo caminho esperado.

Utilizar corretamente Live Connections e Connection List explica como agrupar uma sessão já estabelecida, filtrar um fluxo e ler os respetivos campos de policy e caminho.

Qual artigo é adequado?

Este artigo é a introdução correta caso precise testar uma tentativa de ligação específica com IP de origem, destino, serviço e horário. Para problemas relacionados, um artigo mais específico costuma ser mais rápido:

• O utilizador não aparece em Live Users ou surge com o grupo ou IP de origem incorreto: Resolver sistematicamente erros de autenticação na Sophos Firewall.
• Uma regra não corresponde ou ganha outra regra: Sophos Firewall regra não corresponde: revisão causa.
• DNAT, SNAT, MASQ ou a ordem de NAT estão envolvidos: Entenda NAT em Sophos Firewall.
• Um servidor interno é publicado na Internet: Servidor de publicação usando DNAT.
• Packet Capture mostra quedas, Violation ou motivos inesperados para queda: Analisar pacotes descartados em Sophos Firewall.
• Todo o Log Viewer deixou de mostrar novos eventos: Verificar especificamente os filtros, Local reporting e o erro conhecido do Garner.
• SSL VPN está ligado, mas os destinos internos não estão funcionando: Configurar Remote Access SSL VPN em Sophos Firewall.
• Site-to-Site-IPsec ou Remote-Access-IPsec apresenta problemas: Resolução de problemas de IPsec VPN em Sophos Firewall.
• As ferramentas WebAdmin não são suficientes e os logs locais são necessários: Mapear corretamente os logs de serviço Sophos Firewall.
• Um caso de suporte precisa de ficheiro de log, dados de IPsec ou ficheiros PCAP: Salvar logs de Sophos Firewall para suporte e análise.

Esta delimitação evita que um problema específico de NAT, VPN, encaminhamento ou serviço seja investigado de forma muito ampla com um teste prático.

Classificação correta das ferramentas

• Log Viewer: mostra ID de regra, ID NAT, decisões de ação, utilizador e função de segurança. Não mostra pacotes que não alcançam a firewall.
• Policy tester: mostra a política esperada de firewall, web e SSL/TLS para entradas definidas. Ele não demonstra o caminho de retorno real, SD-WAN, perda de pacotes ou comportamento do provedor.
• Captura de pacotes: mostra se os pacotes chegam, são encaminhados e se as respostas retornam. Ele não explica automaticamente a intenção funcional por trás de uma regra ou política da Web.
• tcpdump: é para capturas mais longas, filtros BPF muito precisos, ficheiros PCAP e análises no Wireshark. As decisões de ID de regra, ID NAT ou Política da Web não são vistas diretamente em WebAdmin.
• Central Reporting ou Syslog: ajuda para histórico, relatórios, correlação SIEM e avaliação posterior. Para fluxo de pacotes em tempo real e detalhes de serviços locais, as ferramentas locais geralmente são mais rápidas.

Se uma regra supostamente “não funciona”, a regra em si não deve ser alterada imediatamente. Muitas vezes a causa é NAT, encaminhamento, uma regra superior, registo em log ausente ou um recurso de segurança. Para resolução de problemas sistemática, Regra para Sophos Firewall não corresponde: Verifique as causas também é adequado.

Para resolução de problemas em tempo real, o Log Viewer local geralmente é mais rápido que Central Reporting ou SIEM. Os logs centralizados são importantes quando os eventos precisam ser reconstruídos posteriormente, correlacionados ou retidos por um longo período de tempo. Para configuração, Central Firewall Reporting e enviar Syslog para SIEM são adequados.

Breve procedimento para testar regras

Para a maioria dos casos de suporte, um procedimento claro é suficiente:

1. Defina o caso de teste com IP de origem, destino, serviço, utilizador e horário.
2. Ative Log firewall traffic na regra afetada.
3. Em System services > Log settings, verifique se o tipo de log adequado está ativo para Local reporting, Central reporting ou Syslog.
4. Verifique a posição da regra e o contador de dados transferidos.
5. Execute o teste exatamente uma vez.
6. Filtre Log Viewer por IP de origem, IP de destino e serviço.
7. Anote Rule ID e NAT ID a partir do registo real.
8. Use Policy tester apenas para lógica de política.
9. Inicie Packet Capture se Log Viewer e Policy tester não corresponderem.
10. Documente o resultado antes de mover ou alterar uma regra.

É importante alterar apenas um caso de teste por passagem. Se a posição da regra, NAT, DNS, encaminhamento e cliente forem alterados ao mesmo tempo, o sucesso subsequente não poderá mais ser atribuído de forma limpa.

Este procedimento evita que uma regra funcional seja modificada desnecessariamente, mesmo que o verdadeiro problema esteja no NAT, no encaminhamento, no DNS, na inspeção TLS ou em um sistema alvo.

Antes do teste

Primeiro deve anotar exatamente o que vai testar:

• IP de origem: 172.16.10.25
• Utilizador: user@domain.local
• Zona de origem: LAN
• Destino: https://www.example.com
• Serviço: HTTPS
• Regra esperada: LAN_to_WAN_Clients
• Ação esperada: permitido, bloqueado, descriptografado, não descriptografado

Em seguida, ative Log firewall traffic na regra de firewall afetada. Sem registo, Log Viewer tem ajuda limitada.

O logging tem dois níveis. Primeiro, a própria regra afetada precisa registar, por exemplo com Log firewall traffic. Segundo, os tipos de log adequados em System services > Log settings precisam estar ativos para o destino desejado: Local reporting para Log Viewer, Central reporting para Sophos Fusion (anteriormente Sophos Central) e os destinos Syslog configurados para servidores de logs externos. Se a opção na regra estiver ativada, mas o tipo de log correspondente não for armazenado localmente ou externamente, a análise de falhas rapidamente parece contraditória.

Para testes rápidos ao vivo, o Log Viewer é suficiente. Se um teste precisar ser rastreável posteriormente, deve-se verificar antes se Central Reporting ou Syslog também recebe o tipo de log relevante. Caso contrário, a prova pode não estar mais disponível após a rotação de logs ou uma reinicialização.

Passo 1: Verifique a posição da regra

Abra Rules and policies > Firewall rules e verifique:

• A regra está acima de regras mais gerais?
• Está ativa?
• A visualização IPv4 ou IPv6 correta está selecionada?
• Está em um grupo de regras lógicas?
• Existem exclusões?
• Existe alguma regra criada automaticamente acima?

Para obter uma comparação clara, abra More options na regra e selecione Reset data transfer count. Isto repõe o contador de dados transferidos, não um contador de correspondências separado. Um novo valor após o teste mostra que os dados passaram pela regra; confirme ainda assim Rule ID e Action no Log Viewer.

Etapa 2: Abra Log Viewer

Abra Log Viewer no canto superior direito da consola WebAdmin.

A utilização completa de módulos, filtros de tempo e de campos, Detailed view, src_trans_ip, Log occurrence e exportação CSV é explicada em Utilizar corretamente o Log Viewer da Sophos Firewall.

Filtros úteis:

• Módulo: Firewall
• IP de origem
• IP de destino
• Porta de destino
• ID da regra
• Nome da regra
• Ação
• Utilizador

Para tráfego da web, verifique adicionalmente:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Log Viewer é atualizado automaticamente. Para uma análise tranquila, é possível pausar a visualização ao vivo, filtrar e continuar.

As sessões de firewall não aparecem necessariamente de imediato: a Sophos Firewall normalmente grava o log da sessão quando recebe um evento Destroy e fecha a ligação. Se uma ligação terminar sem esse evento, por exemplo devido à perda de conectividade com a Internet, a entrada pode faltar. As ligações SSL/TLS são registadas após a conclusão do handshake e no encerramento. Num teste curto, feche deliberadamente a ligação e atualize o Log Viewer; verifique uma sessão ainda aberta em Current activities > Live connections.

Etapa 3: Faça o teste

O teste deve ser executado a partir de um cliente definido:

• Abrir site
• Enviar ping
• Porta de teste
• Iniciar aplicação
• Estabelecer ligação VPN
• Transferir ficheiro

Se possível, apenas um teste deve ser executado por vez. Caso contrário, os logs e os contadores de regras serão confundidos.

Em seguida, verifique:

• O contador de dados transferidos aumenta?
• Um log é visto em Log Viewer?
• Qual ID de regra é exibida?
• Qual ID de regra NAT é exibido?
• O tráfego é permitido ou bloqueado?
• Um recurso de segurança está ativado?

Para uma ligação de longa duração, abra Current activities > Live connections, agrupe por Source IP address ou Username e selecione o número em Total. A hora de início, interfaces de entrada e saída, origem, destino, portas, Firewall Rule ID e NAT Rule ID devem corresponder ao caso de teste. Se a ligação não aparecer enquanto o cliente a estabelece, use Packet Capture em seguida; procure uma ligação já encerrada no Log Viewer.

Se Log Viewer for deixado em branco, isso ainda não prova nada contra a regra. O registo, o filtro de tempo, o filtro do módulo e o fluxo real de pacotes devem ser verificados primeiro. Muitas vezes o tráfego nem chega à firewall, a regra não registra, o tipo de log errado é desativado ou o teste usa um IP de destino diferente do esperado.

Etapa 4: Usar Policy tester

Policy tester é útil se se quiser verificar qual regra de firewall, regra de inspeção SSL/TLS ou política da web teoricamente se aplicaria ao tráfego da web.

Caminho do menu:

SFOS 23: No cabeçalho WebAdmin, abrir Logs and policy test e selecionar o separador Policy test. A secção do cabeçalho do SFOS 23 documenta este acesso para testar qual regra de firewall e política Web se aplicam ao tráfego. É um acesso específico desta versão, não uma prova do fluxo real de pacotes; os logs e, quando necessário, Packet Capture continuam a ser decisivos.

SFOS 22: Mantêm-se o caminho Diagnostics existente e as instruções da janela pop-up abaixo. O novo acesso no cabeçalho do SFOS 23 não demonstra que este caminho tenha sido removido:

Diagnostics > Tools > Policy tester

Em Diagnostics > Tools, na secção Pop-out tools, clique em Policy tester. A ferramenta abre numa janela pop-up. Para um teste com contexto de utilizador, selecione primeiro Authenticated user e depois o utilizador a testar.

Entradas típicas:

• URL
• Utilizador
• Hora e dia
• IP de origem
• Zona de origem
• Método de teste

Como método de teste, selecione por exemplo Firewall, SSL/TLS, and web para verificar a combinação de regra de firewall, regra de inspeção SSL/TLS e política Web.

Com Firewall, SSL/TLS, and web, a regra de firewall e a regra de inspeção SSL/TLS são determinadas com base no serviço indicado no URL e no IP de origem especificado. A proteção Web é considerada se estiver configurada na regra de firewall. O método combinado pode testar tráfego para qualquer porta de destino; não está limitado a HTTP e HTTPS. No entanto, os detalhes da proteção Web, incluindo a política Web correspondente, só aparecem se a regra de firewall aplicar uma política Web e o teste utilizar HTTP ou HTTPS.

Em Source zone, Auto-detection pode determinar a zona a partir do IP de origem. Selecione a zona explicitamente se a ferramenta detetar a zona errada ou se o teste tiver de ser limitado a uma zona específica. O URL determina o protocolo e a porta predefinida: https://www.example.com testa HTTPS na porta 443; sem protocolo, o tester usa HTTP. Indique uma porta de destino diferente no URL, por exemplo testexample.com:21.

Depois de definir o URL, o contexto de utilizador, a hora e o dia, Test method, o IP de origem e Source zone, clique em Test.

O Policy tester não exibe apenas Accepted ou Blocked, mas também a regra de firewall correspondente, o destino reconhecido, a zona de origem e, dependendo do método de teste, mais informações da web ou SSL/TLS. Isso permite ver rapidamente se o tráfego se enquadra fundamentalmente na regra esperada.

O nome com ligação de uma regra de firewall ou regra de inspeção SSL/TLS correspondente abre a respetiva tabela de regras com um filtro para essa regra. Reset filter volta a mostrar todas as regras. Já uma política Web correspondente abre-se através do botão de edição junto ao seu nome. Depois de editar, repita o mesmo teste sem alterar os dados de entrada. Com Web policy only, as regras de firewall não são aplicadas; este método testa apenas HTTP e HTTPS em relação à política Web selecionada.

Importante:

⚠️ O Policy tester não substitui um teste real de fluxo de pacotes. Os resultados dos testes de política não refletem de forma confiável as rotas SD-WAN. Portanto, o comportamento real pode ser diferente se SD-WAN, encaminhamento ou gateways estiverem envolvidos.

O teste de tráfego web utiliza o modelo Transparent Mode. Não reproduz completamente uma ligação Direct Web Proxy com um proxy configurado explicitamente. Também não é possível fazer match com regras que contenham endereços MAC em Source networks and devices. Nesses casos, são decisivos um teste real no cliente, o Log Viewer e o Packet Capture.

Erro no SFOS 22.0 GA corrigido no MR1

O problema conhecido NC-177587 afetava o SFOS 22.0.0 GA-Respin Build 411 e foi corrigido no SFOS 22.0.1 MR1 Build 490. Na versão GA, Policy Test e Policy Route Test podiam mostrar incorretamente o tráfego como bloqueado ou atribuí-lo à regra errada, embora o tráfego de produção fosse processado corretamente.

Independentemente deste erro corrigido, continua a ser importante comparar logs e pacotes reais porque o Policy tester não reproduz um fluxo de pacotes completo.

Para administradores, a consequência é importante: se Policy tester mostra um resultado inesperado, mas Log Viewer, o contador de dados transferidos e Packet Capture confirmam o fluxo real de pacotes, as regras de firewall ou NAT não devem ser alteradas imediatamente. Deve primeiro verificar se isso afeta apenas a exibição de diagnóstico.

Procedimento prático para resultados contraditórios:

1. Documente claramente o teste com IP de origem, destino, serviço e utilizador.
2. Filtrar Log Viewer por IP origem, IP destino e serviço.
3. Verifique o ID da regra e o ID da regra NAT do registo real.
4. Inicie Packet Capture com um filtro estreito.
5. Compare o tráfego de entrada, encaminhamento e retorno.
6. Trate o resultado Policy tester apenas como uma indicação, não como um único teste.
7. Verifique a versão do firmware e os problemas conhecidos do Sophos antes de alterar as regras de produção.

Esta precaução é especialmente importante durante as janelas de manutenção. Um resultado de diagnóstico incorreto não deve levar ao reordenamento de regras produtivas em funcionamento ou ao ajuste de regras NAT sem evidências.

O Policy tester é especialmente bom para:

• Política da Web
• Categorização de URL
• Contexto do utilizador
• Programação
• Regra de inspeção SSL/TLS
• Regras de firewall correspondentes para tráfego da web

É menos bom para:

• decisões reais de encaminhamento
• caminho de retorno NAT
• regras com endereços MAC em Source networks and devices
• perdas de pacotes
• problemas com provedor ou switch
• aplicações com múltiplas ligações e portas

Etapa 5: Usar Packet Capture

Se Log Viewer e Policy tester não forem suficientes, Diagnostics > Packet capture será usado.

O filtro deve ser estreito, por exemplo:

• IP de origem do cliente
• IP de destino do servidor
• Porta de destino
• Protocolo

Então:

1. Iniciar Packet Capture.
2. Faça o teste.
3. Pare Packet Capture.
4. Compare eventos recebidos e encaminhados.
5. Compare o ID da regra e o ID NAT com Log Viewer.

Antes de começar, abra Configure. Number of bytes to capture (per packet) limita os bytes registados de cada pacote e Enter BPF string recebe o filtro de captura restrito. O buffer tem 2048 KB. Sem Wrap capture buffer once full, a captura para automaticamente quando fica cheia; com a opção, os dados mais antigos são substituídos. Para um teste reproduzível, uma captura curta sem substituição é geralmente mais fácil de analisar.

O Packet Capture não mostra apenas pacotes individuais em uma interface. Na saída do WebAdmin, dependendo do pacote, também podem aparecer detalhes de processamento, por exemplo Firewall Rule ID, NAT ID, utilizador, contexto de filtro Web ou Application e se um pacote foi encaminhado, consumido, gerado ou descartado. É exatamente por isso que o Packet Capture é tão forte quando uma regra supostamente não corresponde: ele conecta fluxo de pacotes e visão de policy melhor do que uma simples ferramenta de ping ou teste de porta.

Interpretação:

• Nenhum pacote chega: verifique o cliente, VLAN, switch, gateway, provedor ou Cloud Security Group.
• O pacote entra, mas não sai: verifique regra de firewall, NAT, encaminhamento ou função de segurança.
• Pacote sai, mas falta resposta: verifique caminho de retorno, sistema de destino, NAT ou firewall externo.
• O pacote possui status Violation: verifique Política, IPS, filtro web ou Application Control.
• ID NAT é inesperado: verifique a ordem de NAT e regras genéricas NAT.

Mais informações: Usar ferramenta Packet Capture em WebAdmin. Se os pacotes forem descartados, Analisar pacotes descartados em Sophos Firewall também será útil.

Leia Log Viewer e Packet Capture juntos

Log Viewer mostra a decisão, Packet Capture mostra o fluxo de pacotes. Na prática, ambas as visões são frequentemente necessárias.

• Log Viewer mostra o ID de regra esperado, Packet Capture mostra Forwarded: o teste de regra é plausível para a firewall. O caminho de retorno e o sistema de destino são verificados separadamente.
• Log Viewer mostra o ID de regra esperado, Packet Capture não mostra nenhuma resposta: verifique o sistema de destino, rota de retorno, NAT ou firewall externo.
• Packet Capture mostra Incoming, mas nenhum log adequado: verifique o registo, o filtro de módulo, a regra padrão, Device Access ou a análise de queda.
• Packet Capture mostra Consumed: o tráfego termina na própria firewall. Verifique Device Access e Local Service ACL.
• Packet Capture mostra Violation: compare Motivo, ID de Regra, ID NAT e módulo de segurança com Log Viewer.

Se ambas as ferramentas parecerem contraditórias, o caso de teste deve ser reduzido primeiro. Um único cliente, um destino, uma porta e um tempo de teste curto são melhores do que uma captura ampla com muito tráfego em segundo plano.

Caso especial: tráfego Web nas portas 80 e 443

Um log de firewall com Allowed não prova automaticamente que o acesso pelo navegador foi permitido. Quando uma regra com Action Drop corresponde a tráfego na porta 80 ou 443, a firewall pode entregar internamente o pacote ao Web Proxy. O módulo Firewall mostra então Allowed, enquanto Web filter regista Blocked e devolve uma página de bloqueio. Com Reject, o log de firewall permanece Rejected.

Para HTTP e HTTPS, verifique pelo menos os módulos Firewall e Web filter no mesmo momento. A Sophos também indica que as Web Exceptions podem aplicar-se mesmo com Action Drop. Se o acesso funcionar inesperadamente, verifique as entradas correspondentes em Web > Exceptions em vez de considerar apenas a Rule ID como prova.

Use filtros Packet Capture estreitos

Packet Capture só é útil se o filtro for estreito o suficiente. Uma captura muito ampla mostra rapidamente muito tráfego em segundo plano, especialmente em firewalls de produção com tráfego da Web, DNS, VPN ou de servidor. Portanto, o filtro deve ser derivado do caso de teste definido.

Exemplos práticos de BPF:

• Cliente único para um destino: host 172.16.10.25 and host 203.0.113.10, quando origem e destino são conhecidos.
• Cliente para destino HTTPS: host 172.16.10.25 and port 443, quando o destino pode mudar para DNS ou CDN.
• Apenas tráfego de saída de um cliente: src host 172.16.10.25, ao verificar pela primeira vez se o cliente está enviando.
• Apenas tráfego de resposta do cliente: dst host 172.16.10.25, quando o caminho de retorno ou pacotes de resposta estão faltando.
• Teste DNS: host 172.16.10.25 and port 53, quando a resolução de nomes e o teste de regras devem ser verificados separadamente.
• Teste ICMP: icmp and host 172.16.10.25, quando um ping serve como um teste de acessibilidade simples.

Ao testar DNAT ou VPN, atenção especial deve ser dada à direção de visão. Um filtro no IP do servidor interno não mostra necessariamente o acesso original ao IP público. Por outro lado, um filtro no IP público não mostra automaticamente se o tráfego chega ao servidor interno após NAT. Nesses casos, duas capturas curtas são muitas vezes mais limpas: primeiro no lado público e depois no destino interno.

Após o teste, a captura deve ser interrompida imediatamente. Capturas longas aumentam o risco de capturar dados desnecessários, nomes de host internos ou ligações não relacionadas.

Quando mudar para tcpdump

O Packet Capture do WebAdmin é ideal para testes rápidos. Contudo, não é suficiente para todos os casos. Deve ser alterado para tcpdump se algum destes pontos for verdadeiro:

• A captura deve ser avaliada como um ficheiro PCAP no Wireshark ou pelo suporte.
• O teste dura mais do que um breve teste de reprodução manual.
• Filtros BPF muito precisos são necessários, por exemplo, para VoIP, VPN, DNS ou múltiplos hosts.
• O buffer WebAdmin é preenchido ou exibe apenas um fragmento.
• O tráfego relevante deve ser observado em uma interface específica por um período prolongado.

Também em tcpdump se aplica: definir filtros estreitos, anotar o tempo de teste, manter a captura curta e excluir o ficheiro após a transferência. O guia prático para CLI está em Sophos Firewall tcpdump: Capturar pacotes por CLI.

Etapa 6: Validar recursos de segurança individualmente

Se a regra correta corresponder, mas o tráfego não estiver funcionando, os recursos ativados devem ser verificados individualmente.

• Política Web: revise categoria, utilizador, cronograma e ordem das políticas.
• Verificar HTTP e HTTPS descriptografado: HTTPS só será verificado se já estiver descriptografado.
• Inspeção SSL/TLS: revise a regra apropriada, o perfil de descriptografia e o certificado CA nos clientes.
• IPS: revise assinatura, política e possíveis falsos positivos.
• Application Control: revise o aplicação detectado, a categoria e a detecção de aplicações em nuvem.
• Security Heartbeat: verifica se o Endpoint envia Heartbeat e se o status é verde, amarelo ou vermelho.
• Traffic Shaping: verifica se a política está ativa e corresponde à aplicação ou regra correta.
• NAT: Verifique a regra SNAT, DNAT ou PAT correta e a ordem das regras.

Para HTTPS: Uma regra de firewall com filtragem da web não é suficiente para inspecionar o conteúdo de HTTPS. Também é necessária uma regra de inspeção SSL/TLS adequada com descriptografia e certificado CA distribuído.

Mais informações: Inspeção TLS de fase em Sophos Firewall. Para erros NAT, Understanding NAT in Sophos Firewall é apropriado, pois uma regra NAT não permite tráfego, ela apenas traduz endereços ou portas.

Etapa 7: verificar os ficheiros de log

Caso as ferramentas WebAdmin não sejam suficientes, os ficheiros de log apropriados devem ser verificados.

Ficheiros típicos:

• Regra de firewall: firewall_rule.log
• NAT: nat_rule.log
• Conexões de firewall: fwlog.log
• IPS e DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Qual ficheiro de log pertence a cada módulo está resumido em Atribuir corretamente os logs de serviço de Sophos Firewall.

Em casos de suporte, um ficheiro de log ou CTR só é realmente útil se o tempo de teste e os IDs esperados estiverem documentados. Um pacote de log grande sem origem, destino, porta, utilizador, ID de regra e ID NAT geralmente produz mais perguntas.

Reverter alterações em segurança

Execute o primeiro teste sem alterar políticas. Se depois for necessário mudar a posição de uma regra, um filtro ou uma regra de teste temporária, registe primeiro o valor original e altere apenas um item por execução. No fim, restaure o valor ou a posição original e repita o mesmo teste no cliente. O Log Viewer deve voltar a mostrar a Rule ID e a Action originais; desative ou elimine então a regra temporária. Pare o Packet Capture e limpe a visualização para não deixar dados de pacotes desnecessários no buffer.

Exemplo: regra web de teste de LAN a WAN

1. Criar regra de firewall LAN_to_WAN_Clients.
2. Ativar registo.
3. Configurar serviços em HTTP e HTTPS.
4. Selecione a política da web.
5. Deixe Block QUIC protocol ativado.
6. Ative Scan HTTP and decrypted HTTPS.
7. Criar regra de inspeção SSL/TLS para o grupo de teste.
8. Instale o certificado CA no cliente de teste.
9. Selecione Reset data transfer count.
10. Abra o site.
11. Filtrar Log Viewer por IP de origem.
12. Execute Policy tester para a mesma URL.
13. Iniciar Packet Capture em caso de discrepância.

Desta forma é possível ver se a regra corresponde, se HTTPS está realmente descriptografado e se o filtro web, IPS ou controlo de aplicação está envolvido.

Documente o resultado do teste

Após um teste de regra, o resultado deve ser brevemente documentado. Isto é especialmente importante se surgir um caso de suporte, uma janela de manutenção ou uma limpeza de regras subsequente.

É útil incluir:

• Data e hora do teste
• IP de origem, utilizador, destino, serviço e URL ou aplicação testada
• destinos de log ativados, por exemplo Log Viewer, Sophos Fusion ou Syslog
• ID da regra esperado e realmente correspondente
• ID da regra NAT, se NAT estiver envolvido
• Ação em Log Viewer
• Captura de ecrã ou exportação de Packet Capture, se o fluxo de pacotes fosse relevante
• Regra, política da web, regra de inspeção SSL/TLS ou regra NAT modificada
• Ponto aberto, se o comportamento ainda não estiver totalmente explicado

Nas mudanças produtivas, deve-se observar também se a regra se destina a apenas um piloto, de forma permanente ou como solução temporária. As regras de teste temporário devem ter uma data de expiração ou proprietário claro para que não sejam deixadas como cargas herdadas no conjunto de regras.

Caso o teste da regra resulte em um caso de suporte, o ficheiro de log, Packet Capture ou tcpdump PCAP, período afetado e causas já descartadas também devem ser documentados. Para esta parte cabe Salvar logs Sophos Firewall para suporte e análise.

Perguntas frequentes