{"id":31415,"date":"2019-10-31T21:41:08","date_gmt":"2019-10-31T18:41:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika\/"},"modified":"2019-10-31T21:41:08","modified_gmt":"2019-10-31T18:41:08","slug":"vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Wszystko jest bardzo z\u0142e lub nowy rodzaj przechwytywania ruchu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

13 marca do roboczej grupy RIPE ds. przeciwdzia\u0142ania nadu\u017cyciom wp\u0142yn\u0119\u0142a propozycja<\/a><\/noindex> rozwa\u017cenia BGP hijacking (hjjack) jako naruszenia polityki RIPE. W przypadku akceptacji propozycji, dostawca internetowy, kt\u00f3ry pad\u0142 ofiar\u0105 przej\u0119cia ruchu, mia\u0142by mo\u017cliwo\u015b\u0107 z\u0142o\u017cenia specjalnego wniosku o ujawnienie przest\u0119pcy. Je\u015bli grupa ekspert\u00f3w zgromadzi\u0142aby wystarczaj\u0105c\u0105 ilo\u015b\u0107 dowod\u00f3w, taki LIR, b\u0119d\u0105cy \u017ar\u00f3d\u0142em BGP hijackingu, by\u0142by uwa\u017cany za naruszyciela i m\u00f3g\u0142by zosta\u0107 pozbawiony statusu LIR. Pojawi\u0142y si\u0119 tak\u017ce niekt\u00f3re argumenty przeciwko temu<\/a><\/noindex> zmianie.<\/p>\n

W tej publikacji chcemy pokaza\u0107 przyk\u0142ad ataku, w kt\u00f3rym nie tylko rzeczywisty przest\u0119pca by\u0142 w\u0105tpliwy, ale tak\u017ce ca\u0142a lista poszkodowanych prefiks\u00f3w. Co wi\u0119cej, taki atak ponownie stawia pytania dotycz\u0105ce motyw\u00f3w przysz\u0142ych przej\u0119\u0107 ruchu tego typu.
\n<\/a><\/noindex>
\nW ci\u0105gu ostatnich kilku lat w mediach jako BGP hijackingi relacjonowane by\u0142y tylko konflikty typu MOAS (Multiple Origin Autonomous System). MOAS jest szczeg\u00f3lnym przypadkiem, w kt\u00f3rym dwa r\u00f3\u017cne systemy autonomiczne og\u0142aszaj\u0105 sprzeczne prefiksy z odpowiednimi numerami ASN w AS_PATH (pierwszy ASN w AS_PATH, dalej w tek\u015bcie \u2014 origin ASN). Jednak mo\u017cemy wymieni\u0107 co najmniej 3 dodatkowe typy<\/a><\/noindex> przej\u0119cia ruchu, pozwalaj\u0105ce przest\u0119pcy manipulowa\u0107 atrybutem AS_PATH w r\u00f3\u017cnych celach, w tym w celu obej\u015bcia nowoczesnych metod filtracji i monitoringu. Znany typ ataku Pilosova-Kapeli<\/a><\/noindex> \u2014 to ostatni typ takiego przej\u0119cia, ale nie mniej istotny. Jest ca\u0142kowicie mo\u017cliwe, \u017ce w\u0142a\u015bnie taki atak obserwowali\u015bmy przez ostatnie tygodnie. To zdarzenie ma zrozumia\u0142y charakter i do\u015b\u0107 powa\u017cne konsekwencje.<\/p>\n

Ci, kt\u00f3rzy szukaj\u0105 wersji TL;DR, mog\u0105 przewin\u0105\u0107 do podtytu\u0142u \u201eIdealny atak\u201d.<\/p>\n

T\u0142o sieciowe<\/h3>\n

(aby lepiej zrozumie\u0107 procesy zaanga\u017cowane w ten incydent)<\/i><\/p>\n

Je\u015bli chcesz wys\u0142a\u0107 pakiet i masz kilka prefiks\u00f3w w tablicy routingu zawieraj\u0105cych adres IP docelowy, u\u017cyjesz trasy dla prefiksu o maksymalnej d\u0142ugo\u015bci. Je\u015bli jednak w tablicy routingu istnieje kilka r\u00f3\u017cnych tras dla jednego prefiksu, wybierzesz najlepsz\u0105 (zgodnie z mechanizmem wyboru najlepszej trasy).<\/p>\n

