Web Applications Firewall to zabezpieczenie używane do wykrywania ataków na aplikacje webowe. Zapory te stanowią rozszerzenie dotychczas używanych systemów bezpieczeństwa, np. zapobiegania włamaniom na zasoby dostępne w internecie.

Niezabezpieczone aplikacje webowe to jedna z najłatwiejszych dróg dla hakerów, aby dostać się do zasobów korporacyji. Często są one podatne na wiele zaawansowanych ataków np.. SQL injection. Konieczne jest więc zabezpieczenie infrastruktury internetowej i zapewnienie wysokiej dostępności serwisów WWW, aby zredukować koszty i zapewnić ciągłość biznesową. Sugerowanym rozwiązaniem jest stosowanie aplikacyjnych zapór sieciowych WAF (Web Application Firewall). Obecnie dominują na rynku autonomiczne WAF. Postępuje jednak ich integracja z innymi zabezpieczeniami. Są oferowane jako rozwiązania instalowane w środowisku użytkownika lub jako usługa w modelu chmurowym.

Dotychczas wdrażanie zapór typu WAF hamowało przekonanie firm, że są one nieadekwatne do ochrony przed atakami, jak również skomplikowane w zarządzaniu. To jednak się zmienia. Przeprowadzone w tym roku badanie przez firmę analityczną Wisegate pokazało, że aż 26% firm wymienia zapory WAF jako główny priorytet w obszarze bezpieczeństwa. Częściej wskazywano tylko na zabezpieczenia informacji. To sugeruje przesunięcie nacisku z ochrony urządzeń w kierunku bezpieczeństwa aplikacji i danych. .
Zmiana akcentów wynika z przechowywania coraz większej ilości informacji w chmurze i aplikacjach internetowych. Dlatego ich ochrona staje się głównym priorytetem.

Jak działa Web Applications Firewall

WAF chroni aplikacje webowe przed atakami z Internetu, którym nie potrafią zapobiec systemy IPS czy zwykłe Firewall’e. Podobnie, jak systemy zapobiegania włamaniom, WAF występują w wersji sieciowej lub instalowanej lokalnie w urządzeniu. Mogą występować np. w formie modułu do danego serwera WWW. Są podłączone do interfejsu sieciowego i analizują komunikację przychodzącą do aplikacji internetowej i wychodzącą z niej. W odróżnieniu od systemów IPS, są w stanie analizować ruch w warstwie 7, warstwie aplikacji właśnie oraz rozszyfrowywać ruch zaszyfrowany (np. SSL) z którym nie radzą sobie inne urządzenia sieciowe.

IPS porównuje ruch z sygnaturami zagrożeń oraz wyłapuje anomalie. Z kolei WAF analizuje zachowania oraz logikę komunikacji z aplikacją. Analizuje jakie przychodzą żądania i jakie są odpowiedzi aplikacji. W ten sposób chroni aplikacje webowe przed takimi zagrożeniami, jak wstrzykiwanie kodu SQL, XSS (Cross-Site Scripting), przejmowania sesji, modyfikowanie adresów URL oraz przepełnienie bufora. Odbywa się to w taki sam sposób, jak w przypadku IPS. Analizowany jest każdy przechodzący pakiet.

Zapory WAF są z reguły „umieszczane” – podobnie jak serwery proxy – przed aplikacją webową. W takiej architekturze nie przechodzi przez nie cały ruch odbywający się w sieci lokalnej. Monitorując komunikację WAF może sprawdzić żądania przed przekazaniem ich do aplikacji. Jest to istotna przewaga tego zabezpieczeń nad IPS. Ponieważ systemy zapobiegania włamaniom zostały zaprojektowane tak, aby analizować cały ruch sieciowy, nie potrafią zbyt dokładnie sprawdzać komunikacji w warstwie aplikacji.

Możliwość zapobiegania nieznanym typom zagrożeń

Web Applications Firewall nie tylko wykrywa znane ataki, ale jest też w stanie wykryć i zapobiec nowym, nieznanym typom zagrożeń. Szukając nietypowych – lub niespodziewanych – wzorców w ruchu sieciowym, WAF mogą ostrzegać o nieznanych atakach, a także automatycznie bronić przed nimi. Przykładowo, jeśli Web Applications Firewall wykryje, że aplikacja zwraca znacznie więcej – niż w typowym przypadku – danych, to może zablokować komunikację i powiadomić administratora.

WAF umożliwia również kontrolowanie ruchu z wykorzystaniem wcześniej przygotowanych reguł, które administrator może tworzyć według dwóch zasad. Pierwsza to czarna lista – reguły wskazują, jaka komunikacja jest niebezpieczna i należy ją zablokować, zmienić lub zarejestrować dane zdarzenie w logach. Druga to biała lista – wymaga utworzenia reguł wskazujących na akceptowane treści, które zostaną przepuszczone, a cała reszta ruchu dokładnie przeanalizowana i zablokowana gdy będzie taka konieczność , zmodyfikowana lub zarejestrowana w logach.

Czarna lista umożliwia zapobieganie wykorzystaniu wykrytych podatności bez modyfikowania aplikacji. Z kolei białe listy lepiej blokują nieznane ataki, ponieważ zatrzymują cały ruch poza dozwolonym przez administratora. Ta funkcjonalność wymaga jednak znacznie większego nakładu pracy.

Kryteria wyboru rozwiązań klasy WAF

Wielu administratorów podejmuje decyzje zakupowe wyłącznie na podstawie konkretnych wymogów czy dostępności funkcji, która przypadła im do gustu. Prawdopodobnym rezultatem takiego postępowania będzie wybór nieodpowiedniego – lub nieoptymalnego – rozwiązania. Nawet krótki termin na podjęcie decyzji nie zwalnia z przeprowadzenia rozeznania wśród dostępnych produktów. Aby trafnie wybrać zaporę WAF, warto odpowiedzieć sobie na kilka pytań: Jakie dodatkowe usługi mogą okazać się przydatne? Jak nowe zabezpieczenie wkomponuje się w istniejącą sieć? Czy w firmie jest osoba mającą odpowiednie kwalifikacje do zarządzania takim produktem? Jaki wpływ będzie miało nowe zabezpieczenie na istniejące usługi i użytkowników? Jaki będzie jego koszt? Czy w przyszłości planowane są dodatkowe inwestycje np. zwiększenie ilości aplikacji internetowych albo zwiększenie przepustowność internetu?

Dobrze zdefiniowana, firmowa polityka bezpieczeństwa powinna zawierać cele i wymagania dotyczące zabezpieczania danych. Mając taką podstawę, można trafnie wskazać, jakie zabezpieczenia są potrzebne, aby spełnić te wymagania. Ponieważ każda aplikacja webowa jest unikalna, również zabezpieczenia muszą być skrojone do jej wymogów. Dzięki temu będą lepiej zabezpieczać przed możliwymi zagrożeniami (np. rozpoznanymi podczas tworzenia tej aplikacji). Znając potencjalne zagrożenia, można wybrać taką zaporę WAF, która będzie przed nimi najlepiej chronić, np. analizować parametry przekazywane w adresach URL lub plikach cookies czy chronić przed podatnościami z listy OWASP Top 10.

 

Podziel się na:
  • Facebook
  • Google Bookmarks
  • LinkedIn