Sophos Firewall ATP: configurar X-Ops Threat Feeds

A antiga Advanced Threat Protection (ATP) chama-se Sophos X-Ops Threat Feeds nas versões atuais do SFOS. 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

Antes da ativação, é necessário licenciar Network Protection e Web Protection. Ambas as funções estão incluídas nos bundles Standard e Xstream Protection; o X-Ops não requer uma licença adicional do Sophos Central.

Abrir System services > Log settings.
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.
Abrir Protect > Active threat response > Sophos X-Ops threat feeds.
Ativar Sophos X-Ops threat feeds.
Em Action, escolher Log only para um piloto curto e controlado ou Log and drop para proteção em produção.
Em Advanced security settings, decidir entre Inspect untrusted content e Inspect all content.
Guardar com Apply.
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.

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.

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:

Configuração: o X-Ops está ativado e foram guardados a Action e o âmbito de inspeção pretendidos.
Visibilidade: a regra de firewall, Application Classification ou IPS e, para URLs HTTPS completos, a desencriptação TLS correspondem ao tipo de indicador.
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.

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 é:

Guardar o timestamp, a firewall ou o node HA, a ação e todos os detalhes do log.
Registar Source IP, Destination IP, domínio ou URL, portas, protocolo, Threat Name e Feed Name.
Correlacionar os logs de firewall, DNS, IPS e Web do mesmo período.
Identificar o cliente interno através do DHCP Lease, da associação de utilizador ou dos dados do endpoint.
Procurar no sistema afetado o processo associado, o histórico do browser, o download e outros eventos de segurança.
Se a compromissão for confirmada, isolar o sistema e tratá-lo de acordo com o runbook interno de Incident Response.
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 Central 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 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.