Istniej\u0105ce podej\u015bcia do filtrowania i monitorowania pr\u00f3buj\u0105 analizowa\u0107 trasy i podejmowa\u0107 decyzje na podstawie atrybutu AS_PATH. Router mo\u017ce zmieni\u0107 ten atrybut na dowoln\u0105 warto\u015b\u0107 podczas og\u0142aszania. Proste dodanie ASN w\u0142a\u015bciciela na pocz\u0105tku AS_PATH (jako ASN pochodzenia) mo\u017ce wystarczy\u0107, aby obej\u015b\u0107 obecne mechanizmy weryfikacji \u017ar\u00f3d\u0142a. Co wi\u0119cej, je\u015bli istnieje trasa od zaatakowanego ASN do ciebie, pojawia si\u0119 mo\u017cliwo\u015b\u0107 wyci\u0105gni\u0119cia i u\u017cycia AS_PATH tej trasy w innych twoich og\u0142oszeniach. Ka\u017cda weryfikacja wiarygodno\u015bci tylko AS_PATH dla twoich stworzonych og\u0142osze\u0144 w ko\u0144cu b\u0119dzie pozytywna.<\/p>\n

Istnieje r\u00f3wnie\u017c kilka zas\u0142uguj\u0105cych na uwag\u0119 ogranicze\u0144. Po pierwsze, w przypadku filtrowania prefiks\u00f3w przez wy\u017cszego dostawc\u0119, twoja trasa mo\u017ce by\u0107 nadal odfiltrowana (nawet z poprawnym AS_PATH), je\u015bli prefiks nie nale\u017cy do twojego klienta skonfigurowanego u dostawcy upstream. Po drugie, poprawny AS_PATH mo\u017ce sta\u0107 si\u0119 niepoprawny, je\u015bli utworzona trasa jest og\u0142aszana w nieprawid\u0142owych kierunkach, naruszaj\u0105c tym samym polityk\u0119 routingu. I ostatnia rzecz \u2014 ka\u017cda trasa z prefiksem naruszaj\u0105cym d\u0142ugo\u015b\u0107 ROA mo\u017ce by\u0107 uznana za niepoprawn\u0105.<\/p>\n

Incydent<\/h3>\n

\nKilka tygodni temu otrzymali\u015bmy skarg\u0119 od jednego z u\u017cytkownik\u00f3w. Widzieli\u015bmy trasy z jego ASN pochodzenia i prefiksami \/25, podczas gdy u\u017cytkownik twierdzi\u0142, \u017ce ich nie og\u0142asza\u0142.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|NIEKOMPLETNY|xxx|0|0||NAG||<\/code>
\nPrzyk\u0142ady og\u0142osze\u0144 na pocz\u0105tek kwietnia 2019<\/i><\/p>\n

NTT w drodze dla prefiksu \/25 czyni go szczeg\u00f3lnie podejrzanym. Podczas incydentu LG NTT nie wiedzia\u0142 nic o tej trasie. Wi\u0119c tak, jaki\u015b operator tworzy ca\u0142y AS_PATH dla tych prefiks\u00f3w! Sprawdzaj\u0105c na innych routerach, mo\u017cna wyr\u00f3\u017cni\u0107 jeden szczeg\u00f3lny ASN: AS263444. Spogl\u0105daj\u0105c na inne trasy z tego systemu autonomicznego, napotkali\u015bmy nast\u0119puj\u0105c\u0105 sytuacj\u0119:<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||<\/code>
\nSpr\u00f3buj zgadn\u0105\u0107, co jest nie tak<\/i><\/p>\n

Wygl\u0105da na to, \u017ce kto\u015b wzi\u0105\u0142 prefiks z trasy, podzieli\u0142 go na dwie cz\u0119\u015bci i og\u0142osi\u0142 tras\u0119 z tym samym AS_PATH dla tych dw\u00f3ch prefiks\u00f3w.<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0\/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0\/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||<\/code>
\nPrzyk\u0142ady tras dla jednej z par podzielonych prefiks\u00f3w<\/i><\/p>\n

