Zwitsers bedrijf routeerde KPN- en ander Europees verkeer via China Telecom

De Zwitserse colocatieaanbieder Safe Host heeft donderdag twee uur lang verkeer van meerdere Europese telecomaanbieders per ongeluk omgeleid via het netwerk van China Telecom. Onder andere KPN-verkeer verliep via de omweg.

Apnic beschrijft hoe Safe Host in het Duitse Frankfurt meer dan zeventigduizend routes via China Telecom liet verlopen. Daarbij ging het om dertienhonderd Nederlandse prefixes, waarvan veel van KPN. De omleiding begon voor KPN donderdagochtend rond 10.00, blijkt uit een grafiek van Oracle op basis van BGP Data. Na twee uur had Safe Host het probleem opgelost.

Donderdag bleek al dat KPN-klanten met internetproblemen te maken kregen. Ook pinverkeer ondervond hinder van de storing. Toen al gaven onder andere gebruikers op Gathering of Tweakers aan dat er sprake leek van bgp-hijacking. In een reactie zei KPN toen dat de fout lag bij een configuratiewijziging in het netwerk van een transitpartij in Zwitserland.

Safe Host kondigde als AS21217 per abuis de routering bij China Telecom, oftewel AS4134, aan. Dat zijn de namen van het autonomous system, oftewel de groep van ip-netwerken. Het Chinese bedrijf kondigde daarop de routes aan het globale internet aan. Zo kon er een bgp route leak ontstaan, waardoor verkeer van onder andere KPN, AS1136, Swisscomm, AS3303, Bouygues Telecom, AS5410, en Numericable-SFR, AS21502, met een omweg ging.

Volgens Apnic toont de bgp route leak aan dat China Telecom nog niet de juiste waarborgen heeft doorgevoerd om de verspreiding van onjuist aangekondigde routes te voorkomen en deze binnen afzienbare tijd te detecteren.

Reacties (62)

En daarom, RPKI. RIPE NCC heeft als Regional Internet Registry (RIR) voor EMEA de taak op zich genomen om een Route Origination Authorization (ROA) database aan te leggen waarmee dmv cryptografische validatie kan worden nagegaan of een peer een betreffende prefix wel mag adverteren. Is de prefix invalid? Drop hem dan ipv het verkeer mogelijk de verkeerde kant op te sturen. Wordt gelukkig door steeds meer vendoren van routers en open-source BGP daemons ondersteund

[Reactie gewijzigd door eBait op 7 juni 2019 16:38]

In dit geval had RPKI niet geholpen. Het origin AS was nog steeds van KPN en de more specifics die werden geannounced door Safe Host hadden gewoon ROA entries die gesigned waren door KPN.

Dit was waarschijnlijk alleen te verhelpen door China Telecom. Zij zullen filters moeten maken op basis van IRR data.

Ah - ik moet bekennen dat ik me niet verdiept had in de precieze oorzaak van dit event en ging iets generieker in op BGP Hijacks in general Zoals gewoonlijk is iets op securitygebied geregeld krijgen op Internet-niveau niet eenvoudig, begin bij je eigen netwerk en hoop dat de rest volgt - al zal dat zeker in China nog wel eventjes kunnen duren ben ik bang...

Het is geen BGP hijack maar een BGP leak

Dat zou helpen, maar verbinden op NL-ix en peering met de route-servers aanzwengelen doet ook wonderen. Dan heb je een AS-path lengte van 1 hop naar KPN's Nederlandse netwerk, en kan een lekkende partij niet winnen omdat hun AS-path langer is.

Uiteraard te combineren met RPKI ROA zodat men niet kan hijacken door middel van more specific routes, die weer zouden winnen van een less specific routes met AS-path lengte van 1 hop.

Als soft- en hardware ontwikkelaar zie ik mezelf als redelijk technisch onderlegd.. Toch is het internet zo complex opgezet dat ik het niet kan bevatten.. Door een partij in Zwitserland loopt verkeer uit Nederland via China. Het zet je echt aan het denken over de conplexiteit van iets waar we elke dag gebruik van maken.

