Personal tools
Integrator Integrator  > Archiwum  > Archiwum Wydania Online  > Wydanie 2009  > Nr 7-8/2009 (105)  > Ataki w warstwie aplikacji i przeciwdziałanie im przy pomocy WAF (Web Application Firewall) i Juniper
Integrator nr III/2018(142)
 
 

Ataki w warstwie aplikacji i przeciwdziałanie im przy pomocy WAF (Web Application Firewall) i Juniper

Epoka Web2.0 przyzwyczaiła nas do tego, iż coraz więcej usług oraz informacji dostępnych jest przez sieć Internet. Jesteśmy przyzwyczajeni do efektów graficznych i dynamicznej interakcji na stronach WWW. Zupełnie naturalne stały się zakupy, aukcje, blogowanie czy usługi bankowe - wszystko dostępne przez Internet. Z zasobów internetowych możemy korzystać również przy pomocy telefonów IP, komórek lub urządzeń PDA.

Niestety wraz z tą ekspansją oraz dynamiką wzrostu popularności usług internetowych, wzrasta także liczba atakowanych stron i aplikacji internetowych. Problem ten jest o tyle istotny, że poza kradzieżą tożsamości, utratą wiarygodności wobec klientów/partnerów, niesie za sobą wymierne straty finansowe, ponieważ większość ataków aplikacyjnych przeprowadzanych jest w celu odniesienia konkretnych korzyści finansowych.        
                                                                            
Aby zrozumieć istotę ataków aplikacyjnych, przyjrzyjmy się na początek architekturze aplikacji internetowych. W skład typowej aplikacji internetowej wchodzą:

  • Serwer WWW: odpowiedzialny za interfejs użytkownika. Jego głównym zadaniem jest przedstawienie wyników zapytań w postaci zrozumiałej i miłej oku użytkownika.
  • Serwer aplikacyjny: odpowiedzialny za koordynację procesów aplikacyjnych i logiki aplikacji.
  • Kod aplikacji: nierzadko napisany bądź zoptymalizowany przez firmy trzecie na potrzeby działania konkretnych aplikacji. Kod ten może stanowić integralną część serwera aplikacji, bądź występować jako oddzielna całość. Sama aplikacja zazwyczaj jest niemodyfikowalną całością. Aby w pełni ją wykorzystać zazwyczaj potrzebna jest integracja z resztą aplikacji oraz bazą danych, wchodzących w skład portalu. Tu z pomocą przychodzą mini aplikacje (kod aplikacji), dostosowane do potrzeb i wymagań konkretnych zastosowań.
  • Baza danych: miejsce, w którym przechowywane są dane. Dane te przekazywane są do użytkownika przez serwery aplikacyjne oraz  serwery WWW.

W przypadku mniejszych rozwiązań, wszystkie wymienione powyżej elementy, mogą być zainstalowane na jednym serwerze.  Dostępne są ponadto gotowe rozwiązania, np. phpbb, .NET,  umożliwiające budowę aplikacji internetowych mniejszej skali. Z naszego punktu widzenia, tego typu oprogramowanie to kod aplikacji.

Oczywiście każda aplikacja internetowa powinna być - i zazwyczaj jest - zabezpieczona przez urządzenia sieciowe, takie jak: firewalle, IPSy. Zabezpieczając zasoby firm, urządzenia te muszą jednak umożliwiać, poprzez otwarcie portów tcp 80, 443 (http, https), komunikację użytkowników z aplikacjami oraz transport danych do przeglądarek użytkowników, którzy wysyłają zapytania w kierunku aplikacji.

Na poniższym rysunku została przedstawiona typowa architektura aplikacji internetowych oraz najczęściej spotykany wektor ataku na aplikacje webowe. Zazwyczaj atak ten polega na:

  • Krok1: odpowiednim spreparowaniu zapytania do aplikacji.
  • Krok2: niepoprawnym dostępie aplikacji/kodu aplikacyjnego do bazy danych.
  • Krok3: transporcie niefiltrowanych danych do atakującego, który chciał te dane uzyskać.

 

 1a

Rys.1 Architektura aplikacji internetowej i wektor ataku na aplikację webową

Jak wynika z rysunku, atakujący dokonując ataku aplikacyjnego, nie zaatakował serwera WWW, aplikacji czy bazy danych. Zaatakował kod aplikacji! I takie działanie jest istotą ataku aplikacyjnego. Należy dodać, iż 75% ataków aplikacyjnych dokonywanych jest właśnie w ten sposób.

Dlaczego atak ten jest tak niebezpieczny, a zarazem bardzo popularny i stosunkowo łatwy do przeprowadzenia? Przyczyn i powodów jest kilka:

  • Programiści piszący atakowany kod aplikacji to tylko ludzie. Popełniają błędy, mają swoje nawyki, przyzwyczajenia.
  • Tradycyjne zabezpieczenia sieciowe nie są świadome ataków na aplikacje webowe, ponieważ sieć i jej urządzenia pracują w niższych warstwach modelu ISO OSI – warstwie sieci oraz warstwie transportowej. Nie istnieją reguły dla firewalli czy sygnatury dla IPSów zabezpieczające przed błędami w kodzie aplikacji napisanym przez firmy trzecie pod konkretne potrzeby i zastosowania indywidualnych firm.
  • Niedoskonałości  i błędy w protokołach sieciowych, w tym przede wszystkim http (zostaną one omówione dalej podczas prezentacji najpopularniejszych ataków aplikacyjnych).
  • Internet to relatywnie anonimowe medium.
  • Narzędzie służące do ataku to zazwyczaj po prostu przeglądarka internetowa.

