Saltar para o conteudo
Avanet

Diagnosticar a Sophos NDR Integration Appliance e o sensor

Este runbook delimita problemas da NDR Integration Appliance e do sensor NDR. Começa pelo estado exato no Sophos Fusion, classifica os estados e os valores de medição visíveis e indica quando é necessário recolher logs para o Sophos Support.

Um estado Connected ou verde é apenas uma verificação intermediária. Ele não prova nem cobertura completa do espelho, nem o upload bem-sucedido de cada registo, nem uma deteção end-to-end funcionando.

Fluxo rápido

  1. Nome do Appliance, System ID, registar o início do erro com fuso horário e texto exato da mensagem.
  2. Verificar a cor e o estado do appliance no Sophos Fusion, mas ainda não reiniciar nada.
  3. No Appliance Manager Status, NDR, Integrations e Advanced, ler e crie capturas de ecrã com data e hora.
  4. Atribuir o sintoma a uma classe de erro: Plataforma/CPU, Egress/Upload, SPAN, Registo ou recursos partilhados.
  5. Realizar apenas uma correção reversível dentro desta classe de erro.
  6. Verificar novamente os mesmos pontos de medição sob carga comparável.
  7. Em caso de sinais contraditórios, contentores não prontos para operação ou falta de efeito, recolher logs e escalar.

Sintoma, exame e próximo passo

Sintoma visívelRegistar primeiroVerificarNão fazer
Vermelho: NDR containers not ready, <specific container names>.contentores mencionados, Advanced, plataforma CPU, versão, tempo de atividadeverificar os requisitos da CPU e o estado visível dos contentores; depois recolher os dados de diagnóstico para o suportenão alterar contentores manualmente, sem comandos kubectl ou Dragonfly
Vermelho: Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error>código de erro completo, NDR-Upload, alterações de proxy/firewallverificar DNS, encaminhamento, TCP 443, Web Proxy e destinos atuais do Sophos Egresssem autorização ampla de Internet e sem inventar hosts individuais suspeitos
Vermelho: spanX: unhealthy spanporta afetada, fluxo de tráfego, última alteração de espelhamentoverificar fonte, direção, destino, cabo/grupo de portas, VLAN e caminho do túnel em relação ao plano autorizadonão usar aumento de CPU como substituto para uma configuração de espelhamento incorreta
Amarelo: spanX: packets being droppedPorta, momento, CPU por núcleo, perfil de tráfego, outras integraçõesVerificar capacidade e fontes de espelhamento duplicadas; a mensagem significa mais de 10% de pacotes descartadosnão tratar o limite como um orçamento de perda aceitável
Verde, mas sem dados esperados ou deteçõesCapturar separadamente captura, fluxos, upload e caminho testadoVerificar passo a passo cobertura, tags VLAN, origem/direção e teste de end-to-endExibir verde ou pelo menos 2% de unicast não como prova de cobertura
Connected, mas nenhum dado no Data LakeVerificar NDR-/Upload de Integração e AdvancedVerificar Egress e estado visível do Dragonfly; reconciliar CPU/EVC com PendingNenhuma consulta direta do Dragonfly ou alteração de base de dados
O appliance permanece Waiting for deploymentInicialização da VM, endereço MGMT, DNS/NTP, Egress e atribuição correta do applianceVerificar caminho de gestão e bootstrap; atribuir imagem/seed apenas ao appliance criadosem segundo registo manual e sem reconstrução não verificada
Appliance Manager não acessívelEstado no Fusion, IP de MGMT, rota e regra de acesso em vigorseparar o caminho de gestão do caminho SPAN, verificar o endereço de destino e seguir o ramo de credenciais descrito abaixonão improvisar um IP de gestão na interface SPAN
CPU alta sem aviso adicionalvalores por núcleo, quedas de pacotes, upload, fluxosdiferenciar núcleos DPDK esperados de carga adicionalnão considerar automaticamente um único núcleo a 100% como falha

Ler vermelho, amarelo e verde corretamente

Vermelho: Integração não funciona

