{"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\/da\/blog\/administrirovanie\/pochemu-internet-do-sih-por-onlajn","title":{"rendered":"Hvorfor er internettet stadig online?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Internettet virker som en st\u00e6rk, uafh\u00e6ngig og ufravigelig struktur. I teorien burde netv\u00e6rkets styrke v\u00e6re nok til at overleve en atomexplosion. I virkeligheden kan internettet dog falde over en lille router. Alt dette skyldes, at internettet er en sammenstilling af modsigelser, s\u00e5rbarheder, fejl og videoer med katte. Grundlaget for internettet - BGP-protokollen - indeholder en masse problemer. Det er en overraskelse, at det stadig fungerer. Ud over fejlene i selve internettet bliver det ogs\u00e5 angrebet af alle mulige: store internetudbydere, virksomheder, stater og DDoS-angreb. Hvad skal man g\u00f8re med dette, og hvordan skal man leve med det?<\/p>\n

\"Hvorfor
\n
\nSvaret kender Alexey Uchakkin<\/b> (Night_Snake<\/a><\/noindex>) - leder af netv\u00e6rksingeni\u00f8rteamet hos IQ Option. Hans hovedopgave er at sikre platformens tilg\u00e6ngelighed for brugerne. I transskriptionen af Alexeys foredrag p\u00e5\u00a0Saint HighLoad++ 2019<\/a><\/noindex> diskuterer vi BGP, DDoS-angreb, afbryderen fra internettet, fejl fra udbyderne, decentralisering og tilf\u00e6lde, hvor en lille router har sendt internettet p\u00e5 ferie. Til sidst - et par r\u00e5d om, hvordan man klarer alt dette.
\n<\/a><\/noindex>
\n

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

Dagen, hvor internettet gik ned<\/h2>\n

\nJeg vil kun n\u00e6vne nogle f\u00e5 h\u00e6ndelser, hvor internettets forbindelser er blevet brudt. Dette vil v\u00e6re nok til at give et klart billede.<\/p>\n

\u00abH\u00e6ndelsen med AS7007\u00bb<\/b>. F\u00f8rste gang internettet gik ned var i april 1997. I softwaren p\u00e5 en router fra det autonome system 7007 var der en fejl. P\u00e5 et tidspunkt annoncerede routeren sin interne routingtabel til sine naboer og sendte halvdelen af netv\u00e6rket i en black hole.<\/p>\n

\u00abPakistan mod YouTube\u00bb<\/b>. I 2008 besluttede de modige folk fra Pakistan at blokere YouTube. De gjorde det s\u00e5 godt, at halvdelen af verden blev uden katte.<\/p>\n

\u00abOphold af pr\u00e6fikserne VISA, MasterCard og Symantec af Rostelecom\u00bb<\/b>. I 2017 begyndte Rostelecom ved en fejltagelse at annoncere pr\u00e6fikserne for VISA, MasterCard og Symantec. Resultatet var, at finansiel trafik blev sendt gennem kanaler, som udbyderen kontrollerede. L\u00e6kagen varede ikke l\u00e6nge, men finansielle virksomheder fandt det ubehageligt.<\/p>\n

\u00abGoogle mod Japan\u00bb<\/b>. I august 2017 begyndte Google at annoncere pr\u00e6fikserne for de store japanske udbydere NTT og KDDI i dele af sine uplinks. Trafikken blev sendt til Google som transit, h\u00f8jst sandsynligt ved en fejl. Da Google ikke er en udbyder og derfor ikke tillader transittrafik, blev en betydelig del af Japan uden internet.<\/p>\n

\u00bbDV LINK har overtaget Google, Apple, Facebook, Microsoft's pr\u00e6fikser\u00ab<\/b>. I 2017 begyndte den russiske udbyder DV LINK underligt nok at annoncere netv\u00e6rkene Google, Apple, Facebook, Microsoft og nogle andre store akt\u00f8rer.<\/p>\n

\u00bbeNet fra USA har overtaget AWS Route53 og MyEtherwallets pr\u00e6fikser\u00ab<\/b>. I 2018 annoncerede en udbyder fra Ohio eller en af hans kunder netv\u00e6rkene Amazon Route53 og kryptovaluta-walleten MyEtherwallet. Angrebet var en succes: P\u00e5 trods af det selvsignerede certifikat, der advarte brugeren ved adgang til MyEtherwallets hjemmeside, blev mange wallets stj\u00e5let, og en del kryptovaluta forsvandt.<\/p>\n

S\u00e5danne h\u00e6ndelser skete over 14.000 gange i 2017! Netv\u00e6rket er stadig decentraliseret, s\u00e5 ikke alt g\u00e5r ned og ikke alle rammes. Men h\u00e6ndelser sker med tusindvis, og alle er relateret til BGP-protokollen, som internettet fungerer p\u00e5.<\/p>\n

BGP og dets problemer<\/h2>\n

\nProtokol BGP - Border Gateway Protocol<\/b>, blev f\u00f8rst beskrevet i 1989 af to ingeni\u00f8rer fra IBM og Cisco Systems p\u00e5 tre \u00bbservietter\u00ab \u2013 A4-ark. Disse \u00bbservietter\u00ab<\/a><\/noindex> ligger stadig i Cisco Systems' hovedkontor i San Francisco som en relikvie fra netv\u00e6rksverdenen.<\/p>\n

Grundlaget for protokollen er interaktionen mellem autonome systemer<\/b>\u00a0\u2013 Autonomous Systems eller forkortet AS. Et autonomt system er blot en ID, som i den offentlige register knytter IP-netv\u00e6rk. En router med s\u00e5dan et ID kan annoncere disse netv\u00e6rk til verden. Derfor kan enhver rute p\u00e5 internettet betragtes som en vektor kaldet AS Path<\/b>. Vektoren best\u00e5r af numre p\u00e5 autonome systemer, der skal passeres for at n\u00e5 bestemmelsesnetv\u00e6rket.<\/p>\n

For eksempel er der et netv\u00e6rk best\u00e5ende af et antal autonome systemer. Man skal komme fra system AS65001 til system AS65003. Vejen fra et system er repr\u00e6senteret af AS Path p\u00e5 diagrammet. Den best\u00e5r af to autonome systemer: 65002 og 65003. For hver destinationsadresse er der en AS Path-vektor, der best\u00e5r af numrene p\u00e5 de autonome systemer, man skal passere.<\/p>\n

\"Hvorfor
\n
\nS\u00e5 hvilke problemer har BGP?<\/p>\n

BGP er et tillidsprotokol<\/h3>\n

\nBGP-protokollen er tillidsbaseret. Det betyder, at vi som standard stoler p\u00e5 vores nabo. Dette er en funktion i mange protokoller, der blev udviklet i internettets tidlige dage. Lad os se n\u00e6rmere p\u00e5, hvad det betyder at \"stole\".<\/p>\n

Ingen autentificering af naboen<\/b>. Formelt set findes der MD5, men MD5 i 2019 - ja, det er ikke s\u00e5 godt\u2026<\/p>\n

Ingen filtrering<\/b>. BGP har filtre, som er beskrevet, men de bruges ikke, eller de bruges forkert. Jeg vil senere forklare, hvorfor.<\/p>\n

Meget enkelt at oprette nabolag<\/b>. Konfiguration af nabolag i BGP-protokollen kan n\u00e6sten g\u00f8res med et par linjer i konfigurationen p\u00e5 enhver router.<\/p>\n

Ingen rettigheder kr\u00e6ves for at administrere BGP<\/b>. Du skal ikke op til eksamen for at bekr\u00e6fte din kvalifikation. Ingen vil tage dine rettigheder fra dig for at konfigurere BGP, mens du er beruset.<\/p>\n

To hovedproblemer<\/h3>\n

\nPrefix hijacking<\/b>. Prefix hijacking - annoncering af et netv\u00e6rk, som du ikke ejer, som i tilf\u00e6ldet med MyEtherwallet. Vi tog nogle pr\u00e6fikser, indgik en aftale med udbyderen eller hackede ham, og annoncerer disse netv\u00e6rk gennem ham.<\/p>\n

Rute l\u00e6kager<\/b>. Rute l\u00e6kager er lidt mere komplekse. En l\u00e6kage er en \u00e6ndring af AS Path<\/b>. I bedste fald vil \u00e6ndringen f\u00f8re til h\u00f8jere latens, fordi en l\u00e6ngere rute skal tages, eller en mindre effektiv link skal benyttes. I v\u00e6rste fald vil en situation som med Google og Japan gentage sig.<\/p>\n

Selv Google er ikke en operat\u00f8r og ikke et transit autonomt system. Men n\u00e5r de annoncerede netv\u00e6rkene af japanske operat\u00f8rer til deres udbyder, s\u00e5 trafikken igennem Google p\u00e5 AS Path mere prioriteret. Trafikken gik derhen og blev droppet simpelthen fordi ruteindstillingerne inden for Google er mere komplekse end blot filtre ved gr\u00e6nsen.<\/p>\n

Hvorfor fungerer filtrene ikke?<\/h3>\n

\nIngen bekymrer sig<\/b>. Det er den prim\u00e6re \u00e5rsag - ingen bryder sig. En administrator fra en lille udbyder eller virksomhed, der er tilsluttet en udbyder via BGP, tog en MikroTik, konfigurerede BGP p\u00e5 den og ved ikke engang, at der kan konfigureres filtre.<\/p>\n

Konfigurationsfejl<\/b>. Der blev debuggede noget, en fejl i masken, de satte ikke det rigtige netv\u00e6rk - og voila, en fejl igen.<\/p>\n

Ingen teknisk mulighed<\/b>. For eksempel har teleselskaber mange kunder. Det ville v\u00e6re fornuftigt automatisk at opdatere filtre for hver kunde - overv\u00e5ge, at de f\u00e5r et nyt netv\u00e6rk, at de har udlejet deres netv\u00e6rk. Det er sv\u00e6rt at holde \u00f8je med dette, og endnu sv\u00e6rere manuelt. Derfor s\u00e6tter de bare afslappede filtre eller s\u00e6tter slet ikke filtre.<\/p>\n

Undtagelser<\/b>. Der er undtagelser for de foretrukne og store kunder. Is\u00e6r i tilf\u00e6lde af mellemoperat\u00f8r forbindelser. For eksempel har TransTeleCom og Rostelecom mange netv\u00e6rk og en forbindelse imellem dem. Hvis forbindelsen falder, vil ingen have det godt, s\u00e5 filtrene sl\u00e6kkes eller fjernes helt.<\/p>\n

For\u00e6ldet eller irrelevant information i IRR<\/b>. Filtrene er baseret p\u00e5 information, der er registreret i\u00a0IRR - Internet Routing Registry<\/b>. Dette er registre fra regionale internetregistratorer. Ofte indeholder registrene for\u00e6ldet eller irrelevant information, eller begge dele.<\/p>\n

Hvem er disse registratorer?<\/h3>\n

\"Hvorfor
\n
\nAlle adresser p\u00e5 internettet tilh\u00f8rer organisationen IANA - Internet Assigned Numbers Authority<\/b>. N\u00e5r du k\u00f8ber et IP-netv\u00e6rk fra nogen, k\u00f8ber du ikke adresserne, men retten til at bruge dem. Adresserne er en immateriel ressource, og if\u00f8lge generel overenskomst tilh\u00f8rer de alle IANA-agenturet.<\/p>\n

Systemet fungerer s\u00e5ledes. IANA delegerer styringen af IP-adresser og numre til autonome systemer til fem regionale registratorer. Disse udsteder autonome systemer LIR - lokale internetregistratorer<\/b>. Derefter tildeler LIR IP-adresser til slutbrugerne.<\/p>\n

Systemets mangel er, at hver af de regionale registratorer f\u00f8rer deres registre p\u00e5 deres egen m\u00e5de. Hver har sine egne synspunkter p\u00e5, hvilken information der skal v\u00e6re i registrene, og hvem der skal eller ikke skal verificere den. Resultatet er det rod, der findes i dag.<\/p>\n

Hvordan kan man ellers bek\u00e6mpe disse problemer?<\/h3>\n

\nIRR - middelm\u00e5dig kvalitet<\/b>. IRR er tydeligvis et problem.<\/p>\n

BGP-communities<\/b>. Dette er en bestemt attribut, der er beskrevet i protokollen. Vi kan for eksempel p\u00e5f\u00f8re et specielt community til vores annoncering, s\u00e5 naboen ikke sender vores netv\u00e6rk til sine naboer. N\u00e5r vi har en P2P-forbindelse, udveksler vi kun vores netv\u00e6rk. For at forhindre, at ruten utilsigtet g\u00e5r til andre netv\u00e6rk, p\u00e5f\u00f8rer vi et community.<\/p>\n

Communities er ikke transitiv<\/b>. Det er altid en aftale mellem to, og det er deres ulempe. Vi kan ikke p\u00e5f\u00f8re et hvilket som helst community, undtagen et, der er accepteret som standard af alle. Vi kan ikke v\u00e6re sikre p\u00e5, at alle accepterer dette community og fortolker det korrekt. Derfor, i bedste fald, hvis du laver en aftale med din uplink, vil han forst\u00e5, hvad du \u00f8nsker fra ham via community. Men naboen kan muligvis ikke forst\u00e5 det, eller operat\u00f8ren kan blot fjerne din m\u00e6rkning, og du opn\u00e5r ikke det, du \u00f8nskede.<\/p>\n

RPKI + ROA l\u00f8ser kun en lille del af problemerne<\/b>. RPKI er Resource Public Key Infrastructure\u00a0<\/b> \u2014 en speciel ramme for underskrivelse af ruteinformation. Det er en god id\u00e9 at tvinge LIR'er og deres kunder til at f\u00f8re en opdateret database over adresseomr\u00e5det. Men der er et problem med det.<\/p>\n

RPKI er ogs\u00e5 et hierarkisk system med offentlige n\u00f8gler. IANA har en n\u00f8gle, fra hvilken RIR-n\u00f8gler oprettes, og fra dem genereres LIR-n\u00f8gler, som de signer deres adresseomr\u00e5de med via ROA'er \u2014 Route Origin Authorisations:<\/p>\n

\u2014 Jeg forsikrer, at denne pr\u00e6fiks vil blive annonceret p\u00e5 vegne af denne autonomi.<\/i><\/p>\n

Udover ROA er der ogs\u00e5 andre objekter, men dem kan vi tage en anden gang. Det virker som en god og nyttig ting. Men det beskytter os overhovedet ikke mod l\u00e6kager og l\u00f8ser ikke alle problemer med pr\u00e6fiks-tyveri. Derfor er akt\u00f8rerne ikke s\u00e6rlig ivrige efter at implementere det. Der er dog allerede fra store akt\u00f8rer som AT&T og st\u00f8rre IX'er givet l\u00f8fter om, at pr\u00e6fiks med invalid-ROA-optegnelser vil blive droppet. <\/p>\n

M\u00e5ske vil de g\u00f8re det, men indtil videre har vi et stort antal pr\u00e6fikser, som slet ikke er signerede. P\u00e5 den ene side er det uklart, om de annonceres som valide. P\u00e5 den anden side kan vi ikke som standard droppe dem, fordi vi ikke er sikre p\u00e5, om det er korrekt.<\/p>\n

Hvad er der ellers?<\/h3>\n

\nBGPSec<\/b>. Det er en cool ting, som akademikere har opfundet til netv\u00e6rket af lyser\u00f8de ponyer. De sagde:<\/p>\n

\u2014 Vi har RPKI + ROA \u2014 mekanismen til at bekr\u00e6fte underskriften af adresseomr\u00e5det. Lad os etablere en s\u00e6rskilt BGP-attribut og kalde den BGPSec Path. Hver router vil underskrive de annoncer, den annoncerer til naboer. S\u00e5 f\u00e5r vi en p\u00e5lidelig sti fra k\u00e6den af signerede annoncer, som vi kan verificere.<\/i><\/p>\n

Teoretisk set er det godt, men i praksis er der mange problemer. BGPSec bryder mange eksisterende BGP-mekanikker vedr\u00f8rende valg af next-hop og styring af indg\u00e5ende\/udg\u00e5ende trafik direkte p\u00e5 routeren. BGPSec fungerer ikke, f\u00f8r det er implementeret af 95% af markedets deltagere, hvilket i sig selv er en utopi.<\/p>\n

BGPSec har enorme problemer med ydeevnen. P\u00e5 det nuv\u00e6rende udstyr er hastigheden for at verificere annoncer omtrent 50 pr\u00e6fikser per sekund. Til sammenligning vil den nuv\u00e6rende internettabel med 700.000 pr\u00e6fikser tage 5 timer at indl\u00e6se, i l\u00f8bet af hvilke yderligere 10 \u00e6ndringer vil finde sted.<\/p>\n

BGP Open Policy (Role-based BGP)<\/b>. Et nyt forslag baseret p\u00e5 modellen Gao-Rexford<\/b>. Det er to forskere, der arbejder med unders\u00f8gelser af BGP.<\/p>\n

Modellen Gao-Rexford handler om f\u00f8lgende. For at forenkle det kan man sige, at der er et begr\u00e6nset antal typer interaktioner i forbindelse med BGP:<\/p>\n