Testar corretamente uma regra da Sophos Firewall

Uma regra de firewall não deve ser apenas guardada: também precisa de ser testada de forma direcionada. Sobretudo quando envolve filtragem Web, inspeção TLS, NAT, IPS ou correspondência de utilizadores, uma regra pode parecer correta na configuração e, mesmo assim, não funcionar como 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
• Packet Capture para o fluxo real de pacotes
• tcpdump para capturas mais longas, ficheiros PCAP e casos de suporte

A sequência é importante: primeiro, verifique se o teste está bem definido e se a regra gera registos. O Log Viewer mostra então a decisão que a firewall realmente registou. O Policy tester ajuda a verificar a lógica de políticas esperada, mas não comprova o fluxo real de pacotes. O Packet Capture é a melhor evidência quando podem estar envolvidos encaminhamento, NAT, VLAN, VPN, o fornecedor de acesso ou um sistema de destino. Se o teste tiver de durar mais tempo, se for necessário um ficheiro PCAP ou se o suporte Sophos precisar de analisar a captura, tcpdump na Sophos Firewall é a ferramenta mais adequada.

Um bom teste de regras não responde apenas à pergunta se uma regra “funciona”. Mostra qual Rule ID correspondeu efetivamente ao tráfego, qual NAT ID esteve envolvido, se alguma função de segurança interveio e se o tráfego de ida e de retorno segue o 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 política e de percurso.

Qual artigo é adequado?

Este artigo é o ponto de partida adequado para testar uma tentativa de ligação concreta com IP de origem, destino, serviço e hora definidos. Para problemas relacionados, um artigo mais específico costuma permitir uma investigação mais rápida:

• 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 ao tráfego ou outra regra tem precedência: Regra da Sophos Firewall não corresponde ao tráfego: verificar as causas.
• DNAT, SNAT, MASQ ou a ordem das regras NAT estão envolvidos: Compreender o NAT na Sophos Firewall.
• Um servidor interno é disponibilizado na Internet: Publicar um servidor através de DNAT.
• Packet Capture mostra pacotes descartados, Violation ou motivos de descarte inesperados: Analisar pacotes descartados na Sophos Firewall.
• Todo o Log Viewer deixou de mostrar novos eventos: Verificar especificamente os filtros, Local reporting e o erro conhecido do Garner.
• A SSL VPN está ligada, mas os destinos internos não estão acessíveis: Configurar o acesso remoto SSL VPN na Sophos Firewall.
• A VPN IPsec entre locais ou de acesso remoto apresenta problemas: Resolver problemas de VPN IPsec na Sophos Firewall.
• As ferramentas WebAdmin não são suficientes e são necessários logs locais: Identificar os logs de serviço da Sophos Firewall.
• Um caso de suporte precisa de um arquivo de logs, dados de IPsec ou ficheiros PCAP: Guardar logs da Sophos Firewall para suporte e análise.

Esta distinção evita investigar de forma demasiado ampla um problema específico de NAT, VPN, encaminhamento ou serviço com um teste geral de regras.

Classificação correta das ferramentas

• Log Viewer: mostra Rule ID, NAT ID, Action, utilizador e decisões das funções de segurança. Não comprova a existência de pacotes que nem sequer chegam à firewall.
• Policy tester: mostra as políticas de firewall, Web e SSL/TLS esperadas para os dados de entrada definidos. Não comprova o caminho de retorno real, o comportamento de SD-WAN, perdas de pacotes ou problemas do fornecedor de acesso.
• Packet Capture: mostra se os pacotes chegam, são encaminhados e se as respostas regressam. Não explica automaticamente a intenção funcional de uma regra ou política Web.
• tcpdump: é adequado para capturas mais longas, filtros BPF muito precisos, ficheiros PCAP e análise no Wireshark. Não apresenta diretamente a Rule ID, a NAT ID nem as decisões da política Web que aparecem no WebAdmin.
• Central Reporting ou Syslog: permite consultar o histórico, produzir relatórios, correlacionar eventos num SIEM e analisá-los posteriormente. Para o fluxo de pacotes em tempo real e os detalhes dos serviços locais, as ferramentas locais costumam ser mais rápidas.

