Czy system antyddos dla ISP musi być drogi? Niekoniecznie. Jeżeli jesteśmy w stanie zrezygnować z pewnych udogodnień, to można mieć w pełni działający system do wykrywania ataków DDoS „za darmo”.
W tym wpisie chciałbym się z Wami podzielić rozwiązaniem, które testuje od pewnego czasu i używam jako alternatywę dla innych systemów na których pracuję, np. Wanguarda. Wprawdzie FastNetMon też występuje w wersji płatnej, ale to jednak Wanguard wybierany jest częściej przed ISP. Bez specjalnego analizowania cennika, po prostu Wanguard jest tańszy. Zwłaszcza zakupiony przez agregatora jakim jest np. EPIX. FastNetMon natomiast występuje równolegle w wersji community, która jest dostępna za darmo.
Oczywiście, żeby ktoś nie miał złudzeń. Darmowy FastNetMon nie dorównuje funkcjonalnością Wanguardowi. Nie znajdziemy tu graficznego konfiguratora, pięknych wykresów (chyba że sobie je sami zrobimy, ale o tym później) i intuicyjnego interfejsu. Dostajemy surową aplikację, która mimo wszystko spełnia swoje zadanie.
Do tej pory do analizowania ruchu używałem mirror portów. Czy to był Wanguard czy Mikrotik (tak, też może wykrywać DDoSy), zawsze w ten sposób to robiłem. Miało to swoje zalety takie jak błyskawiczna detekcja każdej anomalii. Z wad należy wymienić konieczność wykorzystania portu w przełączniku, czasami nie jednego i co za tym idzie kolejnych sensorów oraz dość mocnej maszyny. Nie w każdej sieci mogę sobie na to pozwolić, dlatego zacząłem szukać alternatyw i tak wpadłem na FastNetMona, którego postanowiłem zasilić za pomocą netflow lub sflow (W ten sam sposób można wykorzystać Wanguarda, ale nigdy nie miałem okazji spróbować tego typu sensora).
Wiedziałem, że ta metoda będzie miała bardzo istotną zaletę. Nie będę potrzebował fizycznej maszyny dla systemu. Pierwszą instalację FastNetMon uruchomiłem na wirtualnej maszynie. Nie zapeszając, działa i wydaje się, że nawet całkiem dobrze 🙂
Obciążenie hosta (ten pik na CPU to backup VM z librenms):
Długo zastanawiałem się w jaki sposób wysyłać flowy do systemu. Zacząłem od testów sflow z przełącznika na którym terminuje BGP (Nexus N3K). Działało to w miarę poprawnie, ale mimo zabawy z interwałami miałem wrażenie, że działa to zbyt wolno. Pomyślałem więc o netflow wysyłanym bezpośrednio z routera BGP (linux). Działało to sprawniej, ale wyraźnie obciążało router. Zacząłem grzebać w sieci i natknąłem się na pakiet hsflowd. Wydaje się, że to jest to czego szukałem. Duża elastyczność w konfiguracji (sample), a przy tym bardzo małe zapotrzebowanie na zasoby routera. Nie wiem czy to dobra droga, ale wydaje się to działać poprawnie. Chętnie porozmawiam z kimś bardziej doświadczonym, ponieważ na temat wykorzystania sflow do analizowania ddos, zdania w sieci są nieco podzielone.
Mając już działający sensor mogłem przystąpić do uruchomienia. Cała konfiguracja znajduje się w jednym pliku /etc/fastnetmon.conf. Po skonfigurowaniu progów, które są bardzo proste, definiujemy max pasmo, ilość pps, ilość flow, możemy to jeszcze rozdzielić na udp, tcp, icmp (jest możliwość tworzenia grup IP i wyjątków), pozostało skonfigurować sesje BGP. FastNetMon może współpracować z exaBGP i GoBGP. Wybrałem to drugie, mimo że chyba mniej popularne 🙂
Konfiguracja GoBGP:
[global.config]
as = 64545
router-id = "10.254.254.15"
[global.apply-policy.config]
export-policy-list = ["ddos"]
[[neighbors]]
[neighbors.config]
neighbor-address = "10.254.254.11"
peer-as = 64545
[[neighbors.afi-safis]]
[neighbors.afi-safis.config]
afi-safi-name = "ipv4-unicast"
[neighbors.transport.config]
local-address = "10.254.254.15"
[[policy-definitions]]
name = "ddos"
[[policy-definitions.statements]]
[policy-definitions.statements.actions]
route-disposition = "accept-route"
[policy-definitions.statements.actions.bgp-actions.set-community]
options = "add"
[policy-definitions.statements.actions.bgp-actions.set-community.set-community-method]
communities-list = ["64666:666"]
Konfiguracja Bird (wraz z modyfikacją filtra export, w tym przykładzie Polmix):
filter DDOS_OUT {
reject;
}
filter DDOS_IN {
dest = RTD_BLACKHOLE;
preference = 666;
accept;
}
filter WAR_POLMIX_OUT {
if (proto="ANTYDDOS" && (64666,666) ~ bgp_community ) then {
bgp_community = -empty-;
bgp_community.add((4446,666));
accept;
}
bgp_path.prepend(64545);
if proto="ISP" then { accept; }
reject;
}
protocol bgp ANTYDDOS {
neighbor 10.254.254.15 as 64545;
local 10.254.254.11 as 64545;
description "ANTYDDOS";
next hop self;
direct;
export filter DDOS_OUT;
import filter DDOS_IN;
default bgp_local_pref 666;
}
Sprawdzamy działanie:
/opt/gobgp_2_16_0/gobgp neighbor Peer AS Up/Down State |#Received Accepted 10.254.254.11 64545 13d 08:44:42 Establ | 0 0 10.254.254.12 64545 10d 21:37:55 Establ | 0 0
bird> show protocols ANTYDDOS name proto table state since info ANTYDDOS BGP master up 2020-12-15 12:34:25 Established
Możemy sobie dodać ręcznie IP i sprawdzić poprawność rozgłoszenia:
/opt/gobgp_2_16_0/gobgp global rib add 193.X.X.250/32 -a ipv4
bird> show route protocol ANTYDDOS all 193.X.X.250/32 blackhole [ANTYDDOS 2020-12-28 21:20:57 from 10.254.254.15] * (666) [?] Type: BGP unicast univ BGP.community: (64666,666) bird> show route export WAR_POLMIX all 193.X.X.250/32 blackhole [ANTYDDOS 2020-12-28 21:20:57 from 10.254.254.15] * (666) [?] Type: BGP unicast univ BGP.community: (4446,666)
FastNetMon może wysyłać powiadomienia na maila (wymagany skrypt dostępny na stronie). Raporty może nie wyglądają tak ładnie jak w Wanguard, ale dają nam wszystkie potrzebne informacje. Poniżej przykład komunikatu z ataku:
IP: 91.X.X.161 Attack type: udp_flood Initial attack power: 246321 packets per second Peak attack power: 260764 packets per second Attack direction: incoming Attack protocol: udp Total incoming traffic: 989 mbps Total incoming pps: 246321 packets per second Total incoming flows: 112 flows per second Average incoming traffic: 989 mbps Average incoming pps: 246321 packets per second Average incoming flows: 112 flows per second Incoming ip fragmented traffic: 0 mbps Incoming ip fragmented pps: 0 packets per second Incoming tcp traffic: 11 mbps Incoming tcp pps: 1113 packets per second Incoming syn tcp traffic: 0 mbps Incoming syn tcp pps: 0 packets per second Incoming udp traffic: 977 mbps Incoming udp pps: 245203 packets per second Average packet size for incoming traffic: 502.1 bytes 2020-12-27 18:52:13.414105 37.105.252.51:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 57 sample ratio: 2000 2020-12-27 18:52:13.414113 77.30.72.109:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 56 sample ratio: 2000 2020-12-27 18:52:13.414117 51.235.191.59:123 > 91.X.X.161:21653 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 56 sample ratio: 2000 2020-12-27 18:52:13.414120 95.0.4.115:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 53 sample ratio: 2000 2020-12-27 18:52:13.414124 14.169.60.48:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 54 sample ratio: 2000 2020-12-27 18:52:13.414127 185.94.236.126:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 58 sample ratio: 2000 2020-12-27 18:52:13.414130 51.235.131.235:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 57 sample ratio: 2000 2020-12-27 18:52:13.414134 122.100.191.42:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 53 sample ratio: 2000 2020-12-27 18:52:13.414137 42.117.22.77:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 53 sample ratio: 2000 2020-12-27 18:52:13.414140 189.158.52.223:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 53 sample ratio: 2000 2020-12-27 18:52:13.414144 66.96.201.99:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 55 sample ratio: 2000 2020-12-27 18:52:13.414147 51.235.18.42:123 > 91.X.X.161:1920 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 57 sample ratio: 2000 2020-12-27 18:52:13.414150 27.74.10.119:123 > 91.X.X.161:21653 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 53 sample ratio: 2000 2020-12-27 18:52:13.414153 42.113.211.48:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 52 sample ratio: 2000 2020-12-27 18:52:13.414156 113.172.92.91:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 54 sample ratio: 2000 2020-12-27 18:52:13.414160 184.82.65.143:123 > 91.X.X.161:21653 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 52 sample ratio: 2000 2020-12-27 18:52:13.414163 171.226.43.255:123 > 91.X.X.161:47932 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 52 sample ratio: 2000 2020-12-27 18:52:13.414167 118.98.104.26:123 > 91.X.X.161:1920 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 55 sample ratio: 2000 2020-12-27 18:52:13.414170 92.98.52.156:123 > 91.X.X.161:43130 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 56 sample ratio: 2000 2020-12-27 18:52:13.414173 60.173.175.70:123 > 91.X.X.161:1920 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 52 sample ratio: 2000 2020-12-27 18:52:13.414176 171.240.211.139:123 > 91.X.X.161:21653 protocol: udp frag: 0 packets: 1 size: 504 bytes ttl: 51 sample ratio: 2000
Wspominałem o wykresach. FastNetMon daje nam możliwość integracji z Graphite oraz InfluxDB. Można za ich pomocą wykorzystać Grafane do zobrazowania monitorowanego ruchu oraz anomalii. Nie miałem czasu przed świętami się tym zająć, ale pochwalę się i uzupełnię wpis jak coś mi z tego wyjdzie 🙂
To chyba wszystko co chciałem napisać o FastNetMon. Testy trwają od ok miesiąca. Póki co system wydaje się działać poprawnie. Kilkadziesiąt już ataków zostało zablokowanych, a po dopracowaniu progów i samplingu (metodą prób i błędów) nie zauważyłem żadnych zdarzeń „false positive”. Wciąż mam wątpliwości czy softwarowy sflow z routera to dobra droga, ale może ktoś bardziej obeznany w tym temacie rozwieje moje wątpliwości. Nie mam też bezpośredniego porównania do mirror portu na tej samej sieci, żeby porównać czas reakcji. Mimo wszystko atak wydaje się być blokowany zanim zacznie być odczuwalny w sieci.
Podsumowując. Może nie jest to, to samo co Wanguard, ale za darmo to i ocet słodki 🙂 Na pewno jest to ciekawa alternatywa dla oskryptowanego Mikrotika, którego przez lata wykorzystywałem w mniejszych sieciach, gdzie zakup Wanguarda był sporym problemem. Zachęcam do własnych testów. Oczywiście służę pomocą przy uruchomieniu 🙂
