13 maart in de werkgroep RIPE voor de bestrijding van misbruik om BGP-hijacking (hjjack) te beschouwen als een schending van de RIPE-beleid. Als het voorstel wordt aangenomen, zou de internetprovider die het doelwit is van de verkeershijacking de mogelijkheid krijgen om een speciale aanvraag in te dienen om de aanvaller aan de kaak te stellen. Als de experts voldoende bewijs verzamelen, zou een dergelijke LIR, die de bron van de BGP-hijacking is, als overtreder worden beschouwd en het LIR-status kunnen verliezen. Er waren ook enkele argumenten wijziging.
In deze publicatie willen we een voorbeeld tonen van een aanval waarbij niet alleen de werkelijke aanvaller ter discussie stond, maar ook de hele lijst van getroffen prefixen. Bovendien roept een dergelijke aanval opnieuw vragen op over de motieven van toekomstige type verkeershijackingen.
De afgelopen paar jaar zijn in de pers alleen conflicten van het type MOAS (Multiple Origin Autonomous System) als BGP-hijackingen belicht. MOAS is een specifiek geval waarin twee verschillende autonome systemen concurrerende prefixes aankondigen met de bijbehorende ASN-nummers in AS_PATH (de eerste ASN in AS_PATH, hierna origin ASN genoemd). Echter, we kunnen minstens verkeershijacking identificeren, waarmee de aanvaller het AS_PATH-attribuut kan manipuleren met verschillende doelen, inclusief het omzeilen van moderne filtering en monitoringstechnieken. Een bekende type aanval is de laatste type van dergelijke hijacking, maar zeker niet de minste. Het is goed mogelijk dat dit de aanval is die we de afgelopen weken hebben waargenomen. Dit soort gebeurtenis heeft een begrijpelijke achtergrond en voldoende ernstige gevolgen.
Degenen die een TL;DR-versie zoeken, kunnen naar de subkop Ā«Ideale aanvalĀ» scrollen.
Netwerkachtergrond
(om u een beter begrip te geven van de processen die bij dit voorval betrokken zijn)
Als u een pakket wilt verzenden en u heeft meerdere prefixes in de routeringstabel met het bestemmings IP-adres, dan zult u de route voor de prefix met de grootste lengte gebruiken. Als er echter meerdere verschillende routes voor Ć©Ć©n prefix in de routeringstabel bestaan, kiest u de beste (volgens het mechanisme voor het kiezen van de beste route).
Bestaande benaderingen voor filtering en monitoring proberen routes te analyseren en beslissingen te nemen door de AS_PATH-attribuut te analyseren. De router kan dit attribuut tijdens de aankondiging op elke waarde wijzigen. Het eenvoudig toevoegen van de ASN van de eigenaar aan het begin van AS_PATH (als origin ASN) kan voldoende zijn om de huidige mechanismen voor bronvalidatie te omzeilen. Bovendien, als er een route van de aangevallen ASN naar u bestaat, ontstaat de mogelijkheid om de AS_PATH van die route te extraheren en in uw andere aankondigingen te gebruiken. Iedere validatie die alleen de AS_PATH voor uw gefabriceerde aankondigingen controleert, zal uiteindelijk slagen.
Daarnaast zijn er nog verschillende noemenswaardige beperkingen. Ten eerste, in het geval van prefix filtering door een hogere provider kan uw route nog steeds gefilterd worden (zelfs met een correcte AS_PATH), als de prefix niet behoort tot uw klantconus die bij de upstream is ingesteld. Ten tweede, een geldige AS_PATH kan ongeldig worden als de gemaakte route in onjuiste richtingen wordt aangekondigd en daarmee de routeringspolicy schendt. En tot slot, elke route met een prefix die de ROA-lengte schendt, kan als ongeldig worden beschouwd.
Incident
Enkele weken geleden ontvingen we een klacht van een van de gebruikers. We zagen routes met zijn origin ASN en prefixes /25, terwijl de gebruiker beweerde dat hij ze niet had aangekondigd.
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 begin april 2019
NTT op weg met de prefix /25 maakt het bijzonder verdacht. Tijdens het incident was LG NTT niet op de hoogte van deze route. Dus ja, een of andere operator creƫert een hele AS_PATH voor deze prefixes! Controle op andere routers toont een bijzonder ASN aan: AS263444. Bij het bekijken van andere routes met dit autonome systeem, 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 hier niet klopt
Het lijkt erop dat iemand de prefix uit de route heeft genomen, deze in twee delen heeft gesplitst en een route heeft aangekondigd met dezelfde AS_PATH voor deze twee prefixes.
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||
Voorbeelden van routes voor een van de paren van gesplitste prefixes
Er rijzen onmiddellijk meerdere vragen. Heeft iemand werkelijk geprobeerd deze vorm van onderschepping in de praktijk? Heeft iemand deze routes geaccepteerd? Welke prefixes waren betroffen?
Hier begint onze reeks teleurstellingen en opnieuw een ronde van frustratie over de huidige staat van het internet.
De weg van teleurstellingen
Laten we alles stap voor stap doornemen. Hoe kunnen we bepalen welke routers zulke onderschepte routes hebben aangenomen en wiens verkeer vandaag al kan worden omgeleid? We dachten te beginnen met de prefixes /25, omdat ze "gewoon niet globaal kunnen zijn verspreid". Zoals je kunt raden, hebben we ons daarin flink vergist. Deze metriek bleek te veel ruis te bevatten en routes met zulke prefixes kunnen zelfs van Tier-1-operators komen. Bijvoorbeeld, NTT heeft ongeveer 50 van zulke prefixes die het onder zijn eigen klanten verspreidt. Aan de andere kant is deze metriek slecht, omdat zulke prefixes gefilterd kunnen worden als de operator , in alle richtingen. Daarom is deze methode niet geschikt om alle operators te vinden wiens verkeer is omgeleid als gevolg van een dergelijk incident.
Een ander goed idee leek ons om te kijken naar . In het bijzonder naar routes die de maxLength-regel van de relevante ROA schenden. Op deze manier zouden we het aantal verschillende origin ASN's met de status Ongeldig kunnen vinden, die zichtbaar waren voor deze AS. Er is echter een "klein" probleem. De gemiddelde waarde (mediaan en modus) van dit aantal (het aantal verschillende origin ASN's) ligt rond de 150 en zelfs als we kleine prefixes filteren, blijft het boven de 70. Deze situatie heeft een vrij eenvoudige verklaring: er zijn maar enkele operators die al ROA-filters toepassen met het beleid "ongeldige routes resetten" op de ingangs- punten, dus waar dan ook in de echte wereld een route met een ROA-schending verschijnt, kan deze zich in alle richtingen verspreiden.
De laatste twee benaderingen maken het mogelijk om operators te vinden die ons incident hebben gezien (aangezien het groot genoeg was), maar over het algemeen zijn ze niet toepasbaar. Goed, maar kunnen we de aanvaller vinden? Wat zijn de algemene kenmerken van een dergelijke manipulatie van AS_PATH? Er zijn een paar basisveronderstellingen:
- De prefix is eerder nergens opgemerkt;
- De Origin ASN (ter herinnering: de eerste ASN in AS_PATH) is geldig;
- De laatste ASN in AS_PATH is de ASN van de aanvaller (in het geval dat zijn buur ASN controleert op alle binnenkomende routes);
- De aanval komt van Ć©Ć©n provider.
Als alle aannames correct zijn, zal de ASN van de aanvaller (behalve de origin ASN) op alle onjuiste routes worden weergegeven, en dit vormt dus een 'kritisch' punt. Onder de echte afhandelaars bevond zich ook AS263444, hoewel er anderen waren. Zelfs als we de routes van het incident buiten beschouwing laten. Waarom? Een kritiek punt kan kritisch blijven, zelfs voor correcte routes. Het kan voortkomen uit slechte connectiviteit in een bepaalde regio of uit beperkingen in onze eigen zichtbaarheid.
Als resultaat: er is een manier om de aanvaller te detecteren, maar alleen als aan alle bovengenoemde voorwaarden is voldaan en alleen wanneer de interceptie groot genoeg is om de monitoringdrempels te passeren. Als sommige van deze factoren niet worden nageleefd, kunnen we dan de prefixes identificeren die door een dergelijke interceptie zijn getroffen? Voor bepaalde operators - ja.
Wanneer een aanvaller een meer specifieke route aanmaakt, wordt die prefix niet aangekondigd door de echte eigenaar. Als je van hem een dynamische lijst van al zijn prefixes hebt, ontstaat de mogelijkheid om een vergelijking te maken en de vervormde meer specifieke routes te vinden. We verzamelen deze lijst van prefixes via onze BGP-sessies, omdat ons niet alleen de volledige lijst van routes die momenteel door de operator zichtbaar zijn, maar ook de lijst van alle prefixes die hij in de wereld wil aankondigen, wordt doorgegeven. Helaas zijn er momenteel enkele tientallen Radar-gebruikers die deze laatste stap niet helemaal correct uitvoeren. Binnenkort zullen we hen op de hoogte stellen en proberen dit probleem op te lossen. Alle anderen kunnen zich nu al bij ons monitoringssysteem aansluiten.
Als we terugkijken naar het oorspronkelijke incident, zijn zowel de aanvaller als het verspreidingsgebied door ons ontdekt via het zoeken naar kritische punten. Verbazingwekkend genoeg verstuurde AS263444 vervalste routes niet naar al zijn klanten. Er is echter een nog vreemdere zaak.
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 ons adresruimte te onderscheppen.
Wanneer meer specifieke prefixes voor onze netwerken zijn gemaakt, werd een speciaal ontworpen AS_PATH gebruikt. Deze AS_PATH kon echter niet worden verkregen uit een van onze eerdere routes. We hebben zelfs geen connectie met AS6762. We kijken naar andere routes in het incident: sommige van hen hadden een echte AS_PATH die eerder was gebruikt, terwijl anderen dat niet hadden, ook al zagen ze eruit als echt. Een extra wijziging aan AS_PATH heeft geen praktische waarde, omdat het verkeer in elk geval naar de aanvaller zal worden omgeleid, maar routes met een "slecht" AS_PATH kunnen worden gefilterd door ASPA of een ander controlemechanisme. Hier vroegen we ons af wat de motivatie van de aanvaller zou kunnen zijn. We hebben momenteel niet genoeg gegevens om te beweren dat dit incident een geplande aanval was. Toch is het mogelijk. Laten we proberen een hypothetische, maar potentieel zeer reƫle situatie voor te stellen.
De ideale aanval
Wat hebben we? Stel dat u een transitprovider bent die routes voor zijn klanten adverteert. Als uw klanten meerdere verbindingen hebben, krijgt u slechts een deel van hun verkeer. Maar hoe meer verkeer, hoe hoger uw inkomen. Dus als u begint met het adverteren van prefixes van de subnetten van deze routes met dezelfde AS_PATH, krijgt u het resterende verkeer. Als gevolg daarvan ontvangt u de overgebleven geldstromen.
Zal ROA hier helpen? Misschien, als u besluit volledig af te zien van het gebruik . Bovendien is het zeer ongewenst om ROA-registraties met overlappende prefixes te hebben. Voor sommige operators zijn dergelijke beperkingen onaanvaardbaar.
Als we naar andere mechanismen voor het beveiligen van routing kijken, zal ASPA in dit geval ook niet helpen (omdat de AS_PATH van een toegestane route wordt gebruikt). BGPSec blijft een suboptimale keuze vanwege het lage acceptatiepercentage en de voortdurende mogelijkheid van downgrade-aanvallen.
Zo hebben we duidelijke winst voor de aanvaller en een gebrek aan veiligheid. Een uitstekende combinatie!
Wat moet er gedaan worden?
Een voor de hand liggende en ingrijpende stap is het herzien van uw huidige routeringsbeleid. Verdeel uw adresruimte in de kleinste stukjes (zonder overlappingen) die u wilt aankondigen. Onderteken ROA's alleen voor deze, zonder de maxLength parameter te gebruiken. In dit geval kan het huidige POV u redden van een dergelijke aanval. Toch is deze aanpak voor sommige beheerders niet logisch vanwege het uitzonderlijke gebruik van meer specifieke routes. Alle problemen met de huidige staat van ROA en route-objecten zullen in een van onze toekomstige materialen worden beschreven.
Daarnaast kunt u proberen om dergelijke onderscheppingen te monitoren. Hiervoor hebben we betrouwbare informatie over uw prefixen nodig. Als u een BGP-sessie met onze collector instelt en ons informatie over uw internetzichtbaarheid doorgeeft, kunnen we de verspreidingssfeer en andere incidenten vinden. Voor degenen die nog niet zijn aangesloten op ons monitoringssysteem, is een lijst met routes alleen met uw prefixen in het begin voldoende. Als u al een sessie met ons heeft, controleer dan of al uw routes zijn verzonden. Helaas is het nodig om hieraan te herinneren, aangezien sommige beheerders Ć©Ć©n of twee prefixen vergeten, wat hinder veroorzaakt voor onze zoekmethoden. Als alles goed wordt gedaan, hebben we betrouwbare gegevens over uw prefixen, die in de toekomst helpen om dergelijke (en andere) typen van verkeersonderbrekingen voor uw adresruimte automatisch te identificeren en te detecteren.
Als u in realtime op de hoogte bent van een dergelijke onderschepping van uw verkeer, kunt u proberen om zelf tegenmaatregelen te nemen. De eerste benadering is om routes met deze meer specifieke prefixen zelf aan te kondigen. In het geval van een nieuwe aanval op deze prefixen, herhaal dit.
De tweede benadering is om de aanvaller en degenen voor wie hij een kritiek punt is (voor goede routes) te straffen door de toegang tot uw routes voor de aanvaller te snijden. Dit kan worden gedaan door het ASN van de aanvaller toe te voegen aan AS_PATH van uw oude routes, waardoor ze deze AS moeten vermijden met behulp van het ingebouwde cycli-detectiemechanisme in BGP. .
Bron: habr.com
