„Chłopak, który zrobił nam stronę, już ustawił ochronę przed DDoS.”
„Mamy przecież ochronę przed DDoS, dlaczego strona padła?”
„Ile, ile tysięcy chce Qrator?”
Aby normalnie odpowiadać na takie pytania klienta/przełożonego, dobrze by było wiedzieć, co kryje się za nazwą „ochrona przed DDoS”. Wybór usług ochrony przypomina bardziej wybór leku przez lekarza niż wybór stołu w IKEA.
Zajmuję się wsparciem stron od 11 lat, przeżyłem setki ataków na obsługiwane przeze mnie usługi i teraz trochę opowiem o wewnętrznej kuchni ochrony.
Regularne ataki. 350k zapytań łącznie, 52k zapytań legalnych
Pierwsze ataki pojawiły się praktycznie równocześnie z internetem. DDoS jako zjawisko stał się masowy od końca lat 2000. (spójrz) ).
Od około 2015-2016 roku prawie wszyscy dostawcy hostingu wprowadzenie ochronę przed atakami DDoS, tak jak większość zauważalnych stron w konkurencyjnych dziedzinach (zrób whois po IP stron eldorado.ru, leroymerlin.ru, tilda.ws, zobaczysz sieci operatorów ochrony).
Jeśli 10-20 lat temu większość ataków można było odbić na samym serwerze (ocenisz rekomendacje administratora systemów Lenta.ru Maksima Moszkowa z lat 90.: ), to teraz zadania ochrony stały się bardziej skomplikowane.
Rodzaje ataków DDoS z punktu widzenia wyboru operatora ochrony
Ataki na poziomie L3 / L4 (według modelu OSI)
— UDP flood z botnetu (bezpośrednio z zainfekowanych urządzeń na atakowaną usługę przesyłana jest duża liczba zapytań, serwery zalewają kanał);
— DNS/NTP/etc. amplifikacja (z zainfekowanych urządzeń przesyłana jest duża liczba zapytań do wrażliwych DNS/NTP/etc., adres nadawcy jest fałszowany, tony pakietów z odpowiedziami na zapytania zalewają kanał atakowanemu; tak wykonuje się największe ataki w nowoczesnym internecie);
— SYN/ACK flood (na atakowane serwery przesyłana jest duża liczba zapytań o nawiązanie połączenia, co prowadzi do przepełnienia kolejki połączeń);
— ataki z fragmentacją pakietów, ping of death, ping flood (proszę poszukać w Google);
— i tym podobne.
Te ataki mają na celu „zalanie” kanału serwera lub „zabicie” jego zdolności do przyjmowania nowego ruchu.
Chociaż SYN/ACK flood i amplifikacja znacznie się różnią, wiele firm radzi sobie z nimi równie dobrze. Problemy pojawiają się w przypadku ataków z następnej grupy.
Ataki na L7 (poziom aplikacji)
— http flood (jeśli atakowana jest strona internetowa lub jakiś http API);
– atak na wrażliwe części strony (nieposiadające pamięci podręcznej, bardzo obciążające stronę itp.).
Celem jest zmuszenie serwera do „ciężkiej pracy”, przetwarzania wielu „pozornie prawdziwych zapytań” i pozbawienie zasobów do prawdziwych zapytań.
Chociaż występują również inne ataki, te są najbardziej rozpowszechnione.
Poważne ataki na poziomie L7 są tworzone w unikalny sposób dla każdego atakowanego projektu.
Dlaczego dwie grupy?
Ponieważ istnieje wiele osób, które potrafią skutecznie bronić się przed atakami na poziomie L3/L4, ale albo nie podejmują się ochrony na poziomie aplikacji (L7), albo radzą sobie z nimi znacznie gorzej niż alternatywy.
Kto jest kim na rynku ochrony przed DDoS
(mój osobisty punkt widzenia)
Ochrona na poziomie L3/L4
Aby bronić się przed atakami z amplifikacją („przeciążenie” kanału serwera), wystarczą szerokie kanały (wiele z usług ochrony łączy się z większością dużych dostawców szkieletowych w Rosji i ma kanały o teoretycznej pojemności przekraczającej 1 Tbit). Nie zapominajmy, że bardzo rzadkie ataki z amplifikacją trwają dłużej niż godzinę. Jeśli jesteś Spamhaus i nikt cię nie lubi – tak, mogą starać się wyłączyć kanały na kilka dni nawet z ryzykiem dla dalszego przetrwania używanego światowego botnetu. Jeśli masz zwykły sklep internetowy, nawet jeśli to mvideo.ru – 1 Tbit przez kilka dni zobaczysz bardzo rzadko (mam nadzieję).
Aby bronić się przed atakami z fludem SYN/ACK, fragmentacją pakietów itp., niezbędne jest wyposażenie lub systemy oprogramowania do wykrywania i odcinania takich ataków.
Takie urządzenia produkuje wiele firm (Arbor, są rozwiązania od Cisco, Huawei, wdrożenia oprogramowania od Wanguard itp.), wielu operatorów szkieletowych już je zamontowało i sprzedaje usługi ochrony przed DDoS (wiem o instalacjach w Rostelecom, MegaFon, TTK, MTS, w zasadzie u wszystkich dużych dostawców, to samo robią hosterzy ze swoją ochroną a-la OVH.com, Hetzner.de, sam zetknąłem się z ochroną w ihor.ru). Niektóre firmy opracowują własne rozwiązania programowe (technologie typu DPDK pozwalają na przetwarzanie ruchu w dziesiątkach gigabitów na jednym fizycznym komputerze x86).
Wśród znanych graczy wszyscy umieją bardziej lub mniej efektywnie odpierać ataki DDoS na poziomie L3/L4. Nie powiem teraz, który z nich ma największą pojemność kanału (to informacja z kręgów branżowych), ale zazwyczaj nie ma to większego znaczenia, a różnica polega tylko na tym, jak szybko uruchamia się ochrona (natychmiastowo lub po kilku minutach przestoju projektu, jak w Hetzner).
Pytanie brzmi, jak dobrze to się robi: atak z amplifikacją można odeprzeć, blokując ruch z krajów o największej liczbie złośliwego ruchu lub można odrzucać tylko naprawdę zbędny ruch.
Jednak według mojego doświadczenia, wszyscy poważni gracze na rynku radzą sobie z tym bez problemów: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (dawny SkyParkCDN), ServicePipe, Stormwall, Voxility, itd.
Nie miałem do czynienia z ochroną od operatorów takich jak Rostelecom, MegaFon, TTK, Beeline; według relacji kolegów świadczą te usługi na dość dobrym poziomie, ale na razie czasami daje znać niedobór doświadczenia: czasami trzeba coś dostosować przez wsparcie operatora ochrony.
Niektórzy operatorzy oferują osobną usługę „ochrony przed atakami na poziomie L3/L4”, lub „ochrony kanałów”, która kosztuje znacznie mniej niż ochrona na wszystkich poziomach.
A jak operator, który nie jest głównym dostawcą, odpiera ataki rzędu setek Gbit, przecież nie ma swoich kanałów?Operator ochrony może połączyć się z każdym z dużych dostawców i odpierać ataki „na jego koszt”. Za kanał trzeba będzie zapłacić, ale wszystkie te setki Gbit nie będą utylizowane zawsze, są opcje znacznego obniżenia kosztów kanałów w tym przypadku, więc schemat pozostaje wykonalny.
Regularnie otrzymywałem takie raporty od wyższej warstwy ochrony L3/L4, wspierając systemy dostawcy hostingu.
Ochrona na poziomie L7 (poziom aplikacji)
Ataki na poziomie L7 (poziom aplikacji) skutecznie i jakościowo potrafią odpierać tylko nieliczni.
Mam dość duże doświadczenie z
— Qrator.net;
— DDoS-Guard;
— G-Core Labs;
— Kaspersky.
Pobierają opłatę za każdy megabit czystego ruchu, megabit kosztuje około kilku tysięcy rubli. Jeśli masz przynajmniej 100 megabitów czystego ruchu – ojej. Ochrona będzie bardzo droga. Mogę opowiedzieć w następnych artykułach, jak projektować aplikacje, aby bardzo dobrze zaoszczędzić na pojemności kanałów ochrony.
Prawdziwy „król góry” — Qrator.net, pozostali są daleko w tyle. Qrator jest jedyną firmą w mojej praktyce, która oferuje bliski zeru procent fałszywych alarmów, ale jednocześnie są kilka razy drożsi od innych graczy na rynku.
Inni operatorzy też oferują wysoką jakość i stabilną ochronę. Wiele serwisów, które wspieramy (w tym bardzo znane w kraju!) korzysta z ochrony DDoS-Guard, G-Core Labs i są w pełni zadowolone z uzyskanych wyników.
Ataki odparte przez Qrator
Mam również doświadczenie z mniejszymi operatorami ochrony, takimi jak cloud-shield.ru, ddosa.net, jest ich tysiące. Nie mogę ich jednoznacznie polecić, ponieważ doświadczenie nie jest zbyt wielkie, opowiem o zasadach ich działania. Koszty ochrony u nich często są o 1-2 rzędy niższe niż u dużych graczy. Zazwyczaj kupują usługę częściowej ochrony (L3/L4) od jednego z większych graczy + tworzą własną ochronę przed atakami na wyższych poziomach. Może to być całkiem skuteczne + można uzyskać dobrą usługę za mniejsze pieniądze, ale to wciąż małe firmy z niewielkimi zespołami, proszę to uwzględnić.
Na czym polega trudność w odparciu ataków na poziomie L7?
Wszystkie aplikacje są unikalne, należy zezwalać na pożyteczny ruch i blokować szkodliwy. Odrzucenie botów nie zawsze się udaje, dlatego trzeba używać wielu, naprawdę WIELE stopni oczyszczania ruchu.
Kiedyś wystarczał moduł nginx-testcookie (), a i teraz wystarcza do odparcia dużej liczby ataków. Kiedy pracowałem w branży hostingowej, na L7 budowałem ochronę właśnie na nginx-testcookie.
Niestety, ataki stały się bardziej zaawansowane. testcookie wykorzystuje kontrole botów oparte na JS, a wiele współczesnych botów potrafi je skutecznie przechodzić.
Botnety atakujące są również unikalne i trzeba uwzględniać cechy każdego dużego botnetu.
Amplifikacja, bezpośredni flood z botneta, filtracja ruchu z różnych krajów (różna filtracja dla różnych krajów), flood SYN/ACK, fragmentacja pakietów, ICMP, flood http, przy tym na poziomie aplikacji/http można wymyślać nieskończoną liczbę różnych ataków.
W sumie na poziomie ochrony kanałów, specjalistycznego sprzętu do oczyszczania ruchu, specjalnego oprogramowania, dodatkowych ustawień filtracji dla każdego klienta może być dziesiątki i setki poziomów filtracji.
Aby skutecznie zarządzać tym i właściwie dostosować ustawienia filtrowania do różnych użytkowników, potrzebne jest duże doświadczenie i wykwalifikowany personel. Nawet duży operator, który zdecyduje się świadczyć usługi ochrony, nie może po prostu "przykryć problemu pieniędzmi": doświadczenie trzeba zdobywać na nieaktywnych stronach i przez fałszywe alarmy na legalnym ruchu.
Dla operatora ochrony nie ma przycisku "odbić DDoS", jest wiele narzędzi, którymi należy umieć się posługiwać.
I jeszcze jeden przykładowy bonus.
Serwer bez ochrony został zablokowany przez hostera podczas ataku o pojemności 600 mbit.
("Zniknięcie" ruchu nie jest zauważalne, ponieważ atakowany był tylko 1 strona, na chwilę usunięto ją z serwera, a blokada została zdjęta w ciągu godziny).
Ten sam serwer jest pod ochroną. Atakujący "poddali się" po dobie odpieranych ataków. Sam atak okazał się nie najsilniejszy.
Ataki i ochrona L3/L4 są bardziej trywialne, głównie zależą od szerokości kanałów, algorytmów detekcji i filtrowania ataków.
Ataki L7 są bardziej skomplikowane i oryginalne, zależą od atakowanej aplikacji, możliwości i fantazji atakujących. Ochrona przed nimi wymaga dużej wiedzy i doświadczenia, przy czym rezultaty mogą być nie natychmiastowe i nie w 100%. Dopóki Google nie wymyślił kolejnej sieci neuronowej do ochrony.
Źródło: habr.com