^{Voelt zich misschien iets te sentimenteel.}

Je kan niet alles van IT kennen natuurlijk. Ik ken genoeg programmeurs die begrippen als BGP, OSI layers, tcp tunnels nog niet gehoord hebben.
Iedere zijn deel van de koek denk ik. Het ganse Internet routering / Ripe verhaal is sowieso in ICT al een grijze wolk... iedereen verwacht dat het gewoon werkt. BGP, SMTP, DNS, ... allemaal standaarden die tientallen jaren geleden zijn ontstaan en wel eens een revival kunnen gebruiken. DNS heeft DNSSEC nu, SMTP zit nu meestal in grote clouds dus minder acuut als voorheen, maar het zou net als BGP wel eens een opfrisbeurt kunnen genieten

OSI layers zou elke IT-er moeten kennen. Dit is onderdeel van elke fatsoenlijke ICT opleiding en behoort tot de basiskennis.

BGP zou elke ICT-er wel eens van gehoord moeten hebben maar is toch wat meer specifiek voor iedereen die met netwerken/routing bezig is.

Eens, ik weet vrij veel van netwerken, maar van applicaties des te minder. Een beetje C, 8051 assembler en nog wat Commodore 64 basic en dan houdt het op.
Ieder zijn ding.....

Internet is juist helemaal niet complex opgezet. Het is alleen groot, maar de structuur is simpel.

Ik denk dat wat hier gebeurd is, is dat traffic die via Safe Host liep en wat als bestemming KPN had, via China Telecom is gelopen. Ik geloof echt niet dat binnenlandse NL traffic ineens naar het China omgeleid is.

Ik kreeg donderdag meldingen van een klant dat er een locatie onbereikbaar was. Locatie heeft KPN ADSL, de rest is Ziggo. Traceroute liet veel ontbrekende hops zien en ping was 250ms naar de locaties met Ziggo, veel packet loss ook. Dus ja, dit had invloed op verkeer binnen NL.

Ik begrijp er nog steeds geen drol van. KPN en Ziggo hebben gewoon directe peering. Alleen als pakketjes via de Zwitserse SafeHost liepen, zouden ze door SafeHost doorgestuurd worden naar China, anders bleven de datapakketjes gewoon binnen in Nederland hangen.

[Reactie gewijzigd door Rex op 8 juni 2019 00:27]

Dat is dan voor data tussen die locaties.
Maar als je vanaf elders beide locaties gaat proberen te bereiken kan je wel te maken krijgen met dit soort routing issues.

Aan het einde van de dag is alles een zooi if / else statements

Zitten er ook nog kosten verbonden aan dit foutje, dat al het verkeer de halve wereld over gestuurd wordt? Wie betaalt dat?

Niemand gaat betalen. Dit is "part of the deal" wanneer je het over BGP heb en het internet. Waar mensen werken worden fouten gemaakt.

Mogelijk is de enige manier om kosten te vinden verhalen wanneer een bedrijf / instantie een SLA overtreed door deze outage. Maar dat zou je hier op overmacht kunnen schuiven.

Dat klopt niet helemaal.
De partij die de data ontvangt (China Telecom?) en weer doorstuurt naar het KPN netwerk maakt voor het versturen van data (vermoed ik) gebruik van transit providers, in dit geval zou dat China Telecom dus geld kunnen gaan kosten.

[Reactie gewijzigd door Gijs007 op 7 juni 2019 22:07]

Het klopt dat China Telecom geen directe BGP neighborship heeft met KPN, dit loopt zoals je zegt door Transit AS's.

Echter heeft China Telecom, zoals ik het hier lees, ook geen invloed gehad op de herroutering. Wanneer een tussenpartij een fuckup maakt dan komt dat verkeer bij jou terecht zonder dat jij hier invloed op heb.

Toegegeven ik ga ervan uit dat die dikke BGP routers wel een full table hebben in China en dat verkeer verder netjes zouden moeten afhandelen. Echter hebben zij ook niet gevraagd om deze situatie.

[Reactie gewijzigd door Yariva op 7 juni 2019 22:10]

