Miks on internet endiselt online?

Interneti tundub olevat tugev, sõltumatu ja purustamatu struktuur. Teoorias peaks võrgu vastupidavusest piisama ka tuumaplahvatuse üleelamiseks. Tegelikult võib interneti kokkuvarisemise põhjustada isegi üks väike ruuter. Kõik see tuleneb sellest, et internet on täis vastuolusid, haavatavusi, vigu ja kassi-videoid. Interneti aluseks olev BGP-protokoll kannab endas hulgaliselt probleeme. On imelik, et see veel töötab. Peale interneti enda vigade purustavad seda kõik, kes soovivad: suured interneti pakkujad, korporatsioonid, riigid ja DDoS-rünnakud. Mida sellega teha ja kuidas sellega elada?

Vastuse teab Aleksei Učakin (Night_Snake) on IQ Optioni võrguinseneride meeskonna juht. Tema peamine ülesanne on tagada platvormi kättesaadavus kasutajatele. Ajakirjanduses räägime Aлексеi ettekandest Saint HighLoad++ 2019 , kus räägime BGP-st, DDoS-rünnakutest, interneti klapi, pakkujate vigadest, detsentraliseerimisest ja juhtumist, kui väike ruuter läkitas interneti magama. Lõpus jagame mõned nõuanded, kuidas sellest üle elada.

Päev, mil internet jõudis katki

Toome välja vaid mõned intsidentid, kui internetis kadus ühendus. Seda on piisavalt, et saada täielik ülevaade.

«AS7007 intsident». Esmakordselt katkestas internet aprillis 1997. Ühe 7007 autonoomse süsteemi ruuteri tarkvaras oli viga. Teatud hetkel teatas ruuter naabritele oma sise marsruuditabelist ja suunas pool võrku musta auku.

«Pakistani rünnak YouTube'ile». 2008. aastal otsustasid julged mehed Pakistanis blokeerida YouTube'i. Nad tegid seda nii hästi, et pool maailma jäi ilma kassivideodest.

«VISA, MasterCardi ja Symantec'i prefikside haaramine Rostelekomi poolt». 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.

«Google vs Jaapan». Augustis 2017 hakkas Google teatama osa oma ülesõidudest Jaapani suurte teenusepakkujate NTT ja KDDI prefikseid. Trafik suunati Google'i nagu transit, tõenäoliselt ekslikult. Kuna Google ei ole teenusepakkuja ja ei edasta transiittrafikuid, jäi märkimisväärne osa Jaapanist ilma internetita.

«DV LINK haaras Google'i, Apple'i, Facebooki, Microsofti prefiksid». 2017. aastal hakkas Venemaa teenusepakkuja DV LINK kummalisel kombel kuulutama Google'i, Apple'i, Facebooki, Microsofti ja mõnede teiste suuremate tegijate võrgustikke.

«Ameerika Ühendriikide eNet haaras AWS Route53 ja MyEtherwalleti eelistused». 2018. aastal kuulutas mõni Ohio teenusepakkuja või tema kliendid Amazon Route53 ja krüptorahakoti MyEtherwallet võrgustikke. Rünnak õnnestus: vaatamata enesetaludusele, mis hoiatab kasutajat MyEtherwalleti saidile sisenedes, varastati paljusid rahakotte ja osa krüptovaluutast.

Aasta 2017. jooksul oli sarnaseid intsidente üle 14 000! Võrk on endiselt detsentraliseeritud, seega ei riku see kõiki ja mitte kõigis kohtades. Kuid incidente toimub tuhandeid, ja need kõik on seotud BGP-protokolliga, millega internet töötab.

BGP ja selle probleemid

Protokoll BGP - Border Gateway Protocol, mis kirjeldati esmakordselt 1989. aastal kahe inseneri poolt IBM-ist ja Cisco Systems-ist kolme «salvrätikuga» - A4-formaadis lehtedega. Need «salvrätikud» asuvad endiselt Cisco Systems'i peahoones San Franciscos võrgustiku maailma reliikviana.

