Implementar o Sophos NDR no VMware ESXi ou Hyper-V

O Sophos NDR é executado no ESXi ou Hyper-V como uma Integration Appliance virtual. A VM necessita de dois caminhos claramente separados: MGMT obtém um endereço IP normal e acede ao Sophos Fusion (anteriormente Sophos Central) ou ao Sophos Data Lake; SPAN1 e, opcionalmente, SPAN2 recebem apenas cópias espelhadas do tráfego a inspecionar. Por conseguinte, uma VM em bom estado ou o estado Connected no Central ainda não confirma que o NDR consegue ver pacotes.

Fluxo rápido: verifique os pré-requisitos e a capacidade, crie a configuração do NDR no Sophos Fusion, prepare o espelhamento adequado à plataforma, implemente a imagem gerada exatamente uma vez, aguarde que o arranque inicial e o reinício automático terminem e, em seguida, valide separadamente os caminhos de gestão e SPAN.

Limite importante: o caminho SPAN não está em linha e não pode ser utilizado como rede de gestão. O espelhamento é configurado no switch e no hipervisor; a appliance NDR não altera o tráfego de produção original. Para o Hyper-V, não são deliberadamente fornecidos aqui comandos externos do PowerShell para espelhamento. Implemente o design no Hyper-V de acordo com as orientações aprovadas da Microsoft e da Sophos e verifique-o com tráfego de teste real.

Verificar obrigatoriamente os pré-requisitos

Os seguintes requisitos mínimos aplicam-se inicialmente a ambas as plataformas:

• uma licença ativa Sophos Network Detection and Response integration license pack no tenant utilizado;
• 4 vCPUs, 16 GB de RAM e 160 GB de armazenamento;
• os flags de CPU pdpe1gb para Packet Capture e avx2 para as funcionalidades de machine learning;
• uma rede de gestão dedicada com DHCP ou um endereço estático, DNS, gateway predefinido e acesso de saída à Internet;
• caminhos SPAN preparados para cópias bidirecionais de todas as classes de tráfego aprovadas: tráfego virtual interno e tráfego físico externo, se ambos fizerem parte do âmbito de monitorização acordado;
• responsabilidades documentadas para o Central, o hipervisor, os switches físicos e a lista de permissões da firewall.

Se o âmbito aprovado contiver efetivamente apenas uma destas classes de tráfego, documente explicitamente esse limite. Um único caminho SPAN não pode então ser considerado como cobertura da outra classe.

Não instale na appliance qualquer Sophos Agent adicional nem outro agente antimalware. A Sophos gere as atualizações do sistema operativo, de segurança e da appliance. Os requisitos próprios de aplicação de patches ou reforço da segurança não podem alterar este estado gerido sem validação prévia.

Limites das plataformas

O VMware ESXi requer:

• ESXi 6.7 Update 3 ou posterior;
• VM hardware version 11 ou posterior;
• um modo EVC Skylake ou posterior quando for utilizada a Enhanced vMotion Compatibility;
• uma implementação fora do VMware Cloud, uma vez que este não é suportado.

Os flags de CPU têm de continuar visíveis na VM através do modo EVC selecionado. Um processador físico recente, por si só, não é suficiente se o EVC ocultar as capacidades necessárias.

O Microsoft Hyper-V requer:

• Hyper-V 6.0.6001.18016, correspondente ao Windows Server 2016, ou posterior;
• Processor Compatibility Mode desativado;
• no máximo 8 cores de CPU e 32 GB de RAM por VM NDR;
• no máximo um nó NUMA e um socket de CPU.

Os limites do Hyper-V não constituem uma recomendação para atribuir sempre o máximo de recursos à VM. Evitam uma topologia NUMA não suportada.

Dimensionar a VM de acordo com o tráfego

O tamanho padrão com 4 vCPUs destina-se a uma appliance dedicada ao NDR até aos seguintes valores de referência:

• 500 Mbit/s;
• 70'000 pacotes por segundo;
• 1'200 fluxos por segundo.

Para uma carga elevada até 1 Gbit/s, 300'000 pacotes por segundo ou 4'500 fluxos por segundo, utilize 8 vCPUs. O SPAN2 também requer, pelo menos, 8 vCPUs. Se a carga exceder estes valores, distribua-a por várias appliances NDR em pontos de rede adequados; não aumente uma única VM além dos limites documentados.