Zasadniczą przyczyną ataków aplikacyjnych są nawyki programistów oraz ich niewiedza. Deweloperzy też często skupiają się na rozwoju nowych funkcjonalności kosztem dbałości o bezpieczeństwo pisanego przez nich kodu. Jest to niepokojące zjawisko, tym bardziej że wg badań amerykańskiego departamentu obrony, każde 1000 linii kodu zawiera średnio 15 krytycznych luk bezpieczeństwa, a aplikacje składają się na ogół z 150.000 – 250.000 linii kodu. Dlaczego więc po prostu nie poprawić błędów w aplikacjach? Jeżeli weźmiemy pod uwagę powyższe dane i dodamy do nich wyniki  pięcioletnich badań Pentagonu, mówiących o tym, iż przeciętnie diagnoza luki bezpieczeństwa w kodzie zajmuje 75 min, a jej naprawa 6 godzin, to odpowiedź jest oczywista: czas i pieniądze. Z tego powodu potrzebne są inne rozwiązania, bardziej systemowe, pomijające czynnik ludzki. Należą do nich urządzenia typu WAF – Web Application Firewall. Zanim jednak zajmiemy się omówieniem ich funkcji, przyjrzyjmy się najpierw konkretnym przykładom ataków aplikacyjnych.

Przykłady i omówienie najpopularniejszych ataków aplikacyjnych

Znanych jest wiele rodzajów ataków aplikacyjnych, a większość incydentów aplikacyjnych można znaleźć w bazie WHID (Web Hacking Incidents Database) pod adresem http://www.xiom.com/whid. Niektóre z nich są ściśle związane z technikami programowania portali internetowych (np. PHP, ASP), inne są bardziej uniwersalne, jeszcze inne są nazwami całych rodzin zagrożeń web, w których istnieje wiele hybryd i odmian tego samego ataku.

Na poniższym rysunku przedstawiona została lista najpopularniejszych ataków na aplikacje webowe wg OWASP (Open Web Application Security Project) w 2007 roku. Szybka analiza tej statystyki pokazuje, iż dominującymi zagrożeniami są ataki: Cross-Site Scripting i Injection Flaws, które łącznie stanowią około połowę wszystkich ataków. W dalszej części artykułu zostaną one szczegółowo omówione.

2a

Rys.2 Lista najpopularniejszych ataków na aplikacje webowe w 2007 roku wg OWASP

Atak #1 - Unvalidated input

Mimo iż atak unvalidated input nie znajduje się na liście najpopularniejszych ataków OWASP - zostanie on omówiony, ponieważ jest protoplastą dwóch najpopularniejszych ataków na aplikacje webowe: XSS i SQL Injection. Zrozumienie mechanizmu działania tego nadużycia, umożliwi pełne zrozumienie bardziej skomplikowanych ataków, które będą przedstawione w dalszej części artykułu.

Śledząc genezę tego ataku, można powiedzieć, że w bezpośredni sposób wykorzystuje on zbyt duże zaufanie deweloperów, piszących aplikacje webowe do informacji wpisywanych przez użytkowników na stronach internetowych. Aplikacje webowe używają parametrów, by pobrać informacje od klientów wpisywanych w formularzach na stronach. Developerzy zazwyczaj skupiają się na poprawnych wartościach parametrów i ich dalszym przetwarzaniu. Ten brak dbałości przy walidacji i sprawdzaniu poprawności wartości pól otwiera bardzo duże możliwości do nadużyć.

W efekcie aplikacja postępuje zgodnie ze „zmienionymi” informacjami, potencjalnie dając dostęp do kont użytkowników, danych, itp.

Bardziej skomplikowane ataki unvalidated input są maskowane za pomocą technik kodowania. W HTMLu, który jest prostym językiem służącym do pisania stron WWW, znajdują się:

  • zestawy znaków,
  • kodowanie, czyli sposoby transformacji znaków na bity.

Przykład interpretacji strony WWW przez przeglądarki, gdy w jej źródle zostanie zdefiniowane kodowanie i bez niego, został przedstawiony na rysunku poniżej.

3a

Rys.3 Przykład różnej interpretacji strony WWW, gdy określone zostanie kodowanie i bez niego

Najpopularniejszym znanym kodowaniem jest kod ASCII, wykorzystujący 128 znaków. Niestety mimo popularności, za jego pomocą nie można przedstawić wszystkich znaków, występujących we wszystkich językach. Z tego powodu między innymi HTML używa kodowania Unicode. Za jego pomocą można uzyskać 1000 znaków, przy czym - co bardzo istotne - większości znaków do wartości poniżej 128 bajtów przypisywane są te same znaki, dalej używane są kombinacje znaków. Konsekwencją tego jest fakt, iż kodowania wprowadzają alternatywne oznaczenia dla tych samych znaków, w szczególności dla znaków specjalnych.

RFC 1738 opisujące postać jaką może przyjąć URL, pozwala na używanie znaków alfanumerycznych [0-9a-zA-Z], znaków specjalnych: $-_.+!*() oraz znaków zarezerwowanych, np. &. Niestety, co jest głównym problemem wykorzystywanym przy atakach z kodowaniem URLi, jeżeli zestaw znaków na stronie WWW nie zostanie zdefiniowany (przez developera), serwer nie będzie mógł określić, które znaki stanowią znaki specjalne! Dlatego też serwery powinny definiować zestawy znaków specjalnych, a następnie kontrolować, czy we wpisanych danych nie ma zdefiniowanych bajtowych sekwencji.

Jednym z najbardziej znanych przykładów tego ataku jest exploit „Shopping Cart”, umożliwiający manipulowanie parametrami w trakcie transakcji kupna dokonywanej w sklepie internetowym. Exploit ten umożliwiał zmianę cen produktów dodawanych do koszyka. Pomyślne przeprowadzenie ataku unvalidated input nie wiąże się jedynie z posiadaniem „magicznego” oprogramowania, wystarczy zwykła przeglądarka internetowa, ponieważ istnieje szereg użytecznych narzędzi oraz pluginów takich jak: Paros, Suru, Burp, Suite, WebScarab, umożliwiających przeprowadzenie tego ataku.

Atak #2 – XSS (Cross-Site Scripting)

Atak XSS jest obecnie najczęściej spotykanym atakiem skierowanym przeciwko aplikacjom webowym. Porównując go do wcześniej omówionego ataku unvalidated input, jest on jego rozwinięciem, ponieważ o ile ten pierwszy manipulował URLami (głównie przez kodowanie znaków specjalnych), o tyle XSS również manipuluje URLami, jednak wstrzykuje do nich kod PHP, JavaScript (również zakodowany).

