Planear e validar o espelhamento de tráfego para o Sophos NDR

O espelhamento de tráfego fornece ao Sophos NDR uma cópia do tráfego de rede. Em redes locais ou virtualizadas, isto é normalmente feito através de SPAN; para fontes remotas, através de ERSPAN encapsulado sobre GRE ou VXLAN; e, na AWS, através de VPC > Traffic mirror sessions. O essencial não é espelhar o maior número possível de portas sem as verificar. O NDR precisa das relações de tráfego certas, sem ciclos, duplicados desnecessários nem um percurso de destino sobrecarregado.

O procedimento seguro é o seguinte:

definir as relações de tráfego e os limites a observar,
escolher exatamente um ponto de observação adequado por relação,
verificar a capacidade desde a fonte até ao sensor NDR,
começar por espelhar uma pequena fonte-piloto,
validar a cadeia passo a passo, desde a fonte até ao processamento,
alargar as fontes apenas de forma controlada e voltar a medir após cada alteração.

Antes da ativação, a fonte, a direção, o filtro, o destino, a janela de manutenção, o âmbito de dados permitido e a responsabilidade pela reversão têm de ser aprovados e documentados. Os dados espelhados podem conter payloads e outras informações sensíveis. Por conseguinte, segmentos não pretendidos de utilizadores, administração, identidade ou outros segmentos sensíveis não podem ser espelhados de forma abrangente, nem preventivamente nem «por segurança». A fonte-piloto é limitada ao âmbito funcional e de proteção de dados aprovado.

Selecionar fontes e pontos de observação

Antes da configuração, é útil criar uma breve matriz de cobertura. Esta não deve listar simplesmente todas as portas do switch, mas sim os percursos de comunicação relevantes, por exemplo:

clientes para a Internet e serviços externos,
clientes para servidores internos,
servidores entre si, sobretudo através de limites de segmentos ou zonas de segurança,
centro de dados para filiais ou redes cloud,
tráfego este-oeste entre máquinas virtuais que não passa por um uplink físico.

Para cada percurso, é escolhido um ponto onde ambas as direções sejam visíveis. Regra geral, trata-se de um trunk, uma VLAN ou uma porta próxima do limite de um segmento. Um uplink de Internet mostra bem o tráfego norte-sul, mas não vê o tráfego local dentro da mesma VLAN. Por sua vez, um switch físico não vê o tráfego que permanece dentro do mesmo vSwitch. Estas lacunas não podem ser inferidas a partir de um estado verde do sensor; têm de resultar da topologia e da matriz de testes.

Fonte e direção

Consoante a plataforma, uma fonte SPAN pode ser uma porta, um grupo de portas ou uma VLAN. Sempre que possível, é selecionada a opção both, para espelhar o tráfego de entrada e de saída. Uma única direção pode ocultar respostas, erros e partes de uma sessão.

Um trunk ou uma VLAN inteira simplifica a cobertura, mas aumenta o volume de dados e a probabilidade de duplicados. As portas de acesso individuais são mais específicas, mas podem ser esquecidas com maior facilidade durante migrações ou no caso de workloads dinâmicos. Por isso, a escolha é determinada pela relação de tráfego e não pelo número de fontes disponíveis.

Destino

O destino do espelhamento é exclusivamente o percurso de captura do sensor NDR:

numa VM, o grupo de portas ou o vSwitch ao qual está ligado SPAN1 ou SPAN2,
numa ligação física, a porta dedicada do switch para a interface SPAN,
no caso de ERSPAN, o endereço de destino GRE ou VXLAN configurado no sensor,
na AWS, o NDR SPAN Target criado pelo stack do CloudFormation.

A interface de gestão não deve fazer parte desta cadeia como destino SPAN. Além disso, a porta de destino não é utilizada como fonte normal e não deve reenviar tráfego de produção para a rede.

Evitar ciclos e pacotes duplicados

O Port Mirroring copia pacotes; não deve reintroduzi-los no percurso de encaminhamento de produção. Pode surgir um ciclo, por exemplo, se o destino SPAN também for espelhado ou utilizado como uplink normal. Os dados duplicados são mais frequentes: o mesmo pacote é capturado na porta de acesso e no uplink, em ambos os lados do limite de um segmento ou simultaneamente através de SPAN local e ERSPAN.

