Bezpieczny blackholing: trzy punkty do sprawdzenia we własnej sieci

Blackholing (RTBH) jest najszybszym sposobem odcięcia ruchu ataku, ale samo jego włączenie niczego jeszcze nie gwarantuje. Bezpieczny blackholing to określenie, którym opisujemy sprawdzenie kilku konkretnych punktów w sieci, dopiero po ich przejściu mamy pewność, że mechanizm zadziała w całości i że ruch ataku nie wyląduje tam, gdzie zaszkodzi najbardziej.

Ten artykuł pokazuje najpierw, na czym blackholing polega, potem w których miejscach najczęściej zawodzi, a na końcu jak każdy z tych problemów po kolei usunąć.

Na czym polega blackholing, w punktach

1. System detekcji rozpoznaje atak wolumetryczny kierowany na konkretny adres w naszej sieci.
2. Konsola WanGuard rozgłasza ten adres jako prefiks (/32 dla IPv4) przez sesję BGP.
3. Prefiks jest oznaczany BGP community (np. 5617:666), po którym dostawca łącza (Uplink) rozpoznaje, że chodzi o BGP blackhole (RTBH).
4. Nasi dostawcy tranzytowi, widząc to BGP community, odrzucają ruch do tego adresu u siebie, czyli zanim dotrze do nich oraz do naszej sieci.
5. Nasz własny router brzegowy odrzuca to, co mimo wszystko dotarło, pod warunkiem ustawienia lokalnego RTBH.

Trzy punkty, które trzeba sprawdzić

Poniższe trzy warunki weryfikujemy w takiej właśnie kolejności, każdy kolejny ma sens dopiero wtedy, gdy poprzedni jest spełniony.

Punkt 1. Komplet BGP community przy rozgłaszaniu

To jest warunek najważniejszy i jednocześnie najczęściej niedopilnowany. Przy rozgłaszaniu prefiksu blackhole muszą być dołączone wszystkie BGP community używane przez naszych dostawców oraz przez partnerów wymiany ruchu (peering). Każdy operator ma własne BGP community sygnalizujące blackhole i honoruje wyłącznie swoje: obok standardowego 65535:666 w powszechnym użyciu pozostają wartości specyficzne dla poszczególnych sieci.

Konsekwencja jest prosta: jeżeli w rozgłoszeniu brakuje BGP community jednego z dostawców, ten dostawca nie odrzuci ruchu i cały wolumen ataku wejdzie na łącze od jego strony, mimo że pozostali dostawcy zadziałali poprawnie. Blackholing będzie wtedy wyglądał na „działający, ale nieskuteczny”, a przyczyna leży wyłącznie w brakującym BGP community.

Po pokryciu kompletu BGP community ruch do zaatakowanego adresu przestaje docierać do naszej sieci. Warto natomiast wiedzieć, że z punktów wymiany ruchu może przyjść pewna resztka: blackholing nie zawsze działa tam tak samo jak na łączach tranzytowych, bo część partnerów w ogóle nie honoruje BGP community blackhole albo stosuje własne, odmienne zasady. Właśnie dlatego potrzebne są punkty drugi i trzeci.

Punkt 2. Next-hop nie może wskazywać na konsolę WanGuard

W protokole BGP każdy prefiks niesie atrybut next-hop, który mówi, pod jakim kolejnym adresem IP dana sieć jest osiągalna. Prefiks blackhole przychodzi do routera z konsoli WanGuard, więc jego next-hop domyślnie wskazuje właśnie na adres konsoli.

Skutek ujawnia się dokładnie wtedy, gdy jest najgorszy moment. Jeżeli mimo blackholingu na naszych łączach pojawi się wzmożony ruch, na przykład z punktu wymiany ruchu, o czym była mowa wyżej, router potraktuje konsolę jako ostatni element trasy do zaatakowanego adresu i skieruje ten ruch na nią. Konsola WanGuard jest maszyną zarządzającą, nie urządzeniem przenoszącym ruch; przy odpowiednim wolumenie traci wydajność, przestaje odpowiadać i może zerwać sesję BGP, która utrzymuje całą ochronę sieci. Tracimy wtedy ochronę i cały ruch z ataku DDoS pojawi się na łączach.

Rozwiązanie: w polityce importu na sesji BGP z konsolą podmieniamy next-hop przychodzących prefiksów na adres należący do routera.

Punkt 3. Lokalny blackholing na routerze

Podmiana next-hopa sama w sobie przenosi problem, zamiast go rozwiązać: ruch przestaje płynąć do konsoli, ale zaczyna trafiać do routera, który nie ma dokąd go wysłać. Dlatego adres wskazany jako nowy next-hop musi mieć na routerze lokalną regułę odrzucającą: trasę, która mówi wprost, że ruch kierowany pod ten adres ma zostać usunięty.

Ten element jest kluczowy niezależnie od tego, czy pracujemy na routerze sprzętowym, czy programowym. Prawidłowo skonfigurowana trasa odrzucająca powoduje, że pakiety znikają w warstwie przełączającej i nie docierają do procesora kontrolnego. Bez niej router zaczyna obsługiwać ruch programowo, co przy ataku wolumetrycznym oznacza rosnące obciążenie procesora, problemy z sesjami BGP i utratę stabilności, czyli ten sam skutek, którego chcieliśmy uniknąć przy konsoli, tylko przeniesiony w inne miejsce.

Jako adres docelowy dla lokalnego blackholingu wybieramy dowolny nieużywany adres z puli prywatnej według RFC 1918: 10.0.0.0/8, 172.16.0.0/12 lub 192.168.0.0/16. W przykładach poniżej używamy 10.255.255.1. Adres z tych zakresów nie jest routowany w internecie, więc nie da się przypadkowo odciąć czegoś realnego, a przy okazji nie wchodzi w kolizję z domyślną listą martians w Junosie.

