forlegacy

Relatório técnico 01 / 10  ·  Série: detecção de anomalias em fluxos IP

Quando o ataque cabe em 0,01% dos pacotes: entropia de fluxos IP na era do tráfego cifrado

Publicado em 21 de agosto de 2026  ·  Tradução da versão de registro em inglês

Resumo

Ataques de negação de serviço acima de um terabit por segundo deixaram de ser exceção, porém a maior parte do tráfego hostil continua pequena e curta demais para mover qualquer medidor de volume. Este relatório retoma o princípio central da inspeção profunda de fluxos IP, apresentado originalmente em [1], e o recoloca diante do cenário de 2026: transporte cifrado por padrão, botnets formados por dispositivos comprometidos e campanhas que terminam antes que um operador humano consiga reagir. O argumento é que a entropia calculada sobre metadados de fluxo mede a forma do tráfego, e não o seu conteúdo, razão pela qual sobrevive à cifra. Descreve-se o que a entropia representa em termos de concentração e dispersão das propriedades de fluxo, por que uma varredura de rede que consome 0,01% dos pacotes é invisível para detectores volumétricos, e quais limites do modelo clássico aplicado no nível da rede motivaram a análise no nível do dispositivo. Esta é a primeira de dez partes.

Palavras-chave: anomalia de rede, entropia, fluxo IP, tráfego cifrado, detecção de intrusão, gestão de redes.

01A mediana é pequena. A cauda é gigante.

Existe uma distorção conhecida na forma como se fala de ataques de rede. As manchetes registram os recordes, e os recordes são de fato impressionantes: no primeiro semestre de 2026, a Cloudflare relatou ter mitigado 935 ataques de camada de rede acima de 1 Tbps, com uma alta de 519% entre o primeiro e o segundo trimestre[10].

O mesmo relatório traz o número que quase ninguém cita. Nesse período, 96,62% dos ataques de camada de rede ficaram abaixo de 500 Mbps e 90,60% terminaram em menos de dez minutos[10]. A distribuição é bimodal de forma agressiva: uma cauda que dobra a infraestrutura de um provedor e uma massa central que nem sequer aparece nos gráficos de utilização de link.

Essa massa central é o problema difícil. Um detector calibrado pela cauda passa por cima dela sem registrar nada. Um detector calibrado por ela dispara alarmes sem parar quando a cauda chega. Portanto, o que se pede de um sistema de detecção não é sensibilidade, e sim sensibilidade ajustável, um ponto ao qual esta série volta na Parte 4.

Vale notar que a mediana pequena não é sinônimo de evento inofensivo. Uma varredura de portas não derruba nada por si só, contudo costuma ser o primeiro movimento de quem procura uma vulnerabilidade para explorar[12]. O evento barato de gerar é justamente o que antecede o caro.

02O que a cifra deixou visível

Em termos simples

Imagine uma central telefônica que não pode ouvir as chamadas, mas registra todas elas: quem ligou para quem, a que horas, por quantos minutos. Sem escutar uma única palavra, essa lista revela quem ligou para trezentos números diferentes em dois minutos. É esse tipo de leitura que a análise de fluxos faz.

A inspeção profunda de pacotes, que examina o conteúdo transportado, perdeu terreno de forma irreversível. Com o TLS 1.3[8] e com o QUIC[9], não apenas a carga útil, mas também boa parte dos metadados de sessão que antes ficavam em claro passaram a viajar cifrados por padrão.

Todavia, existe uma camada que a criptografia não apaga, porque ela é a condição de funcionamento da própria rede. Roteadores e comutadores precisam saber para onde encaminhar cada pacote, e por isso agrupam o tráfego em fluxos e exportam esses registros por protocolos como o IPFIX[7].

A cifra protege o que foi dito. Ela não esconde quem falou com quem, quando, com que frequência, em que volume e por quanto tempo. Um registro de fluxo carrega endereço de origem e destino, portas, protocolo, contagem de pacotes, de bytes e de fluxos, além das marcas de tempo. Nada disso depende de ler um único byte de conteúdo.

Convém ser honesto quanto ao alcance dessa escolha. Um sistema que observa apenas metadados de fluxo não detecta vírus, cavalos de Troia, estouros de buffer ou escaladas de privilégio, precisamente porque essas evidências vivem no conteúdo[1]. O escopo é mais restrito, embora seja um escopo que continua acessível quando todo o resto se fecha.

