Utilizar corretamente o Log Viewer da Sophos Firewall

No SFOS 22, o Log Viewer é frequentemente o ponto de partida mais rápido para analisar uma falha: que regra de firewall processou o tráfego, que regra NAT esteve envolvida, que utilizador foi identificado e que módulo de segurança bloqueou? Para obter uma resposta correta, o módulo, o intervalo de tempo, os filtros e o momento do registo têm de corresponder.

O Log Viewer mostra eventos registados. Não é um Packet Capture nem um histórico completo das ligações. Por isso, a ausência de uma entrada não prova um bloqueio nem que o pacote tenha chegado à firewall.

Para uma análise fiável, registar sempre a origem, o destino, o serviço, a hora exata do teste e a direção esperada. Em seguida, gerar exatamente um novo fluxo de teste e procurá-lo nos módulos adequados.

Avaliar um teste em sete passos

1. Na regra de firewall afetada, verificar Log firewall traffic ou, na regra SSL/TLS, Log connections.
2. Em System services > Log settings, confirmar que o tipo de log necessário está ativo em Local reporting.
3. Abrir Log viewer (SFOS 22) ou Logs and policy test (SFOS 23) no canto superior direito do WebAdmin e, em seguida, selecionar o módulo de logs adequado.
4. Definir o filtro temporal e usar Add filter para começar por limitar a origem, o destino e o serviço.
5. Gerar um novo fluxo de teste curto e registar a hora exata.
6. Em Detailed view, verificar Rule ID, NAT ID, ação, interfaces, utilizador e campos específicos do módulo.
7. Se a entrada não corresponder ao comportamento observado, correlacionar o mesmo teste com Packet Capture antes de alterar uma regra.

Esta sequência separa três questões que são frequentemente confundidas: foi sequer criado um log? Que política tomou a decisão? E os pacotes entraram e voltaram a sair realmente?

Os Event Logs registam autenticação, eventos do sistema e alterações de configuração, além do tráfego, e são guardados localmente por predefinição. Os Troubleshooting Logs são logs detalhados de serviços acessíveis pelo WebAdmin ou pela CLI. O procedimento de logs de serviços explica o acesso e a recolha em debug. Debug ocupa espaço adicional e tem de ser desativado após a recolha necessária; não é um interruptor para recuperar Event Logs em falta.

Para o envio centralizado, a firewall tem de estar registada no Sophos Central Firewall Management. Depois ativam-se os serviços Central e Send reports and logs to Sophos Central e selecionam-se os tipos de log necessários em System services > Log settings. A documentação SFOS 22 analisada chama ao destino Sophos Fusion, enquanto a de SFOS 23 o chama Sophos Central; devem seguir-se os campos de interface indicados. O procedimento Central Reporting cobre a configuração e a verificação da receção.

Ler corretamente os registos

Porque os registos nem sempre aparecem de imediato

O Log Viewer atualiza a vista automaticamente. No entanto, uma sessão da firewall normalmente só é registada quando a firewall recebe um evento Destroy e fecha a ligação. Numa sessão longa, a entrada pode, portanto, surgir depois do primeiro pedido.

Se uma ligação terminar sem que a firewall receba um evento Destroy, por exemplo devido à perda da ligação à Internet, o log de sessão esperado pode não aparecer. As ligações SSL/TLS são registadas após um handshake bem-sucedido e quando são fechadas. Para um teste curto, uma ligação terminada de forma intencional é, por isso, melhor do que uma sessão de browser, streaming ou HTTP/2 permanentemente aberta.

Recarregar uma página no browser não cria necessariamente uma nova ligação. Dependendo da aplicação, uma janela privada, um processo cliente reiniciado ou um pedido curto como o seguinte é adequado para um teste reproduzível:

curl -I https://example.com/

O comando é executado no cliente de teste, não na shell da firewall. example.com é um domínio reservado para exemplos e pode ser substituído por um serviço conhecido e permitido.

Selecionar o módulo correto

Um fluxo pode passar por vários módulos de log. O módulo Firewall pode mostrar, por exemplo, que uma regra LAN-to-WAN permitiu a ligação, enquanto Web filter, Application filter, IPS ou SSL/TLS inspection bloqueia ou trata o mesmo fluxo de forma diferente posteriormente.

Por isso, uma única entrada verde da firewall não é suficiente para problemas web ou de segurança. Os módulos devem ser correlacionados para o mesmo fluxo de teste com base no período do teste e nos endereços:

• Firewall: decisão da regra, NAT, interfaces, portas e estado básico da ligação.
• Web filter: decisões sobre URL, categoria e Web Policy.
• SSL/TLS inspection: decisões sobre certificados, handshake e desencriptação.
• Application filter: aplicação identificada e ação do Application Control.
• IPS: eventos de assinatura ou anomalia.
• VPN: estabelecimento e estado do respetivo componente VPN.
• Authentication: utilizador identificado e autenticação bem-sucedida ou falhada.
• System: eventos do sistema e iniciados por administradores.
• SD-WAN: perfil SD-WAN, SLA e utilização da rota.

Os tipos de log apresentados localmente são definidos em System services > Log settings, em Local reporting. Estes Event Logs não são o mesmo que On-box Reports. Central reporting e syslog são destinos separados e têm de ser ativados independentemente. Os eventos de Web Policy também exigem Log firewall traffic na regra de firewall associada. Os logs Wireless não estão disponíveis no Log Viewer; devem ser enviados para o Sophos Fusion (anteriormente Sophos Central) ou para um servidor syslog.

Limite do Web Proxy: A documentação SFOS 22/23 sobre o comportamento dos logs descreve este caminho proxy para HTTP/HTTPS nas portas 80 e 443: uma regra Drop correspondente encaminha os pacotes recebidos para o Web Proxy, que envia ao utilizador uma página de bloqueio; sem uma Web Exception correspondente, o log Firewall mostra Allowed e o log Web filter Blocked. As Web Exceptions continuam a aplicar-se e podem permitir pedidos apesar de Drop. O caminho documentado de Reject termina o fluxo antes do processamento pelo proxy. Verificar em conjunto a regra de firewall, a Web Policy e as Web Exceptions; é um cenário documentado, não uma garantia universal de página de bloqueio para qualquer build ou modo de inspeção.

Conflito documental por resolver: A ajuda SFOS 22/23 do formulário de regras descreve a autenticação de utilizadores web desconhecidos com Use web authentication for unknown users ativo, permite as Web Exceptions correspondentes e, nos restantes casos, descreve uma página de bloqueio HTML. Em contrapartida, o guia de logging do tráfego descartado descreve o descarte silencioso e associa a página de bloqueio web a essa opção de autenticação. Não concluir que só a opção determina a resposta. Antes de confiar em Drop para bloquear tráfego web, obter esclarecimento escrito da Sophos para a versão, build e caminho de processamento exatos, ou realizar uma verificação isolada e expressamente autorizada. Registar a regra e as definições atuais para reversão; verificar HTTP e HTTPS separadamente, utilizadores conhecidos/desconhecidos, autenticação ativa/inativa e exceções correspondentes presentes/ausentes. Correlacionar novos fluxos com Rule ID, logs, Packet Capture e resultados do browser. Nem uma página de bloqueio nem um timeout provam, por si só, o bloqueio. Se o acesso for inesperado ou o resultado pouco claro, reverter as alterações de teste e escalar; não implementar em produção.

Nas portas diferentes de 80 e 443, uma regra Drop correspondente descarta os pacotes diretamente; o log Firewall mostra dropped. Com Reject, o log Firewall mostra rejected, tanto em 80/443 como noutras portas. Estas observações exigem Log firewall traffic na regra correspondente. Uma Web Exception pode, por exemplo, permitir atualizações do Windows da Microsoft apesar de uma regra Drop; isso não justifica alargar a regra sem análise.

Regra Allow e heartbeat em falta

Um caso diferente de Drop ocorre quando a regra de firewall que efetivamente corresponde tem Action Allow, Block clients with no Heartbeat está ativo e o endpoint não envia heartbeat. Para observar os logs aqui descritos, Log firewall traffic tem de estar ativo nessa regra. Antes de pesquisar, verificar também os tipos de log necessários em System services > Log settings > Local reporting; ativar apenas um destino externo não basta para a vista local.

• Portas diferentes de 80 e 443: A firewall descarta os pacotes deste endpoint. O log Firewall mostra dropped.
• Portas 80 e 443 no caminho Web Proxy documentado: A firewall aceita os pacotes recebidos e encaminha-os para o Web Proxy. Como o endpoint não envia heartbeat, o sistema heartbeat decide bloquear; o proxy envia ao utilizador uma página de bloqueio. O log Firewall mostra allowed, outro log Firewall mostra Heartbeat blocked e o log Web filter mostra blocked. Aqui, Heartbeat blocked também pertence ao módulo Firewall, não a um módulo separado de logs heartbeat.

