Szerokiej gamie ataków opierających się na HTTP można (i powinno się) zapobiegać już z poziomu aplikacji. Lista OWASP Top 10 jest najlepszym przykładem technik ataków, które można zarówno wykrywać, jak i zapobiegać im na tym poziomie. Istnieje mnóstwo narzędzi, w tym do analizy statycznej i dynamicznej czy testów penetrujących, mających za zadanie zapewnić, że podatnosci zostaną wychwycone w odpowiednim momencie i nie przejdą do fazy produkcyjnej. Oczywiście to wszystko pod warunkiem, że testy te zostały wykonane zgodnie z praktyką, polegającą na integracji bieżących zmian w procesie CI/CD, zamiast bycia ostatnim etapem przed oddaniem produktu w ręce użytkowników.

 

Nawet jeśli udało się wyeliminować wszystkie potencjalne luki w procesie tworzenia oprogramowania, aplikacje nadal mogą być zagrożone. Dzieje się tak ponieważ niektóre ataki nie mogą być wykryte z poziomu aplikacji. W gruncie rzeczy, zanim taki atak dosięgnie aplikację jest już za późno.

Mowa o atakach DDoS na poziomie warstwy aplikacyjnej (HTTP). Tak, właśnie tych, które w niemalże wampiryczny sposób wykorzystując protokół HTTP, wysysają zasoby pamięciowe i obliczeniowe aplikacji, czyniąc ją tym samym bezużyteczną dla użytkowników.

Istnieją dwa typy ataków DDoS: szybki i wolny. Zalewanie dużą ilością pakietów (flooding) oraz wysycanie zasobów.

Atak flooding

Polega na wykorzystaniu faktu, że aplikacje mają za zadanie przyjmować zapytania HTTP i odpowiadać na nie. Po to właśnie zostały stworzone czyż nie? Robią więc to, niezależnie od szybkości, z jaką zapytania napływają. Nawet jeśli dzieje się to w tempie blokującym dostępne zasoby w ciągu minut czy sekund – aplikacja wciąż stara się odpowiedzieć. Każda aplikacja (urządzenie, usługa, system itp.) ma określony limit połączeń TCP, które może nawiązać. Po przekroczeniu tej liczby jest to po prostu niemożliwe, a dalsze zapytania są ignorowane. Użytkownicy spotykają się z taką sytuacją przy okazji napotkania komunikatu „Próba połączenia…”, ponieważ wtedy ich przeglądarka lub aplikacja oczekuje określoną ilość czasu, by następnie przeprosić za brak możliwości połączenia.

Ten rodzaj ataku może nastąpić tak szybko, że przewyższy zdolność systemu do oszacowania skali żądania. Nawet autoskalowanie niewiele tu pomoże, bo czas potrzebny do ustanowienia i wdrożenia nowych instancji dla aplikacji jest większy niż czas potrzebny by ogołocić istniejące instancje zasobów.

Atak wysycający

Z drugiej strony ¬– atak wysycający – ma taki sam cel, jednak wykonuje go poprzez wymuszenie na aplikacji utrzymywania otwartego połączenia dłużej niż rzeczywiście jest to potrzebne. Robi to udając, że jest w trakcie połączenia; przesyłając niewielkie ilości danych z aplikacji w ciągu sekundy zamiast w pełni wykorzystywać dostępne możliwości. Takie działanie sprawia, że połączenie trwa dłużej, a jeżeli zostanie nawiązane wystarczająco dużo połączeń, sprawia to, podobnie jak w ataku blokującym – wyczerpywanie się zasobów. Żadnego z tych ataków nie da się wykryć z poziomu aplikacji. Dlaczego miało by się dać? Dla aplikacji, te żądania są poprawne. Są to dobrze zbudowane, oparte na HTTP żądania dostępu do danych, na które udzielanych jest tysiące odpowiedzi dziennie. Przy żądaniu HTTP nie ma żadnej flagi lub bloków danych, które wskazują na jego podstępną naturę. Aplikacja nie widzi złośliwych intencji, które kryją się za tymi żądaniami, ponieważ nie posiada ona wglądu do sieci lub do szerszego środowiska – w szczególności do tabeli sesji serwera, która zawiera listę wszystkich otwartych połączeń. Nawet pomijając kwestie techniczne związane z wątkami, procesami czy zmiennością danych w wielowątkowych środowiskach, warto skupić się na „braku wglądu w przetwarzanie innych żądań.”

Wystarczy powiedzieć, że aplikacja sama w sobie nie jest w stanie stwierdzić czy któreś z żądań jest częścią większego ataku (atak flooding) czy spowoduje przydzielenie zbyt dużej ilości zasobów powodując ich wysycanie.

Proxy na ratunek

Tym, co ma wgląd w oba źródła, jest proxy, które jest umieszczone przed aplikacją. Dzieje się tak, gdyż proxy dokonuje równoważenia obciążenia (ang. load balancing), a zatem musi zwracać uwagę na liczbę żądań, które są aktualnie przetwarzane jak również na te, które nadchodzą, gdyż musi je wysłać do jednej z aplikacji, znajdujących się w grupie (w klastrze). Co więcej, musi również wiedzieć gdzie wysłać odpowiedź, więc musi posiadać informacje dotyczące klienta oraz jego połączenia sieciowego (zazwyczaj do aplikacji jest wysyłany tylko adres IP klienta). W odróżnieniu od aplikacji, ma on wgląd, który pozwala zauważyć zarówno atak wysycający jak i blokujący oraz powstrzymać je zanim zdążą zanurzyć swoje kły w zasobach aplikacji.

Dlatego usługi oparte o proxy, takie jak WAF (Web Application Firewall) lub nawet zaawansowany load balancer to kluczowe elementy współczesnej strategii ochrony aplikacji. Ponieważ mają one odpowiedni wgląd, oznacza to, że mogą wykryć anomalie związane z zachowaniem się ataku i powstrzymać go, tak jak czosnek powstrzymuje wampira. Ponieważ te tradycyjne usługi „sieciowe” powinny stać się częścią architektury aplikacyjnej, wydaje się być logiczne, że podejście DevOps powinno rozciągnąć swoje skrzydła i wziąć pod nie te usługi, które w naturalny sposób zmierzają w stronę aplikacji, takie jak bezpieczeństwo aplikacji i skalowalność (równoważenie obciążenia).

Aplikacje nie są w stanie zatrzymać każdego ataku, a w szczególności tego, który wymaga wglądu na poziomie, który nie jest dla nich dostępny. Współpraca z takimi usługami aplikacyjnymi jak webowa ochrona aplikacji i równoważenie obciążenia, może sprawić, że bardziej kompleksowa lista ataków będzie mogła zostać zidentyfikowana i powstrzymana, zapewniając mniejszą liczbę włamań i awarii.

Autor: Ireneusz Wiśniewski, Country Manager Poland, F5 Networks