Da Visibilidade da Rede à Cibersegurança: O Principal Mito sobre Telemetria de Rede que Impede a Descoberta do Potencial do NetFlow
Este artigo explora o uso do NetFlow e da telemetria de rede para detecção de ameaças, desmistificando a ideia de que a telemetria é apenas para engenheiros de rede. Ele destaca como a análise de metadados de tráfego, em vez da análise completa do payload, pode ser eficaz na identificação de ataques.
MundiX News·21 de maio de 2026·11 min de leitura·👁 2 views
Olá, pessoal do Habr!
Sou Stanislav Gribanov, chefe da área de produtos da empresa Garda e autor do blog "Cibersegurança e Expertise em Produtos para Negócios".
Hoje, quero discutir os benefícios do NetFlow e da telemetria de rede para proteger redes contra ataques de hackers. Este tópico não é novo, mas ainda existem muitas controvérsias em torno dele.
A telemetria de rede é frequentemente percebida como um artefato do mundo dos engenheiros de rede, e não como uma ferramenta séria de segurança da informação. Isso geralmente está relacionado à percepção errônea dos sistemas NGIPS como análogos de NTA. Nesse caso, a principal funcionalidade é a detecção de ataques por assinatura, que requer apenas tráfego bruto para funcionar. Ao mesmo tempo, os métodos de análise comportamental, aprendizado de máquina e outras técnicas não baseadas em assinatura em tais sistemas são complementares e não formam o núcleo da lógica de detecção.
Por exemplo, a solução Cisco SourceFire NGIPS (folha de dados de 2013) também usa apenas tráfego bruto, e sua funcionalidade se sobrepõe muito à de um analisador de tráfego de rede doméstico típico, que se posiciona como NTA ou NDR. O produto Cisco se baseia em métodos de assinatura, análise de payload, bancos de reputação e usa complementarmente o aprendizado de máquina para detectar malware do tipo worm.
Devido a essa percepção errônea, um equívoco em massa se formou no mercado russo: para procurar ameaças na rede, você só precisa analisar o tráfego bruto, e a telemetria não é adequada para isso.
Abaixo, vou contar como você pode detectar ameaças com base em metadados de tráfego de rede sem analisar o payload, em particular, a telemetria de rede.
O que é telemetria de rede e por que ela é necessária
Pode parecer estranho, mas há confusão aqui com frequência. Alguns erroneamente atribuem dados coletados por agentes de proteção de endpoint à telemetria de rede. Na verdade, não é assim.
A telemetria de rede é estatísticas de fluxos de rede coletadas de equipamentos de rede de camada L2 e superior: switches, roteadores, firewalls e outros dispositivos. O protocolo mais comum para coletar essa telemetria é o NetFlow.
Um pouco de história
NetFlow é um padrão de telemetria de rede desenvolvido pela Cisco em 1996. Na verdade, tornou-se sinônimo do termo "telemetria de rede" e a ferramenta mais massiva para analisar o que está acontecendo na rede. Existem várias versões do protocolo; a décima versão é conhecida como IPFIX (Internet Protocol Flow Information Export).
As soluções da classe NPM (Network Performance Monitoring) são construídas com base no NetFlow. Por exemplo, a solução do conhecido fornecedor SolarWinds (que já deixou a Rússia). Alguns fabricantes usam seus próprios protocolos de telemetria: NetStream (Huawei), JFlow (Juniper), AppFlow (Citrix).
Por que a telemetria de rede é necessária
NetFlow permite detectar ameaças em redes nas quais é difícil ou impossível obter uma cópia do tráfego de rede. Aqui estão alguns exemplos desses casos.
O primeiro exemplo é um data center. Ele processa enormes fluxos de dados em centenas de Gbit/s, a complexidade e o alto custo da análise de tal volume de tráfego bruto tornam o Netflow a única fonte de dados sobre a rede no data center.
Outra opção são redes descentralizadas geodistribuídas com um grande número de pontos de saída separados para a Internet: lojas, pequenos escritórios, instituições educacionais ou médicas, etc. Tirar uma cópia do tráfego (SPAN) em tais redes pode ser difícil devido a equipamentos desatualizados, restrições de canais de comunicação ou topologia de rede.
Fontes de telemetria
Para coletar telemetria de rede, existe uma ampla gama de equipamentos de diferentes fabricantes: da classe Enterprise, como Cisco, Huawei, Eltex, Juniper, Extreme, Fortinet, a soluções de nível SoHo, incluindo Mikrotik, D-Link, TP-Link, Zyxel, Asus e outros.
Amostragem: quando a telemetria se torna inútil para a segurança da informação
Uma nuance importante: as tarefas de segurança da informação limitam significativamente o uso de telemetria amostrada (abreviada), por exemplo, sFlow. Ao amostrar, perdemos metadados para cada sessão - a frequência das comunicações, os volumes individuais das sessões, parâmetros quantitativos precisos.
Tudo isso "quebra" os sinais necessários para construir previsões de comportamento normal do host e detectar anomalias.
Para fins de segurança da informação, é necessária telemetria completa sem amostragem.
O que o IPFIX oferece? Parâmetros-chave
Os dados obtidos da telemetria de rede já foram analisados mais de uma vez, mas vou repetir alguns parâmetros IPFIX interessantes:
Endereços IP e MAC do remetente e do destinatário;
Portas do remetente e do destinatário;
Protocolo de transporte;
Flags TCP, incluindo o motivo da terminação do fluxo;
Duração do fluxo (início e fim);
Número de pacotes e volume de dados do fluxo;
Sistemas autônomos (AS);
Tipo de serviço (TOS);
Aplicativo (análogo a DPI) - se suportado no lado do exportador;
Metadados HTTP: user-agent, tipo de conteúdo e outros parâmetros.
É interessante que o equipamento de rede Cisco suporte seu próprio DPI - NBAR, que contém uma extensa base de protocolos e aplicativos das camadas L3–L7. Caso contrário, os dados DPI podem ser transferidos pelo exportador para IPFIX, por exemplo, NGFW.
Cenários de segurança da informação para os quais a análise baseada em telemetria de rede pode ser aplicada
Análise de reputação (Threat Intelligence Feeds)
A opção mais simples é verificar os endereços IP em bancos de reputação (TI feeds). Por exemplo, em nosso produto "Garda NDR", usamos dados de Inteligência de Ameaças. Estes são feeds que incluem:
C&C (centros de comando e controle);
Atividade de botnet;
DDoS;
Criptomineração;
TOR, proxy;
Phishing, malware;
Força bruta, spam, hosts suspeitos.
Na versão estendida dos feeds de TI, campos de enriquecimento adicionais estão disponíveis: sistemas autônomos, data da última atividade.
Mas IP é apenas o começo. E os nomes de host, que não estão na telemetria padrão? Usamos um módulo de análise de solicitações DNS para servidores DNS corporativos e nosso próprio sistema para enriquecer os metadados da sessão na fase de coleta de pacotes. Isso permite que você verifique os hosts para conformidade com as listas de feeds de TI. Os tipos de listas de reputação podem ser muito diferentes - o principal é que eles contenham os parâmetros suportados, como IP, nomes de host, etc.
Infraestrutura corporativa e Shadow IT
Dados básicos de IP/MAC são suficientes para formar perfis de sub-redes por IP ou portas, detectar novos protocolos, endereços IP ou violações das regras de segmentação de rede em firewalls.
E se não houver DPI e apenas a porta for conhecida? Nesse caso, usamos nossa própria base de correspondência de portas e protocolos, que ajuda a identificar portas não padrão para protocolos conhecidos. É claro que essa abordagem é eficaz apenas para portas estáticas. Para dinâmicas, a extração do applicationId será necessária.
Com a ajuda da telemetria de rede, você também pode detectar DNS não corporativos, DHCP ou até mesmo controladores de domínio falsos. A lógica é simples: procuramos tráfego fora dos recursos corporativos especificados. Para fazer isso, grupos de ativos de usuário são usados. Aplicamos um construtor de grupos lógicos de ativos com suporte hierárquico para dimensionar a lógica de detecção para objetos distribuídos territorialmente. Por exemplo, para DHCP, detectamos o uso das portas 67/68 para todos os hosts que não estão no grupo de servidores DHCP.
A análise de portas e protocolos também ajuda a identificar, por exemplo, violações da segmentação de rede, encaminhamento de acesso remoto e outros incidentes.
Ao enriquecer a telemetria com dados sobre usuários e hosts (por exemplo, do Windows Event Collector), você pode interceptar o uso de contas privilegiadas ou ver eventos de autorização inadmissíveis.
Detecção de ataques: de assinaturas a comportamento
E então chegamos ao mais interessante - a detecção de ataques com base na telemetria. Aqui reside a diferença fundamental entre NDR e NGIDPS.
Qual é a diferença?
IDPS se baseia em um payload malicioso conhecido com antecedência ou assinaturas características que estão disponíveis apenas em uma cópia completa do tráfego. No caso de tráfego criptografado, o NGIDPS só pode funcionar com impressões digitais e apenas para ameaças conhecidas. Sim, parte do tráfego vertical pode ser descriptografada via MITM, mas nem tudo. Muitos aplicativos não suportam MITM, eles devem ser excluídos, dando ao invasor a oportunidade de tunelamento.
É especialmente difícil com o tráfego horizontal criptografado dentro da rede. Ele não passa pelo NGFW de borda, e descriptografá-lo por meio de um proxy MITM em um só lugar é impossível. Mesmo que um NGFW seja instalado dentro da rede, ele geralmente fecha apenas o núcleo ou o data center, e os segmentos que se comunicam diretamente, contornando o núcleo, ainda permanecem "cegos".
Assim, em qualquer infraestrutura, existem áreas onde o NGIDPS baseado na análise de payload é ineficaz. O mesmo se aplica a ferramentas Red Team de código aberto: uma assinatura pode ser escrita para cada uma, mas a modificação da ferramenta torna as assinaturas inúteis. Os grupos APT usam ferramentas personalizadas.
Como detectar ataques na telemetria de rede sem payload
A resposta é por métodos não baseados em assinatura, construindo perfis de tráfego de rede normal e identificando desvios anormais. Essa abordagem é conhecida como NTA (Network Traffic Analysis) e surgiu em 2017. Os pioneiros da detecção não baseada em assinatura usando aprendizado de máquina foram Vectra (desde 2011) e Darktrace (desde 2013).
Desde 2020, o NTA evoluiu para NDR. Em 2025, a Gartner lançou o primeiro quadrante para o segmento NDR (Network Detection and Response). Os quatro líderes do quadrante usam telemetria de rede em seu trabalho.
Do ponto de vista da análise não baseada em assinatura, a diferença entre a captura completa de tráfego e a telemetria está no volume de metadados. Os modelos de ML para detectar desvios anormais do comportamento normal funcionam com metadados (semelhante ao princípio Zeek), e não com o payload, como IDPS.
Magic Quadrant Gartner para NDR
Por que a telemetria de rede está se tornando uma nova tendência
A pergunta natural surge: "Por que a transição para a telemetria se tornou uma tendência agora?". Não se trata apenas da eficácia dos algoritmos, mas também da impossibilidade física de usar métodos antigos em infraestruturas modernas. A abordagem clássica com a análise de uma cópia completa do tráfego (SPAN) enfrenta o rápido crescimento do volume de infraestrutura de nuvem privada e pública. E isso tanto do ponto de vista das capacidades de análise de grandes volumes quanto do ponto de vista do custo.
Tendência mundial: nuvens e telemetria
A análise de grandes volumes de dados nas nuvens (Amazon, Google, Azure) é uma tendência mundial moderna. As nuvens suportam um formato específico de telemetria de rede - VPC Flow Logs.
É para trabalhar com telemetria nas nuvens que a Vectra adquiriu a startup Netography, especializada em segurança em nuvem, bem como na análise de NetFlow, sFlow, IPFIX e VPC Flow Logs. O fundador da Netography é Marty Roesch, criador e desenvolvedor do IDPS Snort, fundador da empresa SourceFire, absorvida pela Cisco.
É simbólico que o fundador do lendário IDPS clássico agora esteja desenvolvendo a análise de telemetria de rede.
Situação na Rússia
A infraestrutura on-prem ainda domina na Federação Russa, mas a necessidade de analisar grandes volumes de dados não vai a lugar nenhum. Na verdade, nas empresas, as nuvens públicas são substituídas por privadas.
A principal vantagem da telemetria de rede é seu tamanho. É de aproximadamente 5 a 10% do volume de dados brutos. Isso é especialmente importante com alta utilização de canal e grandes volumes de tráfego.
Detecção de ameaças com base na análise comportamental na telemetria de rede
Agora - ao ponto. Como exatamente detectar ameaças na telemetria de rede?
Spoiler: exatamente da mesma forma que em uma cópia do tráfego - por metadados.
Este é o uso de certos sinais para cada host, a construção de seu perfil (baseline) e a identificação de desvios anormais. Os sinais devem estar disponíveis na telemetria ou podem ser enriquecidos com dados externos.
O uso de ML permite comparar o comportamento do host com seu perfil previsto. Ele pode ser construído de duas maneiras:
Historicamente - comparando o host consigo mesmo em períodos anteriores;
Por semelhança - comparando o host com outros hosts que são inicialmente semelhantes a ele.
Modelos de aprendizado não supervisionado são usados para construir perfis. Eles são treinados em dados diretamente no site.
Para alguns tipos de ataques, é mais eficaz analisar pares ("remetente - destinatário") com uma previsão individual para cada par. Por exemplo, isso é importante para força bruta, password spraying ou túneis.
Para aumentar a precisão da detecção, é extremamente importante:
Formar perfis individuais para cada host ou par (e não para um grupo);
Use pequenos intervalos de tempo (por exemplo, um surto de sessões em cinco minutos é claramente expresso, e em cinco horas - borrado).
O aprendizado não supervisionado também pode ser usado para detectar certos tipos de ataques. Por exemplo, comunicações com C&C ou C2, e o uso de túneis para mascará-los. Para detectar alguns malware, você pode usar modelos de ML treinados em conjuntos de dados com exemplos de tráfego malicioso e normal.
Para trabalhar na telemetria de rede, os sinais do modelo de ML devem ser suportados na telemetria de rede.
Essa abordagem foi implementada no Encrypted traffic analysis da Cisco. Na solução SNA (antigo Stealthwatch) com base em telemetria de rede enriquecida de tráfego criptografado, o fornecedor classificou vários fluxos contendo diferentes tipos de ameaças.
Exemplo de detecção de movimento lateral
Para detectar movimento lateral usando protocolos legais (RDP, SSH e outros), você pode filtrar as sessões apropriadas e construir uma previsão do número normal de sessões para cada host ou par. Mas se você combinar hosts em grupos por semelhança no número de sessões e construir uma previsão de grupo, um pequeno surto anormal de sessões para um host específico pode ser "borrado" pelo valor geral superestimado do grupo.
A precisão da detecção aumenta muitas vezes se você pré-filtrar as sessões e vinculá-las aos elementos da infraestrutura. Isso é semelhante à configuração do IDPS: dados sobre redes e servidores são necessários - HOMENET, DC_SERVERS, DNS_SERVERS, HTTP_SERVERS, SMTP_SERVERS, etc.
Aumentando a precisão com feeds de TI
Normalmente, a vida útil de um IP malicioso é de algumas horas. A precisão da detecção pode ser aumentada adicionando a presença de indicadores de feeds de TI aos sinais das sessões em que o modelo de ML é treinado. Se o modelo comportamental indicar uma anomalia e o IP estiver presente nos feeds de TI, a confiança na comprometimento do host se torna extremamente alta.
Quais ataques podem ser detectados usando análise comportamental e ML
Aqui está apenas uma lista incompleta de tais ataques, que podem ser detectados graças à análise comportamental e ML.
Ataque
O que exatamente é detectado (padrão comportamental / sinal para ML)
Varredura de portas e hosts, incluindo lenta
Um surto incomum para o host ou par "remetente-destinatário" de sessões curtas para um IP ou várias portas.
Número atípico de endereços IP com os quais o host interagiu.
Força bruta, ataques pass-the-spray
Um surto incomum para o host ou par "remetente-destinatário" de sessões de protocolo ou porta correspondentes à autorização por parâmetros de sessão.
Exfiltração de dados (incluindo lenta e automatizada)
Um surto incomum para o host ou par "remetente-destinatário" do volume de tráfego do protocolo ou porta correspondente. No caso de exfiltração lenta, envio periódico de pacotes entre um par de IPs, que tem sinais de mascaramento de comunicações.
Vários tipos de tunelamento
Um surto incomum para o host ou par "remetente-destinatário" do volume de tráfego ou comunicação periódica com sinais de mascaramento.
Movimento lateral, incluindo o uso de protocolos legais (Living off the Land)
Um surto incomum para o host de sessões horizontais longas sobre o protocolo de gerenciamento remoto.
Aparecimento de um protocolo de acesso remoto horizontal incomum para o host ou grupo de hosts que antes se comportavam de forma semelhante no tráfego de rede.
Comunicações com C&C, incluindo o uso de Jitter
Envio periódico de pacotes entre um par de IPs, que tem sinais de mascaramento de comunicações C&C.
Criptomineração
Envio periódico de pacotes especializados entre um par de IPs, que tem sinais de mineração.
Servidor proxy interno
Um surto incomum para o host de sessões específicas sobre os protocolos ou portas usados pelos pivôs.
Coleta de dados de repositórios de configuração (por exemplo, dump MIB via SNMP)
Um surto incomum para o host ou par "remetente-destinatário" de sessões específicas sobre o protocolo SNMP ou a porta.
Aparência de novos serviços e endereços IP
Portas incomuns para IP ou IPs incomuns para a rede.
Substituição de resposta LLMNR/NBT-NS e retransmissão SMB
Um surto incomum para o host de sessões que têm sinais de seleção de hash.
DoS/DDoS, SYN-flood
Um surto incomum para o host de sessões com as flags de rede apropriadas.
Um surto incomum para o host do volume de tráfego de resposta.
Repetição do comportamento em vários hosts.
Usando portas não padrão
Incompatibilidade das portas usadas com a base.
Comprometimento de contas (ao enriquecer sessões)
Usando contas privilegiadas (administrador) ou autorização incomum de usuários.
Comprometimento de hosts por vários sinais
Surtos incomuns de atividade de rede por vários sinais.
Deslocamento do perfil de rede do host. Por exemplo, uma mudança incomum no comportamento da rede.
Direção incomum de comunicações.
Anomalias de tráfego ICMP
Várias opções para fluxos ICMP incomuns.
Padrões anormais de flags de rede
Sequências anormais de flags de rede.
Ignorar as flags necessárias para uma conexão TCP normal.
O que não é suportado com base na telemetria de rede?
É importante entender não apenas as capacidades, mas também as limitações da telemetria de rede. A primeira é IDPS. Qualquer lógica que exija análise de payload ou conteúdo de comandos de protocolo não é possível apenas na telemetria de rede. A segunda é a análise aprofundada do conteúdo dos protocolos de aplicação.
Conclusão
A telemetria de rede não substitui a análise completa do tráfego de rede. No entanto, ela está se tornando uma poderosa ferramenta de segurança da informação nos casos em que a análise de tráfego é impossível ou muito limitada:
Com altas cargas na rede (centenas de gigabits e acima);
Em redes distribuídas territorialmente com muitos pontos de saída;
Em ambientes de nuvem com enormes volumes de dados transmitidos (VPC Flow Logs).
O principal mito de que NetFlow é "apenas para TI" foi refutado pela prática há muito tempo. As soluções modernas de NDR são construídas precisamente na análise não baseada em assinatura de metadados de tráfego de rede, e não apenas em assinaturas de sistemas IDPS.
Esse fato é confirmado por nossas análises. De acordo com os dados de nossa pesquisa, mais de 50% das soluções da classe NDR no mercado mundial trabalham com telemetria de rede e seus análogos.
Tags:
ndr
nta
netflow
ipfix
ml
TI feeds
análise de tráfego de rede
ngips
anomaly detection
Habrs:
Blog da empresa Garda
Segurança da informação
Olá, pessoal do Habr!
Sou Stanislav Gribanov, chefe da área de produtos da empresa Garda e autor do blog "Cibersegurança e Expertise em Produtos para Negócios".
Hoje, quero discutir os benefícios do NetFlow e da telemetria de rede para proteger redes contra ataques de hackers. Este tópico não é novo, mas ainda existem muitas controvérsias em torno dele.
A telemetria de rede é frequentemente percebida como um artefato do mundo dos engenheiros de rede, e não como uma ferramenta séria de segurança da informação. Isso geralmente está relacionado à percepção errônea dos sistemas NGIPS como análogos de NTA. Nesse caso, a principal funcionalidade é a detecção de ataques por assinatura, que requer apenas tráfego bruto para funcionar. Ao mesmo tempo, os métodos de análise comportamental, aprendizado de máquina e outras técnicas não baseadas em assinatura em tais sistemas são complementares e não formam o núcleo da lógica de detecção.
Por exemplo, a solução Cisco SourceFire NGIPS (folha de dados de 2013) também usa apenas tráfego bruto, e sua funcionalidade se sobrepõe muito à de um analisador de tráfego de rede doméstico típico, que se posiciona como NTA ou NDR. O produto Cisco se baseia em métodos de assinatura, análise de payload, bancos de reputação e usa complementarmente o aprendizado de máquina para detectar malware do tipo worm.
Devido a essa percepção errônea, um equívoco em massa se formou no mercado russo: para procurar ameaças na rede, você só precisa analisar o tráfego bruto, e a telemetria não é adequada para isso.
Abaixo, vou contar como você pode detectar ameaças com base em metadados de tráfego de rede sem analisar o payload, em particular, a telemetria de rede.
O que é telemetria de rede e por que ela é necessária
Pode parecer estranho, mas há confusão aqui com frequência. Alguns erroneamente atribuem dados coletados por agentes de proteção de endpoint à telemetria de rede. Na verdade, não é assim.
A telemetria de rede é estatísticas de fluxos de rede coletadas de equipamentos de rede de camada L2 e superior: switches, roteadores, firewalls e outros dispositivos. O protocolo mais comum para coletar essa telemetria é o NetFlow.
Um pouco de história
NetFlow é um padrão de telemetria de rede desenvolvido pela Cisco em 1996. Na verdade, tornou-se sinônimo do termo "telemetria de rede" e a ferramenta mais massiva para analisar o que está acontecendo na rede. Existem várias versões do protocolo; a décima versão é conhecida como IPFIX (Internet Protocol Flow Information Export).
As soluções da classe NPM (Network Performance Monitoring) são construídas com base no NetFlow. Por exemplo, a solução do conhecido fornecedor SolarWinds (que já deixou a Rússia). Alguns fabricantes usam seus próprios protocolos de telemetria: NetStream (Huawei), JFlow (Juniper), AppFlow (Citrix).
Por que a telemetria de rede é necessária
NetFlow permite detectar ameaças em redes nas quais é difícil ou impossível obter uma cópia do tráfego de rede. Aqui estão alguns exemplos desses casos.
O primeiro exemplo é um data center. Ele processa enormes fluxos de dados em centenas de Gbit/s, a complexidade e o alto custo da análise de tal volume de tráfego bruto tornam o Netflow a única fonte de dados sobre a rede no data center.
Outra opção são redes descentralizadas geodistribuídas com um grande número de pontos de saída separados para a Internet: lojas, pequenos escritórios, instituições educacionais ou médicas, etc. Tirar uma cópia do tráfego (SPAN) em tais redes pode ser difícil devido a equipamentos desatualizados, restrições de canais de comunicação ou topologia de rede.
Fontes de telemetria
Para coletar telemetria de rede, existe uma ampla gama de equipamentos de diferentes fabricantes: da classe Enterprise, como Cisco, Huawei, Eltex, Juniper, Extreme, Fortinet, a soluções de nível SoHo, incluindo Mikrotik, D-Link, TP-Link, Zyxel, Asus e outros.
Amostragem: quando a telemetria se torna inútil para a segurança da informação
Uma nuance importante: as tarefas de segurança da informação limitam significativamente o uso de telemetria amostrada (abreviada), por exemplo, sFlow. Ao amostrar, perdemos metadados para cada sessão - a frequência das comunicações, os volumes individuais das sessões, parâmetros quantitativos precisos.
Tudo isso "quebra" os sinais necessários para construir previsões de comportamento normal do host e detectar anomalias.
Para fins de segurança da informação, é necessária telemetria completa sem amostragem.
O que o IPFIX oferece? Parâmetros-chave
Os dados obtidos da telemetria de rede já foram analisados mais de uma vez, mas vou repetir alguns parâmetros IPFIX interessantes:
Endereços IP e MAC do remetente e do destinatário;
Portas do remetente e do destinatário;
Protocolo de transporte;
Flags TCP, incluindo o motivo da terminação do fluxo;
Duração do fluxo (início e fim);
Número de pacotes e volume de dados do fluxo;
Sistemas autônomos (AS);
Tipo de serviço (TOS);
Aplicativo (análogo a DPI) - se suportado no lado do exportador;
Metadados HTTP: user-agent, tipo de conteúdo e outros parâmetros.
É interessante que o equipamento de rede Cisco suporte seu próprio DPI - NBAR, que contém uma extensa base de protocolos e aplicativos das camadas L3–L7. Caso contrário, os dados DPI podem ser transferidos pelo exportador para IPFIX, por exemplo, NGFW.
Cenários de segurança da informação para os quais a análise baseada em telemetria de rede pode ser aplicada
Análise de reputação (Threat Intelligence Feeds)
A opção mais simples é verificar os endereços IP em bancos de reputação (TI feeds). Por exemplo, em nosso produto "Garda NDR", usamos dados de Inteligência de Ameaças. Estes são feeds que incluem:
C&C (centros de comando e controle);
Atividade de botnet;
DDoS;
Criptomineração;
TOR, proxy;
Phishing, malware;
Força bruta, spam, hosts suspeitos.
Na versão estendida dos feeds de TI, campos de enriquecimento adicionais estão disponíveis: sistemas autônomos, data da última atividade.
Mas IP é apenas o começo. E os nomes de host, que não estão na telemetria padrão? Usamos um módulo de análise de solicitações DNS para servidores DNS corporativos e nosso próprio sistema para enriquecer os metadados da sessão na fase de coleta de pacotes. Isso permite que você verifique os hosts para conformidade com as listas de feeds de TI. Os tipos de listas de reputação podem ser muito diferentes - o principal é que eles contenham os parâmetros suportados, como IP, nomes de host, etc.
Infraestrutura corporativa e Shadow IT
Dados básicos de IP/MAC são suficientes para formar perfis de sub-redes por IP ou portas, detectar novos protocolos, endereços IP ou violações das regras de segmentação de rede em firewalls.
E se não houver DPI e apenas a porta for conhecida? Nesse caso, usamos nossa própria base de correspondência de portas e protocolos, que ajuda a identificar portas não padrão para protocolos conhecidos. É claro que essa abordagem é eficaz apenas para portas estáticas. Para dinâmicas, a extração do applicationId será necessária.
Com a ajuda da telemetria de rede, você também pode detectar DNS não corporativos, DHCP ou até mesmo controladores de domínio falsos. A lógica é simples: procuramos tráfego fora dos recursos corporativos especificados. Para fazer isso, grupos de ativos de usuário são usados. Aplicamos um construtor de grupos lógicos de ativos com suporte hierárquico para dimensionar a lógica de detecção para objetos distribuídos territorialmente. Por exemplo, para DHCP, detectamos o uso das portas 67/68 para todos os hosts que não estão no grupo de servidores DHCP.
A análise de portas e protocolos também ajuda a identificar, por exemplo, violações da segmentação de rede, encaminhamento de acesso remoto e outros incidentes.
Ao enriquecer a telemetria com dados sobre usuários e hosts (por exemplo, do Windows Event Collector), você pode interceptar o uso de contas privilegiadas ou ver eventos de autorização inadmissíveis.
Detecção de ataques: de assinaturas a comportamento
E então chegamos ao mais interessante - a detecção de ataques com base na telemetria. Aqui reside a diferença fundamental entre NDR e NGIDPS.
Qual é a diferença?
IDPS se baseia em um payload malicioso conhecido com antecedência ou assinaturas características que estão disponíveis apenas em uma cópia completa do tráfego. No caso de tráfego criptografado, o NGIDPS só pode funcionar com impressões digitais e apenas para ameaças conhecidas. Sim, parte do tráfego vertical pode ser descriptografada via MITM, mas nem tudo. Muitos aplicativos não suportam MITM, eles devem ser excluídos, dando ao invasor a oportunidade de tunelamento.
É especialmente difícil com o tráfego horizontal criptografado dentro da rede. Ele não passa pelo NGFW de borda, e descriptografá-lo por meio de um proxy MITM em um só lugar é impossível. Mesmo que um NGFW seja instalado dentro da rede, ele geralmente fecha apenas o núcleo ou o data center, e os segmentos que se comunicam diretamente, contornando o núcleo, ainda permanecem "cegos".
Assim, em qualquer infraestrutura, existem áreas onde o NGIDPS baseado na análise de payload é ineficaz. O mesmo se aplica a ferramentas Red Team de código aberto: uma assinatura pode ser escrita para cada uma, mas a modificação da ferramenta torna as assinaturas inúteis. Os grupos APT usam ferramentas personalizadas.
Como detectar ataques na telemetria de rede sem payload
A resposta é por métodos não baseados em assinatura, construindo perfis de tráfego de rede normal e identificando desvios anormais. Essa abordagem é conhecida como NTA (Network Traffic Analysis) e surgiu em 2017. Os pioneiros da detecção não baseada em assinatura usando aprendizado de máquina foram Vectra (desde 2011) e Darktrace (desde 2013).
Desde 2020, o NTA evoluiu para NDR. Em 2025, a Gartner lançou o primeiro quadrante para o segmento NDR (Network Detection and Response). Os quatro líderes do quadrante usam telemetria de rede em seu trabalho.
Do ponto de vista da análise não baseada em assinatura, a diferença entre a captura completa de tráfego e a telemetria está no volume de metadados. Os modelos de ML para detectar desvios anormais do comportamento normal funcionam com metadados (semelhante ao princípio Zeek), e não com o payload, como IDPS.
Magic Quadrant Gartner para NDR
Por que a telemetria de rede está se tornando uma nova tendência
A pergunta natural surge: "Por que a transição para a telemetria se tornou uma tendência agora?". Não se trata apenas da eficácia dos algoritmos, mas também da impossibilidade física de usar métodos antigos em infraestruturas modernas. A abordagem clássica com a análise de uma cópia completa do tráfego (SPAN) enfrenta o rápido crescimento do volume de infraestrutura de nuvem privada e pública. E isso tanto do ponto de vista das capacidades de análise de grandes volumes quanto do ponto de vista do custo.
Tendência mundial: nuvens e telemetria
A análise de grandes volumes de dados nas nuvens (Amazon, Google, Azure) é uma tendência mundial moderna. As nuvens suportam um formato específico de telemetria de rede - VPC Flow Logs.
É para trabalhar com telemetria nas nuvens que a Vectra adquiriu a startup Netography, especializada em segurança em nuvem, bem como na análise de NetFlow, sFlow, IPFIX e VPC Flow Logs. O fundador da Netography é Marty Roesch, criador e desenvolvedor do IDPS Snort, fundador da empresa SourceFire, absorvida pela Cisco.
É simbólico que o fundador do lendário IDPS clássico agora esteja desenvolvendo a análise de telemetria de rede.
Situação na Rússia
A infraestrutura on-prem ainda domina na Federação Russa, mas a necessidade de analisar grandes volumes de dados não vai a lugar nenhum. Na verdade, nas empresas, as nuvens públicas são substituídas por privadas.
A principal vantagem da telemetria de rede é seu tamanho. É de aproximadamente 5 a 10% do volume de dados brutos. Isso é especialmente importante com alta utilização de canal e grandes volumes de tráfego.
Detecção de ameaças com base na análise comportamental na telemetria de rede
Agora - ao ponto. Como exatamente detectar ameaças na telemetria de rede?
Spoiler: exatamente da mesma forma que em uma cópia do tráfego - por metadados.
Este é o uso de certos sinais para cada host, a construção de seu perfil (baseline) e a identificação de desvios anormais. Os sinais devem estar disponíveis na telemetria ou podem ser enriquecidos com dados externos.
O uso de ML permite comparar o comportamento do host com seu perfil previsto. Ele pode ser construído de duas maneiras:
Historicamente - comparando o host consigo mesmo em períodos anteriores;
Por semelhança - comparando o host com outros hosts que são inicialmente semelhantes a ele.
Modelos de aprendizado não supervisionado são usados para construir perfis. Eles são treinados em dados diretamente no site.
Para alguns tipos de ataques, é mais eficaz analisar pares ("remetente - destinatário") com uma previsão individual para cada par. Por exemplo, isso é importante para força bruta, password spraying ou túneis.
Para aumentar a precisão da detecção, é extremamente importante:
Formar perfis individuais para cada host ou par (e não para um grupo);
Use pequenos intervalos de tempo (por exemplo, um surto de sessões em cinco minutos é claramente expresso, e em cinco horas - borrado).
O aprendizado não supervisionado também pode ser usado para detectar certos tipos de ataques. Por exemplo, comunicações com C&C ou C2, e o uso de túneis para mascará-los. Para detectar alguns malware, você pode usar modelos de ML treinados em conjuntos de dados com exemplos de tráfego malicioso e normal.
Para trabalhar na telemetria de rede, os sinais do modelo de ML devem ser suportados na telemetria de rede.
Essa abordagem foi implementada no Encrypted traffic analysis da Cisco. Na solução SNA (antigo Stealthwatch) com base em telemetria de rede enriquecida de tráfego criptografado, o fornecedor classificou vários fluxos contendo diferentes tipos de ameaças.
Exemplo de detecção de movimento lateral
Para detectar movimento lateral usando protocolos legais (RDP, SSH e outros), você pode filtrar as sessões apropriadas e construir uma previsão do número normal de sessões para cada host ou par. Mas se você combinar hosts em grupos por semelhança no número de sessões e construir uma previsão de grupo, um pequeno surto anormal de sessões para um host específico pode ser "borrado" pelo valor geral superestimado do grupo.
A precisão da detecção aumenta muitas vezes se você pré-filtrar as sessões e vinculá-las aos elementos da infraestrutura. Isso é semelhante à configuração do IDPS: dados sobre redes e servidores são necessários - HOMENET, DC_SERVERS, DNS_SERVERS, HTTP_SERVERS, SMTP_SERVERS, etc.
Aumentando a precisão com feeds de TI
Normalmente, a vida útil de um IP malicioso é de algumas horas. A precisão da detecção pode ser aumentada adicionando a presença de indicadores de feeds de TI aos sinais das sessões em que o modelo de ML é treinado. Se o modelo comportamental indicar uma anomalia e o IP estiver presente nos feeds de TI, a confiança na comprometimento do host se torna extremamente alta.
Quais ataques podem ser detectados usando análise comportamental e ML
Aqui está apenas uma lista incompleta de tais ataques, que podem ser detectados graças à análise comportamental e ML.
Ataque
O que exatamente é detectado (padrão comportamental / sinal para ML)
Varredura de portas e hosts, incluindo lenta
Um surto incomum para o host ou par "remetente-destinatário" de sessões curtas para um IP ou várias portas.
Número atípico de endereços IP com os quais o host interagiu.
Força bruta, ataques pass-the-spray
Um surto incomum para o host ou par "remetente-destinatário" de sessões de protocolo ou porta correspondentes à autorização por parâmetros de sessão.
Exfiltração de dados (incluindo lenta e automatizada)
Um surto incomum para o host ou par "remetente-destinatário" do volume de tráfego do protocolo ou porta correspondente. No caso de exfiltração lenta, envio periódico de pacotes entre um par de IPs, que tem sinais de mascaramento de comunicações.
Vários tipos de tunelamento
Um surto incomum para o host ou par "remetente-destinatário" do volume de tráfego ou comunicação periódica com sinais de mascaramento.
Movimento lateral, incluindo o uso de protocolos legais (Living off the Land)
Um surto incomum para o host de sessões horizontais longas sobre o protocolo de gerenciamento remoto.
Aparecimento de um protocolo de acesso remoto horizontal incomum para o host ou grupo de hosts que antes se comportavam de forma semelhante no tráfego de rede.
Comunicações com C&C, incluindo o uso de Jitter
Envio periódico de pacotes entre um par de IPs, que tem sinais de mascaramento de comunicações C&C.
Criptomineração
Envio periódico de pacotes especializados entre um par de IPs, que tem sinais de mineração.
Servidor proxy interno
Um surto incomum para o host de sessões específicas sobre os protocolos ou portas usados pelos pivôs.
Coleta de dados de repositórios de configuração (por exemplo, dump MIB via SNMP)
Um surto incomum para o host ou par "remetente-destinatário" de sessões específicas sobre o protocolo SNMP ou a porta.
Aparência de novos serviços e endereços IP
Portas incomuns para IP ou IPs incomuns para a rede.
Substituição de resposta LLMNR/NBT-NS e retransmissão SMB
Um surto incomum para o host de sessões que têm sinais de seleção de hash.
DoS/DDoS, SYN-flood
Um surto incomum para o host de sessões com as flags de rede apropriadas.
Um surto incomum para o host do volume de tráfego de resposta.
Repetição do comportamento em vários hosts.
Usando portas não padrão
Incompatibilidade das portas usadas com a base.
Comprometimento de contas (ao enriquecer sessões)
Usando contas privilegiadas (administrador) ou autorização incomum de usuários.
Comprometimento de hosts por vários sinais
Surtos incomuns de atividade de rede por vários sinais.
Deslocamento do perfil de rede do host. Por exemplo, uma mudança incomum no comportamento da rede.
Direção incomum de comunicações.
Anomalias de tráfego ICMP
Várias opções para fluxos ICMP incomuns.
Padrões anormais de flags de rede
Sequências anormais de flags de rede.
Ignorar as flags necessárias para uma conexão TCP normal.
O que não é suportado com base na telemetria de rede?
É importante entender não apenas as capacidades, mas também as limitações da telemetria de rede. A primeira é IDPS. Qualquer lógica que exija análise de payload ou conteúdo de comandos de protocolo não é possível apenas na telemetria de rede. A segunda é a análise aprofundada do conteúdo dos protocolos de aplicação.
Conclusão
A telemetria de rede não substitui a análise completa do tráfego de rede. No entanto, ela está se tornando uma poderosa ferramenta de segurança da informação nos casos em que a análise de tráfego é impossível ou muito limitada:
Com altas cargas na rede (centenas de gigabits e acima);
Em redes distribuídas territorialmente com muitos pontos de saída;
Em ambientes de nuvem com enormes volumes de dados transmitidos (VPC Flow Logs).
O principal mito de que NetFlow é "apenas para TI" foi refutado pela prática há muito tempo. As soluções modernas de NDR são construídas precisamente na análise não baseada em assinatura de metadados de tráfego de rede, e não apenas em assinaturas de sistemas IDPS.
Esse fato é confirmado por nossas análises. De acordo com os dados de nossa pesquisa, mais de 50% das soluções da classe NDR no mercado mundial trabalham com telemetria de rede e seus análogos.
Tags:
ndr
nta
netflow
ipfix
ml
TI feeds
análise de tráfego de rede
ngips
anomaly detection