Protokolli alus on autonoomsete süsteemide koostoime — Autonomous Systems ehk lühidalt - AS. Autonoomne süsteem on lihtsalt mingi ID, millele on avalikus registris kinnitatud IP-võrgud. Marsruuter sellise ID-ga võib neid võrgustikke maailmale kuulutada. Seega võib iga interneti marsruuti esitada vektorina, mida nimetatakse AS Path. Vektor koosneb autonoomsete süsteemide numbritest, mille kaudu tuleb minna, et jõuda sihtvõrku.

Näiteks, on olemas võrk, mis koosneb mitmest autonoomsest süsteemist. Tuleb minna süsteemist AS65001 süsteemi AS65003. Üks süsteem moodustab AS Path joonisel. See koosneb kahest autonoomsest süsteemist: 65002 ja 65003. Iga sihtadresse jaoks on AS Path vektor, mis koosneb süsteemide numbritest, millest peame mööduma.

Nii millised on BGP probleemid?

BGP on usaldusprotokoll

BGP-protokoll on usalduslik. See tähendab, et me usaldame oletatavalt oma naabrit. See on paljude protokollide iseloom, mis loodi interneti algusaegadel. Selgitame välja, mida tähendab «usaldame».

Naabri autentimist pole. Ametlikult on olemas MD5, kuid 2019. aastal on MD5 ... noh, mitte väga hea...

Filtreeringut pole. BGP-l on filtrid ja need on kirjeldatud, kuid neile ei pöörata tähelepanu või neid kasutatakse valesti. Hiljem selgitan, miks.

Väga lihtne on naabruskonda seadistada. Naabruse seadistamine BGP-protokollis peaaegu igas ruuteris – paar rida konfiguratsiooni.

BGP haldamiseks õigusi ei nõuta. Pole vaja sooritada eksameid, mis tõestaksid teie kvalifikatsiooni. Keegi ei võta õiguseid ära, kui seadistate BGP joobes olles.

Kaks põhiprobleemi

Prefiksite röövimine – prefix hijacks. Prefiksi röövimine – võrgu kuulutamine, mis ei kuulu teile, nagu MyEtherwalleti puhul. Me võtsime mõned prefiksid, leppisime teenusepakkujaga kokku või häkkisime tema, ja selle kaudu kuulutame neid võrgus.

Marsruudi lekked – route leaks. Lekked on veidi keerukamad. Leak on AS Pathi muutmine. Parimal juhul muudatus toob kaasa suurema viivituse, kuna peate minema pikema marsruudi kaudu või vähem efektiivse lingi kaudu. Halvimal juhul kordub juhtum Google’i ja Jaapaniga.

Isegi Google ei ole operaator ega transiidi autonoomne süsteem. Kuid kui ta kuulutas oma teenusepakkujale välja Jaapani operaatorite võrgud, siis märgiti Google’ist liikuv liiklus AS Pathi kaudu kui prioriteetsem. Liiklus läks sinna ja kukkus lihtsalt ära, kuna Google’i sees on marsruutimise seadistamine keerulisem kui lihtsalt filtrid piiril.

Miks filtrid ei toimi?

Keegi ei hooli. See on peamine põhjus – kõigil on ükskõik. Väikese teenusepakkuja või ettevõtte administraator, kes on BGP kaudu teenusepakkujaga liitunud, võttis MikroTiki, seadistas selle BGP-le ja ei tea isegi, et seal on võimalik filtreid seadistada.

Konfiguratsiooni vead. Midagi debug’iti, viga maskis, vale võrku pandud – ja jälle on viga.

Pole tehnilisi võimalusi. Näiteks teenusepakkujatel on palju kliente. Tark oleks automaatselt uuendada filtreid iga kliendi jaoks – jälgida, et talle on tekkinud uus võrk, et ta on oma võrgust kellelegi rendile andnud. Selle jälgimine on keeruline, käsitsi – veel keerulisem. Seetõttu pannakse lihtsalt lõdvemaid filtreid või ei panda filtreid üldse.

Erandid. Esinevad erandid armastatud ja suurte klientide jaoks. Eriti operaatorite vaheliste ühenduste puhul. Näiteks TransTelecomil ja Rostelecomil on palju võrke ja nende vahel on ühendus. Kui ühendus kukub kokku – pole kellelegi head tulemust, seetõttu lõdvendatakse filtreid või eemaldatakse need täiesti.

