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.
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.
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.
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 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.
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.
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.
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.
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.
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 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 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.
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.
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 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.