🚨 FastFlowIPs

Como tudo começou

Open-source ou não open-source - eis a questão.

O dilema eterno entre pegar algo pronto e construir o seu próprio só se tornou mais agudo na era das ferramentas infinitas de IA. Mas você realmente deveria escrever algo você mesmo? Não há resposta universal. No entanto, se você jogar seus medos em /dev/null, a ideia não parece mais tão louca.

Nossa história começou com uma atualização do VyOS em roteadores de produção para 1.5.x (circinus). Após esse processo já estressante, descobrimos que parte das nossas regras de firewall havia silenciosamente se auto-deletado. E a parte engraçada - era a mesma parte específica em cada roteador. Então relutantemente abrimos VyOS Project Updates, onde esbarramos nisto: FastNetMon-based service ids ddos-protection is removed from rolling and deprecated in LTS releases (T7241):

For quite a while, we had a CLI for configuring FastNetMon — a DDoS detection daemon. However, that integration was never especially deep, and we do not see a path to significant improvement.
The long-term plan is to move FastNetMon to an addon, once we finalize a mechanism for allowing addons to extend the system CLI. As for built-in components, the approach will be “quality over quantity” — it’s better to have a smaller number of integrations that serve a large number of users and play well together, but to provide an option for everyone to install or develop integrations for their own needs.

O problema não era extremamente urgente ou crítico, mas como corretor IPv4 e provedor de hospedagem, precisávamos de tal monitoramento. Portanto, decidimos agir imediatamente.

Após passar pelo ciclo típico - negação, raiva, barganha - finalmente aceitamos a perda de service ids ddos-protection e tentamos ressuscitar o FastNetMon Community manualmente. Foi aí que a depressão começou. A versão Community se recusava a instalar por razões que, sejamos honestos, todos já suspeitavam. E ninguém estava com pressa de comprar a versão comercial.

O problema não era catastrófico, mas para nós como corretor IPv4 e provedor de hospedagem, tal monitoramento era essencial. Então a decisão foi clara: agir imediatamente.

FastNetMon: nós te amamos, mas…

Nosso relacionamento com FastNetMon começou não há muito tempo, mas a ferramenta rapidamente conquistou nossos corações e entregou valor real - mesmo que consistentemente devorasse cerca de 30% da nossa CPU.

A visibilidade do tráfego era perfeita, Grafana brilhava com métricas, e a vida parecia um pouco mais pacífica. E agora? Agora estamos encarando dashboards de tráfego vazios e, por alguma razão, voluntariamente escolhendo a rota “tornar a vida mais difícil”. Bem… não voluntariamente. Mais como à força. E como sempre, você só começa a lembrar de todas as falhas quando perde algo.

FastNetMon geralmente atendia às nossas expectativas - e até as superava. Mas apesar de todos os seus benefícios, coletava uma pilha massiva de dados absolutamente desnecessários, transformando dashboards em um carnaval barulhento de números e gráficos. E depois havia aquela carga de CPU - não catastrófica, mas irritante o suficiente. Então nunca formamos um “sim” ou “não” firme. A alma ansiava por simplicidade e leveza, não mais uma assinatura e ajustes finos toda vez que a ferramenta espirrasse.

A ideia de construir nossa própria ferramenta não veio instantaneamente. A batalha pelo FastNetMon continuou - até tentamos revivê-lo puxando um binário antigo de outro servidor. Sim, foi uma abordagem meio questionável, mas funcionou: FastNetMon voltou à vida. Exceto… não havia alegria nisso.

Parecia que tínhamos costurado uma versão taxidermizada de um animal de estimação morto há muito tempo: tecnicamente em pé, vagamente reconhecível, mas viver com isso era… perturbador.

Então concordamos coletivamente: isso não pode continuar. E foi aí que começamos a construir nosso próprio protetor DDoS alimentado por monitoramento com blackjack e carga mínima de CPU.

E então as coisas escalaram

