Sophos Firewall ATP: configurar X-Ops Threat Feeds

A antiga Advanced Threat Protection (ATP) chama-se Sophos X-Ops Threat Feeds no SFOS 22. A firewall compara o tráfego de saída com uma base de dados gerida pela Sophos que contém endereços IP, domínios e URLs maliciosos conhecidos. Desta forma pode, por exemplo, impedir que um cliente infetado contacte um servidor de Command and Control conhecido.

Em produção, o objetivo é Log and drop. A função está desativada por predefinição e, depois de ativada, só bloqueia se esta ação for selecionada.

Configurar X-Ops Threat Feeds

O módulo X-Ops requer Network Protection. Para implementar a inspeção dos threat feeds é também necessário Web Protection. Ambas as licenças estão incluídas nos bundles Standard e Xstream Protection ou podem ser licenciadas separadamente; o X-Ops não requer uma licença adicional do Sophos Fusion (anteriormente Sophos Central).

1. Abrir System services > Log settings.
2. Na linha Active threat response, ativar pelo menos Local reporting. Conforme o modelo de operação, selecionar também o destino Syslog pretendido e Central reporting.
3. Abrir Protect > Active threat response > Sophos X-Ops threat feeds.
4. Ativar Sophos X-Ops threat feeds.
5. Em Action, escolher Log only para um piloto curto e controlado ou Log and drop para proteção em produção.
6. Em Advanced security settings, decidir entre Inspect untrusted content e Inspect all content.
7. Guardar com Apply.
8. Em seguida, verificar a definição, os destinos de logs e as exceções existentes.

Os modelos XGS 87/87w e 107/107w não suportam reporting local. Nestes modelos utiliza-se Central Reporting ou um servidor Syslog. A coluna Central reporting só aparece depois de ativar Send reports and logs to Sophos Central em Sophos Central.

A Sophos recomenda bloquear IoCs conhecidos em vez de apenas os registar. Num ambiente novo ou ainda não monitorizado, Log only pode, no entanto, ser útil durante uma fase de observação curta e com um prazo claramente definido. Esta fase precisa de um responsável e de uma data de mudança; caso contrário, a função pode permanecer indefinidamente sem efeito de bloqueio.

O que o X-Ops protege — e o que não protege

O X-Ops verifica destinos maliciosos conhecidos no tráfego de saída encaminhado. Um evento típico ocorre quando um cliente ou servidor tenta aceder a um IP, domínio ou URL conhecido por malware, phishing ou C2. Conforme a ação selecionada, a tentativa é apenas registada ou diretamente descartada.

Por outro lado, o X-Ops não suporta Source Matches locais ou remotos. Por isso, não bloqueia automaticamente endereços IP de atacantes conhecidos que acedem como origem a uma publicação DNAT ou WAF, ao WebAdmin ou a um VPN Portal. Para estes casos são mais adequados MDR, NDR ou Third-Party Threat Feeds, juntamente com regras restritivas de firewall, WAF e Device Access.

O IPS, o Malware Scanning e o Zero-Day Protection também desempenham funções diferentes. O X-Ops trabalha com indicadores: um destino tem de ser previamente conhecido como IoC malicioso. O IPS, por sua vez, deteta padrões de ataque conhecidos no tráfego. As duas funções complementam-se, mas não se substituem.

O Active Threat Response verifica os módulos por esta ordem: MDR, NDR Essentials, Sophos X-Ops e depois Third-Party Threat Feeds. Se um módulo anterior bloquear o mesmo IoC, a firewall interrompe a verificação. A ausência de um registo X-Ops não significa, portanto, que nenhuma proteção tenha atuado. O guia de Third-Party Threat Feeds explica em maior detalhe a ordem e os indicadores sobrepostos.

Condições necessárias para detetar eventos

A ativação, por si só, não garante que a firewall consiga ver todos os indicadores de IP, domínio ou URL. O fator decisivo é a informação visível no respetivo percurso de rede.

Endereços IP

Para detetar um IP de destino, o tráfego de saída tem de passar por uma regra de firewall adequada. A firewall pode comparar diretamente o endereço de destino com o feed X-Ops; para isso não é necessária a desencriptação TLS.

Domínios

Para detetar domínios, a regra de firewall em causa deve ter Application Classification ativa ou uma IPS Policy selecionada. Se ambas estiverem ausentes, pode faltar a classificação necessária nesse percurso de tráfego.