Se uma regra aparentemente “não funciona”, não a altere de imediato. Muitas vezes, a causa está no NAT, no encaminhamento, numa regra com precedência, na falta de registos ou numa função de segurança. Para uma investigação sistemática, consulte também Regra da Sophos Firewall não corresponde ao tráfego: verificar as causas.

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 elemento do caso de teste por execução. Se mudar simultaneamente a posição da regra, o NAT, o DNS, o encaminhamento e o cliente, deixará de ser possível identificar claramente a alteração que resolveu o problema.

Este procedimento evita modificar desnecessariamente uma regra funcional quando o verdadeiro problema está no NAT, no encaminhamento, no DNS, na inspeção TLS ou num sistema de destino.

Antes do teste

Primeiro, anote 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, desencriptado, não desencriptado

Em seguida, ative Log firewall traffic na regra de firewall afetada. Sem registos, o Log Viewer é útil apenas de forma limitada.

O registo de logs tem dois níveis. Primeiro, a própria regra afetada tem de gerar registos, por exemplo com Log firewall traffic. Segundo, os tipos de log adequados em System services > Log settings têm de estar ativos para o destino pretendido: Local reporting para o 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 guardado localmente nem enviado para o destino externo, a investigação pode parecer 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: Verificar 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á num grupo de regras adequado?
• 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.

Passo 2: Abrir o 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.

Passo 3: Reproduzir o teste

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

• Abrir um site
• Enviar ping
• Testar uma porta
• Iniciar uma aplicação
• Estabelecer uma ligação VPN
• Descarregar um ficheiro

Se possível, execute apenas um teste de cada vez. Caso contrário, deixará de ser possível associar inequivocamente os logs e o contador de dados transferidos a cada teste.

Em seguida, verifique:

• O contador de dados transferidos aumenta?
• Aparece um registo no Log Viewer?
• Qual é a Rule ID apresentada?
• Qual é a NAT Rule ID apresentada?
• O tráfego é permitido ou bloqueado?
• Alguma função de segurança intervém?

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 o Log Viewer continuar vazio, isso ainda não prova que a regra esteja errada. Verifique primeiro o registo de logs, o filtro de tempo, o filtro de módulo e o fluxo real de pacotes. Muitas vezes, o tráfego nem chega à firewall, a regra não gera registos, o tipo de log necessário está desativado ou o teste utiliza um IP de destino diferente do esperado.

Passo 4: Utilizar o Policy tester

O Policy tester é útil para verificar qual regra de firewall, regra de inspeção SSL/TLS ou política Web se aplicaria teoricamente ao tráfego 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.

Acesso através de Diagnostics: As instruções do Policy tester para SFOS 22 e SFOS 23 continuam a descrever o seguinte caminho, que abre uma janela pop-up. Assim, a documentação do SFOS 23 menciona tanto o acesso através do cabeçalho como o acesso através de Diagnostics; não se pode concluir daí que qualquer um dos dois caminhos 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 com base no IP de origem. Se a ferramenta detetar uma zona incorreta ou se pretender limitar deliberadamente o teste a uma zona, selecione-a explicitamente. O URL determina o protocolo e a porta: https://www.example.com testa HTTPS na porta predefinida 443; se não for indicado um protocolo, o Policy tester utiliza HTTP. Para especificar uma porta de destino diferente, indique-a no URL, por exemplo testexample.com:21. Se não for indicada uma porta, o teste utiliza a porta predefinida do protocolo detetado.

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 apresenta apenas Accepted ou Blocked, mas também a regra de firewall correspondente, o destino reconhecido, a zona de origem e, consoante o método de teste, informações adicionais de Web ou SSL/TLS. Assim, permite verificar rapidamente se o tráfego corresponde, em princípio, à 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 do fluxo real de pacotes. Os resultados dos testes de políticas não têm em conta as rotas SD-WAN. Por isso, o comportamento real pode ser diferente se estiverem envolvidos SD-WAN, encaminhamento ou gateways.

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 encontrar correspondência com regras que contenham endereços MAC em Source networks and devices. Nestes 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 os administradores, a consequência é importante: se o Policy tester mostrar um resultado inesperado, mas o Log Viewer, o contador de dados transferidos e o Packet Capture confirmarem o fluxo real de pacotes, não altere imediatamente as regras de firewall ou NAT. Verifique primeiro se o problema afeta apenas a apresentação do diagnóstico.

