🚨 FastFlowIPs

Jak to się wszystko zaczęło

Open-source czy nie open-source - oto jest pytanie.

Wieczna dylema między wzięciem czegoś gotowego a zbudowaniem własnego stała się jeszcze bardziej ostra w erze nieskończonych narzędzi AI. Ale czy naprawdę powinieneś napisać coś sam? Nie ma uniwersalnej odpowiedzi. Jednak jeśli wrzucisz swoje obawy do /dev/null, pomysł nie wydaje się już tak szalony.

Nasza historia zaczęła się od aktualizacji VyOS na routerach produkcyjnych do wersji 1.5.x (circinus). Po tym i tak już stresującym procesie odkryliśmy, że część naszych reguł firewalla po cichu się samo-usunęła. I zabawna część - była to ta sama konkretna część na każdym routerze. Więc niechętnie otworzyliśmy VyOS Project Updates, gdzie natknęliśmy się na to: 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.

Problem nie był skrajnie pilny ani krytyczny, ale jako broker IPv4 i dostawca hostingu potrzebowaliśmy takiego monitoringu. Dlatego zdecydowaliśmy działać natychmiast.

Po przejściu przez typowy cykl - zaprzeczanie, złość, targowanie się - w końcu zaakceptowaliśmy utratę service ids ddos-protection i próbowaliśmy wskrzesić FastNetMon Community ręcznie. Wtedy przyszła depresja. Wersja Community odmawiała instalacji z powodów, które, bądźmy szczerzy, wszyscy już podejrzewali. I nikt się nie spieszył z kupnem wersji komercyjnej.

Problem nie był katastroficzny, ale dla nas jako broker IPv4 i dostawca hostingu taki monitoring był niezbędny. Więc decyzja była jasna: działać natychmiast.

FastNetMon: kochamy cię, ale…

Nasza relacja z FastNetMon zaczęła się nie tak dawno, ale narzędzie szybko podbiło nasze serca i dostarczało prawdziwej wartości - nawet jeśli konsekwentnie pożerało około 30% naszego CPU.

Widoczność ruchu była perfekcyjna, Grafana świeciła metrykami, a życie wydawało się trochę spokojniejsze. A teraz? Teraz wpatrujemy się w puste dashboardy ruchu i z jakiegoś powodu dobrowolnie wybieramy trasę “utrudnij sobie życie”. Cóż… nie dobrowolnie. Raczej siłą. I jak zawsze, zaczynasz pamiętać wszystkie wady dopiero gdy coś stracisz.

FastNetMon ogólnie spełniał nasze oczekiwania - a nawet je przewyższał. Ale przy wszystkich swoich zaletach zbierał masywną kupę absolutnie niepotrzebnych danych, zamieniając dashboardy w hałaśliwy karnawał liczb i wykresów. A potem było to obciążenie CPU - nie katastroficzne, ale wystarczająco irytujące. Więc nigdy nie wydaliśmy zdecydowanego “tak” lub “nie”. Dusza pragnęła prostoty i lekkości, a nie kolejnej subskrypcji i dostrajania za każdym razem, gdy narzędzie kichnie.

Pomysł zbudowania własnego narzędzia nie przyszedł natychmiast. Bitwa o FastNetMon trwała dalej - próbowaliśmy nawet go wskrzesić, wyciągając stary binarny plik z innego serwera. Tak, to było trochę wątpliwe podejście, ale zadziałało: FastNetMon ożył. Tylko… nie było w tym radości.

Czuło się jak gdybyśmy zszyliśmy wytaksydermowaną wersję dawno zmarłego pupila: technicznie stojącą, mgliste rozpoznawalną, ale życie z tym było… niepokojące.

Więc zbiorowo się zgodziliśmy: to nie może tak dalej. I wtedy zaczęliśmy budować własny protektor DDoS zasilany monitoringiem z blackjackiem i minimalnym obciążeniem CPU.

I wtedy sprawy się zaostrzyły

