Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

W naszym poprzednim materiale na temat chmur, my powiedział, jak chronić zasoby IT w chmurze publicznej i dlaczego tradycyjne antywirusy nie do końca nadają się do tych celów. W tym poście będziemy kontynuować temat bezpieczeństwa w chmurze i porozmawiamy o ewolucji WAF i tym, co lepiej wybrać: sprzęt, oprogramowanie czy chmurę. 

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Co to jest WAF

Ponad 75% ataków hakerów ma na celu luki w aplikacjach i witrynach internetowych: takie ataki są zwykle niewidoczne dla infrastruktury bezpieczeństwa informacji i usług bezpieczeństwa informacji. Luki w aplikacjach internetowych niosą z kolei ryzyko włamania i oszustwa w zakresie kont użytkowników, danych osobowych, haseł i numerów kart kredytowych. Ponadto luki w zabezpieczeniach witryny internetowej stanowią punkt wejścia dla atakujących do sieci korporacyjnej.

Web Application Firewall (WAF) to ekran ochronny, który blokuje ataki na aplikacje internetowe: wstrzykiwanie SQL, wykonywanie skryptów między witrynami, zdalne wykonanie kodu, brute force i obejście autoryzacji. W tym ataki wykorzystujące luki dnia zerowego. Zapory sieciowe aplikacji zapewniają ochronę, monitorując zawartość stron internetowych, w tym HTML, DHTML i CSS, oraz filtrując potencjalnie złośliwe żądania HTTP/HTTPS.

Jakie były pierwsze decyzje?

Pierwsze próby stworzenia zapory aplikacji sieciowych miały miejsce już na początku lat 90-tych. Wiadomo, że co najmniej trzech inżynierów pracowało w tej dziedzinie. Pierwszym z nich jest profesor informatyki Gene Spafford z Purdue University. Opisał architekturę zapory aplikacji proxy i opublikował ją w 1991 roku w książce „Bezpieczeństwo UNIX w praktyce”.

Drugim i trzecim byli specjaliści ds. bezpieczeństwa informacji William Cheswick i Marcus Ranum z Bell Labs. Opracowali jeden z pierwszych prototypów zapory aplikacyjnej. Dystrybucją zajmowała się firma DEC – produkt został wydany pod nazwą SEAL (Secure Outside Access Link).

Ale SEAL nie był pełnoprawnym rozwiązaniem WAF. Był to klasyczny firewall sieciowy z zaawansowaną funkcjonalnością - możliwością blokowania ataków na FTP i RSH. Z tego powodu za pierwsze dziś rozwiązanie WAF uważa się produkt firmy Perfecto Technologies (później Sanctum). Ona w 1999r представила System AppShield. W tym czasie Perfecto Technologies rozwijało rozwiązania z zakresu bezpieczeństwa informacji dla e-commerce, a docelową grupą odbiorców ich nowego produktu stały się sklepy internetowe. AppShield był w stanie analizować żądania HTTP i blokowane ataki w oparciu o dynamiczne zasady bezpieczeństwa informacji.

Mniej więcej w tym samym czasie co AppShield (w 2002 r.) pojawił się pierwszy WAF typu open source. On został ModSecurity. Powstał z myślą o popularyzacji technologii WAF i do dziś cieszy się wsparciem społeczności IT (tutaj jest repozytorium na GitHubie). ModSecurity blokuje ataki na aplikacje w oparciu o standardowy zestaw wyrażeń regularnych (podpisów) - narzędzia do sprawdzania żądań na podstawie wzorców - Podstawowy zestaw reguł OWASP.

W rezultacie twórcom udało się osiągnąć swój cel - na rynku zaczęły pojawiać się nowe rozwiązania WAF, w tym te zbudowane w oparciu o ModSecurity.

Trzy pokolenia to już historia

Zwyczajowo wyróżnia się trzy generacje systemów WAF, które ewoluowały wraz z rozwojem technologii.

