Utilizar corretamente o Log Viewer da Sophos Firewall
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
- Na regra de firewall afetada, verificar Log firewall traffic ou, na regra SSL/TLS, Log connections.
- Em System services > Log settings, confirmar que o tipo de log necessário está ativo em Local reporting.
- Abrir Log viewer no canto superior direito do WebAdmin e selecionar o módulo adequado.
- Definir o filtro temporal e usar Add filter para começar por limitar a origem, o destino e o serviço.
- Gerar um novo fluxo de teste curto e registar a hora exata.
- Em Detailed view, verificar Rule ID, NAT ID, ação, interfaces, utilizador e campos específicos do módulo.
- 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?
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 timestamp e os mesmos 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.
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.
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.
Definir filtros até restar o fluxo correto
O Log Viewer disponibiliza quatro níveis de filtragem:
- Module: limita a vista a Firewall, Web, IPS, VPN ou outra área.
- Time: limita os eventos ao período de teste.
- Add filter: combina um campo específico, uma condição e um valor.
- 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.
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 desanonimização exige uma pessoa autorizada e as respetivas credenciais. Mesmo assim, um screenshot ou uma exportação deve conter apenas as linhas necessárias para o caso.
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 Central 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 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 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.
Alterar regras a partir do Log Viewer apenas de forma controlada
Dependendo do evento, o Log Viewer pode abrir diretamente Web Policies, regras de firewall ou regras SSL/TLS. 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.
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.
Quando faltam os logs esperados
Um resultado vazio é verificado pela seguinte ordem:
- Verificar Pause, módulo, intervalo temporal e filtros e depois utilizar Reset e Refresh.
- Verificar o logging da regra e Local reporting para o tipo de log necessário.
- Criar uma nova ligação terminada de forma intencional com timestamp conhecido.
- Usar Packet Capture para confirmar que o tráfego chega à firewall e que Rule ID o processa.
- Verificar outros módulos quanto a eventos do mesmo fluxo.
- 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.
Porque aparece mais tarde no Log Viewer uma ligação permitida?
Destroy, quando a ligação termina. Uma sessão longa ou reutilizada pode, por isso, aparecer com atraso. Para o teste, deve ser criada uma ligação nova, curta e terminada intencionalmente.