Aegunud või ebatäpne teave IRR-is. Filtrid ehitatakse üles teabe põhjal, mis on registreeritud IRR — Internet Routing Registry. Need regional internet registrars. Often, the registries contain outdated or irrelevant information, or all of the above.

Who are these registrars?

All addresses on the internet belong to organizations IANA — Internet Assigned Numbers Authority. 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.

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 — local internet registrars. The LIR then allocates IP addresses to end users.

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.

How else can we tackle these issues?

IRR — mediocre quality. With IRR, it's clear — everything is bad there.

BGP-communities. 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.

Communities are not transitive. 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.

RPKI + ROA only solve a small part of the problems. RPKI is Resource Public Key Infrastructure  — 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.

RPKI on ka hierarchiline avatud võtmete süsteem. IANAl on võtme, mille alusel luuakse RIR võtmed, ja nende võtmed LIR-idele, millega nad allkirjastavad oma aadressiruumi ROA-de abil — Route Origin Authorisations:

— Ma kinnitan, et see prefiks kuulutatakse välja selle autonoomse süsteemi nimel.

ROA-st on olemas ka teisi objekte, aga nendest hiljem. Tundub, et see on hea ja kasulik süsteem. Kuid see ei kaitse meid lekkide eest üldse ja ei lahenda kõiki probleeme prefikside varguste osas. Seetõttu ei kiirusta mängijad selle rakendamisega. Siiski on suurte mängijate, nagu AT&T ja suured IX-id, käest kinnitusi, et prefiksid, millel on ROA invalid-kirjed, eemaldatakse.

Võib-olla nad teevad seda, aga praegu on meil tohutu hulk prefiksid, mis pole kuidagi allkirjastatud. Ühest küljest ei ole selge, kas need kuulutatakse välja valideeritult. Teiselt poolt ei saa me neid vaikimisi eemaldada, kuna me ei ole kindlad, kas see on õige või mitte.

Kõik raamatukogud põhinevad .NET Standard 2.0-l. Saab kasutada mis tahes kaasaegses .NET projektis.

BGPSec. See on lahe süsteem, mille lõid akadeemikud roosa poni võrgule. Nad ütlesid:

— Meil on RPKI + ROA — 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äärse tee allkirjastatud kuulutuste ahelas ja saame seda kontrollida.

Teoreetikaliselt on hea, kuid praktikas on palju probleeme. BGPSec rikub paljusid olemasolevaid BGP mehhanisme järgmise lüli valimise ja sissetuleva/väljuva liikluse haldamise osas otse ruuteris. BGPSec ei tööta, kuni 95% kogu turust ei rakenda seda, mis on iseenesest utoopia.

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

BGP Open Policy (Rollipõhine BGP). Uus pakkumine, mis põhineb mudelil Gao-Rexford. Need on kaks teadlast, kes uurivad BGP-d.

Gao-Rexford mudel väljendab järgmist. Lihtsustatult öeldes on BGP-s väike arv suhtlemise tüüpe:

• Provider Customer;
• P2P;
• sisedialoog, ütleme, iBGP.

Marsruuteri rolli põhjal saab vaikimisi rakendada teatud impordi/ekspordi poliitikaid. Halduse isik ei pea konfigureerima eelistuste loendeid. Marsruuteri vahel kokkulepitud rolli alusel, mille saab määrata, saame juba mõned vaikimisi filtrid. Praegu on see kavand, mis on arutusel IETF-is. Loodetavasti näeme seda peagi RFC ja seadme rakenduses.

Suured Interneti-teenuse pakkujad

Vaatame näitena teenusepakkujat CenturyLink. See on Ameerika Ühendriikide kolmas suurim teenusepakkuja, mis teenindab 37 osariiki ja omab 15 andmekeskust. 

2018. aasta detsembris oli CenturyLink Ameerika Ühendriikide turul 50 tundi maas. Intsidendi ajal olid probleemid automaatide toimimises kahes osariigis, 911 number ei töötanud mitu tundi viies osariigis. Samuti kukkus loterii Idaho osariigis ära. Selle intsidendi tõttu uurib Ameerika Ühendriikide kommunikatsioonikomisjon praegu.

Traagika põhjuseks oli üks võrgukaart ühes andmekeskuses. Kaart ebaõnnestus, saates vale pakette ning kõik 15 teenusepakkuja andmekeskust kukkusid kokku.

