Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-X

[michalw]

Witam szanowne grono,

Mam przed sobą zadanie uruchomienia systemu do RTBH, który ma funkcjonować w poniższej topologii:

https://image.ibb.co/bRcrn7/bh.jpg

Są sobie dwa łącza od niezależnych operatorów na których mam zestawione produkcyjne sesje BGP. Łacza te przechodzą przez switcha w dwóch odrębnych vlanach (na schemacie vlan zielony i vlan żółty). Switch ten ma za zadanie mirrorowanie całego ruchu IP jaki mam na stykach z tymi operatorami i przekazywanie go do sondy od blackholingu w celu jego analizy. Obaj moi operatorzy obsługują RTBH tylko i wyłącznie za pomocą odpowiednich community na produkcyjnych sesjach BGP, a te mam zestawione do ASRa.

I tu zaczyna się zabawa... Załóżmy, że od strony ISP1 przychodzi atak DDoS na adres X.X.X.X/32 znajdujący się w mojej lokalnie publicznej przestrzeni IP (na schemacie chmura LAN). Sonda go wychwytuje i wysyła do ASRa odpowiednie dla ISP1 community z atakowanym adresem /32. Dzieje sie to na dedykowanej do tego sesji BGP pomiędzy sondą, a ASRem. Z tego co doczytałem to standardowo dla BH na ASRze powinna istnieć trasa statyczna do celu 192.0.2.1 prowadząca przez interfejs Null0, a po odebraniu na ASRze atakowanego prefiksu z sondy z odpowiednim community ustawienie mu nexthopa właśnie na 192.0.2.1. Jednak, o ile dobrze rozumuję, wstawienie go do tablicy routingu spowoduje wysłanie w Nulla całego ruchu przychodzącego z internetu, w tym tego prawidłowego, który nadchodzi od strony ISP2 i jest zaadresowany do atakowanego hosta X.X.X.X/32. Zamysł całości jest taki, żeby nie wysyłać w czarną dziurę żadnego ruchu IP u siebie na ASRze, a tylko przekazywać otrzymany od sondy prefiks /32 z odpowiednim community do odpowiedniego operatora. Blackholing niepożądanego ruchu IP powinien zrobić mój ISP od strony którego nadchodzi atak. W ten sposób atakowany host wciąż bedzie osiągalny przez ISP2. Po za tym, wg. mojej wiedzy o BGP, żeby wysłać jakiś prefiks w sesji musi on istnieć w tablicy routingu, a to komplikuje mi sprawę, bo jak nie będę miał go w tablicy routingu to nie będę miał co wysłać do ISP.

Szukałem po internetach czegoś w rodzaju jak wstrzyknąć w tablicę BGP wysyłaną do ISP prefix /32 otrzymany od sondy bez jego instalacji w tablicy routingu lub możliwości zainstalowania w tablicy routingu ASRa takiej trasy, ale żeby nie miała ona wpływu na forwardowanie pakietów i niestety moje poszukiwania nie przyniosły zadowalającego efektu. Do tego nie mogę robić zbytnio przerw w środowisku produkcyjnym, mającym działać 24h/dobę, by metodą prób i błędów dojść samodzielnie do rozwiązania. Czy ktoś z Was będzie w stanie wskazać mi drogę jak to osiągnąć?

[lbromirs]

Witam szanowne grono,

Mam przed sobą zadanie uruchomienia systemu do RTBH, który ma funkcjonować w poniższej topologii:

https://image.ibb.co/bRcrn7/bh.jpg

Komercyjnie?

I tu zaczyna się zabawa... Załóżmy, że od strony ISP1 przychodzi atak DDoS na adres X.X.X.X/32 znajdujący się w mojej lokalnie publicznej przestrzeni IP (na schemacie chmura LAN). Sonda go wychwytuje i wysyła do ASRa odpowiednie dla ISP1 community z atakowanym adresem /32.

Super.

Dzieje sie to na dedykowanej do tego sesji BGP pomiędzy sondą, a ASRem. Z tego co doczytałem to standardowo dla BH na ASRze powinna istnieć trasa statyczna do celu 192.0.2.1 prowadząca przez interfejs Null0, a po odebraniu na ASRze atakowanego prefiksu z sondy z odpowiednim community ustawienie mu nexthopa właśnie na 192.0.2.1.