Assim começou o desenvolvimento da nossa própria ferramenta. As mentes mais brilhantes da equipe mais alguns modelos de IA, é claro, se juntaram à sessão de brainstorming, e foi assim que nasceu FastFlowIPs. FastFlowIPs é uma ferramenta de monitoramento de rede de alto desempenho baseada em eBPF que rastreia estatísticas de tráfego por IP em tempo real. Foi projetada para ambientes de produção com overhead mínimo.

A ideia central é simples: captura tráfego de rede via eBPF, calcula estatísticas por IP (PPS, Mbps), e pode automaticamente bloquear endereços IP que excedem limites configuráveis. Métricas são exportadas via protocolo Graphite e se encaixam perfeitamente com as expectativas do Grafana. Os dashboards resultantes são limpos, leves e rápidos de configurar.

FastFlowIPs executa com uma única linha onde você especifica -min-ips-pps e -min-flow-pps para exportar apenas as métricas mais significativas, além da rede e interface para monitorar. O único requisito must-have é definir explicitamente -graphite-host e -graphite-port se você quiser enviar métricas.

Além disso, FastFlowIPs é otimizado para redes de alta carga: 75% menos operações mutex, 60% mais rápido no manuseio de strings comparado a implementações típicas.

Um exemplo de configuração é mostrado abaixo:

# Interface and basics
-interface eth0              # Network interface (default: eth0)
-interval 5s                 # Collection interval
-show-stats                  # Display periodic tables
-verbose                     # Detailed logging

# Network filtering
-networks "192.168.1.0/24"   # Monitor specific networks only

# IP banning thresholds
-ban-pps-rx 1000             # Ban if receiving > 1000 PPS
-ban-pps-tx 500              # Ban if sending > 500 PPS
-ban-mbps-rx 100             # Ban if receiving > 100 Mbps
-ban-mbps-tx 50              # Ban if sending > 50 Mbps
-ban-time 5m                 # How long to ban
-ban-script /path/script.sh  # Script to execute on ban/unban

# Graphite export
-graphite-host localhost     # Graphite server
-graphite-port 32003         # Graphite port
-min-flow-pps 10             # Only export flows > 10 PPS
-min-ips-pps 5               # Only export IPs > 5 PPS

Não havia como pular os Modos de Monitoramento - eles permitem ajustar esta ferramenta modesta ao seu gosto pessoal:

• Modo silencioso (padrão): mostra apenas eventos de banimento e mensagens de inicialização. Perfeito para produção.
• Modo stats (-show-stats): imprime tabelas periódicas de tráfego, ordenadas por volume.
• Modo verbose (-verbose): log detalhado, incluindo estatísticas de exportação do Graphite.

E a cereja do bolo - o script de banimento, que bloqueia impiedosamente qualquer atividade suspeita que cruze os limites definidos:

/path/to/script.sh ban 192.168.1.100    # IP exceeded threshold
/path/to/script.sh unban 192.168.1.100  # Ban expired

Um exemplo simples usando iptables:

#!/bin/bash
case $1 in
  ban)   iptables -I INPUT -s $2 -j DROP ;;
  unban) iptables -D INPUT -s $2 -j DROP 2>/dev/null ;;
esac

Mas em todo caso, você sempre pode ajustar o script e torná-lo mais ou menos agressivo - seja lá o que sua infraestrutura exigir.

E algumas palavras sobre Graphite e métricas. Um dashboard do Grafana pode ser construído em apenas alguns minutos usando dois tipos principais de métricas:

Métricas de fluxo: **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
Métricas de IP: **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}**

Você pode encontrar mais detalhes sobre FastFlowIPs no próprio repositório: https://github.com/denisix/fastflowips e sempre pode apoiar o autor ou contribuir para a evolução desta ferramenta pequena mas já poderosa.

Arquitetura em 3 parágrafos (sem o sofrimento)

Se descrevermos a ferramenta em linguagem humana, por dentro é um pequeno serviço Go arrumado que escuta pacotes NetFlow, os analisa em componentes, e constrói estatísticas simples por IP: pps, mbps, entrada/saída - basicamente, quem está fazendo barulho na rede e por quê. Toda a matemática é feita em tempo real - Go é perfeito para operações leves mas de alto throughput como esta.

