W ostatnich tygodniach Anonimowi, niezadowoleni z faktu podpisania przez Polskę umowy ACTA, DDoS-owali polskie strony rządowe. DDoS polega na zalewaniu serwerów na tyle dużą liczbą żądań, aby serwer lub łącze, do którego jest on podpięty, nie było w stanie ich obsłużyć.

Ponieważ ataki DDoS są stosunkowo łatwe do przeprowadzenia (czasem wystarczy skrzyknąć kilkadziesiąt osób i namówić je do jedoczesnego wejścia na daną stronę) celem może być każdy — nie tylko serwisy polityczne. Zastanówmy się więc, co można zrobić, aby zminimalizować skutki ataków DDoS?

    1. Zoptymalizuj swoją stronę. Im mniej zapytań do bazy danych i im mniej zasobów pobieranych z twoich serwerów podczas “wizyty” na twojej stronie, tym lepiej. Mniej połączeń praktycznie zawsze oznacza mniejsze obciążenie dla serwera. Niestety, załadowanie niektórych stron WWW zajmuje kilka sekund i prowadzi do pobrania kilku MB danych z kilkudziesięciu zasobów…

    2. Statyczne treści (obrazki, skrypty js, arkusze stylów, pliki PDF) wystaw przy pomocy osobnego serwera, tzw. CDN (content delivery network). Zasada działania CDN jest prosta — dane serwowane są z zewnętrznej lokalizacji, bliższej internaucie, który o nie “pyta”. Jak to się dzieje? DNS-y podczas rozwiązywania domeny CDN odpowiadają adresami IP najbliższymi w stosunku do zadającego pytanie. Ktoś z Rosji pobierze twój obrazek z innego serwera niż ktoś z Niemiec. Podczas DDoS-u, ruch rozłoży się więć na kilka serwerów…

    3. Rozważ CDN dla całego serwisu. Istnieją tanie rozwiązania takie jak Akamai, Amazon czy darmowy Cloudflare.

    4. Zastanów się nad loadbalancingiem. Krótko mówiąc, skaluj moc obliczeniową swoich serwerów. Żądanie zanim trafi do webserwera jest przechwytywane przez loadbalancer, który następnie decyduje do którego webserwera z farmy (klastra) je przekazać. Wybierane są serwery najmniej obciążone. Dodatkowo, w razie piku w ruchu, można w “przeźroczysty” sposób dostawić kolejne instancje serwerów.

    5. Skaluj łącze. Dynamiczny routing i kilka niezależnych łącz może pomóc w trakcie ataków DDoS. Problem w tym, że odpowiednie zarządzanie łączami (dynamicznym routingiem) wymaga fachowej wiedzy. Zazwyczaj lepiej zostawić te kwestie swojemu dostawcy hostingu.

    6. Rozdziel usługi. DDoS-y z reguły dotykają stron WWW. Jeśli w na tym samym serwerze co serwis internetowy trzymałeś także pocztę e-mail… no cóż, będzie ona niedostępna. Lepiej zawczasu rozdzielić te dwie usługi, m.in. po to, aby w trakcie ataków DDoS mieć e-mailowy kontakt ze swoimi klientami. Wartym rozważenia rozwiązaniem jest delegacja obsługi poczty do darmowej chmury Google Apps.

    7. Ustal alternatywny kanał komunikacji, np. Facebook. Przyzwyczajaj swoich użytkowników do swojej obecności także na innych platfromach, np. w sieci społecznościowej Facebook lub na Twitterze. Kiedy strona nie będzie działać, automatycznie część z nich spróbuje dowiedzieć się co się dzieje z Twojego fanpage — a zddosować Facebooka jest naprawdę ciężko. Z praktyki tej korzysta m.in. TVN24 w czasie usterek swoich serwisów — pomimo awarii serwerów dalej dodają nowe wiadomości na Facebooka.

I na koniec — jeśli przytrafi się Wam DDoS, nie panikujcie. Ataki te nie trwają zazwyczaj długo (koszt). Czas downtime’u strony WWW przeznaczcie na odpisanie na zaległe e-maile. Bo przecież rozdzieliliście już pocztę od serwera WWW, prawda? :-)

Chcesz przetestować swoją sieć kontrolowanym atakiem DDoS?

Na marginesie, od początku tego roku, do naszej komercyjnej oferty usług związanych z testowaniem bezpieczeństwa sieci komputerowych dołączyliśmy testy obciążeniowe będące symulacją ataku DDoS (zarówno w podejściu wolumetrycznym jak i aplikacyjnym).

Jesteśmy w stanie za wygenerować ruch o charakterystyce następujących ataków: SYN Flood, ICMP Flood, UDP Flood, HTTP(S) Connect, HTTP(S) Post, SSL Handshake (exhaustion/renegotiation), oraz inne (do ustalenia). W trakcie ataków możliwe jest dowolne “spoofowanie” pól pakietu/datagramu (np. pól z adresem źródłowym). Zainteresowanych zapraszamy do kontaktu, ale przestrzegamy, że w przypadku klientów nieposiadających własnej serwerowni i łączy, czyli korzystających z cudzego hostingu wymagamy przedstawienia zgody na testy podpisanej także przez firmę hostingową ;-)