Nie ma nic standardowego, wszystko jest umowne. 192.0.2.1 również. Jeśli masz sesję iBGP możesz zmieniać sobie next-hop w obrębie ASa, jeśli masz eBGP oczywiście musisz sugerować się community i sam modyfikować next-hop po odebraniu.

Jednak, o ile dobrze rozumuję, wstawienie go do tablicy routingu spowoduje wysłanie w Nulla całego ruchu przychodzącego z internetu, w tym tego prawidłowego, który nadchodzi od strony ISP2 i jest zaadresowany do atakowanego hosta X.X.X.X/32.

Tak. Blackholing to blackholing.

Zamysł całości jest taki, żeby nie wysyłać w czarną dziurę żadnego ruchu IP u siebie na ASRze, a tylko przekazywać otrzymany od sondy prefiks /32 z odpowiednim community do odpowiedniego operatora. Blackholing niepożądanego ruchu IP powinien zrobić mój ISP od strony którego nadchodzi atak. W ten sposób atakowany host wciąż bedzie osiągalny przez ISP2. Po za tym, wg. mojej wiedzy o BGP, żeby wysłać jakiś prefiks w sesji musi on istnieć w tablicy routingu, a to komplikuje mi sprawę, bo jak nie będę miał go w tablicy routingu to nie będę miał co wysłać do ISP.

To zdecyduj się co chcesz w końcu robić - blackholing czy routing. Z tego co do tej pory napisałeś, nie chcesz wcale robić blackholingu z ruchem który otrzymasz (a to błąd), a tylko przekazywać prefiksy z odpowiednim community, które ustawia Ci sonda - to je po prostu przekazuj. Nie musisz mieć żadnej specjalnej konfiguracji.

Do tego nie mogę robić zbytnio przerw w środowisku produkcyjnym, mającym działać 24h/dobę, by metodą prób i błędów dojść samodzielnie do rozwiązania.

...a zatem mamy to zrobić za Ciebie, za darmo i z gwarancją? :)

[konradrz]

Nie to, żebym się jakoś na BGP znał. Ale wędka:
Raz, że możesz sobie zrobić dwa VRFy.
Dwa, że prefix-listy i route-mapy, jak np tu i tu. Szczególnie to drugie.

Edit: a, no i był kiedyś taki gościu, co to zajmował się takim projektem "BGP Blackholing PL", ale chyba mu się znudziło (i najwyraźniej mu nie wstyd!), bo

Kod: Zaznacz cały

dig @8.8.8.8 blackholing.pl
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64521

Tak czy inaczej, możesz coś znaleźć np tu, przykładowy konfig tu - ale wygasł certyfikat, ktoś tam nie dokonfigurował LetsEncrypt, a tu masz w ogóle ładną prezentację.

[michalw]

Dzięki konradrz.

Prefiks listy planuję wykorzystać by określić mój zakres adresów PA ograniczając je do konkretnych ogłoszeń /32 jakie będę odbierać od sondy. Wyeliminuję w ten sposób możliwość wystąpienia jakiejkolwiek pomyłki i wyciecia czegoś więcej niż pojedyncze /32.

Route mapy zamierzam użyć dokładnie tak samo jak w tych przykładach co podałeś - na odbiorze z sondy zidentyfikować community i ustawić odpowiednie dla nich wartości. Natomiast za pomocą route map do ISP rozgłaszać prefiksy /32 z odpowiednim dla danego operatora community BH i to co pochodzi z mojego ASa.

Dzieki też za wskazanie materiałów, niestety są one bardzo zbliżone do tych wszystkich jakie do tej pory miałem okazje przejrzeć i się z nimi zapoznać.

[michalw]

Łukasz,

Pytasz, czy komercyjnie? Pracuję na etacie dla mniejszego dostawcy internetu, który ma swoich klientów i ci klienci płacą mojemu pracodawcy za dostęp do internetu, więc tak... komercyjnie. Mam z tego wypłatę na koniec miesiąca. Chcemy po prostu dać naszym klientom pewien sposób ochrony przed niepożądanym wolumenem ruchu IP.

