{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS jako pomoc: jak przeprowadzamy testy stresowe i obci\u0105\u017ceniowe","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nFirma Variti opracowuje ochron\u0119 przed botami i atakami DDoS, a tak\u017ce przeprowadza testy obci\u0105\u017ceniowe i wydajno\u015bciowe. Na konferencji HighLoad++ 2018 opowiadali\u015bmy, jak zabezpieczy\u0107 zasoby przed r\u00f3\u017cnego rodzaju atakami. Kr\u00f3tko m\u00f3wi\u0105c: izoluj cz\u0119\u015bci systemu, korzystaj z us\u0142ug chmurowych i CDN oraz regularnie aktualizuj oprogramowanie. Jednak bez wyspecjalizowanych firm zajmuj\u0105cych si\u0119 ochron\u0105 nie poradzisz sobie \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nPrzed przeczytaniem tekstu mo\u017cesz zapozna\u0107 si\u0119 z kr\u00f3tkimi punktami podsumowuj\u0105cymi na stronie konferencji<\/a><\/noindex>.
\nA je\u015bli nie lubisz czyta\u0107 lub po prostu chcesz obejrze\u0107 nagranie, znajdziesz poni\u017cej nasze wyst\u0105pienie w spoilerze.<\/p>\n

Nagranie wideo wyst\u0105pienia<\/b>

\r\n \"Odtwarzaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Wiele firm potrafi przeprowadza\u0107 testy obci\u0105\u017ceniowe, ale nie wszystkie wykonuj\u0105 testy wytrzyma\u0142o\u015bciowe. Niekt\u00f3rzy z naszych klient\u00f3w s\u0105 przekonani, \u017ce ich strona jest odporna na ataki, poniewa\u017c maj\u0105 system highload, kt\u00f3ry dobrze chroni. My jednak pokazujemy, \u017ce to nie do ko\u0144ca prawda.
\nOczywi\u015bcie przed przeprowadzeniem test\u00f3w uzyskujemy zgod\u0119 od klienta, z podpisem i piecz\u0119ci\u0105, a z nasz\u0105 pomoc\u0105 nie mo\u017cna przeprowadzi\u0107 DDoS na nikogo. Testowanie odbywa si\u0119 w ustalonym przez klienta czasie, gdy ruch na jego zasobach jest minimalny, a problemy z dost\u0119pem nie wp\u0142yn\u0105 na klient\u00f3w. Dodatkowo, poniewa\u017c w trakcie testowania zawsze mog\u0105 wyst\u0105pi\u0107 nieprzewidziane zdarzenia, mamy sta\u0142y kontakt z klientem. To pozwala nie tylko na informowanie o osi\u0105gni\u0119tych wynikach, ale tak\u017ce na dokonywanie zmian w trakcie test\u00f3w. Po zako\u0144czeniu test\u00f3w zawsze sporz\u0105dzamy raport, w kt\u00f3rym wskazujemy na znalezione wady i udzielamy rekomendacji dotycz\u0105cych usuni\u0119cia s\u0142abych punkt\u00f3w strony. <\/p>\n

Jak pracujemy<\/h3>\n

\nPodczas testowania emulujemy botnet. Poniewa\u017c pracujemy z klientami, kt\u00f3rzy nie znajduj\u0105 si\u0119 w naszych sieciach, aby test nie zako\u0144czy\u0142 si\u0119 w pierwszej minucie z powodu limit\u00f3w lub ochrony, obci\u0105\u017cenie aplikujemy nie z jednego IP, lecz z w\u0142asnej podsieci. Dodatkowo, aby stworzy\u0107 znacz\u0105ce obci\u0105\u017cenie, mamy w\u0142asny wystarczaj\u0105co mocny serwer testowy.<\/p>\n

Postulaty<\/h3>\n

<\/p>\n

Wiele \u2014 nie znaczy dobrze<\/b>
\nIm mniej obci\u0105\u017cone zasoby doprowadzimy do awarii, tym lepiej. Je\u015bli uda si\u0119 tak zorganizowa\u0107, \u017ce strona przestanie dzia\u0142a\u0107 przy jednym \u017c\u0105daniu na sekund\u0119 lub nawet przy jednym \u017c\u0105daniu na minut\u0119, to b\u0119dzie wspaniale. Poniewa\u017c zgodnie z prawem Murphy'ego u\u017cytkownicy lub hakerzy przypadkowo trafi\u0105 dok\u0142adnie w t\u0119 luk\u0119. <\/p><\/blockquote>\n

Cz\u0119\u015bciowa awaria jest lepsza ni\u017c ca\u0142kowita<\/b>
\nZawsze radzimy, aby systemy by\u0142y heterogeniczne. Powinny by\u0107 dzielone na poziomie fizycznym, a nie tylko przez konteneryzacj\u0119. W przypadku fizycznego podzia\u0142u, nawet je\u015bli co\u015b zawiedzie na stronie, to istnieje du\u017ce prawdopodobie\u0144stwo, \u017ce nie przestanie ona dzia\u0142a\u0107 ca\u0142kowicie, a u\u017cytkownicy b\u0119d\u0105 mieli dost\u0119p przynajmniej do cz\u0119\u015bci funkcji.<\/p><\/blockquote>\n

Prawid\u0142owa architektura to podstawa odporno\u015bci<\/b>
\nOdporno\u015b\u0107 zasobu i jego zdolno\u015b\u0107 do wytrzymania atak\u00f3w i obci\u0105\u017ce\u0144 powinny by\u0107 uwzgl\u0119dnione na etapie projektowania, w\u0142a\u015bciwie ju\u017c na etapie rysowania pierwszych schemat\u00f3w blokowych w notesie. Poniewa\u017c je\u015bli pojawi\u0105 si\u0119 fatalne b\u0142\u0119dy, mo\u017cna je naprawi\u0107 p\u00f3\u017aniej, ale jest to bardzo trudne.<\/p><\/blockquote>\n

Nie tylko kod, ale i konfiguracja musi by\u0107 dobra<\/b>
\nWielu my\u015bli, \u017ce dobra dru\u017cyna programistyczna to gwarancja odporno\u015bci us\u0142ugi. Rzeczywi\u015bcie potrzebna jest dobra dru\u017cyna programistyczna, ale r\u00f3wnie wa\u017cna jest tak\u017ce dobra eksploatacja, dobry DevOps. To znaczy potrzebni s\u0105 specjali\u015bci, kt\u00f3rzy prawid\u0142owo skonfiguruj\u0105 Linux i sie\u0107, poprawnie napisz\u0105 konfiguracje w nginx, ustawi\u0105 limity i inne elementy. W przeciwnym razie zas\u00f3b b\u0119dzie dzia\u0142a\u0142 dobrze tylko na testach, a w \u015brodowisku produkcyjnym w pewnym momencie wszystko si\u0119 zepsuje.<\/p><\/blockquote>\n

R\u00f3\u017cnice mi\u0119dzy testowaniem obci\u0105\u017ceniowym a testowaniem stresowym<\/b>
\nTestowanie obci\u0105\u017ceniowe pozwala na odkrycie granic dzia\u0142ania systemu. Testowanie stresowe koncentruje si\u0119 na znalezieniu s\u0142abych miejsc systemu i jest u\u017cywane do rozbicia tego systemu oraz obserwowania, jak b\u0119dzie si\u0119 zachowywa\u0142 w trakcie awarii r\u00f3\u017cnych element\u00f3w. Przy tym charakter obci\u0105\u017cenia zwykle pozostaje nieznany dla zamawiaj\u0105cego przed rozpocz\u0119ciem testowania stresowego.<\/p><\/blockquote>\n

<\/p>\n

Wyr\u00f3\u017cniaj\u0105ce cechy atak\u00f3w L7<\/h3>\n

\nRodzaje obci\u0105\u017ce\u0144 dzielimy zazwyczaj na obci\u0105\u017cenia na poziomie L7 oraz L3&4. L7 to obci\u0105\u017cenie na poziomie aplikacji, najcz\u0119\u015bciej rozumiane tylko jako HTTP, my jednak rozumiemy przez to ka\u017cde obci\u0105\u017cenie na poziomie protoko\u0142u TCP.
\nAtaki L7 maj\u0105 pewne charakterystyczne cechy. Po pierwsze, pojawiaj\u0105 si\u0119 one bezpo\u015brednio w aplikacji, wi\u0119c przechwycenie ich za pomoc\u0105 \u015brodk\u00f3w sieciowych jest ma\u0142o prawdopodobne. Takie ataki wykorzystuj\u0105 logik\u0119 i dzi\u0119ki temu bardzo efektywnie, nawet przy niewielkim ruchu, zu\u017cywaj\u0105 CPU, pami\u0119\u0107, dysk, baz\u0119 danych i inne zasoby.<\/p>\n

HTTP Flood<\/h3>\n

\nW przypadku jakiegokolwiek ataku \u0142atwiej jest stworzy\u0107 obci\u0105\u017cenie ni\u017c je przetworzy\u0107, co r\u00f3wnie\u017c dotyczy atak\u00f3w L7. Ruch ataku nie zawsze \u0142atwo odr\u00f3\u017cni\u0107 od ruchu legalnego, a najcz\u0119\u015bciej udaje si\u0119 to zrobi\u0107 na podstawie cz\u0119stotliwo\u015bci, jednak je\u015bli wszystko jest dobrze zaplanowane, analiza log\u00f3w nie pozwala okre\u015bli\u0107, gdzie jest atak, a gdzie legalne \u017c\u0105dania.
\nJako pierwszy przyk\u0142ad we\u017amy atak HTTP Flood. Z wykresu wida\u0107, \u017ce zwykle takie ataki s\u0105 bardzo pot\u0119\u017cne; w poni\u017cszym przyk\u0142adzie szczytowa liczba \u017c\u0105dania przekracza\u0142a 600 tysi\u0119cy na minut\u0119.<\/p>\n

\"DDoS
\n
\nHTTP Flood to najprostszy spos\u00f3b na stworzenie obci\u0105\u017cenia. Zazwyczaj u\u017cywa si\u0119 do tego jakiego\u015b narz\u0119dzia do test\u00f3w obci\u0105\u017ceniowych, na przyk\u0142ad ApacheBench, i okre\u015bla si\u0119 \u017c\u0105danie oraz cel. Przy tak prostym podej\u015bciu istnieje du\u017ce ryzyko napotkania na pami\u0119\u0107 podr\u0119czn\u0105 serwera, ale mo\u017cna j\u0105 \u0142atwo obej\u015b\u0107, na przyk\u0142ad dodaj\u0105c losowe ci\u0105gi do \u017c\u0105dania, co zmusi serwer do ci\u0105g\u0142ego zwracania \u015bwie\u017cej strony.
\nNie warto r\u00f3wnie\u017c zapomina\u0107 o user-agencie podczas tworzenia obci\u0105\u017cenia. Wiele user-agent\u00f3w popularnych narz\u0119dzi testuj\u0105cych jest filtrowanych przez administrator\u00f3w systemu, co w takim przypadku mo\u017ce sprawi\u0107, \u017ce obci\u0105\u017cenie po prostu nie dotrze do backendu. Znacz\u0105co poprawi\u0107 wyniki mo\u017cna, wstawiaj\u0105c do \u017c\u0105dania bardziej lub mniej wa\u017cny nag\u0142\u00f3wek z przegl\u0105darki.
\nPomimo swojej prostoty, ataki HTTP Flood maj\u0105 r\u00f3wnie\u017c swoje wady. Po pierwsze, do stworzenia obci\u0105\u017cenia wymagane s\u0105 du\u017ce zasoby. Po drugie, takie ataki s\u0105 bardzo \u0142atwe do wykrycia, szczeg\u00f3lnie je\u015bli pochodz\u0105 z jednego adresu. W rezultacie, \u017c\u0105dania natychmiast zaczynaj\u0105 by\u0107 filtrowane przez administrator\u00f3w systemu lub nawet na poziomie dostawcy. <\/p>\n

Co szuka\u0107<\/h3>\n

\nAby zmniejszy\u0107 liczb\u0119 \u017c\u0105da\u0144 na sekund\u0119 i jednocze\u015bnie nie straci\u0107 na efektywno\u015bci, trzeba wykaza\u0107 si\u0119 nieco kreatywno\u015bci\u0105 i zbada\u0107 stron\u0119. Mo\u017cna obci\u0105\u017ca\u0107 nie tylko \u0142\u0105cze lub serwer, ale tak\u017ce poszczeg\u00f3lne cz\u0119\u015bci aplikacji, takie jak bazy danych czy systemy plik\u00f3w. Mo\u017cna tak\u017ce poszuka\u0107 miejsc na stronie, kt\u00f3re wykonuj\u0105 du\u017ce obliczenia: kalkulatory, strony z rekomendacjami produkt\u00f3w i tym podobne. Wreszcie, cz\u0119sto zdarza si\u0119, \u017ce na stronie znajduje si\u0119 pewien skrypt PHP, kt\u00f3ry generuje stron\u0119 z kilku setek tysi\u0119cy linii. Taki skrypt r\u00f3wnie\u017c w znacznym stopniu obci\u0105\u017ca serwer i mo\u017ce sta\u0107 si\u0119 celem ataku.<\/p>\n

Gdzie szuka\u0107<\/h3>\n

\nGdy skanujemy zas\u00f3b przed przeprowadzeniem test\u00f3w, zwracamy uwag\u0119 przede wszystkim na sam\u0105 stron\u0119. Szukamy wszelkich p\u00f3l wej\u015bciowych, du\u017cych plik\u00f3w \u2014 og\u00f3lnie wszystkiego, co mo\u017ce stwarza\u0107 problemy dla zasobu i spowalnia\u0107 jego dzia\u0142anie. W tym pomagaj\u0105 podstawowe narz\u0119dzia deweloperskie w Google Chrome i Firefox, kt\u00f3re pokazuj\u0105 czasy odpowiedzi strony.
\nSkanujemy tak\u017ce subdomeny. Na przyk\u0142ad, je\u015bli istnieje pewien sklep internetowy, abc.com, i ma on subdomen\u0119 admin.abc.com. Prawdopodobnie jest to panel administracyjny z autoryzacj\u0105, ale je\u015bli na niego na\u0142o\u017cy\u0107 obci\u0105\u017cenie, mo\u017ce to stworzy\u0107 problemy dla g\u0142\u00f3wnego zasobu.
\nStrona mo\u017ce mie\u0107 subdomen\u0119 api.abc.com. Prawdopodobnie jest to zas\u00f3b dla aplikacji mobilnych. Aplikacj\u0119 mo\u017cna znale\u017a\u0107 w App Store lub Google Play, ustawi\u0107 specjalny punkt dost\u0119pu, zanalizowa\u0107 API i zarejestrowa\u0107 konta testowe. Problem w tym, \u017ce cz\u0119sto ludzie my\u015bl\u0105, \u017ce wszystko, co jest chronione autoryzacj\u0105, jest odporne na ataki typu denial of service. Rzekomo autoryzacja to najlepsza CAPTCHA, ale tak nie jest. Stworzenie 10-20 kont testowych jest proste, a po ich za\u0142o\u017ceniu uzyskujemy dost\u0119p do skomplikowanej i niezabezpieczonej funkcjonalno\u015bci.
\nOczywi\u015bcie przygl\u0105damy si\u0119 historii, plikowi robots.txt i WebArchive, ViewDNS, szukaj\u0105c starych wersji zasobu. Czasami zdarza si\u0119, \u017ce deweloperzy wprowadzaj\u0105, powiedzmy, mail2.yandex.net, a stara wersja, mail.yandex.net, pozostaje. Ten mail.yandex.net przestaje by\u0107 wspierany, nie ma na niego przydzielonych zasob\u00f3w deweloperskich, ale nadal spo\u017cywa baz\u0119 danych. W zwi\u0105zku z tym, korzystaj\u0105c ze starej wersji, mo\u017cna skutecznie zaanga\u017cowa\u0107 zasoby backendu i wszystkiego, co stoi za frontem. Oczywi\u015bcie nie zawsze tak si\u0119 dzieje, ale wci\u0105\u017c do\u015b\u0107 cz\u0119sto si\u0119 z tym spotykamy.
\nOczywi\u015bcie, analizujemy wszystkie parametry zapytania oraz struktur\u0119 cookie. Mo\u017cemy na przyk\u0142ad umie\u015bci\u0107 w tablicy JSON wewn\u0105trz cookie jak\u0105\u015b warto\u015b\u0107, stworzy\u0107 du\u017c\u0105 zagnie\u017cd\u017con\u0105 struktur\u0119 i zmusi\u0107 zas\u00f3b do pracy w nierozs\u0105dnie d\u0142ugi spos\u00f3b.<\/p>\n

Obci\u0105\u017cenie w wyszukiwarce<\/h3>\n

\nPierwsze, co przychodzi do g\u0142owy podczas badania strony, to obci\u0105\u017cenie bazy danych, poniewa\u017c wyszukiwanie wyst\u0119puje niemal wsz\u0119dzie i niestety cz\u0119sto jest \u017ale zabezpieczone. Dlaczego\u015b deweloperzy nie po\u015bwi\u0119caj\u0105 wystarczaj\u0105cej uwagi wyszukiwaniu. Ale istnieje jedna rekomendacja \u2014 nie nale\u017cy wykonywa\u0107 jednolitych zapyta\u0144, poniewa\u017c mo\u017cna napotka\u0107 cache, tak jak w przypadku ataku HTTP flood.
\nWykonywanie losowych zapyta\u0144 do bazy danych nie zawsze jest efektywne. O wiele lepiej jest stworzy\u0107 list\u0119 s\u0142\u00f3w kluczowych, kt\u00f3re odnosz\u0105 si\u0119 do wyszukiwania. Je\u015bli wr\u00f3cimy do przyk\u0142adu sklepu internetowego: powiedzmy, \u017ce strona sprzedaje opony samochodowe i pozwala na okre\u015blenie promienia opon, typu samochodu i innych parametr\u00f3w. W zwi\u0105zku z tym kombinacje odpowiednich s\u0142\u00f3w sprawi\u0105, \u017ce baza danych b\u0119dzie pracowa\u0107 w znacznie bardziej z\u0142o\u017conych warunkach.
\nPonadto warto stosowa\u0107 paginacj\u0119: wyszukiwaniu znacznie trudniej jest zwr\u00f3ci\u0107 przedostatni\u0105 stron\u0119 wynik\u00f3w ni\u017c pierwsz\u0105. Dzi\u0119ki paginacji mo\u017cna nieco urozmaici\u0107 obci\u0105\u017cenie.
\nNa poni\u017cszym przyk\u0142adzie pokazujemy obci\u0105\u017cenie w wyszukiwarce. Wida\u0107, \u017ce od pierwszej sekundy testu przy pr\u0119dko\u015bci dziesi\u0119ciu zapyta\u0144 na sekund\u0119 strona pad\u0142a i przesta\u0142a odpowiada\u0107.<\/p>\n

\"DDoS
\n<\/p>\n

Co je\u015bli nie ma wyszukiwania?<\/h3>\n

\nJe\u015bli nie ma wyszukiwania, to nie znaczy, \u017ce strona nie zawiera innych podatnych p\u00f3l wej\u015bciowych. Takim polem mo\u017ce by\u0107 autoryzacja. Wsp\u00f3\u0142cze\u015bni deweloperzy lubi\u0105 tworzy\u0107 skomplikowane hashe, aby zabezpieczy\u0107 baz\u0119 login\u00f3w przed atakami przy u\u017cyciu tabel t\u0119czowych. To dobrze, ale takie hashe zu\u017cywaj\u0105 du\u017ce zasoby CPU. Du\u017cy nat\u0119\u017cenie fa\u0142szywych autoryzacji prowadzi do przeci\u0105\u017cenia procesora, a w efekcie strona przestaje dzia\u0142a\u0107.
\nObecno\u015b\u0107 na stronie wszelkich formularzy do komentarzy i kontaktu to pretekst do wysy\u0142ania tam bardzo du\u017cych tekst\u00f3w lub tworzenia masowego spamu. Czasami strony akceptuj\u0105 za\u0142\u0105czone pliki, tak\u017ce w formacie gzip. W takim przypadku pobieramy plik o rozmiarze 1TB, kompresujemy go przy u\u017cyciu gzip do kilku bajt\u00f3w lub kilobajt\u00f3w i wysy\u0142amy na stron\u0119. Nast\u0119pnie jest on dekompresowany i uzyskujemy bardzo ciekawy efekt. <\/p>\n

Rest API<\/h3>\n

\nChcia\u0142bym po\u015bwi\u0119ci\u0107 chwil\u0119 na om\u00f3wienie popularnych obecnie us\u0142ug, takich jak Rest API. Ochrona Rest API jest znacznie trudniejsza ni\u017c ochrona standardowej strony internetowej. Nawet banalne metody zabezpieczenia przed atakami typu brute force i innymi nieautoryzowanymi dzia\u0142aniami nie dzia\u0142aj\u0105 w przypadku Rest API.
\nRest API jest bardzo \u0142atwe do z\u0142amania, poniewa\u017c bezpo\u015brednio komunikuje si\u0119 z baz\u0105 danych. Awaria takiej us\u0142ugi mo\u017ce mie\u0107 powa\u017cne konsekwencje dla biznesu, poniewa\u017c przez Rest API cz\u0119sto s\u0105 powi\u0105zane nie tylko g\u0142\u00f3wna strona, ale i aplikacja mobilna oraz inne wewn\u0119trzne zasoby biznesowe. Je\u015bli wszystko to przestaje dzia\u0142a\u0107, skutki s\u0105 znacznie powa\u017cniejsze ni\u017c w przypadku awarii prostej strony internetowej. <\/p>\n

Obci\u0105\u017cenie przy du\u017cym obci\u0105\u017ceniu tre\u015bci<\/h3>\n

\nJe\u015bli proponuj\u0105 nam przetestowanie zwyk\u0142ej aplikacji jednostronicowej, l\u0105dowania lub wizyt\u00f3wki, kt\u00f3re nie maj\u0105 z\u0142o\u017conej funkcjonalno\u015bci, poszukujemy obci\u0105\u017caj\u0105cej tre\u015bci. Na przyk\u0142ad du\u017cych zdj\u0119\u0107, kt\u00f3re serwer dostarcza, plik\u00f3w binarnych, dokumentacji PDF \u2014 pr\u00f3bujemy pobiera\u0107 wszystkie te materia\u0142y. Takie testy skutecznie obci\u0105\u017caj\u0105 system plik\u00f3w i zajmuj\u0105 pasmo, co czyni je efektywnymi. Oznacza to, \u017ce je\u015bli nie wy\u0142\u0105czysz serwera podczas pobierania du\u017cego pliku przy niskich pr\u0119dko\u015bciach, po prostu zablokujesz pasmo docelowego serwera, co spowoduje odmow\u0119 obs\u0142ugi.
\nNa przyk\u0142adzie takiego testu wida\u0107, \u017ce przy pr\u0119dko\u015bci 30 RPS strona przesta\u0142a odpowiada\u0107 lub zwraca\u0142a b\u0142\u0119dy serwera 500.<\/p>\n

\"DDoS
\n
\nNie mo\u017cna r\u00f3wnie\u017c zapomina\u0107 o konfiguracji serwer\u00f3w. Cz\u0119sto mo\u017cna spotka\u0107 sytuacje, gdy kto\u015b kupi\u0142 wirtualn\u0105 maszyn\u0119, zainstalowa\u0142 na niej Apache, skonfigurowa\u0142 wszystko domy\u015blnie, umie\u015bci\u0142 aplikacj\u0119 PHP, a poni\u017cej mo\u017cna zobaczy\u0107 wyniki. <\/p>\n

\"DDoS
\n
\nTutaj obci\u0105\u017cenie dotyczy\u0142o g\u0142\u00f3wnego katalogu i wynosi\u0142o zaledwie 10 RPS. Czekali\u015bmy 5 minut, a serwer upad\u0142. Na koniec wiadomo, dlaczego upad\u0142, ale istnieje podejrzenie, \u017ce po prostu przechwyci\u0142 za du\u017co pami\u0119ci i dlatego przesta\u0142 odpowiada\u0107.<\/p>\n

Wave based<\/h3>\n

\nW ci\u0105gu ostatnich dw\u00f3ch lat ataki falowe sta\u0142y si\u0119 do\u015b\u0107 popularne. Wynika to z faktu, \u017ce wiele organizacji kupuje r\u00f3\u017cne urz\u0105dzenia do ochrony przed DDoS, kt\u00f3re wymagaj\u0105 okre\u015blonego czasu na zebranie statystyk przed rozpocz\u0119ciem filtracji ataku. To znaczy, \u017ce nie filtruj\u0105 ataku w pierwszych 30-40 sekundach, poniewa\u017c zbieraj\u0105 dane i ucz\u0105 si\u0119. Odpowiednio w te 30-40 sekund na stron\u0119 mo\u017cna wys\u0142a\u0107 tyle \u017c\u0105da\u0144, \u017ce zas\u00f3b b\u0119dzie niedost\u0119pny przez d\u0142ugi czas, a\u017c wszystkie \u017c\u0105dania zostan\u0105 przetworzone.
\nW przypadku poni\u017cszego ataku interwa\u0142 wynosi\u0142 10 minut, po czym nadesz\u0142a nowa, zmodyfikowana partia ataku.<\/p>\n

\"DDoS
\n
\nTo znaczy, \u017ce ochrona si\u0119 nauczy\u0142a, uruchomi\u0142a filtracj\u0119, ale pojawi\u0142a si\u0119 nowa, zupe\u0142nie inna partia ataku, i ochrona zn\u00f3w rozpocz\u0119\u0142a nauk\u0119. Faktycznie filtracja przestaje dzia\u0142a\u0107, ochrona staje si\u0119 nieskuteczna, a strona jest niedost\u0119pna.
\nAtaki falowe charakteryzuj\u0105 si\u0119 bardzo wysokimi warto\u015bciami szczytowymi, mog\u0105 osi\u0105ga\u0107 sto tysi\u0119cy lub milion zapyta\u0144 na sekund\u0119 w przypadku L7. Je\u015bli m\u00f3wimy o L3 i L4, mo\u017ce to si\u0119ga\u0107 setek gigabit\u00f3w ruchu, lub odpowiednio setek mpps, je\u015bli liczy\u0107 w pakietach.
\nProblem takich atak\u00f3w le\u017cy w synchronizacji. Ataki pochodz\u0105 z botnetu, a aby stworzy\u0107 bardzo du\u017cy jednorazowy szczyt, wymagana jest wysoka synchronizacja. I ta koordynacja nie zawsze si\u0119 udaje: czasami na wyj\u015bciu otrzymuje si\u0119 jaki\u015b paraboliczny szczyt, kt\u00f3ry wygl\u0105da do\u015b\u0107 \u017ca\u0142o\u015bnie.<\/p>\n

Nie samym HTTP \u017cyjemy<\/h3>\n

\nOpr\u00f3cz HTTP na poziomie L7, lubimy tak\u017ce wykorzystywa\u0107 inne protoko\u0142y. Zazwyczaj w przypadku zwyk\u0142ej strony internetowej, tym bardziej w ramach standardowego hostingu, na zewn\u0105trz wystaj\u0105 protoko\u0142y pocztowe i MySQL. Protoko\u0142y pocztowe s\u0105 mniej nara\u017cone na obci\u0105\u017cenia ni\u017c bazy danych, ale mo\u017cna je r\u00f3wnie\u017c obci\u0105\u017cy\u0107 wystarczaj\u0105co efektywnie, co skutkuje przeci\u0105\u017conym CPU na serwerze.
\nZ powodzeniem wykorzystali\u015bmy luk\u0119 w SSH z 2016 roku. Obecnie ta luka zosta\u0142a prawie wsz\u0119dzie naprawiona, ale to nie znaczy, \u017ce nie mo\u017cna obci\u0105\u017ca\u0107 SSH. Mo\u017cna. Po prostu wysy\u0142ana jest ogromna liczba pr\u00f3b autoryzacji, SSH zu\u017cywa prawie ca\u0142e CPU na serwerze, a strona internetowa przestaje dzia\u0142a\u0107 ju\u017c przy jednym lub dw\u00f3ch \u017c\u0105daniach na sekund\u0119. Odpowiednio te jedno-dwa \u017c\u0105dania nie mog\u0105 by\u0107 w logach odr\u00f3\u017cnione od legalnego obci\u0105\u017cenia.
\nWiele po\u0142\u0105cze\u0144, kt\u00f3re otwieramy na serwerach, wci\u0105\u017c pozostaje aktualnych. Kiedy\u015b problem ten dotyczy\u0142 Apache, a obecnie w du\u017cej mierze dotyczy nginx, poniewa\u017c cz\u0119sto jest on konfigurowany domy\u015blnie. Liczba po\u0142\u0105cze\u0144, kt\u00f3re nginx mo\u017ce utrzyma\u0107 otwartych, jest ograniczona; w zwi\u0105zku z tym, po otwarciu tej liczby po\u0142\u0105cze\u0144, nowe po\u0142\u0105czenie nginx ju\u017c nie akceptuje, co skutkuje tym, \u017ce strona nie dzia\u0142a.
\nNasz klaster testowy dysponuje wystarczaj\u0105c\u0105 moc\u0105 CPU, aby przeprowadzi\u0107 atak na SSL handshake. Z praktyki wynika, \u017ce botnety czasami r\u00f3wnie\u017c to robi\u0105. Z jednej strony, oczywiste jest, \u017ce nie mo\u017cna obej\u015b\u0107 si\u0119 bez SSL, poniewa\u017c wp\u0142ywa on na wyniki Google, pozycjonowanie i bezpiecze\u0144stwo. Z drugiej strony, SSL niestety ma problem z CPU. <\/p>\n

L3&4<\/h3>\n

\nKiedy m\u00f3wimy o atakach na poziomach L3&4, zazwyczaj odnosimy si\u0119 do ataku na poziomie kana\u0142u. Taki ruch prawie zawsze mo\u017cna odr\u00f3\u017cni\u0107 od normalnego, chyba \u017ce jest to atak SYN-flood. Problemy zwi\u0105zane z atakami SYN-flood dla \u015brodk\u00f3w ochrony wynikaj\u0105 z du\u017cych obj\u0119to\u015bci. Maksymalna wielko\u015b\u0107 L3&4 wynosi\u0142a 1,5-2 Tb\/s. Taki ruch jest bardzo trudny do przetworzenia, nawet dla du\u017cych firm, takich jak Oracle i Google.
\nSYN i SYN-ACK to pakiety u\u017cywane przy ustanawianiu po\u0142\u0105czenia. Dlatego SYN-flood jest trudny do odr\u00f3\u017cnienia od normalnego obci\u0105\u017cenia: nie wiadomo, czy to SYN, kt\u00f3ry przyby\u0142 w celu nawi\u0105zania po\u0142\u0105czenia, czy cz\u0119\u015b\u0107 floodu.<\/p>\n

UDP-flood<\/h3>\n

\nZazwyczaj przest\u0119pcy nie dysponuj\u0105 takimi mocami, jakie mamy my, dlatego do organizowania atak\u00f3w mo\u017ce by\u0107 wykorzystywana amplifikacja. Oznacza to, \u017ce przest\u0119pca skanuje internet i znajduje albo podatne, albo niew\u0142a\u015bciwie skonfigurowane serwery, kt\u00f3re na przyk\u0142ad w odpowiedzi na jeden pakiet SYN odpowiadaj\u0105 trzema SYN-ACK. Fa\u0142szuj\u0105c adres \u017ar\u00f3d\u0142owy z adresu serwera docelowego, mo\u017cna za pomoc\u0105 jednego pakietu zwi\u0119kszy\u0107 moc, powiedzmy, trzykrotnie, i przekierowa\u0107 ruch na ofiar\u0119.<\/p>\n

\"DDoS
\n
\nProblem amplifikacji polega na ich trudnym wykrywaniu. Z ostatnich przyk\u0142ad\u00f3w mo\u017cna przytoczy\u0107 g\u0142o\u015bny przypadek z podatno\u015bci\u0105 memcached. Co wi\u0119cej, obecnie pojawi\u0142o si\u0119 wiele urz\u0105dze\u0144 IoT, kamer IP, kt\u00f3re r\u00f3wnie\u017c zazwyczaj s\u0105 skonfigurowane domy\u015blnie i s\u0105 \u017ale skonfigurowane, dlatego za pomoc\u0105 takich urz\u0105dze\u0144 przest\u0119pcy najcz\u0119\u015bciej przeprowadzaj\u0105 ataki. <\/p>\n

\"DDoS
\n<\/p>\n

Trudny SYN-flood<\/h3>\n

\nSYN-flood to prawdopodobnie najbardziej interesuj\u0105cy rodzaj ataku z perspektywy programisty. Problem w tym, \u017ce cz\u0119sto administratorzy system\u00f3w stosuj\u0105 do ochrony blokad\u0119 IP. Niestety, przez blokad\u0119 IP cierpi\u0105 nie tylko administratorzy, kt\u00f3rzy dzia\u0142aj\u0105 wed\u0142ug skrypt\u00f3w, ale tak\u017ce, co gorsza, niekt\u00f3re systemy zabezpiecze\u0144, kt\u00f3re s\u0105 kupowane za du\u017ce pieni\u0105dze.
\nTaki spos\u00f3b mo\u017ce doprowadzi\u0107 do katastrofy, poniewa\u017c je\u015bli przest\u0119pcy podmieni\u0105 adresy IP<\/a>, firma zablokuje swoj\u0105 w\u0142asn\u0105 podsie\u0107. Kiedy zapora ogniowa zablokuje w\u0142asny klaster, zewn\u0119trzne interakcje b\u0119d\u0105 si\u0119 psu\u0107, a zas\u00f3b przestanie dzia\u0142a\u0107.
\nOsi\u0105gni\u0119cie blokady w\u0142asnej sieci nie jest trudne. Je\u015bli w biurze klienta istnieje sie\u0107 Wi-Fi, lub je\u015bli wydajno\u015b\u0107 zasob\u00f3w jest mierzona za pomoc\u0105 r\u00f3\u017cnych monitornik\u00f3w, to bierzemy adres IP tego systemu monitoruj\u0105cego lub biurowego klienta Wi-Fi i u\u017cywamy go jako \u017ar\u00f3d\u0142a. W rezultacie zas\u00f3b wydaje si\u0119 dost\u0119pny, ale docelowe adresy IP s\u0105 zablokowane. Tak wi\u0119c mo\u017ce by\u0107 zablokowana sie\u0107 Wi-Fi konferencji HighLoad, na kt\u00f3rej prezentowany jest nowy produkt firmy, co poci\u0105ga za sob\u0105 okre\u015blone koszty biznesowe i ekonomiczne.
\nPodczas testowania nie mo\u017cemy korzysta\u0107 z amplifikacji przez memcached zewn\u0119trznymi zasobami, poniewa\u017c istniej\u0105 umowy dotycz\u0105ce przesy\u0142ania ruchu tylko do dozwolonych adres\u00f3w IP. W zwi\u0105zku z tym u\u017cywamy amplifikacji przez SYN i SYN-ACK, kiedy na wys\u0142anie jednego SYN system odpowiada dwoma lub trzema SYN-ACK, a w rezultacie atak zwi\u0119ksza si\u0119 dwa lub trzy razy. <\/p>\n

Narz\u0119dzia<\/h3>\n

\nJednym z podstawowych narz\u0119dzi, kt\u00f3re wykorzystujemy do obci\u0105\u017cenia na poziomie L7, jest Yandex-tank. W szczeg\u00f3lno\u015bci jako bro\u0144 u\u017cywany jest Phantom, plus istnieje kilka skrypt\u00f3w do generowania pocisk\u00f3w i analizy wynik\u00f3w.
\nDo analizy ruchu sieciowego u\u017cywamy Tcpdump, do analizy serwera \u2014 Nmap. Do generowania obci\u0105\u017cenia na poziomie L3&4 u\u017cywamy OpenSSL i troch\u0119 w\u0142asnej magii z bibliotek\u0105 DPDK. DPDK to biblioteka od Intela, kt\u00f3ra pozwala na prac\u0119 z interfejsem sieciowym, omijaj\u0105c stos Linux, co zwi\u0119ksza efektywno\u015b\u0107. Oczywi\u015bcie, DPDK stosujemy nie tylko na poziomie L3&4, ale tak\u017ce na poziomie L7, poniewa\u017c umo\u017cliwia ona generowanie bardzo du\u017cego przep\u0142ywu obci\u0105\u017cenia, do kilku milion\u00f3w zapyta\u0144 na sekund\u0119 z jednego komputera.
\nU\u017cywamy r\u00f3wnie\u017c okre\u015blonych generator\u00f3w ruchu i specjalnych narz\u0119dzi, kt\u00f3re piszemy pod specyficzne testy. Je\u015bli przypomnimy sobie o podatno\u015bci pod SSH, to podany powy\u017cej zestaw nie mo\u017ce by\u0107 wyeksploatowany. Je\u015bli atakujemy protok\u00f3\u0142 pocztowy, korzystamy z narz\u0119dzi pocztowych lub piszemy na nie skrypty.<\/p>\n

\n

Wnioski<\/h3>\n

\nNa koniec chcieliby\u015bmy powiedzie\u0107:<\/p>\n