Atak ten bazuje przede wszystkim na niedoskonałości protokołu HTTP, który najogólniej mówiąc nie jest świadomy sesji oraz transakcji. W trakcie zakupu, bądź dokonywania przelewu przez Internet, zanim zatwierdzimy transakcję i zostanie ona przyjęta przez system do realizacji, nierzadko przechodzimy przez kilka etapów (podstron), nim finalnie potwierdzimy transakcję. W trakcie przechodzenia do kolejnych podstron, wartości parametrów – w szczególności cena zakupu, kwota przelewu, czy ID użytkownika –nie powinny ulec zmianie, a pozostać nienaruszone do końca transakcji. W tym celu między innymi zostały wykorzystane cookies (ciasteczka), za pomocą których serwer zapisuje na komputerze klienta pewne - potrzebne do przeprowadzenia transakcji - informacje.

Jak nie trudno się domyślić, ideą ataku XSS będzie chęć przejęcia przez atakującego ciasteczka ofiary, w którym zapisywane są informacje o sesji i transakcji użytkownika. Poznanie tych informacji umożliwi atakującemu podszycie się pod ofiarę i kradzież jej tożsamości.

Ataki XSS posiadają wiele odmian, które jednak można zaklasyfikować do trzech zasadniczych grup:

  • Reflected (Non-Persistent)
  • Stored (Persistent): Hakerzy instalują złośliwy kod PHP, JavaScript na stronie internetowej. Każda wizyta na zarażonej stronie powoduje wykonanie tego kodu, a w konsekwencji zarażenie użytkownika. Klasycznym przykładem tego ataku był atak dokonany w 2005 roku na portalu MySpace. Jeden z użytkowników w celu podniesienia ilości osób znajomych (tzw. buddies) włamał się na stronę portalu i umieścił w nim złośliwy kod, powodujący, iż osoby odwiedzające MySpace były dopisywane do listy znajomych atakującego. Po niespełna 24h atakujący miał już ponad milion znajomych. 
  • DOM based (Local)

Bardzo groźną grupę ataków XSS stanowią ataki typu Reflected, ponieważ ich główną metodą propagacji jest SPAM. Atak ten wygląda następująco: atakujący wysyła odpowiednio spreparowany link do ofiary. Ten spreparowany URL zawiera - oprócz przekierowania na dobrze znaną i zaufaną stronę WWW (np. istniejącego banku) – kod, powodujący pobranie z komputera atakującego odpowiedniego skryptu. Zadaniem tego skryptu jest kradzież cookie, które zostanie utworzone w trakcie transakcji kupna, przelewu na dobrze znanej stronie dokonywanej przez ofiarę. Oczywiście w celu ukrycia ataku, zawartość URLa jest kodowana tak, aby ofiara - widząc w URLu ciąg binarny, a nie tekst zrozumiały dla oka ludzkiego - nie była świadoma zagrożenia. Po przejęciu cookie, atakujący może podszyć się pod ofiarę i dokonywać zakupów, przelewów na jej konto. Szczegółowo, algorytm i sposób przeprowadzenia ataku XSS typu Reflected został przedstawiony na poniższym rysunku.

 4a

Rys.4 Algorytm typowego ataku XSS

Atak #3 – SQL Injection

W fachowej literaturze atak SQL Injection jest bodaj najobszerniej opisywanym atakiem aplikacyjnym. Jednak mimo tej popularności i wiedzy na jego temat, jest on nadal bardzo groźny, szczególnie w przypadku ataków masowych, które zostaną opisane później. Atak SQL Injection jest przykładem ataku z grupy Injection Flaws i w dużym uproszczeniu polega na wstrzyknięciu (ang. injection) niepoprawnego zapytania SQL do URLa.

Na początku artykułu, gdy przedstawiona została architektura aplikacji internetowych (patrz rys.1) wspomniano, iż aplikacja/kod aplikacyjny komunikuje się z bazą danych i pobiera z niej/zapisuje w niej, przekazywane przez stronę internetową dane. SQL (Structured Query Language) jest standardem, umożliwiającym aplikacjom komunikację z bazą danych. SQL pozwala na wykonywanie zapytań do bazy danych, które z kolei mogą:

  • pobierać dane z bazy danych (polecenie SELECT),
  • wstawiać nowe rekordy do bazy danych (polecenie INSERT),
  • usuwać rekordy z bazy danych (polecenie DELETE),
  • aktualizować rekordy w bazie (polecenie UPDATE).

Zapytania SQL są bardzo powszechnie wykorzystywane przez aplikacje internetowe, np. przy logowaniu do aplikacji. Służą one wtedy przede wszystkim do poszukiwania rekordów na podstawie wprowadzonych przez użytkownika danych, takich jak nazwa użytkownika/ID i hasło. Dane te są porównywane z rzeczywiście istniejącymi w bazie danych - inaczej każdy mógłby się zalogować na nasze konto. Poniżej znajduje się przykład typowego zapytania SQL, używanego przy logowaniu (na czerwono zostały zaznaczone dane wprowadzane przez użytkownika):

13a

Zapytanie to szuka w bazie danych (konkretnie w tabeli users) użytkownika jan, którego hasło to 123. Jeżeli oba te warunki zostaną spełnione (odnalezione w bazie) to logowanie się powiedzie, w przeciwnym wypadku, nie uda nam się zalogować. W związku z tym, iż w kodzie aplikacyjnym zapytania SQL są często używane, to typowy kod - np. w skrypcie ASP, który wykonuje powyższe zapytanie SQL - wygląda następująco (na niebiesko  zostały zaznaczone dyrektywy wprowadzane przez język skryptowy ASP, a na czerwono dane wpisywane przez użytkownika w formularzu):

12a