To zdecyduj się co chcesz w końcu robić - blackholing czy routing. Z tego co do tej pory napisałeś, nie chcesz wcale robić blackholingu z ruchem który otrzymasz (a to błąd), a tylko przekazywać prefiksy z odpowiednim community, które ustawia Ci sonda - to je po prostu przekazuj. Nie musisz mieć żadnej specjalnej konfiguracji.

Nie, nie chcę robić blackholingu z ruchem jaki otrzymam u SIEBIE. Cel jest taki żeby to u moich dostawców był realizowany BH do moich adresów publicznych, by dzięki temu niepożądany wolumen ruchu IP wogóle do mnie nie dotarł. Nie uważam, żeby to był błąd, bo co mi z blackholingu u mnie skoro łacza do moich ISP będę miał zapchane ruchem który już mnie osiągnie. Uplinki zapchane = DDoS skuteczny i to nie tylko na jedno /32, ale na całą moją infrastrukturę sieci. Co do przekazywania community tak poprostu, okazuje się, że też nie jest od tak poprostu. Wyjaśnię to bliżej w następnym poście z konkretami.

...a zatem mamy to zrobić za Ciebie, za darmo i z gwarancją?

Nieeee... liczyłem od razu, że dostanę konkretną ofertę na wykonanie tego projektu za konkretne pieniądze... ale wystarczy tych żartów
Myśłałem, że od tego jest to forum by móc szukać pomocy od społeczności ludzi po fachu, którzy zjedli pewnie większe projekty niż ten nad którym ja teraz siedzę z BH. Pytałem tylko o wskazówki, bo wiedzy mam tu chyba jednak za mało.

[michalw]

Dobra, spróbuje od innej strony. Środowisko testowe

https://image.ibb.co/kZ2sPx/bh_testing.jpg

oparte o topologię wcześniej przedstawioną

https://image.ibb.co/bRcrn7/bh.jpg

ASR w konfiguracji:

Kod: Zaznacz cały

interface Loopback1
 description MOJA_ADRESACJA_PA
 ip address 222.0.0.1 255.255.240.0
!
interface Null0
 no ip unreachables
!
interface FastEthernet0/0
 description UPLINK do ISP1
 ip address 200.1.3.3 255.255.255.0
 duplex full
!         
interface FastEthernet1/0
 description UPLINK do ISP2
 ip address 200.2.3.3 255.255.255.0
 duplex full
 speed auto
!
interface FastEthernet1/1
 description LINK do SONDY-BH
 ip address 200.3.4.3 255.255.255.0
 duplex full
 speed auto
!
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 222.0.0.0 mask 255.255.240.0
 neighbor 200.1.3.1 remote-as 666
 neighbor 200.1.3.1 description ISP1
 neighbor 200.1.3.1 send-community both
 neighbor 200.1.3.1 route-map ISP1 out
 neighbor 200.2.3.2 remote-as 999
 neighbor 200.2.3.2 description ISP2
 neighbor 200.2.3.2 send-community both
 neighbor 200.2.3.2 route-map ISP2 out
 neighbor 200.3.4.4 remote-as 64512
 neighbor 200.3.4.4 description SONDA-BH
 neighbor 200.3.4.4 prefix-list 1 in
 neighbor 200.3.4.4 route-map SONDA-BH in
 neighbor 200.3.4.4 route-map DONT-ADVERTISE out
 no auto-summary
!
ip forward-protocol nd
ip route 192.0.2.1 255.255.255.255 Null0
!
ip bgp-community new-format
ip community-list 1 permit 666:666
ip community-list 2 permit 999:666
ip as-path access-list 1 permit ^$
!
!
!
ip prefix-list 1 seq 5 permit 222.0.0.0/20 ge 32
!
!
!
!
route-map SONDA-BH permit 1
 match community 1 2
 set ip next-hop 192.0.2.1
 set origin igp
!
route-map SONDA-BH deny 9999
!
route-map DONT-ADVERTISE deny 1
!
route-map ISP2 permit 1
 match community 2
!
route-map ISP2 permit 2
 match as-path 1
!
route-map ISP2 deny 9999
!
route-map ISP1 permit 1
 match community 1
!
route-map ISP1 permit 2
 match as-path 1
!
route-map ISP1 deny 9999
!

Otrzymuje od sondy w aktualizacji BGP dwa prefiksy /32:

Kod: Zaznacz cały

BGP table version is 6, local router ID is 222.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 8.8.4.0/24       200.1.3.1                0             0 666 i
*> 8.8.8.0/24       200.2.3.2                0             0 999 i
*> 222.0.0.0/20     0.0.0.0                  0         32768 i
*  222.0.0.6/32     192.0.2.1                0             0 64512 i
*  222.0.0.9/32     192.0.2.1                0             0 64512 i

Które wyglądają następująco:

Kod: Zaznacz cały

ASR#show bgp ipv4 uni 222.0.0.6/32         
BGP routing table entry for 222.0.0.6/32, version 4
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 666:666
ASR#show bgp ipv4 uni 222.0.0.9/32
BGP routing table entry for 222.0.0.9/32, version 5
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 999:666

Nie są one wstawiane do tablicy routingu:

Kod: Zaznacz cały

C    200.3.4.0/24 is directly connected, FastEthernet1/1
C    200.1.3.0/24 is directly connected, FastEthernet0/0
C    200.2.3.0/24 is directly connected, FastEthernet1/0
     8.0.0.0/24 is subnetted, 2 subnets
B       8.8.4.0 [20/0] via 200.1.3.1, 00:29:15
B       8.8.8.0 [20/0] via 200.2.3.2, 00:29:15
     192.0.2.0/32 is subnetted, 1 subnets
S       192.0.2.1 is directly connected, Null0
C    222.0.0.0/20 is directly connected, Loopback1

Jak sądzę z powodu tego, że next-hop 192.0.2.1 jest inaccessible (co widać wyżej w tablicy BGP)

I było by git, gdyby udało sie wysłać 222.0.0.6/32 zawarte w tablicy BGP do ISP1. Powinna to załatwić route-mapa ISP1, ale tak się nie dzieje. Wysyła tylko moje PA:

Kod: Zaznacz cały

ASR#show bgp ipv4 uni nei 200.1.3.1 advertised-routes 
BGP table version is 6, local router ID is 222.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 222.0.0.0/20     0.0.0.0                  0         32768 i

Total number of prefixes 1 

I tu jak sądzę, z braku 222.0.0.6/32 w tablicy routingu

Teraz inaczej. Przypadek numer 2. Nie ustawiam next-hopa w route-map SONDA-BH. Wygląda ona tak:

Kod: Zaznacz cały

route-map SONDA-BH permit 1
 match community 1 2
 set origin igp

Zgodnie z przewidywaniami obie trasy /32 pojawiają mi się w tablicy routingu

Kod: Zaznacz cały

C    200.3.4.0/24 is directly connected, FastEthernet1/1
     222.0.0.0/32 is subnetted, 2 subnets
B       222.0.0.9 [20/0] via 200.3.4.4, 00:00:09
B       222.0.0.6 [20/0] via 200.3.4.4, 00:00:09
C    200.1.3.0/24 is directly connected, FastEthernet0/0
C    200.2.3.0/24 is directly connected, FastEthernet1/0
     8.0.0.0/24 is subnetted, 2 subnets
B       8.8.4.0 [20/0] via 200.1.3.1, 01:12:05
B       8.8.8.0 [20/0] via 200.2.3.2, 01:12:06
     192.0.2.0/32 is subnetted, 1 subnets
S       192.0.2.1 is directly connected, Null0
C    222.0.0.0/20 is directly connected, Loopback1

i odpowiednie /32 są rozgłaszane do właściwych dla community ISP:

Kod: Zaznacz cały

ASR#show ip bgp nei 200.1.3.1 advertised-routes 
BGP table version is 8, local router ID is 222.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 222.0.0.0/20     0.0.0.0                  0         32768 i
*> 222.0.0.6/32     200.3.4.4                0             0 64512 i

Total number of prefixes 2 

Kod: Zaznacz cały

ASR#show ip bgp nei 200.2.3.2 advertised-routes 
BGP table version is 8, local router ID is 222.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 222.0.0.0/20     0.0.0.0                  0         32768 i
*> 222.0.0.9/32     200.3.4.4                0             0 64512 i