No vermelho, a mensagem concreta é mais importante do que a cor:

  • NDR containers not ready, <specific container names>. significa que pelo menos um aplicativo necessário não está pronto. Se dragonfly for mencionado ou estiver visivelmente anormal, a verificação começa pela compatibilidade da CPU e pelos requisitos da plataforma.
  • Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> significa que o aparelho tentou fazer upload para um bucket S3 por meio de uma URL pré-assinada e recebeu um código de erro. Isso é principalmente uma classe de erro de saída/proxy.
  • spanX: unhealthy span atribui a falha à entrada da porta SPAN mencionada. O componente de rede de envio ou o caminho de espelhamento virtual deve ser verificado primeiro.

Amarelo: A integração está funcionando com erros

spanX: packets being dropped aparece quando são descartados mais de 10% dos pacotes de rede. Captura e processamento de pacotes são intensivos para a CPU. Em uma VM, CPUs virtuais adicionais podem ser necessárias; em hardware certificado, a carga pode ser distribuída para outro appliance de acordo com o plano de cobertura autorizado. Collectors de log operados em conjunto podem consumir os mesmos recursos adicionalmente.

No entanto, apenas uma mudança de capacidade não corrige fontes de espelhamento sobrepostas, caminhos de destino superlotados ou configuração SPAN incorreta. Portanto, antes de escalar, compare o perfil de tráfego e a topologia.

Verde: nenhum erro de integração relatado atualmente

Verde significa que o NDR está a receber tráfego SPAN e a processar os dados dos pacotes sem problemas comunicados. O classificador de estado atual exige pelo menos 2% de pacotes unicast para considerar uma porta SPAN saudável. Isto não comprova que todas as VLANs, localizações, direções ou janelas temporais pretendidas estejam a ser capturadas. A declaração anterior de que uma porta deve mostrar 100% de unicast não é usada.

Para a interpretação detalhada dos sinais de estado de funcionamento e capacidade, veja «Monitorar estado de funcionamento e capacidade do Sophos NDR».

Se as deteções esperadas não ocorrerem apesar do estado verde, execute primeiro a deteção de teste NDR segura. Ative VLAN Strip apenas se os dados recolhidos mostrarem simultaneamente a VLAN selecionada e VLAN0. Caso contrário, mantenha a configuração inalterada. Se a evidência continuar ambígua, não altere VLAN Strip por tentativa: preserve as capturas e escale para a equipa de rede ou para o Sophos Support, conforme o componente em causa.

Delimitar eventos locais com NDR Query

Quando for necessário verificar separadamente a captura e o carregamento, o NDR Query no Appliance Manager pode mostrar a camada de eventos local. A consulta é executada na base de dados de eventos NDR desta VM da appliance, não no Sophos Data Lake. Deve ser claramente distinguida da Investigation Console, disponibilizada separadamente, que fornece dados de uma NDR Appliance atribuída para threat hunting na rede local.

  1. Registe a appliance afetada e a janela temporal da falha.
  2. Abra NDR Query e, em Query, selecione Example queries.
  3. Copie uma consulta predefinida adequada com Copy, cole-a no campo de texto e execute-a com Go.
  4. Guarde o resultado em Query Results com um carimbo de data/hora; se necessário, reordene as colunas por arrastar e largar.
  5. Compare o resultado com a atividade em NDR e com o estado no Fusion durante a mesma janela temporal.

Atualmente, o Appliance Manager suporta aqui apenas consultas predefinidas. Não utilize uma consulta SQL própria nem uma consulta da Investigation Console. Um resultado local quando não existem dados no Fusion direciona a verificação seguinte para o carregamento e o egress. Um resultado local vazio direciona-a primeiro para a entrada SPAN, a janela temporal e a consulta predefinida selecionada; por si só, ainda não comprova uma falha.

Interpretar deteções Nmap inesperadas

Se surgirem novas análises de SO baseadas em Nmap noutros produtos de segurança, verifique o estado de OS Detection em Global NDR Settings. Quando ativada, esta opção, desativada por predefinição, analisa a cada duas horas todos os endereços IP internos detetados pelo NDR. Isto pode gerar deteções noutros produtos de segurança.

