Atak DDoS – historia prawdziwa

Prezentujemy historię rzeczywistego ataku DDoS na usługi oferowane przez amerykańską firmę CrownPeak i wnioski, które można wyciągnąć z analizy tego zdarzenia.

Każda aplikacja internetowa jest podatna na atak cybernetyczny. Kluczowe staje się przygotowanie i planowanie metod obrony przed zagrożeniem. Prezentujemy historię rzeczywistego ataku DDoS na usługi oferowane przez CrownPeak.

CrownPeak jest dostawcą usług zarządzania treścią Web CMS (Content Management System) w modelu SaaS dla średnich i dużych organizacji. Klienci CrownPeak tworzą aplikacje dla zaawansowanych technologicznie dziedzin, takich jak farmaceutyka czy finanse. Klient w ramach opisywanej historii pozostaje anonimowy, ale stanowi dużą organizację działającą na styku finansów i opieki zdrowotnej działającą w USA. Udostępniane przez klienta aplikacje służą do rozliczania tysięcy szpitali oraz dostawców usług zdrowotnych. Skala omawianego szczególnego ataku DDoS (Disturbed Denial of Service) była ogromna – w szczytowym momencie osiągnęła liczbę 86 milionów jednoczesnych zapytań do strony klienta, generowanych przez ponad 100000 rozproszonych hostów z różnych lokalizacji. O sprawie poinformowane zostało FBI. Atak trwał 39 godzin.

Zobacz również:

  • #Cyber data science. Najważniejsze statystyki, trendy i fakty dotyczące cyberbezpieczeństwa
  • Amazon EKS Anywhere#

Pierwsze uderzenie

W czasie trwania spotkania konferencyjnego klienta, w którym uczestniczyło 15000 słuchaczy, CrownPeak otrzymał ważny komunikat. Serwery Web klienta odbierały niewiarygodną ilość ruchu w wyniku ataku DDoS. CrownPeak jest dostawcą usług SaaS oraz usług analitycznych dla klientów, więc każda degradacja wydajności infrastruktury, miała dramatyczny wpływ na dostępność usług i reputację firmy. Nie było czasu na czekanie, aż atak ustąpi.

W początkowym etapie prac ustalono zakres ataku:

  • wszystkie zapytania stanowiły prawidłowe URL, więc nie istniała opcja szybkiego i skutecznego odfiltrowania podejrzanego ruchu,
  • atak pochodził z różnych stron świata – włączając w to Północna Koreę, Estonię, Litwę, Chiny, Rosją, Północną Amerykę,
  • prawie 60% ruchu pochodziło z terenu USA,
  • atak kierowany był bezpośrednio na adresy IP serwerów udostępniających aplikacje klienta.

Początkowo atak został z sukcesem odparty poprzez zmianę adresów IP serwerów udostępniających aplikację i odcięciu ruchu kierowanego na atakowane IP. Domena klienta utrzymywana była w ramach usługi Amazon Route 53. Po zablokowaniu ruchu i zmianie adresacji IP serwerów, usługi funkcjonowały poprawnie. Z biegiem czasu okazało się, że była to tylko pierwsza fala ataku. Wkrótce nadeszło prawdziwe tsunami DDoS.

Atak powrócił wieczorem, biorąc za cel nazwy domenowe aplikacji klienta, w przeciwieństwie do bezpośrednich adresów IP serwerów. Oznaczało to, że nie było możliwości zastosowania metody blokowania dostępu do określonych adresów IP serwerów, która wykorzystana została wcześniej. To uderzenie było krytyczne, ponieważ zasoby nie były wystarczające do obsługi takiego poziomu ruchu. W CrownPeak rozpoczęto debatę na temat możliwości finansowania skutecznej obrony, co mogło kosztować nawet dziesiątki tysięcy dolarów. Na szali stała jednak reputacja firmy.

Przyglądając się szczegółowo drugiej fazie ataku okazało się, że istnieje kilka prostych sposobów zniwelowania zagrożenia. Atakowana strona zawierająca aplikację klienta obsługiwała wyłącznie klientów z rejonu USA, natomiast duża część ruchu DDoS przychodziła z adresów IP spoza USA. Szybko zaimplementowana została reguła zapory ogniowej, która dopuszczała do aplikacji klienta jedynie ruch z terenu USA. Dzięki nieskomplikowanej, ale skutecznej metodzie zatrzymane zostało około 40% połączeń od atakujących. Kolejną czynnością było wdrożenie zapory ogniową na poziomie aplikacji Web, umieszczonej przed skalowalnymi serwerami HA Proxy, co pozwoliło zebrać wiele informacji pomocnych w analizie zagrożenia. Trzecim krokiem była modyfikacja konfiguracji automatycznego skalowania infrastruktury. Skalowanie infrastruktury od tej pory było możliwe wyłącznie w górę do wyższych parametrów, nigdy w drugą stronę. Chwilowe zmniejszenia skali ataków nie powodowało zmniejszenia mocy infrastruktury (skalowania w dół). W ten sposób infrastruktura była zawsze przygotowana na różne poziomy ataku, który nasilał się.