I prawie ok. ISP1 zablokuje mi ruch do 222.0.0.6/32, a ISP2 zablokuje do 222.0.0.9/32, ale... gdy ruch do 222.0.0.6/32 przyjdzie od strony ISP2 to zostanie skierowany na sondę, a nie trasą 222.0.0.0/20, gdzie rezyduje host, bo /20 jest mniej szczegółowa

Trzeci przypadek to zasadniczo pierwszy przypadek, czyli ustawienie next-hop na trasę statyczną prowadzącą w Nulla. Nie wiem tylko dlaczego w tablicy BGP prefiks /32 wskazujacy na następny hop 192.0.2.1 oznacza mi jako nieosiągalny:

Kod: Zaznacz cały

ASR#show bgp ipv4 uni 222.0.0.6/32         
BGP routing table entry for 222.0.0.6/32, version 4
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 666:666
ASR#show bgp ipv4 uni 222.0.0.9/32
BGP routing table entry for 222.0.0.9/32, version 5
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 999:666

Domyślam się, że gdy next-hop stanie się osiągalny to np. trasa do 222.0.0.6/32 wskazująca na 192.0.2.1 zostanie wstawiona do tablicy routingu i cały ruch z ISP1 i ISP2 zostanie u mnie wysłany w kosmos. Słowo klucz... u MNIE, a więc i tak niepożądany ruch już do mnie dotrze i UPLINK do operatora od strony którego atak nadchodzi będę miał wysycony.

Niby wszystko zgodnie z naukami wyniesionymi z akademii Cisco, a jednak gdzieś tu wiedzy musi mi brakować. Nie mam pojęcia co robię źle, wiem tylko tyle że kręcę się w kółko koło tematu BH na Cisco. Czy da się w ogóle na Cisco osiągnąć zamierzony cel? Przypomnę, że cel jest taki żeby to u moich dostawców był realizowany BH do moich adresów publicznych i dzięki temu niepożądany wolumen ruchu IP wogóle do mnie nie dotarł i nie zapchał mi łącz jakie mam z tymi właśnie operatorami. Jakieś wskazówki? Cokolwiek.

[konradrz]

Czekaj, ja to tępy jestem (i późno też jest, i piję też, bo brzydka pogoda w tej pieprzonej Holandii), ale czego od Ciebie oczekuje ISP? Wpisu w routingu, czy community?
Inaczej, czemu zamiast "set ip next-hop 192.0.2.1" (które zadziała u Ciebie) nie spróbujesz "set community XYZ" (które pójdzie do operatora)?

Swoją drogą ktoś miał podobny problem i rozwiązał go 'dummy serwerem'. Pewnie dałoby się loopbackiem i "redistribute connected/static".
Z innej strony (znowu, nie wiem czego Twój ISP oczekuje) - tutaj masz podane obie metody, i "set next hop" i "set community". I możesz mieć inne "set community" dla osobnych ISP ("Figure 13", nomen omen).

Ale, znowu, niech się mądrzejsi wypowiedzą. Jak np ten koleś, co olał najwyraźniej strony WWW swojego projektu Blackholing
Ja o BGP to gówno wiem. I nie boję się przyznać.

[lbromirs]

Czekaj, ja to tępy jestem (i późno też jest, i piję też, bo brzydka pogoda w tej pieprzonej Holandii), ale czego od Ciebie oczekuje ISP? Wpisu w routingu, czy community?
Inaczej, czemu zamiast "set ip next-hop 192.0.2.1" (które zadziała u Ciebie) nie spróbujesz "set community XYZ" (które pójdzie do operatora)?

Swoją drogą ktoś miał podobny problem i rozwiązał go 'dummy serwerem'. Pewnie dałoby się loopbackiem i "redistribute connected/static".
Z innej strony (znowu, nie wiem czego Twój ISP oczekuje) - tutaj masz podane obie metody, i "set next hop" i "set community". I możesz mieć inne "set community" dla osobnych ISP ("Figure 13", nomen omen).

Ale, znowu, niech się mądrzejsi wypowiedzą. Jak np ten koleś, co olał najwyraźniej strony WWW swojego projektu Blackholing :)
Ja o BGP to gówno wiem. I nie boję się przyznać.

Próbowałem się powstrzymać, ale Konrad był zbyt uparty... a w dodatku odpowiedział Ci już dwukrotnie :)

Żeby wysłać prefiks, musi być osiągalny. Prefisków nieosiągalnych BGP nie rozgłasza.