De tijden in de grafiek en in het artikel zijn in UTC
Voor de nederlandse zomertijd mag je daar 2 uur bij optellen
wat ook weer klopt met het vorige artikel en comments

UTC +2 voor NL aangezien hier de problemen rond 12:00 gemeld werden

Uit het artikel kan ik helaas niet echt de specifieke technische oorzaak achterhalen. Uit mijn vorige post gokte ik dat het AS Path attribute (per ongeluk) lager lag voor de route naar China en dat deze hierdoor werd aangepakt.

Echter blijkt het iets gecompliceerder te liggen. In de tekst staat dat het bedrijf zich voordeed onder een ander AS nummer. Maar dan alsnog moet je op een of andere manier die prefixes in BGP pompen om deze te adverteren... Dan zou je toch verwachten dat je niet prefixes van een andere instantie / bedrijf gaat adverteren.

Ach tja... Ict problemen zijn nooit simpel, helaas

[Reactie gewijzigd door Yariva op 7 juni 2019 17:25]

BGP uitleg: https://www.youtube.com/watch?v=_aLmzq-23pE
BGP hijacking uitleg: https://www.youtube.com/watch?v=Ovh_ceqp63M

Uiteraard is dit geen BGP Prefix hijack.
een prefix hijack is opzettelijk en bovendien wordt dat uitgevoerd door de partij waar de prefixes naartoe moeten.
Als China Telecom dit had gedaan met als doel om het verkeer over hun peering point te laten lopen was het dat wel geweest.

Logisch dat er internet problemen ontstaan; intern beslist de router dat het om intern verkeer gaat, maar als het verkeer buiten het AS moet dan weet het de weg niet meer terug.

Dus de Great Firewall of China stopt niet alles dus wat niet klopt

Die stopt alleen binnenlands verkeer. Alles wat door China naar een ander land gaat dus niet.

Als dat zo zou zijn, hoefden de VS Huawei het werk niet onmogelijk te maken, die zouden dan immers niet kunnen spioneren!

Dit kan gewoon. BGP is niet een 'beveiligd' protocol. Staat ook wel bekend als BGP Hijacking.

Dit klinkt vrij aannemelijk, hoewel BGP route uitwisseling automatisch is worden de effectieve toegestane next hops, AS-paden, ... allemaal onderworpen aan heel wat hand-crafted policies. Die policies bevatten vaak nogal wat numerieke vergelijkingen, regexes, ... en dit is allemaal handcrafted. Een fout is spijtig genoeg zo gemaakt. Meestal wordt dat snel gedetecteerd omdat je aan beide kanten van de peerings controle mechanismes hebt of omdat er routing loops/blackholes geintroduceerd worden. Hier waren blijkbaar controle mechanismes afwezig en enkel een routing detour, geen loop/blackhole.

Dus als je hier Hanlon's Razer toepast kom je toch wel heel snel aan gewoon 'een foutje' ipv spionage. De spionage zou ook vrij onnozel zijn: je zal bijna enkel flow-data (from IP to IP) hebben want heel veel end-to-end encryption tegenwoordig en zoals dit artikel bewijst worden dergelijke zaken bijna altijd door derde partijen gevonden, spionage probeer je toch liever iets heimelijker te doen.

Dus ja, gezien al dat begrijp ik de 0/-1 voor jouw post wel.

Het punt is dat je op deze manier gewoon verkeer kan onderscheppen en dat het mij heel waarschijnlijk lijkt dat dit gewoon spionage is.

Wat wil je precies met HTTPS verkeer doen? Je 'onderschept' het. maar je moet het ook weer binnen de TTL terug/door sturen. Geen idee hoe snel jij deep packet scans wilt doen op zo veel verkeer. Dat is dan misschien ook wel het enige wat je kunt. De headers van een pakket lezen, van wie het is, en waar het naar toe moet.

... kennelijk zijn sommige mensen niet zo goed in het interpreteren van mijn woorden.

Liever reageer ik er niet op, maar ik wil het je graag als tip mee geven: Begin eens bij je zelf. Kom met een goed argument waarom dit geen ongelukje zou zijn.