Compare a hora de ativação, a appliance afetada, os endereços IP de destino e os carimbos de data/hora das deteções. Se a ativação não tiver sido autorizada, se os destinos não forem permitidos ou se existirem impactos operacionais, desative novamente OS Detection e documente a hora. Depois, confirme que não surgem novos eventos de análise causados por esta função; trate os alertas já existentes de acordo com o processo da respetiva ferramenta. Não repita manualmente comandos Nmap nem crie exceções noutros produtos de segurança apenas para ocultar o sintoma. Se a função tiver de permanecer ativa, é necessária uma autorização documentada dos responsáveis de rede e segurança, bem como uma validação durante pelo menos um intervalo completo de duas horas.

Isolar sintomas de containers e Dragonfly sem CLI

Dragonfly processa dados NDR. Dois padrões visíveis são relevantes para o diagnóstico:

  • Uma mensagem vermelha indicando contentores não operacionais pode aparecer se o dragonfly estiver preso em um ciclo de reinício, porque faltam instruções de CPU necessárias.
  • Se o appliance estiver no Fusion Connected, os dados chegam ao Data Lake, mas não chegam, e o Dragonfly está sob Advanced no Pending, é necessário verificar o modo EVC em um cluster VMware-EVC. Sophos exige Skylake generation or later; Sandy Bridge não é suportado.

Para VMs NDR no VMware ESXi ou Hyper-V, as flags de CPU pdpe1gb e avx2 devem estar disponíveis. pdpe1gb é necessária para captura de pacotes, avx2 para funções de aprendizado de máquina. Mais vCPUs não compensam a ausência de flags. No Hyper-V, Processor Compatibility Mode não é suportado. No ESXi, aplicam-se adicionalmente a versão de hardware da VM 11 ou superior e os requisitos de plataforma documentados.

Exame seguro:

  1. Documentar o estado e o nome visível do contentor afetado sob Advanced.
  2. Registar utilização da CPU, memória, disco raiz e disco de dados em Status.
  3. Comparar o hypervisor, o modelo de CPU, a configuração EVC ou de compatibilidade e as flags fornecidas à VM com a documentação da plataforma disponibilizada.
  4. Corrigir uma configuração incorreta de hypervisor/CPU apenas em uma janela de manutenção planejada; registar o valor original e o caminho de retorno antes.
  5. Em seguida, validar o estado da VM e do appliance através das interfaces de operação normais.
  6. Se dragonfly Pending permanecer, se um contentor não estiver pronto ou se um loop de reinício for visível, criar um pacote de log e escalar.

Os valores da plataforma e os requisitos de CPU suportados estão resumidos em «Sophos NDR: Escolher a plataforma e dimensionar corretamente o sensor».

Verificar upload no S3 e ligação de saída

Um erro de upload S3 não significa que nenhum tráfego SPAN está chegando. Captura e upload são duas etapas separadas. No Appliance Manager, guarde a atividade de Captura/Fluxo em NDR e Uploaded para o mesmo intervalo de tempo.

Verifique o caminho de saída nesta ordem:

  1. A configuração de IP de MGMT – DHCP ou manual – está de acordo com a rede de gestão?
  2. O DNS e o NTP funcionam através dos serviços previstos?
  3. A rota padrão é orientada pelo caminho de saída central ou pela Internet previsto?
  4. A ACL de rede, o grupo de segurança ou o firewall local permitem tráfego HTTPS de saída?
  5. O proxy web permite que o appliance e os destinos necessários se conectem sem alterar ou bloquear a solicitação S3 pré-assinada?
  6. As regras estão de acordo com as exceções de porta e domínio aktuellen da Sophos?

A lista de domínios dependentes da região sem curingas não é copiada de tickets antigos. Deve ser verificada no momento da auditoria contra os Appliance requirements atuais. Uma autorização temporária ampla para toda a Internet não é um teste seguro. As alterações são feitas individualmente e validadas após cada etapa com a mesma janela de erro.

Rollback: Uma regra de proxy, ACL ou firewall ajustada para teste será revertida ao valor original após a verificação, a menos que seja necessária de forma permanente. Ao repor, os caminhos de gestão e upload que estavam funcionando para outras integrações devem permanecer intactos.

SPAN não saudável, perda de pacotes ou fluxos ausentes

spanX: unhealthy span