Efekt złożenia trzech punktów

Mając komplet BGP community przy rozgłaszaniu, podmieniony next-hop przy imporcie oraz lokalny blackholing na routerze, uzyskujemy pewność, że ruch ataku:

• w przeważającej części zostaje odrzucony u dostawców, zanim wejdzie na nasze łącza,
• nie trafia na konsolę WanGuard, więc system detekcji pracuje dalej i widzi przebieg incydentu,
• nie obciąża routera brzegowego, tylko zostaje odrzucony jako ruch zbędny i niebezpieczny.

Konfiguracja, Juniper MX

Poniżej pełna konfiguracja sesji z konsolą WanGuard, obejmująca zarówno RTBH, jak i BGP FlowSpec:

set protocols bgp group eBGP-Wanguard type internal

set protocols bgp group eBGP-Wanguard description Wanguard

set protocols bgp group eBGP-Wanguard peer-as 65000

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 local-address 10.0.2.5

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 import import-Wanguard

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet unicast

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet flow no-validate NO-VALIDATION

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 unicast

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 flow no-validate NO-VALIDATION

set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 export no-export



set policy-options policy-statement NO-VALIDATION then accept

set policy-options policy-statement REJECT-ALL term reject then reject

set policy-options policy-statement import-Wanguard term flowspec_import from rib inetflow.0

set policy-options policy-statement import-Wanguard term flowspec_import then accept

set policy-options policy-statement import-Wanguard term rtbh from protocol bgp

set policy-options policy-statement import-Wanguard term rtbh from community blackhole

set policy-options policy-statement import-Wanguard term rtbh then accept

set policy-options policy-statement import-Wanguard term last-deny-all then reject



set policy-options community blackhole members 5617:666



set routing-options rib inetflow.0 maximum-prefixes 5000

set routing-options flow term-order standard

Ostatni człon jest istotny: sesja z konsolą WanGuard służy wyłącznie do sygnalizowania RTBH i BGP FlowSpec, więc wszystko, co nie pasuje do wzorca, odrzucamy.

Do powyższego dochodzą dwa elementy realizujące punkty drugi i trzeci, podmiana next-hopa przy imporcie oraz trasa odrzucająca:

set routing-options static route 10.255.255.1/32 discard



set policy-options policy-statement import-Wanguard term rtbh then next-hop 10.255.255.1

Junos pozwala też kierować ruch na interfejs discard zamiast na trasę statyczną. Rozwiązanie jest wygodniejsze tam, gdzie chcemy liczyć albo próbkować odrzucany ruch, ponieważ do interfejsu można przypiąć filtry.

Konfiguracja, Cisco

ip route 10.255.255.1 255.255.255.255 Null0



ip community-list standard BLACKHOLE permit 5617:666



ip prefix-list HOST-ROUTES permit 0.0.0.0/0 ge 32 le 32



route-map WANGUARD-IN permit 10

 match community BLACKHOLE

 match ip address prefix-list HOST-ROUTES

 set ip next-hop 10.255.255.1

route-map WANGUARD-IN deny 20



router bgp <ASN>

 neighbor <adres-konsoli> route-map WANGUARD-IN in

Interfejs Null0 jest pseudointerfejsem, który zawsze pozostaje aktywny i nigdy nie przenosi ruchu, kierowanie na niego to standardowy sposób realizacji lokalnego blackholingu na platformach Cisco.

Weryfikacja

Trzy testy, najlepiej wykonane na spokojnie, poza atakiem.

BGP community. Po zgłoszeniu testowego blackhole’a sprawdźcie u każdego dostawcy, czy prefiks został przyjęty i czy jest u niego oznaczony jako blackhole. To jedyny sposób, żeby wychwycić brakujące BGP community zanim zrobi to atak.

Next-hop. Na routerze sprawdźcie trasę do testowanego adresu. Next-hop musi wskazywać na adres lokalnego blackholingu i nigdy na adres konsoli. To jest najważniejszy pojedynczy test w całym wdrożeniu.

Trasa odrzucająca. Na Juniperze show route 10.255.255.1 powinno pokazać wpis typu Discard, na Cisco show ip route 10.255.255.1 powinno wskazywać Null0. Liczniki interfejsu wejściowego mają rosnąć, wyjściowego już nie.

Lista kontrolna

• Spisana lista wszystkich dostawców i partnerów wymiany ruchu wraz z wymaganymi przez nich BGP community.
• Konsola dokleja komplet tych BGP community przy rozgłaszaniu prefiksu blackhole.
• Polityka importu na sesji z konsolą podmienia next-hop na adres lokalny.
• Polityka reaguje wyłącznie na prefiksy hostowe oznaczone BGP community blackhole, reszta jest odrzucana.
• Adres lokalnego blackholingu ma trasę discard lub Null0.
• Test wykonany: next-hop wskazuje na blackholing lokalny, nie na konsolę.
• Prefiksy blackhole nie wyciekają poza zamierzony zakres rozgłoszenia.

Materiały źródłowe

• Cisco: Remotely Triggered Black Hole Filtering (opracowanie techniczne).
• Cisco: Remotely triggered blackhole filtering (dokumentacja BGP, IOS XR).
• Juniper: discard (routing-options).
• Juniper: Example: Forwarding Packets to the Discard Interface.
• IETF: RFC 7999 (BGP community BLACKHOLE 65535:666) oraz RFC 5635 (blackholing wyzwalany zdalnie).