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.

Um Threat Feed é uma lista continuamente atualizada desses indicadores, abreviados como IoCs (Indicators of Compromise). O X-Ops recebe automaticamente a base de dados global do SophosLabs; não se introduz um URL de feed próprio. Em Active Threat Response, é possível configurar um ou vários módulos: MDR Threat Feeds fornecem informações dos analistas de MDR sobre ameaças ativas na própria rede; NDR Essentials analisa o tráfego da firewall com aprendizagem automática, avalia os IoCs detetados e regista-os. Em Third-Party Threat Feeds, por outro lado, configuram-se URLs de feeds próprios. Um módulo X-Ops ativo não ativa automaticamente os outros módulos.

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).

Antes de efetuar alterações, documentam-se o build do firmware, as licenças, a Action atual, o âmbito da inspeção, os destinos dos logs e as exceções. Para Synchronized Security, é também necessária uma licença Intercept X no Sophos Fusion ou no Sophos Central; a licença X-Ops, por si só, não fornece integração com endpoints. Verifica-se também se as regras da firewall reagem a um Security Heartbeat vermelho: nesse caso, a alteração de estado documentada no SFOS 23 pode afetar o acesso do endpoint, além da ligação individual bloqueada.

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. Guardar os destinos de log suportados neste modelo na página Log settings com Apply. Recarregar a página e confirmar que os destinos selecionados continuam definidos antes de passar à configuração do X-Ops. Os logs de eventos locais não são equivalentes aos relatórios locais; as alternativas para modelos sem relatórios locais encontram-se abaixo.
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.
SFOS 23: Log only regista o evento sem alterar o estado do Security Heartbeat do endpoint. Log and drop regista o evento, bloqueia a ameaça e muda o estado do Security Heartbeat do endpoint para vermelho.
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 88/88w 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 Fusion (anteriormente 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.

A visão geral e a descrição do X-Ops não são inteiramente coerentes entre si: A matriz de tráfego da visão geral do SFOS 22/23 indica que o X-Ops não suporta Destination Match, mas suporta Source Match local. No entanto, a secção de configuração do X-Ops descreve a comparação com endereços IP, domínios e URLs maliciosos, na qual se baseia a inspeção de destinos neste artigo. Esta matriz contraditória não permite garantir a cobertura de todos os destinos de tráfego encaminhado nem estabelecer uma cobertura fiável de Source Match local. Para definir estes limites, é necessária uma confirmação para o build utilizado antes de substituir as regras de proteção existentes. De forma coerente, a matriz não indica proteção X-Ops para origens remotas em DNAT/WAF nem para origens de tráfego destinado ao sistema, dirigido ao WebAdmin, ao VPN-Portal ou à VPN. Para estes serviços, continuam a ser necessárias regras restritivas de firewall, WAF e Device Access; os feeds alternativos são contextualizados no artigo sobre Third-Party Threat Feeds.

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 a deteção de domínios, as definições necessárias relacionadas com IPS têm de estar efetivas: Application Classification tem de estar ativada ou deve estar selecionada uma política IPS na regra de firewall em causa. Segundo a documentação, Application Classification está ativada por predefinição; ainda assim, verifica-se o estado real. Neste contexto, não deve ser entendida como uma opção adicional em cada regra de firewall. Este requisito aplica-se especialmente a HTTPS e a consultas DNS a resolvers externos através de HTTP ou HTTPS. Se faltar a classificação necessária, a comparação de domínios pode não ocorrer no percurso de tráfego em causa.

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.

No Web Proxy, selecionam-se as opções Use web proxy instead of DPI engine e Decrypt HTTPS during web proxy filtering em Web filtering, na regra de firewall adequada. No percurso DPI, Use web proxy instead of DPI engine permanece desativada; a regra de desencriptação adequada é configurada em Rules and policies > SSL/TLS inspection rules, com Action definida como Decrypt. Ambos os percursos também precisam dos pré-requisitos de classificação acima indicados para uma inspeção completa dos URLs HTTPS. Altera-se apenas o percurso de tráfego aprovado e, em seguida, verificam-se a confiança nos certificados, o processo de negócio normal e a regra efetivamente aplicada no Log Viewer.

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.

A documentação descreve a diferença de desempenho entre os dois âmbitos de inspeção como geralmente pequena, mas potencialmente significativa em situações de tráfego elevado. Antes da alteração, regista-se o valor anterior. Se a comparação revelar uma degradação relevante, repõe-se o âmbito de inspeção anterior em Advanced security settings, guarda-se com Apply e verificam-se novamente o processo de negócio, a carga e o registo de logs. Para isso, não é necessário desativar a ação de bloqueio de forma generalizada.

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 obter um resumo local, abre-se Reports > Network & threats > Active threat response. O widget com o mesmo nome no Control Center apresenta uma visão geral dos hosts afetados e dos eventos de ameaça. MDR e X-Ops apresentam o estado e as ameaças bloqueadas; NDR Essentials apresenta o estado e as ameaças monitorizadas; Third-Party Threat Feeds apresenta também os feeds configurados e o respetivo estado de sincronização. Configure abre a configuração, Reports abre os relatórios e More details expande a vista do widget. Nos dispositivos sem relatórios locais o botão Reports não está disponível; nesses casos, utilizam-se os destinos Central ou Syslog configurados. Uma contagem de ameaças monitorizadas pelo NDR não constitui prova de bloqueio. A ação concreta e os detalhes da ligação são verificados no relatório ou no Log Viewer. Para Third-Party Threat Feeds, o widget apresenta também o número de ameaças bloqueadas por esses feeds.

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:

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.
Em Log viewer > Active threat response, verificar o módulo, a ação efetivamente aplicada e os detalhes da ligação para o mesmo IoC. Apenas uma ação de bloqueio comprovada de um módulo anterior, como o MDR com Log and drop, termina a verificação antes do X-Ops. O NDR Essentials deteta e regista com Log threats, mas não bloqueia. Um evento monitorizado pelo NDR, por si só, não termina a verificação pelo X-Ops nem explica a ausência de uma entrada de log do X-Ops.
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.
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.
Procurar o domínio ou URL em Log viewer > Web filter; verificar também a coluna Category e a vista de detalhes. Aí são identificados o ID da regra de firewall e a política Web selecionada. Se a Web policy responsável indicar Allow, verificar a ordem das regras e das políticas. Para um domínio ou URL confirmado como malicioso, pode utilizar-se um grupo de URLs com âmbito estritamente limitado, com uma ação Block numa política Web, numa regra LAN-to-WAN adequada colocada acima da regra que até então permitia o tráfego. No percurso Web Proxy, verificar também Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses e Source IP addresses podem abranger o indicador ou o endpoint que efetua o pedido. No percurso DPI, verificar as SSL/TLS Exclusion Lists. Uma exceção não deve ser removida indiscriminadamente; primeiro, esclarecem-se a sua finalidade, o processo de negócio afetado e a aprovação.
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 é:

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 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.

Para uma exceção aprovada, abre-se Protect > Active threat response > Add threat exclusions e utiliza-se uma das seguintes alternativas, conforme o tipo de exceção:

Hosts ou redes: Em Host and network exclusions, clicar em Add new item e selecionar apenas os objetos de host ou de rede aprovados.
Indicador de ameaça: Em alternativa, em Threat exclusions, introduzir o endereço IP, domínio ou URL aprovado e adicioná-lo à lista com Add. Respeitar o limite de 128 caracteres por entrada.

Em seguida, guardar com Apply. Voltar a abrir a página e confirmar que apenas as entradas pretendidas ficaram guardadas. Add new item ou Add, por si só, não substitui este passo final de gravaçã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.

Para regressar ao estado anterior, apenas se anula a última alteração efetuada: o âmbito da inspeção é definido para o valor anterior documentado e guardado com Apply; uma regra ou exceção Web/SSL/TLS recém-criada é revertida de forma específica, sem alterar as regras existentes nem outras exceções. Em seguida, voltam a verificar-se o processo de negócio, a regra que efetivamente corresponde e os logs. Se uma exceção for revertida, a correspondência em causa pode voltar a ser bloqueada. Se uma perturbação operacional exigir temporariamente Log only, o bloqueio pelo X-Ops fica suspenso durante esse período; definem-se os responsáveis e a hora de fim, e repõe-se Log and drop depois de esclarecida a causa. Um módulo desativado não é uma forma equivalente de regressar ao estado anterior, pois deixa também de realizar a sua inspeção. Um teste controlado com um feed piloto próprio e dedicado em Third-Party Threat Feeds comprova apenas o percurso do tráfego desse feed, não a entrega da base de dados X-Ops nem a verificação de correspondências nessa base de dados.

XML API: tratar separadamente a ativação, a ação e as exceções

Ao automatizar o X-Ops, é necessário distinguir três definições independentes no objeto XML documentado ATP. A referência da API do SFOS-22/23 descreve:

ATP/ThreatProtectionStatus: interruptor escalar do módulo com Enable ou Disable. Ativa ou desativa o X-Ops; não é a ação aplicada a uma correspondência nem uma exceção individual.
ATP/Policy: ação escalar aplicada a uma correspondência. A tabela de parâmetros indica Log Only e Log and Drop, apresenta Log Only como valor predefinido e assinala o campo como obrigatório quando o X-Ops está ativado. Trata-se de uma indicação da tabela da API, não de uma prova do estado guardado na própria firewall.
ATP/InspectContent: âmbito de inspeção escalar com all ou untrusted. Um âmbito de inspeção diferente não equivale a Disable nem a uma alteração da ação aplicada a uma correspondência.
ATP/HostException/Host: lista de cadeias de caracteres para hosts ou redes de origem a excluir. O exemplo contém HostName; para adicionar uma entrada, é necessária a referência de objeto aprovada da própria configuração.
ATP/ThreatException/Threat: lista separada de cadeias de caracteres para indicadores de destino a excluir. A tabela da API indica endereços IP de destino e domínios. A introdução de URLs na interface, descrita acima, não comprova, por si só, uma sintaxe de payload XML para URLs.

As duas listas de exceções estão, portanto, aninhadas sob elementos-pai diferentes e podem conter várias entradas. Não são interruptores de desativação global. A tabela da API indica o seu efeito no X-Ops, no MDR e nos Third-Party Threat Feeds; por isso, o aviso mais abrangente sobre o efeito transversal aos módulos e as regras de aprovação na secção sobre exceções continuam a ser importantes.

Esclarecer o conflito de Policy antes de efetuar um pedido de escrita: O exemplo XML utiliza o texto alert/drop para Policy, enquanto a tabela de parâmetros indica Log Only e Log and Drop. Estas formas não são convertidas implicitamente entre si; a grafia dos rótulos da interface também não comprova que um valor seja válido para a API. Antes da automatização, confirmam-se o valor concreto e a estrutura do pedido na ajuda da API do build instalado ou com o Sophos Support. Até essa confirmação, o exemplo não é um pedido pronto a copiar cujo funcionamento tenha sido verificado.

A configuração segura da XML API é tratada separadamente. Antes de uma alteração aprovada, guardam-se o estado do módulo, a ação, o âmbito de inspeção e ambas as listas de exceções. Depois, volta-se a ler o estado efetivamente guardado ou abre-se a página de configuração e comparam-se estas cinco áreas individualmente. Em caso de erro, verifica-se primeiro o estado guardado antes de repetir o pedido; uma exceção ou um âmbito de inspeção diferente não pode resultar inadvertidamente numa desativação global.