Tak zaczął się rozwój naszego własnego narzędzia. Najjaśniejsze umysły zespołu plus kilka modeli AI, oczywiście, dołączyło do sesji burzy mózgów, i tak narodził się FastFlowIPs. FastFlowIPs to wysokowydajne narzędzie monitoringu sieciowego oparte na eBPF, które śledzi statystyki ruchu per-IP w czasie rzeczywistym. Zostało zaprojektowane dla środowisk produkcyjnych z minimalnym narzutem.

Główna idea jest prosta: przechwytuje ruch sieciowy przez eBPF, oblicza statystyki per-IP (PPS, Mbps), i może automatycznie blokować adresy IP, które przekraczają konfigurowalne progi. Metryki są eksportowane przez protokół Graphite i idealnie pasują do oczekiwań Grafany. Wynikowe dashboardy są czyste, lekkie i szybkie do skonfigurowania.

FastFlowIPs uruchamia się jedną linią, gdzie określasz -min-ips-pps i -min-flow-pps żeby eksportować tylko najważniejsze metryki, plus sieć i interfejs do monitorowania. Jedynym wymogiem must-have jest wyraźne ustawienie -graphite-host i -graphite-port jeśli chcesz wysyłać metryki.

Ponadto, FastFlowIPs jest zoptymalizowany dla sieci wysokiego obciążenia: 75% mniej operacji mutex, 60% szybsze przetwarzanie stringów w porównaniu z typowymi implementacjami.

Przykład konfiguracji pokazany jest poniżej:

# 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

Nie było sposobu na pominięcie Trybów Monitoringu - pozwalają one dostroić to skromne narzędzie do twojego osobistego gustu:

• Tryb cichy (domyślny): pokazuje tylko zdarzenia banowania i komunikaty startowe. Idealny do produkcji.
• Tryb statystyk (-show-stats): wypisuje okresowe tabele ruchu, posortowane według objętości.
• Tryb gadatliwy (-verbose): szczegółowe logowanie, włączając statystyki eksportu Graphite.

I wisienka na torcie - skrypt banowania, który bezwzględnie blokuje wszelką podejrzaną aktywność przekraczającą określone progi:

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

Prosty przykład używający 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

Ale w każdym przypadku zawsze możesz dostosować skrypt i uczynić go bardziej lub mniej agresywnym - cokolwiek wymaga twoja infrastruktura.

I kilka słów o Graphite i metrykach. Dashboard Grafany może być zbudowany w ciągu kilku minut używając dwóch głównych typów metryk:

Metryki przepływu: **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
Metryki IP: **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}**

Więcej szczegółów o FastFlowIPs znajdziesz w samym repozytorium: https://github.com/denisix/fastflowips i zawsze możesz wesprzeć autora lub przyczynić się do ewolucji tego małego ale już potężnego narzędzia.

Architektura w 3 akapitach (bez cierpienia)

Jeśli opiszemy narzędzie ludzkim językiem, w środku to schludny mały serwis Go, który nasłuchuje pakietów NetFlow, analizuje je na komponenty, i buduje proste statystyki per-IP: pps, mbps, przychodzące/wychodzące - w zasadzie, kto robi hałas w sieci i dlaczego. Cała matematyka jest robiona w locie - Go jest idealne dla lekkich ale wysokowydajnych operacji takich jak ta.

Dane są agregowane w małych strukturach w pamięci, sortowane, i okresowo wysyłane na zewnątrz: albo do Graphite/Grafana, albo do jakiegokolwiek innego odbiornika który określisz. Blokowanie IP przez zewnętrzny skrypt jest implementowane przez progi PPS/Mbps i wywołanie BanScript - na wypadek gdyby ktoś nagle zdecydował się zorganizować mały lokalny festiwal DDoS.

Najlepsza część: to pojedynczy czysty binarny plik bez kupy zależności i bez zwykłego “piekła małego biznesu open-source”. Konfiguracje są przekazywane przez flagi, statystyki są zbierane bezpośrednio, logika jest przejrzysta. Na końcu dostaliśmy lekkie i uczciwe narzędzie, które robi dokładnie to czego potrzebujemy - bez nadmiernej magii, bez ciężkich demonów w zestawie.