Allowed, por si só, não prova que o acesso tenha sido bem-sucedido. Antes de alterar uma regra, correlacionar as entradas do mesmo fluxo de teste: verificar em conjunto o período do teste, origem, destino, portas e regra correspondente. Procurar a entrada separada Heartbeat blocked e a entrada Web filter com blocked. Não é necessária uma ordem fixa dos eventos, timestamps idênticos ou um número universal de linhas; se faltarem entradas esperadas, verificar primeiro o logging, os destinos locais e os filtros e usar Packet Capture se necessário.

Esta interpretação aplica-se a esta opção exata da regra, a um endpoint sem heartbeat e ao caminho proxy descrito. Não é uma afirmação geral sobre todas as regras Allow, endpoints com estado vermelho ou outro estado não saudável, nem outros modos de inspeção. Não desativar a exigência de heartbeat como solução genérica; primeiro esclarecer a correspondência da regra e a causa do heartbeat em falta.

Distinguir Standard view de Detailed view

A Standard view é útil para uma leitura rápida. As colunas podem ser mostradas ou ocultadas e um clique num valor pode usá-lo diretamente como filtro. Para validações técnicas, a Detailed view é mais importante porque mostra os nomes dos campos subjacentes e valores adicionais.

Um detalhe NAT importante: se for utilizado um endereço de origem traduzido diferente do endereço MASQ predefinido, a Standard view pode continuar a mostrar o endereço MASQ como endereço de saída. A origem realmente traduzida aparece na Detailed view no campo src_trans_ip.

Na Standard view, passar o rato sobre o ícone de um módulo também apresenta detalhes. A função de cópia coloca informações do log na área de transferência. O viewer abre numa nova janela de ecrã inteiro; se não aparecer, verificar primeiro o bloqueador de popups do browser.

Campos típicos para um teste de firewall são:

• IP de origem e de destino, bem como portas de origem e de destino
• In interface e Out interface
• Firewall Rule ID e NAT Rule ID
• Action ou estado
• nome do utilizador, se tiver sido identificada uma identidade
• origem e destino traduzidos
• Log component e Log subtype

Um nome de campo ou um ID não explica automaticamente a causa. A Rule ID é comparada com a base de regras atual, a NAT ID com a regra NAT correspondente e um ID de política de segurança com o respetivo módulo.

Se estiver simultaneamente ativo um Packet Capture em Diagnostics > Packet capture, a opção Open PCAP na entrada de log correspondente pode abrir as informações dos pacotes associados. Isto relaciona a decisão registada com os detalhes dos pacotes, mas não substitui um filtro de captura bem delimitado: origem, destino, porta e hora do teste têm de continuar a corresponder ao fluxo analisado.

Isolar o fluxo correto

Definir filtros até restar o fluxo correto

O Log Viewer disponibiliza quatro níveis de filtragem:

1. Module: limita a vista a Firewall, Web, IPS, VPN ou outra área.
2. Time / Timer filter: limita os eventos ao período de teste; clicar em Timer filter e escolher uma opção temporal.
3. Add filter: combina um campo específico, uma condição e um valor.
4. Free text search: procura, por exemplo, portas, endereços IP, utilizadores ou nomes de regras e também funciona com informações anonimizadas.

Num teste normal de ligação, começa-se pelo IP de origem, IP de destino e porta de destino. Depois, limita-se ainda mais com Rule ID, utilizador ou Action. Reset remove todos os filtros. Isto é importante porque um filtro temporal ou de campo antigo pode dar a impressão de que o viewer deixou de receber eventos.

O número de entradas disponíveis depende do tamanho do disco e da retenção local. Por isso, o Log Viewer não substitui um arquivo de longo prazo protegido contra manipulação. Para esse fim, são adequados o Central Firewall Reporting ou o envio de syslog para um SIEM.

A quota local de Event Logs depende do modelo de appliance: para modelos de gama alta, a Sophos indica até 15 % de toda a partição /var ou 50 % do seu espaço livre, consoante o valor menor. Não é um período de retenção garantido nem uma quota para todos os modelos. A análise de armazenamento distingue Event Logs, relatórios e Troubleshooting Logs; não se devem eliminar ficheiros por tentativa.

Utilizar corretamente Pause, Refresh e a exportação CSV

Pause interrompe a atualização automática da vista. É útil para ler ou copiar uma linha com calma. Não interrompe o registo na firewall. Refresh atualiza manualmente a vista e Export descarrega os logs atualmente disponíveis em CSV.