Wprawne oko uważnego czytelnika zwróci uwagę na fakt, iż do wpisywanych przez użytkownika danych (nazwa użytkownika, hasło) SQL dodaje apostrof, oznaczając w ten sposób informacje, które będzie pobierał, cytował. Apostrof, mimo iż jest małym, niepozornym znakiem, w przypadku ataku SQL odgrywa bardzo istotną rolę i daje duże możliwości atakującemu. Dlaczego? Ponieważ umożliwia „złamanie” oryginalnie wykonywanego zapytania SQL i wstrzyknięcie do niego  spreparowanych danych. Kontynuując nasz przykład, jeżeli w formularzu, w którym wpisujemy nazwę użytkownika i hasło wpiszemy (wstrzykniemy za pomocą apostrofu) zamiast prawdziwych danych poniższe informacje:

 14a

to zgodnie z logiką SQL zapytanie jakie wykona SQL w bazie danych będzie miało następującą postać:

15a

Ostatni wiersz tego zapytania celowo został napisany szarym kolorem, ponieważ wprowadzone wcześniej w polu form_user znaki -- oznaczają, iż wszystko co pojawi się za nimi będzie komentarzem i nie ma być interpretowane przez SQL, więc tak naprawdę jest nieistotne. Skoro ostatni wiersz, a więc hasło jest nieistotne, przyjrzyjmy się wierszowi drugiemu. Zgodnie z jego zapisem, SQL poszuka w bazie danych użytkownika bez nazwy (login=’’) albo sprawdzi czy 1=1. Najprawdopodobniej użytkownik z pustą nazwą nie istnieje w bazie, jednak warunek logiczny 1=1 jest zawsze prawdziwy, więc cały drugi wiersz zawsze będzie prawdą! Z tego też powodu uda nam się zalogować do systemu. Wszystko dzięki apostrofowi i niedbalstwu deweloperów, którzy powinni za pomocą rzutowania typów, podwójnego cytowania czy innych znanych technik walidacji, sprawdzić wprowadzane dane i uniemożliwić wpisywanie w formularzach znaków specjalnych, takich jak np. apostrof ale również innych: )”><\.

Opisany powyżej atak SQL Injection jest dobrze znanym, trywialnym atakiem i został przedstawiony w celach edukacyjnych. W rzeczywistości ataki SQL Injection są o wiele groźniejsze i nie wykorzystują jedynie zapytań SQL typu Select.

Poniżej na Listingu1 znajduje się przykład takiego ataku. Na pierwszy rzut oka jest to typowe żądanie pobrania obrazków ze strony WWW, za którym następuje ciąg znaków. Dla lepszej czytelności, cały wstrzykiwany do aplikacji kod został celowo oznaczony kolorem czerwonym. Jeżeli przyjrzymy się teraz uważnie podanemu na Listingu1 linkowi zobaczymy, że atakujący dodał do standardowego adresu URL średnik, za którym następują kolejne instrukcje SQL, zaczynające się od DECLARE. Po słowie CAST następuje łańcuch znaków niezrozumiałych dla oka ludzkiego. Atakujący, używając zwykłego kodowania heksadecymalnego (szesnastkowego), celowo zaciemnił ten fragment przed systemami zabezpieczeń, ponieważ zawierają one złośliwy kod.

5a

Listing 1. Atak SQL Injection używający kodowania heksadecymalnego

Po zdekodowaniu tego ciągu znaków zobaczymy, że tak naprawdę fragment ten jest ciągiem zapytań i instrukcji SQL. Postać czytelną dla oka ludzkiego przedstawia poniższy Listing 2.

6a

Listing 2. Atak SQL Injection po zdekodowaniu

W dużym skrócie, zadaniem powyżej przedstawionych instrukcji SQL, jest wstrzyknięcie do wszystkich pól tekstowych każdej tabeli bazy danych, skryptu o nazwie ngg.js, zawierającego złośliwy kod. Użytkownicy oglądający zainfekowane w ten sposób strony WWW, pobierają na swoje komputery skrypt, który następnie tworzy lukę w zabezpieczeniach systemu i umożliwia dostanie się atakującemu na ich komputery.

WAF – omówienie funkcjonalności na podstawie Cisco

Sporą część artykułu poświęciliśmy atakom aplikacyjnym, ich charakterystyce i przykładom. Liczba zagrożeń i skala ich oddziaływania jest naprawdę duża. Problem ten zauważyły również organizacje międzynarodowe, które postanowiły przeciwdziałać atakom aplikacyjnym na poziomie standardów i norm. Jednym z takich przykładów jest standard PCI-DSS (Payment Card Industry Data Security Standard), opisujący konieczne zabezpieczenia przy transakcjach kartami płatniczymi. Jego dwie sekcje: 6.5 i 6.6 koncentrują się na bezpieczeństwie aplikacji internetowych. Druga z nich, obliguje do instalacji urządzenia typu WAF (Web Application Firewall) do końca czerwca 2008.

            WAF w dużym uproszczeniu to firewall, który rozumie, ma świadomość aplikacji, a więc działa nie tylko w warstwie sieci ale również w warstwie aplikacji. W ofercie SOLIDEX S.A. znajdują się trzy urządzenia realizujące te funkcje:

  • Cisco WAF,
  • F5 BIG-IP z funkcjonalnością ASM,
  • Imperva SecureSphere WAF.

W dalszej części artykułu omówione zostaną funkcje, jakich możemy oczekiwać od firewalli aplikacyjnych, na przykładzie Cisco WAF.

            Istnieje kilka modeli wdrożeń w przypadku poszczególnych urządzeń, dostępnych w ofercie SOLIDEX S.A. Firewalle aplikacyjne można wdrażać:

  • w trybie transparentnym (bridge’a), w którym urządzenia działają w warstwie drugiej i kontrolują ruch sieciowy w trybie in-line,
  • w trybie routera, w którym urządzenia translują adresy (NAT),
  • w trybie reverse proxy.