Pierwsza generacja. Działa z wyrażeniami regularnymi (lub gramatykami). Obejmuje to ModSecurity. Dostawca systemu bada rodzaje ataków na aplikacje i generuje wzorce opisujące uzasadnione i potencjalnie złośliwe żądania. WAF sprawdza te listy i decyduje, co zrobić w konkretnej sytuacji – zablokować ruch, czy nie.

Przykładem detekcji opartej na wyrażeniach regularnych jest wspomniany już projekt Podstawowy zestaw zasad otwarte źródło. Inny przykład - Naksi, który również jest oprogramowaniem typu open source. Systemy z wyrażeniami regularnymi mają szereg wad, w szczególności w przypadku wykrycia nowej luki administrator musi ręcznie utworzyć dodatkowe reguły. W przypadku infrastruktury IT o dużej skali może istnieć kilka tysięcy reguł. Zarządzanie tak dużą liczbą wyrażeń regularnych jest dość trudne, nie mówiąc już o tym, że ich sprawdzanie może zmniejszyć wydajność sieci.

Wyrażenia regularne mają również dość wysoki współczynnik wyników fałszywie dodatnich. Słynny językoznawca Noam Chomsky zaproponował klasyfikację gramatyk, w której podzielił je na cztery warunkowe poziomy złożoności. Zgodnie z tą klasyfikacją wyrażenia regularne mogą opisywać jedynie reguły zapory sieciowej, które nie zawierają odchyleń od wzorca. Oznacza to, że atakujący mogą łatwo „oszukać” WAF pierwszej generacji. Jedną z metod zwalczania tego problemu jest dodanie do żądań aplikacji znaków specjalnych, które nie wpływają na logikę złośliwych danych, ale naruszają zasadę podpisu.

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Druga generacja. Aby obejść problemy z wydajnością i dokładnością WAF, opracowano zapory aplikacyjne drugiej generacji. Mają teraz parsery odpowiedzialne za identyfikowanie ściśle określonych typów ataków (na HTML, JS itp.). Parsery te współpracują ze specjalnymi tokenami opisującymi zapytania (na przykład zmienna, ciąg znaków, nieznane, liczba). Potencjalnie złośliwe sekwencje tokenów umieszczane są na osobnej liście, którą system WAF regularnie sprawdza. Podejście to zostało po raz pierwszy zaprezentowane na konferencji Black Hat 2012 w formie C/C++ biblioteki libinjection, co pozwala wykryć zastrzyki SQL.

W porównaniu do WAF pierwszej generacji wyspecjalizowane parsery mogą być szybsze. Nie rozwiązały one jednak trudności związanych z ręczną konfiguracją systemu w przypadku pojawienia się nowych złośliwych ataków.

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Trzeciej generacji. Ewolucja logiki detekcji trzeciej generacji polega na zastosowaniu metod uczenia maszynowego, które pozwalają maksymalnie zbliżyć gramatykę detekcji do rzeczywistej gramatyki SQL/HTML/JS chronionych systemów. Ta logika wykrywania jest w stanie dostosować maszynę Turinga do obsługi gramatyk rekurencyjnie przeliczalnych. Co więcej, wcześniej zadanie stworzenia adaptowalnej maszyny Turinga było nie do rozwiązania, dopóki nie opublikowano pierwszych badań neuronowych maszyn Turinga.

Uczenie maszynowe zapewnia wyjątkową możliwość dostosowania dowolnej gramatyki do każdego rodzaju ataku bez ręcznego tworzenia list sygnatur zgodnie z wymogami wykrywania pierwszej generacji i bez opracowywania nowych tokenizatorów/parserów dla nowych typów ataków, takich jak zastrzyki Memcached, Redis, Cassandra, SSRF , zgodnie z wymogami metodologii drugiej generacji.

Łącząc wszystkie trzy generacje logiki detekcji, możemy narysować nowy diagram, na którym trzecia generacja detekcji jest oznaczona czerwoną obwódką (Rysunek 3). Do tej generacji zalicza się jedno z rozwiązań, które wdrażamy w chmurze wspólnie z firmą Onsek, twórcą platformy do adaptacyjnej ochrony aplikacji webowych oraz API Wallarm.