Verifique para exatamente a porta mencionada:

  • fonte de espelho esperada e direção,
  • interface de destino dedicado e cabeamento físico,
  • Atribuição de NIC de captura, grupo de portas ou vSwitch,
  • no ERSPAN, endereço de destino, encaminhamento, MTU, bem como valores de GRE ou VXLAN,
  • últimas alterações em VLAN, trunk, grupo de portas, alocação de host ou sessão de espelhamento,
  • se o mesmo destino for acidentalmente espelhado novamente como origem.

Gerar tráfego unicast conhecido e inofensivo com um host piloto e observar, no mesmo intervalo de tempo, a porta SPAN prevista, bem como o fluxo de dados. Se a atividade estiver ausente, o diagnóstico permanece na origem, direção, filtro, transporte ou atribuição de captura. Apenas quando a entrada estiver ocupada, o processamento e o upload serão avaliados.

spanX: packets being dropped

Para quedas superiores a 10%, também são registados:

  • vCPUs atribuídas e CPU por núcleo,
  • Largura de banda, pacotes/s e fluxos/s,
  • fontes Mirror recém-adicionadas ou sobrepostas,
  • Tendência de memória, bem como de disco raiz e de dados,
  • todos os coletores de logs do mesmo appliance com Received, Filtered, Accepted e Uploaded.

Para um appliance partilhado, a dimensionamento começa com NDR; depois a carga do coletor é considerada. Como sinais limites adicionais, aplica-se no máximo 8.000 eventos de coletor por segundo em todo o appliance e, com 16 GB de RAM, no máximo 2 GB para coletores de log. Até mesmo núcleos de CPU utilizados pelo NDR podem ser partilhados por outras integrações, afetando assim a capacidade do NDR. O carregamento do Collector deve ser distribuído, primeiro defina a responsabilidade e o appliance de destino e use o Guia de Integração genérico; este runbook não altera as fontes Syslog específicas do fabricante.

Com 4 vCPUs, tipicamente um núcleo fica a 100% devido ao DPDK; com 8 vCPUs, dois núcleos ficam a 100%. Isso por si só é normal. Uma falha de capacidade é indicada pela combinação com perdas, outros núcleos sobrecarregados, redução do upload ou uma alteração no fluxo.

A cadeia Mirror, a validação do piloto e um caminho de retorno limitado estão descritos em «Planejar e validar o Traffic Mirroring para Sophos NDR».

Registo e diagnosticar Connected

Um novo appliance inicialmente aparece como Waiting for deployment. Após o bootstrap bem-sucedido e o caminho de gestão, o estado deste appliance muda de Threat Analysis Center > Integrations > Configured > Integration Appliances para Connected.

Se essa mudança não ocorrer:

  1. identificar o appliance correto com base no nome, plataforma e imagem gerada ou seed,
  2. Verificar se a inicialização da VM apresenta ciclos contínuos de erro ou reinício,
  3. Verificar MGMT-IP, VLAN, DHCP ou valores manuais, gateway e DNS,
  4. Verificar NTP e Egress necessários em relação aos requisitos atuais do appliance,
  5. No ESXi, utilize o OVA criado no Fusion apenas numa única tentativa de implementação. Nas restantes plataformas, siga o procedimento de implementação atual.
  6. Documentar o momento, o estado visível e a última saída do bootstrap sem segredos.

Não elimine nem reinstale o appliance. Este runbook não contém deliberadamente procedimentos de desativação ou substituição. Connected confirma a ligação e a atribuição central, não a cobertura SPAN, upload ou deteção.

Se o appliance já estava Connected e perde esse estado, primeiro são verificados o caminho de gestão, a saída e a disponibilidade do appliance. Configurações de espelhamento não são a primeira abordagem para isso, porque SPAN e gestão são caminhos separados.

Verificar o acesso ao geridor de appliances em vez de erro do sensor

Se Open Appliance Manager abrir, mas o início de sessão com zadmin falhar, trata-se primeiro de um problema de autenticação, não de SPAN, upload ou Dragonfly. Na caixa de confirmação de Open Appliance Manager, utilize a ligação reset it e defina uma nova palavra-passe. Guarde imediatamente a nova palavra-passe no sistema de gestão de palavras-passe; nem a palavra-passe antiga nem a nova devem constar de capturas de ecrã, registos de operações ou casos de suporte.