Modyfikacja next-hop jest o tyle wygodna, że przy sesjach iBGP next-hop jest przekazywany (choć i tak stosuje się dla porządku oznaczanie community, choćby z uwagi na accounting). Prefiks do nadrzędnego operatora powinien być oznaczony community - next-hop i tak na sesji eBGP zostanie podmieniony na wychodzący interfejs.

Konrad - blackholing.pl nigdy nie było ;) A z null0.pl/ttl0.net właśnie robimy porządek.

[michalw]

Czekaj, ja to tępy jestem (i późno też jest, i piję też, bo brzydka pogoda w tej pieprzonej Holandii), ale czego od Ciebie oczekuje ISP? Wpisu w routingu, czy community?
Inaczej, czemu zamiast "set ip next-hop 192.0.2.1" (które zadziała u Ciebie) nie spróbujesz "set community XYZ" (które pójdzie do operatora)?

Operatorzy moi oczekują ode mnie, że wyślę im prefiks /32 z ustawionym odpowiednim community do BH w aktualizacji BGP, w tej samej sesji co wysyłam im swoje adresy PA. W przedstawionej przeze mnie wcześniej topologii testowej przyjąłem przykładowo, że moje PA to 222.0.0.0/20, a community dla BH ISP1 to 666:666 i dla ISP2 999:666. Przyjąłem też, że atakowane są dwa hosty, ze strony ISP1 222.0.0.6 i ze strony ISP2 222.0.0.9. Zwróćcie uwagę, że w momencie odebrania aktualizacji BGP na ASRze wysłanej z sondy wyłapuję prefiksy /32 właśnie po tych community route-mapą SONDA-BH

Kod: Zaznacz cały

ip bgp-community new-format
ip community-list 1 permit 666:666
ip community-list 2 permit 999:666
!
route-map SONDA-BH permit 1
 match community 1 2
 set ip next-hop 192.0.2.1
 set origin igp

i po ich odebraniu w tablicy BGP na ASR te community są nadal ustawione:

Kod: Zaznacz cały

ASR#show bgp ipv4 uni 222.0.0.6/32         
BGP routing table entry for 222.0.0.6/32, version 4
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 666:666
ASR#show bgp ipv4 uni 222.0.0.9/32
BGP routing table entry for 222.0.0.9/32, version 5
Paths: (1 available, no best path)
  Not advertised to any peer
  64512
    192.0.2.1 (inaccessible) from 200.3.4.4 (222.0.0.129)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 999:666

Nie ustawiam ich na ASRze i nie modyfikuję ich już w żaden sposób. One są już ustawione wcześniej na sondzie. Następnie w ten sam sposób identyfikuje odpowidnie prefiksy do BH przy wysyłce do obu moich operatorów:

Kod: Zaznacz cały

route-map ISP2 permit 1
 match community 2
!
route-map ISP2 permit 2
 match as-path 1
!
route-map ISP2 deny 9999
!
route-map ISP1 permit 1
 match community 1
!
route-map ISP1 permit 2
 match as-path 1
!
route-map ISP1 deny 9999

Jednak w tym powyższym przypadku nie są one wysyłane do żadnego ISP bo nie widnieją w tablicy routingu z wiadomego powodu. Swoją drogą nadal nie wiem dlaczego 192.0.2.1 jest inaccesible. Trasa statyczna do 192.0.2.1 wskazuje na Null0 i jest ustawiona. Widać to w tablicy routingu. Pokazałem to już wcześniej w tym poście. To że community z /32 są wysyłane do obu ISP pokazuje przykład drugi jaki Wam przedstawiłem, gdzie nie ustawiam "set ip next-hop" i zostaje on niezmieniony po odebraniu go na ASRze - next-hop wskazuje wtedy na sondę. To też wcześniej pokazałem. Na ISP2 jest wtedy tak:

Kod: Zaznacz cały

ISP2#show bgp   
BGP table version is 4, local router ID is 8.8.8.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 8.8.8.0/24       0.0.0.0                  0         32768 i
*> 222.0.0.0/20     200.2.3.3                0             0 100 i
*> 222.0.0.9/32     200.2.3.3                              0 100 64512 i