Por isso, antes da ativação, verifique o seguinte:

A interface de destino é apenas um destino e nunca uma fonte da mesma sessão ou de uma sessão sobreposta.
Um percurso de tráfego end-to-end é espelhado, sempre que possível, exatamente num limite relevante.
Duas portas SPAN não recebem fontes sobrepostas, exceto se essa sobreposição estiver documentada e for intencional para um teste de duração limitada.
Os broadcasts e multicasts não são recolhidos em vários pontos do mesmo domínio de Layer 2.
Num cluster ou com vMotion, é claro em que host e uplink chega o espelhamento físico. Uma VM NDR com SPAN padrão proveniente de um switch físico tem de permanecer no host ESXi que recebe esse tráfego.
Na AWS, existe apenas a sessão necessária para cada ENI e âmbito de tráfego pretendido. A ordem das sessões e os filtros também são verificados.

Os duplicados consomem capacidade de captura, túnel e CPU sem melhorar a cobertura funcional. Taxas de pacotes ou bytes que quase duplicam após a adição de uma fonte são suspeitas se o tráfego de produção não tiver mudado. Nesse caso, a última fonte adicionada é novamente desativada e a topologia é verificada quanto a sobreposições.

Configurar SPAN localmente ou no hipervisor

A sintaxe concreta varia consoante o switch e o hipervisor. Independentemente da plataforma, o modelo mantém-se: selecionar a fonte e a direção, definir um destino dedicado e assegurar que o grupo de portas de captura virtual permite a receção promíscua.

Numa sessão de switch Sophos, uma pequena configuração-piloto pode, por exemplo, espelhar as portas 1 a 4 em ambas as direções para a porta 8:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

Os números das interfaces são exemplos e têm de corresponder à cablagem existente. Antes de guardar, confirme que 0/8 conduz realmente apenas ao percurso de captura NDR. Para outros fabricantes, utilize os respetivos comandos SPAN documentados; nomes semelhantes não implicam automaticamente uma semântica idêntica.

Num ESXi Standard vSwitch, defina o grupo de portas de captura como VLAN ID 4095 e, em Security, defina Promiscuous mode como Accept. O tráfego espelhado fisicamente requer ainda um uplink dedicado entre o switch e o vSwitch correspondente. O tráfego interno das VMs pode exigir uma fonte de espelhamento virtual separada. No Hyper-V, a interface de captura NDR tem de estar ligada como destino do espelhamento de portas no vSwitch correto; a configuração da plataforma é verificada separadamente da configuração do sensor NDR.

O Sophos NDR ativa SPAN Port 1 por predefinição; SPAN Port 2 está desativada por predefinição. Uma segunda porta SPAN só é útil se receber uma fonte separada, sem sobreposições desnecessárias. Para SPAN Port 2, a VM necessita de pelo menos 8 vCPUs.

Utilizar ERSPAN com GRE ou VXLAN

O ERSPAN transporta as cópias de fontes remotas através de uma rede IP até ao sensor. Deste modo, o percurso de transporte passa a fazer parte da análise de capacidade e de erros: MTU, routing, ACLs e uma possível fragmentação podem afetar a captura, mesmo que a sessão de origem esteja correta.

No Sophos Appliance Manager, configure a interface de captura adequada em Settings:

VXLAN

Junto à porta SPAN prevista, ative Enable ERSPAN.
Em Tunnel Protocol, selecione vxlan.
Em IP Address, introduza o endereço da interface VTEP.
Defina VXLAN ID e VXLAN Port exatamente como na fonte de encapsulamento.
Selecione Save.

GRE

Junto à porta SPAN prevista, ative Enable ERSPAN.
Em Tunnel Protocol, selecione gre.
Em IP Address, introduza o endereço da interface de destino GRE.
Introduza GRE Port de acordo com a configuração da fonte.
Selecione Save.

As alterações às definições SPAN só entram em vigor após reiniciar a VM. Antes do reinício, verifique se a mesma appliance processa outras integrações; a recolha de dados dessas integrações também será interrompida. Em seguida, os parâmetros do túnel e o processamento têm de ser novamente validados.