Se a conta tiver sido bloqueada devido a demasiadas tentativas com palavras-passe incorretas, o caminho alternativo documentado é a consola Web do hipervisor que aloja a appliance: na Weblink interface, selecione Unlock Account. Este procedimento alternativo pressupõe um acesso já autorizado a essa consola Web do hipervisor; este runbook não acrescenta comandos de shell, SSH ou consola, nem deduz daí outro caminho de acesso. Em seguida, teste uma vez o início de sessão com a palavra-passe armazenada em segurança. Se a conta continuar bloqueada, não tente outras palavras-passe; documente a hora e a mensagem visível e contacte o Sophos Support.

Configuração de gestão offline como último passo de recuperação local

Actions > Settings > Management no Appliance Manager só pode ser alterado localmente quando a VM não tem ligação de rede. Se existir conectividade, a alteração deve ser efetuada no Sophos Fusion. O facto de a VM estar offline não cria, por si só, um novo acesso: a correção local pressupõe um procedimento de recuperação existente e autorizado. Sem este acesso, registe o IP de MGMT atual, o último estado conhecido no Fusion e os dados da plataforma e escale o problema.

Antes de selecionar Save, compare os valores antigos e novos de IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 e, se aplicável, Enable Web Proxy, Web Proxy Type, Proxy URL e Port Number. As credenciais do proxy permanecem no sistema de gestão de palavras-passe. Altere apenas o valor comprovadamente incorreto. Se a interface pedir a confirmação de um reinício, trata-se de um reinício da appliance: o NDR e todos os Log Collectors são interrompidos. Por isso, documente primeiro as cargas de trabalho partilhadas, a janela de manutenção, o novo endereço IP esperado e o caminho de retorno.

Depois de a alteração entrar em vigor, verifique a acessibilidade no novo endereço IP, o estado no Fusion, a captura e o carregamento NDR e todos os Log Collectors. Se o acesso de recuperação autorizado continuar disponível e a validação falhar, reverta exatamente a última alteração para os valores iniciais registados. Se a interface deixar de estar acessível, não tente adivinhar endereços nem valores do proxy; escale com a linha de base, a hora e o impacto. As verificações prévias e posteriores completas encontram-se em «Operar a appliance e o sensor Sophos NDR em segurança».

Appliance partilhada: proteger outras integrações

Antes de cada reinício ou qualquer alteração de recursos no Fusion, abra a seta ao lado do nome do appliance e registre todas as integrações operando no mesmo appliance. No Appliance Manager, o Integrations mostra o estado delas, o último reinício e os contadores do Syslog.

  • Um único coletor de logs pode ser reiniciado de forma independente via Restart; NDR e outras integrações permanecem ativas.
  • Restart All diz respeito a todos os Coletores de Logs, mas não ao NDR.
  • Restart NDR diz respeito ao sensor NDR, não aos coletores de log.
  • Actions > Restart afeta toda a VM e interrompe o NDR bem como todos os coletores de log.
  • Actions > Shutdown para toda a VM e todas as integrações; é necessário um caminho de ativação separado verificado.

Um reinício amplo da VM não é o primeiro passo de diagnóstico. Primeiro, registre os estado e valores de medição e determine o menor componente afetado. Impactos e sequência de operação segura são descritos em «Operar com segurança o Sophos NDR Appliance e Sensor».

Recolher dados de diagnóstico e logs

Pacote básico

Registar antes de uma alteração:

  • Nome do aparelho, System ID, Version, K3S Helm Chart version e Uptime,
  • Estado de fusão e texto de erro exato,
  • Início, período de reprodução e fuso horário,
  • sob Status CPU por núcleo, memória, disco raiz e disco de dados,
  • em cada porta SPAN configurada no NDR Capture, Uploaded e histórico de fluxo,
  • sob Integrations todos os Log Collectors operando no mesmo appliance, juntamente com estado e contadores,
  • estado visível do contentor e último horário visível de reinício sob Advanced,
  • Plataforma, recursos de VM, perfil de tráfego e últimas alterações,
  • resultado esperado, resultado real e impacto nos negócios.

Se não for possível acessar o geridor de dispositivos

  1. Abrir no Fusion Threat Analysis Center > Integrations > Configured > Integration Appliances.
  2. No menu de três pontos do appliance afetado Collect logs, selecione.
  3. Na coluna Log requested, abra a indicação de informações e anote o nome do ficheiro exibido lá.
  4. Fornecer este nome de ficheiro com appliance, janela de tempo e texto de erro ao suporte da Sophos.

