Recolher telemetria de rede com Sophos XDR Collector

Para OPNsense, pfSense, Netskope SSE e NetScaler ADC, o percurso documentado usa um Sophos XDR Data Collector. Primeiro implementar o collector, depois ligar a origem no formato syslog adequado e verificar a ingestão real. Um endereço syslog genérico não basta: a Sophos tem de interpretar corretamente formato e categoria.

Os dados netflow descritos exigem uma subscrição Sophos Next-Gen SIEM. Netskope e NetScaler também fornecem outros esquemas, que não têm todos a mesma nota SIEM na documentação. Para OPNsense e pfSense, o âmbito verificado são eventos de ligação firewall em netflow. SIEM e as bases das integrações explicam escolha e licenças.

Preparar collector e origens

O collector tem de estar aprovisionado para o tenant correto em Security Operations > Integrations > Data Collectors. O runbook do collector trata recursos, uplinks regionais, DNS, hora e diferenças para a antiga SVA e NDR. Um XDR Data Collector novo não assume automaticamente uma carga NDR existente.

Antes da mudança, registar percurso de logs anterior, novo destino, redes autorizadas e eventos pretendidos. Permitir syslog de entrada apenas dessas redes. Não substituir um percurso UDP documentado por TLS-syslog ou outro formato sem validar compatibilidade. UDP não confirma a entrega de cada mensagem; considerar perdas ao comparar origem e destino.

Escolher para cada piloto um evento inofensivo autorizado com hora e prova de origem. Um receiver configurado ou estado verde não prova receção de todas as categorias nem normalização. Validar separadamente comunicação, fluxo e conteúdo.

OPNsense: filterlog por UDP/514

O percurso OPNsense processa filterlog de ligações TCP, UDP e ICMP permitidas ou bloqueadas. Requer acesso administrativo e um collector acessível.

1. Após deployment, abrir Remote Logging no OPNsense. A navegação depende da versão; os valores seguintes são os documentados pela Sophos.
2. Ativar Enabled e escolher UDP(4) em Transport.
3. Em Applications, escolher filter (filterlog). Em Levels, selecionar info, notice, warn, error, critical, alert e emergency. Deixar Facilities vazio.
4. Em Hostname, introduzir o IP real do collector e em Port, 514. Desativar rfc5424. A Description documentada é FilterLog; não confundir esse nome com outro formato.
5. Guardar e gerar um evento firewall inofensivo previsto. A regra de origem tem de o registar efetivamente. Confirmar hora, endereços e ação no OPNsense e depois no esquema Sophos netflow.

Se o registo faltar, verificar logging de origem, seleção filterlog, UDP/IPv4, IP, porta e RFC5424. Não desativar proteção para forçar um fluxo de teste.

pfSense: Firewall Events em formato BSD

pfSense também fornece filter logs TCP, UDP e ICMP. O formato documentado difere de outros logs pfSense; uma seleção syslog arbitrária não o substitui.

1. Abrir Log Settings na administração pfSense.
2. Em General Logging Options, escolher BSD (RFC 3164, default).
3. Ativar Enable Remote Logging em Remote Logging Options.
4. Em Source Address, escolher interface ou rede que alcance o collector. Definir IP Protocol como IPv4.
5. Introduzir o IP real em Remote log servers e escolher Firewall Events em Remote Syslog Contents.
6. Guardar, gerar um evento autorizado efetivamente registado e encontrá-lo em netflow no tenant correto. Ação e ligação têm de corresponder à origem.

Outra Source Address pode alterar routing e correspondência firewall. Na falta de dados, verificar primeiro a saída dessa interface, depois receiver e BSD. Outras categorias não ficam automaticamente abrangidas.

Netskope SSE: Cloud Log Shipper e CEF

Há duas etapas: Netskope Cloud Log Shipper consulta as API Netskope e encaminha CEF por syslog ao collector Sophos. Uma conta Netskope introduzida diretamente no collector não substitui o Shipper.

Podem chegar atividades web/cloud, malware, alertas de segurança/policy e administração, nomeadamente em http, antivirus, thirdpartyalert, nids e auth. Os eventos adicionais de ligação/túnel netflow exigem SIEM.

1. Implementar um Cloud Log Shipper aprovado para o tenant Netskope. Configurar API e categorias segundo o procedimento Netskope correspondente. A Sophos não define permissões API universais.
2. Escolher a saída Plugin: Syslog.
3. Usar Syslog Defaults Mapping em Mapping. Preservar o percurso CEF documentado; um mapping personalizado pode alterar a normalização.
4. Definir o IP real do XDR Data Collector como destino. Transporte e receiver têm de coincidir com a configuração aprovada; os requisitos UDP/514 de outros produtos não determinam uma porta Netskope universal.
5. Escolher um evento adequado e confirmar a sua recolha pela API e envio pelo Shipper. Comparar depois esquema e campos na Sophos.

Se faltarem apenas ligações, verificar também categorias e entitlement SIEM. Um registo HTTP não prova todas as categorias Netskope. Separar falhas da consulta API e do envio syslog.

NetScaler ADC: auditoria com hora inequívoca

NetScaler ADC, anteriormente Citrix ADC, envia eventos web/Application Firewall (http), autenticações/sessões VPN (auth) e comandos administrativos (managementevent). Abertura e fecho TCP são netflow e exigem SIEM.

1. Após deployment do collector, abrir Audit Logging para syslog no NetScaler. Ajustar servidor/policy à versão e âmbito; a fonte Sophos não documenta um comando CLI universal.
2. Usar o IP do collector certo como destino e verificar o percurso autorizado.
3. Definir data MM/DD/YYYY. DD/MM/YYYY não é suportado para ingestão correta.
4. Enviar horas dos eventos em UTC. Alterar depois a apresentação Sophos não corrige um timestamp de origem mal interpretado.
5. Gerar alteração administrativa ou login aprovado no âmbito de auditoria. Comparar prova, hora, utilizador e ação com o esquema adequado. Netflow precisa do seu próprio teste de ligação.

Se um evento parecer ausente, comparar primeiro hora de origem e janela de pesquisa. Data ou fuso incorretos podem colocá-lo fora do intervalo. Verificar depois audit policy, categoria enviada, IP e rede.

Aceitação e remoção controlada

Documentar por origem pelo menos um evento reproduzível, origem, tenant, hora de ingestão e esquema. Comparar endereços, portas, ação e utilizador quando esperados e presentes. Ausência de detection ou case não significa necessariamente ausência de dados; é o registo real que conta.

Repetir a aceitação após alterar origem ou formato. CEF corretamente processado ontem não prova nada sobre mapping alterado hoje. Para diferenças horárias, verificar o relógio de origem em vez de desligar proteção.

Para retirar, parar a nova entrada Remote Logging ou saída Shipper dedicada e verificar o percurso anterior documentado. Manter collectors, identidades API e outras saídas partilhadas. Remover recursos exclusivamente dedicados apenas após rever dependências. Eliminar a integração não prova apagamento histórico nem recupera eventos perdidos.