A utilização de SPAN em conjunto com VXLAN na mesma appliance é um design comum. VXLAN e GRE em simultâneo na mesma appliance só devem ser utilizados se as fontes, a capacidade e os domínios de falha estiverem claramente separados e documentados.

Enquadrar o AWS Traffic Mirroring

Na AWS, o modelo de arquitetura mantém-se: a Mirror Source é a ENI do workload aprovado, e não a ENI de gestão do sensor NDR; a Mirror Target e o filtro têm de pertencer ao design NDR implementado. O filtro é limitado ao âmbito de dados pretendido. A implementação propriamente dita na AWS e a criação da Traffic Mirror Session estão descritas em «Implementar o Sophos NDR na AWS» e não são aqui repetidas.

Para a aceitação, é depois utilizada a cadeia de evidências descrita abaixo. A mera existência de uma sessão AWS não comprova o fluxo de pacotes até ao destino, nem o processamento, o upload ou a deteção.

Limitar a capacidade antes da aceitação

SPAN Port 2 não constitui uma expansão da capacidade: a VM necessita de pelo menos 8 vCPUs para a ativar, mas a segunda entrada acrescenta tráfego e, consequentemente, necessidades de processamento. É utilizada apenas para uma fonte separada e não sobreposta. Se a taxa ou as perdas de pacotes aumentarem após a sua ativação, verifique se SPAN2 introduziu carga adicional ou duplicada.

A forma de interpretar os sinais de estado, unicast e drops e de avaliar a capacidade é descrita em «Monitorizar o estado e a capacidade do Sophos NDR». Encontrará os passos para uma resolução de problemas orientada pelos sintomas em «Diagnosticar a NDR Integration Appliance e o sensor». Consoante a plataforma, as medidas de capacidade possíveis incluem CPU adicional para a VM ou a distribuição das fontes por outra appliance, sem sobreposições; outras integrações com utilização intensiva de CPU têm de ser planeadas separadamente. A simples adição de SPAN2 não aumenta a capacidade de processamento.

Validação: da fonte à deteção

A verificação é realizada com um host-piloto conhecido e uma janela temporal definida. Assim, é possível atribuir um erro a uma etapa, em vez de alterar simultaneamente o switch, o túnel, o sensor e o Sophos Fusion.

1. Configuração e topologia

Comparar a fonte, a direção e o destino com a matriz de cobertura.
Verificar o estado do fabricante da sessão SPAN ou AWS.
Assegurar que o destino não está incluído como fonte.
No caso de ERSPAN, conferir o endereço de destino, os parâmetros GRE ou VXLAN e o percurso de rede.
Nas plataformas virtuais, verificar a associação da NIC de captura, do grupo de portas ou do vSwitch.

2. Pacotes no destino

Utilizando tráfego de teste unicast controlado proveniente do host-piloto, verifique se os pacotes chegam ao destino de captura previsto. Como evidência, registe a janela temporal, a interface de destino, os endereços de origem e destino esperados e, quando aplicável, ambas as direções. Esta etapa comprova a chegada dos pacotes verificados ao destino previsto, mas ainda não o respetivo processamento ou upload. Um broadcast, por si só, não constitui um teste fiável. Se faltarem pacotes, limite inicialmente a análise à fonte, ao filtro, à direção, ao transporte e ao grupo de portas virtual.

3. Captura e fluxo na porta SPAN prevista

Em Sophos Appliance Manager > NDR, registe, para a porta SPAN prevista e apenas para essa porta, o valor de captura apresentado em percentagem e a atividade no gráfico Total Flow durante a janela de 30 segundos. Ambos têm de coincidir temporalmente com o tráfego-piloto. Isto comprova a atividade na entrada selecionada; os indicadores não comprovam a receção integral dos pacotes, o âmbito de dados correto, ambas as direções ou um upload bem-sucedido.

A classificação atual da Sophos considera saudável uma porta SPAN com pelo menos 2 por cento de pacotes de rede unicast. Este valor é exclusivamente o classificador de estado mínimo: na amostra considerada, apenas exclui uma percentagem de unicast igual a zero. Uma entrada incorreta, parcial, duplicada, desatualizada ou inadequada à finalidade também pode atingir o limite de 2 por cento. Por conseguinte, o valor não comprova a fonte e a direção esperadas, tráfego útil, cobertura, o valor de captura apresentado, upload ou deteção. As referências mais antigas a 100 por cento de unicast não são utilizadas como requisito atual.