Logika wykrywania wykorzystuje teraz informacje zwrotne z aplikacji do automatycznego dostrojenia. W uczeniu maszynowym tę pętlę informacji zwrotnej nazywa się „wzmocnieniem”. Zazwyczaj istnieje jeden lub więcej rodzajów takiego zbrojenia:

  • Analiza zachowania odpowiedzi aplikacji (pasywna)
  • Skanowanie/fuzzer (aktywny)
  • Zgłoś pliki/procedury/pułapki przechwytujące (po fakcie)
  • Podręcznik (określony przez przełożonego)

W rezultacie logika wykrywania trzeciej generacji uwzględnia również ważną kwestię dokładności. Obecnie możliwe jest nie tylko uniknięcie fałszywych alarmów i fałszywych negatywów, ale także wykrycie prawidłowych, prawdziwych negatywów, takich jak wykrycie użycia elementu polecenia SQL w Panelu sterowania, ładowanie szablonu strony internetowej, żądania AJAX związane z błędami JavaScript i inne.

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Następnie rozważymy możliwości technologiczne różnych opcji wdrożenia WAF.

Sprzęt, oprogramowanie czy chmura – co wybrać?

Jedną z opcji wdrożenia zapór aplikacyjnych jest rozwiązanie sprzętowe. Systemy takie to wyspecjalizowane urządzenia obliczeniowe, które firma instaluje lokalnie w swoim centrum danych. Ale w tym przypadku trzeba kupić własny sprzęt i zapłacić integratorom za jego skonfigurowanie i debugowanie (jeśli firma nie ma własnego działu IT). Jednocześnie każdy sprzęt staje się przestarzały i bezużyteczny, więc klienci zmuszeni są przeznaczyć budżet na modernizację sprzętu.

Inną opcją wdrożenia WAF jest implementacja oprogramowania. Rozwiązanie jest instalowane jako dodatek do niektórych programów (na przykład ModSecurity jest konfigurowany na Apache) i działa z nim na tym samym serwerze. Z reguły takie rozwiązania można wdrożyć zarówno na serwerze fizycznym, jak i w chmurze. Ich wadą jest ograniczona skalowalność i wsparcie ze strony dostawców.

Trzecią opcją jest skonfigurowanie WAF z chmury. Takie rozwiązania dostarczane są przez dostawców usług chmurowych w ramach usługi subskrypcyjnej. Firma nie musi kupować i konfigurować specjalistycznego sprzętu, te zadania spadają na barki usługodawcy. Co ważne, nowoczesna chmura WAF nie oznacza migracji zasobów na platformę dostawcy. Stronę można wdrożyć w dowolnym miejscu, nawet lokalnie.

Wyjaśnimy dalej, dlaczego ludzie coraz częściej zwracają się ku chmurze WAF.

Co WAF może zrobić w chmurze

