W naszym poprzednim materiale na temat chmur mówiliśmy, , jak chronić zasoby IT w publicznej chmurze i dlaczego tradycyjne programy antywirusowe nie są do tego do końca odpowiednie. W tym wpisie kontynuujemy temat bezpieczeństwa w chmurze i omówimy ewolucję WAF oraz co lepiej wybrać: sprzęt, oprogramowanie czy chmurę.
Czym jest WAF
Ponad 75% ataków hakerów skierowanych jest na luki w aplikacjach internetowych i stronach: takie ataki są zazwyczaj niedostrzegane przez infrastrukturę i usługi bezpieczeństwa informacji. Luki w aplikacjach internetowych niosą ze sobą ryzyko kompromitacji i oszustw związanych z kontami oraz danymi osobowymi użytkowników, hasłami i numerami kart kredytowych. Ponadto, luki na stronie internetowej stanowią punkt wejścia dla cyberprzestępców do sieci korporacyjnej.
Web Application Firewall (WAF) to ekran ochronny, który blokuje ataki na aplikacje internetowe: SQL injection, cross-site scripting, zdalne wykonywanie kodu, ataki brute-force i bypassowanie autoryzacji. W tym również ataki wykorzystujące luki zero-day. Zapory aplikacyjne zapewniają ochronę poprzez monitorowanie treści stron internetowych, w tym HTML, DHTML i CSS, oraz filtrowanie potencjalnie szkodliwych żądań po HTTP/HTTPS.
Jakie były pierwsze rozwiązania?
Pierwsze próby stworzenia Web Application Firewall podejmowano już na początku lat 90. Znamy co najmniej trzech inżynierów, którzy pracowali w tej dziedzinie. Pierwszym był profesor informatyki Gene Spafford z Uniwersytetu Purdue. Opisał on architekturę zapory aplikacyjnej z proxy i w 1991 roku opublikował ją w książce .
Drugim i trzecim byli specjaliści ds. bezpieczeństwa informacji William Cheswick i Marcus Ranum z Bell Labs. Opracowali oni jeden z pierwszych prototypów zapór aplikacyjnych. Rozpowszechniało go przedsiębiorstwo DEC — produkt został wydany pod nazwą SEAL (Secure External Access Link).
Jednak SEAL nie był pełnoprawnym rozwiązaniem WAF. Stanowił on klasyczną zaporę sieciową z rozszerzoną funkcjonalnością — możliwością blokowania ataków na FTP i RSH. Z tego powodu pierwszym rozwiązaniem WAF uznawanym dzisiaj jest produkt firmy Perfecto Technologies (później Sanctum). W 1999 roku firma ta system AppShield. At that time, Perfecto Technologies was developing cybersecurity solutions for e-commerce, and the target audience for their new product became online stores. AppShield could analyze HTTP requests and block attacks based on dynamic cybersecurity policies.
Around the same time as AppShield (in 2002), the first open-source WAF emerged. It became . It was created to promote WAF technologies and is still supported by the IT community (here is its ). ModSecurity blocks application attacks based on a standard set of regular expressions (signatures) — tools for checking requests against a pattern — .
As a result, the developers succeeded in their goal — new WAF solutions began to appear on the market, including those built on ModSecurity.
Three generations — now that’s history
It is customary to distinguish three generations of WAF systems, which have evolved with the development of technologies.
The first generation. It works with regular expressions (or grammars). This includes ModSecurity. The system provider studies the types of attacks on applications and creates patterns that describe legitimate and potentially malicious requests. The WAF checks these lists and decides what to do in a particular situation — whether to block the traffic or not.
An example of detection based on regular expressions is the aforementioned project open source. Another example is , which is also open-source. Systems using regular expressions have a number of drawbacks, particularly when a new vulnerability is discovered, the administrator has to manually create additional rules. In the case of a large IT infrastructure, there could be thousands of rules. Managing such a large number of regular expressions is quite difficult, not to mention that checking them can reduce network performance.
Wyrażenia regularne mają również dość wysoki poziom fałszywych alarmów. Słynny językoznawca Noam Chomsky zaproponował klasyfikację gramatyk, dzieląc je na cztery warunkowe poziomy trudności. Zgodnie z tą klasyfikacją, za pomocą wyrażeń regularnych można opisać jedynie reguły zapory ogniowej, które nie przewidują odstępstw od wzoru. Oznacza to, że napastnicy mogą łatwo "oszukać" zaporę WAF pierwszej generacji. Jedną z metod walki z tym jest dodanie do zapytań do aplikacji specjalnych symboli, które nie wpływają na logikę złośliwych danych, ale naruszają zasady sygnatur.
Druga generacja. Aby obejść problemy związane z wydajnością i dokładnością WAF, opracowano zapory aplikacji drugiej generacji. Pojawiły się w nich analizatory, które są odpowiedzialne za identyfikację ściśle określonych typów ataków (na HTML, JS itd.). Te analizatory pracują ze specjalnymi tokenami, opisującymi zapytania (np. zmienna, ciąg, nieznana, liczba). Potencjalnie złośliwe sekwencje tokenów są przenoszone na osobną listę, która jest regularnie porównywana z systemem WAF. Po raz pierwszy podejście to zaprezentowano na konferencji Black Hat 2012 w postaci biblioteki C/C++ , która pozwala na wykrywanie SQL injection.
W porównaniu z WAF pierwszej generacji, wyspecjalizowane analizatory mogą działać szybciej. Jednak nie rozwiązały one trudności związanych z ręczną konfiguracją systemu w przypadku nowych złośliwych ataków.
Trzecia generacja. Ewolucja w logice wykrycia trzeciej generacji polega na zastosowaniu metod uczenia maszynowego, które pozwalają jak najbardziej zbliżyć gramatykę wykrywania do rzeczywistej gramatyki SQL/HTML/JS chronionych systemów. Ta logika wykrywania jest w stanie dostosować maszynę Turinga do objęcia rekurencyjnie wyliczanych gramatyk. Co więcej, wcześniej zadanie stworzenia dostosowywalnej maszyny Turinga było nierozwiązywalne, aż do momentu opublikowania pierwszych badań nad neuronowymi maszynami Turinga.
Uczenie maszynowe daje unikalną możliwość dostosowania każdej gramatyki do różnych typów ataków bez ręcznego tworzenia list sygnatur, jakie były wymagane w detekcji pierwszej generacji, oraz bez opracowywania nowych tokenizatorów/parserów dla nowych typów ataków, takich jak ataki Memcached, Redis, Cassandra, SSRF, jak wymagano w drugiej generacji.
Łącząc wszystkie trzy pokolenia logiki detekcji, możemy narysować nowy diagram, na którym czerwonym konturem zaznaczone jest trzecie pokolenie detekcji (rys. 3). Do tego pokolenia należy jedno z rozwiązań, które wdrażamy w chmurze we współpracy z "OnSec", deweloperem platformy adaptacyjnej ochrony aplikacji internetowych i API Valarm.
Obecnie w logice detekcji wykorzystywana jest informacja zwrotna z aplikacji do automatycznej kalibracji. W ramach uczenia maszynowego ta pętla informacyjna nazywana jest "wzmocnieniem". Zwykle istnieje jeden lub kilka typów takiego wzmocnienia:
- Analiza zachowania odpowiedzi aplikacji (pasywne)
- Skany/fazowanie (aktywne)
- Pliki raportów/procedury przechwytywania/pułapki (po fakcie)
- Ręczne (określane przez superwizora)
W rezultacie logika detekcji trzeciej generacji rozwiązuje również ważny problem dokładności. Teraz możemy nie tylko unikać fałszywych alarmów i fałszywych negatywów, ale także wykrywać wiarygodne prawdziwe negatywy, takie jak wykrywanie wykorzystania elementu komend SQL w panelu sterowania, ładowanie szablonów stron internetowych, żądania AJAX związane z błędami JavaScript oraz inne.
Przyjrzyjmy się dalej technologicznym możliwościom różnych wariantów wdrożenia WAF.
Sprzęt, oprogramowanie czy chmura — co wybrać?
Jednym z wariantów wdrożenia zapór aplikacji jest rozwiązanie "sprzętowe". Takie systemy to wyspecjalizowane urządzenia obliczeniowe, które firma instaluje lokalnie w swoim centrum danych. W takim przypadku należy jednak zakupić własny sprzęt i zapłacić integratorom za jego konfigurację i uruchomienie (jeśli firma nie posiada własnego działu IT). Należy pamiętać, że każdy sprzęt staje się przestarzały i ulega degradacji, więc zamawiający muszą uwzględniać w budżecie koszty aktualizacji sprzętu.
Inną opcją wdrożenia WAF jest realizacja programowa. Rozwiązanie jest instalowane jako dodatek do oprogramowania (na przykład ModSecurity konfigurowane jest na Apache) i działa na tym samym serwerze. Zazwyczaj takie rozwiązania można wdrożyć zarówno na serwerze fizycznym, jak i w chmurze. Ich wadą są ograniczone możliwości skalowalności oraz wsparcia ze strony dostawcy.
Trzecia opcja to konfiguracja WAF w chmurze. Takie rozwiązania są oferowane przez dostawców chmurowych jako usługa w modelu subskrypcyjnym. Firmy nie muszą kupować ani konfigurować specjalistycznego sprzętu, te zadania spoczywają na dostawcy usługi. Ważny moment – nowoczesny WAF w chmurze nie wymaga migracji zasobów na platformę dostawcy. Strona może być wdrożona w dowolnym miejscu, nawet lokalnie.
Dlaczego coraz częściej zwraca się ku chmurowemu WAF, opowiemy dalej.
Co może WAF w chmurze
Z punktu widzenia możliwości technologicznych:
- Za aktualizacje odpowiada dostawca. WAF jest oferowany w modelu subskrypcyjnym, dlatego dostawca usługi dba o aktualność aktualizacji i licencji. Aktualizacje dotyczą nie tylko oprogramowania, ale i sprzętu. Dostawca modernizuje infrastrukturę serwerową i zajmuje się jej utrzymaniem. Odpowiada również za równoważenie obciążenia i rezerwację. W przypadku awarii serwera WAF ruch jest natychmiast przekierowywany na inny serwer. Racjonalne rozłożenie ruchu pozwala uniknąć sytuacji, kiedy zapora przechodzi w tryb fail open — nie radzi sobie z obciążeniem i przestaje filtrować zapytania.
- Wirtualne łatanie. Wirtualne łaty ograniczają dostęp do skompromitowanych części aplikacji do momentu, gdy programista usunie lukę. W rezultacie klient dostawcy chmury zyskuje możliwość spokojnego oczekiwania na publikację oficjalnych „łat” przez dostawcę oprogramowania. Szybkie wprowadzenie poprawek to priorytet dla dostawcy oprogramowania. Na przykład w platformie „Valarm” za wirtualne łatanie odpowiada osobny moduł programowy. Administrator może dodawać niestandardowe wyrażenia regularne do blokowania złośliwych zapytań. System umożliwia oznaczanie niektórych zapytań flagą „Dane poufne”. Wówczas ich parametry są maskowane, a same zapytania nie są w żadnym wypadku przekazywane poza obszar roboczy zapory.
- Wbudowany skaner obwodu i luk. Umożliwia to samodzielne określenie granic sieci IT, wykorzystując dane zapytań DNS i protokołu WHOIS. Po tym, WAF automatycznie analizuje działające w obrębie obwodu usługi i serwisy (przeprowadza skanowanie portów). Zapora potrafi wykrywać wszystkie powszechne typy luk — SQLi, XSS, XXE i inne — oraz ujawnia błędy w konfiguracji oprogramowania, na przykład, nieautoryzowany dostęp do repozytoriów Git i BitBucket oraz anonimowe zapytania do Elasticsearch, Redis, MongoDB.
- Ataki są monitorowane przez zasoby chmury. Zwykle dostawcy chmur dysponują dużymi mocami obliczeniowymi. Umożliwia to przeprowadzenie analizy zagrożeń z wysoką precyzją i szybkością. W chmurze uruchamiany jest klaster węzłów filtrujących, przez które przechodzi cały ruch. Te węzły blokują ataki na aplikacje internetowe i przesyłają statystyki do Centrum Analityki. Wykorzystuje ono algorytmy uczenia maszynowego, aby aktualizować zasady blokady dla wszystkich chronionych aplikacji. Wdrożenie takiego schematu przedstawiono na rys. 4. Takie dostosowane zasady bezpieczeństwa minimalizują liczbę fałszywych alarmów generowanych przez zaporę.
Teraz kilka słów o cechach chmurowych WAF z punktu widzenia organizacyjnego i zarządzania:
- Przejście na OpEx. W przypadku chmurowych WAF koszt wdrożenia wynosi zero, ponieważ dostawca już opłacił cały sprzęt i licencje, płatność za usługę odbywa się na podstawie subskrypcji.
- 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, zabezpieczonego panelu sterowania. Dostęp do niego odbywa się za pośrednictwem HTTPS, a dodatkowo dostępny jest mechanizm uwierzytelniania dwuskładnikowego oparty na protokole TOTP (algorytm jednorazowego hasła opartego na czasie).
- Połączenie przez DNS. Można samodzielnie zmienić DNS i skonfigurować trasowanie w sieci. Aby rozwiązać te zadania, nie ma potrzeby angażowania i szkolenia specjalistów. Z reguły w konfiguracji może pomóc wsparcie techniczne dostawcy.
Technologie WAF przeszły ewolucję od prostych zapór sieciowych z empirycznymi zasadami do złożonych systemów ochrony z algorytmami uczenia maszynowego. Obecnie zapory aplikacyjne posiadają szeroki zakres funkcji, które były trudne do zrealizowania w latach 90-tych. W dużym stopniu wprowadzenie nowych funkcji stało się możliwe dzięki technologiom chmurowym. Rozwiązania WAF i ich komponenty nadal się rozwijają, podobnie jak inne obszary cyberbezpieczeństwa.
Tekst przygotował Alexander Karpuzikov, menedżer ds. rozwoju produktów bezpieczeństwa w chmurowym dostawcy #CloudMTS.
Źródło: habr.com