Antes de uma exportação, documentar o módulo, o intervalo de tempo e os filtros. O CSV pode conter endereços IP internos, nomes de utilizadores, URLs e relações de comunicação e, por isso, deve permanecer num fluxo protegido de suporte ou análise.

Quando Data anonymization está ativa, valores identificadores como nome de utilizador, endereços IP, MAC e e-mail são apresentados de forma protegida. A Sophos recomenda pelo menos dois Authorizers: se o administrador com sessão iniciada for um deles, pelo menos outra pessoa autorizada tem de aprovar a desanonimização. Mesmo assim, um screenshot ou uma exportação deve conter apenas as linhas necessárias para o caso.

Para mostrar identidades através da função de desanonimização, é necessário ter autorização e fornecer as credenciais de autenticação. Copiar uma linha não substitui essa autorização.

Compreender Log suppression e Log occurrence

Em System services > Log settings, a firewall pode suprimir eventos Firewall consecutivos e idênticos. Isto poupa armazenamento e processamento. A supressão afeta não só os logs locais, mas também o Sophos Fusion e os destinos syslog configurados.

No Log Viewer, Log occurrence mostra quantas vezes ocorreu um evento agrupado. Uma única linha pode, portanto, representar muitas repetições. Não deve ser contabilizada automaticamente como um único pacote ou uma única ligação.

Antes de alterar Log suppression, verificar se o volume atual de logs é realmente a causa do problema. Para uma análise curta, normalmente é suficiente interpretar conscientemente Log occurrence. Uma alteração global também afeta os destinos de logs externos e não deve ser feita apenas para obter um screenshot.

Interpretar os resultados com segurança

Interpretar corretamente Invalid traffic

Invalid traffic significa que o conntrack não conseguiu associar um pacote a uma ligação atual. Isto pode acontecer devido a um caminho assimétrico, uma sessão expirada, flags TCP inesperadas ou pacotes RST e FIN adicionais. Não significa automaticamente um ataque nem uma avaria da firewall.

Se existir simultaneamente um problema de ligação, os dois sentidos devem ser verificados com Packet Capture. Origem, destino, flags TCP, interfaces e timestamps têm de pertencer ao mesmo fluxo. Aumentar Tcp Connection Establishment Idle Timeout pode reduzir o número destes logs, mas não resolve a causa subjacente no caminho ou na sessão. Por isso, o valor não deve ser alterado por tentativa.

O registo Invalid traffic está ativo por predefinição. O conntrack acompanha sessões TCP e determinadas sessões UDP e ICMP; pacotes iniciais, como TCP SYN ou um pedido ICMP Echo, estabelecem a associação à ligação. As flags TCP interpretam-se assim:

• SYN: solicita sincronização.
• SYN-ACK: confirma-a e acorda os parâmetros da ligação.
• ACK: confirma o acordo; pode começar a transferência de dados.
• PSH: solicita a entrega imediata dos dados.
• FIN: solicita um encerramento ordenado; ambas as partes confirmam a conclusão.
• RST: termina a ligação sem esperar resposta, por exemplo após um pacote inesperado.

Pacotes RST e FIN adicionais podem ser descartados e registados como Invalid traffic. Uma entrada isolada deve ser correlacionada com o problema real de ligação, em vez de ser considerada um ataque separado.

O comando só de leitura show advanced-firewall na Device Console mostra o valor global atual; a Sophos documenta 10800 segundos, ou três horas, como predefinição. Uma alteração afeta todas as sessões TCP correspondentes da firewall. Primeiro devem ser correlacionados de forma inequívoca a aplicação afetada, o seu tempo real de inatividade e o evento Invalid traffic. Um timeout superior é apenas um ajuste operacional justificado, não uma correção para routing assimétrico ou perda de pacotes.

O fluxo completo de análise de drops com Reason, Rule ID e a Firewall ID especial 0 é explicado em Analisar pacotes descartados na Sophos Firewall.

A fonte chama ao campo Tcp Connection Establishment Idle Timeout, mas descreve entradas conntrack que expiram após inatividade e usa o parâmetro tcp-est-idle-timeout. Esta designação é ambígua; não demonstra um timeout de handshake separado. Deve verificar-se a saída real e a ajuda CLI do build utilizado.

A referência CLI SFOS 22/23 associa explicitamente tcp-est-idle-timeout a ligações TCP já estabelecidas e permite de 2700 a 432000 segundos. A designação diferente do campo não é, por isso, utilizada como recomendação para alterar um timeout de estabelecimento da ligação.