Ostatni z trybów - Reverse Proxy jest najbardziej optymalnym. W trybie tym WAF sprawdza zapytanie klienta (analizuje pod względem bezpieczeństwa) i przekierowuje do właściwego serwera HTTP. Tryb ten umożliwia modyfikowanie zawartości pakietów, podpisywanie ciasteczek, itp. Wymaga on jednak zazwyczaj rekonfiguracji wpisów DNS i wskazanie klientom jako adresu IP serwera WWW, adresu aplikacyjnego firewalla. Rozwiązania Cisco WAF oraz Impreva SecureSphere nie posiadają wbudowanych mechanizmów zapewniających redundancję. Można ją osiągnąć, wykorzystując:

  • zewnętrzny load balancer,
  • SLB (Server Load Balancing) funkcjonalność balansowania ruchu dostępna na routerach i multilayer switchach z odpowiednim IOS.

Na poniższym rysunku został przedstawiony model wdrożenia Cisco WAF w trybie reverse proxy z balansowaniem ruchu, realizowanym przez zewnętrzny load balancer.

7a

Rys.5 Wdrożenie Cisco WAF z użyciem zewnętrznych load balancerów

Wg powyższego modelu wdrożenia, klienci wysyłają żądania na adres strony WWW, który jest adresem wirtualnym (VIP), utworzonym na zewnętrznych load balancerach. Urządzenia balansujące wybierają odpowiedniego WAFa i przekierowują do niego zapytanie. Po przeanalizowaniu ruchu, WAF przesyła żądania na adres innej grupy VIP, skonfigurowanej na load balancerach. Grupa ta jest adresem wirtualnym docelowych serwerów WWW i za pomocą mechanizmów balansujących balancer wybiera odpowiedni serwer WWW, wysyłając do niego ruch po inspekcji.

Wspólną cechą firewalli aplikacyjnych jest również fakt, iż wdrażane są one w pierwszej fazie w trybie monitoringu. Ten nieinwazyjny tryb umożliwia uruchomienie WAFa bez ingerencji czy przerw w działaniu aplikacji webowych, pozwalając na obserwację ewentualnego zachowania, bez podejmowania akcji blokujących ruch.

Bardzo ważną uwagą wdrożeniową jest fakt, aby nie kierować do urządzeń WAF innego ruchu niż HTML, XML. Urządzenia te nie wspierają innego typu ruchu poza HTTP i jeżeli otrzymają ruch typu: SSH, FTP, odrzucą go. Bardzo istotne jest, aby selektywnie przekierowywać ruch do firewalli aplikacyjnych.

Spora część artykułu poświęcona została na omówienie ataków z kodowaniem, które starają się ukryć intencje atakującego. Firewalle aplikacyjne, aby wyeliminować tego typu ataki, kanonizują URLe (doprowadzają je do postaci kanonicznej). Dla przykładu,  Cisco WAF zanim przystąpi do inspekcji ruchu, normalizuje go do UTF-8.

Obok funkcji bezpieczeństwa, firewall aplikacyjny powinien zapewniać pełną analizę zarejestrowanych ataków i nadużyć. Powinien więc posiadać funkcje raportujące.

Cisco WAF został zbudowany na bazie urządzenia AXG (ACE XML Gateway), który był XML firewallem i pojawił się w ofercie Cisco w maju 2008 wraz z oprogramowaniem AXG 6.0. Dostępny jest w formie appliance’a jak również jako licencja do modułu ACE. Sam moduł ACE to typowy load balancer, który występuje w formie wolnostojącego urządzenia oraz modułu usługowego dla Catalysta 6500. Jeżeli chodzi o funkcje bezpieczeństwa, moduł ACE jest bardzo podobny do innego modułu usługowego Catalysta 6500, będącego typowym firewallem - modułu FWSM. Cisco ACE w zakresie funkcjonalności firewall umożliwia konfigurację: access-list, statefull firewall, deep packet inspection (również HTTP). Posiada również szereg rozszerzeń, dotyczących inspekcji, np. FTP, TCP. Jednak bez licencji WAF, moduł ACE nie jest firewallem aplikacyjnym.

Dostępne są dwa rodzaje licencji:

  • Gateway,
  • Manager (zarządzanie Cisco WAF Gateway).

Pojedynczy Manager może zarządzać kilkoma Gatewyami. Można też połączyć funkcjonalności Managera oraz Gatewaya na jednym urządzeniu, jak również na module ACE, jednak nie jest to w chwili obecnej wspierane przez support Cisco.  W przypadku Cisco WAF appliance dostępne są licencje FIPS zapewniające parametry związane z kryptografią i przechowywaniem kluczy. Sposób licencjonowania Cisco WAF appliance został przedstawiony na poniższym rysunku.

8a

Rys.6 Model licencjonowania Cisco WAF appliance

Jeżeli chodzi o wydajność, Cisco WAF appliance może analizować do 9.000 sesji HTTP na sekundę, utrzymywać 30.000 sesji oraz obsługiwać ruch do 1GBps.

Chronione aplikacje webowe grupowane są na podstawie dowolnych kryteriów (np. aplikacje produkcyjne, testowe), co zapewnie sporą elastyczność wdrożenia. Punkty kontrolne przypisywane są do aplikacji za pomocą profili bezpieczeństwa. Pojedyncza aplikacja może mieć przypisany jeden profil, ale jeden profil może być skojarzony z wieloma aplikacjami. Cisco WAF umożliwia kreowanie profili w ramach trzech sekcji:

  • ekcji aktywnego bezpieczeństwa,
  • zmiany wybranej treści w komunikacji pomiędzy klientem i serwerem,
  • analizy ruchu za pomocą sygnatur.

Bardzo istotnym elementem bezpieczeństwa, który powinien posiadać firewall aplikacyjny jest ochrona za pomocą sygnatur. Sygnatury są zestawem reguł, opisujących konkretny atak aplikacyjny.

Najbardziej rozbudowaną sekcją w Cisco WAF jest sekcja aktywnego bezpieczeństwa. Funkcje w niej zawarte powinien posiadać każdy firewall aplikacyjny. Należą do nich:

  • Maskowanie wersji serwera WWW w ramach modyfikowania nagłówków serwera WWW. Ukrycie informacji o serwerze WWW utrudnia atak, ponieważ atakujący nie jest w stanie atakować serwera w oparciu o listę jego znanych słabości i dziur.
  • Ochrona DLP realizowana przez:
    • maskowanie odpowiedzi z serwera WWW, np. maskowanie (rewriting) numerów kart kredytowych,
    • remapowanie komunikatów błędów serwera WWW, ponieważ często wynikiem pracy aplikacji, niepotrafiącej prawidłowo obsłużyć wprowadzonego przez użytkownika nieprzewidywalnego parametru, jest wyświetlanie danych (np. nazw tabel w bazie danych), które nie powinny być wyświetlone.

