13. maaliskuuta RIPE väärinkäytön vastaiselle työryhmälle pitää BGP-kaappausta (hjjack) RIPE-käytännön rikkomuksena. Jos ehdotus hyväksyttäisiin, liikenteen kaappauksen kohteena olevalla Internet-palveluntarjoajalla olisi mahdollisuus lähettää erityinen pyyntö hyökkääjän paljastamiseksi. Jos arviointiryhmä keräsi riittävästi todisteita, LIR, joka oli BGP-kuuntelun lähde, katsottaisiin tunkeilijaksi ja siltä voitaisiin poistaa LIR-status. Oli myös joitain argumentteja muutoksia.
Tässä julkaisussa haluamme näyttää esimerkin hyökkäyksestä, jossa kyseessä ei ollut vain todellinen hyökkääjä, vaan myös koko luettelo vaikuttavista etuliitteistä. Lisäksi tällainen hyökkäys herättää jälleen kysymyksiä tämäntyyppisen liikenteen myöhempien sieppausten motiiveista.
Parin viime vuoden aikana vain konflikteja, kuten MOAS (Multiple Origin Autonomous System), on käsitelty lehdistössä BGP-kuunteluina. MOAS on erikoistapaus, jossa kaksi erilaista autonomista järjestelmää mainostavat ristiriitaisia etuliitteitä vastaavien ASN-numeroiden kanssa AS_PATH:ssa (ensimmäinen ASN kohdassa AS_PATH, jäljempänä alkuperä-ASN). Voimme kuitenkin nimetä ainakin liikenteen sieppaus, jonka avulla hyökkääjä voi manipuloida AS_PATH-attribuuttia eri tarkoituksiin, mukaan lukien nykyaikaisten suodatus- ja valvontamenetelmien ohittaminen. Tunnettu hyökkäystyyppi - viimeinen tällaisten sieppausten tyyppi, mutta ei lainkaan tärkeyden kannalta. On täysin mahdollista, että tämä on juuri sellainen hyökkäys, jota olemme nähneet viime viikkoina. Tällaisella tapahtumalla on ymmärrettävä luonne ja melko vakavat seuraukset.
TL;DR-versiota etsivät voivat selata "Perfect Attack" -tekstitystä.
Verkko tausta
(auttaa sinua ymmärtämään paremmin tähän tapaukseen liittyviä prosesseja)
Jos haluat lähettää paketin ja sinulla on useita etuliitteitä kohde-IP-osoitteen sisältävässä reititystaulukossa, käytät pisimmän etuliitteen reittiä. Jos reititystaulukossa on useita eri reittejä samalle etuliitteelle, valitaan paras (parhaan polunvalintamekanismin mukaan).
Nykyiset suodatus- ja valvontamenetelmät yrittävät analysoida reittejä ja tehdä päätöksiä analysoimalla AS_PATH-attribuuttia. Reititin voi muuttaa tämän määritteen mihin tahansa arvoon mainoksen aikana. Pelkästään omistajan ASN:n lisääminen AS_PATH:n alkuun (alkuperäisenä ASN:nä) saattaa riittää ohittamaan nykyiset alkuperän tarkistusmekanismit. Lisäksi, jos hyökkäyksen kohteena olevasta ASN:stä on reitti sinulle, on mahdollista poimia tämän reitin AS_PATH ja käyttää sitä muissa mainoksissasi. Kaikki vain AS_PATH-vahvistustarkistukset muotoilluille ilmoituksillesi läpäisevät lopulta.
Muutamia mainitsemisen arvoisia rajoituksia on edelleen. Ensinnäkin, jos etuliite suodattaa ylävirran palveluntarjoajaa, reittisi voidaan silti suodattaa (jopa oikealla AS_PATH), jos etuliite ei kuulu asiakaskartioosi, joka on määritetty ylävirran puolella. Toiseksi kelvollinen AS_PATH voi muuttua kelpaamattomaksi, jos luotua reittiä mainostetaan vääriin suuntiin ja siten se rikkoo reitityskäytäntöä. Lopuksi mitä tahansa reittiä, jonka etuliite rikkoo ROA:n pituutta, voidaan pitää kelpaamattomina.
tapaus
Saimme muutama viikko sitten valituksen yhdeltä käyttäjältämme. Näimme reittejä, joissa oli hänen alkuperänsä ASN ja /25-etuliitteet, kun taas käyttäjä väitti, ettei hän mainostanut niitä.
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||
Esimerkkejä huhtikuun 2019 alun ilmoituksista
Etuliitteen /25 polussa oleva NTT tekee siitä erityisen epäilyttävän. LG NTT ei ollut tietoinen tästä reitistä tapahtumahetkellä. Joten kyllä, jotkut operaattorit luovat koko AS_PATH:n näille etuliitteille! Muiden reitittimien tarkistaminen paljastaa yhden tietyn ASN:n: AS263444. Tarkasteltuamme muita tämän autonomisen järjestelmän reittejä, kohtasimme seuraavan tilanteen:
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||
Yritä arvata mikä tässä on vialla
Näyttää siltä, että joku otti etuliitettä reitiltä, jakoi sen kahteen osaan ja mainosti reittiä samalla AS_PATH:lla näille kahdelle etuliitteelle.
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||
Esimerkkireitit yhdelle jaetuista etuliitepareista
Useita kysymyksiä herää yhtä aikaa. Onko kukaan todella kokeillut tällaista sieppausta käytännössä? Onko kukaan valinnut näitä reittejä? Mihin etuliitteisiin vaikutti?
Tästä alkaa epäonnistumistemme sarja ja jälleen uusi pettymys Internetin nykyiseen tilaan.
Epäonnistumisen polku
Ensimmäiset asiat ensin. Kuinka voimme määrittää, mitkä reitittimet hyväksyivät tällaiset siepatut reitit ja kenen liikenne voitaisiin reitittää uudelleen tänään? Ajattelimme aloittaa /25-etuliitteillä, koska niillä "ei yksinkertaisesti voi olla globaalia jakelua". Kuten arvata saattaa, olimme pahasti väärässä. Tämä mittari osoittautui liian äänekkääksi ja tällaisilla etuliitteillä varustettuja reittejä voi ilmestyä jopa Tier-1-operaattoreista. Esimerkiksi NTT:llä on noin 50 tällaista etuliitettä, jotka se jakaa omille asiakkailleen. Toisaalta tämä mittari on huono, koska tällaiset etuliitteet voidaan suodattaa pois, jos operaattori käyttää , kaikkiin suuntiin. Siksi tämä menetelmä ei sovellu kaikkien operaattoreiden etsimiseen, joiden liikenne on ohjattu uudelleen tällaisen tapahtuman seurauksena.
Toinen hyvä idea, jonka ajattelimme, oli katsoa . Erityisesti reiteille, jotka rikkovat vastaavan ROA:n maxLength-sääntöä. Tällä tavalla pystyimme löytämään tietylle AS:lle näkyvien eri alkuperä-ASN-numeroiden määrän Invalid. Siinä on kuitenkin "pieni" ongelma. Tämän luvun (eri alkuperää olevien ASN-numeroiden lukumäärä) keskiarvo (mediaani ja muoto) on noin 150, ja vaikka pienet etuliitteet suodatamme pois, se pysyy yli 70:n. Tälle tilanteelle on hyvin yksinkertainen selitys: on olemassa vain harvat operaattorit, jotka jo käyttävät ROA-suodattimia "reset Invalid routes" -käytännöllä tulopisteissä, jotta missä tahansa ROA-rikkomusreitti esiintyy todellisessa maailmassa, se voi levitä kaikkiin suuntiin.
Kaksi viimeistä lähestymistapaa antavat meille mahdollisuuden löytää operaattoreita, jotka näkivät tapauksemme (koska se oli melko suuri), mutta yleensä ne eivät sovellu. Okei, mutta voimmeko löytää tunkeilijan? Mitkä ovat tämän AS_PATH-manipuloinnin yleiset ominaisuudet? On olemassa muutamia perusoletuksia:
- Etuliitettä ei ollut nähty missään aiemmin;
- Alkuperäinen ASN (muistutus: ensimmäinen ASN kohdassa AS_PATH) on kelvollinen;
- AS_PATH:n viimeinen ASN on hyökkääjän ASN (jos sen naapuri tarkistaa naapurin ASN:n kaikilla saapuvilla reiteillä);
- Hyökkäys on peräisin yhdeltä palveluntarjoajalta.
Jos kaikki oletukset ovat oikeita, kaikki väärät reitit esittävät hyökkääjän ASN:n (paitsi alkuperäisen ASN:n), ja näin ollen tämä on "kriittinen" kohta. Todellisten kaappaajien joukossa oli AS263444, vaikka muitakin oli. Jopa silloin, kun jätimme tapahtumareitit huomioimatta. Miksi? Kriittinen kohta voi jäädä kriittiseksi jopa oikeilla reiteillä. Se voi johtua joko alueen huonoista yhteyksistä tai oman näkyvyytemme rajoituksista.
Tämän seurauksena on olemassa tapa havaita hyökkääjä, mutta vain, jos kaikki yllä olevat ehdot täyttyvät ja vain silloin, kun sieppaus on riittävän suuri valvontakynnysten ylittämiseksi. Jos jotkut näistä tekijöistä eivät täyty, voimmeko tunnistaa etuliitteet, jotka kärsivät tällaisesta sieppauksesta? Tietyille operaattoreille - kyllä.
Kun hyökkääjä luo tarkemman reitin, todellinen omistaja ei mainosta tällaista etuliitettä. Jos sinulla on dynaaminen luettelo kaikista sen etuliitteistä, on mahdollista tehdä vertailu ja löytää vääristyneitä tarkempia reittejä. Keräämme tämän luettelon etuliitteistä käyttämällä BGP-istuntojamme, koska meille ei anneta vain täydellinen luettelo operaattorille juuri nyt näkyvistä reiteistä, vaan myös luettelo kaikista etuliitteistä, joita se haluaa mainostaa maailmalle. Valitettavasti nyt on useita kymmeniä Radar-käyttäjiä, jotka eivät suorita viimeistä osaa oikein. Ilmoitamme heille pian ja yritämme ratkaista tämän ongelman. Kaikki muut voivat liittyä seurantajärjestelmäämme juuri nyt.
Jos palaamme alkuperäiseen tapaukseen, havaitsimme sekä hyökkääjän että jakelualueen etsimällä kriittisiä kohtia. Yllättäen AS263444 ei lähettänyt valmistettuja reittejä kaikille asiakkailleen. Vaikka on outo hetki.
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||
Tuore esimerkki yrityksestä siepata osoiteavaruuttamme
Kun etuliitteillemme luotiin tarkempia, käytettiin erityisesti luotua AS_PATH:ta. Tätä AS_PATH:ta ei kuitenkaan voitu ottaa yhdeltäkään aikaisemmista reiteistämme. Meillä ei edes ole yhteyttä AS6762:een. Tarkasteltaessa muita tapahtuman reittejä, joillakin niistä oli todellinen AS_PATH, jota käytettiin aiemmin, kun taas toisilla ei ollut, vaikka se näyttäisikin oikealta. AS_PATH:n muuttamisessa ei myöskään ole käytännössä mitään järkeä, koska liikenne ohjataan joka tapauksessa hyökkääjälle, mutta ASPA:lla tai millä tahansa muulla tarkastusmekanismilla voidaan suodattaa reitit, joissa on "huono" AS_PATH. Tässä mietitään kaappaajan motivaatiota. Meillä ei tällä hetkellä ole tarpeeksi tietoa vahvistaaksemme, että tämä tapaus oli suunniteltu hyökkäys. Siitä huolimatta se on mahdollista. Yritetään kuvitella, vaikkakin vielä hypoteettinen, mutta mahdollisesti melko todellinen tilanne.
Täydellinen hyökkäys
Mitä meillä on? Oletetaan, että olet julkisen liikenteen tarjoaja, joka lähettää reittejä asiakkaillesi. Jos asiakkaillasi on useita läsnäoloa (multihome), saat vain osan heidän liikenteestään. Mutta mitä enemmän liikennettä, sitä enemmän tulojasi. Joten jos alat mainostaa näiden samojen reittien aliverkon etuliitteitä samalla AS_PATH:lla, saat niiden muun liikenteestä. Tämän seurauksena loput rahat.
Auttaako ROA tässä? Ehkä kyllä, jos päätät lopettaa sen käytön kokonaan . Lisäksi ei ole erittäin toivottavaa, että ROA-tietueet leikkaavat etuliitteet. Joillekin operaattoreille tällaisia rajoituksia ei voida hyväksyä.
Muut reitityksen suojausmekanismit huomioon ottaen ASPA ei auta tässäkään tapauksessa (koska se käyttää AS_PATH:ta kelvolliselta reitiltä). BGPSec ei ole vieläkään optimaalinen vaihtoehto alhaisten käyttöönottoasteiden ja jäljellä olevien alentamishyökkäysten vuoksi.
Meillä on siis selvä etu hyökkääjälle ja turvallisuuden puute. Hieno sekoitus!
Mitä minun pitäisi tehdä?
Ilmeisin ja rajuin askel on tarkistaa nykyinen reitityskäytäntösi. Jaa osoiteavaruus pienimpiin osiin (ei päällekkäisyyksiä), joita haluat mainostaa. Allekirjoita ROA vain heille ilman maxLength-parametria. Tässä tapauksessa nykyinen POV voi pelastaa sinut tällaiselta hyökkäykseltä. Joillekin operaattoreille tämä lähestymistapa ei kuitenkaan ole järkevä, koska se käyttää yksinomaan tarkempia reittejä. Kaikki ROA:n ja reittiobjektien nykyiseen tilaan liittyvät ongelmat kuvataan yhdessä tulevista materiaaleistamme.
Lisäksi voit yrittää valvoa tällaisia sieppauksia. Tätä varten tarvitsemme luotettavia tietoja etuliitteistäsi. Jos siis aloitat BGP-istunnon keräilijämme kanssa ja annat meille tietoja Internet-näkyvyydestäsi, voimme löytää mahdollisuuden muihin tapauksiin. Niille, jotka eivät vielä ole yhteydessä valvontajärjestelmäämme, riittää aluksi luettelo reiteistä pelkillä etuliitteilläsi. Jos sinulla on istunto kanssamme, tarkista, että kaikki reitit on lähetetty. Valitettavasti tämä kannattaa muistaa, koska jotkut operaattorit unohtavat etuliitteen tai kaksi ja häiritsevät siten hakumenetelmiämme. Oikein tehtynä meillä on luotettavia tietoja etuliitteistäsi, mikä auttaa meitä tulevaisuudessa automaattisesti tunnistamaan ja havaitsemaan tämän (ja muun) liikenteen sieppauksen osoiteavaruudessasi.
Jos huomaat tällaisen liikenteen sieppauksen reaaliajassa, voit yrittää torjua sitä itse. Ensimmäinen tapa on mainostaa itse reittejä näillä tarkemmilla etuliitteillä. Jos näitä etuliitteitä vastaan tulee uusi hyökkäys, toista.
Toinen tapa on rangaista hyökkääjää ja niitä, joille hän on kriittinen kohta (hyville reiteille), katkaisemalla reitesi pääsy hyökkääjälle. Tämä voidaan tehdä lisäämällä hyökkääjän ASN vanhojen reittien AS_PATH:iin ja pakottamalla heidät siten välttämään kyseistä AS:ta käyttämällä BGP:n sisäänrakennettua silmukantunnistusmekanismia. .
Lähde: will.com