Sophos NDR: escolher a plataforma e dimensionar corretamente o sensor

O Sophos NDR pode ser executado como appliance virtual em VMware ESXi, Microsoft Hyper-V, AWS ou Nutanix, bem como em hardware físico adequado. A escolha é feita antes da implementação: os sensores virtuais e na cloud são dimensionados com base na largura de banda, nos pacotes e nos fluxos; no hardware, a versão da Integration Appliance determina se se aplica uma aprovação anterior de modelos ou os requisitos de hardware atuais.

Decisão rápida: até 500 Mbit/s, 70'000 pacotes por segundo e 1'200 fluxos por segundo, a configuração padrão é suficiente para um sensor NDR virtual dedicado. Até 1 Gbit/s, 300'000 pacotes por segundo e 4'500 fluxos por segundo, estão previstas 8 vCPUs. Se qualquer uma das métricas ultrapassar o respetivo valor, são necessárias várias appliances virtuais na rede. Para larguras de banda superiores ou para um sensor físico, escolha hardware adequado com base na carga contínua e de pico efetivamente medida.

Licença e fundamentos do planeamento

A integração requer o Sophos Network Detection and Response integration license pack. A Sophos calcula a licença NDR com base no número total de utilizadores e servidores da organização. O software para appliances virtuais está incluído; podem ser implementados tantos sensores NDR quantos forem necessários ao abrigo da licença. Isto é importante quando um ambiente de maior dimensão tem de ser distribuído por vários sensores devido aos limites documentados das VMs.

Antes de escolher a plataforma, recolha os seguintes valores:

• largura de banda máxima e contínua do tráfego que será efetivamente espelhado,
• pacotes por segundo e fluxos por segundo durante o mesmo período,
• capacidade do switch ou da porta de espelhamento a partir da qual o sensor recebe o tráfego,
• número e localização previstos dos sensores,
• outras integrações de Log Collector que devam ser executadas na mesma appliance,
• microarquitetura da CPU, flags da CPU, memória e armazenamento disponíveis,
• plataforma de virtualização suportada ou versão da appliance e configuração exata do hardware.

Uma ligação à Internet, por si só, não constitui uma base de dimensionamento suficiente. O sensor processa o tráfego que lhe é espelhado. Por isso, os valores devem ser medidos no ponto de espelhamento previsto e documentados como carga contínua e de pico.

Escolher a plataforma

Appliance virtual ou cloud

Uma appliance virtual é adequada quando já existe uma das plataformas testadas, a carga se mantém dentro dos limites da VM ou pode ser distribuída de forma adequada por vários sensores. São suportados:

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

Para a AWS, o guia atual de implementação do Sophos NDR lista os tipos de instância c5n.2xlarge, c6i.4xlarge e c7i.16xlarge (virtualização Nitro). A especificação técnica que indica c5n.2xlarge não é, por isso, uma lista completa das opções AWS referidas nesse guia. Os mecanismos de implementação concretos, as interfaces de rede e as definições de Traffic Mirroring constam das respetivas instruções de implementação e não são determinados pela decisão de dimensionamento.

O VMware Cloud não é suportado. Para ESXi e Hyper-V, aplicam-se também os requisitos de versão e de CPU descritos abaixo. Os requisitos disponíveis, por outro lado, não incluem uma matriz de versões comum para AWS e Nutanix; os pré-requisitos de implementação devem, por isso, ser verificados na documentação da respetiva plataforma.

Hardware certificado

O hardware é uma opção quando é necessário um sensor físico dedicado. A partir da Integration Appliance v2.2.0, a Sophos deixa de publicar uma lista de hardware testado. Por isso, uma certificação atual do modelo não é um pré-requisito geral de aquisição para este ramo de versões. Tal não implica, porém, um compromisso de suporte para qualquer sistema x86.

Antes da aquisição, compare a versão da appliance e os requisitos seguintes com a matriz atual de hardware da Sophos:

• arranque UEFI e partições GPT;
• CPU a partir de 2,5 GHz com pdpe1gb e avx2, pelo menos DDR4-2400;
• armazenamento NVMe ou SAS de alto desempenho recomendado; são suportadas configurações com uma ou duas unidades, também em RAID;
• pelo menos duas interfaces de rede; para gestão/logs conta o suporte de Oracle Linux 9 e, para captura, também a NIC DPDK suportada e o respetivo chipset;
• recomendações de CPU, RAM, armazenamento e NIC adequadas à carga medida.

