Internet wydaje się silną, niezależną i niepodważalną strukturą. W teorii, wytrzymałość sieci wystarczyłaby, aby przetrwać wybuch jądrowy. W rzeczywistości, Internet może spaść przez jeden mały router. Wszystko przez to, że Internet to nagromadzenie sprzeczności, podatności, błędów i filmików o kotach. Podstawą Internetu jest protokół BGP, który zawiera mnóstwo problemów. Zadziwiające, że nadal funkcjonuje. Oprócz błędów samego Internetu, jest on łamany przez wszystkich, którzy tylko mają na to ochotę: dużych dostawców Internetu, korporacje, rządy i ataki DDoS. Co z tym zrobić i jak z tym żyć?
Odpowiedź zna Aleksiej Uczakin () – lider zespołu inżynierów sieciowych w firmie IQ Option. Jego głównym zadaniem jest zapewnienie dostępności platformy dla użytkowników. W transkrypcji wykładu Aleksieja na porozmawiamy o BGP, atakach DDoS, wyłączniku dla Internetu, błędach dostawców, decentralizacji oraz przypadkach, gdy mały router wysłał Internet na drzemkę. Na końcu – kilka wskazówek, jak to wszystko przetrwać.
Dzień, w którym Internet się zepsuł
Przedstawię tylko kilka incydentów, kiedy Internet tracił łączność. To wystarczy, aby zobaczyć pełny obraz.
Incydent z AS7007. Po raz pierwszy Internet się zepsuł w kwietniu 1997 roku. W oprogramowaniu jednego routera z autonomicznego systemu 7007 wystąpił błąd. W pewnym momencie router ogłosił swoim sąsiadom swoją wewnętrzną tabelę routingu i wysłał połowę sieci w czarną dziurę.
Pakistan przeciwko YouTube. W 2008 roku dzielni panowie z Pakistanu postanowili zablokować YouTube u siebie. Zrobili to na tyle skutecznie, że połowa świata została bez filmików o kotach.
Przechwycenie prefiksów VISA, MasterCard i Symantec przez Rostelekom. W 2017 roku Rostelekom przez pomyłkę zaczął ogłaszać prefiksy VISA, MasterCard i Symantec. W rezultacie finansowy ruch został skierowany przez kanały kontrolowane przez dostawcę. Incydent trwał krótko, ale dla firm finansowych było to nieprzyjemne.
Google przeciwko Japonii. W sierpniu 2017 roku Google zaczął ogłaszać w części swoich łączy uplink prefiksy dużych japońskich dostawców NTT i KDDI. Ruch został skierowany do Google jako tranzytowy, prawdopodobnie przez błąd. Ponieważ Google nie jest dostawcą i nie przepuszcza ruchu tranzytowego, znaczna część Japonii została bez Internetu.
DV LINK przechwycił prefiksy Google, Apple, Facebook, Microsoft. W 2017 roku rosyjski dostawca DV LINK zaczął bezsensownie ogłaszać sieci Google, Apple, Facebook, Microsoft i niektórych innych dużych graczy.
„eNet z USA przejął prefiksy AWS Route53 i MyEtherwallet”. W 2018 roku dostawca z Ohio lub ktoś z jego klientów ogłosił sieci Amazon Route53 i portfela kryptowalutowego MyEtherwallet. Atak był udany: mimo samopodpisanego certyfikatu, ostrzeżenie, które pojawiało się u użytkownika przy odwiedzaniu strony MyEtherwallet, wiele portfeli zostało skradzionych i część kryptowaluty skradziona.
W 2017 roku takich incydentów było ponad 14 000! Sieć nadal jest zdecentralizowana, dlatego nie wszystko psuje się u wszystkich. Ale incydenty zdarzają się tysiącami i wszystkie są związane z protokołem BGP, na którym działa internet.
BGP i jego problemy
Protokół BGP - Border Gateway Protocol, po raz pierwszy opisany w 1989 roku przez dwóch inżynierów z IBM i Cisco Systems na trzech „serwetkach” - kartkach formatu A4. Te do dziś leżą w głównym biurze Cisco Systems w San Francisco jako relikwia świata sieciowego.
W podstawie protokołu znajduje się interakcja autonomicznych systemów — Autonomous Systems, w skrócie - AS. Autonomiczny system to po prostu pewien ID, pod którym w publicznym rejestrze przypisane są sieci IP. Router z takim ID może ogłaszać te sieci światu. W związku z tym, każdą trasę w internecie można przedstawić jako wektor, który nazywa się AS Path. Wektor składa się z numerów autonomicznych systemów, które trzeba przejść, aby dotrzeć do sieci docelowej.
Na przykład, istnieje sieć składająca się z pewnej liczby autonomicznych systemów. Trzeba przejść z systemu AS65001 do systemu AS65003. Droga od jednego systemu jest przedstawiona jako AS Path na schemacie. Składa się z dwóch autonomicznych systemów: 65002 i 65003. Dla każdego adresu docelowego istnieje wektor AS Path, który składa się z numerów autonomicznych systemów, które musimy przejść.
Jakie są zatem problemy z BGP?
BGP to protokół zaufania
Protokół BGP - oparty na zaufaniu. To oznacza, że z zasady ufamy naszemu sąsiadowi. Jest to cecha wielu protokołów, które zostały opracowane na samym początku internetu. Zrozummy, co oznacza „ufamy”.
Brak autoryzacji sąsiada. Formalnie istnieje MD5, ale MD5 w 2019 roku - no, takie sobie...
Brak filtracji. BGP ma filtry i są one opisane, ale nie są używane lub są używane niewłaściwie. Później wyjaśnię, dlaczego.
Bardzo łatwe do skonfigurowania sąsiedztwo. Konfiguracja sąsiedztwa w protokole BGP na niemal każdym routerze to tylko kilka linijek konfiguracyjnych.
Nie są wymagane uprawnienia do zarządzania BGP. Nie trzeba zdawać egzaminów potwierdzających kwalifikacje. Nikt nie odbierze uprawnień za konfigurację BGP w stanie nietrzeźwym.
Dwa główne problemy
Krady prefiksów — prefix hijacks. Kradzież prefiksu to ogłaszanie sieci, która do Ciebie nie należy, tak jak w przypadku z MyEtherwallet. Wzięliśmy kilka prefiksów, dogadaliśmy się z dostawcą lub go zhakowaliśmy i ogłaszamy te sieci przez niego.
Przecieki tras — route leaks. W przypadku przecieków sprawa jest nieco bardziej skomplikowana. Przeciek to zmiana AS Path. W najlepszym przypadku zmiana prowadzi do większych opóźnień, ponieważ musisz przejść trasą dłuższą lub przez mniej wydajny link. W najgorszym przypadku powtórzy się sytuacja z Google i Japonii.
Sam Google nie jest operatorem ani tranzystorowym systemem autonomicznym. Jednak kiedy ogłosił swojemu dostawcy sieci japońskich operatorów, ruch przez Google w AS Path był widziany jako bardziej priorytetowy. Ruch poszedł tam i został dropowany tylko dlatego, że ustawienia trasowania wewnątrz Google są bardziej skomplikowane niż tylko filtry na granicy.
Dlaczego filtry nie działają?
Nikt się tym nie interesuje. To główny powód — wszystkim jest to obojętne. Administrator małego dostawcy lub firmy, która podłączyła się do dostawcy przez BGP, wziął MikroTik, skonfigurował BGP i nawet nie wie, że można ustawiać tam filtry.
Błędy konfiguracji. Coś debugowano, błąd w masce, ustawiono nie tą sieć — i oto, znów błąd.
Brak możliwości technicznych. Na przykład, dostawcy internetu mają wielu klientów. Rozsądnie byłoby automatycznie aktualizować filtry dla każdego klienta — monitorować, że pojawiła się nowa sieć, że wynajął swoją sieć komuś innemu. Trudno jest to śledzić, a ręcznie jeszcze trudniej. Dlatego po prostu stosują luźno ustawione filtry lub wcale ich nie ustawiają.
Wyjątki. Są wyjątki dla ulubionych i większych klientów. Szczególnie w przypadku styków międzyoperatorowych. Na przykład, u TransTelekom i Rostelecom jest wiele sieci i między nimi styk. Jeśli styk upadnie — nikomu nie będzie dobrze, dlatego filtry są luźniej ustawiane lub całkowicie usuwane.
Zdezaktualizowane lub nieaktualne informacje w IRR. Filtry są budowane na podstawie informacji zapisanych w IRR — Internet Routing Registry. To są rejestry regionalnych rejestratorów internetowych. Często w rejestrach znajdują się przestarzałe lub nieaktualne informacje, albo jedno i drugie.
Kim są ci rejestratorzy?
Wszystkie adresy w internecie należą do organizacji IANA — Internet Assigned Numbers Authority. Kiedy kupujesz od kogoś sieć IP, kupujesz nie adresy, a prawo do ich używania. Adresy to zasób niematerialny, a według ogólnych ustaleń wszystkie należą do agencji IANA.
System działa w ten sposób. IANA deleguje zarządzanie adresami IP i numerami systemów autonomicznych pięciu regionalnym rejestratorom. Ci wydają systemy autonomiczne LIR — lokalnym rejestratorom internetowym. Następnie LIR przydzielają adresy IP ostatecznym użytkownikom.
Wadą systemu jest to, że każdy z regionalnych rejestratorów prowadzi swoje rejestry na swój sposób. Każdy ma swoje poglądy na to, jakie informacje powinny być zawarte w rejestrach, kto je powinien lub nie powinien weryfikować. W rezultacie powstaje bałagan, który mamy teraz.
Jak jeszcze można walczyć z tymi problemami?
IRR — przeciętna jakość. Z IRR wiadomo — tam wszystko jest źle.
BGP-communities. To pewien atrybut, który jest opisany w protokole. Możemy nałożyć, na przykład, specjalne community na nasze ogłoszenie, aby sąsiad nie przesyłał naszych sieci swoim sąsiadom. Kiedy mamy link P2P, wymieniamy się tylko swoimi sieciami. Aby przypadkowo trasa nie trafiła do innych sieci, nakładamy community.
Community nie są tranzytowe. To zawsze umowa na dwóch, i to jest ich wada. Nie możemy nałożyć jakiegoś community, z wyjątkiem jednego, które jest akceptowane domyślnie przez wszystkich. Nie możemy być pewni, że to community wszyscy przyjmą i właściwie zinterpretują. Dlatego, w najlepszym przypadku, jeśli dogadasz się ze swoim uplinkiem, on zrozumie, czego od niego chcesz przez community. Ale sąsiad może tego nie zrozumieć, albo operator po prostu odrzuci twoją etykietę i nie osiągniesz tego, czego chciałeś.
RPKI + ROA rozwiązują tylko małą część problemów. RPKI — to Resource Public Key Infrastructure — specjalny framework do podpisywania informacji o trasach. Dobry pomysł, aby zmusić LIR-ów i ich klientów do prowadzenia aktualnej bazy przestrzeni adresowej. Ale z nim jest jeden problem.
RPKI to także hierarchiczny system kluczy publicznych. IANA ma klucz, od którego tworzony jest klucz RIR, a od niego klucze LIR, którymi podpisują swoją przestrzeń adresową za pomocą ROAs - Route Origin Authorisations.
— Zapewniam, że ten prefiks będzie ogłaszany w imieniu tej autonomii.
Oprócz ROA istnieją inne obiekty, ale o nich później. Wydaje się, że to dobry i przydatny mechanizm. Jednak nie zabezpiecza nas wcale przed wyciekami i nie rozwiązuje wszystkich problemów z kradzieżą prefiksów. Dlatego gracze nie mają zbyt wiele chęci do wdrażania tego. Chociaż już dużym graczom, jak AT&T i dużym IX-om, zapewniono, że prefiksy z nieprawidłowym zapisem ROA będą odrzucane.
Możliwe, że będą to robić, ale obecnie mamy ogromną liczbę prefiksów, które w żaden sposób nie są podpisane. Z jednej strony nie wiadomo, czy są one ogłaszane jako ważne. Z drugiej strony nie możemy ich domyślnie odrzucać, ponieważ nie jesteśmy pewni, czy to słuszne czy nie.
Co jest jeszcze?
BGPSec. To świetny mechanizm wymyślony przez akademików dla sieci różowych kucyków. Powiedzieli:
— Mamy RPKI + ROA - mechanizm potwierdzający podpis przestrzeni adresowej. Stwórzmy osobny atrybut BGP i nazwijmy go BGPSec Path. Każdy router będzie podpisywał swoje ogłoszenia, które ogłasza sąsiadom. W ten sposób uzyskamy zaufaną ścieżkę z łańcucha podpisanych ogłoszeń i będziemy mogli ją zweryfikować.
Teoretycznie to brzmi dobrze, ale w praktyce napotyka wiele problemów. BGPSec zaburza wiele istniejących mechanik BGP związanych z wyborem next-hop i zarządzaniem ruchem przychodzącym/wychodzącym bezpośrednio na routerze. BGPSec nie działa, dopóki nie wdroży go 95% uczestników całego rynku, co samo w sobie jest utopią.
BGPSec ma ogromne problemy z wydajnością. Na obecnym sprzęcie szybkość weryfikacji ogłoszeń wynosi około 50 prefiksów na sekundę. Dla porównania: obecna tabela internetu z 700 000 prefiksów będzie ładowana przez 5 godzin, w ciągu których zmieni się jeszcze 10 razy.
BGP Open Policy (BGP oparty na roli). Nowa propozycja oparta na modelu Gao-Reksforda. To dwóch naukowców zajmujących się badaniami nad BGP.
Model Gao-Reksforda opiera się na następujących założeniach. Upraszczając, w przypadku BGP istnieje niewielka liczba typów interakcji:
- Provider Customer;
- P2P;
- wewnętrzna interakcja, powiedzmy, iBGP.
Na podstawie roli routera można domyślnie wdrażać pewne polityki importu/eksportu. Administrator nie musi konfigurować list prefiksów. Na podstawie roli, nad którą uzgodnią się routery i którą można wystawić, otrzymujemy pewne domyślne filtry. Obecnie to szkic, który jest omawiany w IETF. Mam nadzieję, że wkrótce zobaczymy to w formie RFC i wdrożenia na sprzęcie.
Duzi dostawcy Internetu
Rozważmy na przykładzie dostawcy CenturyLink. To trzeci co do wielkości dostawca w USA, który obsługuje 37 stanów i ma 15 centrów danych.
W grudniu 2018 roku CenturyLink miał awarię na rynku USA trwającą 50 godzin. W trakcie incydentu wystąpiły problemy z działaniem bankomatów w dwóch stanach, a przez kilka godzin nie działał numer 911 w pięciu stanach. Oprócz tego odwołano loterię w Idaho. W sprawie tego incydentu Komisja ds. Łączności w USA prowadzi obecnie dochodzenie.
Przyczyną tragedii była jedna karta sieciowa w jednym centrum danych. Karta uległa awarii, wysyłała nieprawidłowe pakiety, a wszystkie 15 centrów danych dostawcy uległo awarii.
Dla tego dostawcy nie zadziałała idea „zbyt dużego, aby upaść”. Ta idea w ogóle nie działa. Można wziąć każdego dużego gracza i powalić go drobnostką. W USA nadal wszystko jest w porządku z łącznością. Klienci CenturyLink, którzy mieli zapas, masowo przeszli do niego. Potem alternatywni operatorzy skarżyli się na przeciążenie swoich łącz.
Jeśli zawiedzie hipotetyczny „Kazakhtelecom” – cały kraj zostanie bez Internetu.
Korporacje
Czy Internet opiera się głównie na Google, Amazonie, Facebooku i innych korporacjach? Nie, one również w nim zawodzą.
W 2017 roku w Petersburgu na konferencji ENOG13 Jeff Houston z APNIC przedstawił . Mówi w nim, że przyzwyczailiśmy się, iż interakcje, przepływy pieniądzy i ruch w Internecie są pionowe. Mamy małych dostawców, którzy płacą większym, a ci już płacą za łączność globalnemu tranzytowi.
Obecnie mamy taką pionowo zorientowaną strukturę. Wszystko byłoby dobrze, ale świat się zmienia – duzi gracze budują swoje transoceaniczne kable, aby stworzyć własne backbones.
Aktualności o kablu CDN.
W 2018 roku TeleGeography opublikowało badanie, które wykazało, że ponad połowa ruchu w internecie to już nie internet, a backbones CDN dużych graczy. To ruch, który ma związek z internetem, ale to już nie ta sieć, o której mówiliśmy.
Internet rozpada się na dużą liczbę słabo ze sobą powiązanych sieci.
Microsoft ma swoją sieć, Google ma swoją, a one wzajemnie słabo się krzyżują. Ruch, który powstał gdzieś w USA, przemieszcza się kanałami Microsoftu przez ocean do Europy, gdzieś na CDN, następnie przez CDN lub IX łączy się z twoim dostawcą i trafia do twojego routera.
Decentralizacja znika.
Ta mocna strona internetu, która pomoże mu przetrwać po wybuchu jądrowym, zanika. Pojawiają się miejsca koncentracji użytkowników i ruchu. Jeśli padnie hipotetycznie Google Cloud - będzie wielu poszkodowanych na raz. Częściowo poczuliśmy to, kiedy Roskomnadzor zablokował AWS. A na przykładzie CenturyLink widać, że do tego wystarczy i drobiazg.
Kiedyś nie wszystko się psuło i nie u wszystkich. W przyszłości możemy dojść do tego, że wpływając na jednego dużego gracza, można zniszczyć wiele rzeczy, w wielu miejscach i u wielu ludzi.
Państwa
Następne w kolejce są państwa, a z nimi dzieje się zazwyczaj tak.
Tutaj nasz Roskomnadzor w ogóle nawet nie jest pionierem. Podobna praktyka Internet shutdown występuje w Iranie, Indiach, Pakistanie. W Anglii jest projekt ustawy dotyczącej możliwości wyłączenia internetu.
Każde duże państwo pragnie uzyskać wyłącznik do odłączenia internetu, czy to całkowicie, czy częściami: Twitter, Telegram, Facebook. Nie to, żeby nie rozumieli, że nigdy nie uda im się to, ale bardzo tego pragną. Stosują wyłączniki na ogół w celach politycznych - aby wyeliminować konkurentów politycznych, lub gdy wybory są na horyzoncie, lub rosyjscy hakerzy znów coś zepsuli.
Ataki DDoS
Nie będę zabierać chleba towarzyszom z Qrator Labs, oni robią to znacznie lepiej ode mnie. Mają o stabilności internetu. I oto, co napisali w raporcie za 2018 rok.
Średni czas trwania ataków DDoS spada do 2,5 godzin. Napastnicy również zaczynają liczyć pieniądze, a jeśli zasób nie padnie od razu, to szybko zostawiają go w spokoju.
Rosnie intensywność ataków. W 2018 roku widzieliśmy 1,7 Tb/s w sieci Akamai i to nie jest limit.
Pojawiają się nowe wektory ataków i wzmacniają się stare.Pojawiają się nowe protokoły podatne na amplifikację, a także nowe ataki na istniejące protokoły, szczególnie na TLS i podobne.
Większość ruchu to urządzenia mobilne.W międzyczasie ruch internetowy przechodzi na mobilnych klientów. Z tym muszą poradzić sobie zarówno atakujący, jak i obrońcy.
Nie ma systemów nie do zniszczenia.To główna myśl – nie ma i nie będzie uniwersalnej ochrony, która dokładnie zabezpieczy przed każdym DDoS-em.
Systemu nie można wyłączyć, jeśli nie jest podłączony do internetu.
Mam nadzieję, że wystarczająco was przestraszyłem. Zastanówmy się teraz, co z tym zrobić.
Co robić?!
Jeśli macie wolny czas, chęci i znajomość angielskiego – weźcie udział w grupach roboczych: IETF, RIPE WG. To otwarte listy mailowe, subskrybujcie newslettery, uczestniczcie w dyskusjach, przyjeżdżajcie na konferencje. Jeśli macie status LIR, możecie głosować, na przykład, w RIPE nad różnymi inicjatywami.
Dla zwykłych śmiertelników – to monitoring. Aby wiedzieć, co się zepsuło.
Monitorowanie: co sprawdzać?
Zwykły Ping, przy czym nie tylko binarna kontrola – działa czy nie. Zapisujcie RTT w historii, aby później móc sprawdzać anomalie.
Traceroute. To program do określania tras przesyłania danych w sieciach TCP/IP. Pomaga w wykrywaniu anomalii i blokad.
Sprawdzanie HTTP – niestandardowe adresy URL i certyfikaty TLS pomogą wykryć blokady lub podmianę DNS dla ataku, co jest praktycznie tym samym. Blokady często realizowane są przez podmianę DNS i przekierowanie ruchu na stronę zatrzymania.
Jeśli to możliwe, sprawdzajcie rozwiązywanie waszego origin z różnych miejsc, jeśli macie aplikację. Dzięki temu wykryjecie anomalie przechwytywania DNS, które czasami zdarzają się u dostawców.
Monitorowanie: skąd sprawdzać?
Nie ma uniwersalnej odpowiedzi. Sprawdzajcie tam, skąd przychodzi użytkownik. Jeśli użytkownicy są w Rosji – sprawdzajcie z Rosji, ale nie ograniczajcie się tylko do niej. Jeśli wasi użytkownicy żyją w różnych regionach – sprawdzajcie z tych regionów. Ale najlepiej z całego świata.
Monitorowanie: czym sprawdzać?
Zmyśliłem trzy metody. Jeśli znacie więcej – napiszcie w komentarzach.
- RIPE Atlas.
- Komercyjne monitorowanie.
- Własna sieć wirtualnych maszyn.
Porozmawiajmy o każdej z nich.
RIPE Atlas — to taka mała skrzyneczka. Dla tych, którzy znają rodzimy "Rewizor" — to taka sama skrzyneczka, ale z inną naklejką.
RIPE Atlas — darmowy program. Rejestrujesz się, otrzymujesz router pocztą i podłączasz go do sieci. Za to, że ktoś inny korzysta z twojego pomiaru, zdobywasz pewne kredyty. Na te kredyty możesz prowadzić różne badania. Można testować na różne sposoby: ping, traceroute, sprawdzać certyfikaty. Zasięg jest dość duży, wiele nodów. Ale są pewne niuanse.
System kredytów nie pozwala na budowanie rozwiązań produkcyjnych. Kredytów na stałe badania lub komercyjny monitoring nie wystarczy. Kredytów wystarcza na krótkie badanie lub jednorazową kontrolę. Dzienna norma z jednego pomiaru jest konsumowana przez 1-2 kontrole.
Zasięg jest nierównomierny. Ponieważ program jest darmowy w obie strony, zasięg jest dobry w Europie, w europejskiej części Rosji i w niektórych regionach. Ale jeśli potrzebujesz Indonezji lub Nowej Zelandii, to wszystko jest znacznie gorsze — 50 pomiarów na kraj może nie wystarczyć.
Nie można sprawdzać http z próby. To wynika z technicznych niuansów. Obiecują naprawić w nowej wersji, ale na razie nie można sprawdzać http. Można jedynie sprawdzić certyfikat. Jakieś https check można zrobić tylko do specjalnego urządzenia RIPE Atlas, które nazywa się Anchor.
Drugi sposób — monitoring komercyjny. Z nim wszystko w porządku, płacisz pieniądze? Obiecują ci kilka dziesiątek lub setek punktów monitorowania na całym świecie, rysują piękne dashboardy „z pudełka”. Ale znowu, są pewne problemy.
To kosztuje, miejscami bardzo. Monitoring pingiem, kontrole z całego świata i wiele kontroli http mogą kosztować kilka tysięcy dolarów rocznie. Jeśli finanse na to pozwalają i to rozwiązanie ci odpowiada — proszę.
Zasięg może być niewystarczający w interesującym regionie. Tym pingiem wyznaczają maksymalnie abstrakcyjną część świata — Azję, Europę, Amerykę Północną. Rzadkie systemy monitorowania mogą szczegółowo określić próbę do konkretnego kraju lub regionu.
Słaba obsługa testów customowych. Jeśli potrzebujesz czegoś nietypowego, a nie tylko „kurlyku” na url, to również są z tym problemy.
Trzeci sposób — swój monitoring. To klasyka: „A może napiszemy swoje!”
Twój monitoring przekształca się w rozwój oprogramowania, w tym rozproszonego. Szukasz dostawcy infrastruktury, patrzysz, jak to wdrożyć i monitorować - monitoring trzeba monitorować, prawda? Potrzebujesz też wsparcia. Dziesięć razy przemyśl, zanim się za to weźmiesz. Może lepiej zapłacić komuś, kto zrobi to za Ciebie.
Monitorowanie anomalii BGP i ataków DDoS
W przypadku dostępnych zasobów jest to jeszcze prostsze. Anomalie BGP są wykrywane za pomocą specjalistycznych serwisów, takich jak QRadar, BGPmon. Przyjmują one tabelę full view od wielu operatorów. Na podstawie tego, co widzą od różnych operatorów, mogą wykrywać anomalie, szukać amplifikatorów i innych. Zazwyczaj rejestracja jest darmowa - wpisujesz numer swojej autonomicznej sieci, zapisujesz się na powiadomienia e-mailowe, a serwis informuje o Twoich problemach.
W monitorowaniu ataków DDoS również wszystko jest proste. Zazwyczaj jest to oparte na NetFlow i logi. Istnieją specjalistyczne systemy typu FastNetMon, moduły dla Splunk. W ostateczności można skontaktować się z dostawcą ochrony DDoS. Można również przesyłać mu dane NetFlow, a na tej podstawie będzie on informować o atakach w Twoim kierunku.
Wnioski
Nie miej złudzeń - internet na pewno się złamie. Nie wszystko i nie u wszystkich, ale 14 tysięcy incydentów w 2017 roku sugeruje, że incydenty będą.
Twoim zadaniem jest zauważyć problemy jak najszybciej. Przynajmniej nie później niż Twój użytkownik. Oprócz zauważania, zawsze miej w zapasie 'plan B'. Plan to strategia, co zamierzasz zrobić, gdy wszystko się złamie: rezerwowi operatorzy, centra danych, CDN. Plan to osobna lista kontrolna, według której sprawdzasz działanie wszystkiego. Plan powinien działać bez angażowania inżynierów sieciowych, ponieważ ich zazwyczaj jest mało i chcą spać.
Na tym kończymy. Życzę Ci wysokiej dostępności i zielonego monitorowania.
W przyszłym tygodniu w Nowosybirsku spodziewane jest słońce, wysoka obciążalność i duża koncentracja programistów na . W Syberii prognozowane są sesje wykładowe dotyczące monitorowania, dostępności, testowania, bezpieczeństwa i zarządzania. Oczekiwane są opady w postaci zapisanych notatek, networking, zdjęć i postów w mediach społecznościowych. Zalecamy odłożyć wszystkie sprawy 24 i 25 czerwca i . Czekamy na Ciebie w Syberii!
Źródło: habr.com