DDoS dzień drugi

Gdy zwiększała się moc ataku, infrastruktura CrownPeak działająca w ramach Amazon Web Services skalowała się w górę. W odpowiedzi siła ataku zwiększała się jeszcze bardziej, co skutkowało jeszcze większym skalowaniem zasobów po stronie CrownPeak. Takie zachowane stanowiło normę podczas drugiego dnia ataku. W szczytowym okresie DDoS wykorzystywanych było 18 bardzo wydajnych serwerów HA Proxy oraz 40 serwerów Web. Farma serwerów była tak duża, ponieważ pomimo wyeliminowania ruchu nie pochodzącego z USA, pozostało 60% „prawidłowego” ruchu z rejonu USA. Większość zapytań realizowała dostęp do usług dynamicznych, które nie mogły być w łatwy sposób udostępniane z pamięci podręcznej serwerów pośredniczących.

Około godziny 19:00 drugiego dnia ataku, pojawiły się pierwsze efekty podjętych działań. Infrastruktura dysponowała możliwością dalszego skalowania w górę, natomiast atak utrzymywany był na niezmienionym poziomie. W tym punkcie infrastruktura przyjmowała 86 milionów jednoczesnych zapytań, od ponad 100000 hostów. Zmierzony ruch do infrastruktury osiągnął poziom 20 Gb/s. Atak był 40 raz większy niż średnia obserwowana przy atakach DDoS w 2014 roku, zgodnie z danymi Arbor Networks. Aplikacja klienta nadal pracowała poprawnie, ale czasy odpowiedzi na zapytanie wynosiły około 1-3 sekundy. Po kilku godzinach atak stracił impet, aż do całkowitego zaniku.

Jakie wnioski?

Podsumowując zdarzenie specjaliści CrownPeak stwierdzili, że gdyby aplikacja utrzymywania byłaby we własnym centrum danych, prawdopodobnie nie byłoby możliwości zatrzymania ataku. Warto pamiętać o założeniach dotyczących finansowania całej operacji. Na koniec dnia, całkowite opłaty dla AWS pozwalające odpierać atak przez 36 godzin wyniosły mniej niż 1500 USD.

Tylko odpowiednie doświadczenie i plan działań w takiej sytuacji pozwoliły przetrwać atak. Analiza zdarzenia dostarczyła jednak dodatkowej wiedzy na temat obrony przed atakami DDoS o wielkiej skali. W rezultacie warto powiedzieć o kilku ważnych sprawach, dotyczących ochrony aplikacji Web przed atakami DDoS:

  • tworzymy, konfigurujemy i testujemy infrastrukturę do przeciwdziałania atakom DDoS. Testy powinny być przeprowadzone w ramach ustaleń z dostawcą usług hostingowych i przy jego pomocy,
  • dokładnie definiujemy co jest normalnym zachowaniem w danym środowisku i ustawiamy alarmy na przypadek odchyleń od tej normy,
  • zapewniamy możliwość szybkich zmian DNS, najlepiej w czasie rzeczywistym, bez zależności od zewnętrznego dostawcy usługi,
  • warto nauczyć się i przećwicz jak efektywnie zarządzać zmianami DNS w przypadku potencjalnych wyzwań,
  • testy odporności na atak powinny zawierać wiele wielowątkowych zapytań z setek atakujących hostów z możliwością szybkiego przekroczenia dostępnych zasobów serwerowych. Należy uruchomić każdy test na co najmniej trzy godziny w celu oceny odpowiedzi infrastruktury w czasie,
  • gdy budujemy skalowalną konfigurację, nie warto wykorzystywać obciążenia CPU jako metryki. Najlepszym rozwiązaniem w przypadku DDoS jest badanie ilości przychodzących zapytań http i ustawienie pod tą opcję odpowiednich poziomów wyzwalających zmiany skalowania,
  • warto skalować się w górę szybko, natomiast w dół wolno. Pozwoli to bardzo szybko odpowiedzieć na początkowe ataki oraz zredukować ryzyko ponownego skalowania w górę jeżeli atakujący wróci z mocniejszym atakiem.
W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200