Selle teenusepakkuja puhul ei toiminud idee «liialt suur, et kukkuda». See idee ei toimi tõesti. Võib võtta mistahes suurt mängijat ja kukutada selle mingi pisiasjaga. Ameerika Ühendriikides on veel kõik hästi ühenduvuse osas. CenturyLinki kliendid, kellel oli varu, lahkusid massiliselt. Hiljem kurtsid alternatiivsed operaatorid oma linkide ülekoormuse üle.

Kui kukub niisugune «Kazakhtelecom», jääb kogu riik Internetita.

Korporatsioonid

Kas internet sõltub tõepoolest Google'ist, Amazonist, Facebookist ja teistest korporatsioonidest? Ei, nad rikuvad seda samuti.

2017. aastal Peterburis konverentsil ENOG13 Jeff Houston API-s APNIC esitles ettekanne «Transiidi surm». Sellega seoses öeldi, et oleme harjunud, et suhted, rahaliikumine ja interneti liiklus on vertikaalsed. Meil on väikesed teenusepakkujad, kes maksavad suurematele, ja need maksavad omakorda globaalsele transpordile.

Hetkel on meil selline vertikaalselt suunatud struktuur. Kõik oleks hästi, aga maailm muutub — suured mängijad ehitavad oma ookeanialuseid kaableid, et luua oma backboned.

Uudised CDN-kaabli kohta.

2018. aastal avaldas TeleGeography uuringu, et enam kui pool interneti liiklusest ei ole enam internet, vaid suurte mängijate CDN-ide selg. See on liiklus, mis on seotud internetiga, kuid see ei ole enam see võrk, millest me rääkisime.

Internet laguneb suureks nõrgalt omavahel seotud võrkude kogumikuks.

Microsoftil on oma võrk, Google'il on oma, ja nad on omavahel nõrgalt seotud. Liiklus, mis algas kuskil Ameerikas, liigub Microsofti kanalite kaudu ookeani üle Euroopasse, kus see jõuab CDN-i, sealt edasi läbi CDN-i või IX-i seondub teie teenusepakkujaga ja jõuab teie ruuterisse.

Decentraliseerimine kaob.

See interneti tugev külg, mis aitas tal ellu jääda pärast tuumaplahvatust, kaob. Kasutajate ja liikluskoondumiskohtade ilmumine. Kui näiteks Google Cloud kukub, saavad paljud korraga kannatada. Osa sellest tundsime, kui Roskomnadzor AWS-i blokkeeris. CenturyLinki näitel on näha, et isegi väikese probleemiga on piisav.

Varem ei murdunud kõik ja mitte kõigil. Tulevikus võime jõuda selleni, et mõjutades ühte suurt mängijat, saame palju asju, palju kohti ja palju inimesi rikutud.

Riigid

Järgmised järjekorras on riigid, ja nendega juhtub tavaliselt nii.

Siin ei ole meie Roskomnadzor sugugi pioneer. Sarnane Interneti-katkestamise praktika on Iraanis, Indias, Pakistanis. Suurbritannias on seadusandlik algatus, mis lubab interneti väljalülitamist.

Iga suur riik soovib omada lülitit, et internetit kas täielikult või osaliselt välja lülitada: Twitter, Telegram, Facebook. Nad ei saa päris hästi aru, et nad ei saavuta seda kunagi, kuid nad väga tahavad. Lülitit rakendatakse tavaliselt poliitilistel eesmärkidel – poliitiliste konkurentide eemaldamiseks, või kui valimised on tulekul, või kui venelased häkkisid jälle midagi katki.

DDoS rünnakud

Ma ei hakka võtma leiba kolleegidelt Qrator Labs'ist, nad teevad seda palju paremini kui mina. Neil on aastaaruanne interneti stabiilsusest. Ja siin on, mida nad 2018. aasta aruandes kirjutasid.

Keskmine DDoS-rünnakute kestus langeb 2.5 tunnini. Ründajad hakkavad samuti raha lugema ja kui ressurss ei murdu kohe, siis jäetakse see kiiresti rahule.

Rünnakute intensiivsus kasvab. 2018. aastal nägime 1.7 Tb/s Akamai võrgus, ja see ei ole piir.

