Internettet ser ud til at være en stærk, uafhængig og uforgængelig struktur. I teorien er netværket stærkt nok til at overleve en atomeksplosion. I virkeligheden kan internettet slippe én lille router. Alt sammen fordi internettet er en bunke af modsætninger, sårbarheder, fejl og videoer om katte. Rygraden i internettet, BGP, er fyldt med problemer. Det er utroligt, at han stadig trækker vejret. Ud over fejl på selve internettet er det også brudt af alle og enhver: store internetudbydere, virksomheder, stater og DDoS-angreb. Hvad skal man gøre ved det, og hvordan man kan leve med det?
Kender svaret Alexey Uchakin () er leder af et team af netværksingeniører hos IQ Option. Dens hovedopgave er platformens tilgængelighed for brugerne. I udskriften af Alexeys rapport vedr Lad os tale om BGP, DDOS-angreb, internet-switches, udbyderfejl, decentralisering og tilfælde, hvor en lille router sendte internettet i dvale. Til sidst - et par tips til, hvordan man overlever alt dette.
Den dag, hvor internettet gik i stykker
Jeg vil blot nævne nogle få hændelser, hvor internettets forbindelse gik i stykker. Dette vil være nok til det komplette billede.
"AS7007 hændelse". Første gang internettet gik i stykker var i april 1997. Der var en fejl i softwaren på en router fra det autonome system 7007. På et tidspunkt annoncerede routeren sin interne routing-tabel til sine naboer og sendte halvdelen af netværket ind i et sort hul.
"Pakistan mod YouTube". I 2008 besluttede modige fyre fra Pakistan at blokere YouTube. De gjorde det så godt, at halvdelen af verden stod uden katte.
"Optagelse af VISA, MasterCard og Symantec præfikser af Rostelecom". I 2017 begyndte Rostelecom ved en fejl at annoncere VISA-, MasterCard- og Symantec-præfikserne. Som følge heraf blev finansiel trafik dirigeret gennem kanaler kontrolleret af udbyderen. Lækagen varede ikke længe, men det var ubehageligt for finansielle virksomheder.
Google vs Japan. I august 2017 begyndte Google at annoncere præfikserne for de store japanske udbydere NTT og KDDI i nogle af sine uplinks. Trafikken blev sendt til Google som transit, sandsynligvis ved en fejl. Da Google ikke er en udbyder og ikke tillader transittrafik, blev en betydelig del af Japan efterladt uden internettet.
"DV LINK fangede præfikserne for Google, Apple, Facebook, Microsoft". Også i 2017 begyndte den russiske udbyder DV LINK af en eller anden grund at annoncere netværkene af Google, Apple, Facebook, Microsoft og nogle andre store spillere.
"eNet fra USA har fanget AWS Route53 og MyEtherwallet præfikser". I 2018 annoncerede Ohio-udbyderen eller en af dens kunder Amazon Route53 og MyEtherwallet crypto wallet-netværk. Angrebet lykkedes: Selv på trods af det selvsignerede certifikat, en advarsel om hvilket dukkede op for brugeren, når han gik ind på MyEtherwallet-webstedet, blev mange tegnebøger kapret, og en del af kryptovalutaen blev stjålet.
Der var mere end 2017 sådanne hændelser alene i 14! Netværket er stadig decentraliseret, så ikke alt og ikke alle går i stykker. Men der er tusindvis af hændelser, alle relateret til BGP-protokollen, der driver internettet.
BGP og dets problemer
protokol BGP - Border Gateway Protocol, blev første gang beskrevet i 1989 af to ingeniører fra IBM og Cisco Systems på tre "servietter" - A4-ark. Disse sidder stadig i Cisco Systems hovedkvarter i San Francisco som et levn fra netværksverdenen.
Protokollen er baseret på samspillet mellem autonome systemer - Autonome systemer eller kort sagt AS. Et autonomt system er simpelthen et ID, som IP-netværk er tildelt i det offentlige register. En router med dette ID kan annoncere disse netværk til verden. Derfor kan enhver rute på internettet repræsenteres som en vektor, som kaldes AS-sti. Vektoren består af antallet af autonome systemer, der skal gennemløbes for at nå destinationsnetværket.
For eksempel er der et netværk af en række autonome systemer. Du skal komme fra AS65001-systemet til AS65003-systemet. Stien fra et system er repræsenteret ved AS Path i diagrammet. Den består af to autonome systemer: 65002 og 65003. For hver destinationsadresse er der en AS Path vektor, som består af antallet af autonome systemer, som vi skal igennem.
Så hvad er problemerne med BGP?
BGP er en tillidsprotokol
BGP-protokollen er tillidsbaseret. Det betyder, at vi som standard stoler på vores nabo. Dette er en funktion af mange protokoller, der blev udviklet i begyndelsen af internettet. Lad os finde ud af, hvad "tillid" betyder.
Ingen nabogodkendelse. Formelt er der MD5, men MD5 i 2019 er netop det...
Ingen filtrering. BGP har filtre og de er beskrevet, men de bliver ikke brugt eller brugt forkert. Jeg forklarer hvorfor senere.
Det er meget nemt at oprette et kvarter. Opsætning af et kvarter i BGP-protokollen på næsten enhver router er et par linjer i konfigurationen.
Der kræves ingen BGP-administrationsrettigheder. Du behøver ikke at tage eksamen for at bevise dine kvalifikationer. Ingen vil fratage dig dine rettigheder til at konfigurere BGP, mens du er fuld.
To hovedproblemer
Præfiks hijacks. Præfiks kapring er at reklamere for et netværk, der ikke tilhører dig, som det er tilfældet med MyEtherwallet. Vi tog nogle præfikser, aftalte med udbyderen eller hackede det, og gennem det annoncerer vi disse netværk.
Rutelækager. Lækager er lidt mere komplicerede. Læk er en ændring i AS Path. I bedste fald vil ændringen resultere i en større forsinkelse, fordi du skal rejse en længere rute eller på et mindre rummeligt link. I værste fald vil sagen med Google og Japan blive gentaget.
Google er ikke selv en operatør eller et autonomt transitsystem. Men da han annoncerede japanske operatørers netværk til sin udbyder, blev trafik gennem Google via AS Path set som en højere prioritet. Trafikken gik derhen og faldt, simpelthen fordi routingindstillingerne i Google er mere komplekse end blot filtre ved grænsen.
Hvorfor virker filtre ikke?
Alle er ligeglade. Dette er hovedårsagen - ingen er ligeglad. Administratoren for en lille udbyder eller virksomhed, der tilsluttede sig udbyderen via BGP, tog MikroTik, konfigurerede BGP på den og ved ikke engang, at filtre kan konfigureres der.
Konfigurationsfejl. De rodede noget sammen, lavede en fejl i masken, tog det forkerte net på - og nu er der fejl igen.
Ingen teknisk mulighed. For eksempel har teleudbydere mange kunder. Det smarte at gøre er automatisk at opdatere filtrene for hver klient – at overvåge, at han har et nyt netværk, at han har lejet sit netværk ud til nogen. Det er svært at følge dette, og endnu sværere med dine hænder. Derfor installerer de blot afslappede filtre eller installerer slet ikke filtre.
undtagelser. Der er undtagelser for elskede og store kunder. Især i tilfælde af inter-operator-grænseflader. For eksempel har TransTeleCom og Rostelecom en masse netværk, og der er en grænseflade mellem dem. Hvis leddet falder, vil det ikke være godt for nogen, så filtrene slappes af eller fjernes helt.
Forældede eller irrelevante oplysninger i IRR. Filtre er bygget ud fra oplysninger, der er registreret i IRR - Internet Routing Registry. Disse er registre for regionale internetregistratorer. Ofte indeholder registre forældede eller irrelevante oplysninger eller begge dele.
Hvem er disse registratorer?
Alle internetadresser tilhører organisationen IANA - Internet Assigned Numbers Authority. Når du køber et IP-netværk af nogen, køber du ikke adresser, men retten til at bruge dem. Adresser er en immateriel ressource, og efter fælles aftale ejes de alle af IANA.
Systemet fungerer sådan her. IANA uddelegerer administrationen af IP-adresser og autonome systemnumre til fem regionale registratorer. De udsteder autonome systemer LIR - lokale internetregistratorer. LIR'er tildeler derefter IP-adresser til slutbrugere.
Ulempen ved systemet er, at hver af de regionale registratorer vedligeholder sine registre på sin egen måde. Alle har deres egne holdninger til, hvilke oplysninger der skal være i registre, og hvem der skal eller ikke skal kontrollere dem. Resultatet er det rod, vi har nu.
Hvordan kan du ellers bekæmpe disse problemer?
IRR - middelmådig kvalitet. Det er klart med IRR - alt er dårligt der.
BGP-fællesskaber. Dette er en egenskab, der er beskrevet i protokollen. Vi kan for eksempel knytte et særligt fællesskab til vores udmelding, så en nabo ikke sender vores netværk til sine naboer. Når vi har et P2P-link, udveksler vi kun vores netværk. For at forhindre, at ruten ved et uheld går til andre netværk, tilføjer vi fællesskab.
Fællesskaber er ikke transitive. Det er altid en kontrakt for to, og det er deres ulempe. Vi kan ikke tildele noget fællesskab, med undtagelse af et, som accepteres som standard af alle. Vi kan ikke være sikre på, at alle vil acceptere dette fællesskab og fortolke det korrekt. Derfor vil han i bedste fald, hvis du er enig med dit uplink, forstå, hvad du ønsker af ham i forhold til fællesskabet. Men din nabo forstår det måske ikke, eller operatøren vil simpelthen nulstille dit tag, og du vil ikke opnå det, du ønskede.
RPKI + ROA løser kun en lille del af problemerne. RPKI er Ressource Public Key Infrastruktur — en særlig ramme for signering af ruteinformation. Det er en god idé at tvinge LIR'er og deres klienter til at opretholde en opdateret adresserumsdatabase. Men der er et problem med det.
RPKI er også et hierarkisk offentligt nøglesystem. IANA har en nøgle, hvorfra RIR-nøgler genereres, og fra hvilke LIR-nøgler genereres? som de signerer deres adresseområde med ved hjælp af ROA'er - Route Origin Authorisations:
— Jeg forsikrer Dem om, at dette præfiks vil blive annonceret på vegne af denne autonome region.
Udover ROA er der andre objekter, men mere om dem senere. Det virker som en god og nyttig ting. Men det beskytter os ikke mod lækager fra ordet "overhovedet" og løser ikke alle problemer med præfikskapring. Derfor har spillerne ikke travlt med at implementere det. Selvom der allerede er forsikringer fra store aktører som AT&T og store IX-virksomheder om, at præfikser med en ugyldig ROA-record vil blive droppet.
Måske vil de gøre dette, men indtil videre har vi et stort antal præfikser, der ikke er underskrevet på nogen måde. På den ene side er det uklart, om de er gyldigt annonceret. På den anden side kan vi ikke droppe dem som standard, fordi vi ikke er sikre på, om dette er korrekt eller ej.
Hvad er der ellers?
BGPSec. Dette er en cool ting, som akademikere fandt på til et netværk af lyserøde ponyer. De sagde:
- Vi har RPKI + ROA - en mekanisme til at verificere adresserumssignaturer. Lad os oprette en separat BGP-attribut og kalde den BGPSec Path. Hver router underskriver med sin egen signatur de meddelelser, den annoncerer til sine naboer. På denne måde vil vi få en pålidelig vej fra kæden af underskrevne meddelelser og vil være i stand til at kontrollere den.
Godt i teorien, men i praksis er der mange problemer. BGPSec bryder mange eksisterende BGP-mekanikker til valg af næste hop og styring af indgående/udgående trafik direkte på routeren. BGPSec virker ikke før 95% af hele markedet har implementeret det, hvilket i sig selv er en utopi.
BGPSec har store ydeevneproblemer. På den nuværende hardware er hastigheden for at kontrollere meddelelser cirka 50 præfikser pr. sekund. Til sammenligning: den nuværende internettabel med 700 præfikser vil blive uploadet om 000 timer, hvor den ændres 5 gange mere.
BGP Open Policy (rollebaseret BGP). Frisk forslag baseret på modellen Gao-Rexford. Det er to videnskabsmænd, der forsker i BGP.
Gao-Rexford-modellen er som følger. For at forenkle er der med BGP et lille antal typer interaktioner:
- Udbyder Kunde;
- P2P;
- intern kommunikation, siger iBGP.
Baseret på routerens rolle er det allerede som standard muligt at tildele visse import-/eksportpolitikker. Administratoren behøver ikke at konfigurere præfikslister. Baseret på den rolle, som routerne aftaler indbyrdes, og som kan indstilles, modtager vi allerede nogle standardfiltre. Dette er i øjeblikket et udkast, der diskuteres i IETF. Jeg håber, at vi snart vil se dette i form af en RFC og implementering på hardware.
Store internetudbydere
Lad os se på eksemplet med en udbyder CenturyLink. Det er den tredjestørste amerikanske udbyder, der betjener 37 stater og har 15 datacentre.
I december 2018 var CenturyLink på det amerikanske marked i 50 timer. Under hændelsen var der problemer med betjeningen af pengeautomater i to stater, og 911-nummeret virkede ikke i flere timer i fem stater. Lotteriet i Idaho var fuldstændig ødelagt. Hændelsen er i øjeblikket under undersøgelse af den amerikanske telekommission.
Årsagen til tragedien var ét netværkskort i ét datacenter. Kortet fejlede, sendte forkerte pakker, og alle 15 af udbyderens datacentre gik ned.
Idéen virkede ikke for denne udbyder "for stor til at falde". Denne idé virker slet ikke. Du kan tage enhver større spiller og lægge nogle små ting ovenpå. USA klarer sig stadig godt med forbindelse. CenturyLink-kunder, der havde en reserve, gik ind i det i hobetal. Så klagede alternative operatører over, at deres links var overbelastet.
Hvis den betingede Kazakhtelecom falder, vil hele landet stå uden internettet.
Selskaber
Sandsynligvis understøtter Google, Amazon, Facebook og andre virksomheder internettet? Nej, de bryder det også.
I 2017 i St. Petersborg ved ENOG13-konferencen Jeff Houston af APNIC indsendt . Den siger, at vi er vant til, at interaktioner, pengestrømme og trafik på internettet er vertikale. Vi har små udbydere, der betaler for forbindelse til større, og de betaler allerede for forbindelse til global transit.
Nu har vi sådan en vertikalt orienteret struktur. Alt ville være fint, men verden ændrer sig - store aktører bygger deres transoceaniske kabler for at bygge deres egne rygrader.
Nyheder om CDN kabel.
I 2018 udgav TeleGeography en undersøgelse om, at mere end halvdelen af trafikken på internettet ikke længere er internettet, men rygraden CDN af store spillere. Dette er trafik, der er relateret til internettet, men det er ikke længere det netværk, vi talte om.
Internettet bryder op i et stort sæt løst forbundne netværk.
Microsoft har sit eget netværk, Google har sit eget, og de har lidt overlapning med hinanden. Trafik, der stammer fra et sted i USA, går gennem Microsoft-kanaler over havet til Europa et eller andet sted på et CDN, derefter via CDN eller IX forbindes det med din udbyder og kommer til din router.
Decentraliseringen er ved at forsvinde.
Denne styrke ved internettet, som vil hjælpe det med at overleve en atomeksplosion, er ved at blive tabt. Steder med koncentration af brugere og trafik vises. Hvis den betingede Google Cloud falder, vil der være mange ofre på én gang. Det mærkede vi delvist, da Roskomnadzor blokerede AWS. Og eksemplet med CenturyLink viser, at selv små ting er nok til dette.
Tidligere gik ikke alt og ikke alle i stykker. I fremtiden kan vi komme til den konklusion, at vi ved at påvirke én stor aktør kan bryde en masse ting, mange steder og mange mennesker.
stater
Stater er de næste i rækken, og det er, hvad der normalt sker for dem.
Her er vores Roskomnadzor slet ikke engang en pioner. En lignende praksis med internetnedlukning findes i Iran, Indien og Pakistan. I England er der et lovforslag om muligheden for at lukke ned for internettet.
Enhver stor stat ønsker at få en kontakt til at slukke for internettet, enten helt eller i dele: Twitter, Telegram, Facebook. Det er ikke, at de ikke forstår, at de aldrig vil lykkes, men de vil det virkelig. Skiftet bruges som regel til politiske formål - for at eliminere politiske konkurrenter, eller valg nærmer sig, eller russiske hackere har brudt noget igen.
DDoS-angreb
Jeg vil ikke tage brød fra mine kammerater fra Qrator Labs, de gør det meget bedre end mig. De har om internetstabilitet. Og det skrev de i 2018-rapporten.
Den gennemsnitlige varighed af DDoS-angreb falder til 2.5 timer. Angriberne begynder også at tælle penge, og hvis ressourcen ikke umiddelbart er tilgængelig, så lader de den hurtigt stå.
Intensiteten af angreb vokser. I 2018 så vi 1.7 Tb/s på Akamai-netværket, og det er ikke grænsen.
Nye angrebsvektorer dukker op, og gamle intensiveres. Nye protokoller dukker op, der er modtagelige for amplifikation, og nye angreb opstår på eksisterende protokoller, især TLS og lignende.
Det meste af trafikken kommer fra mobile enheder. Samtidig skifter internettrafik til mobile klienter. Både dem, der angriber, og dem, der forsvarer, skal kunne arbejde med dette.
Usårlig - nej. Dette er hovedideen - der er ingen universel beskyttelse, der helt sikkert vil beskytte mod enhver DDoS.
Systemet kan ikke installeres, medmindre det er forbundet til internettet.
Jeg håber, jeg har skræmt dig nok. Lad os nu tænke over, hvad vi skal gøre ved det.
Hvad skal man gøre?!
Har du fritid, lyst og kendskab til engelsk, så deltag i arbejdsgrupper: IETF, RIPE WG. Det er åbne maillister, abonner på mailinglister, deltag i diskussioner, kom til konferencer. Hvis du har LIR-status, kan du stemme for eksempel i RIPE på forskellige tiltag.
For blot dødelige er dette overvågning. At vide, hvad der er gået i stykker.
Overvågning: hvad skal man tjekke?
Almindelig Ping, og ikke kun en binær check - den virker eller ej. Optag RTT i historien, så du kan se på uregelmæssigheder senere.
traceroute. Dette er et hjælpeprogram til at bestemme dataruter på TCP/IP-netværk. Hjælper med at identificere anomalier og blokeringer.
HTTP kontrollerer for tilpassede URL'er og TLS-certifikater hjælper med at opdage blokering eller DNS-spoofing for et angreb, hvilket praktisk talt er det samme. Blokering udføres ofte ved DNS-spoofing og ved at vende trafik til en stubside.
Hvis det er muligt, så tjek dine kunders beslutning om din oprindelse fra forskellige steder, hvis du har en ansøgning. Dette vil hjælpe dig med at opdage DNS-kapring anomalier, noget som udbydere nogle gange gør.
Overvågning: hvor skal man tjekke?
Der er ikke noget universelt svar. Tjek, hvor brugeren kommer fra. Hvis brugere er i Rusland, skal du tjekke fra Rusland, men begræns dig ikke til det. Hvis dine brugere bor i forskellige regioner, skal du tjekke fra disse regioner. Men bedre fra hele verden.
Overvågning: hvad skal man tjekke?
Jeg fandt på tre måder. Hvis du ved mere, så skriv i kommentarerne.
- MODEN Atlas.
- Kommerciel overvågning.
- Dit eget netværk af virtuelle maskiner.
Lad os tale om hver af dem.
MODEN Atlas - det er sådan en lille kasse. For dem, der kender den indenlandske "Inspektør" - dette er den samme æske, men med et andet klistermærke.
RIPE Atlas er et gratis program. Du registrerer dig, modtager en router med posten og tilslutter den til netværket. For det faktum, at en anden bruger din prøve, får du nogle kreditter. Med disse lån kan du selv lave noget research. Du kan teste på forskellige måder: ping, traceroute, check certifikater. Dækningen er ret stor, der er mange noder. Men der er nuancer.
Kreditsystemet tillader ikke at bygge produktionsløsninger. Der vil ikke være nok kreditter til igangværende forskning eller kommerciel overvågning. Kreditterne rækker til et kort studie eller engangstjek. Dagsnormen fra en prøve forbruges af 1-2 kontroller.
Dækningen er ujævn. Da programmet er gratis i begge retninger, er dækningen god i Europa, i den europæiske del af Rusland og nogle regioner. Men hvis du har brug for Indonesien eller New Zealand, så er alt meget værre - du har måske ikke 50 prøver pr. land.
Du kan ikke kontrollere http fra en prøve. Dette skyldes tekniske nuancer. De lover at ordne det i den nye version, men http kan indtil videre ikke kontrolleres. Kun certifikatet kan verificeres. En form for http-tjek kan kun udføres på en speciel RIPE Atlas-enhed kaldet Anchor.
Den anden metode er kommerciel overvågning. Alt er fint med ham, du betaler penge, ikke? De lover dig flere dusin eller hundredvis af overvågningspunkter rundt om i verden og tegner smukke dashboards ud af kassen. Men igen, der er problemer.
Det er betalt, nogle steder er det meget. Ping-overvågning, verdensomspændende kontrol og masser af http-tjek kan koste flere tusinde dollars om året. Hvis økonomien tillader det, og du kan lide denne løsning, så fortsæt.
Dækningen er muligvis ikke tilstrækkelig i området af interesse. Med samme ping angives maksimalt en abstrakt del af verden - Asien, Europa, Nordamerika. Sjældne overvågningssystemer kan bore ned til et specifikt land eller område.
Svag support til brugerdefinerede tests. Hvis du har brug for noget brugerdefineret, og ikke bare en "krøllet" på url'en, så er der også problemer med det.
Den tredje måde er din overvågning. Dette er en klassiker: "Lad os skrive vores eget!"
Din overvågning bliver til udvikling af et softwareprodukt og et distribueret. Du leder efter en infrastrukturudbyder, se på, hvordan du implementerer og overvåger den - overvågning skal overvåges, ikke? Og støtte er også påkrævet. Tænk dig om ti gange, før du tager fat på dette. Det kan være lettere at betale nogen for at gøre det for dig.
Overvågning af BGP-anomalier og DDoS-angreb
Her, baseret på de tilgængelige ressourcer, er alt endnu enklere. BGP-anomalier opdages ved hjælp af specialiserede tjenester såsom QRadar, BGPmon. De accepterer en fuld visningstabel fra flere operatører. Baseret på, hvad de ser fra forskellige operatører, kan de opdage uregelmæssigheder, lede efter forstærkere og så videre. Registrering er normalt gratis - du indtaster dit telefonnummer, abonnerer på e-mail-notifikationer, og tjenesten vil advare dig om dine problemer.
Overvågning af DDoS-angreb er også enkelt. Typisk er dette NetFlow-baseret og logfiler. Der er specialiserede systemer som FastNetMon, moduler til splunk. Som en sidste udvej er der din DDoS-beskyttelsesudbyder. Det kan også lække NetFlow, og baseret på det vil det give dig besked om angreb i din retning.
Fund
Hav ingen illusioner - internettet vil helt sikkert gå i stykker. Ikke alt og ikke alle vil gå i stykker, men 14 tusind hændelser i 2017 antyder, at der vil være hændelser.
Din opgave er at opdage problemer så tidligt som muligt. Som minimum ikke senere end din bruger. Ikke kun er det vigtigt at bemærke, altid holde en "Plan B" i reserve. En plan er en strategi for, hvad du vil gøre, når alt går i stykker.: reserveoperatører, DC, CDN. En plan er en separat tjekliste, som du tjekker arbejdet med alting op imod. Planen skal fungere uden involvering af netværksingeniører, fordi der normalt er få af dem, og de vil sove.
Det er alt. Jeg ønsker dig høj tilgængelighed og grøn overvågning.
Næste uge i Novosibirsk forventes solskin, høj belastning og en høj koncentration af udviklere . I Sibirien forudsiges en front af rapporter om overvågning, tilgængelighed og test, sikkerhed og ledelse. Der forventes nedbør i form af skriblede sedler, netværk, fotografier og opslag på sociale netværk. Vi anbefaler at udskyde alle aktiviteter den 24. og 25. juni og . Vi venter på dig i Sibirien!
Kilde: www.habr.com