Ochrona DLP jest bardzo ważnym aspektem bezpieczeństwa, który powinien zapewniać WAF, ponieważ wg badań, z dwóch na pięć aplikacji webowych następuje wyciek informacji.

  • Ochrona przed atakami typu Buffer Overflow i DoS umożliwiająca określenie parametrów granicznych (np. maksymalny rozmiar URL, maksymalna długość nagłówka, maksymalny rozmiar ciasteczka, itp.), a w konsekwencji ignorowanie zapytań, przekraczających te wartości.
  • Podpisywanie i szyfrowanie ciasteczek. Zaszyfrowanie informacji, które zapisuje serwer WWW po stronie klienta uniemożliwia skuteczne przeprowadzenie ataku XSS lub CSRF. W związku z tym, iż operacje kryptograficzne są czasochłonne, aby nie wpływały one na wydajność firewalla aplikacyjnego, powinny być realizowane sprzętowo. Zasadę szyfrowania ciasteczek przedstawia poniższy rysunek.
9a

Rys.7 Szyfrowanie ciasteczek przez Cisco WAF appliance

Firewalle aplikacyjne, próbując przeciwdziałać atakom aplikacyjnym, działają w warstwie aplikacji. Większość rozwiązań tego typu (F5, Imperva) posiada umiejętność dynamicznego uczenia się aplikacji, tzw. site learinig. Firewalle aplikacyjne dynamicznie budują profile zachowań wykorzystania aplikacji, które później będą chronić. Jednak dynamiczne uczenie ma swoje wyzwania:

  • zajmuje czas, średnio 2-3 tygodnie potrzebne są na naukę aplikacji,
  • po jego włączeniu, nie można go ponownie wyłączyć,
  • jak odizolować czysty ruch od ataków, wiąże się to ze żmudnym przeglądaniem logów.

Cisco nie implementuje site learningu w formie takiej, jaką posiadają rozwiązania konkurencji: F5, czy Imperva. W zamian za to proponuje mechanizm HaL (Human Assisted Learning). HaL nie uczy się aplikacji w klasyczny sposób, tylko pokazuje, które sygnatury wzbudziłyby się, gdyby były włączone w trybie blokowania. HaL daje więc plusy związane z dynamicznym uczeniem, usuwając konieczność zgadywania, czy dany ruch był atakiem czy nie. Nie można jednak utożsamiać go z site learningiem, którego rozwiązanie Cisco de facto nie posiada.

F5 WAF – ASM

Firma F5 specjalizuje się w produkcji load balancerów, będąc światowym liderem w zakresie ich produkcji. W ofercie F5 dostępnych jest kilka modeli urządzeń balansujących z rodziny BIG-IP, która jest bardzo dojrzałą rodziną load balancerów oraz nowej rodziny VIPRON. Urządzenia balansujące F5, to urządzenia dostosowane do różnych warunków wydajnościowych. Najmniejsze urządzenie BIG-IP 1600 jest w stanie obsługiwać ruch do 750Mbps, podczas gdy największe jest w stanie obsłużyć ruch w warstwie aplikacji o wartości 7,5Gbps. Nowe, modularne balancery z rodziny VIPRON mogą obsługiwać ruch, przekraczający nawet 30Gbps.

Urządzenia F5 poza wydajnością, różnią się miedzy sobą również ilością interfejsów sieciowych, możliwością instalacji dodatkowych kart funkcjonalnych czy ilością możliwych do uruchomienia programowych modułów funkcjonalnych.

Podstawą rozwiązań F5 jest specjalnie opracowana architektura sprzętowa oraz dedykowany system operacyjny TMOS z zaimplementowanym własnym, zoptymalizowanym stosem TCP-IP, pełnym proxy warstwy aplikacji czy wirtualną segmentacją sieciową. Otwarta architektura TMOS pozwala na implementację na jednej platformie wielu funkcjonalności, takich jak:

  • load balancing,
  • connection pooling,
  • kompresja (realizowana sprzętowo),
  • caching (Fast Cache Module),
  • akceleracja SSL / SSL Offloading (realizowana sprzętowo),
  • zaawansowany routing,
  • moduł zaawansowanego uwierzytelnienia klientów,
  • moduł obsługujący IPv6,
  • moduł kształtujący ruch (L7 Rate Shaping Module),
  • firewall aplikacyjny (WAF).

Firma F5 oferuje możliwość instalacji rozwiązań typu WAF w postaci licencji, uruchamianych niezależnie od pozostałych, na urządzeniach z rodziny BIG-IP i VIPRON. Dostępne są dwa rozwiązania:

  • ASM (Application Security Manager), który zapewnia pełną ochronę typu WAF.
  • PSM (Policy Security Manager), który jest okrojoną wersją ASM I umożliwia sprawdzenie zgodności zapytań z RFC. Realizuje więc jedynie ochronę protokołu, a nie aplikacji.

W związku z faktem, iż F5 umożliwia instalację funkcji balansujących i security (WAF) na jednym urządzeniu, typowy model wdrożenia jest uproszczony w stosunku do przedstawionego wcześniej, również ze względu na fakt, iż F5 obsługuje redundancję. Typowy model wdrożenia urządzeń F5 został przedstawiony na poniższym rysunku.

10a

Rys.8 Typowy model wdrożenia F5 BIG-IP z ASM

ASM posiada wszystkie funkcje omówione wcześniej na przykładzie Cisco WAF i zabezpiecza przed wszystkimi zagrożeniami, występującymi na liście OWASP Top10.