ISP2#show bgp 222.0.0.9/32               
BGP routing table entry for 222.0.0.9/32, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  100 64512
    200.2.3.3 from 200.2.3.3 (222.0.0.1)
      Origin IGP, localpref 100, valid, external, best
      Community: 999:666

Tu wnioskuję, że nie ma potrzeby ustawiania na ASR "set community XYZ" bo odpowiednie dla danego ISP community do BH są już ustawiane wcześniej na sondzie dla każdego konkretnego prefiksu /32 jak bedzie atakowany. Po co ustawiać coś co już wcześniej zostało ustawione? Sonda wyłapuję ze strony którego ISP nadchodzi atak i na jaki adres IP z mojej puli PA jest on kierowany. Na tej podstawie sonda ustawia właściwe community dla tego ISP i wysyła do ASRa aktualizację BGP z atakowanym /32 i tym właśnie community. Jako że wiem które community obsługuje ISP1 to na ASRze chcę je do niego kierować. Tak samo z ISP2. Mam to ogarnięte na ASRze w "route-map ISP1" i "route-map ISP2" które są zapięte na out przy konfiguracji sąsiedztwa BGP obu nadrzędnych operatorów.

Panowie, nie doczytaliście chyba tego co do tej pory zamieściłem w tym poście. Problem nie tkwi w tym jak ustawić community, czy next-hop, ale jak wysłać do ISP1 lub ISP2 prefix /32 z ustawionym już wcześniej community jaki odbieram od sondy, aby u mnie nie nie miało to wpływu na routing do tego właśnie hosta. Ruch do niego ma być przekazywany na ASRze trasą bezpośrednio podłączoną na interfejs gdzie mam skonfigurowane moje PA /20, a nie trasą /32 z ustawionym next-hopem wskazującym na NULL0, czy na sondę. Blackholing ma się dziać u operatora z którego strony atak nadchodzi, a nie u mnie.

[zet69]

Panowie, nie doczytaliście chyba tego co do tej pory zamieściłem w tym poście. Problem nie tkwi w tym jak ustawić community, czy next-hop, ale jak wysłać do ISP1 lub ISP2 prefix /32 z ustawionym już wcześniej community jaki odbieram od sondy,

Czesc, udalo sie? Moze latwiej bedzie uzyc sondy z zainstalowanym softem exaBGP, w celu wyslania do ISP interesujacych Ciebie tras /32. Minus jest taki ze ISP musi zestawic kolejna sesje BGP, pomiedzy exaBGP a ISP, lub moze nawet udaloby sie to zrobic za pomoca exaBGP -> ASR ->ISP.

[lbromirs]

Panowie, nie doczytaliście chyba tego co do tej pory zamieściłem w tym poście. Problem nie tkwi w tym jak ustawić community, czy next-hop, ale jak wysłać do ISP1 lub ISP2 prefix /32 z ustawionym już wcześniej community jaki odbieram od sondy, aby u mnie nie nie miało to wpływu na routing do tego właśnie hosta. Ruch do niego ma być przekazywany na ASRze trasą bezpośrednio podłączoną na interfejs gdzie mam skonfigurowane moje PA /20, a nie trasą /32 z ustawionym next-hopem wskazującym na NULL0, czy na sondę. Blackholing ma się dziać u operatora z którego strony atak nadchodzi, a nie u mnie.

Już napisałem powyżej - albo routing, albo blackholing - w jednej instancji tablicy routingu.

Możesz:

a) zestawić osobną sesję z trigger routera bezpośrednio do operatora - nierealne jak sądze
b) zestawić osobną sesję lokalnie do routera operatora na np. innym loopbacku, zamknąć go w osobnym VRFie (po stronie operatora może to być po prostu inny interfejs, np. rozróżniany przez 802.1q) i tak wrzucać trasy do blackholingu jeśli nie ma on odbywać się również u Ciebie (dziwne założenie, ale nie będę już wnikał)

Każda dodatkowa informacja i mechanizm (QPPB, FlowSpec) opiera się już o istnienie prefiksu w tablicy routingu, a zatem musiałbyć tą /32 instalować w FIBie. Co z nią dalej robisz, można jeszcze próbować kombinować, ale odradzam - kombinowanie kończy się dramatem. Sugeruje przegadać z operatorem opcję b) powyżej.