Gigantyczny atak DDoS na GitHuba – 1,3 terabita na sekundę
Gdzie leży granica przepustowości złośliwych ataków odmowy usługi? Na jakie ataki muszą przygotować się usługodawcy? Wraz z ewolucją nowych metod ataków przesuwa się granica – i obecnie wynosi 1,3 terabita na sekundę.
Wczoraj popularny serwis programistyczny GitHub odnotował kilkuminutową przerwę w działalności. Dzisiejszy komunikat techniczny wskazuje, że przyczyną był gigantyczny atak odmowy usługi, w którym napastnicy zalewali serwery GitHuba ogromnym strumieniem danych.
Szczegóły ataku
O godzinie 17:21 GitHub odnotował znaczący i nagły wzrost ilości ruchu przychodzącego do swoich serwerów. Mimo niedawnego podwojenia przepustowości wykorzystywanych łączy ruchu było tyle, że zablokowana została możliwość korzystania z serwisu. GitHub skorzystał zatem z umów wcześniej zawartych z firmą Akamai, co pozwoliło na przyjęcie uderzenia przez partnera o większych możliwościach technicznych. Około 17:30 sytuacja została opanowana i strona powróciła do życia. Skalę ataku najlepiej obrazuje wykres przygotowany przez Akamai.
W szczytowym momencie ataku złośliwy ruch osiągał przepustowość rzędu 1,35 terabita na sekundę. Do sieci Akamai docierało 127 milionów pakietów na sekundę z przeznaczeniem dla serwerów GitHuba. Wcześniejszy najsilniejszy odnotowany i ujawniony atak sięgał 1,2 terabita na sekundę i dotknął firmę Dyn oraz – pośrednio – wiele popularnych usług internetowych które z jej usług korzystały.
Czego użyto do ataku
Co ciekawe, atak przeprowadzono niedawno szerzej opisaną metodą, wykorzystującą nieprawidłowo skonfigurowane serwery Memcached, przydatnej usługi pomagającej w zarządzaniu dużym ruchem na stronie. Niestety wielu posiadaczy Memcached zapomniało, że usługa ta nie powinna być dostępna dla każdego użytkownika internetu, a jedynie dla sieci wewnętrznej. Wystawione do świata serwery Memcached oferują ogromny mnożnik atakującym – na każdy wysłany do nich bajt ze sfałszowanym adresem nadawcy można liczyć na odpowiedź o rozmiarze 51 kilobajtów, wysłaną na adres celu ataku. Dzięki temu atakujący mogą osiągnąć efekt 51 000 razy mocniejszy niż gdyby atakowali serwer ofiary bezpośrednio, dodatkowo ukrywając swoją tożsamość. GitHub poinformował, że atak nadszedł z ponad tysiąca podsieci i dziesiątek tysięcy hostów. Widać zatem, że opisany trzy dni temu przez naszego rodaka pracującego w CloudFlare problem z serwerami Memcached jeszcze nie został rozwiązany przez ich administratorów.
Podobne wpisy
- Przestańcie nagłaśniać rosyjskie ataki DDoS – to ich akcje propagandowe
- Ofiara ransomware kontratakuje i to całkiem skutecznie
- TAMA – operatorski system ochrony przed atakami DDoS
- Używasz Kodi i wtyczki Exodus? Mogłeś nieświadomie brać udział w atakach DDoS
- Duży atak DDoS powoduje problemy z dostępem do wielu usług
Do dobrego zwyczaju należy filtrowanie (lub chociaż rate limit) memcached i kilkunastu podobnych protokołów na brzegu sieci, żeby nie brać udziału w ataku.
Mnie to nie pomoże, ale innym tak.
Żeby to tylko było nieco popularniejsze.
pytanie, po co komu atakować githuba?
Trening, pokaz siły lub testy do czegoś większego. Wątpię, żeby ktoś od tak zaatakował GitHuba, dla zabawy.
Może to Apple w zamian za to, że nie chcieli usunąć iOSa.:)
to na pewno odpowiedź więtego Mikołaja na listy niegrzecznych dzeci
Ktoś sobie botnet testuje :)
Zawsze należy zadać sobie pytanie: Kto zyskał na zdarzeniu ? W tym przypadku jest to świetna reklama dla Akamai
Kto jak kto, ale Akamai chyba nie musi się reklamować ;)
@bieda moglo byc np tak, ze ktos szantazuje ta firme – chce kase za odstapienie od atakow.
Czy przy takim zatkaniu GITHUBa jest szansa na przechwycenie czyjegoś commita lub podstawienie mu zmodyfikowany serwis i/lub pliki? Jeśli tak to w ciągu kilku tygodni wyjdzie, że jakieś znane oprogramowanie miało „wklejki”.
A jak zablokujesz wejscie do klatki schodowej to jest szansa ze ci ktos ukradnie laptopa z mieszkania?
W jaki niby sposob takie przechwycenie commita mialoby sie odbyc? Zakladajac, ze atakujacy nie jest MITM.
Nie, nie ma takiej szansy. Zasada działania Git praktycznie eliminuje takie „wrzutki” a jeśliby się coś takiego zdarzyło (zakładając złamanie SSL przy transporcie i paru innych rzeczy), dość szybko można się zorientować, że repozytoria się „rozjechały”. Rozproszony system zarządzania kodem źródłowym dość dobrze chroni przed naruszeniami integralności. Prawdopodobnie cała akcja to zasłona dymna i test czegoś zupełnie innego.
Ciekawe czy dojdą do takiego zakresu, żeby zrobić DDoS nie na serwery danej firmy, ale żeby zatkać całe łącze, np. podmorski światłowód.
A to już nie robią na DNS-y ataków albo na najpopularniejsze usługi typu Akamai jakoś rok temu, gdy 30% internetu po prostu zamarło?
Chińczycy?
Japonczycy i Tajowie.