Se a própria firewall responder aos pedidos DNS dos clientes, o módulo DNS efetua a correspondência do domínio. Se os clientes utilizarem um resolver externo, esse percurso DNS também tem de atravessar a firewall e ficar visível com as definições IPS necessárias. Quando não surge uma deteção de domínio, deve verificar-se o percurso do resolver realmente utilizado e não apenas a regra do cliente para o destino Web.

URLs completos através de HTTPS

Além do domínio, um URL contém também um caminho, por exemplo https://example.invalid/download/payload.exe. Em tráfego HTTPS encriptado, sem desencriptação a firewall normalmente só vê o domínio através de SNI, mas não o caminho /download/payload.exe.

Para verificar o indicador URL completo, é necessário um Web Proxy com desencriptação HTTPS ativa ou uma regra de SSL/TLS Inspection adequada com Decrypt. A TLS Inspection não deve ser ativada globalmente e sem controlo apenas por causa do X-Ops: distribuição de certificados, privacidade, exceções, compatibilidade de aplicações e desempenho exigem um rollout próprio.

Escolher conscientemente o âmbito da inspeção

Em Advanced security settings define-se com que amplitude o X-Ops inspeciona o tráfego:

• Inspect untrusted content limita a inspeção ao tráfego com origens ou destinos não confiáveis. Esta opção requer menos recursos e constitui um ponto de partida sensato quando a carga e os efeitos secundários ainda não são conhecidos.
• Inspect all content inspeciona tráfego confiável e não confiável. Oferece maior cobertura, mas pode afetar o desempenho, sobretudo em ambientes com muito tráfego.

Em redes de clientes, servidores ou administração particularmente sensíveis, Inspect all content pode ser apropriado se a appliance tiver reserva suficiente. A alteração deve ser efetuada durante uma janela de manutenção. Depois comparam-se a utilização de CPU, a latência, o throughput e as ocorrências no helpdesk com o estado anterior.

Durante a introdução, a ação e o âmbito da inspeção não devem ser alterados várias vezes em simultâneo. Ao mudar primeiro a visibilidade e depois a ação de bloqueio, torna-se mais fácil perceber qual definição causou um problema.

Verificar o efeito e o logging

Depois de guardar, não basta verificar se o interruptor está ativo. Uma validação operacional sólida inclui três níveis:

1. Configuração: o X-Ops está ativado e foram guardados a Action e o âmbito de inspeção pretendidos.
2. Visibilidade: a regra de firewall, Application Classification ou IPS e, para URLs HTTPS completos, a desencriptação TLS correspondem ao tipo de indicador.
3. Evidência: os eventos estão disponíveis em Log viewer > Active threat response ou no destino Central ou Syslog configurado.

Para um resumo local, abre-se Reports > Network & threats > Active threat response. O widget com o mesmo nome no Control Center mostra o estado e o número de ameaças bloqueadas; a ação concreta e os detalhes da ligação são verificados no relatório ou no Log Viewer.

O tipo técnico do log Syslog continua a chamar-se ATP, embora a interface utilize atualmente X-Ops e Active Threat Response. Conforme o percurso de processamento, log_component pode indicar Firewall, DNS, IPS ou Web. Para uma análise são especialmente úteis o timestamp, a ação, Source, Destination, portas, domínio ou URL, Threat Name, Feed Name e Event ID.

Na Advanced Shell, ips.log é o principal log do engine para Active Threat Response. garner.log ajuda a analisar o processamento e o encaminhamento de eventos, sobretudo quando o Central Reporting parece incompleto. A visão geral dos serviços e logs da Sophos Firewall explica estes ficheiros e o acesso SSH seguro.

Não existe um indicador de teste inofensivo do X-Ops documentado de forma geral. Por isso, não se deve abrir deliberadamente um domínio real de malware nem ligar a um endereço IP malicioso conhecido. Se for necessário um teste reproduzível, um Third-Party Pilot Feed próprio com um destino controlado é o método mais seguro. No X-Ops verificam-se a configuração e a visibilidade; o próximo evento real, cuidadosamente analisado, confirma o efeito de bloqueio.

Quando um IoC não é bloqueado ou não surge um log X-Ops

A verificação começa pelo tipo específico de indicador e pelo percurso real do tráfego. Assim evitam-se exceções abrangentes ou alterações TLS globais baseadas em suposições:

1. Em Protect > Active threat response > Sophos X-Ops threat feeds, confirmar que o X-Ops está ativo e que Action está realmente definido como Log and drop. Log only apenas cria uma entrada.
2. Em Log viewer > Active threat response, verificar se o MDR ou NDR já tratou o mesmo IoC. O X-Ops deixa de ser verificado quando um módulo anterior aplica uma ação de bloqueio.
3. Para endereços IP de destino, verificar a regra LAN-to-WAN que corresponde efetivamente. Para domínios, verificar também Application Classification, a política IPS e o percurso do resolver.
4. Para URLs HTTPS completos, procurar o nome do servidor em Log viewer > SSL/TLS inspection. Se a SSL/TLS rule correspondente mostrar Don't decrypt, o X-Ops não consegue ver o caminho do URL. Só depois de identificar essa regra se deve planear uma regra Decrypt tão restrita quanto possível.
5. Procurar o domínio ou URL em Log viewer > Web filter. Se a Web policy responsável mostrar Allow, verificar a ordem das regras e políticas. No percurso Web Proxy, verificar também Web > Exceptions; em DPI, verificar as SSL/TLS Exclusion Lists.
6. Em Protect > Active threat response > Add threat exclusions, procurar tanto o IoC como o host ou a rede que efetua o pedido. Estas exceções aplicam-se a todos os módulos.

Depois de cada correção, repetir o mesmo processo de negócio e verificar os logs relevantes. Se a causa continuar pouco clara, guardar o timestamp, o ID da regra de firewall, o ID da regra Web ou SSL/TLS e a vista detalhada do evento Active Threat Response para o caso de suporte.

Analisar um alerta do X-Ops

Um IoC bloqueado é um sinal importante, mas ainda não constitui uma análise completa do incidente. O endereço de destino pode ter sido contactado por malware, uma ligação de phishing, uma extensão de browser comprometida ou um serviço legítimo classificado incorretamente.

Um procedimento adequado é:

1. Guardar o timestamp, a firewall ou o node HA, a ação e todos os detalhes do log.
2. Registar Source IP, Destination IP, domínio ou URL, portas, protocolo, Threat Name e Feed Name.
3. Correlacionar os logs de firewall, DNS, IPS e Web do mesmo período.
4. Identificar o cliente interno através do DHCP Lease, da associação de utilizador ou dos dados do endpoint.
5. Procurar no sistema afetado o processo associado, o histórico do browser, o download e outros eventos de segurança.
6. Se a compromissão for confirmada, isolar o sistema e tratá-lo de acordo com o runbook interno de Incident Response.
7. Só depois da análise decidir se é necessária limpeza, um bloqueio adicional ou uma exceção muito restrita.

Com Synchronized Security, nos endpoints Windows suportados podem aparecer também o utilizador do processo, o Endpoint ID e o caminho de execução. Estes detalhes do processo não estão disponíveis no macOS; aí, a Source IP continua a ser especialmente importante para a associação.

Falso alerta HA conhecido NC-170292

Num sistema HA com SFOS 21.5.1 MR1 Build 261, o NC-170292 pode gerar no Sophos Fusion um falso alerta Advanced threat detected com Raw Logs. Ao mesmo tempo, pode chegar um e-mail da firewall sem detalhes úteis.

Esta limitação não se aplica de forma geral a outros builds ou a firewalls standalone. Por isso, o alerta é primeiro guardado e analisado conforme descrito acima. Se o sistema corresponder exatamente ao build afetado e faltarem detalhes fiáveis do evento, a Sophos indica o reinício do serviço Garner como solução temporária. Como a Known Issues List não especifica um comando CLI concreto para este erro, o reinício só deve ser executado segundo um procedimento de suporte ou manutenção aprovado. Se os alertas se repetirem, o estado HA, o firmware build, o timestamp e garner.log devem ser incluídos no caso do Sophos Support.

Adicionar exceções apenas após análise confirmada

Em Protect > Active threat response > Add threat exclusions podem ser adicionadas Host and network exclusions e Threat exclusions para endereços IP, domínios ou URLs. Uma entrada em Threat exclusions pode ter no máximo 128 caracteres. Uma exceção deste tipo não se aplica apenas ao X-Ops, mas a todos os módulos Active Threat Response. Uma exceção rápida pode, portanto, enfraquecer ao mesmo tempo a proteção de MDR, NDR ou Third-Party Threat Feeds.

Quando um falso positivo é confirmado, deve excluir-se apenas o menor indicador necessário. A exceção deve incluir motivo, ticket, pessoa responsável e data de revisão. Excluir preventivamente redes inteiras de clientes ou grupos amplos de domínios remove o alerta visível, mas também uma grande parte da proteção.

Depois da alteração, o mesmo processo de negócio é verificado novamente e confirma-se no Log Viewer que apenas o evento pretendido deixou de aparecer. Os restantes eventos X-Ops devem continuar a ser registados ou bloqueados.