Marso 13 sa RIPE anti-abuse working group isaalang-alang ang BGP hijacking (hjjack) bilang isang paglabag sa RIPE policy. Kung tinanggap ang panukala, magkakaroon ng pagkakataon ang Internet provider na inatake ng traffic interception na magpadala ng espesyal na kahilingan para ilantad ang umaatake. Kung ang pangkat ng pagsusuri ay nangolekta ng sapat na sumusuportang ebidensya, ang LIR na pinagmulan ng pagharang ng BGP ay ituring na isang nanghihimasok at maaaring alisin sa katayuan ng LIR nito. Nagkaroon din ng ilang argumento mga pagbabago.
Sa publication na ito gusto naming magpakita ng halimbawa ng isang pag-atake kung saan hindi lang ang tunay na umaatake ang pinag-uusapan, kundi pati na rin ang buong listahan ng mga apektadong prefix. Higit pa rito, ang gayong pag-atake ay muling nagdudulot ng mga tanong tungkol sa mga motibo para sa mga pagharang sa hinaharap ng ganitong uri ng trapiko.
Sa nakalipas na ilang taon, ang mga salungatan lang tulad ng MOAS (Multiple Origin Autonomous System) ang na-cover sa press bilang mga pagharang ng BGP. Ang MOAS ay isang espesyal na kaso kung saan ang dalawang magkaibang autonomous system ay nag-a-advertise ng magkasalungat na prefix na may katumbas na mga ASN sa AS_PATH (ang unang ASN sa AS_PATH, pagkatapos nito ay tinutukoy bilang pinagmulang ASN). Gayunpaman, maaari naming pangalanan ang hindi bababa sa traffic interception, na nagpapahintulot sa isang attacker na manipulahin ang AS_PATH attribute para sa iba't ibang layunin, kabilang ang pag-bypass sa mga modernong diskarte sa pag-filter at pagsubaybay. Kilalang uri ng pag-atake - ang huling uri ng naturang pagharang, ngunit hindi mahalaga. Posible na ito mismo ang uri ng pag-atake na nakita natin sa mga nakaraang linggo. Ang ganitong kaganapan ay may isang maliwanag na kalikasan at medyo malubhang kahihinatnan.
Ang mga naghahanap ng bersyon ng TL;DR ay maaaring mag-scroll sa subtitle na "Perfect Attack".
Background ng network
(upang matulungan kang mas maunawaan ang mga prosesong kasangkot sa insidenteng ito)
Kung gusto mong magpadala ng packet at marami kang prefix sa routing table na naglalaman ng patutunguhang IP address, gagamitin mo ang ruta para sa prefix na may pinakamahabang haba. Kung mayroong ilang magkakaibang ruta para sa parehong prefix sa routing table, pipiliin mo ang pinakamahusay (ayon sa pinakamahusay na mekanismo ng pagpili ng landas).
Sinusubukan ng mga kasalukuyang diskarte sa pag-filter at pagsubaybay na suriin ang mga ruta at gumawa ng mga desisyon sa pamamagitan ng pagsusuri sa katangiang AS_PATH. Maaaring baguhin ng router ang katangiang ito sa anumang halaga sa panahon ng advertisement. Ang pagdaragdag lamang ng ASN ng may-ari sa simula ng AS_PATH (bilang ang pinagmulang ASN) ay maaaring sapat na upang i-bypass ang kasalukuyang mga mekanismo ng pagsuri sa pinagmulan. Bukod dito, kung mayroong ruta mula sa inaatakeng ASN papunta sa iyo, magiging posible na kunin at gamitin ang AS_PATH ng rutang ito sa iyong iba pang mga advertisement. Ang anumang pagsusuri sa pagpapatunay na AS_PATH lamang para sa iyong mga ginawang anunsyo ay papasa sa kalaunan.
Mayroon pa ring ilang mga limitasyon na dapat banggitin. Una, sa kaso ng pag-filter ng prefix ng upstream provider, maaari pa ring ma-filter ang iyong ruta (kahit na may tamang AS_PATH) kung ang prefix ay hindi kabilang sa iyong client cone na na-configure sa upstream. Pangalawa, ang isang wastong AS_PATH ay maaaring maging invalid kung ang ginawang ruta ay ina-advertise sa mga maling direksyon at, sa gayon, lumalabag sa patakaran sa pagruruta. Panghuli, ang anumang ruta na may prefix na lumalabag sa haba ng ROA ay maaaring ituring na hindi wasto.
Nagkataon
Ilang linggo ang nakalipas nakatanggap kami ng reklamo mula sa isa sa aming mga user. Nakakita kami ng mga ruta na may pinagmulang ASN at /25 na prefix, habang sinabi ng user na hindi niya ina-advertise ang mga ito.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Mga halimbawa ng mga anunsyo para sa simula ng Abril 2019
Ang NTT sa path para sa /25 prefix ay ginagawa itong lalo na kahina-hinala. Hindi alam ng LG NTT ang rutang ito sa oras ng insidente. Kaya oo, ang ilang operator ay gumagawa ng isang buong AS_PATH para sa mga prefix na ito! Ang pagsuri sa ibang mga router ay nagpapakita ng isang partikular na ASN: AS263444. Matapos tingnan ang iba pang mga ruta na may ganitong autonomous system, nakatagpo kami ng sumusunod na sitwasyon:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Subukan mong hulaan kung ano ang mali dito
Lumalabas na may kumuha ng prefix mula sa ruta, hinati ito sa dalawang bahagi, at nag-advertise ng ruta na may parehong AS_PATH para sa dalawang prefix na iyon.
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||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_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||
TABLE_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||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Mga halimbawang ruta para sa isa sa mga split prefix na pares
Maraming mga katanungan ang lumitaw nang sabay-sabay. May sinuman ba talagang sinubukan ang ganitong uri ng pagharang sa pagsasanay? Mayroon bang tumahak sa mga rutang ito? Anong mga prefix ang naapektuhan?
Dito magsisimula ang aming string ng mga pagkabigo at isa pang round ng pagkabigo sa kasalukuyang kalagayan ng kalusugan ng Internet.
Ang landas ng kabiguan
Una sa lahat. Paano natin matutukoy kung aling mga router ang tumanggap ng mga na-intercept na ruta at kaninong trapiko ang maaaring i-reroute ngayon? Naisip namin na magsisimula kami sa mga prefix na /25 dahil ang mga ito ay "simpleng hindi maaaring magkaroon ng pandaigdigang pamamahagi." Tulad ng maaari mong hulaan, kami ay napaka mali. Ang sukatan na ito ay naging masyadong maingay at ang mga rutang may ganitong mga prefix ay maaaring lumabas kahit na mula sa mga Tier-1 na operator. Halimbawa, ang NTT ay may humigit-kumulang 50 tulad ng mga prefix, na ipinamamahagi nito sa sarili nitong mga kliyente. Sa kabilang banda, ang sukatang ito ay masama dahil ang mga naturang prefix ay maaaring i-filter out kung ang operator ay gumagamit , sa lahat ng direksyon. Samakatuwid, ang pamamaraang ito ay hindi angkop para sa paghahanap ng lahat ng mga operator na ang trapiko ay na-redirect bilang resulta ng naturang insidente.
Isa pang magandang ideya na naisip namin ay tingnan . Lalo na para sa mga rutang lumalabag sa maxLength na panuntunan ng kaukulang ROA. Sa ganitong paraan, mahahanap namin ang bilang ng iba't ibang pinagmulang ASN na may katayuang Di-wasto na nakikita ng isang ibinigay na AS. Gayunpaman, mayroong isang "maliit" na problema. Ang average (median at mode) ng numerong ito (ang bilang ng iba't ibang pinagmulang ASN) ay humigit-kumulang 150 at, kahit na i-filter natin ang maliliit na prefix, nananatili itong higit sa 70. Ang kalagayang ito ay may napakasimpleng paliwanag: mayroon lamang ilang operator na gumagamit na ng mga ROA-filter na may patakarang "i-reset ang mga Invalid na ruta" sa mga entry point, upang saanman lumitaw ang isang ruta na may paglabag sa ROA sa totoong mundo, maaari itong magpalaganap sa lahat ng direksyon.
Ang huling dalawang diskarte ay nagbibigay-daan sa amin na makahanap ng mga operator na nakakita sa aming insidente (dahil ito ay medyo malaki), ngunit sa pangkalahatan ay hindi ito naaangkop. Okay, ngunit maaari ba nating mahanap ang nanghihimasok? Ano ang mga pangkalahatang tampok ng pagmamanipula ng AS_PATH na ito? Mayroong ilang mga pangunahing pagpapalagay:
- Ang prefix ay hindi nakita kahit saan dati;
- Ang Origin ASN (paalala: unang ASN sa AS_PATH) ay may bisa;
- Ang huling ASN sa AS_PATH ay ang ASN ng umaatake (kung sakaling suriin ng kapitbahay nito ang ASN ng kapitbahay sa lahat ng papasok na ruta);
- Ang pag-atake ay nagmula sa iisang provider.
Kung tama ang lahat ng mga pagpapalagay, ang lahat ng maling ruta ay magpapakita ng ASN ng umaatake (maliban sa pinagmulang ASN) at, sa gayon, ito ay isang "kritikal" na punto. Kabilang sa mga totoong hijacker ay ang AS263444, bagama't may iba pa. Kahit na itinapon namin ang mga ruta ng insidente mula sa pagsasaalang-alang. Bakit? Ang isang kritikal na punto ay maaaring manatiling kritikal kahit para sa mga tamang ruta. Maaaring ito ay resulta ng mahinang koneksyon sa isang rehiyon o mga limitasyon sa sarili nating visibility.
Bilang resulta, mayroong isang paraan upang matukoy ang isang umaatake, ngunit kung ang lahat ng mga kundisyon sa itaas ay natutugunan at kapag ang pagharang ay sapat na malaki upang makapasa sa mga limitasyon sa pagsubaybay. Kung ang ilan sa mga salik na ito ay hindi natutugunan, maaari ba nating tukuyin ang mga prefix na nagdusa mula sa naturang pagharang? Para sa ilang mga operator - oo.
Kapag ang isang umaatake ay lumikha ng isang mas tiyak na ruta, ang naturang prefix ay hindi ina-advertise ng tunay na may-ari. Kung mayroon kang isang dynamic na listahan ng lahat ng mga prefix nito mula dito, magiging posible na gumawa ng paghahambing at makahanap ng mga pangit na mas tiyak na mga ruta. Kinokolekta namin ang listahang ito ng mga prefix gamit ang aming mga session sa BGP, dahil binibigyan kami hindi lamang ng buong listahan ng mga ruta na nakikita ng operator ngayon, kundi pati na rin ng listahan ng lahat ng prefix na gusto nitong i-advertise sa mundo. Sa kasamaang palad, mayroon na ngayong ilang dosenang mga gumagamit ng Radar na hindi nakumpleto nang tama ang huling bahagi. Aabisuhan namin sila sa ilang sandali at susubukan naming lutasin ang isyung ito. Ang lahat ay maaaring sumali sa aming monitoring system ngayon.
Kung babalik kami sa orihinal na insidente, ang umaatake at ang lugar ng pamamahagi ay natukoy namin sa pamamagitan ng paghahanap ng mga kritikal na punto. Nakapagtataka, ang AS263444 ay hindi nagpadala ng mga gawa-gawang ruta sa lahat ng mga kliyente nito. Bagama't may isang estranghero sandali.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Isang kamakailang halimbawa ng isang pagtatangkang hadlangan ang aming address space
Kapag ginawa ang mga mas tiyak para sa aming mga prefix, ginamit ang isang espesyal na nilikhang AS_PATH. Gayunpaman, ang AS_PATH na ito ay hindi maaaring makuha mula sa alinman sa aming mga nakaraang ruta. Wala rin kaming komunikasyon sa AS6762. Sa pagtingin sa iba pang mga ruta sa insidente, ang ilan sa mga ito ay may totoong AS_PATH na dati nang ginamit, habang ang iba ay wala, kahit na ito ay mukhang tunay. Ang pagpapalit ng AS_PATH sa karagdagan ay walang anumang praktikal na kahulugan, dahil ang trapiko ay ire-redirect pa rin sa umaatake, ngunit ang mga rutang may "masamang" AS_PATH ay maaaring i-filter ng ASPA o anumang iba pang mekanismo ng inspeksyon. Dito namin iniisip ang tungkol sa motibasyon ng hijacker. Kasalukuyan kaming walang sapat na impormasyon upang kumpirmahin na ang insidenteng ito ay isang binalak na pag-atake. Gayunpaman, posible. Subukan nating isipin, bagaman hypothetical pa rin, ngunit potensyal na medyo totoo, isang sitwasyon.
Perpektong Pag-atake
Kung anong meron tayo? Sabihin nating isa kang transit provider na nag-broadcast ng mga ruta para sa iyong mga kliyente. Kung marami ang presensya ng iyong mga kliyente (multihome), bahagi lang ng kanilang trapiko ang matatanggap mo. Ngunit kung mas maraming trapiko, mas marami ang iyong kita. Kaya kung sisimulan mo ang pag-advertise ng mga subnet prefix ng parehong mga ruta na ito na may parehong AS_PATH, matatanggap mo ang natitirang bahagi ng kanilang trapiko. Bilang resulta, ang natitirang pera.
Makakatulong ba ang ROA dito? Marahil ay oo, kung magpasya kang ganap na ihinto ang paggamit nito . Bilang karagdagan, lubos na hindi kanais-nais na magkaroon ng mga tala ng ROA na may mga intersecting prefix. Para sa ilang mga operator, ang mga naturang paghihigpit ay hindi katanggap-tanggap.
Isinasaalang-alang ang iba pang mekanismo ng seguridad sa pagruruta, hindi rin makakatulong ang ASPA sa kasong ito (dahil gumagamit ito ng AS_PATH mula sa isang wastong ruta). Hindi pa rin pinakamainam na opsyon ang BGPSec dahil sa mababang mga rate ng pag-aampon at ang natitirang posibilidad ng mga pag-atake sa pag-downgrade.
Kaya mayroon kaming malinaw na pakinabang para sa umaatake at kakulangan ng seguridad. Mahusay na halo!
Ano ang dapat kong gawin?
Ang halata at pinakamarahas na hakbang ay suriin ang iyong kasalukuyang patakaran sa pagruruta. Hatiin ang puwang ng iyong address sa pinakamaliit na piraso (walang mga overlap) na gusto mong i-advertise. Mag-sign ROA para sa kanila lang, nang hindi ginagamit ang maxLength parameter. Sa kasong ito, maililigtas ka ng iyong kasalukuyang POV mula sa gayong pag-atake. Gayunpaman, muli, para sa ilang mga operator ang diskarte na ito ay hindi makatwiran dahil sa eksklusibong paggamit ng mas tiyak na mga ruta. Ang lahat ng mga problema sa kasalukuyang estado ng ROA at mga bagay sa ruta ay ilalarawan sa isa sa aming mga materyal sa hinaharap.
Bilang karagdagan, maaari mong subukang subaybayan ang mga naturang pagharang. Upang gawin ito, kailangan namin ng maaasahang impormasyon tungkol sa iyong mga prefix. Kaya, kung magtatatag ka ng session ng BGP kasama ang aming kolektor at bibigyan kami ng impormasyon tungkol sa iyong visibility sa Internet, mahahanap namin ang saklaw para sa iba pang mga insidente. Para sa mga hindi pa konektado sa aming monitoring system, sa simula, isang listahan ng mga ruta lamang na may mga prefix ay sapat na. Kung mayroon kang sesyon sa amin, pakitiyak na naipadala na ang lahat ng iyong ruta. Sa kasamaang palad, ito ay nagkakahalaga ng pag-alala dahil ang ilang mga operator ay nakakalimutan ng isang prefix o dalawa at sa gayon ay nakakasagabal sa aming mga paraan ng paghahanap. Kung nagawa nang tama, magkakaroon kami ng mapagkakatiwalaang data tungkol sa iyong mga prefix, na sa hinaharap ay makakatulong sa aming awtomatikong tukuyin at matukoy ito (at iba pang) uri ng pagharang ng trapiko para sa iyong address space.
Kung nalaman mo ang gayong pagharang sa iyong trapiko sa real time, maaari mong subukang kontrahin ito mismo. Ang unang diskarte ay ang mag-advertise ng mga ruta gamit ang mga mas partikular na prefix na ito. Sa kaso ng isang bagong pag-atake sa mga prefix na ito, ulitin.
Ang pangalawang diskarte ay parusahan ang umaatake at ang mga taong siya ay isang kritikal na punto (para sa mahusay na mga ruta) sa pamamagitan ng pagputol ng access ng iyong mga ruta sa umaatake. Magagawa ito sa pamamagitan ng pagdaragdag ng ASN ng umaatake sa AS_PATH ng iyong mga lumang ruta at sa gayon ay pilitin silang iwasan ang AS na iyon gamit ang built-in na mekanismo ng pagtuklas ng loop sa BGP .
Pinagmulan: www.habr.com