Os dados de fluxo clássicos mostram a rede. Explicar o tráfego moderno de aplicações requer contexto L7.
O NetFlow clássico e a análise de fluxo normalmente dependem de campos L3/L4 — IP de origem, IP de destino, porta, protocolo e contagem de bytes. Esses dados são valiosos para capacidade de rede e direção do tráfego, mas no tráfego moderno HTTP e de API não conseguem responder à pergunta "o que aconteceu?" por conta própria. Centenas de hosts, paths, métodos e comportamentos de aplicação diferentes podem compartilhar o mesmo IP e porta.
As equipes de operações e segurança podem ver volumes de tráfego altos na tela do coletor de fluxo, mas se não conseguem ver qual URL, método, código de status ou contexto do cliente gerou esse tráfego, a análise permanece incompleta. O contexto L7 é necessário para planejamento de capacidade, análise de DDoS, relatórios de escopo PCI e auditoria em nível de requisição.
Fechar essa lacuna com uma probe de fluxo separada ou camada de coletor externa é possível, mas adiciona trabalho de instalação, manutenção separada, um modelo de alta disponibilidade separado e overhead de monitoramento separado. Quando o tráfego de aplicações já está atravessando a camada ADC/WAAP, reproduzir o mesmo contexto em um ponto diferente é operacionalmente ineficiente.
A abordagem correta é produzir exportações de fluxo no ponto de trânsito do tráfego e entregá-las a sistemas externos no formato padrão IPFIX / NetFlow. Os campos padrão preservam a visibilidade da rede enquanto os campos Enterprise IE adicionam contexto HTTP. Os sistemas de análise de fluxo podem então responder não apenas "qual IP conversou quanto?" mas também "qual path, qual resposta e qual contexto do cliente estava envolvido?"
A Exportação Nativa IPFIX / NetFlow do TR7 combina campos IPFIX padrão com campos Enterprise IE do TR7, produzindo registros de fluxo enriquecidos com L7 tanto das fases de requisição quanto de resposta.
Nossa abordagem
O TR7 remove a exportação de fluxo do papel de uma probe externa e a implementa como uma camada de observabilidade nativa dentro do caminho de dados ADC/WAAP.
Biblioteca C nativa e wrapper Lua produzem registros de fluxo
Elementos de informação padrão e enterprise são preparados pela biblioteca nativa. O wrapper Lua coleta os valores necessários das fases de requisição e resposta e os converte em registros IPFIX.
Hooks de requisição e resposta capturam o contexto L7
No lado da requisição, host, path, query, método, headers e dados de bytes enviados são coletados. No lado da resposta, código de status, content-type da resposta, bytes baixados e estado de terminação completam o registro de fluxo.
O modelo de template IPFIX garante compatibilidade com coletores padrão
O formato IPFIX v10 usa conjuntos de templates e IDs de template para definir campos de fluxo para sistemas externos. Esse modelo permite que os coletores analisem campos corretamente e mantém compatibilidade com ferramentas de análise de fluxo padrão.
Os campos Enterprise IE levam detalhes HTTP para o formato de fluxo
Sob o Enterprise Number 57011 do TR7, campos personalizados são definidos para contagens de bytes de upload/download, query de requisição, X-Forwarded-For, Referer, Cookie, content-type de resposta e estado de terminação. Os dados de fluxo clássicos são enriquecidos com contexto L7 por meio desse mecanismo.
Capacidades
A exportação IPFIX / NetFlow combina campos de rede padrão com detalhes de requisição/resposta HTTP, enviando registros de fluxo enriquecidos para sistemas coletores.
sFlow® — a vista de interface que o IPFIX não lhe pode dar
Os registos IPFIX são de âmbito de serviço: dizem o que uma aplicação publicada está a transportar. O sFlow® é de âmbito de interface e diz o que o cabo está a transportar, incluindo tráfego que nunca chega a um vService. A taxa de amostragem e o intervalo de sondagem são configuráveis e, como o sFlow® não mantém tabela de fluxos, o exportador não se torna o estrangulamento durante um ataque: o sinal chega em segundos, exatamente quando um exportador baseado em fluxos estaria em dificuldades. Alimente ambos no coletor que já tem a funcionar. (sFlow® é uma marca registada da InMon Corp.)
Endereços de origem e destino IPv4 e IPv6 são exportados usando campos IPFIX padrão
O TR7 pode exportar sourceIPv4Address, destinationIPv4Address, sourceIPv6Address e destinationIPv6Address usando elementos de informação IPFIX padrão. O tráfego IPv4 e IPv6 são visíveis dentro do escopo de análise de fluxo. Ambientes dual-stack não ficam limitados a análise somente IPv4. A visibilidade de rede de origem e destino é preservada no lado do coletor por meio de campos padrão.
As portas de transporte de origem e destino completam a correlação de fluxo
Os campos sourceTransportPort e destinationTransportPort são incluídos no registro de fluxo. Esses campos são importantes na análise em nível de rede para conexões de clientes, portas VIP e acesso a serviços. Combinados com o contexto HTTP, torna-se possível ver qual path de aplicação está rodando sobre qual porta. A análise de capacidade e anomalia se torna mais significativa.
Host HTTP, path, método e versão são adicionados ao registro de fluxo
Campos HTTP padrão como httpRequestHost, httpRequestPath, httpRequestMethod e httpMessageVersion elevam o registro de fluxo ao nível L7. Hosts ou paths diferentes chegando no mesmo IP e porta podem ser distinguidos. Isso fornece visibilidade crítica em ambientes de serviço virtual e multi-aplicação. A análise de fluxo já não vê apenas a conexão — ela vê o contexto da requisição da aplicação.
O código de status HTTP e o content-type tornam o comportamento da resposta visível
O campo httpStatusCode indica se a resposta foi um sucesso, redirecionamento, erro do cliente ou erro do servidor. Os campos de content-type da requisição e da resposta ajudam a analisar o tipo de dados sendo transferidos. Essas informações são especialmente valiosas para análise de taxa de erros, inspeção de comportamento de API e investigação de tráfego baseada em tipo de dados. As tendências de erros L7 podem ser lidas com mais clareza no coletor de fluxo.
Os campos User-Agent, Referer e Cookie fornecem contexto do cliente
Os campos httpUserAgent, httpReferrer e httpCookie permitem análise mais detalhada do comportamento do cliente. Esses campos podem ser usados para análise de bots, inspeção de fluxo do usuário e diferenciação de tipo de cliente. O campo Cookie pode conter dados sensíveis, portanto a política de exportação deve ser projetada cuidadosamente. Deve ser habilitado apenas para ambientes seguros e alvos coletores limitados quando necessário.
Os campos de bytes enviados e baixados medem o payload da aplicação
O Enterprise IE do TR7 inclui os campos uploadedBytes e downloadedBytes. Esses campos permitem que o volume do corpo da requisição e da resposta seja medido no nível de fluxo. Não apenas a contagem total de bytes de conexão, mas o fluxo de dados direcional da aplicação pode ser analisado. Essa visibilidade é valiosa em casos como grandes uploads, downloads anormais ou suspeita de exfiltração de dados.
Os campos Query e X-Forwarded-For carregam o contexto real da requisição
O campo httpRequestQuery adiciona parâmetros de query além do path no registro de fluxo. O campo httpXForwardedFor ajuda a analisar o IP real do cliente atrás de uma cadeia de proxies. Ambos os campos são particularmente úteis ao correlacionar logs de aplicação com registros de fluxo. O contexto da requisição se torna mais completo em investigações de segurança e conformidade.
O código de estado de terminação leva o comportamento de fechamento da conexão ao coletor
O campo httpTerminationStateCode fornece um sinal adicional sobre como a conexão terminou. Fechamento normal, erro, interrupção ou terminação inesperada podem ser diferenciados na análise de fluxo. Essas informações ajudam na avaliação conjunta de problemas de camada de rede e aplicação. É um campo valioso para equipes SRE durante a análise de causa raiz de erros.
O Enterprise Number 57011 do TR7 adiciona campos personalizados ao IPFIX padrão
Os campos Enterprise IE são definidos sob o Enterprise Number 57011 do TR7. Essa estrutura não quebra a compatibilidade IPFIX padrão; ela carrega campos personalizados de forma claramente analisável. Quando o lado do coletor é configurado para reconhecer esses campos, os detalhes L7 ficam disponíveis nos dashboards de fluxo. Campos padrão e personalizados são combinados no mesmo registro de exportação.
A compatibilidade com IPFIX v10 e NetFlow v9 preserva os investimentos em coletores existentes
A abordagem de exportação do TR7 é construída sobre IPFIX v10 e suporta um caminho retrocompatível com NetFlow v9. Isso torna a integração com os investimentos existentes de coletor de fluxo e visibilidade de rede das organizações simples. Em vez de aprender um novo formato de log personalizado, o ecossistema de fluxo padrão pode ser utilizado. O enriquecimento L7 chega como camada de valor adicional do TR7.
Profundidade operacional
A exportação IPFIX / NetFlow opera juntamente com a estrutura de template, campos enterprise, comportamento de transporte, ordem de bytes e dependências de build.
Versão e template IPFIX
O valor da versão IPFIX é 10. O Template Set ID é 2 e o Template ID é 256. Esse template informa ao coletor quais campos chegarão e em qual ordem.
Estrutura do header IPFIX
O header IPFIX consiste nos campos version, length, exportTime, sequenceNumber e observationDomainId. O comprimento total do header é 16 bytes. Essa estrutura fornece o frame base para compatibilidade com coletores IPFIX padrão.
Enterprise Number
Os elementos de informação personalizados do TR7 são carregados sob o Enterprise Number 57011. Os campos uploadedBytes, downloadedBytes, httpRequestQuery, httpXForwardedFor, httpReferrer, httpCookie, httpResponseContentType e httpTerminationStateCode são definidos nesse escopo. Os campos L7 não padrão são explicitamente diferenciados por meio desse mecanismo.
Transporte padrão
O transporte padrão para exportação é UDP. A porta do coletor é configurável para valores como 4779 ou 2055 dependendo dos requisitos do ambiente. O UDP é um modelo de transporte de baixo overhead amplamente usado; para ambientes que requerem garantias de entrega, a arquitetura do coletor deve ser planejada adequadamente.
Ordem de bytes de rede
Os campos de múltiplos bytes são transmitidos usando a ordem de bytes de rede. Esse comportamento é crítico para a análise correta de campos de porta, comprimento, template e contador. A compatibilidade do coletor depende fortemente dessa codificação padrão.
Modelo de build da biblioteca
A biblioteca C nativa é compilada como biblioteca compartilhada para integração Lua. O ambiente de build requer pacotes de desenvolvimento Lua, pkg-config e ferramentas de compilação. A biblioteca resultante é chamada pelo wrapper Lua para produzir registros de fluxo.
Quando usar
Visibilidade L7 na análise de fluxo de provedores de serviço
Um provedor de serviços recebendo exportação IPFIX do TR7 pode visualizar detalhes de host HTTP, path e código de status em seu sistema de análise de fluxo existente. A análise clássica de IP/porta é estendida com contexto L7. A investigação de capacidade e anomalia se torna mais significativa.
Auditoria em nível de requisição para conformidade financeira
As instituições financeiras podem exportar cada requisição HTTP como um registro de fluxo para sistemas externos. Campos de host, path, método, código de status e bytes podem ser correlacionados com um SIEM ou coletor de fluxo. As questões de auditoria sobre qual tráfego fluiu por qual path de aplicação são respondidas com mais clareza.
Análise de bytes e código de status na detecção de DDoS
As equipes de segurança podem usar os valores de bytes enviados/baixados e a distribuição de código de status HTTP dos registros de fluxo para detecção de anomalias. Uploads repentinamente altos, downloads anormais ou padrões densos de 4xx/5xx podem ser monitorados no coletor. O TR7 leva sinais L7 para a camada de fluxo para análise de ataques.
Trilha de tráfego baseada em URL para relatórios de escopo PCI
Os paths de aplicação dentro do escopo de dados do titular do cartão podem ser rastreados com contexto de host e URL dentro da exportação de fluxo. As equipes de auditoria recebem evidências de tráfego baseadas no path HTTP relevante em vez de apenas IP/porta. Isso fortalece os processos de determinação de escopo e criação de trilha de auditoria.
Drill-down em nível de path L7 para planejamento de capacidade
As equipes de operações podem visualizar o volume de tráfego por path HTTP em vez de apenas IP/porta em seu sistema de análise de fluxo existente. Qual endpoint carrega que carga pode ser analisado em maior detalhe. Essa visibilidade suporta o planejamento de recursos e decisões de crescimento.
Perguntas frequentes
Quais versões IPFIX e NetFlow o TR7 suporta?
Os campos Enterprise IE funcionam com coletores IPFIX padrão?
Quantos elementos de informação IPFIX (IEs) podem ser exportados no total?
Qual protocolo de transporte é usado para exportação de fluxo?
Como a segurança dos dados é mantida quando o campo Cookie é exportado?
É necessária uma probe de fluxo separada ou instalação de software adicional?
Fortaleça sua análise de fluxo com visibilidade L7
Exportação nativa compatível com IPFIX v10 e NetFlow v9 — registros de fluxo enriquecidos com HTTP sem uma probe separada. Vamos fazer um tour ao vivo na sua própria infraestrutura de coletor.