03Entropia, em termos simples

Em termos simples

Anote a porta de destino de cada conexão que entra na sua rede durante cinco minutos. Se a lista for quase toda igual, a entropia é baixa. Se cada linha trouxer um número diferente, a entropia é alta. Anomalias empurram esse número para um dos dois extremos, e é a distância até o extremo que serve de alarme.

Entropia é uma medida que os físicos criaram para quantificar desordem e que a teoria da informação adotou para medir incerteza[2]. Na análise de tráfego, ela ganha uma leitura mais direta: entropia mede o quanto uma propriedade do tráfego está concentrada ou dispersa.

Dada uma distribuição de probabilidades p1, p2, …, pn, a entropia de Shannon é definida como:

HS = −∑ pi log pi

O valor é mínimo quando quase toda a probabilidade se acumula em um único ponto, e máximo quando ela se espalha por igual entre muitos pontos. Aplicada a portas de destino, por exemplo, a medida separa um servidor web sadio, no qual quase tudo chega à porta 443, de um alvo sob varredura, no qual dezenas de milhares de portas aparecem uma vez cada.

04Concentração e dispersão são a assinatura do evento

O ponto que torna a entropia interessante não é detectar que algo mudou. É que a direção da mudança, propriedade por propriedade, descreve o tipo de evento.

Uma inundação TCP contra um servidor concentra o endereço de destino, a porta de destino, a contagem de pacotes e a de fluxos, ao mesmo tempo em que dispersa a porta de origem, já que a ferramenta de ataque sorteia portas altas a cada conexão. Uma varredura de rede faz o oposto quase na íntegra, dispersando endereços e contagens com pacotes minúsculos.

Em [1], essa leitura foi formalizada como uma assinatura textual, na qual cada posição corresponde a uma propriedade de fluxo rotulada como concentrada (C), dispersa (D) ou normal (N). O ataque distribuído real registrado no estudo produziu TCCDCCCC, o evento de alpha flow produziu TCCCCCDC e a varredura de rede produziu IDDDDD.

São, na prática, impressões digitais. Duas anomalias que causam perturbações de magnitude completamente diferente ficam distinguíveis pela forma, e não pelo tamanho.

Valores de entropia por dispositivo ativo, com a banda de normalidade sombreada entre os limiares inferior e superior. Um ponto cai abaixo da banda e está marcado como concentrado; outro sobe acima dela e está marcado como disperso.
Fig. 1. Leitura da entropia por dispositivo ativo. A faixa entre o limiar inferior (LT) e o superior (UT) delimita a região considerada normal. Um ponto abaixo de LT indica concentração da propriedade; um ponto acima de UT indica dispersão. Esquema elaborado para este relatório, seguindo a forma de apresentação de [1]; não corresponde a dados medidos. Os rótulos da figura permanecem em inglês, por ser a língua única das ilustrações da série.

05Por que medir a rede inteira não é suficiente

A aplicação clássica da entropia em detecção de anomalias trabalha no nível da rede[3][4]. Calcula-se uma distribuição única, agregando todo o tráfego observado no intervalo, e verifica-se o desvio dessa distribuição em relação ao comportamento habitual.

O modelo funciona bem enquanto existe um evento por vez. Quando vários acontecem simultaneamente, entretanto, aparece um efeito de dominância: o ataque que move gigabytes reescreve a distribuição agregada, e o evento discreto some dentro dela[4].

Os números do experimento com varredura de rede em [1] mostram a escala do problema. O dispositivo varredor sondou 254 destinos e respondeu, em média, por 0,01% dos pacotes, 0,001% dos bytes e 0,15% dos fluxos do intervalo. O evento estava no tráfego. Ele apenas não estava na média.

No mesmo estudo, quando quatro anomalias distintas foram reunidas em um único conjunto de dados, a entropia de Shannon aplicada no nível da rede identificou apenas uma das quatro[1]. Não se trata de defeito de implementação, e sim de uma consequência direta de agregar antes de medir.

A saída proposta foi mudar a unidade de observação. Em vez de uma distribuição para a rede, calcula-se a entropia sobre os fluxos trocados entre cada par de dispositivos, o que exige representar a rede como um grafo dirigido e inspecionar cada aresta. Essa é a inspeção profunda de fluxo IP, tema da Parte 3.