Procedimento prático para resultados contraditórios:

1. Documente claramente o teste com IP de origem, destino, serviço e utilizador.
2. Filtre o Log Viewer por IP de origem, IP de 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 do Policy tester apenas como um indício, não como prova única.
7. Verifique a versão do firmware e os problemas conhecidos da 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 à reordenação de regras de produção que funcionam nem à alteração de regras NAT sem evidências.

O Policy tester é especialmente útil para:

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

É menos adequado 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 o fornecedor de acesso ou o switch
• aplicações com múltiplas ligações e portas

Passo 5: Utilizar o Packet Capture

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

O filtro deve ser estreito, por exemplo:

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

Em seguida:

1. Inicie o Packet Capture.
2. Reproduza o teste.
3. Pare o Packet Capture.
4. Compare os eventos de entrada e de encaminhamento.
5. Compare a Rule ID e a NAT ID com o 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 numa interface. Na saída do WebAdmin, consoante o pacote, também podem aparecer detalhes de processamento, por exemplo Firewall Rule ID, NAT ID, utilizador, contexto de filtragem Web ou de aplicações e a indicação de que um pacote foi encaminhado, consumido, gerado ou descartado. Por isso, o Packet Capture é tão útil quando uma regra aparentemente não corresponde ao tráfego: relaciona o fluxo de pacotes com a avaliação das políticas melhor do que uma simples ferramenta de ping ou teste de porta.

Interpretação:

• Nenhum pacote chega: verifique o cliente, a VLAN, o switch, o gateway, o fornecedor de acesso ou o grupo de segurança na cloud.
• O pacote entra, mas não sai: verifique a regra de firewall, o NAT, o encaminhamento ou a função de segurança.
• O pacote sai, mas falta a resposta: verifique a rota de retorno, o sistema de destino, o NAT ou a firewall externa.
• O pacote tem o estado Violation: verifique a política, o IPS, o filtro Web ou o Application Control.
• A NAT ID é inesperada: verifique a ordem das regras NAT e as regras NAT genéricas.

Mais informações: Utilizar a ferramenta Packet Capture no WebAdmin. Se os pacotes forem descartados, consulte também Analisar pacotes descartados na Sophos Firewall.

Analisar o Log Viewer e o Packet Capture em conjunto

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 a Rule ID esperada e Packet Capture mostra Forwarded: o resultado do teste é plausível do ponto de vista da firewall. O caminho de retorno e o sistema de destino ainda têm de ser 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 não há um log correspondente: verifique o registo de logs, o filtro de módulo, a regra predefinida, Device Access ou a análise dos pacotes descartados.
• Packet Capture mostra Consumed: o tráfego termina na própria firewall. Verifique Device Access e Local Service ACL.
• Packet Capture mostra Violation: compare Reason, Rule ID, NAT ID e o módulo de segurança com o Log Viewer.

Se as duas ferramentas parecerem contraditórias, restrinja primeiro o caso de teste. Um único cliente, um destino, uma porta e um intervalo curto de teste 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.

Utilizar filtros restritos no Packet Capture

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 um destino HTTPS: host 172.16.10.25 and port 443, quando o destino pode mudar devido a DNS ou CDN.
• Apenas tráfego de saída de um cliente: src host 172.16.10.25, para verificar primeiro se o cliente está a enviar tráfego.
• Apenas tráfego de resposta para o cliente: dst host 172.16.10.25, quando falta o caminho de retorno ou não chegam pacotes de resposta.
• 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 teste simples de conectividade.

