Jak każde oprogramowanie, również aplikacje webowe nie są pozbawione błędów oraz luk w zabezpieczeniach. W przypadku aplikacji udostępnianych w internecie wpływ zagrożenia wynikającego z nieszczelności jest jednak znacznie większy. Konieczność publicznego udostępnienia połączenia z aplikacją powoduje, że prób nadużyć może być mnóstwo każdego dnia.
Żaden zespół programistów nie jest nam też w stanie zagwarantować stuprocentowej pewności, że stworzona przez niego aplikacja jest pozbawiona nieszczelności. Zupełnie naturalny jest właściwie ciągły proces aktualizacji oprogramowania i wykrywania kolejnych luk. Na bezpieczeństwo samej aplikacji ma zresztą w równym stopniu wpływ konfiguracja środowiska, na którym jest uruchomiona.
Niższe warstwy nie wystarczą
Uruchomienie aplikacji zaczyna się od odpowiedniego zabezpieczenia systemu operacyjnego oraz jej środowiska uruchomieniowego (serwer webowy, serwer bazodanowy itp.). Kolejnym niezbędnym elementem jest zapewnienie aktualizacji oprogramowania serwerowego, które ochronią system przed wykrytymi zagrożeniami. Zabezpieczenie na poziomie zapory sieciowej oraz systemu wykrywania lub zapobiegania włamaniom uzupełnia proces przygotowania środowiska do startu aplikacji.
Powyższe kroki, chociaż bardzo istotne, nie są w stanie wyeliminować wielu zagrożeń wynikających z działania naszej aplikacji. Konieczna jest do tego dodatkowa ochrona właśnie w warstwie aplikacji. Co z tego, że na serwerze zabezpieczymy poprawnie wszystkie porty, wgramy wszelkie możliwe poprawki do serwera webowego, a system IDS/IPS będzie miał wgrane wszystkie najnowsze sygnatury ataków, jeśli nasza aplikacja będzie podatna na prymitywny atak, w rezultacie którego wygeneruje błąd, który wyświetli na ekranie klienta dane autoryzacyjne i strukturę wykorzystywanej bazy danych.
Musimy pamiętać, że to właśnie uruchomiona aplikacja jest „wizytówką” całego mozolnie budowanego systemu informatycznego. Co więcej, sami zgadzamy się na jej wykorzystywanie przez użytkowników z internetu. Eskalacja błędu, który zostanie przez włamywacza wykryty w aplikacji, może doprowadzić go do zasobów zgromadzonych w niższych warstwach, a także – co jest najczęstszym powodem ataków – do danych zgromadzonych na serwerze albo kompromitacji organizacji czy firmy.
Podejście kompletne
Dopiero całościowe spojrzenie na system wraz z aplikacją zbliża nas do osiągnięcia zakładanego poziomu bezpieczeństwa. Takie podejście jest możliwe dzięki zastosowaniu Web Application Firewalla. Na podstawie analizy ruchu kierowanego do serwera webowego jest on w stanie wykryć i zareagować na anomalie w przesyłanych zapytaniach i odpowiedziach. Zasilony przez odpowiednią bazę w postaci reguł, sygnatur, ale także dane o lokalizacji i aktywności podejrzanych adresów IP oraz własną wbudowaną logikę, to właśnie WAF może stanowić podstawowy element obrony przed tak popularnymi dziś atakami.
Narzędzia klasy WAF istnieją na rynku od blisko 10 lat, mimo to ich zastosowanie wciąż wzbudza kontrowersje. Jedni uważają je za proste rozwiązanie problemów z bezpieczeństwem aplikacji bez konieczności ingerencji w ich kod, inni z kolei zwracają uwagę na kłopoty z ich funkcjonowaniem polegające na blokowaniu prawidłowego ruchu oraz nieskuteczność zdefiniowanych reguł.
WAF a IPS
Administratorzy posiadający już w swoich sieciach narzędzia do wykrywania i zapobiegania włamaniom często stawiają pod znakiem zapytania konieczność wprowadzania dodatkowego urządzenia do serwerowni.
System IPS (Intrusion Prevention System) dopasowuje monitorowany ruch sieciowy do sygnatur zgromadzonych w bazie danych, w celu wykrycia anomalii, które odróżniają podejrzany ruch od „normalnego”. W przypadku pozytywnego dopasowania następuje określona akcja – blokowanie, alert czy logowanie ruchu. Dzieje się to jednak poniżej warstwy aplikacyjnej modelu OSI.
Web Application firewall działa w warstwie 7 modelu sieciowego – czyli właśnie w warstwie aplikacji, dzięki czemu jest w stanie „rozumieć” zapytania i komunikację zachodzącą w aplikacjach webowych. Oprócz dopasowania bazującego na sygnaturach potrafi także działać w sposób heurystyczny i na podstawie zdefiniowanych reguł wywnioskować, że dany ruch jest niebezpieczny. Zasadniczą różnicą w stosunku do IPS jest więc nie tylko warstwa, w której pracuje – bo istnieją także rozwiązania IPS (Host IPS) operujące częściowo także w warstwie aplikacyjnej, ale również stopień „zrozumienia” ruchu, który jest znacznie wyższy w przypadku firewalla aplikacyjnego.
Web Application Firewall może być umiejscowiony w sieci na różne sposoby. Najpopularniejsze i dające najwięcej możliwości rozwiązanie to praca jako Reverse Proxy. W tym trybie urządzenie znajduje się w linii i przechodzi przez nie całość ruchu sieciowego. WAF posiada publiczny adres IP i dokonuje połączeń do serwerów webowych w imieniu klienta. Tryb ten jest wymagany przez niektóre dodatkowe funkcje WAF. Minusem rozwiązania jest możliwość wprowadzenia opóźnień, które mogą powodować problemy z działaniem aplikacji.
W trybie Reverse Proxy możemy dodatkowo uruchomić (w zależności od producenta i konfiguracji) takie mechanizmy jak cache, kompresję, a także akcelerację ruchu SSL. W przypadku rozwiązań sprzętowych ta ostatnia czynność jest obsługiwana także przed hardware, co może znacznie przyspieszyć ten proces w porównaniu z wydajnością oferowaną przez serwer webowy. W środowiskach, w których korzystamy z klastrów przydadzą się także funkcje Load Balancingu i pulowania połączeń uruchomione w ramach WAF.
Web Application Firewall może być umiejscowiony w sieci na różne sposoby. Najpopularniejsze i dające najwięcej możliwości rozwiązanie to praca jako Reverse Proxy. W tym trybie urządzenie znajduje się w linii i przechodzi przez nie całość ruchu sieciowego. WAF posiada publiczny adres IP i dokonuje połączeń do serwerów webowych w imieniu klienta. Tryb ten jest wymagany przez niektóre dodatkowe funkcje WAF. Minusem rozwiązania jest możliwość wprowadzenia opóźnień, które mogą powodować problemy z działaniem aplikacji.
W trybie Reverse Proxy możemy dodatkowo uruchomić (w zależności od producenta i konfiguracji) takie mechanizmy jak cache, kompresję, a także akcelerację ruchu SSL. W przypadku rozwiązań sprzętowych ta ostatnia czynność jest obsługiwana także przed hardware, co może znacznie przyspieszyć ten proces w porównaniu z wydajnością oferowaną przez serwer webowy. W środowiskach, w których korzystamy z klastrów przydadzą się także funkcje Load Balancingu i pulowania połączeń uruchomione w ramach WAF.
Możliwa jest konfiguracja firewalla webowego także w trybie monitora sieciowego. W takiej konfiguracji urządzenie pracuje jako sniffer ruchu sieciowego z portu monitoringu skonfigurowanego na przełączniku sieciowym. Jest to najlepszy tryb do testowania WAF w środowisku sieciowym. W dalszym ciągu możliwe jest także blokowanie niechcianego ruchu za pomocą resetowania połączeń TCP (spoofowany TCP RST).
Ostatnia możliwość konfiguracji WAF to uruchomienie go bezpośrednio na serwerze webowym – np. w postaci modułu, jak w przypadku otwartego ModSecurity. Takie rozwiązanie nie pozawala na implementacje dodatkowych funkcjonalności. Powoduje także dodatkowe obciążenie samego serwera, co należy wziąć pod uwagę w przypadku większego ruchu. Zaletą jest usunięcie dodatkowego punktu uszkodzenia z topologii sieci.
Komercyjne lub darmowe
Rynek rozwiązań Web Application Firewall jest dość bogaty. Produkty tej klasy ma w swojej ofercie większość firm zajmujących się bezpieczeństwem sieciowym. Spośród nich warto wymienić takie firmy jak: Baracuda (Baracuda Web Application Firewall), Cisco (ACE Web Application Firewall), Citrix (NetScaler Application Firewall), Fortinet (FortiWeb Web Security Appliance) czy Imperva (Web Application Firewall). Są to rozwiązania komercyjne dostępne jako dedykowane urządzenia appliance lub w postaci maszyn wirtualnych.
Narzędzia
komercyjne oferują dostęp do często znacznie bardziej rozbudowanych baz reguł, co ma oczywiście odzwierciedlenie w cenie samego rozważania (kilka, a nawet kilkadziesiąt tysięcy dolarów w zależności od konfiguracji).
Około 15–20 tys. zł za podstawowe modele appliance może wydawać się ceną dość wygórowaną dla segmentu małych i średnich przedsiębiorstw, jednak w przypadku firm, których działalność bazuje na internecie – np. dużych sklepów internetowych czy systemów transakcyjnych – warto ponieść taki koszt. Rozwiązania z wyższej półki cenowej to jak na polskie realia rozwiązania dla dużych firm i operatorów usług internetowych.
Niezależnie czy zainwestujemy w rozwiązanie komercyjne, czy w darmowe – do utrzymania systemu będzie potrzebna wykwalifikowana osoba, która będzie miała dobre rozeznanie także w specyfice działania naszych aplikacji webowych.
Nauka i reguły
Samo włączenie firewalla webowego na niewiele się zda bez implementacji w nim odpowiedniego zestawu reguł. Włączenie zbyt rygorystycznego, a przede wszystkim niedopasowanego zestawu reguł może spowodować za to nieprawidłowe działanie aplikacji. W praktyce proces integracji środowiska z systemem WAF jest dość pracochłonny.
Większość krytyki rozwiązań WAF jest spowodowana właśnie niepowodzeniami podczas tego procesu, który ze względu na czasochłonność oraz poziom skomplikowania – w przypadku dużych aplikacji – jest kluczowy dla powodzenia integracji.
Warto zacząć go od włączenia WAF w trybie obserwacji ruchu. W zamkniętym środowisku wykonamy wtedy wszelkie dozwolone akcje w aplikacji zgodnie ze scenariuszem testowym. Na podstawie zalogowanych informacji możemy stworzyć wyjściową listę reguł, która będzie bazować na „normalnych” z punktu widzenia aplikacji działaniach. Jest to metoda tworzenia reguł pozytywnych (postivie security). Następnie możemy włączyć tryb blokowania w WAF i zaobserwować, czy nie ma on wpływu na działanie aplikacji.
Kolejnym krokiem jest uruchomienie reguł negatywnych dla typowych ataków sieciowych. Reguły takie są dostarczane przez twórców oprogramowania i społeczność. Zderzenie tych reguł z aplikacją nieraz powoduje jej zupełne unieruchomienie. Podobnie jak przy tworzeniu zestawu bazowego, należy na podstawie logów z aplikacji zweryfikować,
które żądania powodują blokowanie i podjąć decyzję o modyfikacji oprogramowania albo samej reguły, jeśli mamy podejrzenie, że uruchamia się niepotrzebnie (tzw. wskazanie false positive). Liczba fałszywych alarmów może być w początkowej fazie integracji z WAF naprawdę duża. Nie należy się tym zrażać, tylko małymi krokami dążyć do celu.
Język reguł jest także bardzo dobrym narzędziem do tworzenia tzw. wirtualnych patchy. Czas wymagany na wytworzenie i zaaplikowanie poprawek do aplikacji webowych może być bardzo długi. Odpowiednio skonfigurowane reguły mogą ukryć podatność aplikacji bez konieczności wprowadzania jakichkolwiek zmian do jej kodu.
Praca nad regułami to proces ciągły
Przy tworzeniu i modyfikacji reguł firewalla webowego nie obejdziemy się bez współpracy z twórcami oprogramowania. Bez odpowiedniej znajomości samej aplikacji trudno będzie ocenić wpływ potencjalnych zagrożeń identyfikowanych przez WAF, a także zaplanować zmiany w kodzie.
Zakładając, że aplikacje webowe są obecnie bardzo szybko rozwijane, trzeba przyjąć, że kontakt z developerami będzie bardzo częsty.
Reguły mogą być definiowane za pomocą specyficznej składni używanej w konkretnym rozwiązaniu WAF. Część rozwiązań pozwala także na nieco wygodniejszą ich edycję za pomocą interfejsu graficznego. Nowe reguły lub wyjątki od nich można tworzyć na przykład na bazie zebranych logów aplikacji, co jest bardzo wygodnym rozwiązaniem w początkowym procesie konfiguracji reguł.
Dodatkowym ułatwieniem w opracowywaniu reguł z możliwością tłumaczenia ich między różnymi standardami jest narzędzie NTODefend. Stworzymy w nim reguły dla urządzeń Impreva, Baracudy, F5, a także dla modułu ModSecurity.
Podsumowanie
Każde nadrzędzie jest na tyle dobre, na ile potrafimy efektywnie z niego korzystać. Dobrze zarządzany Web Application Firewall po zasileniu odpowiednią bazą sygnatur i reguł może być bardzo przydatny w eliminowaniu zagrożeń dla aplikacji webowych. W zależności od potrzeb i możliwości możemy zastosować rozwiązanie darmowe lub komercyjne (appliance, wirtualne albo nawet w chmurze). W większości przypadków typowych stron czy systemów CMS wiele pomoże już dobrze skonfigurowany moduł ModSecurity dla Apache. Firmy, których działanie oparte jest na bezpiecznie działających systemach handlu, transakcji, których witryny odwiedzane są przez wielu użytkowników docenią dedykowane urządzenia appliance. Oprócz funkcji zabezpieczeń mają one także dodatkowe funkcjonalności podnoszące wydajność aplikacji webowych. Odpowiadając na tytułowe pytanie – Web Application Firewall to z pewnością ochrona, ale tylko w sytuacji, gdy do jego wdrożenia odpowiednio się przygotowaliśmy.
Źródło: Internet