Az internet erős, független és megbonthatatlan struktúrának tűnik. Elméletben a hálózat erőssége elég ahhoz, hogy túlélje egy nukleáris robbantást. A valóságban azonban az internetet egyetlen kis router is le tudja kapcsolni. Mindez azért van, mert az internet ellentmondások, sebezhetőségek, hibák és macskás videók halmaza. Az internet alapja, a BGP protokoll, tele van problémákkal. Meglepetés, hogy még mindig működik. Ezen kívül mindenki, akinek kedve van, megtöri: nagy internetes szolgáltatók, vállalatok, államok és DDoS-támadások. Mit tegyünk ezzel kapcsolatban, és hogyan éljünk együtt ezzel?
A válasz tudja Alexey Uchakov () – a hálózati mérnökök csapatának vezetője az IQ Option-nél. Fő feladata a platform elérhetősége a felhasználók számára. Alexey előadásának átírásában a beszélni fogunk a BGP-ről, DDoS-támadásokról, az internettől való lekapcsolásról, a szolgáltatók hibáiról, a decentralizációról és az esetről, amikor egy kis router az internetet aludni küldte. A végén egy pár tipp, hogyan éljük túl mindezt.
A nap, amikor az internet megállt
Csak néhány olyan incidenst hozok, amikor az internet összeköttetése megszakadt. Ez elegendő lesz a teljes képhez.
„AS7007-es incidens”. Először 1997 áprilisában állt meg az internet. Az 7007-es autonóm rendszer egyik routerében hiba volt. Egy ponton a router bejelentette szomszédainak a belső útvonal táblázatát, és a hálózat felét a fekete lyukba küldte.
„Pakisztán a YouTube ellen”. 2008-ban a bátor pakisztáni fiúk úgy döntöttek, hogy blokkolják a YouTube-ot. Olyan jól csinálták, hogy a világ felének elment a macskás videója.
„A VISA, MasterCard és Symantec prefixek Rostelekom általi elfogása”. 2017-ben a Rostelekom véletlenül elkezdte bejelenteni a VISA, MasterCard és Symantec prefixeket. Ennek következményeként a pénzügyi forgalom olyan csatornákra irányult, amelyeket a szolgáltató irányít. A szivárgás nem sokáig tartott, de a pénzügyi cégek számára kellemetlen volt.
„Google Japán ellen”. 2017 augusztusában a Google elkezdett bejelenteni a nagy japán szolgáltatók, az NTT és a KDDI prefixeit egyes uplinkjein. A forgalom transit szerverként érkezett a Google-hoz, valószínűleg tévedésből. Mivel a Google nem szolgáltató, és nem engedi át a transit forgalmat, Japán jelentős része internet nélkül maradt.
„A DV LINK elfoglalta a Google, Apple, Facebook, Microsoft prefixeit“. Ugyanebben az évben, 2017-ben, a DV LINK orosz szolgáltató miért is, de bejelentette a Google, Apple, Facebook, Microsoft és néhány más nagy szereplő hálózatait.
„Az eNet az Egyesült Államokból elfoglalta az AWS Route53 és a MyEtherwallet prefixeit“. 2018-ban egy Ohio-i szolgáltató vagy az egyik ügyfelük bejelentette az Amazon Route53 és a MyEtherwallet kriptotárca hálózatait. A támadás sikeres volt: még a saját aláírású tanúsítvány ellenére is, amely figyelmeztetést adott a felhasználónak, amikor a MyEtherwallet oldalára lépett, sok tárcát elloptak, és részben kriptovalutát loptak el.
Csak 2017-ben több mint 14 000 hasonló incidens történt! A hálózat még mindig decentralizált, tehát nem mindenhol és nem mindenkinél történt meg a hiba. De az incidensek ezrével fordulnak elő, és mind a BGP protokollhoz kapcsolódnak, amelyen az internet működik.
A BGP és annak problémái
Protokoll A BGP – Border Gateway Protocol, először 1989-ben két mérnök, az IBM és a Cisco Systems-től, három „szalvétán” – A4-es papírlapokon írták le. Ezek még mindig a Cisco Systems fő irodájában, San Franciscóban találhatóak, mint a hálózati világ relikviái.
A protokoll alapja az autonóm rendszerek közötti interakció – Autonomous Systems, vagy röviden AS. Az autonóm rendszer egy egyszerű ID, amelyhez a nyilvános nyilvántartásban IP hálózatok vannak rendelve. Az ilyen ID-vel rendelkező router be tudja jelenti a világba ezeket a hálózatokat. Ennek megfelelően bármely internetes útvonalat egy vektorként lehet ábrázolni, amit AS Path-nakhívnak. A vektor az autonóm rendszerek számaiból áll, amelyeken át kell jutnunk, hogy elérjük a célhálózatot.
Például van egy hálózat néhány autonóm rendszertől. El kell érnünk az AS65001 rendszerből az AS65003 rendszerbe. Az egyik rendszerből a másikba vezető utat az AS Path ábrázolja a diagramon. Két autonóm rendszerből áll: 65002 és 65003. Minden célcímhez egy AS Path vektor tartozik, amely az átjárandó autonóm rendszerek számaiból áll.
Milyen problémái vannak tehát a BGP-nek?
A BGP egy bizalmi protokoll
A BGP protokoll – trust based. Ez azt jelenti, hogy alapértelmezetten megbízunk a szomszédunkban. Ez számos protokoll speciális jellemzője, amelyeket az internet hajnalán fejlesztettek ki. Nézzük meg, mit jelent a „megbízni”.
Nincs szomszéd azonosítás. Formálisan van MD5, de az MD5 2019-ben – hát, nem túl jó…
Nincs szűrés. A BGP-nek vannak filterei, és ezek le vannak írva, de nem használják őket, vagy helytelenül használják. Később elmagyarázom, miért.
Nagyon egyszerű beállítani a szomszédságot. A szomszédság beállítása a BGP protokollban szinte bármelyik routeren pár soros konfiguráció.
Nincsenek szükségletek a BGP kezelésére. Nem szükséges vizsgát tenni, amely igazolja a képesítéseit. Senki nem veszi el a jogait, ha részeg állapotban állít be BGP-t.
Két fő probléma
Prefix eltulajdonítás - prefix hijacks. A prefix eltulajdonítása - egy olyan hálózat bejelentése, amely nem az öné, mint a MyEtherwallet esetén. Elvettünk néhány prefixet, megállapodtunk a szolgáltatóval vagy feltörtük, és rajta keresztül bejelentjük ezeket a hálózatokat.
Útvonal szivárgások - route leaks. A szivárgással kicsit bonyolultabb a helyzet. A szivárgás az AS Path megváltoztatása. A legjobb esetben a változás nagyobb késést okoz, mert hosszabb vagy kevésbé elágazó linken kell haladnia. A legrosszabb esetben a Google és Japán esete ismétlődni fog.
Magának a Google-nak nincsenek üzemeltetési jogai és nem tranzit autonóm rendszer. De amikor bejelentette a japán szolgáltatók hálózatait a szolgáltatójának, a Google által generált forgalom az AS Path-on priorizáltabbnak tűnt. A forgalom odament, és egyszerűen leesett, mert a Google belső útválasztási beállításai bonyolultabbak, mint a határon lévő filterek.
Miért nem működnek a filterek?
Senkit sem érdekel. Ez a fő ok - mindenkinek mindegy. Egy kicsi szolgáltató adminisztrátora, vagy egy cég, amely BGP-n keresztül csatlakozott egy szolgáltatóhoz, vett egy MikroTik-et, beállította rajta a BGP-t, és még csak nem is tud arról, hogy lehet filtereket beállítani.
Konfigurációs hibák. Valamit debugoltak, hibáztak a maszkban, rossz hálózatot állítottak be - és íme, ismét hiba.
Nincs technikai lehetőség. Például a szolgáltatóknál sok ügyfél van. Okosan érdemes lenne automatikusan frissíteni a filtereket minden egyes ügyfél számára - figyelni, hogy új hálózata van, hogy bérbe adta a hálózatát valakinek. Ezt nehéz figyelni, kézzel még nehezebb. Ezért egyszerűen laza filtereket állítanak be, vagy egyáltalán nem állítanak be filtereket.
Kivétel. Vannak kivételek a kedvenc és nagy ügyfelek számára. Különösen a szolgáltatók közötti interfészek esetén. Például a TransTelecomnak és a Rosztelkomnak rengeteg hálózata van, és közöttük interfész található. Ha az interfész megszakad - senkinek sem lesz jó, ezért a filtereket lazítják, vagy teljesen eltávolítják.
Elavult vagy elavult információ az IRR-ben. A szűrők az alapján épülnek fel, ami fel van jegyezve IRR – Internet Routing Registry. Ezek a regionális internetnyilvántartók. Gyakran a nyilvántartókban elavult vagy nem aktuális információ található, vagy mindkettő.
Kik ezek a regisztrátorok?
Minden internetes cím a következő szervezethez tartozik IANA – Internet Assigned Numbers Authority. Amikor valakitől IP hálózatot vásárol, akkor nem címeket, hanem azok használati jogát vásárolja meg. A címek immateriális erőforrások, és közös megállapodás alapján mind a IANA ügynökséghez tartoznak.
A rendszer így működik. IANA delegálja az IP-címek és az autonóm rendszerek számának kezelését öt regionális regisztrátor számára. Ők autonóm rendszereket adnak ki LIR – helyi internetnyilvántartók. A LIR-ek ezután IP-címeket osztanak ki végfelhasználóknak.
A rendszer hátránya, hogy mindegyik regionális regisztrátor a saját módján vezeti a nyilvántartásokat. Mindenkinek megvannak a saját elképzelései arról, hogy milyen információknak kellene szerepelniük a nyilvántartásokban, ki fogja ellenőrizni, vagy ki nem. Ennek eredményeként a helyzet jelenleg zűrzavart okoz.
Miként lehetne még harcolni ezekkel a problémákkal?
IRR – közepes minőség. Az IRR helyzete egyértelmű – ott minden rosszul áll.
BGP-communities. Ez egy bizonyos attribútum, amelyet a protokoll definiál. Például specialis közösséget rendelhetünk a bejelentésünkhöz, hogy a szomszédunk ne küldje a hálózatainkat a saját szomszédainak. Amikor P2P kapcsolatunk van, csak a saját hálózatainkat cseréljük.
A közösségek nem tranzitívak. Ez mindig egy kétoldalú megállapodás, és ez a hátrányuk. Nem rendelhetünk hozzá más közösséget, kivéve egyet, amelyet mindenki alapértelmezés szerint elfogad. Nem lehetünk biztosak abban, hogy ezt a közösséget mindenki elfogadja és helyesen értelmezi. Ezért, legjobb esetben, ha megállapodást köt a saját uplinkjével, megérti, hogy mit szeretne a közösségen keresztül. De a szomszédja nem biztos, hogy megérti, vagy az üzemeltető egyszerűen eltávolítja a címkét, és nem éri el, amit szeretett volna.
Az RPKI + ROA csak a problémák kis részét oldja meg. Az RPKI – ez egy Resource Public Key Infrastructure — speciális keretrendszer az útvonal-információk aláírására. Jó ötlet, hogy a LIR-ek és ügyfeleik naprakészen tartsák az címzett tartományi adatbázist. De ezzel van egy probléma.
Az RPKI egy hierarchikus nyílt kulcsrendszer is. Az IANA-nak van kulcsa, amelyből a RIR kulcsok készülnek, és ezekből a LIR kulcsok, amelyek az ő címzett tartományukat ROA-k segítségével írják alá — Route Origin Authorisations:
— Én tanúsítom, hogy ez a prefix ezt az autonóm rendszert képviselve fog bejelentésre kerülni.
A ROA-n kívül vannak más objektumok is, de arról majd később. Úgy tűnik, hogy ez egy jó és hasznos dolog. De nem véd meg minket a leak-elésektől egyáltalán, és nem oldja meg minden prefix-eltérítési problémát. Ezért a szereplők nem sietnek a bevezetésével. Bár már a nagyobb szereplők, mint az AT&T, és nagy IX-ek biztosítják, hogy a nevében érvénytelen ROA-val rendelkező prefixeket el fogják dobni.
Lehet, hogy ezt meg fogják tenni, de jelenleg hatalmas mennyiségű prefix létezik, amelyek egyáltalán nincsenek aláírva. Egyrészt nem világos, hogy érvényesen kerülnek-e bejelentésre. Másrészt nem tudjuk őket alapértelmezés szerint eldobni, mert nem vagyunk benne biztosak, hogy helyes ez vagy sem.
Mi van még?
BGPSec. Ez egy nagyszerű dolog, amit akadémikusok találtak ki a rózsaszín pónik számára. Azt mondták:
— Van RPKI + ROA — egy mechanizmus az címzett tartomány aláírásának tanúsítására. Létrehozhatunk egy külön BGP-attribútumot, és nevezzük el BGPSec Path-nak. Minden router a saját aláírásával alá fogja írni azokat a bejelentéseket, amelyeket szomszédainak bejelent. Így egy megbízható utat kapunk az aláírt bejelentések láncán, amelyet ellenőrizhetünk.
Elméletben jól hangzik, de a gyakorlatban sok probléma van. A BGPSec sok meglévő BGP mechanizmust megzavar a next-hop kiválasztásában és a bejövő/kimenő forgalom kezelésében közvetlenül a routeren. A BGPSec nem működik, amíg a piacon részt vevő 95% nem vezeti be, ami önmagában utópia.
A BGPSec-nek hatalmas teljesítménybeli problémái vannak. Jelenlegi hardveren a bejelentések ellenőrzési sebessége körülbelül 50 prefix másodpercenként. Összehasonlításképpen: a jelenlegi internetes táblázatban, amely 700 000 prefixet tartalmaz, 5 órát fog tartani, ami alatt még 10 alkalommal változik meg.
BGP Open Policy (Szerepalapú BGP). Friss javaslat egy modellt alapján Gao-Rexford. Ők ketten BGP kutatással foglalkozó tudósok.
A Gao-Rexford model consists of the following. To simplify, in the case of BGP, there are a few types of interactions:
- Provider Customer;
- P2P;
- internal interaction, say, iBGP.
Based on the role of the router, certain import/export policies can be applied by default. The administrator does not need to configure prefix lists. Depending on the role that routers agree upon and can set, we obtain certain default filters. This is currently a draft being discussed at IETF. I hope that soon we will see it in the form of an RFC and implementation on hardware.
Large Internet providers
Let's take the example of the provider CenturyLink. This is the third largest provider in the USA, serving 37 states and having 15 data centers.
In December 2018, CenturyLink was down in the USA for 50 hours. During the incident, there were problems with ATM operations in two states, and the 911 number was out of service for several hours in five states. Additionally, the lottery in Idaho was disrupted. The US Federal Communications Commission is currently investigating this incident.
The cause of the tragedy was one network card in one data center. The card failed, sending incorrect packets, causing all 15 data centers of the provider to go down.
For this provider, the idea of ‘too big to fail’did not hold. This idea does not work in general. One can take any large player and take them down with something minor. In the USA, connectivity is still doing well. CenturyLink customers with reserves massively switched to it. Then alternative operators complained about the overload of their links.
If a hypothetical ‘Kazakhtelecom’ goes down, the entire country will be left without the internet.
Corporations
Is the internet probably held up by Google, Amazon, Facebook, and other corporations? No, they break it too.
At the ENOG13 conference in Saint Petersburg in 2017, Jeff Houston a , az öt regionális internet regisztrátor egyike, bemutatott . It mentions that we have gotten used to the fact that interactions, cash flows, and internet traffic are vertical. We have small providers that pay for connectivity to larger ones, and those pay for connectivity to global transit.
Jelenleg egy vertikálisan orientált struktúrával rendelkezünk. Mindez rendben lenne, de a világ változik - a nagy szereplők saját transzkontinentális kábeleiket építik saját nevük alatt.
Hír a CDN-kábellel kapcsolatban.
2018-ban a TeleGeography kiadott egy kutatást, amelyben azt állítják, hogy az internetforgalom több mint fele már nem az internet, hanem a nagy szereplők CDN backbone-jai. Ez a forgalom kapcsolódik az internethez, de ez már nem az a hálózat, amiről beszéltünk.
Az internet egy nagy, gyengén összekapcsolt hálózatokra bomlik.
A Microsoftnak van saját hálózata, a Google-nak is a sajátja, és egymással gyengén keresztezik egymást. A forgalom, amely valahol az Egyesült Államokban keletkezett, a Microsoft csatornáin keresztül halad át az óceánon Európába valahol a CDN-en, onnan a CDN vagy IX révén csatlakozik az ön szolgáltatójához, és eljut az ön routeréhez.
A decentralizáció eltűnik.
Ez az internet erőssége, ami segítene neki túlélni egy nukleáris robbanást, elvész. Megjelennek a felhasználók és a forgalom koncentrációs helyei. Ha egy feltételezett Google Cloud leáll, rengeteg ember szenved egyszerre. Részben ezt már éreztük, amikor a Roszkomnadzor letiltotta az AWS-t. A CenturyLink példáján látszik, hogy ehhez elég egy apróság is.
Korábban nem mindenki és nem mindenhol omlott össze. A jövőben odáig juthatunk, hogy ha egy nagy szereplőt megcélozunk, sok mindent tönkretehetünk, sok helyen és sok embernél.
Államok
A következő az államok, és a velük általában így történik.
Itt a Roszkomnadzorunk valójában soha nem volt élenjáró. Az internet leállításának hasonló gyakorlata van Iránban, Indiában, Pakisztánban. Angliában van egy törvényjavaslat az internet leállításának lehetőségéről.
Bármely nagy állam szeretné megszerezni a kapcsolót, hogy az internetet vagy teljesen, vagy részenként le tudja kapcsolni: Twitter, Telegram, Facebook. Nem úgy van, hogy nem értik, hogy ez soha nem fog sikerülni, de nagyon szeretnék. A kapcsolót általában politikai célokra alkalmazzák - a politikai versenytársak eltávolítására, vagy közelgő választásokkor, vagy orosz hackerek ismét valamit tönkre tettek.
DDoS-támadások
Nem fogom elvenni a kenyeret a Qrator Labs barátaitól, ők sokkal jobban csinálják ezt, mint én. Van nekik az internet stabilitásáról. És itt van, amit az ő 2018-as jelentésükben írtak.
A DDoS-támadások átlagos időtartama 2,5 órára csökken.. A támadók is elkezdik számolni a pénzt, és ha az erőforrás nem dőlt meg azonnal, akkor gyorsan otthagynak.
Növekszik a támadások intenzitása. 2018-ban 1.7 Tb/s-ot láttunk az Akamai hálózatán, és ez még nem a végső határ.
Új támadási vektorok jelennek meg, és a régi vektorok erősödnek.. Új, fokozó hatású protokollok jelennek meg, új támadások alakulnak ki a meglévő protokollok ellen, különösen a TLS-sel és hasonlókkal szemben.
A forgalom jelentős része mobil eszközökön zajlik. Ezzel párhuzamosan az internetes forgalom mobil kliensre vált. Ezzel dolgozni kell, legyen szó támadókról vagy védelmi szakemberekről.
Nincs sebezhetetlen rendszer. Ez a fő üzenet – nem létezik és nem is fog megjelenni egy univerzális védelem, amely biztosan megvéd minden DDoS-tól.
Az rendszert nem lehet leállítani, csak akkor, ha nincs internetkapcsolata.
Remélem, eléggé megijesztettelek. Most gondolkodjunk el azon, hogy mit kezdjünk vele.
Mit tegyünk?!
Ha van szabadidőd, kedved és angoltudásod, csatlakozz a munkacsoportokhoz: IETF, RIPE WG. Ezek nyílt levelezőlisták, iratkozz fel a hírlevelekre, vegyél részt a megbeszéléseken, látogass el konferenciákra. Ha van LIR státuszod, szavazhatsz például a RIPE-ban különböző kezdeményezésekért.
A hétköznapi emberek számára ez: monitorozás. Hogy tudd, mi romlott el.
Monitoring: mit ellenőrizzünk?
Normál Ping, és nemcsak bináris ellenőrzés – működik-e vagy sem. Mentse el az RTT-t a történelembe, hogy később észlelhesse az anomáliákat.
Traceroute. Ez egy segédprogram a TCP/IP hálózatok adatforgalmának útvonalváltásának meghatározására. Segít az anomáliák és blokkolások azonosításában.
HTTP ellenőrzések – egyedi URL-k és TLS tanúsítványok segítenek felfedezni a blokkolásokat vagy a DNS hamisítást a támadás során, ami lényegében ugyanaz. A blokkolások gyakran DNS hamisítással és a forgalom elterelésével történnek egy figyelmeztető oldalra.
Ha van rá lehetőség, ellenőrizze az originjének elérhetőségét a különböző helyekről az ügyfeleitől, ha van alkalmazása. Így észlelheti a DNS lehallgatásának anomáliáit, amiben néha a szolgáltatók is vétkesek.
Monitoring: honnan ellenőrizzünk?
Nincs univerzális válasz. Ellenőrizze, ahonnan a felhasználó érkezik. Ha a felhasználók Oroszországban vannak – ellenőrizzen Oroszországból, de ne korlátozódjon csak erre. Ha a felhasználói köre különböző régiókban él – ellenőrizzen azokról a régiókból. De jobb, ha az egész világból ellenőriz.
Monitorozás: mivel ellenőrizzünk?
Három módszert találtam ki. Ha tudtok többet, írjátok meg a kommentekben.
- RIPE Atlas.
- Kereskedelmi monitorozás.
- Saját virtuális hálózat.
Beszéljünk mindegyikről.
RIPE Atlas — ez egy olyan kis doboz. Akik ismerik a hazai «Revizor»-t, azoknak ez is hasonló doboz, de másik címkével.
A RIPE Atlas egy ingyenes program. Regisztrálsz, kapsz egy routert e-mailben, és csatlakoztatod a hálózatra. Azért, mert más használja a vonalad, némi kreditet kapsz. Ekkor ezeket a krediteket felhasználhatod különféle kutatásokhoz. Különböző teszteket lehet végezni: ping, traceroute, tanúsítványok ellenőrzése. A lefedettség elég nagy, sok csomópont van. De vannak nyűgök.
A kreditrendszer nem teszi lehetővé a termelési megoldások felépítését. A hosszan tartó kutatáshoz vagy kereskedelmi monitorozáshoz a kreditek nem elegendőek. A kreditek elégségesek egy rövid kutatáshoz vagy egyszeri ellenőrzéshez. Egy próba napi normája 1-2 ellenőrzéssel fogy el.
A lefedettség egyenlőtlen. Mivel a program ingyenes mindkét irányban, a lefedettség jó Európában, Oroszország európai részén és néhány régióban. De ha Indonéziára vagy Új-Zélandra van szükséged, akkor sokkal rosszabb lehet — egy országra 50 próba összegyűjtése nem biztos, hogy megoldható.
A http ellenőrzése nem lehetséges próba alapján. Ez technikai problémák miatt van. Ígérik, hogy a következő verzióban javítják, de jelenleg a http-t nem lehet ellenőrizni. Csak a tanúsítványt lehet ellenőrizni. Valamilyen http ellenőrzést csak a RIPE Atlas speciális eszköze előtt lehet végezni, amelyet Anchor-nak hívnak.
A második módszer a kereskedelmi monitorozás. Ezzel rendben van minden, hiszen pénzt fizetsz? Ígérnek neked több tucat vagy akár több száz monitorozási pontot világszerte, szépen megrajzolt műszerfalakat „a dobozból”. De megint vannak problémák.
Ez költséges, helyenként nagyon. A ping monitorozás, az ellenőrzések a világ minden tájáról és a sok http-ellenőrzés költsége évi több ezer dollár lehet. Ha a pénzügyeid engedik és tetszik ez a megoldás, kérlek.
A lefedettség nem mindig elegendő az érdeklődő régióban. Ugyanazzal a pinggel maximum egy absztrakt földrajzi területen – Ázsiában, Európában, Észak-Amerikában lehet pontosítani. Ritka monitorozó rendszerek képesek a próbát egy konkrét országra vagy régióra részletezni.
Gyenge támogatás a testreszabott tesztekhez. Ha szüksége van valami testre szabott megoldásra, és nem csupán «kurlyk» egy URL-en, akkor ezzel is problémák lesznek.
A harmadik módszer — saját monitorozás. Ez klasszikus: «Írjunk egy sajátot!»
A saját monitorozás programtermékké fejlődik, mégpedig elosztottá. Infrastruktúra szolgáltatót keres, nézi, hogyan lehet ezt telepíteni és monitorozni — a monitorozást is monitorozni kell, ugye? Ráadásul támogatásra is szükség van. Tízszer gondolja át, mielőtt belevág. Lehet, hogy egyszerűbb kifizetni valakinek, aki elvégzi ezt Ön helyett.
BGP-anomáliák és DDoS-támadások monitorozása
Itt az elérhető erőforrások még egyszerűbbek. A BGP-anomáliákat olyan speciális szolgáltatásokkal észlelik, mint a QRadar, BGPmon. Ezek teljes nézetű táblázatokat fogadnak el számos szolgáltatótól. Az alapján, amit különböző szolgáltatóktól látnak, képesek anomáliákat észlelni, amplifikátorokat keresni és egyebeket. Általában a regisztráció ingyenes — megadja az autonóm számát, feliratkozik az e-mail értesítésekre, és a szolgáltatás értesíti Önt a problémáiról.
A DDoS-támadások monitorozása is egyszerű. Általában ez NetFlow-alapú és naplók. Vannak speciális rendszerek, mint például FastNetMon, modulok a Splunk. Végső esetben ott van a DDoS-védelmi szolgáltatója. Neki is lehet küldeni NetFlow-t, és ennek alapján értesíteni fogja Önt a támadásokról.
Következtetések
Ne tápláljon illúziókat — az internet elkerülhetetlenül le fog omlani. Nem minden és nem mindenkinél, de 2017-ben 14 ezer incidens figyelmeztet arra, hogy események várhatók.
Az Ön feladata a problémák minél korábbi észlelése. Legalább nem később, mint a felhasználója. Ráadásul, amit észlelni kell, mindig legyen készenlétben egy «B terv». A terv az a stratégia, amit követni fog, amikor minden összeomlik: tartalék szolgáltatók, adatközpontok, CDN. A terv egy külön ellenőrzőlista, amely alapján ellenőrzi az összes működést. A tervnek működnie kell anélkül, hogy hálózati mérnököket vonna be, mert általában kevesen vannak, és aludni szeretnének.
Ezzel mindent elmondtam. Kívánok Önnek magas rendelkezésre állást és zöld monitorozást.
A jövő héten Novoszibirszkben napfény, nagy terhelés és fejlesztők magas koncentrációja várható . Szibériában a monitoring, elérhetőség és tesztelés, biztonság és menedzsment témájú előadások várhatóak. Csapadékra számíthatunk írott jegyzetek, kapcsolatteremtés, fényképek és közösségi média posztok formájában. Javasoljuk, hogy halassza el minden feladatát június 24-én és 25-én, és . Várjuk Önöket Szibériában!
Forrás: habr.com
