VIII Seminarium PLOUG Warszawa Kwiecieñ 2003 Zabezpieczanie aplikacji internetowych za pomoc¹ firewalli aplikacyjnych Wojciech Dworakowski wojciech.dworakowski@securing.pl 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.
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 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: Firewall 5. Aplikacji 4. TCP 3. IP 2. Łącza 1. Fizyczna 9iAS Web Cache Oracle HTTP Server OC4J Metadata DBMS
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 5. Aplikacji 4. TCP 3. IP 2. Łącza 1. Fizyczna 9iAS Web Cache Oracle HTTP Server OC4J Metadata DBMS 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.
22 Wojciech Dworakowski 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 Firewall aplikacyjny OC4J DBMS 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.