{"id":35550,"date":"2019-10-31T22:04:58","date_gmt":"2019-10-31T19:04:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/pochemu-internet-do-sih-por-onlajn\/"},"modified":"2019-10-31T22:04:58","modified_gmt":"2019-10-31T19:04:58","slug":"pochemu-internet-do-sih-por-onlajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/pochemu-internet-do-sih-por-onlajn","title":{"rendered":"Waarom is het internet nog steeds online?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Het internet lijkt een sterke, onafhankelijke en onwrikbare structuur te zijn. In theorie heeft het netwerk voldoende veerkracht om een nucleaire explosie te doorstaan. In de werkelijkheid kan het internet echter \u00e9\u00e9n klein routertje laten vallen. Dit komt doordat het internet een hoop tegenstrijdigheden, kwetsbaarheden, fouten en kattenfilmpjes is. De basis van het internet, het BGP-protocol, zit vol problemen. Het is al opmerkelijk dat het nog steeds functioneert. Naast de fouten binnen het internet wordt het ook aangevallen door allerlei partijen: grote internetproviders, bedrijven, staten en DDoS-aanvallen. Wat moeten we hiermee doen en hoe leven we ermee?<\/p>\n

\"Waarom
\n
\nHet antwoord weet Aleksey Uchakin<\/b> (Night_Snake<\/a><\/noindex>) \u2014 leider van het team van netingenieurs bij IQ Option. Zijn belangrijkste taak is de beschikbaarheid van het platform voor gebruikers. In de presentatie van Aleksey op\u00a0Saint HighLoad++ 2019<\/a><\/noindex> , zullen we het hebben over BGP, DDoS-aanvallen, de schakelaar van het internet, fouten van providers, decentralisatie en gevallen waarin een klein routertje het internet in slaap heeft gestuurd. Aan het einde \u2014 een paar tips over hoe je dit alles kunt overleven.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

De dag waarop het internet brak<\/h2>\n

\nIk zal slechts enkele incidenten aanhalen waarbij de connectiviteit van het internet verstoord raakte. Dit zal voldoende zijn voor een compleet beeld.<\/p>\n

\u201cIncident met AS7007\u201d<\/b>. Voor de eerste keer brak het internet in april 1997. In de software van een router uit autonome systeem 7007 zat een fout. Op een gegeven moment adverteerde de router zijn interne routeringtabel aan zijn buren en stuurde de helft van het netwerk in een black hole.<\/p>\n

\u201cPakistan tegen YouTube\u201d<\/b>. In 2008 besloten dappere jongens uit Pakistan om YouTube daar te blokkeren. Ze deden dit zo goed dat de halve wereld zonder katten kwam te zitten.<\/p>\n

\u201cPrefixovername van VISA, MasterCard en Symantec door Rostelecom\u201d<\/b>. In 2017 begon Rostelecom per ongeluk de prefixes van VISA, MasterCard en Symantec aan te kondigen. Het resultaat was dat financieel verkeer via kanalen ging die door de provider werden gecontroleerd. De lekkage duurde niet lang, maar het was vervelend voor de financi\u00eble bedrijven.<\/p>\n

\u201cGoogle tegen Japan\u201d<\/b>. In augustus 2017 begon Google een deel van zijn uplinks de prefixes van grote Japanse providers NTT en KDDI aan te kondigen. Het verkeer werd vermoedelijk per ongeluk naar Google gestuurd als transitverkeer. Aangezien Google geen provider is en transitverkeer niet doorlaat, bleef een aanzienlijk deel van Japan zonder internet.<\/p>\n

\u201cDV LINK nam de prefixes van Google, Apple, Facebook en Microsoft over\u201d<\/b>. In 2017 begon de Russische provider DV LINK om de een of andere reden netwerken van Google, Apple, Facebook, Microsoft en enkele andere grote spelers aan te kondigen.<\/p>\n

\u00abeNet uit de VS heeft de prefixes van AWS Route53 en MyEtherwallet overgenomen\u00bb<\/b>. In 2018 kondigde een provider uit Ohio of iemand van zijn klanten de netwerken van Amazon Route53 en de cryptocurrency-portemonnee MyEtherwallet aan. De aanval was succesvol: ondanks het zelfondertekende certificaat, dat een waarschuwing aan de gebruiker gaf bij het inloggen op de MyEtherwallet-site, werden veel portemonnees gestolen en een deel van de cryptocurrency gejat.<\/p>\n

In 2017 waren er meer dan 14.000 van dergelijke incidenten! Het netwerk is nog steeds gedecentraliseerd, dus niet alles en niet bij iedereen faalt. Maar incidenten gebeuren met duizenden en ze zijn allemaal gerelateerd aan het BGP-protocol waarop internet draait.<\/p>\n

BGP en zijn problemen<\/h2>\n

\nProtocol BGP - Border Gateway Protocol<\/b>, voor het eerst beschreven in 1989 door twee ingenieurs van IBM en Cisco Systems op drie 'servetten' - A4-papier. Deze 'servetten'<\/a><\/noindex> liggen nog steeds in het hoofdkwartier van Cisco Systems in San Francisco als een relikwie uit de netwerkwereld.<\/p>\n

De basis van het protocol is de interactie tussen autonome systemen<\/b>\u00a0\u2014 Autonomous Systems, of kortweg AS. Een autonoom systeem is gewoon een bepaalde ID waarvoor netwerken van IP in het publieke register zijn geregistreerd. Een router met die ID kan deze netwerken aan de wereld aankondigen. Dienovereenkomstig kan elke route op internet worden afgebeeld als een vector, die men het noemt AS Path<\/b>. De vector bestaat uit de nummers van de autonome systemen die moeten worden gepasseerd om het bestemmingsnetwerk te bereiken.<\/p>\n

Bijvoorbeeld, er is een netwerk bestaande uit een aantal autonome systemen. We moeten van systeem AS65001 naar systeem AS65003 gaan. De route van het ene systeem wordt weergegeven als AS Path in de schets. Deze bestaat uit twee autonome systemen: 65002 en 65003. Voor elk bestemmingsadres is er een vector AS Path, die bestaat uit de nummers van de autonome systemen die we moeten passeren.<\/p>\n

\"Waarom
\n
\nDus wat zijn de problemen met BGP?<\/p>\n

BGP is een protocol van vertrouwen<\/h3>\n

\nHet BGP-protocol is trust based. Dit betekent dat we standaard onze buurman vertrouwen. Dit is een kenmerk van veel protocollen die zijn ontwikkeld in de vroege dagen van het internet. Laten we eens kijken wat 'vertrouwen' betekent.<\/p>\n

Er is geen authenticatie van de buurman<\/b>. Formeel is er MD5, maar MD5 in 2019 - nou ja, dat is niet geweldig...<\/p>\n

Er is geen filtering<\/b>. BGP heeft filters en deze zijn beschreven, maar ze worden niet gebruikt of worden verkeerd gebruikt. Ik zal later uitleggen waarom.<\/p>\n

Heel eenvoudig om buren in te stellen<\/b>. Het instellen van buren in BGP-protocol op bijna elke router vereist maar een paar regels configuratie.<\/p>\n

Geen beheersrechten voor BGP benodigd<\/b>. Er zijn geen examens nodig om je kwalificatie te bevestigen. Niemand zal je rechten afnemen voor BGP-configuratie terwijl je dronken bent.<\/p>\n

Twee belangrijkste problemen<\/h3>\n

\nPrefixdiefstal - prefix hijacks<\/b>. Bij prefixdiefstal wordt een netwerk dat je niet bezit aangekondigd, zoals met MyEtherwallet. We namen enkele prefixes, maakten afspraken met de provider of hackten deze, en we kondigen deze netwerken via hen aan.<\/p>\n

Routelekken - route leaks<\/b>. Routelekken zijn iets complexer. Een lek is een wijziging in het AS-Pad<\/b>. In het beste geval leidt de wijziging tot hogere latency, omdat je een langere route of een minder effici\u00ebnte link moet nemen. In het slechtste geval herhaalt zich het geval met Google en Japan.<\/p>\n

Zelfs Google is geen operator of transit autonome systeem. Maar toen het zijn provider de netwerken van Japanse operators aanbood, leek het verkeer via Google op het AS-Pad meer prioriteit te hebben. Het verkeer ging daarheen en werd gewoon gedropped omdat de routeringsinstellingen binnen Google complexer zijn dan alleen filters aan de rand.<\/p>\n

Waarom werken de filters niet?<\/h3>\n

\nNiemand geeft erom<\/b>. Dit is de belangrijkste reden - niemand geeft erom. De admin van een kleine provider of bedrijf dat verbonden is met de provider via BGP, heeft MikroTik genomen, heeft BGP ingesteld en weet zelfs niet dat je filters kunt instellen.<\/p>\n

Configuratiefouten<\/b>. Iets terwijl ze debugden, maakten een fout in de maskering, stelden het verkeerde netwerk in - en kijk, weer een fout.<\/p>\n

Geen technische mogelijkheid<\/b>. Bijvoorbeeld, providers hebben veel klanten. Slim zou zijn om de filters automatisch voor elke klant bij te werken - te kijken of ze een nieuw netwerk hebben, of ze hun netwerk aan iemand hebben verhuurd. Dit is moeilijk om te volgen, en handmatig is het nog moeilijker. Daarom plaatsen ze gewoon ontspannende filters of zetten ze helemaal geen filters.<\/p>\n

Uitzonderingen<\/b>. Er zijn uitzonderingen voor geliefde en grote klanten. Vooral in het geval van inter-operator aansluitingen. Bijvoorbeeld, TransTeleCom en Rostelecom hebben veel netwerken en er is een aansluiting tussen hen. Als de aansluiting fout gaat, zal niemand het goed hebben, dus worden de filters versoepeld of helemaal verwijderd.<\/p>\n

Verouderde of onjuiste informatie in IRR<\/b>. Filters zijn gebaseerd op informatie die is vastgelegd in\u00a0IRR - Internet Routing Registry<\/b>. Dit zijn de registers van regionale internetregisters. Vaak bevat de registers verouderde of ongepaste informatie, of een combinatie van beide.<\/p>\n

Wie zijn deze registrars?<\/h3>\n

\"Waarom
\n
\nAlle adressen op het internet behoren tot organisaties IANA - Internet Assigned Numbers Authority<\/b>. Wanneer je een IP-netwerk van iemand koopt, koop je niet de adressen, maar het recht om ze te gebruiken. Adressen zijn een immaterieel goed, en volgens algemene overeenstemming behoren ze allemaal tot het IANA-agentschap.<\/p>\n

Het systeem werkt als volgt. IANA delegeert het beheer van IP-adressen en autonome systeemnummers aan vijf regionale registrars. Deze verstrekken autonome systemen LIR - lokale internetregistrars<\/b>. Vervolgens wijzen LIR IP-adressen toe aan eindgebruikers.<\/p>\n

Een nadeel van het systeem is dat elke regionale registrar zijn registers op zijn eigen manier bijhoudt. Iedereen heeft zijn eigen visie op welke informatie in de registers moet worden opgenomen en wie deze wel of niet moet controleren. Dit resulteert in de chaos die we nu hebben.<\/p>\n

Hoe kunnen we deze problemen anders aanpakken?<\/h3>\n

\nIRR - middelmatige kwaliteit<\/b>. Met IRR is het duidelijk - daar is alles slecht.<\/p>\n

BGP-communities<\/b>. Dit is een bepaald attribuut dat in het protocol is beschreven. We kunnen bijvoorbeeld een speciale community aan onze aankondiging hangen, zodat de buurman onze netwerken niet naar zijn buren doorstuurt. Wanneer we een P2P-link hebben, delen we alleen onze netwerken. Om te voorkomen dat een route per ongeluk naar andere netwerken gaat, hangen we een community aan.<\/p>\n

Communities zijn niet transitief<\/b>. Het is altijd een overeenkomst tussen twee partijen, en dat is hun nadeel. We kunnen geen enkele community toevoegen, behalve \u00e9\u00e9n die door iedereen als standaard wordt aanvaard. We kunnen er niet van uitgaan dat deze community door iedereen wordt geaccepteerd en correct wordt ge\u00efnterpreteerd. Daarom, in het beste geval, als je het eens wordt met je uplink, begrijpt hij wat je bedoelt met de community. Maar zijn buurman kan het mogelijk niet begrijpen, of de operator kan gewoon je label verwijderen, en dan bereik je niet wat je wilde.<\/p>\n

RPKI + ROA lost slechts een klein deel van de problemen op<\/b>. RPKI is Resource Public Key Infrastructure\u00a0<\/b> \u2014 een speciaal raamwerk voor het ondertekenen van route-informatie. Een goed idee om LIR's en hun klanten te dwingen een actuele database van het adresruimte bij te houden. Maar er is \u00e9\u00e9n probleem mee.<\/p>\n

RPKI is also a hierarchical open key system. IANA has a key from which RIR keys are created, and from them, LIR keys are created, which they use to sign their address space using ROAs \u2014 Route Origin Authorisations:<\/p>\n

\u2014 I assure you that this prefix will be announced on behalf of this AS.<\/i><\/p>\n

Besides ROA, there are other objects, but we'll discuss those later. It seems that this is a good and useful thing. However, it does not protect us from leaks at all and does not solve all issues with prefix hijacking. Therefore, players are in no hurry to implement it. Although there are already assurances from major players like AT&T and large IXs that prefixes with invalid ROA records will be dropped. <\/p>\n

They might do it, but for now, we have a huge number of prefixes that are not signed at all. On the one hand, it's unclear whether they are validly announced. On the other hand, we cannot drop them by default because we are not sure whether it's right or wrong.<\/p>\n

Wat is er nog meer?<\/h3>\n

\nBGPSec<\/b>. This is a cool thing that was invented by academics for the pink pony network. They said:<\/p>\n

\u2014 We have RPKI + ROA \u2014 a signature assurance mechanism for address space. Let's create a separate BGP attribute and call it BGPSec Path. Each router will sign its announcements that it announces to neighbors. This way, we will have a trusted path from a chain of signed announcements and will be able to verify it.<\/i><\/p>\n

In theory, it sounds good, but in practice, there are many issues. BGPSec breaks many existing BGP mechanics related to next-hop selection and management of incoming\/outgoing traffic directly on the router. BGPSec won't work until 95% of the entire market participants implement it, which is itself a utopia.<\/p>\n

BGPSec has enormous performance issues. On current hardware, the announcement verification speed is about 50 prefixes per second. For comparison, the current internet table with 700,000 prefixes would take 5 hours to load, during which time another 10 changes would occur.<\/p>\n

BGP Open Policy (Role-based BGP)<\/b>. A fresh proposal based on the Gao-Rexford<\/b>. These are two scholars researching BGP.<\/p>\n

The Gao-Rexford model can be simplified to say that there is a small number of types of interactions in the case of BGP:<\/p>\n