A segunda decisão foi trocar a entropia de Shannon pela entropia de Tsallis[6], cuja generalização introduz um parâmetro entrópico q que controla o peso das probabilidades altas e baixas no resultado[5]. Esse parâmetro é o botão de sensibilidade citado na Seção 1, e a Parte 4 mostra o que ele custa e o que ele entrega.

06O que vem nas próximas nove partes

A série percorre o caminho completo, do registro bruto de fluxo até a operação autônoma, sempre confrontando o desenho original com o cenário atual.

  1. Fluxos IP como fonte de dados. NetFlow, IPFIX e o que se perde ao abrir mão do conteúdo.
  2. A rede como grafo. Inspeção profunda de fluxo e a mudança da unidade de observação para o dispositivo.
  3. O parâmetro entrópico q. Sintonizar o detector entre a cauda e a mediana.
  4. Limiares adaptativos. Por que percentis substituíram média e desvio padrão.
  5. Assinaturas e classificação por regras. Da detecção ao diagnóstico do tipo de evento.
  6. Anomalias simultâneas. O caso em que o detector precisa ver mais de uma coisa ao mesmo tempo.
  7. Amostragem de pacotes. O custo de enxergar 1 pacote em 2048.
  8. Localizar origem e destino. Heurísticas para fluxos bidirecionais sem marca de iniciador.
  9. Da detecção à autonomia. Métricas, indicadores de desempenho e o laço de controle autonômico.

Referências

  1. A. A. Amaral, L. de S. Mendes, B. B. Zarpelão e M. L. Proença Jr., “Deep IP flow inspection to detect beyond network anomalies”, Comput. Commun., vol. 98, pp. 80–96, jan. 2017, doi: 10.1016/j.comcom.2016.12.007.
  2. C. E. Shannon, “A mathematical theory of communication”, Bell Syst. Tech. J., vol. 27, nº 4, pp. 623–656, out. 1948.
  3. A. Lakhina, M. Crovella e C. Diot, “Mining anomalies using traffic feature distributions”, em Proc. ACM SIGCOMM, Filadélfia, EUA, 2005, pp. 217–228.
  4. G. Nychis, V. Sekar, D. G. Andersen, H. Kim e H. Zhang, “An empirical evaluation of entropy-based traffic anomaly detection”, em Proc. 8th ACM SIGCOMM Conf. Internet Meas. (IMC), Vouliagmeni, Grécia, 2008, pp. 151–156.
  5. A. Ziviani, A. T. A. Gomes, M. L. Monsores e P. S. S. Rodrigues, “Network anomaly detection using nonextensive entropy”, IEEE Commun. Lett., vol. 11, nº 12, pp. 1034–1036, dez. 2007.
  6. C. Tsallis, “Possible generalization of Boltzmann-Gibbs statistics”, J. Stat. Phys., vol. 52, nº 1–2, pp. 479–487, jul. 1988.
  7. B. Claise, B. Trammell e P. Aitken, “Specification of the IP Flow Information Export (IPFIX) protocol for the exchange of flow information”, IETF, RFC 7011, set. 2013. [Online]. Disponível: https://www.rfc-editor.org/rfc/rfc7011
  8. E. Rescorla, “The Transport Layer Security (TLS) protocol version 1.3”, IETF, RFC 8446, ago. 2018. [Online]. Disponível: https://www.rfc-editor.org/rfc/rfc8446
  9. J. Iyengar e M. Thomson, “QUIC: a UDP-based multiplexed and secure transport”, IETF, RFC 9000, maio 2021. [Online]. Disponível: https://www.rfc-editor.org/rfc/rfc9000
  10. Cloudflare, “Cloudflare DDoS threat report H1 2026”, Cloudflare Blog, ago. 2026. [Online]. Disponível: https://blog.cloudflare.com/ddos-threat-report-2026-h1/
  11. M. Antonakakis et al., “Understanding the Mirai botnet”, em Proc. 26th USENIX Security Symp., Vancouver, Canadá, 2017, pp. 1093–1110.
  12. M. H. Bhuyan, D. K. Bhattacharyya e J. K. Kalita, “Surveying port scans and their detection methodologies”, Comput. J., vol. 54, nº 10, pp. 1565–1581, out. 2011.
  13. A. Sperotto, G. Schaffrath, R. Sadre, C. Morariu, A. Pras e B. Stiller, “An overview of IP flow-based intrusion detection”, IEEE Commun. Surveys Tuts., vol. 12, nº 3, pp. 343–356, 3º trim. 2010.