Kontynuując opis konfiguracji Birda, w tym wpisie skupię się na obsłudze BGP Blackholingu. Pokażę jak rozgłosić ręcznie dodany prefix oraz jak połączyć Birda z hostem do wykrywania ataków DDoS.
Zacznijmy od dwóch zdań wyjaśnienia jak działa BGP Blackholing. Chodzi o to, aby atakowany adres IP jak najszybciej przestał był widoczny w internecie (trafił do czarnej dziury – blackhole). W praktyce wygląda to tak, że w momencie ataku musimy oznaczyć atakowany adres IP odpowiednim BGP community i rozgłosić go do naszych upstreamów. Dzięki temu atakowany adres przestaje być dostępny z Internetu i atak na naszą sieć ustaje.
Na przykładzie usług EPIX pokażę jak odpowiednio oznaczyć i rozgłosić prefix za pomocą Birda. Zaczniemy od metody ręcznej. Dodajemy do naszej konfiguracji kolejny protokół typu static, do którego będziemy wpisywać adresy do blackholowania:
Protocol static BH {
route 155.133.29.200/32 reject;
}
Następnie modyfikujemy nasze filtry typu out i dodajemy odpowiednie community. Poniższy przykład dla usługi KAT-GlobalMix w EPIX (community 50607:666):
filter EPG_OUT {
bgp_path.prepend(200577);
bgp_path.prepend(200577);
if proto="PREFIX" then { accept; }
if proto="BH" then { bgp_community.add((50607,666));
accept; }
reject;
}
Sprawdzamy poprawność konfiguracji i zatwierdzamy zmiany:
bird> configure check
Reading configuration from /etc/bird/bird.conf
Configuration OK
bird> configure
Reading configuration from /etc/bird/bird.conf
Reconfigured
Pozostaje nam sprawdzić, czy prefix poprawnie został rozgłoszony:
bird> show route export EPGLOBAL all
155.133.29.0/24 unreachable [PREFIX 2018-10-24 15:23:18] * (200)
Type: static unicast univ
BGP.origin: IGP
BGP.as_path: 200577 200577 200577
BGP.next_hop: 176.126.59.243
BGP.local_pref: 100
155.133.29.200/32 unreachable [BH 2018-12-23 15:39:36] * (200)
Type: static unicast univ
BGP.origin: IGP
BGP.as_path: 200577 200577 200577
BGP.next_hop: 176.126.59.243
BGP.local_pref: 100
BGP.community: (50607,666)
Oraz czy EPIX widzi poprawnie nasz adres IP:
Ręczne dodawanie do BH bywa przydatne, ale jeżeli chcemy reagować szybko na ataki, to powinniśmy wdrożyć system do wykrywania DDoS. Rozwiązań jest kilka, np płatny Wanguard, którego naprawdę mogę polecić. Można też skorzystać z darmowych rozwiązań opartych o linuxa czy nawet Mikrotika. Tak, Mikrotika 🙂 O ile nie przepadam za tym systemem w roli BGP, tak do analizy ruchu nadaje się całkiem dobrze. Bez względu na co się zdecydujemy, zasada działania jest podobna. Na switchu do którego mamy podłączony nasz router BGP tworzymy mirror port z portu „wejściowego” do BGP. Mirrorowany ruch musi trafić do naszego analizatora. Analizator posiada sesję z naszym routerem BGP i w momencie wykrycia ataku (po przekroczeniu wyznaczonych progów) rozgłasza do naszego BGP odpowiednio oznaczony prefix. Nasz router BGP musi go odebrać i wysłać dalej z odpowiednim community (tak jak w przypadku metody ręcznej).
Mój analizator to Mikrotik. Atakowany adres IP oznacza wewnętrznym community 64666:666:
/routing filter
add action=accept append-bgp-communities=64666:666 chain=bgp-blackhole-out
/routing bgp advertisements> print peer=bgp-v4 detail
peer="bgp-v4" prefix=155.133.29.200/32 nexthop=155.133.29.137 origin=igp local-pref=100 communities=64666:666
Bird musi przyjąć ten prefix, usunąć moje wewnętrze community i dodać odpowiednie dla danego peera:
filter EPG_OUT {
if ((64666,666) ~ bgp_community ) then {
bgp_community = -empty-;
bgp_community.add((50607,666));
accept;
}
bgp_path.prepend(200577);
bgp_path.prepend(200577);
if proto="PREFIX" then { accept; }
reject;
}
I sprawdzamy działanie:
bird> show route export EPGLOBAL all
155.133.29.0/24 unreachable [PREFIX 2018-10-24 15:23:18] * (200)
Type: static unicast univ
BGP.origin: IGP
BGP.as_path: 200577 200577 200577
BGP.next_hop: 176.126.59.243
BGP.local_pref: 100
155.133.29.200/32 blackhole [ANTYDDOS 2018-12-23 17:02:00 from 155.133.29.137] * (666) [AS200577i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 200577
BGP.next_hop: 176.126.59.243
BGP.local_pref: 100
BGP.community: (50607,666)
Na koniec jeszcze jedna rada, którą warto wykorzystać. EPIX w usłudze Open Peering rozgłasza do nas prefixy blackholowane przez uczestników. Warto to wykorzystać i na filtrze typu in oznaczyć je, by zostały blackholowane na naszym routerze. Dzięki temu nie będzie komunikacji z tymi adresami z naszej sieci:
filter EPIX_IN {
if (net ~ [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 224.0.0.0/4+ ]) then reject;
if net.ip = 0.0.0.0 then reject;
if (net.len < 8) || (net.len > 32) then reject;
if ( bgp_path.len > 50 ) then reject;
if ((62047,666) ~ bgp_community ) then {
dest = RTD_BLACKHOLE;
preference = 666;
accept; }
accept;
}
I efekt (z innej sieci):
# birdc show route | grep 155
155.133.29.200/32 blackhole [EPIX_RS1 2018-12-23 17:02:01 from 178.216.40.1] * (666) [AS200577i]
# ping 155.133.29.200
PING 155.133.29.200 (155.133.29.200) 56(84) bytes of data.
From 185.179.58.1 icmp_seq=1 Destination Net Unreachable
From 185.179.58.1 icmp_seq=2 Destination Net Unreachable
From 185.179.58.1 icmp_seq=3 Destination Net Unreachable
--- 155.133.29.200 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2050ms
Pamiętajcie, że w przypadku usług EPIX obsługa BGP Blackholing jest domyślnie wyłączona. Należy skontaktować się z NOC EPIX i poprosić o jej włączenie na wszystkich usługach.