Pojawia si\u0119 kilka pyta\u0144. Czy rzeczywi\u015bcie kto\u015b pr\u00f3bowa\u0142 w praktyce tego typu przechwytywania? Czy kto\u015b zaakceptowa\u0142 te trasy? Jakie prefiksy zosta\u0142y dotkni\u0119te?<\/p>\n

Tutaj zaczyna si\u0119 nasza seria niepowodze\u0144 i kolejna runda rozczarowania obecnym stanem zdrowia Internetu.<\/p>\n

\u015acie\u017cka niepowodze\u0144<\/h3>\n

\nZacznijmy od pocz\u0105tku. Jak mo\u017cemy okre\u015bli\u0107, kt\u00f3re routery przyj\u0119\u0142y takie przechwycone trasy i kt\u00f3ry ruch mo\u017ce by\u0107 przekierowywany ju\u017c dzi\u015b? Zdecydowali\u015bmy si\u0119 zacz\u0105\u0107 od prefiks\u00f3w \/25, poniewa\u017c \"nie mog\u0105 one mie\u0107 globalnego zasi\u0119gu\". Jak mo\u017cesz si\u0119 domy\u015bli\u0107 \u2014 bardzo si\u0119 pomylili\u015bmy. Ta metryka okaza\u0142a si\u0119 zbyt zaszumiona, a trasy z takimi prefiksami mog\u0105 by\u0107 nawet od operator\u00f3w Tier-1. Na przyk\u0142ad NTT posiada oko\u0142o 50 takich prefiks\u00f3w, kt\u00f3re rozprowadza w\u015br\u00f3d swoich klient\u00f3w. Z drugiej strony, ta metryka jest kiepska, poniewa\u017c takie prefiksy mog\u0105 by\u0107 filtrowane, je\u015bli operator stosuje filtrowanie ma\u0142ych prefiks\u00f3w<\/a><\/noindex>, we wszystkich kierunkach. Dlatego ta metoda nie nadaje si\u0119 do wyszukiwania wszystkich operator\u00f3w, kt\u00f3rego ruch zosta\u0142 przekierowany w wyniku podobnego incydentu.<\/p>\n

Jeszcze jednym dobrym pomys\u0142em wydawa\u0142o nam si\u0119 przyjrzenie si\u0119 POV<\/a><\/noindex>. W szczeg\u00f3lno\u015bci trasom naruszaj\u0105cym zasady maxLength odpowiedniego ROA. W ten spos\u00f3b mogliby\u015bmy znale\u017a\u0107 liczb\u0119 r\u00f3\u017cnych origin ASN ze statusem Invalid, kt\u00f3re by\u0142y widoczne dla danej AS. Niemniej jednak istnieje \"niewielki\" problem. \u015arednia warto\u015b\u0107 (mediana i moda) tej liczby (liczby r\u00f3\u017cnych origin ASN) wynosi oko\u0142o 150 i, nawet je\u015bli przefiltrujemy ma\u0142e prefiksy, wci\u0105\u017c pozostanie powy\u017cej 70. Taka sytuacja ma do\u015b\u0107 proste wyt\u0142umaczenie: jest tylko kilku operator\u00f3w, kt\u00f3rzy ju\u017c stosuj\u0105 filtry ROA z polityk\u0105 \u201eresetowania Invalid tras\u201d na punktach wej\u015bciowych, wi\u0119c gdziekolwiek na \u015bwiecie pojawi si\u0119 trasa naruszaj\u0105ca ROA, mo\u017ce ona by\u0107 rozprowadzana we wszystkich kierunkach.<\/p>\n

Ostatnie dwa podej\u015bcia pozwalaj\u0105 znale\u017a\u0107 operator\u00f3w, kt\u00f3rzy dostrzegli nasz incydent (poniewa\u017c by\u0142 on do\u015b\u0107 du\u017cy), ale og\u00f3lnie s\u0105 one niepraktyczne. Dobrze, ale czy mo\u017cemy znale\u017a\u0107 sprawc\u0119? Jakie s\u0105 og\u00f3lne cechy takiej manipulacji AS_PATH? Istnieje kilka podstawowych za\u0142o\u017ce\u0144:<\/p>\n