Se forem também executadas integrações de coletores de registos na mesma appliance, planeie a respetiva carga separadamente. O NDR reserva, com prioridade elevada, duas CPUs quando são utilizadas 4 vCPUs e três quando são utilizadas 8 vCPUs. Outras integrações podem, ainda assim, sobrecarregar estas CPUs. Com 16 GB de RAM, as integrações de coletores de registos podem utilizar, no total, no máximo 2 GB. Independentemente do número de integrações, uma appliance aceita no máximo 8'000 eventos de registo por segundo. Só é possível uma integração NDR por appliance.

Permitir ligações de saída

Se a firewall suportar carateres universais, a appliance necessita dos seguintes destinos:

yum.oracle.com é opcional porque, se não conseguir aceder a esse destino, a appliance utiliza o espelho da Sophos no JFrog. Não expanda indiscriminadamente os carateres universais a outras zonas. Se a firewall não permitir carateres universais, adicione à lista de permissões, antes da alteração, a lista completa e atual de nomes de anfitrião da Sophos específica da região e verifique-a a partir da zona MGMT através de testes de DNS e conectividade. Uma lista abreviada ou copiada de outra região não é uma alternativa segura.

Criar a integração e a imagem no Sophos Fusion

1. No Sophos Fusion, abra Threat Analysis Center > Integrations > Marketplace.
2. Selecione Sophos Network Detection and Response (NDR).
3. Em Data Ingest (Security Alerts), clique em Add Configuration.
4. Em Step 1, introduza um nome exclusivo e uma descrição para a integração.
5. Em Step 2, selecione uma appliance existente ou clique em Create new appliance. Uma appliance existente não pode já ter outra integração NDR.
6. Para uma nova appliance, escolha um Appliance name exclusivo, uma descrição e a plataforma correta, VMware ESXi ou Microsoft Hyper-V.
7. Em Internet-facing network port settings, configure DHCP ou Manual. Um endereço atribuído por DHCP tem de ser reservado.
8. Em Step 3, introduza um Exclusion list name. Este nome é obrigatório mesmo que a lista esteja inicialmente vazia.
9. Termine clicando em Save.

Para Manual, preencha os campos IP address, Subnet mask, Gateway address, DNS 1 e, opcionalmente, DNS 2. Um exemplo interno é:

• IP address: 10.0.252.5
• Subnet mask: 255.255.255.0
• Gateway address: 10.0.252.1
• DNS 1: 10.0.252.53
• DNS 2: 10.0.252.54

Substitua estes valores por endereços disponíveis e servidores DNS acessíveis a partir da sua rede de gestão. Verifique antecipadamente o endereço estático em relação ao conjunto DHCP, ao IPAM e aos anfitriões existentes.

Em Domain exclusions, pode introduzir um nome de domínio. Protocol exclusions tem um campo para o protocolo principal, como TCP ou UDP, e outro para o subprotocolo, como facebook; quando ambos são especificados, o Central une-os com um único ponto. Não exclua um protocolo principal completo apenas para reduzir o volume de dados. Cada exclusão requer um falso positivo confirmado ou uma decisão de capacidade justificada, um responsável e uma data de revisão.

Depois de guardar, selecione a transferência específica da plataforma na coluna Actions: Download OVA file para ESXi ou o pacote ZIP para Hyper-V. O estado à esquerda da integração muda para Waiting for deployment. A imagem contém a configuração específica da appliance e não pode ser reutilizada entre tenants ou appliances.

Implementar no VMware ESXi

1. Preparar os grupos de portas SPAN

Para o tráfego virtual interno, crie um grupo de portas dedicado no vSwitch padrão em causa:

1. Abra Networking > Virtual switches e selecione o vSwitch previsto.
2. Em Port groups, clique em Add port group.
3. Atribua um nome exclusivo.
4. Defina VLAN ID como 4095.
5. Em Security, defina Promiscuous mode como Accept.
6. Guarde o grupo de portas.

Para tráfego espelhado proveniente de um switch físico, utilize um vSwitch separado com o seu próprio grupo de portas SPAN, seguindo o mesmo padrão. Em vSwitch topology, utilize Add uplink para atribuir uma NIC física disponível. Ligue a porta de destino de espelhamento dedicada do switch físico diretamente a esta NIC do anfitrião ESXi.

