La 13-an de marto al la laborgrupo RIPE kontraŭ misuzo konsideru BGP-kaperadon (hjjack) kiel malobservon de RIPE-politiko. Se la propono estus akceptita, la interreta provizanto atakita de trafika interkapto havus la ŝancon sendi specialan peton por malkaŝi la atakanton. Se la revizioteamo kolektis sufiĉan apogan indicon, la LIR kiu estis la fonto de la BGP-interkapto estus konsiderita entrudiĝinto kaj povus esti senvestigita de sia LIR-statuso. Estis ankaŭ kelkaj argumentoj ŝanĝoj.
En ĉi tiu eldonaĵo ni volas montri ekzemplon de atako, kie ne nur la vera atakanto estis priparolata, sed ankaŭ la tutan liston de tuŝitaj prefiksoj. Krome, tia atako denove levas demandojn pri la motivoj por estontaj interkaptoj de ĉi tiu tipo de trafiko.
Dum la pasintaj du jaroj, nur konfliktoj kiel MOAS (Multiple Origin Autonomous System) estis kovritaj en la gazetaro kiel BGP-interkaptoj. MOAS estas speciala kazo kie du malsamaj aŭtonomiaj sistemoj reklamas konfliktajn prefiksojn kun ekvivalentaj ASNoj en AS_PATH (la unua ASN en AS_PATH, ĉi-poste referita kiel origin ASN). Tamen ni povas nomi almenaŭ trafikinterkapto, permesante al atakanto manipuli la AS_PATH-atributon por diversaj celoj, inkluzive de preterpasi modernajn alirojn al filtrado kaj monitorado. Konata atako tipo - la lasta speco de tia interkapto, sed tute ne en graveco. Estas tute eble, ke ĉi tio estas ĝuste la speco de atako, kiun ni vidis dum la pasintaj semajnoj. Tia evento havas kompreneblan naturon kaj sufiĉe gravajn sekvojn.
Tiuj, kiuj serĉas la TL;DR-version, povas ruliĝi al la subtitolo "Perfect Attack".
Reta fono
(por helpi vin pli bone kompreni la procezojn implikitajn en ĉi tiu okazaĵo)
Se vi volas sendi pakaĵeton kaj vi havas plurajn prefiksojn en la vojtabelo enhavanta la celan IP-adreson, tiam vi uzos la itineron por la prefikso kun la plej longa longo. Se estas pluraj malsamaj vojoj por la sama prefikso en la vojtabelo, vi elektos la plej bonan (laŭ la plej bona vojo elekta mekanismo).
Ekzistantaj filtraj kaj monitoraj aliroj provas analizi itinerojn kaj fari decidojn analizante la AS_PATH-atributon. La enkursigilo povas ŝanĝi ĉi tiun atributon al iu ajn valoro dum reklamado. Simple aldoni la ASN de la posedanto komence de AS_PATH (kiel la origino ASN) povas sufiĉi por preteriri nunajn originkontrolajn mekanismojn. Plie, se ekzistas itinero de la atakita ASN al vi, fariĝas eble ĉerpi kaj uzi la AS_PATH de ĉi tiu itinero en viaj aliaj reklamoj. Ajna AS_PATH-nur-konfirmkontrolo por viaj kreitaj anoncoj eventuale trapasos.
Estas ankoraŭ kelkaj limigoj menciindaj. Unue, en kazo de prefiksa filtrado de la kontraŭflua provizanto, via itinero ankoraŭ povas esti filtrita (eĉ kun la ĝusta AS_PATH) se la prefikso ne apartenas al via klientkonuso agordita ĉe la kontraŭfluo. Due, valida AS_PATH povas iĝi malvalida se la kreita itinero estas reklamita en malĝustaj direktoj kaj, tiel, malobservas la vojpolitikon. Finfine, ajna itinero kun prefikso kiu malobservas la ROA-longon povas esti konsiderata nevalida.
Okazaĵo
Antaŭ kelkaj semajnoj ni ricevis plendon de unu el niaj uzantoj. Ni vidis itinerojn kun lia origino ASN kaj /25 prefiksoj, dum la uzanto asertis ke li ne reklamis ilin.
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||
Ekzemploj de anoncoj por la komenco de aprilo 2019
NTT en la vojo por la /25 prefikso faras ĝin speciale suspektinda. LG NTT ne sciis pri ĉi tiu itinero dum la okazaĵo. Do jes, iu operatoro kreas tutan AS_PATH por ĉi tiuj prefiksoj! Kontroli aliajn enkursigilojn malkaŝas unu apartan ASN: AS263444. Post rigardi aliajn itinerojn kun ĉi tiu aŭtonoma sistemo, ni renkontis la sekvan situacion:
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||
Provu diveni, kio malbonas ĉi tie
Ŝajnas ke iu prenis la prefikson de la itinero, dividis ĝin en du partojn, kaj reklamis la itineron kun la sama AS_PATH por tiuj du prefiksoj.
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||
Ekzemplaj itineroj por unu el la dividitaj prefiksaj paroj
Pluraj demandoj ekestas samtempe. Ĉu iu efektive provis tian interkapton en la praktiko? Ĉu iu prenis ĉi tiujn vojojn? Kiuj prefiksoj estis tuŝitaj?
Ĉi tie komenciĝas nia ŝnuro de fiaskoj kaj ankoraŭ plia raŭndo de seniluziiĝo kun la nuna stato de la sano de Interreto.
La vojo de fiasko
Unuaj aferoj unue. Kiel ni povas determini kiuj enkursigiloj akceptis tiajn kaptitajn itinerojn kaj kies trafiko povus esti redirektita hodiaŭ? Ni pensis, ke ni komencus per /25-prefiksoj ĉar ili "simple ne povas havi tutmondan distribuon." Kiel vi povas supozi, ni tre eraris. Ĉi tiu metriko montriĝis tro brua kaj itineroj kun tiaj prefiksoj povas aperi eĉ de Tier-1-funkciigistoj. Ekzemple, NTT havas ĉirkaŭ 50 tiajn prefiksojn, kiujn ĝi distribuas al siaj propraj klientoj. Aliflanke, ĉi tiu metriko estas malbona ĉar tiaj prefiksoj povas esti filtritaj se la funkciigisto uzas , en ĉiuj direktoj. Tial ĉi tiu metodo ne taŭgas por trovi ĉiujn funkciigistojn, kies trafiko estis alidirektita kiel rezulto de tia okazaĵo.
Alia bona ideo, kiun ni pensis, estis rigardi . Precipe por itineroj kiuj malobservas la maxLength-regulon de la responda ROA. Tiel ni povus trovi la nombron da malsamaj origin-ASN-oj kun statuso Nevalidaj, kiuj estis videblaj al donita AS. Tamen estas "malgranda" problemo. La mezumo (mediano kaj reĝimo) de ĉi tiu nombro (la nombro de malsamaj originaj ASN-oj) estas proksimume 150 kaj, eĉ se ni filtras malgrandajn prefiksojn, ĝi restas super 70. Ĉi tiu stato havas tre simplan klarigon: ekzistas nur malmultaj funkciigistoj kiuj jam uzas ROA-filtrilojn kun "restarigi Malvalidaj itineroj" politiko ĉe enirpunktoj, tiel ke kie ajn itinero kun ROA-malobservo aperas en la reala mondo, ĝi povas disvastigi en ĉiuj direktoj.
La lastaj du aliroj permesas al ni trovi funkciigistojn kiuj vidis nian okazaĵon (ĉar ĝi estis sufiĉe granda), sed ĝenerale ili ne estas aplikeblaj. Bone, sed ĉu ni povas trovi la entrudiĝinton? Kio estas la ĝeneralaj trajtoj de ĉi tiu AS_PATH-manipulado? Estas kelkaj bazaj supozoj:
- La prefikso nenie antaŭe estis vidita;
- Origina ASN (rememorigilo: unua ASN en AS_PATH) validas;
- La lasta ASN en AS_PATH estas la ASN de la atakanto (kaze ĝia najbaro kontrolas la ASN de la najbaro sur ĉiuj envenantaj itineroj);
- La atako devenas de ununura provizanto.
Se ĉiuj supozoj estas ĝustaj, tiam ĉiuj malĝustaj itineroj prezentos la ASN de la atakanto (krom la origino ASN) kaj, tiel, tio estas "kritika" punkto. Inter la veraj aviadilkaperistoj estis AS263444, kvankam estis aliaj. Eĉ kiam ni forĵetis la okazaĵajn itinerojn de konsidero. Kial? Kritika punkto povas resti kritika eĉ por ĝustaj itineroj. Ĝi povas aŭ esti la rezulto de malbona konektebleco en regiono aŭ limigoj en nia propra videbleco.
Kiel rezulto, ekzistas maniero detekti atakanton, sed nur se ĉiuj ĉi-supraj kondiĉoj estas plenumitaj kaj nur kiam la interkapto estas sufiĉe granda por pasi la monitorajn sojlojn. Se kelkaj el ĉi tiuj faktoroj ne estas renkontitaj, tiam ni povas identigi la prefiksojn kiuj suferis de tia interkapto? Por certaj funkciigistoj - jes.
Kiam atakanto kreas pli specifan itineron, tia prefikso ne estas reklamita de la vera posedanto. Se vi havas dinamikan liston de ĉiuj ĝiaj prefiksoj de ĝi, tiam eblos fari komparon kaj trovi distorditajn pli specifajn itinerojn. Ni kolektas ĉi tiun liston de prefiksoj uzante niajn BGP-sesiojn, ĉar ni ricevas ne nur la plenan liston de itineroj videblaj al la funkciigisto nun, sed ankaŭ liston de ĉiuj prefiksoj kiujn ĝi volas reklami al la mondo. Bedaŭrinde, estas nun kelkaj dekoj da Radaraj uzantoj, kiuj ne kompletigas la lastan parton ĝuste. Ni informos ilin baldaŭ kaj provos solvi ĉi tiun problemon. Ĉiuj aliaj povas aliĝi al nia monitora sistemo nun.
Se ni revenas al la originala okazaĵo, kaj la atakanto kaj la distribuareo estis detektitaj de ni serĉante kritikajn punktojn. Surprize, AS263444 ne sendis fabrikitajn itinerojn al ĉiuj siaj klientoj. Kvankam estas pli stranga momento.
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||
Lastatempa ekzemplo de provo kapti nian adresspacon
Kiam oni kreis pli specifajn por niaj prefiksoj, oni uzis speciale kreitan AS_PATH. Tamen ĉi tiu AS_PATH ne povus esti prenita de iu ajn el niaj antaŭaj itineroj. Ni eĉ ne havas komunikadon kun AS6762. Rigardante la aliajn itinerojn en la okazaĵo, kelkaj el ili havis veran AS_PATH kiu antaŭe estis uzita, dum aliaj ne havis, eĉ se ĝi aspektas kiel la vera. Ŝanĝi AS_PATH krome ne havas ajnan praktikan sencon, ĉar la trafiko estos redirektita al la atakanto ĉiukaze, sed itineroj kun "malbona" AS_PATH povas esti filtritaj per ASPA aŭ ajna alia inspekta mekanismo. Ĉi tie ni pensas pri la instigo de la aviadilkaperisto. Ni nuntempe ne havas sufiĉajn informojn por konfirmi, ke ĉi tiu okazaĵo estis planita atako. Tamen, ĝi eblas. Ni provu imagi, kvankam ankoraŭ hipotezan, sed eble sufiĉe realan, situacion.
Perfekta Atako
Kion ni havas? Ni diru, ke vi estas transita provizanto dissendanta itinerojn por viaj klientoj. Se viaj klientoj havas multoblan ĉeeston (multihome), tiam vi ricevos nur parton de ilia trafiko. Sed ju pli da trafiko, des pli estas via enspezo. Do se vi komencas reklami subretajn prefiksojn de ĉi tiuj samaj itineroj kun la sama AS_PATH, vi ricevos la reston de ilia trafiko. Kiel rezulto, la resto de la mono.
Ĉu ROA helpos ĉi tie? Eble jes, se vi decidas tute ĉesi uzi ĝin . Krome, estas tre nedezirinda havi ROA-rekordojn kun intersekcantaj prefiksoj. Por iuj funkciigistoj tiaj limigoj estas neakcepteblaj.
Konsiderante aliajn sekurecmekanismojn pri vojigo, ASPA ankaŭ ne helpos ĉi-kaze (ĉar ĝi uzas AS_PATH de valida itinero). BGPSec ankoraŭ ne estas optimuma opcio pro malaltaj adoptoprocentoj kaj la restanta ebleco de malaltigo de atakoj.
Do ni havas klaran gajnon por la atakanto kaj mankon de sekureco. Bonega miksaĵo!
Kion mi faru?
La evidenta kaj plej drasta paŝo estas revizii vian nunan enrutigan politikon. Rompu vian adresspacon en la plej malgrandajn pecojn (sen interkovroj) kiujn vi volas reklami. Subskribu ROA nur por ili, sen uzi la parametron maxLength. En ĉi tiu kazo, via nuna POV povas savi vin de tia atako. Tamen, denove, por kelkaj funkciigistoj tiu aliro ne estas akceptebla pro la ekskluziva uzo de pli specifaj itineroj. Ĉiuj problemoj kun la nuna stato de ROA kaj itinerobjektoj estos priskribitaj en unu el niaj estontaj materialoj.
Krome, vi povas provi kontroli tiajn interkaptojn. Por fari tion, ni bezonas fidindajn informojn pri viaj prefiksoj. Tiel, se vi establas BGP-sesion kun nia kolektanto kaj provizas al ni informojn pri via interreta videbleco, ni povas trovi la amplekson por aliaj okazaĵoj. Por tiuj, kiuj ankoraŭ ne estas konektitaj al nia monitorsistemo, por komenci, sufiĉos listo de itineroj nur kun viaj prefiksoj. Se vi havas kunsidon kun ni, bonvolu kontroli, ke ĉiuj viaj itineroj estas senditaj. Bedaŭrinde, ĉi tio estas memorinda ĉar iuj operatoroj forgesas prefikson aŭ du kaj tiel malhelpas niajn serĉmetodojn. Se farite ĝuste, ni havos fidindajn datumojn pri viaj prefiksoj, kiuj estonte helpos nin aŭtomate identigi kaj detekti ĉi tiun (kaj aliajn) specojn de trafika interkapto por via adresspaco.
Se vi konscias pri tia interkapto de via trafiko en reala tempo, vi povas provi kontraŭstari ĝin mem. La unua aliro estas reklami itinerojn kun ĉi tiuj pli specifaj prefiksoj mem. En kazo de nova atako al ĉi tiuj prefiksoj, ripetu.
La dua aliro estas puni la atakanton kaj tiujn por kiuj li estas kritika punkto (por bonaj itineroj) fortranĉante la aliron de viaj itineroj al la atakanto. Ĉi tio povas esti farita aldonante la ASN de la atakanto al la AS_PATH de viaj malnovaj itineroj kaj tiel devigi ilin eviti tiun AS uzante la enkonstruitan buklan detektan mekanismon en BGP. .
fonto: www.habr.com