W przeciwieństwie do tradycyjnych systemów ochrony aplikacji, takich jak systemy detekcji i blokowania włamań, moduł ASM wykorzystuje tzw. pozytywny model bezpieczeństwa, aby osłaniać chronione aplikacje. Pozytywny model oznacza sytuację, w której definiowane jest poprawne zachowanie chronionej aplikacji i wszelkie próby wyjścia poza to poprawne zachowanie są blokowane. Aby zdefiniować poprawne zachowanie trzeba mieć świadomość całej aplikacji –  firewall aplikacyjny musi się jej nauczyć. Istnieje wiele sposobów na poznanie aplikacji – od wykorzystania automatycznych silników analizy aplikacji, np. crowler, po ręczne definicje. Wygodnym jest również tryb nauki, podczas którego firewall aplikacyjny przygląda się zachowaniu aplikacji w trakcie użytkowania jej przez końcowych użytkowników. Następnie koniecznym jest zdefiniowanie poprawnych zachowań – na przykład określenie, jakie znaki mogą być używane w konkretnych polach lub też zdefiniowanie kolejności przepływu informacji przez poszczególne formatki. Przełączenie firewalla w tryb blokowania spowoduje, że tylko poprawne zapytania - pochodzące od klientów aplikacji - będą akceptowane, a wszystkie inne będą blokowane. Co ważne, kontrola następuje dwukierunkowo, dlatego można również zdefiniować poprawne odpowiedzi, jakie mogą być przesyłane z serwera aplikacyjnego do klientów. Dzięki temu, ASM ma możliwość zablokowania przesyłania na przykład poufnych informacji, takich jak: numery kont, numery kart płatniczych itd.

Ciekawą funkcjonalnością oferowaną przez F5 (ale również Cisco) jest możliwość instalacji kart terminujących SSL i uczestniczących w procesie szyfrowania ciasteczek. Karty F5 posiadają certyfikację FIPS 140-2 (Federal Information Processing Standard) – standardu publicznego stworzonego przez rząd federalny Stanów Zjednoczonych. Karty FIPS, mogą być montowane w urządzeniach BIG-IP od modelu BIG-IP 6400 i wyższych. Realizują one funkcję sprzętowego modułu kryptograficznego HSM (Hardware Security Module), wspomagając proces szyfrowania ruchu SSL oraz zapewniając odpowiedni, zdefiniowany w standardzie FIPS 140-2 poziom bezpieczeństwa przechowywania kluczy oraz certyfikatów. Karta FIPS SSL jako bezpieczne repozytorium kluczy prywatnych bierze udział na przykład w negocjacji kluczy symetrycznych, przekazując funkcje szyfrowania już sprzętowym kartom SSL, dostępnym w każdym z modeli BIG-IP w standardzie.

Imperva SecureSphere WAF

Rozwiązanie Imperva SecureSphere jest systemem łączącym w sobie wiele różnych mechanizmów ochrony:

  • Firewalla aplikacji web oraz baz danych.
  • Zaporę sieciową firewalla chroniącą przed nieautoryzowanymi użytkownikami, niebezpiecznymi protokołami i innymi znanymi atakami warstwy sieciowej.
  • Sieciowy system ochrony przed intruzami IPS chroniący przed znanymi atakami skierowanymi na serwery WWW,  serwery aplikacyjne czy systemy operacyjne. Dzięki aktualizacjom dostarczanym z laboratorium Imperva Application Defense Center (ADC) -  odpowiedzialnemu za śledzenie i analizowanie nowych zagrożeń - chronione zasoby w krótkim czasie stają się odporne, na pojawiające się nowe niebezpieczeństwa.

W odróżnieniu od np. rozwiązań F5 i Cisco, rozwiązanie Impervy nie posiada wbudowanego load balancera. Z tego też powodu najczęstszym modelem wdrożenia tych produktów jest model przedstawiony przy omówieniu Cisco WAF, przy czym Impervę można również wdrożyć transparentnie lub w trybie routera. Nie mniej jednak w przypadku ruchu zaszyfrowanego HTTPS - Imperva SecureSphere nie terminuje sesji SSL, a jedynie odszyfrowuje kopię ruchu oryginalnego.

Podobnie jak w przypadku rozwiązania Cisco,  rozwiązanie Impervy składa się z serwera zarządzającego (MX Manager Server) i modułu zabezpieczeń. Serwer zarządzający MX jest dostępny jako dedykowane rozwiązanie typu appliance. Moduły zabezpieczeń również można zakupić jako dedykowane urządzenia lub licencję na oprogramowanie, które następnie może zostać zainstalowane na urządzeniu Crossbeam z serii X.

Dodatkowym elementem rozwiązania Impervy, pozwalającym na inteligentną reakcję na pojawiające się zdarzenia bezpieczeństwa, jest moduł CAV (Correlated Attack Validation). CAV decyduje o podjęciu akcji, na podstawie korelacji informacji o pojawiających się zdarzeniach, takich jak liczność, częstotliwość czy rodzaj zdarzenia. Reguły korelacji pozwalają przykładowo podjąć akcję dopiero w sytuacji, gdy dane zdarzenie wystąpi kilkukrotnie w okresie zdefiniowanego czasu. Korelację pomiędzy wszystkimi modułami przedstawia poniższy rysunek.

11a

Rys.9 Korelacja zdarzeń w rozwiązaniach imperia SecureSphere

Jednym z kluczowych elementów systemu Imperva SecureSphere jest moduł Web Application Firewall, który podobnie jak w przypadku F5 BIG-IP, wykorzystuje pozytywny model bezpieczeństwa, aby osłaniać chronione aplikacje. Podobnie do rozwiązania F5, Imperva realizuje również site learning (dynamiczną naukę aplikacji), za który odpowiada moduł Dynamic Profiling. Zastosowana technologia pozwala - na podstawie analizy obserwowanego ruchu - zbudować odzwierciedlenie całej struktury aplikacji, składającej się z katalogów, URLi, metod dostępu, parametrów, typów wartości oraz długości ciągów znaków, wprowadzanych przez użytkowników w poszczególnych formatkach. Dodatkowo Imperva posiada możliwość nauki formularzy, służących do logowania się użytkowników do aplikacji web. Dzięki temu możliwe jest śledzenie aktywności użytkowników poprzez moduł Web Application User Tracking, co jest funkcją unikalną na rynku. System SecureSphere koreluje nazwę użytkownika, logującego się do aplikacji z identyfikatorem sesji lub wartością cookie, co pozwala na audytowanie działalności użytkownika. Śledzenie jest realizowanie na podstawie nazwy użytkownika zalogowanego do aplikacji, a nie tylko adresów IP, z których użytkownik się łączy. Dzięki temu możemy rozróżnić aktywność użytkowników, łączących się zza serwerów proxy lub z sieci prywatnych, za urządzeniami realizującymi translację NAT.

