Zabezpieczanie aplikacji internetowych za pomocą firewalli

VIII Seminarium PLOUG
Warszawa
Kwiecieñ 2003
Zabezpieczanie aplikacji internetowych
za pomoc¹ firewalli aplikacyjnych
Wojciech Dworakowski
[email protected]
SecuRing
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
17
Poprzedni wykład miał na celu uświadomienie słuchaczowi, że posiadanie aplikacji internetowych
wiąże się z wieloma zagrożeniami. Zapewnienie odpowiedniego poziomu bezpieczeństwa aplikacji
internetowych to duże wyzwanie dla administratorów. Podobnie jak w wypadku tradycyjnych aplikacji i serwisów sieciowych należy stosować dwojaką ochronę:
• Metody prewencyjne – a więc zapobiegające powstaniu zagrożenia. Tu mamy przede
wszystkim konstruowanie bezpiecznych architektur, stosowanie dobrych zasad programowania oraz ciągłe edukowanie projektantów i programistów w zakresie bezpieczeństwa.
• Metody proaktywne – reagujące na próby ataków. Narzucenie odpowiednich reguł programowania to nie wszystko. Należy jeszcze stosować mechanizmy zabezpieczające przed
błędami popełnionymi przez programistów i projektantów.
Jedną z metod proaktywnego zabezpieczania aplikacji internetowych jest zastosowanie firewalli
umiejących filtrować ruch charakterystyczny dla aplikacji internetowych. Temat ten był omawiany
w artykule „Obrona przed atakami SQL-injection z punktu widzenia administratora” (PLOUG’tki
nr 25). Wykład jest rozszerzeniem tego tematu i praktyczną prezentacją dostępnych rozwiązań.
Zabezpieczanie aplikacji internetowych – punkt widzenia administratora
Podczas poprzedniego wykładu starałem się pokazać że większość zagrożeń dla danych udostępnianych przez aplikacje internetowe wiąże się z błędami wewnątrz samej aplikacji. Co w takim
razie może zrobić administrator serwera aplikacji, bazy danych lub sieci? Z reguły ma on ograniczony wpływ na kod który jest publikowany na jego serwerze. Kod tworzą deweloperzy, a administrator ma zapewnić, że będzie on działał na serwerach. Im większa firma, tym bardziej te dwie
funkcje są od siebie oddalone i tym mniejszy jest wpływ administratora na bezpieczeństwo samego
kodu umieszczonego na serwerze aplikacji.
Częstokroć kod ten pochodzi ze źródeł zewnętrznych. Jest tworzony na zlecenie lub jest to po prostu fragment jakiegoś produktu integrującego serwer WWW i bazę danych. W takim wypadku
wpływ administratora na jakość i bezpieczeństwo kodu udostępnianego na serwerze WWW jest
jeszcze mniejsza.
Wymagania co do bezpieczeństwa jakie powinny spełniać aplikacje internetowe, powinna regulować polityka bezpieczeństwa, a dokładniej odpowiednie instrukcje bezpieczeństwa wynikające z
przyjętej polityki. Tak więc dbałość o bezpieczeństwo aplikacji powinna być poza obowiązkami
administratorów serwerów aplikacyjnych. Jednakże mało w której instytucji istnieją tak szczegółowe instrukcje. Poza tym oprócz środków prewencyjnych należy stosować środki aktywnie reagujące na zagrożenia.
Z pomocą przychodzą tutaj rozwiązania potrafiące analizować ruch aplikacji internetowych i aktywnie reagować na próby ataku.
Spróbuję podać kilka metod technicznych, które mogą podnieść bezpieczeństwo serwera aplikacyjnego, niezależnie od udostępnianego na nim kodu i rodzaju zastosowanej metody server-side
(JSP + servlety, PL/SQL, ASP, PHP, itd.). Z góry zaznaczam, że nie są to sposoby skuteczne
w 100%, każdy z nich posiada swoje ograniczenia. Jednak stosowanie tych dodatkowych metod
może znacznie podnieść poprzeczkę, którą musi pokonać intruz.
Dlaczego tradycyjny firewall nie wystarcza?
Przyjrzyjmy się architekturze serwerów aplikacyjnych, a przede wszystkim sposobowi w jaki
klienci korzystają z serwera aplikacji internetowych. Poniższy schemat pokazuje architekture typowego serwera aplikacyjnego J2EE. Takim serwerem aplikacji jest m.in. Oracle 9iAS.
Wojciech Dworakowski
18
(schemat pochodzi z dokumentacji Oracle)
HTTP/
HTTPS
Typem klienta, który nas interesuje jest przeglądarka WWW. Nie implementuje ona po swojej
stronie Javy w związku z tym podstawową metodą komunikacji z serwerem aplikacji jest przekazywanie stron HTML lub dokumentów XML przez protokół HTTP.
Jeżeli na drodze między przeglądarką a serwerem aplikacji będzie stał firewall, to dla niego ruch
aplikacji internetowej będzie zwykłym ruchem HTTP lub HTTPS. Tradycyjne firewalle analizują
tylko trzecią i czwartą warstwę protokołów sieciowych. W naszym wypadku są to protokoły IP i
TCP. W związku z tym mogą one filtrować ruch tylko na podstawie:
• źródłowego i docelowego adresu IP
• źródłowego i docelowego numeru portu TCP
• stanu sesji TCP (tylko firewalle statefull inspection)
Jak widać tradycyjne firewalle nie są w stanie reagować na ataki wysokopoziomowe na same aplikacje internetowe. Dla nich ruch HTTP będący atakiem jest nie do rozróżnienia od zwykłego, dozwolonego ruchu HTTP gdyż nie analizują one zawartości sesji HTTP.
Poniższy schemat pokazuje analizę ruchu do aplikacji internetowej przez tradycyjny firewall:
4. TCP
3. IP
2. Łącza
1. Fizyczna
9iAS
OC4J
Oracle HTTP
Server
5. Aplikacji
Web Cache
Firewall
DBMS
Metadata
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
19
Firewalle z częściową możliwością analizy ruchu
Niektóre z zaawansowanych firewalli mają rozszerzone możliwości o analizę najczęściej wykorzystywanych protokołów. Zwykle jest to realizowane przez specjalne moduły umiejące analizować
konkretny protokół. W takim wypadku, monitorowany protokół jest wykrywany przez firewall i
przekazywany do analizy do odpowiedniego modułu.
Schemat monitorowania ruchu do aplikacji internetowej przez tego typu firewall przedstawia poniższy rysunek:
Firewall
Filtr
HTTP
9iAS
5. Aplikacji
2. Łącza
Oracle HTTP
Server
3. IP
OC4J
Web Cache
4. TCP
DBMS
Metadata
1. Fizyczna
Firewall-1
Przykładem firewalla, który umie analizować niektóre protokoły wyższych warstw, jest Checkpoint
Firewall-1. Posiada on moduły aplikcyjne o nazwie Security Servers. Nas będzie interesował HTTP
Security Server. Pozwala on na filtrowanie odwołań HTTP według:
– metody dostępu (GET, POST, inne)
– zawartości URI
Niestety nie ma możliwości analizowania parametrów POST. Jest to spore ograniczenie gdyż
większość formularzy webowych przekazuje swoje parametry w postaci zleceń POST.
Niemniej jednak Firewall-1 daje możliwość ograniczenia ruchu tylko do niezbędnych metod (np.
tylko GET i POST) oraz możliwość narzucenia ograniczneń na zawartość URI.
Żeby dodać regułę blokującą ruch w zależności od zawartości URI, należy najpierw zdefiniować
opis danego ataku (dla Firewall-1 jest to zasób). Z poziomu Checkpoint Policy Editor wykonać
należy:
Manage -> Resources -> New -> URI
20
Wojciech Dworakowski
W pole „Name” należy wpisać nazwę definiowanego zasobu, czyli nazwę opisu danego ataku – np.
„SQL-injection”, zaś w polu „URI Match Specification Type” zaznaczyć „Wild Cards”.
Na zakładce „Match” mamy możliwość zdefiniowania szczegółów tworzonego zasobu. Tu należy
jak najdokładniej opisać atak SQL-injection który chcemy blokować:
Schemes: http
Methods: GET, POST
Query: *SELECT*FROM*
tu wpisujemy wyrażenie które chcemy blokować w ciągu URI
Dodatkowo – na zakładce „Action” w polu „Replacement Uri” można zdefiniować stronę na którą
będzie przekierowany intruz. Istnieje również możliwość importowania wyrażeń z pliku.
Regułę blokującą zdefiniowany przed chwilą zasób „SQL-injection”, dodajemy tak jak każdą inną
regułę filtrowania, z tym że w polu „Service”, po kliknięciu prawym klawiszem myszy wybieramy
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
21
„Add with resource”. Następnie wybieramy usługę „http” a w polu „Resource” zdefiniowany przez
nas zasób „SQL-injection”.
Poniższy rysunek przedstawia gotową przykładową regułkę blokującą niektóre ataki SQLinjection:
Niewątpliwą zaletą blokowania ataków na serwery aplikacyjne na firewallu jest możliwość ochronienia wielu serwerów WWW i aplikacji, za pomocą jednego urządzenia i jednego zestawu reguł.
Znacznie upraszcza to wdrożenie i zarządzanie przy rozbudowanych infrastrukturach, gdzie musimy chronić wiele serwerów WWW korzystających z baz danych.
Natomiast ogromną wadą takiego rozwiązania jest niemożność analizowania ruchu HTTPS (SSL).
Ruch ten jest zaszyfrowany, a co za tym idzie – niemożliwy do przeanalizowania przez firewall.
Warto zauważyć że fragmenty aplikacji WWW chronione protokołem SSL, z reguły są połączone z
bardzo istotnymi informacjami w bazie danych, tak więc tym bardziej należałoby je chronić.
Powyższy przykład pokazywał jak skonfigurować Firewall-1 do obrony przed niektórymi atakami
typu SQL-injection. Podobne reguły należałoby stworzyć dla pozostałych typów ataków. Warto
przy tym zauważyć że nie wszystkie typy ataków da się opisać za pomocą parametrów dostępnych
w Firewall-1.
Jak widać Firewall-1 nie jest instrumentem przystosowanym do chronienia aplikacji internetowych.
Jednakże jeśli już jest w naszej sieci, to warto skorzystać z jego możliwości w zakresie filtrowania
ruchu HTTP.
Wojciech Dworakowski
22
Firewalle aplikacyjne
Tradycyjne firewalle sieciowe nie są w stanie sprostać ochronie aplikacji internetowych. W związku z tym, ostatnio pojawiła się nowa klasa oprogramowania – firewalle aplikacyjne.
Firewall aplikacyjny to rodzaj filtru integrującego się z serwerem WWW. Działa on między częścią
sieciową serwera, a częścią aplikacyjną. W związku z tym dostaje do analizy ruch po wstępnej
obróbce przez serwer, tak jak go będą widziały dalsze warstwy. Serwer zajmuje się:
• rozszyfrowaniem transmisji SSL (jeśli jest używana),
• zdekodowaniem zlecenia (jeśli było stosowane np. kodowanie hexadecymalne URI),
• wstępną obróbką zlecenia.
Firewalle aplikacyjne działając jako moduł serwera WWW bardzo blisko się integrują z serwerem
aplikacji. Dzięki takiemu rozwiązaniu:
• nie muszą dbać o szyfrowanie SSL
• nie da się ich obejść, przez zakodowanie zlecenia
• mogą być to stosunkowo proste mechanizmy, gdyż sporą część pracy wykonuje za nie
serwer WWW.
Poniższy schemat przedstawia umiejscowienie firewalla aplikacyjnego w architekturze serwera
aplikacji.
9iAS
Oracle HTTP Server
OC4J
DBMS
Firewall aplikacyjny
Firewall
Metadata
Praktycznie każdy współczesny serwer WWW posiada możliwość rozszerzania swojej funkcjonalności przez dodawanie modułów:
• dla serwera Microsoft ISS są to filtry ISAPI
• dla Apache są to moduły Apache
• dla Netscape/iPlanet/SunOne są to moduły iAPI
Oracle HTTP Server to standardowy serwer Apache 1.3.x. Posiada on możliwość ładowania modułów dynamicznych, tworzonych w postaci bibliotek. Tak więc powinien dobrze integrować się z
rozwiązaniami stworzonymi dla Apache. Przyjrzymy się dwóm takim rozwiązaniom.
Niestety jak narazie nie stworzono firewalla aplikacyjnego dedykowanego dla Oracle Application
Server. Rozwiązania przygotowane dla Apache 1.3 powinny działać, jednakże nie są to konfiguracje w jaki kolwiek sposób wspierane przez Oracle. Firewalle aplikacyjne to stosunkowo nowa
dziedzina informatyki, w związku z tym ciężko jest znaleźć jakiekolwiek informacje o próbach
zintegrowania poniższych rozwiązań z serwerami aplikacji Oracle. Poniższe rozwiązania na pewno
zadziałają dla serwera Apache, w związku z tym powinny również poprawnie współpracować z
Oracle HTTP Server, jednak ich wdrożenie powinno zostać poprzedzone szczegółowymi testami.
NGSecureWeb
NGSecureWeb to oprogramowanie hiszpańskiej firmy NGSec. Potrafi integrować się z następującymi platformami serwera WWW:
• Apache 1.3 – Linux (x86), Solaris (Sparc i x86), BSD (x86), Windows, HP-UX
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
23
• Microsoft IIS
• iPlanet (Sun One) – Linux (x86), Solaris (Sparc), Windows, HP-UX
Do instalacji jest niezbędny program axps, który umieszcza w pliku konfiguracyjnym Apache
(httpd.conf) odwołanie do modułu filtrującego – mod_ngswa. Do oprogramowania dołączony jest
graficzny konfigurator. Można też administrować nim przez edycję plików konfiguracyjnych.
NGSecureWeb potrafi wykrywać i blokować kilka typów ataków na serwery aplikacyjne. Mamy
do dyspozycji następujące rodzaje zabezpieczeń:
• Long URL Protection
Pozwala na ograniczenie długości URL i w ten sposób może zabezpieczać przed atakami
buffer overflow w przekazywanych parametrach
• Traversal Directory Protection
Wykrywa próby ominięcia zabezpieczeń katalogów wirtualnych serwera i wyjścia poza
standardową ścieżkę.
• Long Headers Protection
Zabezpiecza przed atakami buffer overflow w polach nagłówków HTTP.
• Forbidden Words Protection
Pozwala na zdefiniowanie niedozwolonych słów kluczowych, w przetwarzanych zleceniach HTTP. Słowa te mogą występować w nagłówkach, argumentach GET i POST.
• Shellcode Protection
Wykrywa próby uruchomienia na serwerze zewnętrznego kodu. Jest to metoda wykorzystująca ataki buffer overflow i format strings.
• Non Printable Characters Protection
Pozwala na zdefiniowanie listy zabronionych znaków specjalnych.
• Method Protection
Pozwala na ograniczenie dostępnych metod (np. GET, POST, PUT, HEADER, inne)
Przykładowo – do obrony przed atakami SQL-injection możemy wykorzystać filtr „Forbidden
Words Protection”. Wykrywa on w zleceniu HTTP słowa kluczowe. Poniższy rysunek przedstawia
przykładową konfigurację odrzucającą wszystkie zlecenia zawierające w sobie słowo SELECT.
W odróżnieniu od przykładu z Firewall-1, oprogramowanie NGSecureWeb potrafi analizować
również argumenty przekazywane w metodzie POST. Dzięki temu można filtrować każdy sposób
komunikacji między przeglądarką a serwerem.
24
Wojciech Dworakowski
Po skonfigurowaniu słowa kluczowego SELECT, każda próba użycia go w dowolnej części zlecenia HTTP spowoduje zwrócenie przez serwer strony informującej o zablokowaniu ataku.
Rozwiązanie to nie jest jednak wolne od wad. Za największą uważam to, że do opisania ataku da
się używać tylko i wyłącznie pojedynczych słów, a nie np. wyrażeń regularnych. Ponadto intruz
zawsze jest informowany o tym, że atak został zablokowany przez NGSecureWeb. Strona odpowiedzi, pokazana na rysunku powyżej nie da się edytować.
Zarządzanie modułem serwera odbywa się przez edycje plików konfiguracyjnych lub przy wykorzystaniu lokalnej konsoli GUI. Nie da się zarządzać wieloma serwerami z jednej konsoli.
CodeSeeker
CodeSeeker to oprogramowanie jeszcze w wersji beta, ale o bardzo dużych możliwościach. Oprogramowanie to zostało stworzone przez firmę Butterfly Security, jednak w październiku 2002 zostało przekazane dla projektu OWASP. Od tej pory jest udostępniane za darmo, na zasadach Open
Source. OWASP (Open Web Application Security Project) to grupa specjalistów zajmujących się
różnymi aspektami bezpieczeństwa aplikacji. W projekt są zaangażowani specjaliści z takich firm
jak np. IBM, Deloitte&Touche czy Microsoft, eksperci z firm zajmujących się komercyjnymi systemami ochronnymi oraz eksperci zajmujący się na codzień testowaniem bezpieczeństwa aplikacji.
Według dokumentacji CodeSeeker integruje się z Apache, IIS oraz iPlanet. Jednak dostępna skompilowana wersja 1.0-Beta-1 zawiera wyłącznie moduł ISAPI do Microsoft IIS. Moduły Apache i
iPlanet są w wersji rozwojowej. Ich źródła można pobrać przez CVS i skompilować samodzielnie.
Na razie CodeSeeker należy uznać za oprogramowanie w fazie testów beta. Dużo do życzenia pozostawia zwłaszcza instalator. Poniżej kilka wskazówek, które pomogą pomyślnie przebrąć proces
instalacji.
• Konsola CodeSeeker-a jest napisana w Javie. W mojej instalacji uruchamiała się prawidłowo przy zainstalowanym JDK v. 1.4.1 (j2sdk1.4.1_02)
• Po instalacji automatycznie uruchomi się program do generacji kluczy SSL (licensehelper.exe). Należy zapamiętać odciski (fingerprint) klucza serwera. Okienko w którym jest
on wyświetlany nie udostępnia zaznaczenia i skopiowania, więc najlepszym wyjściem jest
zrobienie „screenshota” (Alt-Pint Screen)
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
•
•
25
Instalator omyłkowo nie przegrywa programu licensehelper.exe, chociaż jest on uruchamiany podczas instalacji i potem istnieje do niego skrót w menu „Start”. Należy otworzyć
plik programu instalacyjnego za pomocą ZIP-a i rozpakować go. Następnie przegrać z niego „ręcznie” program licensehelper.exe do podkatalogu „bin” w katalogu w którym zainstalowaliśmy CodeSeeker.
Przed połączeniem z monitorowanym systemem z konsoli, administrator jest uwierzytelniany za pomocą hasła. Wcześniej należy dodać użytkownika do CodeSeekera, za pomocą
programu „User Manager”. Każdorazowo, po dodaniu użytkownika należy skopiować plik
/Program Files/CodeSeeker/conf/SystemUsers.temp do pliku /Program Files/CodeSeeker/conf/SystemUsers oraz zrestartować serwer WWW.
Podczas samej eksploatacji oprogramowania natomiast nie zauważyłem znaczących błędów. Np.
nie zadziałało zapisywanie zdarzeń do Event Loga na Windows.
CodeSeeker składa się z dwóch części: konsoli zarządzającej napisanej w Javie, oraz modułu monitorującego serwer WWW. W przypadku Microsoft IIS jest to biblioteka DLL, którą instaluje się
jako filtr ISAPI. W przypadku Apache jest to moduł w formie biblioteki „so”, który nalezy dodać
do Apache tak jak w przypadku NGSecureWeb opisywanego powyżej.
Konsola zarządzająca umożliwia kontrolowanie wielu serwerów WWW. Jeden z serwerów (pierwszy dodany do konsoli) ma funkcję nadrzędną i na nim jest przechowywana polityka inspekcji ruchu. Serwery komunikują się z konsolą za pomocą transmisji szyfrowanej SSL-em. Dodanie serwera do konsoli wymaga podania jego adresu IP, oraz odcisku (fingerprint) klucza.
Podczas normalnej eksploatacji moduł serwera przechwytuje całość ruchu kierowanego do serwera, po wstępnej obróbce przez serwer i nadzoruje go zgodnie z przyjętą polityką.
Możliwość definiowania bardzo szczegółowej polityki uważam za największą zaletę tego oprogramowania.
26
Wojciech Dworakowski
Polityka nadzoru ruchu do serwera aplikacji składa się z dwóch grup sygnatur: jedna opisuje ogólne zagrożenia takie jak path traversal, SQL-injection, próby wykonania programów, itp, druga zaś
opisuje konkretne znane exploity na poszczególne typy serwerów. Dla każdego zagrożenia można
skonfigurować listę ścieżek URL serwera, do których będzie stosowana dana reguła. Znacznie to
ułatwia wdrożenie filtrowania przy dużych, skomplikowanych aplikacjach WWW.
Do wykrycia każdego zagrożenia można zdefiniować akcje oraz sposób informowania. Akcje to:
• Zablokowanie odwołania. Można przy tym zdefiniować kod błędu HTTP, a nawet informacje tekstową mu towarzyszącą.
• Przekierowanie odwołania do innego adresu URL.
Każdorazowo, oprogramowanie może informować, o próbie ataku. Mamy do dyspozycji następujące metody:
• Wysłanie e-maila.
• Zapisanie informacji przez Syslog (unixowy mechanizm logowania zdarzeń) – również na
maszynie zdalnej.
• Zapisanie informacji do Windows EventLog
• Zapisanie informacji do pliku tekstowego. Administrator ma możliwość definiowania zawartości i stopnia szczegółowości zapisywanej informacji.
Zabezpieczanie aplikacji internetowych za pomocą firewalli aplikacyjnych
27
Przy wdrażaniu monitoringu, zalecane jest uruchomienie najpierw CodeSeekera w trybie pasywnym, bez blokowania ruchu lecz tylko z zapisywaniem każdego wykrytego ataku do logów. Potem
należy wykonać w swojej aplikacji internetowej większość możliwych operacji i sprawdzić czy
któraś z nich nie spowodowała podniesienia alarmu. Dla tych części aplikacji należy zdefiniować
wyjątki i wtedy dopiero włączyć blokowanie ataków w CodeSeeker. Taki sposób wdrożenia zapewni stabilnoość działania aplikacji i zmniejszy ilość fałszywych alarmów.
Podsumowanie
Firewalle aplikacyjne to nowe, ciekawe narzędzie uzupełniające, podnoszące bezpieczeństwo. Są
one w stanie znacznie ograniczyć ryzyko, jednak na pewno nie stanowią panaceum na wszelkie
metody ataku na aplikacje internetowe. Problem z większością ataków na aplikacje, polega na tym,
że nie da się ich odróżnić od normalnej aktywności użytkowników. W związku z tym najlepszą
formą ochrony pozostanie zawsze stosowanie zasad najlepszych praktyk jeśli chodzi o bezpieczeństwo. Np. ograniczanie tej „normalnej aktywności” do niezbędnego minimum.