Käibele tulevad uued rünnakusuunad ja vanad tugevnevad. Tekkivad uued protokollid, mis on vastuvõtlikud amplifitseerimisele, esinevad uued rünnakud olemasolevatele protokollidele, eriti TLS-ile ja sarnastele.

Suurem osa liiklusest on mobiilseadmed. Samal ajal liigub internetiliiklus mobiiliklientidele. Sellega peavad toime tulema nii ründajad kui ka kaitsjad.

Terveid pole. See on peamine mõttepunkt - universaalset kaitset, mis kaitseks igasuguste DDoS rünnakute eest, ei eksisteeri ja ei teki.

Süsteemi ei saa maas kitkuda, kui see ei ole internetiga ühendatud.

Loodan, et ma olen teid piisavalt hirmutanud. Räägime nüüd, mida sellega ette võtta.

Mida teha?!

Kui teil on aega, soovi ja inglise keele oskust – võtke osa töörühmades: IETF, RIPE WG. Need on avatud meililood, liituge uudiskirjadega, osalege aruteludes, tulge konverentsidele. Kui teil on LIR staatuse, siis saate hääletada näiteks RIPE'is erinevate algatuste poolt.

Tavalistele surmaga lõppevatele – see monitooring. Et teada, mis on katki.

Jälgimine: mida kontrollida?

Tavaline Ping, ja mitte ainult binaarne kontroll – kas töötab või mitte. Salvestage RTT ajaloosse, et hiljem vaadata anomaaliaid.

Traceroute. See on abiprogramm andmete edastusteede määramiseks TCP/IP võrkudes. Aitab tuvastada anomaaliaid ja blokeeringuid.

HTTP checks - kontrollid custom URL ja TLS sertifikaate aitavad tuvastada blokeeringuid või DNS-i vahetuste rünnakut, mis on praktiliselt sama. Blokeeringud teostatakse sageli DNS-i vahetuste kaudu ja liikluse suunamisega ummistuse lehe peale.

Kui võimalik, kontrollige oma klientide lahendust oma origini erinevates kohtades, kui teil on rakendus. Nii saate tuvastada DNS-i vahelesegamise anomaaliaid, millega mõnikord riskivad teenusepakkujad.

Jälgimine: kust kontrollida?

Ühtset vastust pole. Kontrollige sealt, kust kasutajad tulevad. Kui kasutajad on Venemaal – kontrollige Venemaalt, kuid ärge piirdage ainult sellega. Kui teie kasutajad elavad erinevates piirkondades – kontrollige neist piirkondadest. Kuid parem on kontrollida üle kogu maailma.

Jälgimine: millega kontrollida?

Olen välja mõelnud kolm meetodit. Kui teate rohkem – kirjutage kommentaarides.

• RIPE Atlas.
• Kommertse jälgimine.
• Oma virtuaalvõrk.

Räägime igaühe kohta.

RIPE Atlas — see on selline väike karp. Neile, kes tunnevad kodumaist "Revisori" — see on sama karp, kuid teise sildiga.

RIPE Atlas — tasuta programm. Te registreerite, saate posti teel ruuteri ja ühendate selle võrguga. Selle eest, et keegi teine kasutab teie proovimist, saate teatud krediite. Nende krediitide eest saate ise teostada mõningaid uuringuid. Testida saab erinevalt: ping, traceroute, sertifikaatide kontrollimine. Katvus on üsna suur, palju nodi. Kuid on nüansse.

Krediidisüsteem ei võimalda ehitada tootmislahendusi. Pidevaks uurimiseks või ärimonitoringu jaoks ei piisa krediitidest. Krediite jätkub lühiajaliseks uurimiseks või ühekorra kontrollimiseks. Päevane norm ühe prooviga tarbitakse 1-2 kontrolliga.

Katvus on ebaühtlane. Kuna programm on tasuta mõlemalt poolt, siis on katvus hea Euroopas, Venemaa Euroopa osas ja mõnedes piirkondades. Kuid kui vajate Indoneesiat või Uut Meremaat, siis on kõik palju halvem — 50 proovi riigi kohta ei pruugi kokku saada.

