13 maart aan de RIPE-antimisbruikwerkgroep beschouw BGP-kaping (hjjack) als een schending van het RIPE-beleid. Als het voorstel zou worden aanvaard, zou de internetprovider die werd aangevallen door het onderscheppen van verkeer de mogelijkheid hebben om een speciaal verzoek te sturen om de aanvaller te ontmaskeren. Als het beoordelingsteam voldoende ondersteunend bewijsmateriaal verzamelde, zou de LIR die de bron was van de BGP-onderschepping als een indringer worden beschouwd en van zijn LIR-status kunnen worden ontdaan. Er waren ook enkele argumenten veranderingen.
In deze publicatie willen we een voorbeeld laten zien van een aanval waarbij niet alleen de echte aanvaller in het geding was, maar ook de hele lijst met getroffen voorvoegsels. Bovendien roept een dergelijke aanval opnieuw vragen op over de motieven voor toekomstige onderscheppingen van dit soort verkeer.
De afgelopen jaren zijn alleen conflicten als MOAS (Multiple Origin Autonomous System) in de pers als BGP-onderscheppingen behandeld. MOAS is een speciaal geval waarin twee verschillende autonome systemen conflicterende voorvoegsels adverteren met overeenkomstige ASN's in AS_PATH (de eerste ASN in AS_PATH, hierna oorsprong-ASN genoemd). We kunnen echter tenminste een naam noemen verkeersonderschepping, waardoor een aanvaller het AS_PATH-attribuut voor verschillende doeleinden kan manipuleren, waaronder het omzeilen van moderne benaderingen van filteren en monitoren. Bekend aanvalstype - het laatste type van een dergelijke onderschepping, maar helemaal niet belangrijk. Het is heel goed mogelijk dat dit precies het soort aanval is dat we de afgelopen weken hebben gezien. Een dergelijke gebeurtenis heeft een begrijpelijk karakter en vrij ernstige gevolgen.
Wie op zoek is naar de TL;DR-versie kan scrollen naar de ondertitel ‘Perfect Attack’.
Netwerk achtergrond
(om u te helpen de processen die betrokken zijn bij dit incident beter te begrijpen)
Als u een pakket wilt verzenden en er zijn meerdere voorvoegsels in de routeringstabel die het bestemmings-IP-adres bevatten, dan gebruikt u de route voor het voorvoegsel met de langste lengte. Als er meerdere verschillende routes voor hetzelfde voorvoegsel in de routeringstabel staan, kiest u de beste (volgens het beste padselectiemechanisme).
Bestaande filter- en monitoringbenaderingen proberen routes te analyseren en beslissingen te nemen door het AS_PATH-attribuut te analyseren. De router kan dit attribuut tijdens het adverteren in elke waarde veranderen. Het simpelweg toevoegen van de ASN van de eigenaar aan het begin van AS_PATH (als de oorsprong-ASN) kan voldoende zijn om de huidige oorsprongscontrolemechanismen te omzeilen. Als er bovendien een route is van de aangevallen ASN naar u, wordt het mogelijk om de AS_PATH van deze route te extraheren en te gebruiken in uw andere advertenties. Elke AS_PATH-validatiecontrole voor uw gemaakte aankondigingen zal uiteindelijk slagen.
Er zijn nog een aantal beperkingen die het vermelden waard zijn. Ten eerste, in het geval van prefixfiltering door de upstream-provider, kan uw route nog steeds worden gefilterd (zelfs met het juiste AS_PATH) als het prefix niet behoort tot uw clientkegel die upstream is geconfigureerd. Ten tweede kan een geldige AS_PATH ongeldig worden als de gemaakte route in de verkeerde richting wordt geadverteerd en daarmee het routeringsbeleid schendt. Ten slotte kan elke route met een voorvoegsel dat de ROA-lengte schendt, als ongeldig worden beschouwd.
Incident
Een paar weken geleden ontvingen wij een klacht van een van onze gebruikers. We zagen routes met de voorvoegsels van zijn oorsprong ASN en /25, terwijl de gebruiker beweerde dat hij er geen reclame voor maakte.
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||
Voorbeelden van aankondigingen voor begin april 2019
NTT in het pad voor het voorvoegsel /25 maakt het bijzonder verdacht. LG NTT was ten tijde van het incident niet op de hoogte van deze route. Dus ja, een operator maakt een volledig AS_PATH voor deze voorvoegsels! Als u andere routers controleert, wordt één specifieke ASN onthuld: AS263444. Nadat we naar andere routes met dit autonome systeem hadden gekeken, kwamen we de volgende situatie tegen:
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||
Probeer te raden wat er hier mis is
Het lijkt erop dat iemand het voorvoegsel van de route heeft overgenomen, deze in twee delen heeft gesplitst en de route heeft geadverteerd met dezelfde AS_PATH voor die twee voorvoegsels.
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||
Voorbeeldroutes voor een van de gesplitste prefixparen
Er rijzen meerdere vragen tegelijk. Heeft iemand dit soort onderschepping daadwerkelijk in de praktijk geprobeerd? Heeft iemand deze routes gevolgd? Welke voorvoegsels zijn getroffen?
Dit is waar onze reeks mislukkingen begint en opnieuw een ronde van teleurstelling over de huidige staat van de gezondheid van het internet.
Het pad van mislukking
Eerste dingen eerst. Hoe kunnen we bepalen welke routers dergelijke onderschepte routes accepteerden en wiens verkeer vandaag de dag zou kunnen worden omgeleid? We dachten dat we zouden beginnen met /25-voorvoegsels omdat deze "gewoonweg geen wereldwijde distributie kunnen hebben." Zoals je kunt raden, hadden we het helemaal mis. Deze statistiek bleek te luidruchtig en routes met dergelijke voorvoegsels kunnen zelfs verschijnen bij Tier-1-operators. NTT heeft bijvoorbeeld ongeveer 50 van dergelijke voorvoegsels, die zij onder haar eigen klanten distribueert. Aan de andere kant is deze statistiek slecht omdat dergelijke voorvoegsels kunnen worden uitgefilterd als de operator deze gebruikt , in alle richtingen. Daarom is deze methode niet geschikt om alle operators te vinden waarvan het verkeer is omgeleid als gevolg van een dergelijk incident.
Een ander goed idee waarvan we dachten dat we ernaar moesten kijken . Vooral voor routes die de maxLength-regel van de bijbehorende ROA schenden. Op deze manier konden we het aantal ASN's van verschillende oorsprong met de status Ongeldig vinden die zichtbaar waren voor een bepaalde AS. Er is echter een "klein" probleem. Het gemiddelde (mediaan en modus) van dit aantal (het aantal ASN's van verschillende oorsprong) is ongeveer 150 en zelfs als we kleine voorvoegsels eruit filteren, blijft het boven de 70. Deze stand van zaken heeft een heel eenvoudige verklaring: er zijn slechts een Er zijn maar weinig exploitanten die al ROA-filters gebruiken met een “reset ongeldige routes”-beleid op toegangspunten, zodat overal waar een route met een ROA-schending in de echte wereld verschijnt, deze zich in alle richtingen kan voortplanten.
Met de laatste twee benaderingen kunnen we operators vinden die ons incident hebben gezien (aangezien het vrij groot was), maar over het algemeen zijn ze niet van toepassing. Oké, maar kunnen we de indringer vinden? Wat zijn de algemene kenmerken van deze AS_PATH-manipulatie? Er zijn een paar basisaannames:
- Het voorvoegsel was nog nergens eerder gezien;
- Oorsprong-ASN (herinnering: eerste ASN in AS_PATH) is geldig;
- De laatste ASN in AS_PATH is de ASN van de aanvaller (in het geval dat zijn buurman de ASN van de buurman controleert op alle inkomende routes);
- De aanval is afkomstig van één enkele provider.
Als alle aannames juist zijn, zullen alle onjuiste routes de ASN van de aanvaller weergeven (behalve de ASN van oorsprong) en dit is dus een "kritiek" punt. Een van de echte kapers was AS263444, hoewel er nog meer waren. Zelfs toen we de incidentroutes buiten beschouwing lieten. Waarom? Een kritisch punt kan zelfs voor correcte routes kritisch blijven. Het kan het gevolg zijn van slechte connectiviteit in een regio of van beperkingen in onze eigen zichtbaarheid.
Als gevolg hiervan is er een manier om een aanvaller te detecteren, maar alleen als aan alle bovenstaande voorwaarden is voldaan en alleen als de onderschepping groot genoeg is om de monitoringdrempels te overschrijden. Als aan sommige van deze factoren niet wordt voldaan, kunnen we dan de voorvoegsels identificeren die onder deze onderschepping hebben geleden? Voor bepaalde operators: ja.
Wanneer een aanvaller een specifiekere route creëert, wordt een dergelijk voorvoegsel niet geadverteerd door de echte eigenaar. Als je er een dynamische lijst van alle voorvoegsels van hebt, wordt het mogelijk om een vergelijking te maken en vervormde, specifiekere routes te vinden. We verzamelen deze lijst met voorvoegsels met behulp van onze BGP-sessies, omdat we niet alleen de volledige lijst met routes krijgen die op dit moment zichtbaar zijn voor de operator, maar ook een lijst met alle voorvoegsels die hij aan de wereld wil adverteren. Helaas zijn er inmiddels enkele tientallen Radar-gebruikers die het laatste onderdeel niet correct invullen. We zullen ze binnenkort op de hoogte stellen en proberen dit probleem op te lossen. Alle anderen kunnen nu lid worden van ons monitoringsysteem.
Als we terugkeren naar het oorspronkelijke incident, zijn zowel de aanvaller als het verspreidingsgebied door ons gedetecteerd door te zoeken naar kritieke punten. Verrassend genoeg stuurde AS263444 geen verzonnen routes naar al zijn klanten. Hoewel er een vreemder moment is.
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||
Een recent voorbeeld van een poging om onze adresruimte te onderscheppen
Toen er specifiekere voor onze voorvoegsels werden gemaakt, werd een speciaal gemaakte AS_PATH gebruikt. Deze AS_PATH kan echter niet van een van onze eerdere routes zijn overgenomen. We hebben niet eens communicatie met AS6762. Kijkend naar de andere routes in het incident, hadden sommige een echte AS_PATH die eerder werd gebruikt, terwijl andere dat niet hadden, ook al lijkt het op de echte. Bovendien heeft het wijzigen van AS_PATH geen praktische zin, omdat het verkeer toch al naar de aanvaller wordt omgeleid, maar routes met een “slechte” AS_PATH kunnen worden gefilterd door ASPA of een ander inspectiemechanisme. Hier denken we na over de motivatie van de kaper. We hebben momenteel niet genoeg informatie om te bevestigen dat dit incident een geplande aanval was. Toch is het mogelijk. Laten we ons proberen een situatie voor te stellen, hoewel nog steeds hypothetisch, maar potentieel behoorlijk reëel.
Perfecte aanval
Wat we hebben? Stel dat u een transitprovider bent die routes uitzendt voor uw klanten. Als uw klanten meerdere aanwezigheid hebben (multihome), ontvangt u slechts een deel van hun verkeer. Maar hoe meer verkeer, hoe meer uw inkomen. Dus als u begint met het adverteren van subnetvoorvoegsels van dezelfde routes met hetzelfde AS_PATH, ontvangt u de rest van hun verkeer. Als gevolg hiervan blijft de rest van het geld over.
Zal ROA hierbij helpen? Misschien wel, als u besluit er helemaal mee te stoppen . Bovendien is het zeer onwenselijk om ROA-records te hebben met elkaar kruisende voorvoegsels. Voor sommige exploitanten zijn dergelijke beperkingen onaanvaardbaar.
Als we andere routeringsbeveiligingsmechanismen in ogenschouw nemen, zal ASPA in dit geval ook niet helpen (omdat het AS_PATH van een geldige route gebruikt). BGPSec is nog steeds geen optimale optie vanwege de lage acceptatiegraad en de resterende mogelijkheid van downgrade-aanvallen.
We hebben dus een duidelijke winst voor de aanvaller en een gebrek aan beveiliging. Geweldige mix!
Wat moet ik doen?
De voor de hand liggende en meest drastische stap is het herzien van uw huidige routeringsbeleid. Verdeel uw adresruimte in de kleinste stukjes (geen overlappingen) waarvoor u wilt adverteren. Onderteken ROA alleen voor hen, zonder de parameter maxLength te gebruiken. In dit geval kan uw huidige POV u van een dergelijke aanval redden. Maar nogmaals, voor sommige exploitanten is deze aanpak niet redelijk vanwege het exclusieve gebruik van meer specifieke routes. Alle problemen met de huidige status van ROA en routeobjecten zullen worden beschreven in een van onze toekomstige materialen.
Bovendien kunt u proberen dergelijke onderscheppingen te monitoren. Hiervoor hebben we betrouwbare informatie over uw voorvoegsels nodig. Als u dus een BGP-sessie met onze verzamelaar tot stand brengt en ons informatie verstrekt over uw zichtbaarheid op internet, kunnen we de mogelijkheden voor andere incidenten achterhalen. Voor degenen die nog niet zijn aangesloten op ons monitoringsysteem, is om te beginnen een lijst met routes met alleen uw voorvoegsels voldoende. Als u een sessie bij ons heeft, controleer dan of al uw routes zijn verzonden. Helaas is dit de moeite waard om te onthouden, omdat sommige operators een of twee voorvoegsels vergeten en daardoor onze zoekmethoden verstoren. Als dit correct wordt gedaan, beschikken we over betrouwbare gegevens over uw voorvoegsels, waardoor we in de toekomst deze (en andere) typen verkeersonderschepping voor uw adresruimte automatisch kunnen identificeren en detecteren.
Als u zich in realtime bewust wordt van een dergelijke onderschepping van uw verkeer, kunt u proberen dit zelf tegen te gaan. De eerste aanpak is om zelf routes met deze specifiekere voorvoegsels te adverteren. Herhaal dit in het geval van een nieuwe aanval op deze voorvoegsels.
De tweede benadering is om de aanvaller en degenen voor wie hij een cruciaal punt is (voor goede routes) te straffen door de toegang van jouw routes voor de aanvaller af te sluiten. Dit kunt u doen door de ASN van de aanvaller toe te voegen aan de AS_PATH van uw oude routes en hem zo te dwingen die AS te vermijden met behulp van het ingebouwde lusdetectiemechanisme in BGP .
Bron: www.habr.com