Wyniki po kilku dniach

Proces debugowania okazał się znacznie dłuższy i bardziej skomplikowany niż napisanie samego narzędzia. Początkowo nawet nie planowaliśmy ustawiania wartości progów dla FastFlowIPs, więc kilka razy (wiele) Grafana nerwowo wstrzymywała oddech pod samą objętością metryk i odmawiała pokazania nam ich w ogóle. Legenda dashboardu zawierała tyle adresów IP, że możesz by przewijać godzinami i prawdopodobnie nigdy nie dotrzeć do końca. Przeliczyliśmy się - ale gdzie?

Debugging ciągle psuł rzeczy, potem je stabilizował, potem znów psuł nasz wyczerpany FastFlowIPs, aż zaczął cicho płakać w skrajnych przypadkach. Było albo za dużo metryk, albo za mało, albo wcale żadnych. Najwyraźniej z przeciążenia emocjonalnego. Poza tym, największą zagadką dla nas okazały się metryki Flows RX/TX, które lekko się zamieniły miejscami, coś co było pięknie widoczne w czasie rzeczywistym na routerach VyOS. Najjaśniejsze umysły naszego zespołu walczyły z tym, i w końcu cel został osiągnięty: metryki zostały ustabilizowane, a Grafana została wyleczona z astmy.

Dziś mamy schludne, uporządkowane i informatywne metryki, które pokazują dokładnie ruch sieciowy jakiego potrzebujemy:

Kiedy pora zbudować własny mini-FastNetMon

Budowanie własnych rowerów to zło. Aż do momentu gdy po prostu nie możesz iść dalej bez jednego.

Pisanie własnego narzędzia absolutnie ma sens kiedy istniejące rozwiązania są albo za ciężkie albo za mądre dla twojego konkretnego zadania. Kiedy nie potrzebujesz 100500 funkcji, integracji ze stacją kosmiczną, i dashboardów na 19 monitorach - kiedy po prostu potrzebujesz liczb, szybko i bez bólu głowy.

Powinieneś także rozważyć stworzenie własnego rozwiązania jeśli sytuacja wymaga elastyczności: potrzebujesz dodać metrykę w locie, wbudować niestandardową logikę anty-DDoS, sprawić żeby monitoring grał ładnie z twoim dziwnym sprzętem, lub po prostu ominąć ograniczenia które nagle zostały usunięte z twojego ulubionego firmware (ciepłe pozdrowienia dla VyOS 1.5).

Krótko mówiąc, budowanie własnego narzędzia to kwestia kontroli, szybkości, minimalizmu, i nie zależności od komponentów które nagle znikają z repozytoriów. Główną rzeczą jest pamiętanie złotej zasady: jeśli może być zrobione prościej - rób to prościej.

I jeszcze jedna zasada: jeśli działa - nie ruszaj.

Wielki finał

Ostatecznie, cała ta historia nie dotyczy ruchu, DDoS, ani nawet FastNetMon. Dotyczy faktu, że czasami zespół po prostu chce narzędzie które działa, nie psuje się po aktualizacji, i nie zamienia twojego życia w powtórkę Skazanych na Shawshank.

Nie wynaleźliśmy koła na nowo - zbudowaliśmy własną małą hulajnogę która idealnie pasuje do naszej drogi. I nie ma w tym nic złego. W świecie gdzie masywne projekty open-source żyją swoim nieprzewidywalnym życiem, miło jest mieć coś własnego - znajome, stabilne, i cudownie nudne.

Więc jeśli kiedykolwiek patrzyłeś na kolejne “idealne ale trochę zbyt idealne” narzędzie i pomyślałeś: “szczerze mówiąc, łatwiej byłoby napisać to samemu” - możesz być na właściwej ścieżce. Tylko rób to mądrze, z testami… i bądź gotowy trochę pocierpieć.