{"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\/et\/blog\/administrirovanie\/pochemu-internet-do-sih-por-onlajn","title":{"rendered":"Miks on internet endiselt online?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Interneti tundub olevat tugev, s\u00f5ltumatu ja purustamatu struktuur. Teoorias peaks v\u00f5rgu vastupidavusest piisama ka tuumaplahvatuse \u00fcleelamiseks. Tegelikult v\u00f5ib interneti kokkuvarisemise p\u00f5hjustada isegi \u00fcks v\u00e4ike ruuter. K\u00f5ik see tuleneb sellest, et internet on t\u00e4is vastuolusid, haavatavusi, vigu ja kassi-videoid. Interneti aluseks olev BGP-protokoll kannab endas hulgaliselt probleeme. On imelik, et see veel t\u00f6\u00f6tab. Peale interneti enda vigade purustavad seda k\u00f5ik, kes soovivad: suured interneti pakkujad, korporatsioonid, riigid ja DDoS-r\u00fcnnakud. Mida sellega teha ja kuidas sellega elada?<\/p>\n

\"Miks
\n
\nVastuse teab Aleksei U\u010dakin<\/b> (Night_Snake<\/a><\/noindex>) on IQ Optioni v\u00f5rguinseneride meeskonna juht. Tema peamine \u00fclesanne on tagada platvormi k\u00e4ttesaadavus kasutajatele. Ajakirjanduses r\u00e4\u00e4gime A\u043b\u0435\u043a\u0441\u0435i ettekandest\u00a0Saint HighLoad++ 2019<\/a><\/noindex> , kus r\u00e4\u00e4gime BGP-st, DDoS-r\u00fcnnakutest, interneti klapi, pakkujate vigadest, detsentraliseerimisest ja juhtumist, kui v\u00e4ike ruuter l\u00e4kitas interneti magama. L\u00f5pus jagame m\u00f5ned n\u00f5uanded, kuidas sellest \u00fcle elada.
\n<\/a><\/noindex>
\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

P\u00e4ev, mil internet j\u00f5udis katki<\/h2>\n

\nToome v\u00e4lja vaid m\u00f5ned intsidentid, kui internetis kadus \u00fchendus. Seda on piisavalt, et saada t\u00e4ielik \u00fclevaade.<\/p>\n

\u00abAS7007 intsident\u00bb<\/b>. Esmakordselt katkestas internet aprillis 1997. \u00dche 7007 autonoomse s\u00fcsteemi ruuteri tarkvaras oli viga. Teatud hetkel teatas ruuter naabritele oma sise marsruuditabelist ja suunas pool v\u00f5rku musta auku.<\/p>\n

\u00abPakistani r\u00fcnnak YouTube'ile\u00bb<\/b>. 2008. aastal otsustasid julged mehed Pakistanis blokeerida YouTube'i. Nad tegid seda nii h\u00e4sti, et pool maailma j\u00e4i ilma kassivideodest.<\/p>\n

\u00abVISA, MasterCardi ja Symantec'i prefikside haaramine Rostelekomi poolt\u00bb<\/b>. 2017. aastal tegi Rostelekom ekslikult teatavaks VISA, MasterCardi ja Symantec'i prefiksid. Tulemuseks suunati finantstrafik kanalite kaudu, mida kontrollib pakkuja. Leak kestis mitte kaua, kuid finantsinstituutide jaoks oli see ebameeldiv.<\/p>\n

\u00abGoogle vs Jaapan\u00bb<\/b>. Augustis 2017 hakkas Google teatama osa oma \u00fcles\u00f5idudest Jaapani suurte teenusepakkujate NTT ja KDDI prefikseid. Trafik suunati Google'i nagu transit, t\u00f5en\u00e4oliselt ekslikult. Kuna Google ei ole teenusepakkuja ja ei edasta transiittrafikuid, j\u00e4i m\u00e4rkimisv\u00e4\u00e4rne osa Jaapanist ilma internetita.<\/p>\n

\u00abDV LINK haaras Google'i, Apple'i, Facebooki, Microsofti prefiksid\u00bb<\/b>. 2017. aastal hakkas Venemaa teenusepakkuja DV LINK kummalisel kombel kuulutama Google'i, Apple'i, Facebooki, Microsofti ja m\u00f5nede teiste suuremate tegijate v\u00f5rgustikke.<\/p>\n

\u00abAmeerika \u00dchendriikide eNet haaras AWS Route53 ja MyEtherwalleti eelistused\u00bb<\/b>. 2018. aastal kuulutas m\u00f5ni Ohio teenusepakkuja v\u00f5i tema kliendid Amazon Route53 ja kr\u00fcptorahakoti MyEtherwallet v\u00f5rgustikke. R\u00fcnnak \u00f5nnestus: vaatamata enesetaludusele, mis hoiatab kasutajat MyEtherwalleti saidile sisenedes, varastati paljusid rahakotte ja osa kr\u00fcptovaluutast.<\/p>\n

Aasta 2017. jooksul oli sarnaseid intsidente \u00fcle 14 000! V\u00f5rk on endiselt detsentraliseeritud, seega ei riku see k\u00f5iki ja mitte k\u00f5igis kohtades. Kuid incidente toimub tuhandeid, ja need k\u00f5ik on seotud BGP-protokolliga, millega internet t\u00f6\u00f6tab.<\/p>\n

BGP ja selle probleemid<\/h2>\n

\nProtokoll BGP - Border Gateway Protocol<\/b>, mis kirjeldati esmakordselt 1989. aastal kahe inseneri poolt IBM-ist ja Cisco Systems-ist kolme \u00absalvr\u00e4tikuga\u00bb - A4-formaadis lehtedega. Need \u00absalvr\u00e4tikud\u00bb<\/a><\/noindex> asuvad endiselt Cisco Systems'i peahoones San Franciscos v\u00f5rgustiku maailma reliikviana.<\/p>\n

Protokolli alus on autonoomsete s\u00fcsteemide koostoime<\/b>\u00a0\u2014 Autonomous Systems ehk l\u00fchidalt - AS. Autonoomne s\u00fcsteem on lihtsalt mingi ID, millele on avalikus registris kinnitatud IP-v\u00f5rgud. Marsruuter sellise ID-ga v\u00f5ib neid v\u00f5rgustikke maailmale kuulutada. Seega v\u00f5ib iga interneti marsruuti esitada vektorina, mida nimetatakse AS Path<\/b>. Vektor koosneb autonoomsete s\u00fcsteemide numbritest, mille kaudu tuleb minna, et j\u00f5uda sihtv\u00f5rku.<\/p>\n

N\u00e4iteks, on olemas v\u00f5rk, mis koosneb mitmest autonoomsest s\u00fcsteemist. Tuleb minna s\u00fcsteemist AS65001 s\u00fcsteemi AS65003. \u00dcks s\u00fcsteem moodustab AS Path joonisel. See koosneb kahest autonoomsest s\u00fcsteemist: 65002 ja 65003. Iga sihtadresse jaoks on AS Path vektor, mis koosneb s\u00fcsteemide numbritest, millest peame m\u00f6\u00f6duma.<\/p>\n

\"Miks
\n
\nNii millised on BGP probleemid?<\/p>\n

BGP on usaldusprotokoll<\/h3>\n

\nBGP-protokoll on usalduslik. See t\u00e4hendab, et me usaldame oletatavalt oma naabrit. See on paljude protokollide iseloom, mis loodi interneti algusaegadel. Selgitame v\u00e4lja, mida t\u00e4hendab \u00abusaldame\u00bb.<\/p>\n

Naabri autentimist pole<\/b>. Ametlikult on olemas MD5, kuid 2019. aastal on MD5 ... noh, mitte v\u00e4ga hea...<\/p>\n

Filtreeringut pole<\/b>. BGP-l on filtrid ja need on kirjeldatud, kuid neile ei p\u00f6\u00f6rata t\u00e4helepanu v\u00f5i neid kasutatakse valesti. Hiljem selgitan, miks.<\/p>\n

V\u00e4ga lihtne on naabruskonda seadistada<\/b>. Naabruse seadistamine BGP-protokollis peaaegu igas ruuteris \u2013 paar rida konfiguratsiooni.<\/p>\n

BGP haldamiseks \u00f5igusi ei n\u00f5uta<\/b>. Pole vaja sooritada eksameid, mis t\u00f5estaksid teie kvalifikatsiooni. Keegi ei v\u00f5ta \u00f5iguseid \u00e4ra, kui seadistate BGP joobes olles.<\/p>\n

Kaks p\u00f5hiprobleemi<\/h3>\n

\nPrefiksite r\u00f6\u00f6vimine \u2013 prefix hijacks<\/b>. Prefiksi r\u00f6\u00f6vimine \u2013 v\u00f5rgu kuulutamine, mis ei kuulu teile, nagu MyEtherwalleti puhul. Me v\u00f5tsime m\u00f5ned prefiksid, leppisime teenusepakkujaga kokku v\u00f5i h\u00e4kkisime tema, ja selle kaudu kuulutame neid v\u00f5rgus.<\/p>\n

Marsruudi lekked \u2013 route leaks<\/b>. Lekked on veidi keerukamad. Leak on AS Pathi muutmine<\/b>. Parimal juhul muudatus toob kaasa suurema viivituse, kuna peate minema pikema marsruudi kaudu v\u00f5i v\u00e4hem efektiivse lingi kaudu. Halvimal juhul kordub juhtum Google\u2019i ja Jaapaniga.<\/p>\n

Isegi Google ei ole operaator ega transiidi autonoomne s\u00fcsteem. Kuid kui ta kuulutas oma teenusepakkujale v\u00e4lja Jaapani operaatorite v\u00f5rgud, siis m\u00e4rgiti Google\u2019ist liikuv liiklus AS Pathi kaudu kui prioriteetsem. Liiklus l\u00e4ks sinna ja kukkus lihtsalt \u00e4ra, kuna Google\u2019i sees on marsruutimise seadistamine keerulisem kui lihtsalt filtrid piiril.<\/p>\n

Miks filtrid ei toimi?<\/h3>\n

\nKeegi ei hooli<\/b>. See on peamine p\u00f5hjus \u2013 k\u00f5igil on \u00fcksk\u00f5ik. V\u00e4ikese teenusepakkuja v\u00f5i ettev\u00f5tte administraator, kes on BGP kaudu teenusepakkujaga liitunud, v\u00f5ttis MikroTiki, seadistas selle BGP-le ja ei tea isegi, et seal on v\u00f5imalik filtreid seadistada.<\/p>\n

Konfiguratsiooni vead<\/b>. Midagi debug\u2019iti, viga maskis, vale v\u00f5rku pandud \u2013 ja j\u00e4lle on viga.<\/p>\n

Pole tehnilisi v\u00f5imalusi<\/b>. N\u00e4iteks teenusepakkujatel on palju kliente. Tark oleks automaatselt uuendada filtreid iga kliendi jaoks \u2013 j\u00e4lgida, et talle on tekkinud uus v\u00f5rk, et ta on oma v\u00f5rgust kellelegi rendile andnud. Selle j\u00e4lgimine on keeruline, k\u00e4sitsi \u2013 veel keerulisem. Seet\u00f5ttu pannakse lihtsalt l\u00f5dvemaid filtreid v\u00f5i ei panda filtreid \u00fcldse.<\/p>\n

Erandid<\/b>. Esinevad erandid armastatud ja suurte klientide jaoks. Eriti operaatorite vaheliste \u00fchenduste puhul. N\u00e4iteks TransTelecomil ja Rostelecomil on palju v\u00f5rke ja nende vahel on \u00fchendus. Kui \u00fchendus kukub kokku \u2013 pole kellelegi head tulemust, seet\u00f5ttu l\u00f5dvendatakse filtreid v\u00f5i eemaldatakse need t\u00e4iesti.<\/p>\n

Aegunud v\u00f5i ebat\u00e4pne teave IRR-is<\/b>. Filtrid ehitatakse \u00fcles teabe p\u00f5hjal, mis on registreeritud\u00a0IRR \u2014 Internet Routing Registry<\/b>. Need regional internet registrars. Often, the registries contain outdated or irrelevant information, or all of the above.<\/p>\n

Who are these registrars?<\/h3>\n

\"Miks
\n
\nAll addresses on the internet belong to organizations IANA \u2014 Internet Assigned Numbers Authority<\/b>. When you purchase an IP network from someone, you are not buying the addresses themselves, but the right to use them. Addresses are an intangible resource, and by common agreement, they all belong to the IANA agency.<\/p>\n

The system works like this. IANA delegates the management of IP addresses and autonomous system numbers to five regional registrars. They issue autonomous systems LIR \u2014 local internet registrars<\/b>. The LIR then allocates IP addresses to end users.<\/p>\n

The drawback of the system is that each regional registrar manages their registries in their own way. Each has its own views on what information should be contained in the registries and who should or should not verify it. As a result, we have the chaos that exists today.<\/p>\n

How else can we tackle these issues?<\/h3>\n

\nIRR \u2014 mediocre quality<\/b>. With IRR, it's clear \u2014 everything is bad there.<\/p>\n

BGP-communities<\/b>. This is a certain attribute described in the protocol. We can attach, for example, a special community to our announcement so that a neighbor does not send our networks to their neighbors. When we have a P2P link, we exchange only our networks. To prevent a route from accidentally going to other networks, we attach a community.<\/p>\n

Communities are not transitive<\/b>. It is always an agreement between two parties, and that's their downside. We cannot attach some community, except for one that is accepted by default by everyone. We cannot be sure that this community will be accepted and interpreted correctly. Therefore, at best, if you come to an agreement with your uplink, he will understand what you want regarding the community. But his neighbor may not understand it, or the operator might just drop your tag, and you won't achieve what you wanted.<\/p>\n

RPKI + ROA only solve a small part of the problems<\/b>. RPKI is Resource Public Key Infrastructure\u00a0<\/b> \u2014 a special framework for signing routing information. A good idea to make LIRs and their clients maintain an up-to-date address space database. But there is one problem with it.<\/p>\n

RPKI on ka hierarchiline avatud v\u00f5tmete s\u00fcsteem. IANAl on v\u00f5tme, mille alusel luuakse RIR v\u00f5tmed, ja nende v\u00f5tmed LIR-idele, millega nad allkirjastavad oma aadressiruumi ROA-de abil \u2014 Route Origin Authorisations:<\/p>\n

\u2014 Ma kinnitan, et see prefiks kuulutatakse v\u00e4lja selle autonoomse s\u00fcsteemi nimel.<\/i><\/p>\n

ROA-st on olemas ka teisi objekte, aga nendest hiljem. Tundub, et see on hea ja kasulik s\u00fcsteem. Kuid see ei kaitse meid lekkide eest \u00fcldse ja ei lahenda k\u00f5iki probleeme prefikside varguste osas. Seet\u00f5ttu ei kiirusta m\u00e4ngijad selle rakendamisega. Siiski on suurte m\u00e4ngijate, nagu AT&T ja suured IX-id, k\u00e4est kinnitusi, et prefiksid, millel on ROA invalid-kirjed, eemaldatakse. <\/p>\n

V\u00f5ib-olla nad teevad seda, aga praegu on meil tohutu hulk prefiksid, mis pole kuidagi allkirjastatud. \u00dchest k\u00fcljest ei ole selge, kas need kuulutatakse v\u00e4lja valideeritult. Teiselt poolt ei saa me neid vaikimisi eemaldada, kuna me ei ole kindlad, kas see on \u00f5ige v\u00f5i mitte.<\/p>\n

K\u00f5ik raamatukogud p\u00f5hinevad .NET Standard 2.0-l. Saab kasutada mis tahes kaasaegses .NET projektis.<\/h3>\n

\nBGPSec<\/b>. See on lahe s\u00fcsteem, mille l\u00f5id akadeemikud roosa poni v\u00f5rgule. Nad \u00fctlesid:<\/p>\n

\u2014 Meil on RPKI + ROA \u2014 mehhanism aadressiruumi allkirjastamise kinnitamiseks. Looge eraldi BGP-aatribuut ja nimetagem see BGPSec Path'iks. Iga ruuter allkirjastab oma allkirjaga kuulutused, mida ta naabritele kuulutab. Nii saame usaldusv\u00e4\u00e4rse tee allkirjastatud kuulutuste ahelas ja saame seda kontrollida.<\/i><\/p>\n

Teoreetikaliselt on hea, kuid praktikas on palju probleeme. BGPSec rikub paljusid olemasolevaid BGP mehhanisme j\u00e4rgmise l\u00fcli valimise ja sissetuleva\/v\u00e4ljuva liikluse haldamise osas otse ruuteris. BGPSec ei t\u00f6\u00f6ta, kuni 95% kogu turust ei rakenda seda, mis on iseenesest utoopia.<\/p>\n

BGPSec-l on tohutuid tootlikkuse probleeme. Praegusel riistvaral on kuulutuste kontrollimise kiirus umbes 50 prefiksi sekundis. V\u00f5rdluseks: praegune Interneti tabel 700 000 prefiksiga laaditakse 5 tunni jooksul, mille jooksul vahetub see veel 10 korda.<\/p>\n

BGP Open Policy (Rollip\u00f5hine BGP)<\/b>. Uus pakkumine, mis p\u00f5hineb mudelil Gao-Rexford<\/b>. Need on kaks teadlast, kes uurivad BGP-d.<\/p>\n

Gao-Rexford mudel v\u00e4ljendab j\u00e4rgmist. Lihtsustatult \u00f6eldes on BGP-s v\u00e4ike arv suhtlemise t\u00fc\u00fcpe:<\/p>\n