Pod względem możliwości technologicznych:

  • Dostawca jest odpowiedzialny za aktualizacje. WAF jest udostępniany w ramach subskrypcji, więc usługodawca monitoruje ważność aktualizacji i licencji. Aktualizacje dotyczą nie tylko oprogramowania, ale także sprzętu. Dostawca unowocześnia park serwerów i utrzymuje go. Odpowiada także za równoważenie obciążenia i redundancję. Jeśli serwer WAF ulegnie awarii, ruch jest natychmiast przekierowywany na inną maszynę. Racjonalna dystrybucja ruchu pozwala uniknąć sytuacji, gdy zapora sieciowa przechodzi w tryb Fail Open – nie radzi sobie z obciążeniem i przestaje filtrować żądania.
  • Wirtualne łatanie. Wirtualne łaty ograniczają dostęp do zaatakowanych części aplikacji, dopóki programista nie usunie luki. Dzięki temu klient dostawcy chmury ma możliwość spokojnie poczekać, aż dostawca tego czy innego oprogramowania opublikuje oficjalne „łatki”. Priorytetem dla dostawcy oprogramowania jest zrobienie tego tak szybko, jak to możliwe. Przykładowo w platformie Wallarm za wirtualne patchowanie odpowiada osobny moduł oprogramowania. Administrator może dodać niestandardowe wyrażenia regularne, aby blokować złośliwe żądania. System umożliwia oznaczenie niektórych żądań flagą „Dane poufne”. Wówczas ich parametry są maskowane i w żadnym wypadku nie są przesyłane poza obszar pracy firewalla.
  • Wbudowany skaner obwodowy i podatności na zagrożenia. Pozwala to na samodzielne określenie granic sieciowych infrastruktury IT przy wykorzystaniu danych z zapytań DNS i protokołu WHOIS. Następnie WAF automatycznie analizuje usługi działające wewnątrz obwodu (wykonuje skanowanie portów). Zapora sieciowa jest w stanie wykryć wszystkie popularne typy podatności - SQLi, XSS, XXE itp. - oraz zidentyfikować błędy w konfiguracji oprogramowania, np. nieautoryzowany dostęp do repozytoriów Git i BitBucket oraz anonimowe wywołania do Elasticsearch, Redis, MongoDB.
  • Ataki są monitorowane przez zasoby w chmurze. Z reguły dostawcy usług chmurowych dysponują dużą mocą obliczeniową. Pozwala to analizować zagrożenia z dużą dokładnością i szybkością. W chmurze wdrażany jest klaster węzłów filtrujących, przez który przechodzi cały ruch. Węzły te blokują ataki na aplikacje internetowe i wysyłają statystyki do Centrum analitycznego. Wykorzystuje algorytmy uczenia maszynowego do aktualizacji reguł blokowania dla wszystkich chronionych aplikacji. Implementację takiego schematu pokazano na ryc. 4. Tak dostosowane zasady bezpieczeństwa minimalizują liczbę fałszywych alarmów firewalla.

Ewolucja zapory aplikacji internetowych: od zapór ogniowych po systemy ochrony w chmurze z uczeniem maszynowym

Teraz trochę o cechach chmurowych WAF-ów pod kątem zagadnień organizacyjnych i zarządzania:

  • Przejście na OpEx. W przypadku chmurowych WAF-ów koszt wdrożenia wyniesie zero, gdyż dostawca opłacił już cały sprzęt i licencje, a płatność za usługę odbywa się w formie abonamentu.
  • Różne plany taryfowe. Użytkownik usługi chmurowej może szybko włączyć lub wyłączyć dodatkowe opcje. Zarządzanie funkcjami odbywa się z jednego panelu sterowania, który jest również bezpieczny. Dostęp do niego odbywa się poprzez HTTPS, a ponadto istnieje dwuskładnikowy mechanizm uwierzytelniania oparty na protokole TOTP (Time-Based One-Time Password Algorithm).
  • Połączenie przez DNS. Możesz samodzielnie zmienić DNS i skonfigurować routing sieciowy. Aby rozwiązać te problemy, nie ma potrzeby rekrutacji i szkolenia indywidualnych specjalistów. Z reguły pomoc techniczna dostawcy może pomóc w konfiguracji.

Technologie WAF ewoluowały od prostych zapór sieciowych z praktycznymi zasadami do złożonych systemów ochrony z algorytmami uczenia maszynowego. Zapory aplikacyjne oferują obecnie szeroką gamę funkcji, które były trudne do wdrożenia w latach 90-tych. Pod wieloma względami pojawienie się nowych funkcjonalności stało się możliwe dzięki technologiom chmurowym. Rozwiązania WAF i ich komponenty stale ewoluują. Podobnie jak inne obszary bezpieczeństwa informacji.

Tekst przygotował Alexander Karpuzikov, menedżer ds. rozwoju produktów związanych z bezpieczeństwem informacji u dostawcy usług w chmurze #CloudMTS.

Źródło: www.habr.com

Dodaj komentarz