Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-X
Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-X
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ąć?
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ąć?
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
Komercyjnie?michalw pisze: ↑26 mar 2018, 16:46 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
Super.michalw pisze: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.
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.michalw pisze: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.
Tak. Blackholing to blackholing.michalw pisze: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.
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.michalw pisze: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.
...a zatem mamy to zrobić za Ciebie, za darmo i z gwarancją? :)michalw pisze: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.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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
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ę.
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
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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ć.
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ć.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
Ł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.
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.
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.
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.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.
Nieeee... liczyłem od razu, że dostanę konkretną ofertę na wykonanie tego projektu za konkretne pieniądze... ale wystarczy tych żartów...a zatem mamy to zrobić za Ciebie, za darmo i z gwarancją?
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.
Ostatnio zmieniony 04 kwie 2018, 15:06 przez michalw, łącznie zmieniany 1 raz.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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:
Otrzymuje od sondy w aktualizacji BGP dwa prefiksy /32:
Które wyglądają następująco:
Nie są one wstawiane do tablicy routingu:
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:
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:
Zgodnie z przewidywaniami obie trasy /32 pojawiają mi się w tablicy routingu
i odpowiednie /32 są rozgłaszane do właściwych dla community ISP:
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:
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.
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
!
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
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
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
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
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
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
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
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
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.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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ć.
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ć.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
Próbowałem się powstrzymać, ale Konrad był zbyt uparty... a w dodatku odpowiedział Ci już dwukrotnie :)konradrz pisze: ↑05 kwie 2018, 00:51 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ć.
Ż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.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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-BHkonradrz pisze: ↑05 kwie 2018, 00:51 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)?
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
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
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
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
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.
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
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.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,
Re: Remotely Triggered Black Hole via community - przekazanie prefiksów z sondy RTBH do ISP przez router Cisco ASR 1002-
Już napisałem powyżej - albo routing, albo blackholing - w jednej instancji tablicy routingu.michalw pisze: ↑09 kwie 2018, 18:46 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.
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.