Por exemplo, até 1 Gbit/s e 4'000 ligações/s, a Sophos recomenda pelo menos um Intel Core i5 com 4 núcleos/8 threads, 16 GB de RAM, 1 TB NVMe/SAS e Intel i350. Não equipare estes valores aos valores históricos de NUC de 2,5 Gbit/s abaixo. Verifique separadamente as classes de carga superiores na matriz de hardware. A compatibilidade de BIOS/controladores e a captura real têm de ser validadas; nomes de modelos semelhantes não bastam.

Para versões anteriores da appliance, continuam a ser relevantes as aprovações de modelos da época. Os valores Dell, NUC e OnLogic abaixo são exemplos de planeamento datados, não uma lista atual para v2.2.0 e posteriores.

Dimensionar sensores virtuais e na cloud

Recursos mínimos

Para ESXi e Hyper-V, aplicam-se os seguintes recursos mínimos:

• 4 CPUs,
• 16 GB RAM,
• 160 GB de armazenamento.

A OVA do VMware já vem pré-configurada com estes valores mínimos para o Sophos NDR e as integrações de Log Collector. Para a AWS, selecione um dos tipos de instância acima com base no guia atual de implementação na AWS; a lista não implica que todas as instâncias tenham capacidade NDR idêntica. Para o Nutanix, a fonte de requisitos utilizada não especifica aqui recursos mínimos separados. No entanto, os recursos mínimos ainda não constituem uma garantia de capacidade. Para escolher entre a configuração padrão, 8 vCPUs e várias appliances, é necessário considerar as três métricas de tráfego.

Os valores-limite definem em conjunto uma classe de carga. Um sensor com 400 Mbit/s, mas 100'000 pacotes por segundo, já não se enquadra integralmente na classe Média. Se os valores forem superiores aos da classe Alta, a Sophos prevê várias appliances virtuais distribuídas pela rede; as fontes não permitem concluir que seja possível utilizar uma única VM maior acima deste limite.

A especificação técnica limita um sensor NDR virtual a um máximo de 1 Gbit/s. Este valor não anula os limites mais restritivos relativos a pacotes e fluxos.

Verificar a CPU e o hipervisor

Os requisitos de microarquitetura e de flags que se seguem aplicam-se ao sistema em que a VM é executada. No ESXi, Hyper-V e noutros hosts de VM autogeridos, as flags de CPU pdpe1gb e avx2 têm de estar disponíveis na VM. pdpe1gb é necessária para a captura de pacotes e avx2 para as funções de Machine Learning. Um número superior de vCPUs não compensa a ausência destas flags.

Para a AWS, verifique antes o tipo de instância suportado e os requisitos de implementação da AWS; as appliances físicas são validadas segundo o ramo de versões descrito acima, incluindo flags de CPU e configuração de hardware. Na AWS não é exigida uma verificação manual adicional na CPU do host físico.

A Sophos documenta as seguintes microarquiteturas de CPU:

• Intel: Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh e Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 e Raptor Lake/Raptor Cove Generation 13.
• AMD: Naples e Great Horned Owl com Zen 1, Rome com Zen 2, Milan com Zen 3 e Genoa com Zen 4.

Também podem ser utilizadas CPUs mais recentes, desde que ambas as flags necessárias estejam disponíveis. A Sophos indica que as CPUs lançadas desde o primeiro trimestre de 2015 deverão funcionar; para a aprovação, continua a ser necessária a confirmação concreta das duas flags na VM prevista.

Aplicam-se aos hipervisores as seguintes versões mínimas e limitações:

• VMware ESXi: versão 6.7 Update 3 ou posterior e VM Hardware Version 11 ou superior. Num cluster EVC, deve estar selecionado Skylake generation or later. O VMware Cloud não é suportado.
• Microsoft Hyper-V: versão 6.0.6001.18016 no Windows Server 2016 ou posterior. O Processor Compatibility Mode não é suportado.

Appliance partilhada com Log Collectors

Os valores de VM para as classes Média e Alta aplicam-se a uma appliance que execute apenas o Sophos NDR. Se também forem alojadas integrações de Log Collector, o planeamento começa pelo dimensionamento do NDR e acrescenta depois a respetiva carga. Estão documentados os seguintes limites e efeitos:

• Todas as integrações de Log Collector de uma VM, em conjunto, podem aceitar no máximo 8'000 eventos por segundo.
• Uma integração de Log Collector necessita de aproximadamente 400 MB RAM sob carga elevada.
• Com 4 CPUs, o NDR utiliza 2 CPUs; com 8 CPUs, utiliza 3 CPUs. Outras integrações podem, ainda assim, utilizar estas CPUs e afetar o volume de tráfego que o NDR consegue processar.
• Com 16 GB RAM, as integrações de Log Collector podem utilizar, em conjunto, no máximo 2 GB, para que o NDR conserve memória suficiente.
• Um Log Collector no limite máximo da taxa de eventos requer, numa VM com as 4 CPUs padrão, aproximadamente a mesma capacidade de processamento que o NDR sob carga média-alta.

Não existe uma dimensão única e universal para cargas mistas. Se for provável que os limites do NDR ou os recursos disponíveis sejam ultrapassados, devem ser planeadas appliances adicionais. Se várias integrações de Log Collector ultrapassarem, em conjunto, 8'000 eventos por segundo, devem ser utilizadas várias VMs. Se, pelo contrário, uma única integração ultrapassar este limite, tente primeiro reduzir o volume de eventos através das definições de Syslog do sistema de origem. Os valores aproximados documentados não justificam uma sobrealocação arbitrária.

Dimensionar hardware certificado

Exemplos históricos de modelos, não a matriz de aquisição para v2.2.0 e posteriores: Os valores seguintes de guias de dimensionamento e fichas técnicas são mantidos para enquadrar implementações existentes. Para novas implementações, aplicam-se o percurso de requisitos descrito acima e a matriz de hardware atual aí indicada.

A Sophos determina o nível de hardware com base na capacidade do switch que efetua o espelhamento e na carga contínua e de pico. O sensor NDR deve ter a mesma capacidade que o switch do qual provém o tráfego espelhado. As recomendações seguintes baseiam-se numa organização típica com 20 por cento de Power Users, 60 por cento de utilizadores típicos e 20 por cento de Light Users. Pressupõem ainda VoIP, algum streaming de vídeo, uploads e downloads de grande dimensão, bem como servidores de aplicações e Web.

Estes nomes e níveis de desempenho servem apenas para uma pré-seleção. Para uma versão anterior da appliance, o modelo exato e a configuração exata são comparados com a aprovação aplicável a essa versão; não são transpostos sem verificação para v2.2.0 e posteriores.

Para cada linha, a Sophos documenta uma possível carga de pico duas a três vezes superior à carga típica. Esta indicação de pico não substitui uma medição e não deve ser confundida com o nível de capacidade. Se houver utilização intensa adicional de streaming de vídeo e música, poderá ser necessário o nível seguinte; a decisão baseia-se na carga contínua e de pico medida e nos limites aplicáveis à versão da appliance escolhida. Se predominar a utilização de correio eletrónico, poderá ser adequado um nível inferior, desde que a carga contínua e de pico medida e o número de utilizadores se mantenham dentro dos respetivos valores.

A largura de banda e o número de utilizadores, por si só, não são suficientes para escolher o hardware. Também é necessário verificar o número máximo de ligações por segundo e a configuração de CPU, RAM e, se aplicável, sockets para a versão da appliance escolhida. Isto é particularmente importante para tráfego com muitas ligações. Por exemplo, a ficha técnica do Sophos NDR de 19 de dezembro de 2024 indica, para duas configurações R660, o mesmo débito nominal, mas limites diferentes de ligações e recursos:

As configurações da ficha técnica com data de 19.12.2024 em detalhe:

Dell R660, 2 sockets

• Débito máx.: 40 Gbit/s
• Ligações máx./s: 120'000
• CPUs: 64
• RAM: 128 GB

Dell R660, 1 socket

• Débito máx.: 40 Gbit/s
• Ligações máx./s: 80'000
• CPUs: 32
• RAM: 64 GB

Dell R650

• Débito máx.: 20 Gbit/s
• Ligações máx./s: 40'000
• CPUs: 24
• RAM: 64 GB

Dell R450