Stel dat je een nieuw systeem voor massale deep packet scans hebt ontwikkeld en je wilt 'm testen.
Geen spionage, wel opzet.

Dan zou een simpele port-mirror net zo effectief zijn en niet opvallen...

Ik. Check op Wikipedia de lijst van publieke BGP hijacks. Er zullen er vast nog een hoop meer zijn, en deze is nog niet toegevoegd.

Het is zeker niet de eerste keer dat dit gebeurd, en zal vast ook niet de laatste zijn. Totdat er een manier komt om BGP te beschermen, zullen er vast nog wel wat foutjes langskomen.

BGP hijacks zijn extreem publiekelijk. Als je wil hacken, is het dus geen goede tactiek, omdat je het publiekelijk aankondigt. Als mensen bewijs hebben dat je met BGP aan het rommelen bent, wordt je als ISP waarschijnlijk zo het internet af gegooid, dus dat zit er niet echt in.

Kijk maar eens op BGPstream https://bgpstream.com/

Wie denkt nog oprecht dat dit een ongelukje is?

Oh, dat geloof ik wel. BGP-fouten gebeuren wel vaker. Als jij de data van iemand wilt stelen is het een nogal opvallende, ingewikkelde en weinig effectieve manier.

Vergeet niet dat je alleen de IP-pakketten krijgt. Die zijn als het goed is nog altijd versleuteld.

Daarnaast krijg je een hele sloot aan netwerkverkeer, waar je in moet gaan filteren. Als je Man-in-the-Middle wilt doen, is het veel makkelijker om een wat meer gerichte aanval te doen.

Een BGP-hijack is als Denial-of-Service nog wel effectief in te zetten, maar om data te ontfutselen is het alsof je met grote rotsblokken een mug probeert te raken. De kans dat het lukt is klein en er zijn veel betere methoden.

[Reactie gewijzigd door Keypunchie op 7 juni 2019 17:05]

Wie denkt nog oprecht dat dit een ongelukje is?

ik. een ongeluk zit in een extreem klein hoekje bij BGP. Dit soort dingen zie ik semi-geregeld langskomen sinds 1999, en het was vrijwel altijd een stom ongelukje. Zeker als je de uitleg van Niet Henk er bij neemt. Het is een vreselijk publieke manier van rotzooi schoppen. Het valt onmiddelijk op, je kunt het niet verbergen / verdoezelen, en heeft per definitie gevolgen.

Ik. Het was een vergissing bij Safe Host in het Duitse Frankfurt. Als het door een daar werkende Chinees was gedaan had dat nu al de krantenkoppen bereikt.

Ik. Zou ook niet weten waarom ik anders moet denken in dit geval?

Omdat China en Rusland het grote kwaad is volgens sommigen. Ze zien die landen nog steeds als een of andere Lenin die handenwrijvend in een KGB kantoor uit een oude Bond-film hele dagen druk bezig zijn om het westen te pesten

Vergeet niet dat het grootste gedeelte van dit soort Lenins wel zijn opgegroeid met vaste haat tegenover het Westen. Vergeet ook niet dat er 33 miljoen Russen hun leven hebben gegeven voor onze vrijheid en dat dit standaard verzwegen wordt door het Westen. Dat creeert ook wrok.

Dus dat er heden ten dage nog Lenins zijn die het ons zuur willen maken geloof ik best. En ik ben dan nog iemand die niet alles gelooft wat er over Rusland gezegd en geschreven wordt.

Maar goed, dit is uiteraard off-topic.

Die Russen hebben niet hun leven gegeven voor onze vrijheid, dat was een bijkomstigheid. Als het aan Rusland had gelegen had dat IJzeren gordijn hier op de Nederlandse kust gestaan. Vrij zouden we niet zijn geweest.

We mogen de Russen dankbaar zijn voor hun strijd, maar niet voor onze vrijheid.

Iedereen, behalve een aantal aluhoedjes op dit forum....

Maar waarschijnlijk werk jij niet, of heb je geen verantwoordelijkheden waardoor je je niet kunt voorstellen dat mensen wel eens fouten maken.