No switch físico, selecione apenas as portas ou VLANs aprovadas como origens de espelhamento e selecione ambas as direções. A porta de destino transporta as cópias para a NIC do ESXi e não pode ser utilizada simultaneamente como uma porta normal de acesso, trunk ou gestão. A sintaxe exata do switch é específica do fabricante e não pode ser copiada de um exemplo de outro modelo.

Se forem utilizados em conjunto o SPAN físico e o vMotion, a VM NDR tem de permanecer no anfitrião ESXi cuja NIC física recebe o tráfego espelhado. Uma migração não intencional para outro anfitrião pode remover silenciosamente o caminho SPAN, embora o MGMT continue a funcionar.

2. Importar o OVA e mapear as interfaces

O OVA transferido está associado a esta configuração do Central e só pode ser utilizado uma vez. Para uma substituição ou nova implementação, gere um novo OVA no Central.

1. No anfitrião ESXi, abra Virtual Machines > Create/Register VM.
2. Selecione Deploy a virtual machine from an OVF or OVA file.
3. Introduza um nome para a VM e selecione ndr-sensor.ova.
4. Selecione Standard como tipo de armazenamento e, em seguida, escolha o datastore previsto.
5. Em Deployment options, mapeie cuidadosamente as redes:
   • SPAN1: primeiro grupo de portas SPAN preparado;
   • SPAN2: segundo grupo de portas SPAN, se for realmente necessário;
   • SYSLOG: para uma appliance dedicada ao NDR, selecione um grupo de portas temporário e desligue o adaptador após a importação;
   • MGMT: o grupo de portas de gestão com DHCP ou os parâmetros de rede estáticos introduzidos no Central.
6. Defina Disk Provisioning como Thin.
7. Ative Power on automatically.
8. Ignore Additional settings sem efetuar alterações e clique em Finish para importar.

Antes de ligar a VM pela primeira vez, volte a documentar o mapeamento, o estado da ligação e os endereços MAC de todas as vNICs. O MGMT não pode estar num grupo de portas SPAN. Se for utilizado o SPAN2, a VM tem de ter, pelo menos, 8 vCPUs.

Implementar no Microsoft Hyper-V

1. Preparar o design de espelhamento

Antes de executar o script, determine a finalidade de cada vSwitch:

• um vSwitch normal para MGMT, com DHCP ou o caminho de rede estático planeado;
• um caminho de destino para SPAN1;
• opcionalmente, um segundo caminho de destino para SPAN2, nesse caso com, pelo menos, 8 vCPUs;
• nenhum caminho SYSLOG ativo, a menos que a mesma appliance também processe integrações de terceiros aprovadas.

Para o Hyper-V, a configuração do espelhamento é composta, conceptualmente, por quatro partes: uma porta de espelhamento de tráfego, uma SPAN Virtual Interface ligada ao vSwitch, a Microsoft NDIS Capture Extension ativada e os modos de espelhamento Source e Destination corretamente definidos. A implementação depende da versão do Windows/Hyper-V, do tipo de vSwitch e da origem do tráfego a espelhar. Por este motivo, não copie comandos do PowerShell não verificados de outros ambientes.

Antes de iniciar o NDR, a equipa da plataforma verifica o caminho previsto, como teste rápido de implementação, através de um fluxo de teste bidirecional conhecido. A cópia tem de chegar ao caminho de destino previsto sem alterar o fluxo de produção original. Só então este vSwitch é selecionado como destino SPAN no script da Sophos. Este teste isolado não confirma a cobertura completa do espelhamento.

2. Extrair o ZIP e executar o script da Sophos

1. Extraia o ZIP transferido do Central para uma pasta local protegida no anfitrião Hyper-V. Contém discos virtuais, seed.iso e ndr-sensor.ps1.
2. Na pasta, inicie ndr-sensor.ps1 com Run with PowerShell.
3. Quando surgir Security Warning, verifique o ficheiro local transferido diretamente do Central e autorize-o com Open.
4. Introduza um nome exclusivo para a VM.
5. Verifique o novo diretório da VM apresentado no caminho predefinido dos discos virtuais e introduza C para o criar.
6. Especifique 4 CPUs para o tamanho padrão ou 8 CPUs para carga elevada ou SPAN2.
7. Especifique 16 GB de RAM como valor padrão; não exceda o limite de 32 GB do Hyper-V.
8. Na lista numerada de vSwitches, selecione primeiro o vSwitch MGMT.
9. Para SYSLOG numa appliance dedicada ao NDR, selecione um vSwitch temporário e desligue este adaptador após a criação.
10. Selecione o vSwitch preparado para SPAN1 e, se planeado, o de SPAN2.
11. Aguarde por Installation Completed Successfully e, em seguida, prima qualquer tecla para sair do script.
12. Abra a nova VM no Hyper-V Manager e, antes de a iniciar, verifique a CPU, a RAM, os adaptadores de rede, os vSwitches ligados e o adaptador SYSLOG desligado.

