W dniu wczorajszym rozpoczął się udany, trwający wiele godzin atak DDoS na witrynę WordPress.com hostującą dziennie ponad 100 milionów nowych wpisów dla 30 milionów klientów (np. TED, CBS, TechCrunch). To ponad 300 milionów unikalnych wizyt miesięcznie oraz 10% wszystkich stron WWW. Skutecznie przez wiele godzin atakowane były 3 centra hostingowe (Chicago, San Antonio oraz Dallas) uniemożliwiając normalne korzystanie z usług. Pracownicy firmy WordPress przyznają, iż był to największy atak DDoS w historii firmy, który przyjęły ich serwery.
Głównym podejrzanym jest jeden z serwisów (nie angielskich), który został zaatakowany ze względów politycznych. Rozmiar ataku osiągnął siłę wielu gigabitów na sekundę przepływności oraz dziesiątek milionów pakietów na sekundę przesyłanych danych. Warto w takiej sytuacji zastanowić się nad kolejną wadą rozwiązania umieszczenia swojego serwisu w chmurze wielkiego operatora posiadającego miliony klientów. W sytuacji gdy ktoś zwraca się przeciwko jednemu z tych klientów – automatycznie (oczywiście wszystko jest kwestią skali) atak kieruje się także w naszą stronę.
6 komentarzy do
4 marca, 2011 o godzinie 13:56
jest to wada i jednocześnie zaleta. Bo jeżeli atakują Twoją stronę, to oni coś muszą z tym zrobić, a tak to niestety trzeba się martwić samemu. Usuwanie skutków takiego ataku/jego przerwanie może przecież zabrać parę dni z życiorysu.
4 marca, 2011 o godzinie 13:57
Ale co ma do tego chmura? Wykupienie serwera wirtualnego, dedykowanego etc. u dostawcy to też chmura? A można równie dobrze ugotować się jak w prawdziwej chmurze.
Pisałbym raczej o „wspólnym” hostingu w takim kontekście.
4 marca, 2011 o godzinie 18:01
@matipl:
W tym wypadku nie posiadasz ani zwykłego hostingu czyli takiego gdzie przykładowo jest uruchomionych per serwer, skrajnie – tysiące klientów, ani serwera dedykowanego, który posiada swój własny IP i własne zasoby.
Klient otrzymuje w zasadzie Usługę, a pojęcia nie ma jaki będzie jest adres IP, które konkretnie zasoby, którego serwera współdzieli z innymi użytkownikami itd. Przechowywanie danych na wielu serwerach, w wielu miejscach, w przezroczysty dla Ciebie sposób przemieszczanych zarówno pod kątem danych jak i redundantnej struktury sieciowej czyli IMHO w chmurze właśnie.
Winniśmy zacząć dywagować na temat tego jak bardzo wspólny hosting na wirtualnych maszynach, z rozproszonymi sieciowymi systemami plików, jest podobny do chmury i w którym miejscu kończy się hosting, a zaczyna się chmura. I czy usługi w *.wordpress.com to już chmura czy jeszcze nie? Chyba nie o to nam chodzi :]
A już w tym konkretnym przypadku wciąż nie wiemy czy pakietowane były routery brzegowe operatorów wysycając przepływność czy load balancery WWW, tudzież DNS domeny wordpress.com czy serwery serwujące treści.
5 marca, 2011 o godzinie 16:09
>Warto w takiej sytuacji zastanowić się nad kolejną wadą rozwiązania umieszczenia swojego serwisu w chmurze
Zgadzam sie jackkiem. Zarzniecie wordpressa to powazne przedsiewziecie. Zarzniecie lokalnego hostingu jakiejs malej firmy to pikus.
5 marca, 2011 o godzinie 18:40
Oczywiście, że tak. Nie porównujemy wielkiej chmury do małego hostingu w kontekście możliwości położenia. Chodziło mi wyłącznie o to, że w chmurze jest klientów 30 milionów i wystarczyło, że ktoś z olbrzymią mocą nie polubił jednego z tych 30 milionów. Atakując całą chmurę jako usługę (nie wyłącznie jako przepływność sieciową) w zależności od jej budowy, może wpłynąć na całościowe jej działanie. Nie widziałem jeszcze jednego serwera hostującego 30 milionów klientów, a w podobnym przypadku jeśli atakowany Klient miałby wykupioną usługę na przykład serwera dedykowanego – wystarczyłoby (oczywiście mniejszymi zasobami) położyć unieruchomić serwer, pozostałej części Klientom nie groziłaby w takiej sytuacji utrata działania usługi.
10 marca, 2011 o godzinie 23:42
a umieszczenie wlasnego serwera w duzej serwerowni ktora ma duzo klientow? ktos sie uwezmie na klienta z szafki obok i tez cie niema bo pada skrzynka odpowiedzalna za te sciane szafek. czy to w chumurze, czy to w malej czy w duzej serwerowni czy to we wlasnej serwerowni ktos zawsze moze stwierdzic my botnet is bigger than yours