• Débito máx.: 10 Gbit/s
• Ligações máx./s: 20'000
• CPUs: 16
• RAM: 32 GB

Dell R350

• Débito máx.: 4 Gbit/s
• Ligações máx./s: 8'000
• CPUs: 8
• RAM: 32 GB

Intel NUC 13th Gen

• Débito máx.: 2,5 Gbit/s
• Ligações máx./s: 4'000
• CPUs: 12
• RAM: 32 GB

Estes valores datados apresentam todas as dimensões técnicas do dimensionamento e a importância da configuração exata, mas não constituem uma matriz atual de aquisição ou certificação. Para R360, R660xs, OnLogic e qualquer variante diferente, os valores em falta não são inferidos a partir de modelos semelhantes, mas verificados separadamente com base nos requisitos aplicáveis à versão da appliance escolhida.

As recomendações de hardware são um modelo de carga, não uma garantia para todas as distribuições de tráfego. O streaming e os fluxos de backup de grande dimensão geram muito volume; o Sophos NDR está otimizado para este tipo de streaming e tráfego de «Elephant Flow», ao passo que muitas ameaças são detetadas no tráfego normal de navegação e de aplicações. Por isso, o perfil dos utilizadores e os valores reais da rede são avaliados em conjunto.

Pré-requisitos de rede antes da implementação

A appliance necessita de ligações de saída para arrancar e receber atualizações. Se a firewall suportar wildcards, a Sophos documenta as seguintes permissões:

yum.oracle.com é opcional; sem acesso, a appliance utiliza o mirror do repositório Sophos JFrog.

Destinos concretos sem wildcards

Se a firewall não suportar wildcards, os hosts comuns e os padrões regionais de nomes abaixo constituem uma referência completa das 52 correspondências documentadas entre destino, porta e protocolo. Os padrões não são wildcards da firewall: substitua {region} por cada um dos valores indicados abaixo para criar FQDNs concretos. Nos padrões com dois marcadores, utilize o mesmo valor de região nas duas posições; todos os outros caracteres permanecem inalterados.

Hosts comuns:

• fusion.sophos.com — TCP/443, HTTPS.
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com — TCP/443, HTTPS.
• sdu-feedback.sophos.com — TCP/443, HTTPS.
• sophossecops.jfrog.io — TCP/443, HTTPS.
• yum.oracle.com — TCP/443, HTTPS; apenas este destino é opcional, com o mirror descrito acima como alternativa.
• ndr.apu.sophos.com — TCP/22, SSH.
• 2.pool.ntp.org — UDP/123, NTP.

Cinco famílias regionais, todas com TCP/443 e HTTPS:

• Proxy NTA: nta-proxy.cloudstation.{region}.prod.hydra.sophos.com
• WebSocket push NTA: nta-push-ws.cloudstation.{region}.prod.hydra.sophos.com
• S3: s3-r-w.{region}.amazonaws.com
• Imagem da appliance: tf-nta-sva-images-cloudstation-{region}-prod-bucket.s3.{region}.amazonaws.com
• NDR com URL pré-assinado: tf-presigned-url-{region}-prod-ndr-bucket.s3.{region}.amazonaws.com

Para cada uma das cinco famílias, a referência contém estes nove valores de região:

• eu-central-1
• eu-west-1
• us-east-2
• us-west-2
• ca-central-1
• ap-northeast-1
• ap-southeast-2
• ap-south-1
• sa-east-1

Por exemplo, a família de imagens da appliance com eu-west-1 gera o host tf-nta-sva-images-cloudstation-eu-west-1-prod-bucket.s3.eu-west-1.amazonaws.com. As cinco famílias geram 45 destinos HTTPS concretos; com os sete hosts comuns, a referência permanece completa.

Esta referência não significa que todas as appliances contactem todas as regiões. Também não justifica uma redução geral a uma única região da conta. Antes de alterar uma regra:

1. Comparar a referência com os Appliance requirements atuais e a implementação prevista. Confirmar os destinos necessários e a sua aplicabilidade; esclarecer qualquer incerteza sobre a seleção de regiões antes de restringir o acesso.
2. Limitar as permissões de saída à origem de gestão da appliance e aos FQDNs e serviços confirmados. Verificar a resolução DNS e os logs da firewall e do proxy. A designação «exclusions», por si só, não demonstra que seja necessário contornar a inspeção SSL/TLS; a conectividade e a desencriptação continuam a ser decisões distintas.
3. Após a alteração, verificar não apenas a ligação à gestão central, mas também o upload NDR, a captura SPAN e cada Log Collector alojado, de acordo com o runbook de operação da appliance. Em caso de falha, identificar primeiro nos logs a correspondência de destino e porta bloqueada, em vez de alargar indiscriminadamente as permissões ou as exclusões de inspeção.

Não instale um Sophos Agent nem qualquer outro agente antimalware na Integration Appliance. As atualizações do sistema operativo e de segurança também não devem ser instaladas manualmente; a Sophos gere estas atualizações.

Validar e transmitir a decisão

Antes da implementação, um registo de planeamento deve incluir, no mínimo, os seguintes pontos:

1. Plataforma: ESXi, Hyper-V, AWS, Nutanix ou hardware físico com versão da appliance e configuração exata.
2. Período de medição: data, hora e duração da medição, bem como valores contínuos e de pico para largura de banda, pacotes e fluxos no ponto de espelhamento previsto.
3. Dimensionamento: classe de carga ou nível de hardware selecionado e o respetivo valor-limite mais restritivo; para hardware, comparar adicionalmente o número máximo de ligações por segundo medido com o limite aplicável à versão da appliance escolhida.
4. Recursos por plataforma:
   • ESXi, Hyper-V e outros hosts de VM autogeridos: vCPUs, RAM, armazenamento, modelo da CPU e as flags pdpe1gb e avx2 visíveis na VM.
   • AWS: selecionar c5n.2xlarge, c6i.4xlarge ou c7i.16xlarge (virtualização Nitro) com base no guia atual de implementação na AWS e nos respetivos pré-requisitos.
   • Hardware físico: verificar a versão da appliance, o modelo exato, as flags de CPU, a RAM, o armazenamento e a NIC de captura segundo o percurso de requisitos adequado; para versões anteriores, também a aprovação de modelos da época.
5. Carga adicional: nomes e número previsto de eventos por segundo de todas as integrações de Log Collector alojadas em conjunto.
6. Rede: ligações previstas de gestão e espelhamento, bem como confirmação das permissões de portas e domínios de saída.
7. Escalabilidade: número e localização de sensores adicionais, caso um sensor virtual ultrapasse os limites da classe Alta.

A decisão é sólida quando cada valor medido se encontra dentro do nível escolhido e os pré-requisitos específicos da plataforma estão cumpridos. Nos hosts de VM autogeridos, estes incluem o hipervisor, a CPU e as flags visíveis na VM. Na AWS, conta o tipo de instância suportado em conjunto com os requisitos de implementação. No hardware, a matriz de requisitos atual ou a aplicável à versão anterior da appliance, a configuração real, a capacidade de captura, o débito e o número máximo de ligações por segundo têm de ser coerentes entre si. Numa appliance partilhada, é também necessário considerar a taxa de eventos, a RAM e o impacto dos Log Collectors na CPU.

A criação da imagem, a instalação, o registo, o Traffic Mirroring e a primeira Detection pertencem às etapas seguintes de implementação e validação. Um estado posterior Connected ou um estado verde da appliance apenas confirma o estado da integração; não comprova uma cobertura completa do espelhamento nem uma deteção de ponta a ponta funcional.

Limites do planeamento documentado

As fontes não fornecem uma fórmula que permita calcular uma configuração individual arbitrária de CPU e RAM acima dos níveis de VM indicados com base no número de utilizadores, na largura de banda ou nos eventos. Acima dos limites da classe Alta, a decisão documentada é, por isso, várias appliances virtuais, e não uma única VM especulativamente maior.

Da mesma forma, as tabelas históricas de hardware não substituem os requisitos aplicáveis à versão da appliance escolhida. Indicam valores datados de fichas técnicas, mas não uma aprovação atual para servidores com nomes semelhantes ou componentes diferentes. Se a configuração exata não tiver sido verificada face à matriz de requisitos adequada ou não existirem valores fiáveis de tráfego e ligações, a plataforma ainda não deve ser autorizada para implementação. O mesmo se aplica a um host de VM autogerido se as flags de CPU necessárias não estiverem disponíveis na VM.