EdgeWarden
O que você vai configurar
O Traffic Flow é o exportador de NetFlow e IPFIX do RouterOS. Neste guia você vai ligá-lo em um MikroTik de borda com RouterOS v7, enviar a exportação para o coletor do EdgeWarden em 192.0.2.10, porta 2055/UDP, e ajustar os poucos parâmetros que decidem se um ataque aparece em segundos ou em meia hora.
O parâmetro que mais pesa na detecção de DDoS é o active-flow-timeout. O padrão do RouterOS é 30 minutos: um flow longo, como uma inundação UDP contínua contra um cliente, só seria reportado ao coletor depois desse tempo. Com 1 minuto, o EdgeWarden recebe o flow e o analisa no ciclo seguinte, que por padrão roda a cada 10 segundos.
Pré-requisitos
- RouterOS v7. Os comandos seguem a documentação oficial da MikroTik para o RouterOS v7.
- EdgeWarden instalado conforme o guia de instalação, com a 2055/UDP liberada para o IP do roteador.
- Um endereço de origem fixo para a exportação, de preferência uma loopback. Neste exemplo:
198.51.100.1. - Cota de exportadores livre na licença (Starter 1, Professional 2, Enterprise 10). Exportador acima da cota é descartado antes do parse, sem erro na tela.
Este guia não cobre o RouterOS v6. Guias muito antigos usam address=192.0.2.10:2055 no target; as versões atuais usam dst-address e port, como nos comandos abaixo. A documentação atual também informa que a amostragem de pacotes é recurso do v7. Em v6, confira cada parâmetro com ? no console antes de aplicar.
Passo 1: ligar o Traffic Flow e ajustar os timeouts
O padrão interfaces=all faz o roteador contabilizar tudo o que passa pela CPU, inclusive tráfego interno que não interessa para a detecção. Informe só os links de trânsito, IX e CDN, separados por vírgula:
/ip traffic-flow set enabled=yes interfaces=sfp-sfpplus1,ether1 cache-entries=256k active-flow-timeout=1m inactive-flow-timeout=15s| Parâmetro | Padrão | Sugestão | Motivo |
|---|---|---|---|
active-flow-timeout | 30m | 1m | Flows longos são exportados a cada minuto. Menor detecta mais rápido e gera mais carga |
inactive-flow-timeout | 15s | 15s | A documentação avisa que valores muito baixos geram flows demais e podem estourar o buffer |
cache-entries | 4k | conforme a RAM | 4k é pouco para borda de ISP; um ataque com origens forjadas cria milhares de flows por segundo |
interfaces | all | links de borda | Menos interfaces, menos CPU |
A latência total da detecção com NetFlow ou IPFIX é o active timeout do roteador somado ao ciclo de análise do EdgeWarden. Se precisar de reação abaixo de um segundo, use sFlow ou o Packet Sensor.
Passo 2: criar o target
O src-address fixa o IP de origem dos pacotes de exportação, e é esse IP que você vai cadastrar no EdgeWarden.
# IPFIX para o coletor, com origem fixa na loopback
/ip traffic-flow target add dst-address=192.0.2.10 port=2055 version=ipfix src-address=198.51.100.1Para NetFlow v9, troque para version=9. Use um único target por coletor: dois targets para o mesmo destino duplicam o volume. O template é reenviado a cada 20 pacotes (v9-template-refresh, padrão); em roteadores com pouco tráfego, defina também v9-template-timeout para o coletor não ficar esperando o template depois de um reinício.
Passo 3: escolher os campos do IPFIX
O menu /ip traffic-flow ipfix liga e desliga cada campo do registro. Confira o estado atual e garanta os campos que os detectores usam:
/ip traffic-flow ipfix print
/ip traffic-flow ipfix set src-address=yes dst-address=yes src-port=yes dst-port=yes protocol=yes bytes=yes packets=yes tcp-flags=yes ttl=yes tos=yes icmp-type=yes icmp-code=yes in-interface=yes out-interface=yes src-address-mask=yes dst-address-mask=yes gateway=yes first-forwarded=yes last-forwarded=yesSem tcp-flags, os detectores de SYN, ACK e RST ficam cegos; sem in-interface e out-interface, o tráfego por interface some. Campos como tcp-seq-num, tcp-ack-num, tcp-window-size e os endereços MAC não são usados na detecção e podem ser desligados para reduzir o tamanho dos registros.
O EdgeWarden percebe quando o exportador não envia um campo e registra no log do serviço qual detector fica inerte. A lista de campos do RouterOS não inclui fragmentação, então espere esse aviso para o detector de Fragment Flood. Se o log também apontar o TTL Variance, é porque o TTL exportado não chega no campo que esse detector lê (minimumTTL, IE 52); os demais detectores seguem funcionando.
Passo 4 (opcional): amostragem
O sampling-interval é o número de pacotes amostrados em sequência e o sampling-space é o número de pacotes ignorados em seguida. Para 1 em cada 1000:
# 1 pacote amostrado, 999 ignorados
/ip traffic-flow set packet-sampling=yes sampling-interval=1 sampling-space=999A taxa efetiva é (interval + space) / interval. Prefira sampling-interval=1: com valores maiores o RouterOS amostra blocos de pacotes seguidos, não pacotes espaçados.
O EdgeWarden multiplica bytes e pacotes pela taxa antes de gravar. Ele usa a taxa anunciada por Options Template quando o roteador a envia; a documentação do RouterOS não descreve esse anúncio, então preencha Taxa de Amostragem de Flow com 1000 no cadastro do dispositivo e confira o selo manual ou detectado na tela. Se o roteador anunciar a taxa, o valor anunciado vence e a tela avisa cadastro: 1:N (ignorado) quando ele diverge do cadastro. Sem amostragem, deixe 1.
Passo 5: SNMP para nomear as interfaces
O flow traz o índice da interface; o nome e a capacidade vêm do SNMP. Libere leitura apenas para o coletor:
/snmp community add name=edgewarden-ro addresses=192.0.2.10/32 read-access=yes write-access=no
/snmp set enabled=yes src-address=198.51.100.1
/interface print oidNo print oid, o último número de cada OID é o ifIndex da interface. Para SNMPv3, a community aceita security=private com autenticação e criptografia, e o EdgeWarden suporta v3 no cadastro. Revise também a community padrão public, que a própria MikroTik considera insegura: restrinja os endereços dela ou desative-a.
Verificação no roteador
/ip traffic-flow print
/ip traffic-flow target print
/tool sniffer quick ip-address=192.0.2.10 port=2055Os dois print devem mostrar enabled: yes, as interfaces e os timeouts escolhidos, e o target com 192.0.2.10, porta 2055. O sniffer quick mostra os pacotes saindo para o coletor; interrompa com Ctrl+C.
Verificação no EdgeWarden
No servidor, confirme primeiro que os pacotes chegam do IP certo:
sudo tcpdump -i any -n -c 5 udp port 2055 and host 198.51.100.1
10:15:02.481233 ens18 In IP 198.51.100.1.40312 > 192.0.2.10.2055: UDP, length 1372
sudo journalctl -u flowspec-core -fDepois, na interface web:
- Em Configurações → Rede → Dispositivos, cadastre o roteador com Endereço IP
198.51.100.1(o mesmosrc-addressdo target), a community SNMP e a taxa de amostragem. - Em 1 a 2 minutos os flows aparecem na tela Flows. Em Tráfego → Interfaces, os nomes devem aparecer como
sfp-sfpplus1, não comoif:12. - Compare o volume de uma interface movimentada com o contador SNMP no painel Fluxo × SNMP nas interfaces, da tela Análise do instante. Se o flow mostrar 1/N do SNMP, a taxa está faltando; se mostrar N vezes, foi aplicada duas vezes.
Quem alcança a 2055/UDP pode injetar flows forjados. Restrinja por origem: sudo ufw allow from 198.51.100.1 to any port 2055 proto udp.
Armadilhas comuns
Pela documentação da MikroTik, pacotes em FastTrack não passam pelo ip traffic-flow, e o Traffic Flow só vê o que passa pela CPU: tráfego com offload em hardware (roteamento L3HW no switch chip, bridge com offload) não vira flow.
- FastTrack ligado na borda. A configuração padrão de muitos equipamentos tem uma regra
action=fasttrack-connectionna chain forward. Só uma parte dos pacotes dessas conexões passa pelo caminho normal; o volume fica muito abaixo do SNMP e a linha de base do tráfego legítimo fica distorcida. Localize a regra com/ip firewall filter print where action=fasttrack-connectione decida se ela deve existir no roteador de borda. - L3HW em CRS3xx, CRS5xx, CCR2116 e CCR2216. Com
l3-hw-offloadingativo, o switch chip roteia sem a CPU e, segundo a MikroTik, esse tráfego não é reportado pelo Traffic Flow. Se o volume não bate com o SNMP, confira esse recurso antes de mexer na taxa. - Porta espelhada. Espelhar tráfego de um switch para o MikroTik não funciona: os pacotes espelhados são descartados antes da chain input.
- Carga de CPU. O Traffic Flow processa cada pacote na CPU. Acompanhe com
/tool profile cpu=totaldurante o pico; se a CPU apertar, reduza as interfaces ou use amostragem. - IP de origem diferente do cadastro. Sem
src-address, a exportação sai com o IP da interface de saída. O EdgeWarden não casa os flows com o dispositivo e as interfaces ficam sem nome. - Timeout padrão de 30 minutos. É a causa mais comum de "o ataque só apareceu depois que acabou".
Próximos passos
Se os flows não aparecerem depois desses passos, siga o roteiro de diagnóstico de flows que não aparecem, da captura no servidor até a cota da licença. Para escolher a taxa de amostragem e os timeouts com mais critério, leia amostragem e timeouts sem perder ataques. Para revisar portas e serviços do coletor, volte ao guia de instalação, e veja em Recursos como o EdgeWarden usa esses flows para detectar e mitigar ataques.