Além da 5-tupla
Endereços, portas, protocolo e contadores bastam para detectar um ataque volumétrico. Os campos opcionais do IPFIX respondem às perguntas seguintes: qual cliente de L3VPN está sendo atacado, por qual vizinho BGP o ataque entra e se aquela rajada em UDP/53 é consulta legítima ou reflexão. Isso decide onde mitigar e quem avisar.
Este guia mostra quais campos o EdgeWarden lê, em que tela cada um aparece, o que cada fabricante exporta segundo a própria documentação e como ligar esses campos onde o suporte é confirmado.
Pré-requisitos
- Exportação IPFIX básica funcionando, com o roteador cadastrado em Configurações → Rede → Dispositivos e SNMP ativo. Se ainda não chegou lá, comece pelos guias de Juniper MX, Cisco ou Huawei.
- Rotas BGP no roteador exportador. Sem a rota, ASN e next-hop chegam zerados. O EdgeWarden completa o ASN pela base ip2asn, mas não tem como inventar o next-hop.
- Janela de manutenção: nos passos abaixo você altera records e filtros aplicados às interfaces.
Os campos e as telas
| Campo IPFIX | IE | Onde aparece no EdgeWarden |
|---|---|---|
| ingressVRFID / egressVRFID | 234 / 235 | VRF Visibility e Analisador de Rede |
| bgpSourceAsNumber / bgpDestinationAsNumber | 16 / 17 | Flow Explorer (eixo AS), Análise de AS e Peering Analytics |
| bgpNextHopIPv4Address / bgpNextHopIPv6Address | 18 / 63 | Analisador de Rede, dimensão BGP Next Hop |
| layer2SegmentId (VNI) | 351 | Analisador de Rede, dimensões Tipo Túnel e ID Túnel |
| dataLinkFrameSection | 315 | Aplicações (DPI): TLS SNI, HTTP Host e DNS |
Sem o IE 18 ou o 63, o EdgeWarden usa o next-hop IP comum (IE 15 ou 62). Nesse caso o valor é o próximo salto imediato, não o vizinho que anunciou a rota.
Túneis não exigem campo extra. O EdgeWarden classifica VxLAN (UDP 4789), GENEVE (UDP 6081), L2TP (UDP 1701), MPLS-in-UDP (UDP 6635), GRE e IP-in-IP pelo cabeçalho externo de qualquer flow. O IE 351 só acrescenta o VNI; sem ele, o túnel aparece classificado e com ID vazio.
O que cada fabricante exporta
Resumo do que conferimos na documentação oficial. "Não documentado" quer dizer que não encontramos o campo, não que ele com certeza falte na sua versão.
| Plataforma | VRF (IE 234/235) | ASN e next-hop BGP | Packet section (IE 315) |
|---|---|---|---|
| Cisco IOS XE (Flexible NetFlow) | Sim: match routing vrf input / output | Sim: collect routing | Não documentado |
| Cisco IOS XR | Provável: confira no cache | Sim, no record fixo | ASR 9000: só até o cabeçalho L4 |
| Juniper MX (inline J-Flow) | Não consta no template | Sim: IE 16, 17, 18 e 63 | Sim, por inline monitoring (Junos 19.4R1+) |
| Huawei NE40E/NE8000 | Não confirmado | Sim: origin-as bgp-nexthop | Não documentado |
| MikroTik RouterOS v7 | Não | Não; só o campo gateway | Não |
- Cisco IOS XE: a referência de comandos do Flexible NetFlow não traz comando para o IE 315. O
collect ipv4 section headerexporta o IE 313, que o EdgeWarden ignora quando o registro já traz endereços, e o IE 314 (section payload) não é lido. Por esse caminho não há DPI. - Cisco IOS XR: os exemplos de IPFIX da Cisco para o ASR 9000 mostram
InputVRFID,OutputVRFID,BGPNextHopV6e ASN de origem no cache do monitor. Por padrão o record traz o AS de origem;record ipv4 peer-astroca pelo AS vizinho. Mantenha o padrão: o EdgeWarden espera o AS de origem. O IPFIX 315 do ASR 9000 corta o quadro no cabeçalho L4, funciona só na entrada, em linecards de 3ª e 4ª geração, e não pode ser ligado numa interface que já tem monitores IPv4, IPv6 ou MPLS: o EdgeWarden reconstrói a 5-tupla, mas não há carga útil para extrair SNI, Host ou DNS. - Huawei:
ip netstream export versionaceitaroute-distinguisherapenas no formato 9, não noipfix, e a documentação não diz em qual campo o valor vai. Para ASN e next-hop, useip netstream export version ipfix origin-as bgp-nexthop ttl, como no guia Huawei. - MikroTik: nenhum campo de
/ip traffic-flow ipfixtraz VRF, ASN ou next-hop BGP. Ogatewayé o próximo salto do flow, e o ASN vem da base ip2asn do EdgeWarden.
Passo 1: VRF, ASN e next-hop BGP no Cisco IOS XE
Acrescente os campos aos records do guia Cisco. A Cisco exige tirar o monitor de todas as interfaces antes de alterar o record; depois, reaplique. O exemplo mostra uma interface: repita a remoção e a reaplicação em cada interface onde o monitor está.
interface GigabitEthernet0/0/1
no ip flow monitor EW-MON-V4 sampler EW-SAMP input
no ipv6 flow monitor EW-MON-V6 sampler EW-SAMP input
!
flow record EW-REC-V4
match routing vrf input
collect routing source as 4-octet
collect routing destination as 4-octet
collect routing next-hop address ipv4 bgp
!
flow record EW-REC-V6
collect routing source as 4-octet
collect routing destination as 4-octet
collect routing next-hop address ipv6 bgp
!
interface GigabitEthernet0/0/1
ip flow monitor EW-MON-V4 sampler EW-SAMP input
ipv6 flow monitor EW-MON-V6 sampler EW-SAMP input4-octetexporta o ASN em 4 bytes; sem ele, o campo tem 2 bytes e não comporta ASNs de 32 bits. Não usepeer: ele troca o AS de origem pelo AS vizinho e o exporta em outros campos (IE 128/129), que o EdgeWarden não lê.match routing vrf outputexiste desde o IOS XE 3.8S, mas exige monitoroutput. Somado aoinput, o mesmo pacote é contado duas vezes. Prefira só a VRF de entrada.- O exemplo de VRF da Cisco usa um record IPv4. Se a sua plataforma aceitar, acrescente
match routing vrf inputtambém aoEW-REC-V6. Se recusar alguma linha, remova só ela e confira os campos comshow flow record.
Passo 2: next-hop BGP preciso no Juniper MX
O template IPFIX do MX já traz ASN e next-hop BGP (IE 16, 17, 18 e 63). Quando o destino tem vários caminhos, porém, o next-hop IP (IE 15) e a interface de saída (IE 14) mostram o primeiro caminho da tabela de encaminhamento, e no IPv6 vêm zerados, até você ligar o nexthop-learning. O next-hop BGP tem o mesmo problema com tráfego balanceado entre vários peers BGP: o MX informa o primeiro da lista. A partir do Junos 24.2R1, nos MX240, MX480, MX960, MX2010 e MX2020, o multi-bgp-path informa o vizinho correto, e ele depende do nexthop-learning.
set services flow-monitoring version-ipfix template ew-ipv4 nexthop-learning enable
set services flow-monitoring version-ipfix template ew-ipv6 nexthop-learning enable
set services flow-monitoring version-ipfix template ew-ipv4 multi-bgp-path
set services flow-monitoring version-ipfix template ew-ipv6 multi-bgp-path
commit check
commit confirmed 10
commitEm versões anteriores ao 24.2R1 ou em outros modelos, omita as duas linhas de multi-bgp-path e confira o suporte no Feature Explorer da Juniper. Para IPv6, a Juniper também pede ipv6-extended-attrib na tabela de flows da FPC; a hierarquia aparece de forma diferente em páginas da própria documentação, então confira na sua versão. Com o recurso ligado, o fragmentIdentification (IE 54) passa a valer 0.
Passo 3: packet section para DPI no Juniper MX
O inline monitoring (MX com MPC a partir do Junos 19.4R1; MPC10E e MPC11E a partir do 20.4R1) exporta o pacote amostrado no IE 315, recortado a partir do cabeçalho Ethernet: até 126 bytes no Junos OS, até 256 no Junos OS Evolved. O exemplo amostra só DNS, em que o nome consultado costuma caber no recorte, e HTTP, em que o Host só cabe quando a linha de requisição é curta. Ele cobre IPv4; para IPv6, repita os termos num filtro family inet6.
set services inline-monitoring template ew-im-tpl template-refresh-rate 60
set services inline-monitoring template ew-im-tpl option-template-refresh-rate 60
set services inline-monitoring template ew-im-tpl observation-domain-id 2
set services inline-monitoring instance ew-im template-name ew-im-tpl
set services inline-monitoring instance ew-im maximum-clip-length 126
set services inline-monitoring instance ew-im collector ew-col source-address 198.51.100.1
set services inline-monitoring instance ew-im collector ew-col destination-address 192.0.2.10
set services inline-monitoring instance ew-im collector ew-col destination-port 2055
set services inline-monitoring instance ew-im collector ew-col sampling-rate 1000
set firewall family inet filter EW-IM term dns from protocol udp
set firewall family inet filter EW-IM term dns from port 53
set firewall family inet filter EW-IM term dns then inline-monitoring-instance ew-im
set firewall family inet filter EW-IM term dns then accept
set firewall family inet filter EW-IM term http from protocol tcp
set firewall family inet filter EW-IM term http from destination-port 80
set firewall family inet filter EW-IM term http then inline-monitoring-instance ew-im
set firewall family inet filter EW-IM term http then accept
set firewall family inet filter EW-IM term resto then accept
set interfaces xe-0/0/0 unit 0 family inet filter input EW-IM
commit check
commit confirmed 10
commit- O termo
restoé obrigatório: sem ele, o descarte implícito do filtro derruba todo o resto do tráfego. Se a interface já tem filtro de entrada, acrescente os termos a ele em vez de trocar. - No Junos OS a taxa é por coletor, e a Juniper a anuncia no option data record (IE 34). O EdgeWarden guarda a taxa por exportador e domínio de observação. O
observation-domain-iddefine só o byte mais significativo do domínio (os outros três são gerados pelo roteador); um valor próprio, como o2do exemplo, ajuda a manter a taxa do inline monitoring separada da do J-Flow. - O SNI do TLS costuma ficar além de 126 bytes. Com 256 bytes nem sempre cabe. Para SNI de verdade, use o Packet Sensor ou sFlow com cabeçalho amostrado maior que os 128 bytes padrão, se o equipamento permitir.
Os pacotes que o inline J-Flow já amostra voltam a ser contados pelo inline monitoring. O EdgeWarden não sabe que os dois registros descrevem o mesmo pacote, e o volume de DNS e HTTP daquele roteador sobe. Mantenha o filtro estreito e confira o quadro Fluxo × SNMP nas interfaces na tela Análise do instante.
Conferência no roteador
show flow record EW-REC-V4
show flow monitor name EW-MON-V4 cache format recordshow services inline-monitoring statistics fpc-slot 0No cache do IOS XE, os flows de interfaces em VRF devem mostrar a VRF de entrada e o next-hop BGP preenchidos. No Junos, os contadores do comando devem crescer a cada execução.
Conferência no EdgeWarden
- Em 1 a 2 minutos depois da mudança, abra a tela Flows e filtre pelo exportador
198.51.100.1. - No Analisador de Rede, agrupe por VRF Ingress, BGP Next Hop e Tipo Túnel. Valor zero ou vazio em tudo indica campo ausente no template.
- Em VRF Visibility, cadastre cada ID numérico com nome, RD e cliente. A tela separa o tráfego por instância.
- Em Aplicações (DPI), a coluna Tipo mostra TLS SNI, HTTP ou DNS quando a identificação veio do pacote. DNS Cache indica DNS passivo.
- Se o packet section chegou, o log registra a linha "IPFIX inline monitoring detectado". Acompanhe com
journalctl -u flowspec-core -f.
Armadilhas comuns
- Template antigo no coletor: os campos novos só são decodificados depois que o template novo chega ao coletor. Template refresh curto encurta a espera.
- Interface de saída em outra VRF no MX: segundo a Juniper, máscara de destino, AS de destino, next-hop IP (IE 15) e interface de saída vêm zerados.
- ASN zerado sem tabela completa: o Flow Explorer e a Análise de AS ficam vazios até a base ip2asn ser importada.
- Filtro do inline monitoring pegando IPFIX: a Juniper avisa que amostrar o próprio tráfego IPFIX cria um laço. Não inclua a porta 2055 nos termos.
- Cota da licença: um
source-addressdiferente para o inline monitoring vira outro exportador e ocupa outra vaga.
Packet section carrega pedaços reais de pacotes de clientes, inclusive nomes consultados. Restrinja a 2055/UDP aos IPs dos roteadores e trate esses dados conforme a sua política de privacidade.
Próximos passos
Se nenhum flow chegar, siga o checklist Nenhum flow aparece no EdgeWarden?. Para comparar com o sFlow, que carrega o cabeçalho bruto, veja NetFlow v5, v9, IPFIX ou sFlow?. Para a configuração base, veja os guias de Juniper MX, Cisco, Huawei e MikroTik. Revise portas e buffers no guia de instalação e veja em Recursos como esses campos entram na detecção.