http kontrolli proovist ei saa teha. See on põhjustatud tehnilistest nüanssidest. Lubatakse parandada uues versioonis, kuid praegu ei saa http-d kontrollida. Saate kontrollida ainult sertifikaati. Mõningasuguse http kontrolli saab teha ainult spetsiaalse RIPE Atlase seadme, mida nimetatakse Anchor.

Teine meetod — ärimonitoring. Sellega on kõik hästi, maksate raha? Teile lubatakse mitukümmend või isegi sadu monitorimispunkte üle kogu maailma, joonistatakse kauneid juhtpaneele "karbist". Kuid taas, on probleeme.

See on tasuline, kohati väga. Pingi monitorimine, kontrollid üle kogu maailma ja mitmed http kontrollid võivad maksma minna mitu tuhat dollarit aastas. Kui rahandust võimaldab ja teile meeldib see lahendus — palun.

Katvus võib huvipakkuvas piirkonnas puududa. Sama pingi abil täpsustatakse maksimaalselt abstraktne osa maailmast — Aasia, Euroopa, Põhja-Ameerika. Haruldased monitorimissüsteemid suudavad proovi detailida konkreetse riigi või piirkonna tasemele.

Kohandatud testide nõrk tugi. Kui vajate midagi kohandatud, mitte lihtsalt "kurlyk" url-il, siis on ka sellega probleeme.

Kolmas meetod — oma monitorimine. See on klassika: "Teeme oma!"

Teie jälgimine muutub jaotatud tarkvara arendamiseks. Otsite infrastruktuuri pakkujat, vaatate, kuidas seda juurutada ja jälgida — jälgimist tuleb ju jälgida, eks? Ja vajalik on ka tugi. Mõelge kümme korda, enne kui selle ülesande peale asute. Võib-olla on lihtsam maksta kellelegi, kes teeb selle teie eest.

BGP-anomaaliate ja DDoS-rünnakute jälgimine

Siin on saadaval olevate ressursside puhul veelgi lihtsam. BGP-anomaaliad tuvastatakse spetsialiseeritud teenuste, nagu QRadar, BGPmon, abil.. Nad võtavad vastu full view tabeli mitmelt operaatorilt. Selle põhjal, mida nad erinevatelt operaatoritelt näevad, saavad nad tuvastada anomaaliaid, otsida võimendajaid jne. Reeglina on registreerimine tasuta — sisestate oma autonoomse numbri, tellite e-posti teavitused ja teenus hoiatab teid teie probleemide eest.

DDoS-rünnakute jälgimine on samuti lihtne. Reeglina on see NetFlow-põhine ja logid. On spetsialiseeritud süsteeme, nagu FastNetMon, moodulid jaoks Splunk. Äärmuslikel juhtudel on teie DDoS-kaitse pakkuja. Talle saab ka NetFlow andmeid edastada ja tema põhjal teavitab ta teid rünnakutest teie suunas.

Järeldused

Ärge pidage illusioone — internet puruneb kindlasti. Mitte kõik ja mitte kõikjal, kuid 14 000 intsidendi 2017. aastal vihjab, et sündmusi tuleb.

Teie ülesanne on märgata probleeme võimalikult varakult. Vähemalt mitte hiljem kui teie kasutaja. Lisaks on oluline mitte ainult märgata, vaid alati hoida käepärast "B-plaan". Plaani — see on strateegia, mida teete, kui kõik puruneb: varuoperaatorid, andmekeskused, CDN. Plaan on eraldi kontrollnimekiri, mille järgi kontrollite kõike töötamist. Plaan peab töötama ilma võrguinseneride kaasamiseta, sest neid on tavaliselt vähe ja nad tahavad magada.

Sellega on kõik. Soovin teile suurt kättesaadavust ja roheline jälgimine.

Järgmise nädala prognoosi kohaselt oodatakse Novosibirskis päikest, kõrge koormuse ja kõrge kontsentratsiooni arendajate jaoks HighLoad++ Siberia 2019. Siberis prognoositakse ettekannete fronti jälgimise, kättesaadavuse ja testimise, turvalisuse ja juhtimise teemal. Oodatakse sademeid, vormitud märkmeid, võrku loomist, fotosid ja postitusi sotsiaalmeedias. Soovitame kõik asjad edasi lükata 24. ja 25. juunil ja broneerida lennupiletid. Ootame teid Siberisse!

Allikas: habr.com