Os dados são agregados em pequenas estruturas na memória, ordenados, e periodicamente enviados para fora: seja para Graphite/Grafana, ou para qualquer outro destino que você especificar. Bloqueio de IP via script externo é implementado através de limites PPS/Mbps e uma chamada para BanScript - só no caso de alguém de repente decidir hospedar um pequeno festival DDoS local.

A melhor parte: é um binário único e limpo sem pilha de dependências e sem o usual “inferno de pequeno negócio open-source”. Configurações são passadas via flags, estatísticas são coletadas diretamente, a lógica é transparente. No final, obtivemos uma ferramenta leve e honesta que faz exatamente o que precisamos - sem magia excessiva, sem demônios pesados anexados.

Resultados após alguns dias

O processo de debugging se mostrou muito mais longo e complicado que escrever a própria ferramenta. Inicialmente, nem planejávamos definir valores de limite para FastFlowIPs, então várias vezes (muitas) Grafana nervosamente prendeu a respiração sob o volume puro de métricas e se recusou a nos mostrá-las. A legenda do dashboard continha tantos endereços IP que você poderia rolar por horas e provavelmente nunca chegar ao fim. Calculamos mal - mas onde?

O debugging continuava quebrando coisas, depois estabilizando-as, depois quebrando nosso FastFlowIPs exausto novamente, até que começou a chorar silenciosamente em cenários de casos extremos. Havia ou métricas demais, ou muito poucas, ou nenhuma. Aparentemente por sobrecarga emocional. Além disso, o maior mistério para nós se mostraram as métricas Flows RX/TX, que se trocaram ligeiramente, algo que era lindamente visível em tempo real nos roteadores VyOS. As mentes mais brilhantes da nossa equipe lutaram com isso, e eventualmente o objetivo foi alcançado: as métricas foram estabilizadas, e Grafana foi curado de sua asma.

Hoje, temos métricas arrumadas, organizadas e informativas que mostram exatamente o tráfego de rede que precisamos:

Quando é hora de construir seu próprio mini-FastNetMon

Construir suas próprias bicicletas é ruim. Até o momento em que você simplesmente não consegue seguir em frente sem uma.

Escrever sua própria ferramenta absolutamente faz sentido quando as soluções existentes são muito pesadas ou muito inteligentes para sua tarefa específica. Quando você não precisa de 100500 recursos, integrações com uma estação espacial, e dashboards em 19 monitores - quando você só precisa de números, rapidamente e sem dores de cabeça.

Você também deveria considerar desenvolver sua própria solução se a situação demanda flexibilidade: você precisa adicionar uma métrica rapidamente, incorporar lógica anti-DDoS customizada, fazer o monitoramento funcionar bem com seu hardware peculiar, ou simplesmente contornar limitações que foram repentinamente removidas do seu firmware favorito (um caloroso olá para VyOS 1.5).

Em resumo, construir sua própria ferramenta é sobre controle, velocidade, minimalismo, e não depender de componentes que de repente desaparecem dos repositórios. O principal é lembrar da regra dourada: se pode ser feito mais simples - faça mais simples.

E mais uma regra: se funciona - não mexa.

O grande final

No final, toda essa história não é sobre tráfego, DDoS, ou mesmo FastNetMon. É sobre o fato de que às vezes uma equipe simplesmente quer uma ferramenta que funciona, não quebra após uma atualização, e não transforma sua vida em uma reprise de Um Sonho de Liberdade.

Não reinventamos a bicicleta - construímos nosso próprio pequeno scooter que se adapta perfeitamente à nossa estrada. E não há nada de errado nisso. Em um mundo onde projetos massivos de código aberto vivem suas próprias vidas imprevisíveis, é bom ter algo próprio - familiar, estável, e maravilhosamente entediante.

Então se você já olhou para mais uma ferramenta “perfeita mas um pouco perfeita demais” e pensou: “honestamente, seria mais fácil escrever eu mesmo” - você pode estar no caminho certo. Apenas faça isso inteligentemente, com testes… e prepare-se para sofrer um pouco.