Os discos virtuais e o seed.iso gerados pela Sophos formam um conjunto. Não substitua ficheiros individuais por ficheiros com o mesmo nome de uma transferência anterior.

Arranque inicial e teste rápido de implementação

Durante o arranque inicial, a appliance verifica as redes atribuídas e o acesso à Internet e, em seguida, reinicia automaticamente. Este processo pode demorar até dez minutos.

Não interrompa o arranque inicial nem o reinício automático. Desligar manualmente a VM durante este período pode deixá-la num estado incompleto e não constitui um passo de resolução de problemas.

Efetue o teste rápido técnico de implementação pela seguinte ordem:

1. Consola da VM: o processo de arranque termina sem um ciclo persistente de erros ou reinícios.
2. Caminho de gestão: o endereço MGMT configurado ou reservado, o DNS, o NTP e os destinos de saída necessários estão acessíveis.
3. Caminho de controlo do Central: em Threat Analysis Center > Integrations > Configured > Integration Appliances ou na página da integração NDR, a appliance muda de Waiting for deployment para Connected.
4. Caminho SPAN: para cada caminho SPAN implementado, gere um fluxo de teste anunciado e inofensivo, em ambas as direções, entre dois sistemas de teste conhecidos. No switch ou hipervisor, Source, Direction e Destination têm de corresponder à alteração; na appliance, o adaptador SPAN mapeado tem de receber tráfego.
5. Plausibilidade: compare o intervalo de tempo, os endereços de origem e destino e a direção do fluxo de teste observado. O respetivo caminho implementado só fica confirmado para este teste rápido quando estes valores coincidirem.
6. Carga: durante um primeiro período de carga adequado, compare o débito, os pacotes e os fluxos com o nível de dimensionamento selecionado. Um estado Connected não comprova a capacidade.

Não é necessária uma única deteção artificial para o teste rápido de implementação. O importante é um caminho de gestão estável e tráfego bidirecional comprovado na interface SPAN correta. O fluxo de teste não contém malware nem dados reais de clientes numa Packet Capture.

Este teste rápido comprova apenas os caminhos especificamente testados. A aceitação completa de todas as origens, VLANs, direções e classes de tráfego previstas pertence ao runbook separado Planear e validar o espelhamento de tráfego para o Sophos NDR; nem Connected nem um único fluxo bem-sucedido são aqui considerados prova de uma cobertura abrangente do espelhamento.

Resolver problemas por sintoma

O estado permanece em Waiting for deployment

1. Verifique se foi implementada a imagem correta, recentemente transferida a partir desta configuração.
2. Verifique a consola e o estado de alimentação da VM e aguarde pelo menos dez minutos ininterruptos pelo arranque inicial.
3. Compare a vNIC de MGMT, o grupo de portas ou o vSwitch e a reserva DHCP ou os campos estáticos.
4. Verifique o DNS, o gateway, o NTP, o TCP 443, o TCP 22 e o UDP 123 a partir da rede de gestão, de acordo com a lista de permissões.
5. Só volte a implementar após estas verificações. No ESXi, é necessário um OVA recém-gerado; não volte a importar o OVA já utilizado.

Connected, mas sem tráfego NDR

No ESXi, verifique primeiro o mapeamento de SPAN1/SPAN2, VLAN ID 4095, Promiscuous mode: Accept, o uplink físico e a porta de destino de espelhamento. Ao utilizar o vMotion, verifique se a VM continua a ser executada no anfitrião com a NIC SPAN ligada.

No Hyper-V, a equipa da plataforma verifica a SPAN Virtual Interface, a NDIS Capture Extension, o modo Source/Destination e o vSwitch selecionado no script da Sophos. Não adicione regras de firewall nem comandos de espelhamento inventados com base em suposições.