Só se um caso confirmado de timeout por inatividade justificar um ajuste global, selecionar 4. Device Console na CLI, registar o valor atual com show advanced-firewall e acordar uma janela de manutenção. O exemplo documentado aumenta-o para seis horas; não é um valor recomendado de forma geral:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Verificar o novo valor e repetir o teste da mesma aplicação durante o período de inatividade relevante. Menos entradas Invalid traffic não provam, por si só, uma correção. Para reverter, usar o mesmo comando de configuração com os segundos anteriormente registados e verificar com show advanced-firewall; 10800 só é adequado se era o valor original. Se a saída CLI não for clara ou o problema persistir, parar os ajustes e analisar o caminho dos pacotes ou recorrer ao suporte. Este procedimento foi verificado documentalmente, não testado numa firewall.

Alterar regras a partir do Log Viewer apenas de forma controlada

Dependendo do evento, o Log Viewer pode abrir diretamente Web Policies ou regras NAT, de firewall ou SSL/TLS. Clicar numa Web Policy, regra NAT ou regra de firewall disponibiliza uma ligação para a edição no WebAdmin. Isto é prático, mas não encurta a verificação técnica. Antes da edição, verificar Rule ID, nome e posição da regra, zonas, objetos, serviço, correspondência de utilizador e sessões existentes; registar também os valores atuais dos campos a alterar para que possam ser repostos.

Para uma exceção SSL/TLS, selecionar SSL/TLS inspection, deslocar-se até Manage, escolher Exclude, verificar a opção no diálogo e só depois confirmar com Exclude. Domain e Subdomain são adicionados ao grupo URL Local TLS exclusion list, visível em Categories and websites nas regras SSL/TLS. Web category é adicionado a Exclusions by website or category, visível na lista de regras SSL/TLS. Para Other properties, selecionar a regra SSL/TLS e objetos adequados, como utilizadores ou endereços IP. Antes de confirmar, verificar o objeto de destino e o âmbito; uma exclusão de domínio não equivale a uma exceção prevista para um só utilizador. O Log Viewer não disponibiliza Exclude para 19004 (tráfego permitido) ou 19005 (bloqueado por uma Web Policy).

Um clique numa IPS Signature ID pode disponibilizar Disable signature for this IPS policy. Esta ação altera a IPS Policy ativa e não apenas a vista. Primeiro devem ser documentadas a regra, a policy, a assinatura, o impacto na proteção e o âmbito da exceção; depois volta a testar-se exatamente o fluxo confirmado.

Uma regra Allow abrangente, uma exceção web global ou a SSL/TLS inspection desativada pode ocultar o sintoma e criar ao mesmo tempo uma nova falha de segurança. As alterações devem, por isso, limitar-se ao fluxo confirmado, ser testadas numa janela de manutenção e depois validadas novamente com um novo fluxo no Log Viewer e, se necessário, no Packet Capture. Se o teste falhar ou a exceção for demasiado ampla, deve repor-se o estado anteriormente registado no objeto de regra ou policy associado e repetir o teste com um novo fluxo.

Quando faltam logs ou estão no outro nó HA

Quando faltam os logs esperados

Um resultado vazio é verificado pela seguinte ordem:

1. Verificar Pause, módulo, intervalo temporal e filtros e depois utilizar Reset e Refresh.
2. Verificar o logging da regra e Local reporting para o tipo de log necessário.
3. Criar uma nova ligação terminada de forma intencional com timestamp conhecido.
4. Usar Packet Capture para confirmar que o tráfego chega à firewall e que Rule ID o processa.
5. Verificar outros módulos quanto a eventos do mesmo fluxo.
6. Só investigar o caminho do viewer ou do serviço de logging se toda a vista local deixar de receber eventos novos.

O procedimento de diagnóstico específico da versão para um viewer totalmente parado é explicado em Log Viewer não mostra novos logs. Um restart do serviço ou uma intervenção na base de dados local de logs não faz parte da utilização normal.

Log Viewer em ambientes HA

Cada node HA guarda apenas os logs e relatórios do tráfego que ele próprio processou. Especialmente em active-active ou depois de um failover, a entrada esperada pode, por isso, estar no outro node. O momento, a função do node e Connection served by devem ser documentados em conjunto.

O Central Firewall Reporting ou syslog podem proporcionar uma vista central. No entanto, não substituem a verificação específica do node quando se analisa uma mudança concreta de função HA, uma falha local de serviço ou o caminho do tráfego no momento do evento.