Drugim z podstawowych elementów systemu SecureSphere jest firewall baz danych Database Security Gateway (DSG). Stosowane dotychczas tradycyjne zabezpieczenia, takie jak systemy IPS/IDS, poddając analizie ruch kierowany do baz danych, sprawdzają poprawność protokołu komunikacji oraz poprawność składni wysyłanych zapytań. Takie rozwiązania nie mają jednak świadomości chronionych zasobów, dlatego nie mogą na przykład blokować dostępu do poszczególnych części bazy jak tabele itp. Imperva DSG również posiada możliwość kontrolowania poprawności ruchu bazdodanowego, a informacje pochodzące z Application Defense Center o najnowszych podatnościach i zagrożeniach, pozwalają chronić bazę danych przed znanymi atakami. Kluczowym wyróżnikiem Database Security Gateway jest jednak świadomość chronionych zasobów, a co za tym idzie bardzo granularna możliwość kontroli.

Database Assesment to kolejna innowacyjna funkcjonalność Imperva Secure Sphere - pozwala ona na ocenę stanu bezpieczeństwa bazy danych - co jest bardzo istotnym zagadnieniem, biorąc pod uwagę fakt coraz częstszych ataków, wykorzystujących podatności baz danych lub słabości haseł. Badanie bazy danych odbywa się w dwojaki sposób - poprzez pasywną analizę ruchu i porównywanie go z odpowiednimi wzorcami oraz poprzez aktywne skanowanie bazy danych w poszukiwaniu wrażliwych informacji, podatności lub naruszeń uprawnień. Zgromadzone informacje można w automatyczny sposób wykorzystać do porównania zgodności z międzynarodowymi regulacjami, takimi jak SOX, HIPAA, GLBA, PCI czy CA 1386.

Funkcją, na którą należy zwrócić szczególną uwagę jest tzw. Universal User Tracking, który umożliwia zidentyfikowanie nazwy użytkownika przesyłanej w zapytaniach do aplikacji, dzięki temu w logach systemu możemy jasno określić, dla jakiego użytkownika aplikacji wykonała ona zapytanie do bazy danych. Dodatkowo w sytuacji, kiedy aplikacja nie przekazuje nazwy lub ID użytkownika, z pomocą przychodzi korelacja informacji z WAF i DSG. Universal User Tracking umożliwia transparentne skorelowanie nazw użytkowników, zalogowanych w aplikacji web z dokonywanymi przez tę aplikację transakcjami w bazie. Ponadto Universal User Tracking możne w łatwy sposób - na podstawie analizy ruchu lub wykorzystując odpowiednich agentów bezpośrednio na bazie danych - audytować działalność użytkowników oraz administratorów. Jest to mechanizm niezależny od samej bazy danych, a co za tym idzie, nie obciąża jej dodatkowymi zadaniami oraz nie powoduje konfliktów administracyjnych.

Podsumowanie

Do tej pory omówiliśmy przykłady i rodzaje zagrożeń aplikacyjnych oraz opisaliśmy trzy urządzenia typu WAF, występujące w ofercie SOLIDEX S.A. Firewalle aplikacyjne posiadają szereg zaawansowanych technologii przeciwdziałających atakom na aplikacje webowe, jednak pamiętajmy, że rozwiązania typu WAF nie zapewnią całkowitego bezpieczeństwa ochranianym aplikacjom. Problem leży w kodzie aplikacji, stamtąd więc powinny być usuwane błędy. Jeżeli założymy, że po audycie bezpieczeństwa zostanie ujawnionych 100 błędów i WAF zapobiegnie wykorzystaniu 85-u z nich, to nadal zyskujemy czas, ponieważ możemy skupić się na usunięci pozostałych 15-u.

Z drugiej strony, w maju tego roku grupa OWASP (ta sama, która publikuje listy Top10 ataków webowych) zademonstrowała narzędzie, rozpoznające firewalle aplikacyjne i wykorzystujące wykryte w nich błędy. Czy więc instalowanie urządzeń typu WAF rzeczywiście może podnieść poziom bezpieczeństwa aplikacji internetowych?

Oczywiście TAK i jest ku temu kilka istotnych powodów. Przede wszystkim WAF to jedyne urządzenie sieciowe, które w logiczny i czytelny sposób potrafi poinformować dział sieci  i specjalistów ds. bezpieczeństwa o aplikacjach internetowych i atakach na nie. Zazwyczaj dział sieci nie ma żadnej wiedzy na temat aplikacji, skupiając się jedynie na dostarczeniu i utrzymaniu  infrastruktury pod owe aplikacje. Ponadto celem narzędzia opracowanego przez OWASP, jak deklarują członkowie tej organizacji, jest troska o bezpieczeństwo aplikacji webowych i forma nacisku na producentów firewalli aplikacyjnych, aby stale rozwijali swe produkty i usuwali w nich błędy. Działania OWASP wpłyną więc mobilizująco na producentów firewalli aplikacyjnych, a w konsekwencji bezpieczeństwo aplikacji internetowych. Na koniec - rozwiązania typu WAF są świetnym narzędziem typu Virtual Patchtool, zapewniającym bezpieczeństwo aplikacjom, dla których nie pojawią się szybko aktualizacje poprawiające w nich błędy.


 

Document Actions

Our cookies are safe! We use them to ensure that our website is best suited to the needs of users. You can change your cookie settings at any time. Default settings for popular browsers allow cookies to be saved. For more information, read our cookies policy.

[X] Don't show this message again