4. Processamento e upload

Em Sophos Appliance Manager > NDR, registe o valor de upload apresentado em percentagem para a mesma janela temporal e compare-o temporalmente com a atividade de captura e de fluxo. Isto documenta a atividade de upload, mas não prova que todos os pacotes espelhados tenham sido enviados nem que seja posteriormente criada uma Detection. Connected comprova sobretudo a ligação da appliance e não substitui esta evidência. Se os sinais de estado, captura, upload e drops divergirem, siga o diagnóstico sistemático da appliance e do sensor.

5. Cobertura funcional

Para cada linha da matriz de cobertura, gere tráfego de teste específico e autorizado e registe a hora, o dispositivo de teste, o segmento esperado, a fonte, o destino e a direção. A evidência das etapas 2 a 4 é associada a este teste. Só estas amostras demonstram que os percursos verificados são, em princípio, capturados; não constituem prova para segmentos ou janelas temporais não testados.

6. Deteção end-to-end inofensiva

Só depois de uma aceitação bem-sucedida do espelhamento deve executar o procedimento separado e aprovado «Gerar e verificar uma Sophos NDR Test-Detection segura». A geração do teste não é antecipada aqui. O resultado é verificado para o dispositivo de teste e a janela temporal esperados em Threat Analysis Center > Detections e associado à cadeia de evidências anterior. Uma Test-Detection aí observada comprova o percurso end-to-end testado; não garante a deteção de todas as técnicas de ataque nem a cobertura de outros percursos.

Isolar desvios passo a passo

Se uma aceitação falhar, investigue apenas a primeira etapa sem a evidência esperada: o percurso real da fonte, a direção e o filtro; depois, a cablagem do destino ou a associação da captura virtual; no caso de ERSPAN, o transporte e os valores de túnel correspondentes; em seguida, a captura e o fluxo na porta prevista; e, por fim, o upload e a Detection. Um estado verde ou pelo menos 2 por cento de unicast não permite ignorar nenhuma destas etapas. Faça apenas uma alteração de cada vez e volte a medir com o mesmo piloto e a mesma janela temporal.

Se faltar apenas uma direção ou um segmento, compare a matriz de cobertura com o percurso físico ou virtual real, sem incluir preventivamente outros segmentos sensíveis nem todas as portas. Se a taxa for invulgarmente elevada, verifique individualmente as sobreposições documentadas em relação aos contadores e à visibilidade do tráfego-piloto. Este procedimento termina com a aceitação do espelhamento e a localização do erro; em caso de erros do sensor, de upload ou da plataforma, prossiga com o diagnóstico da appliance e do sensor.

Reverter em segurança as alterações deste procedimento

Antes de cada expansão, registe o ID da sessão, as fontes, as direções, os filtros, o destino, os parâmetros do túnel e as taxas de referência. O processo de reversão descrito a seguir abrange apenas as novas alterações de espelhamento efetuadas neste procedimento; não constitui um guia para remover uma appliance, um stack cloud ou outra infraestrutura.

Em caso de problemas, reverta pela ordem inversa:

remover a última fonte local adicionada; eliminar uma AWS Traffic Mirror Session criada de novo para este procedimento,
repor um filtro recentemente alargado no âmbito-piloto documentado,
desativar o ERSPAN recentemente ativado ou repor os valores anteriores do túnel,
desativar SPAN Port 2 se tiver introduzido a nova carga ou sobreposição,
repor a sessão anterior do switch no caso de alteração de um espelhamento físico,
voltar a verificar o fluxo de pacotes, a taxa de drops, o estado da integração e o tráfego-piloto.

A reversão das definições SPAN da Sophos requer novamente Save e um reinício da VM para que a alteração entre em vigor. Também neste caso, são considerados os efeitos noutras integrações da mesma appliance. A reversão só estará concluída quando não só o estado tiver voltado a ficar verde, mas também os percursos-piloto anteriormente documentados estiverem visíveis sem novos duplicados e sem perdas de pacotes problemáticas.