Heel het internet af te luisteren door zeer ernstig lek

Ik vind dit erg overtrokken en bij lange niet vergelijkbaar met het DNS probleem.
Als eerst ontvang je met de beschreven methode alleen het verkeer wat naar het doel gaat en niet het terugverkeer. Je kan overigens natuurlijk het laatste verkeer ook opvangen als je ook de andere kant gaat spoofen.
Ten tweede,.. hoe krijg je in godsnaam een statiche route naar het doelnetwerk? Je moet dan een p2p verbinding met hun hebben want zit er maar 1 BGP router tussen dan werkt het al niet, want dan gaat het verkeer immers gewoon weer terug naar de spoofer.
Als laatste zal het zeer snel opvallen. Vooral van verbindingen die doorgaans zeer snel zijn en plotseling een stuk trager werken. Een traceroute verteld dan precies wat er aan de hand is. Natuurlijk kan in die tijd al genoeg informatie ontvangen zijn maar anoniem is de spoofer niet.

@Igor, in [url=http://blog.wired.com/27bstroke6/files/edited-iphd-2.ppt]deze powerpoint[/url] hebben de onderzoekers hun bevindingen en opzet van de aanval uit te doeken gedaan.

Arnoud toch. Je gaat echt wel moeten leren om je verhalen te dubbelchecken en te laten nalezen door iemand die er echt iets van weet.

Een paar onjuistheden eerst:

- "Een structurele oplossing voor het probleem zou de implementatie van Secure BGP (SBGP) zijn ... vergelijkbaar is met de structurele oplossing voor het DNS-lek: DNSSEC ..."

Wel, de structurele oplossing voor het dns-"lek" is gewoon doen wat een aantal dns-soft vendors al jaren doen. Noch PowerDNS noch DJB-dns waren kwetsbaar voor die bug, omdat zij "slimmer" waren dan de standaard implementatie. Gewoon hun checks inbouwen in andere dns soft, was de oplossing, komt helemaal geen DNSSEC aan te pas. Dit wil niet zeggen dat dnssec geen nut heeft, maar de oplossing voor dat dns-"lek" was veel eenvoudiger dan dat.

- De titel van je artikel is bijzonder misleidend. Je spreekt van een "lek" en dat "heel het internet af te luisteren is". Er is helemaal geen "lek". Heel het internet is een "web of trust". Het is per definitie de-centraal. Live with it. De paper die gepresenteerd werd op DevCon combineert gewoon een aantal (bestaande) technieken die allemaal een gevolg zijn van dat decentrale. Als je je BGP-peers (in de technische zin van het woord, kan dus gaan om transit, klanten of "peers") niet vertrouwt, moet je je afvragen waarom het je BGP peers zijn en of je dat wel wil houden. Als je ze wel vertrouwt, en hen niet filtert, moet je maar met de gevolgen leven. Dit is helemaal geen "lek", dit is gewoon een gevolg van hoe het internet werkt.

- Je beschrijving van de attack is niet compleet, je moet nog je AS paden gaan juistzetten en op je routers met de TTLs gaan spelen als je het "zo onzichtbaar mogelijk" wil doen, maar dat zijn details.

Wat zijn nu wel oplossingen om zoiets tegen te gaan? Wel er zijn er een paar:

- Zorg eerst dat je eigen info correct bij RIPE staat. Neen, serieus, hoeveel Nederlandse en Belgische bedrijven er zijn wiens RIPE routing-db info niet correct is, het is erg. Iedereen heeft zijn mond vol van dat fameus "lek" zoals jij het noemt, maar diezelfde mensen zouden beter eerst kijken of hun eigen dingen in orde zijn.

- Filter minstens je transit klanten, en zet een max-prefix op je "peering" bgp peers. In een ideale wereld filter je al je bgp peering klanten want als ze allemaal stap 1 van hierboven correct doen, zullen die filters correct zijn.

- Registreer je bij diensten als myASN van Ripe, PHAS, renesys enz. Momenteel detecteren de meeste van die instanties de BGP MITM attack nog niet, maar het is niet zoveel werk voor hen om het wel te doen. Meer nog, ik weet dat ze er allemaal aan bezig zijn om dit zeer snel te gaan implementeren. Als er dan iemand zo'n aanval op je uitvoert, ben je er tenminste bijzonder snel van op de hoogte.

@Igor: je bent correct dat het niks te maken heeft met de DNS-attack. Maar over die statische routes en zo: lees de pdf, het iets ingewikkelder dan wat Arnout beschreef, maar het kan volledig.

@Frank,Arnoud: Klopt. Met de AS-prepends is het wel degelijk mogelijk om de more-specific te filteren bij de paar uplink providers van de target. Neemt niet weg dat natuurlijk klanten van die providers geen last hebben van de spoof.
En wat ik dus niet netjes vind is dat Arnoud het 'statische' routes noemt. Hij voegt verkeerde informatie toe aan een nieuws item. Voor je het weet wordt dit opgepakt door anderen en klopt het hele item niet meer.

@Igor, dat het werkt met static routes is toch echt wat ik gelezen heb in de powerpoint, al kan ik het onderstaande verkeerd begrepen hebben:
[quote]
1. Traceroute & plan reply path to target
2. Note the ASN’s seen towards target from traceroute & bgp table on your router
3. Apply as-path prepends naming each of the ASN’s intended for reply path
4. Nail up static routes towards the next-hop of the first AS in reply path
5. Done[/quote]

@Arnout: Je bedoelt punt 4. Ze bedoelen daar, .. leg een statische route naar je first hop. Maw,.. bijna gelijk aan je default gw.
Maar het belangrijkste is het nieuws item is punt 3. Dat zorgt er voor dat de more-specific update (die de spoofer de wereld in stuurt) gefiltered wordt bij de paar uplink providers van de target.

@Igor, ik heb er nu het volgende van gemaakt "De wijze waarop ze dat doen is redelijk eenvoudig. Allereerst wordt er vanaf het eigen netwerk met “as-prepends” een route aangelegd naar het netwerk van het slachtoffer, waardoor de route tussen het netwerk van het slachtoffer en de aanvaller altijd dezelfde is.", klopt dat?

Oplossing lijkt mij simpel, verplichte aanmelding op een internationaal filter voor alle ARIN/RIPE/AFRINIC Members
onderhouden en beheerd door ICANN. word het filter niet gebruikt dan lidmaatschap ontbinden, dit filter kan alle foute announces er uitpikken waardoor leden geen ranges kunnen announcen die ze niet mogen announcen.

@Robin; de oplossing is even simpel als complex. Hoe ga je die verplichting opleggen, op welke termijn etc. etc. Technisch is het goed te doen, maar in de praktijk zal het nog behoorlijk lang duren voordat dit is doorgevoerd. (Denk aan softwareleveranciers die software moeten schrijven/updaten etc.)

Robin: wat doe je met projecten als AS112? Of anycast prefixen die vanuit verschillende ASN's worden announcet? (Niet proper, maar kan, en wordt gedaan).

@ Dennis,

Inderdaad, het zal tijd en geld kosten om een dergelijk iets te implementeren, maar ik denk dat er genoeg partijen zijn die hier in willen investeren, vooral nu de geest uit de fles is, de verplichting kan worden opgelegd door een aanpassing in het reglement van of de RIR of door ICANN.


@ frank

Ik moet bekennen dat ik AS112 project niet ken, maar als ik het goed gelezen en begrepen heb zou ik zeggen dat die private ranges niets te zoeken hebben in het publieke bgp domein, ik zelf filter deze ranges per default.

Als er partijen zijn die afzonderlijke niet root dns servers willen gebruiken voor die queries, dan is dat prima mogelijk op een virtueel of private netwerk tussen deze partijen.

Bedoel je met de anycast het RFC3068 6to4?

@Frank: "Wel, de structurele oplossing voor het dns-”lek” is gewoon doen wat een aantal dns-soft vendors al jaren doen. Noch PowerDNS noch DJB-dns waren kwetsbaar voor die bug, omdat zij “slimmer” waren dan de standaard implementatie."

Dat is incorrect, ze zijn minder vatbaar, maar nog steeds is spoofing mogelijk. Ipv enkele seconden duurt het echter ongeveer een dag. Zie bijvoorbeeld http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spoofing-an-agile-source-port-randomised-resolver

Daarom werk je ook met filters en werken de meeste carriers ook met filters. Het is logisch dat ik IP adressen van Microsoft kan announcen, echter echt ver kom je niet. Plus je bent _altijd_ te traceren. Je hebt upstream partijen nodig. Als deze geen prefix filters hebben op hun klanten dan kan het inderdaad wel eens uit de hand lopen.

Om je zelf te behoeden van typefouten werk je uiteraard zelf ook werken met prefixfilters naar buiten toe....

Verder werken veel carriers met de databases zoals die van RIPE. Netwerken moeten op een IP blok een route-object aanmaken, hiermee bewijs je dat de range van het netwerk is die hem gaat announcen.

Zo moeilijk is het niet als iedereen zich aan de regeltjes houd ;)

@robbert: er is wel 1 probleem, _iedereen_ moet zich aan de regeltjes houden wil het echt goed werken. Kijk maar eens naar het voorbeeld van Pakistan/YouTube hoe makkelijk het op mis kan gaan. Als een grootte transit een route accepteert, accepteren de andere ze ook en daarmee een heleboel andere partijen.

Er zijn wel mensen die protocollen hebben bedacht voor geautomatiseerde verificatie van announcements, dat lijkt mij een veel beter plan, maar die zijn nergens geimplementeerd.

1 werkt op basis van DNS, maar is natuurlijk zonder DNSSec niet veilig genoeg.

Jammer dat IANA de root beheert voor DNS en ook de IP's uitgeeft anders was het misschien zinnige geweest een andere DNS-root voor bgp te gebruiken. Dat was dan een mooie test voor DNSSec geweest. Nu staat dat hele traject stil.