Google Cloud blokuje największy atak DDoS, łatwo bije poprzedni rekord Cloudflare

W czerwcu Cloudflare poinformował, że powstrzymał największy rozproszony atak typu „odmowa usługi” (DDoS) na HTTPS, który został ustalony na poziomie 26 milionów żądań na sekundę (rps). To więcej niż jego poprzedni rekord 15,3 mln obr./min w kwietniu. Szybko do sierpnia, a Google ogłosił, że teraz nosi koronę blokowania największego ataku DDoS w historii.

W poście na blogu Google Cloud firma twierdzi, że była w stanie zablokować atak DDoS, który osiągnął 46 milionów żądań na sekundę, o 76% więcej niż Cloudflare. Aby dać ci pewien kontekst skali tego ataku, wyobraź sobie, że wszystkie zapytania są codziennie wysyłane do Wikipedii na całym świecie, teraz wyobraź sobie, że są wysyłane w ciągu 10 sekund, a nie rozsyłane w ciągu dnia.

Atak DDoS został przeprowadzony na kliencie Google Cloud przy użyciu Cloud Armor. Google twierdzi, że gdy tylko usługa wykryje oznaki zagrożenia, zaalarmowała klienta i zaleciła regułę ochronną, aby zapobiec niebezpieczeństwu. Ta reguła została następnie wdrożona przed szczytem żądań, co oznaczało, że klient nadal pozostawał online, podczas gdy Cloud Armor chronił swoją infrastrukturę i obciążenia.

Google informuje, że atak rozpoczął się wczesnym rankiem 1 czerwca z szybkością 10 000 żądań na sekundę, ale w ciągu ośmiu minut wzrósł do 100 000 żądań na sekundę, po czym zadziałała ochrona adaptacyjna Cloud Armor. Dwie minuty później liczba żądań na sekundę wzrosła do 46 milionów, ale klient był już bezpieczny i działał. Atak zatrzymał się w ciągu 69 minut, prawdopodobnie dlatego, że nie przyniósł pożądanego efektu z powodu ingerencji Google Cloud Armor.

W swojej analizie ogólnego ataku Google zauważył, że:

Oprócz niespodziewanie dużego ruchu, atak miał inne godne uwagi cechy. Atak obejmował 5256 źródłowych adresów IP ze 132 krajów. Jak widać na rysunku 2 powyżej, 4 kraje z największą liczbą ataków odpowiadają za około 31% całego ruchu związanego z atakami. W ataku wykorzystano zaszyfrowane żądania (HTTPS), których wygenerowanie wymagałoby dodatkowych zasobów obliczeniowych. O ile zatrzymanie szyfrowania było konieczne do zbadania ruchu i skutecznego złagodzenia ataku, to użycie potokowania HTTP wymagało od Google wykonania stosunkowo niewielkiej liczby uścisków dłoni TLS.

Około 22% (1169) źródłowych adresów IP odpowiadało węzłom wyjściowym Tora, chociaż ilość żądań pochodzących z tych węzłów stanowiła tylko 3% ruchu ataków. Chociaż uważamy, że zaangażowanie Tora w atak było przypadkowe ze względu na charakter podatnych usług, nawet przy szczytowym poziomie 3% (ponad 1,3 miliona żądań na sekundę), nasza analiza pokazuje, że węzły wyjściowe Tora mogą wysyłać znaczną ilość niepożądanego ruchu do sieć – aplikacje i usługi.

Rozkład geograficzny i rodzaje niezabezpieczonych usług wykorzystywanych do przeprowadzenia ataku są zgodne z rodziną ataków Mēris. Znana ze swoich masowych ataków, które złamały rekordy DDoS, metoda Meris wykorzystuje niezabezpieczone serwery proxy, aby ukryć prawdziwe źródło ataków.

Firma Google ostrzegła, że ​​osoby atakujące często wykorzystują DDoS do złamania zabezpieczeń krytycznych obciążeń. Firma zaleciła więc szczegółową strategię ochrony i oczywiście wykorzystanie Google Cloud Armor.