Ao testar DNAT ou VPN, tenha especial atenção ao ponto de observaçã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 o NAT. Nestes casos, duas capturas curtas costumam ser mais claras: primeiro do 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, mas não é suficiente em todos os casos. Passe para tcpdump se alguma destas condições se verificar:

• 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 do WebAdmin fica cheio ou apresenta apenas um fragmento.
• O tráfego relevante deve ser observado em uma interface específica por um período prolongado.

Com tcpdump, aplicam-se os mesmos cuidados: definir filtros restritos, anotar a hora do teste, manter a captura curta e eliminar o ficheiro após a transferência. O guia prático de CLI está em Capturar pacotes por CLI com tcpdump na Sophos Firewall.

Passo 6: Validar as funções de segurança individualmente

Se a regra correta corresponder ao tráfego, mas a ligação não funcionar, verifique individualmente as funções ativadas.

• Web policy: verifique a categoria, o utilizador, o horário e a ordem das políticas.
• Scan HTTP and decrypted HTTPS: o tráfego HTTPS só é analisado se já estiver desencriptado.
• SSL/TLS inspection: verifique a regra adequada, o Decryption Profile e o certificado CA nos clientes.
• IPS: verifique a assinatura, a política e possíveis falsos positivos.
• Application Control: verifique a aplicação detetada, a categoria e a deteção de aplicações na cloud.
• Security Heartbeat: verifique se o endpoint envia Heartbeat e se o estado é verde, amarelo ou vermelho.
• Traffic Shaping: verifique 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 Web, por si só, ainda não desencripta os conteúdos HTTPS. No modo DPI, o tráfego precisa de uma SSL/TLS inspection rule adequada com Decrypt. Na filtragem Web Proxy, configuram-se, em alternativa, Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering, bem como a CA de análise adequada; as SSL/TLS inspection rules não controlam a desencriptação efetuada pelo proxy. Em ambos os modos, a CA utilizada para assinar tem de estar instalada como fidedigna nos clientes.

Mais informações: Implementar a inspeção TLS na Sophos Firewall por etapas. Para problemas de NAT, consulte Compreender o NAT na Sophos Firewall: uma regra NAT não permite tráfego, apenas traduz endereços ou portas.

Passo 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
• Ligaçõ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

Para identificar o ficheiro de log de cada módulo, consulte Identificar os logs de serviço da Sophos Firewall.

Num caso de suporte, um arquivo de logs ou CTR só é realmente útil se a hora do teste e os IDs esperados estiverem documentados. Um pacote grande de logs sem origem, destino, porta, utilizador, Rule ID e NAT ID costuma apenas gerar mais pedidos de esclarecimento.

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: testar uma regra Web de LAN para WAN

1. Crie a regra de firewall LAN_to_WAN_Clients.
2. Ative o registo de logs.
3. Defina os serviços como HTTP e HTTPS.
4. Selecione a política Web.
5. Deixe Block QUIC protocol ativado.
6. Ative Scan HTTP and decrypted HTTPS.
7. Crie uma 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. Filtre o Log Viewer por IP de origem.
12. Execute Policy tester para a mesma URL.
13. Inicie o Packet Capture em caso de discrepância.

Assim, pode verificar se a regra corresponde ao tráfego, se HTTPS está realmente desencriptado e se o filtro Web, o IPS ou o controlo de aplicações intervêm.

Documentar 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
• Rule ID esperada e efetivamente correspondente
• ID da regra NAT, se NAT estiver envolvido
• Ação em Log Viewer
• Captura de ecrã ou exportação do Packet Capture, se o fluxo de pacotes foi 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 alterações em produção, registe também se a regra se destina apenas a um projeto-piloto, a uma utilização permanente ou a uma solução temporária. As regras de teste temporárias devem ter uma data de expiração ou um responsável claramente identificado, para não ficarem esquecidas no conjunto de regras.

Se o teste da regra der origem a um caso de suporte, documente também o arquivo de logs, a captura do Packet Capture ou o ficheiro PCAP do tcpdump, o período afetado e as causas já excluídas. Para esta etapa, consulte Guardar logs da Sophos Firewall para suporte e análise.

Perguntas frequentes