Quando o Appliance Manager estiver acessível

  1. No menu de três pontos, selecione Open Appliance Manager e depois Open.
  2. Selecionar no Appliance Manager Actions > Download Log File.
  3. Transmitir o ficheiro de log apenas através do canal de suporte acordado para o caso existente.

Ficheiros de log podem conter endereços IP, nomes de host e outros dados operacionais confidenciais. Palavra-passes zadmin, tokens, chaves privadas, credenciais de proxy e outros segredos nunca devem ser incluídos em ticket, captura de ecrã ou anexo.

Liberar controle do Assistência Remota

Ativar a Assistência Remota apenas para um caso de suporte específico. O aparelho deve estar online.

  1. Abrir no Fusion Threat Analysis Center > Integrations > Configured > Integration Appliances.
  2. No menu de três pontos, selecione Remote Assistance.
  3. Ativar no diálogo Enable.
  4. Marque a confirmação do Aviso de Privacidade do Grupo Sophos e selecione Save.
  5. Espere até que um Access ID seja exibido.
  6. Envie apenas esse ID de acesso pelo canal acordado para o suporte da Sophos.

A autorização termina automaticamente após, no máximo, sete dias. Se a análise for concluída antes, desative Enable no mesmo diálogo e documente o término. A Assistência Remota não substitui um caso de suporte nem o pacote de diagnóstico.

Validar a correção com segurança e reverter

Alterar apenas uma hipótese por rodada. Antes, registar o valor inicial, a pessoa responsável, a janela de manutenção e o caminho de retorno. Depois, verificar sob carga comparável:

  • a mensagem vermelha ou amarela anterior não ocorre novamente,
  • o estado esperado do appliance e o caminho de gestão estão estáveis,
  • cada porta SPAN prevista mostra atividade correspondente ao tráfego de piloto,
  • O fluxo e o upload permanecem estáveis ao longo de uma janela de tempo significativa,
  • nenhuma notificação para mais de 10% de quedas é retornada,
  • CPU fora dos núcleos DPDK esperados, memória e armazenamento mostram folga suficiente,
  • todos os Log Collectors operando no mesmo appliance continuam processando dados,
  • uma mudança de plataforma fornece as flags de CPU necessárias e o modo suportado.

Se a reavaliação falhar ou surgirem novos efeitos, rever exatamente a última alteração realizada. Se o estado original não puder ser restaurado, não fazer mais alterações, recolher dados de diagnóstico e abrir um caso no Suporte da Sophos.

Uma integração verde, após a correção técnica, ainda não é uma prova de deteção. Só use depois de uma cadeia estável de espelho e upload «Gerar e verificar deteção de teste segura da Sophos NDR».

Escalar para o suporte da Sophos

Abrir um caso no suporte da Sophos se:

  • permanecer NDR containers not ready ou dragonfly visível em Pending ou permanecer em um loop de reinício,
  • flags de CPU necessários não estão disponíveis, apesar da plataforma estar correta,
  • um erro de upload S3 permanece, apesar do DNS, proxy, firewall e caminho de saída confirmados,
  • spanX: unhealthy span, apesar de fonte verificada, direção e atribuição de destino permanecem,
  • Quedas de pacotes retornam após a distribuição adequada de capacidade ou carga,
  • Connected, upload local e recebimento de Data-Lake se contradizem,
  • o bootstrap não consegue concluir o registo ou o appliance alterna inesperadamente entre estados,
  • uma correção segura exigiria intervenções de baixo nível em contentores, Kubernetes ou Dragonfly.

No caso do pacote básico, enviar o nome do ficheiro de log ou do ficheiro de log, passos exatos e resultados mensuráveis. Hipóteses já descartadas devem ser claramente mencionadas. O suporte da Sophos assume problemas do produto durante a instalação, administração e operação; o caso não é uma solicitação para investigação de uma deteção.

Uma deteção autogerida baseada em XDR permanece com o cliente. Apenas um caso MDR gerido pela Sophos será investigado e respondido pelo MDR da Sophos. Para a criação e escalonamento de casos, veja «Abrir ticket de suporte da Sophos com o Assistente de Suporte».