Em ambas as plataformas, não restrinja imediatamente o filtro de teste: verifique primeiro os contadores do adaptador e um fluxo bidirecional claramente identificável. O tráfego MGMT no adaptador MGMT não comprova que o SPAN funciona.

Só é visível uma direção ou uma rede

• A origem de espelhamento tem de incluir o envio e a receção.
• Com encaminhamento assimétrico, o caminho de retorno pode utilizar outro uplink.
• O tráfego virtual interno e o tráfego físico externo podem necessitar de caminhos SPAN separados.
• Se o SPAN2 estiver configurado, o segundo vSwitch ou grupo de portas tem de estar corretamente mapeado e têm de estar disponíveis, pelo menos, 8 vCPUs.

Repita exatamente o mesmo fluxo de teste após cada correção. Desta forma, fica claro qual foi a alteração que produziu efeito.

Dragonfly permanece em Pending

Se o Central já estiver Connected, mas o NDR não funcionar, verifique o estado do serviço Dragonfly na Sophos VA Console. Antes deste passo, o acesso à consola local tem de ter sido disponibilizado de acordo com o runbook separado Operar a Sophos NDR Integration Appliance e o sensor. Não reutilize para este fim credenciais do hipervisor ou do Central sem validação; este runbook de implementação não cria nem divulga credenciais locais da appliance.

Em caso de Pending num cluster EVC do ESXi, verifique primeiro o modo EVC e as capacidades de CPU visíveis. O Sandy Bridge não é suportado para esta utilização; é necessário o Skylake ou posterior, bem como pdpe1gb e avx2.

No Hyper-V, verifique também o Processor Compatibility Mode, os limites de CPU e RAM e a topologia, com no máximo um nó NUMA e um socket de CPU. Não tente «reparar» a VM adicionando CPUs ou RAM além dos limites suportados.

Faltam pacotes ou resultados sob carga

Compare o débito, os pacotes e os fluxos atuais com os limites de dimensionamento. Se um destino SPAN for mais lento do que a soma das respetivas origens, a cópia pode perder pacotes enquanto o tráfego de produção continua sem interrupções. Nesse caso, restrinja a seleção de origens, divida os caminhos SPAN ou utilize várias appliances. As exclusões abrangentes de protocolos não substituem um dimensionamento correto.

Reversão local limitada desta implementação

Os passos seguintes constituem uma recomendação conservadora de reversão local da alteração para a implementação passiva aqui descrita. Não constituem um procedimento completo de desativação ou remoção documentado pela Sophos. A reversão é deliberadamente limitada aos objetos de sensor e de espelhamento recém-criados no âmbito da alteração:

1. Guarde os comprovativos dos testes e os últimos estados conhecidos: estado do Central, recursos da VM, mapeamento de interfaces, origens e direções de espelhamento.
2. Primeiro, desative a sessão SPAN ou de espelhamento no switch ou hipervisor. Não elimine nem volte a cablar as portas de origem, VLANs ou vSwitches de produção durante este processo.
3. Verifique se o tráfego original continua a funcionar e se já não chegam cópias ao caminho de destino do NDR.
4. Em seguida, encerre corretamente a VM NDR.
5. Remova grupos de portas, vSwitches, uplinks ou ficheiros da VM dedicados apenas depois de confirmar que são utilizados exclusivamente por esta appliance. Os objetos partilhados de gestão ou produção mantêm-se.
6. Reverta a reserva DHCP estática, a lista de permissões da firewall e os registos DNS como alterações separadas, depois de verificar as respetivas referências.

A integração ou a appliance do Central não é eliminada no âmbito desta reversão local. Essa eliminação está fora do âmbito desta reversão da implementação e requer um processo de remoção separado, validado e aprovado. Do mesmo modo, um OVA existente não é tratado como uma imagem de reversão: gere uma nova imagem no Central para outra implementação no ESXi.

Após uma falha no arranque inicial, a reversão limitada localmente consiste, portanto, em parar o espelhamento, desligar a VM, reverter apenas os objetos de rede claramente associados a esta alteração e identificar a causa antes de uma nova implementação. Não converta de forma improvisada um teste NDR passivo noutro design de rede nem num caminho em linha.