Ataki distributed denial of service są jednym z tych zagrożeń, przed którymi nie da się chronić jedynie za pomocą rozwiązań technicznych i w momencie ich wystąpienia.

Co prawda każda z dostępnych obecnie na rynku zapór sieciowych ma funkcję "obrony przed atakami DoS" ale w praktyce lekarstwo jest gorsze od choroby - co mogliśmy w praktyce obserwować podczas trwających ponad tydzień ataków na strony rządowe na początku 2012 roku. Ochrona ta polega bowiem na blokowaniu części ruchu, który wykracza poza ustalony poziom "normalny" albo "wygląda podejrzanie". Rezultat jest więc taki, że tak czy inaczej część żądań wysyłanych w dobrej wierze jest odrzucana.

Zobacz również:

• Ministerstwo Cyfryzacji ostrzega przed rosnącym zagrożeniem atakami DDoS

W przypadku MKiDN moment uruchomienia zapory sieciowej można było poznać po tym, że zamiast "po prostu wisieć", strona ministerstwa odpowiadała uprzejmym komunikatem, że ze względu na rzekomy atak, jakiego dopuszcza się przeglądający stronę jego żądanie zostało zablokowane.

Tymczasem z punktu widzenia właściciela serwisu atak DDoS niewiele różni się od pozbawionych cech złośliwości zjawisk znanych jako efekt Slashdota, w Polsce częściej występującego jako efekt Wykopu.

W szczególności ze zjawiskami tego typu nie da się "walczyć" w sensie podejmowania rozmaitych działań po ich wystąpieniu. Jeśli celem serwisu jest udostępnianie jakiejś informacji to jej blokowanie jest z tym celem sprzeczne.

Ciekawym przykładem jest ZUS, który praktycznie od początku udostępniania Programu Płatnika przez Internet cyklicznie doświadczał "ataku DDoS" po pojawieniu się każdej kolejnej wersji (Doroczne pretensje wobec ZUS i Płatnika). Inne tego typu "ataki" opisywałem także w 2007 roku (Jak walczyć z cyberterroryzmem?).

Tymczasem jest to zjawisko od lat doskonale znany firmom udostępniającym przez Internet "ciężkie" - w sensie objętościowym - treści: filmy, zdjęcia, pliki, sterowniki, aplikacje itd. Ciągłość działania takich serwisów da się utrzymać jedynie przez rozproszenie zasobów.

I tutaj technologia oferuje nam bardzo szeroki zakres usług. W przypadku ataków DDoS sprawa jest właściwie nawet prostsza, bo złośliwe ataki DDoS są zwykle incydentami jednorazowymi, nawet jeśli trwają tydzień czy dwa. Tymczasem wymienione serwisy znajdują się praktycznie w stanie "permanentnego DDoS".

Co zatem mogą zrobić operatorzy serwisów narażonych w niedalekiej perspektywie atakiem DDoS lub przejściowym zwiększeniem obciążenia (np. ze względu na zawirowania polityczne lub potencjalny skok zainteresowania)?

Operatorzy serwisów, których przejściowo ograniczona dostępność nie stanowi wielkiej tragedii powinni zadbać o stworzenie kopii serwisu produkcyjnego (mirror) oraz wersji minimum - statycznej, zawierającej tylko te informacje, które muszą być dostępne.

W razie ataku pozwala to na podjęcie szeregu działań ograniczających straty - wystawienie kopii pod innym adresem i podmianę pełnej, dynamicznej wersji atakowanego serwisu na wersję "minimum", która może odsyłać do kopii. Albo w ogóle pozostawienie tylko wersji minimum - w ten sposób poradził sobie autor popularnego narzędzia do wykrywania rootkitów (Gmer.net), na którego stronę skierowano potężny DDoS w 2007 roku.

A trzeba pamiętać, że atak DDoS to nie tylko obciążenie dla łącza ale także dla aplikacji webowej, która obsługuje daną stronę. W jednym ze skrajnych przypadków, z którym się zetknąłem w przeszłości coś co zostało zgłoszone jako atak DDoS było w rzeczywistości obciążeniem powodowanym przez jeden (!) źle napisany skrypt PHP generujący reklamy. W przypadku ataku DDoS zastąpienie dynamicznej strony głównej statycznym plikiem HTML bez obrazków skutkuje zarówno odciążeniem serwera, jak i pozwala wykorzystać całe dobrodziejstwo licznych systemów keszowania (na serwerach proxy, w przeglądarkach, w wyszukiwarkach), które są zwykle ograniczane przez strony dynamiczne w celu zagwarantowania, że pokazywana jest najświeższa wersja strony. W przypadku ataku DDoS niewątpliwie lepiej jednak jest pokazać niekoniecznie najświeższą wersję strony niż żadną.

Operatorzy serwisów o znaczeniu z różnych powodów krytycznym powinni z kolei rozważyć wykorzystanie technologii rozpraszania danych, znanych ogólnie jako technologie CDN (content delivery network). Wśród nich można znaleźć także takie, które są zaprojektowane przede wszystkim celu ochrony przed atakami DDoS (Verizon, Akamai). Są to zwykle usługi przeznaczone dla odbiorców instytucjonalnych i w skali bezwzględnej dość kosztowne.

Z drugiej strony, by przywołać opisany powyżej przypadek Programu Płatnika, najprostszą usługę CDN polegającą na wystawieniu ograniczonej liczby plików pod "rozproszonym" adresem usługodawcy można wykupić już za kilkaset złotych miesięcznie. Co więcej, nic nie stoi na przeszkodzie by wystawić go tam tylko na czas prognozowanego zwiększonego zainteresowania, a potem przywrócić link do wersji przechowywanej na własnym serwerze.

Ze względu na konieczność działań wyprzedzających i niekiedy konieczność poniesienia dodatkowych kosztów ochrona przed atakami DDoS musi charakter strategiczny. W każdej większej organizacji istnieją procesy, które są doskonałym miejscem na uwzględnienie charakterystyki ataków DDoS - są to plany ciągłości działania (BCP - business continuity plan).

Ponieważ zespoły zajmujące się BCP nie posiadają zwykle pełni kompetencji pozwalających na szczegółową analizę aspektów technicznych , muszą być one w tym wspierane przez zespoły zajmujące się bezpieczeństwem teleinformatycznym. Równocześnie jednak "gospodarzem" ochrony przed atakami DDoS powinien być jednak zespoły BCP, bo to właśnie one dysponują narzędziami (BIA - business impact analysis) niezbędnymi do wyznaczenia właściwiego poziomu ochrony, a co za tym idzie środków technicznych jakich stosowanie w każdym przypadku będzie miało sens.