VIII Seminarium PLOUG
Warszawa
Kwiecień 2003
Zabezpieczanie aplikacji internetowych
za pomocą firewalli aplikacyjnych
Wojciech Dworakowski
[e-mail]
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 apli-
kacji 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 programo-
wania 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ł pro-
gramowania 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 admini-
stratora
Podczas poprzedniego wykładu starałem się pokazać że większość zagrożeń dla danych udostęp-
nianych 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 ograni-
czony wpływ na kod który jest publikowany na jego serwerze. Kod tworzą deweloperzy, a admini-
strator 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 z
ródeł zewnętrznych. Jest tworzony na zlecenie lub jest to po pro-
stu 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 regulo-
wać 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 reagu-
jące na zagrożenia.
Z pomocą przychodzą tutaj rozwiązania potrafiące analizować ruch aplikacji internetowych i ak-
tywnie reagować na próby ataku.
Spróbuję podać kilka metod technicznych, które mogą podnieść bezpieczeństwo serwera aplika-
cyjnego, 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 ty-
powego serwera aplikacyjnego J2EE. Takim serwerem aplikacji jest m.in. Oracle 9iAS.
18 Wojciech Dworakowski
(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 przeka-
zywanie 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:
" z
ródłowego i docelowego adresu IP
" z
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 apli-
kacje internetowe. Dla nich ruch HTTP będący atakiem jest nie do rozróżnienia od zwykłego, do-
zwolonego ruchu HTTP gdyż nie analizują one zawartości sesji HTTP.
Poniższy schemat pokazuje analizę ruchu do aplikacji internetowej przez tradycyjny firewall:
Firewall
9iAS
5. Aplikacji
OC4J
4. TCP
DBMS
3. IP
2. A
ącza
Metadata
1. Fizyczna
Oracle HTTP
Server
Web Cache
 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 wykorzy-
stywanych 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 po-
niższy rysunek:
Firewall
Filtr
HTTP
9iAS
5. Aplikacji
OC4J
4. TCP
DBMS
3. IP
2. A
ącza
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
Oracle HTTP
Server
Web Cache
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 SQL-
injection:
Niewątpliwą zaletą blokowania ataków na serwery aplikacyjne na firewallu jest możliwość ochro-
nienia 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 musi-
my 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.
22 Wojciech Dworakowski
Firewalle aplikacyjne
Tradycyjne firewalle sieciowe nie są w stanie sprostać ochronie aplikacji internetowych. W związ-
ku 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
OC4J
Oracle HTTP Server
DBMS
Firewall aplikacyjny
Firewall
Metadata
Praktycznie każdy współczesny serwer WWW posiada możliwość rozszerzania swojej funkcjonal-
noś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 konfigura-
cje w jaki kolwiek sposób wspierane przez Oracle. Firewalle aplikacyjne to stosunkowo nowa
dziedzina informatyki, w związku z tym ciężko jest znalez
ć 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 zlece-
niach 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 wykorzy-
stują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 zlece-
nia 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 odpo-
wiedzi, pokazana na rysunku powyżej nie da się edytować.
Zarządzanie modułem serwera odbywa się przez edycje plików konfiguracyjnych lub przy wyko-
rzystaniu 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. Opro-
gramowanie to zostało stworzone przez firmę Butterfly Security, jednak w paz
dzierniku 2002 zo-
stał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 sys-
temami 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 skom-
pilowana wersja 1.0-Beta-1 zawiera wyłącznie moduł ISAPI do Microsoft IIS. Moduły Apache i
iPlanet są w wersji rozwojowej. Ich z
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 po-
zostawia 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ę prawi-
dłowo przy zainstalowanym JDK v. 1.4.1 (j2sdk1.4.1_02)
" Po instalacji automatycznie uruchomi się program do generacji kluczy SSL (licensehel-
per.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 urucha-
miany 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 nie-
go  ręcznie program licensehelper.exe do podkatalogu  bin w katalogu w którym zain-
stalowaliśmy CodeSeeker.
" Przed połączeniem z monitorowanym systemem z konsoli, administrator jest uwierzytel-
niany 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 Fi-
les/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 moni-
torują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 (pierw-
szy dodany do konsoli) ma funkcję nadrzędną i na nim jest przechowywana polityka inspekcji ru-
chu. Serwery komunikują się z konsolą za pomocą transmisji szyfrowanej SSL-em. Dodanie serwe-
ra do konsoli wymaga podania jego adresu IP, oraz odcisku (fingerprint) klucza.
Podczas normalnej eksploatacji moduł serwera przechwytuje całość ruchu kierowanego do serwe-
ra, 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 opro-
gramowania.
26 Wojciech Dworakowski
Polityka nadzoru ruchu do serwera aplikacji składa się z dwóch grup sygnatur: jedna opisuje ogól-
ne 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 infor-
macje 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ępu-
ją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 za-
wartoś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 pasyw-
nym, 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 za-
pewni 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.