WAF, czyli web application firewall na przykładzie ModSecurity

Web Application Firewall (w skrócie WAF) to rozwiązanie, które potrafi zapobiec wielu incydentom bezpieczeństwa związanym z atakami na aplikacje webowe. Wydawać by się mogło, że w czasach gdy większość systemów i usług dostępna jest za pomocą interfejsu webowego, WAF stanowić będzie podstawowe narzędzie bezpieczeństwa. Niestety tak nie jest. Mimo wielu głośnych incydentów polegających na włamaniach, wyciekach danych czy infekowaniu stron www, zabezpieczeniem w postaci WAF-a pochwalić może się tylko nieliczny odsetek dostawców usług.

Po co mi WAF?

Podstawowym zadaniem web application firewalla jest blokowanie podejrzanych zapytań wysyłanych do serwera www. Podejrzanych, czyli takich, które nie powinny się raczej pojawić jako wynik interakcji typowego użytkownika z webaplikacją.

Mogą to być nietypowe wartości pojawiające się w URL-u, takie jak np.:

https://adres_strony.pl/../../etc/passwd

Powyższe zapytanie wysłane do serwera może świadczyć o próbie wykorzystania luki typu path traversal (możliwość przeglądania zawartości systemu plików poprzez serwer www) do odczytania zawartości pliku „/etc/passwd”. Plik ten nie powinien być dostępny z poziomu serwera www, a próba jego odczytu w ten sposób może świadczyć o świadomym poszukiwaniu luki przez intruza.

Innym przykładem jest przekazywanie w zapytaniu podejrzanych parametrów, np:

https://adres_strony.pl?execute=/bin/bash

Powyższy przykład może stanowić próbę uruchomienia kodu po stronie serwera (w tym wypadku shella systemowego). Oczywiście w większości przypadków nie będzie to możliwe, ale znowu próba przekazania takiego zapytania do naszego serwera www będzie świadczyła o złych intencjach odwiedzającego naszą stronę.

Jeszcze inny przykład to próba umieszczania w formularzach na stronie www wartości mogących sygnalizować ataki typu SQL injections. Np. podanie jako nazwy użytkownika lub hasła któregoś z poniższych ciągów:

a' or 1=1--
"a"" or 1=1--"
or a = a
a' or 'a' = 'a
1 or 1=1

może skutkować ominięciem mechanizmu uwierzytelniania i uzyskaniem nieautoryzowanego dostępu do systemu. W tym wypadku również powinniśmy uznać, że tego typu ciągi nie powinny pojawić się w normalnej interakcji użytkownika z systemem.

I ostatni przykład – próba wykorzystania podatności typu XSS (cross site scripting), czyli przekazania do aplikacji kodu skryptu, który zostanie zapisany i wykonany podczas odwiedzania strony przez innych użytkowników:

<script>alert(document.cookie)</script>

Powyższy skrypt ma charakter testowy, spowoduje wyświetlenie okna z ciasteczkami aktualnego użytkownika, ale w realnych atakach mógłby zostać zmodyfikowany tak, by te ciasteczka wysłać do intruza.

Powyższe przykłady to zaledwie kilka bardzo podstawowych i raczej szablonowych zagrożeń, które powinny być blokowane z użyciem rozwiązania typu WAF. Większość (ale nadal nie wszystkie) współczesnych aplikacji będzie na nie odporna.

Należy jednak pamiętać, że strony www w Internecie podlegają nieustannemu skanowaniu przez różnej maści skrypty i botnety, które poszukują dużo bardziej zaawansowanych i mniej popularnych luk. Twórcy naszego systemu niekoniecznie muszą wiedzieć o ich występowaniu.

Kolejny powód, dla którego powinniśmy zainteresować się web application firewallem to brak aktualizacji lub wsparcia dla starszych systemów. Dobrym przykładem jest tutaj wykryta pod koniec 2021 roku podatność „log4j” występująca w bibliotece używanej masowo przez wielu dostawców oprogramowania. Jeśli nasz system nie może zostać zaktualizowany, to z pomocą przyjdzie nam WAF, który posiada sygnatury najnowszych zagrożeń i będzie potrafił zablokować próby ich wykorzystania.

Jaki WAF wybrać?

Na rynku jest cała masa rozwiązań zarówno komercyjnych, jak i dostępnych bezpłatnie. WAF może stanowić dodatkową funkcjonalność w rozwiązaniach typu firewall/UTM lub serwerach web proxy. Za tę funkcjonalność najczęściej trzeba oczywiście dodatkowo zapłacić.

Jednak nawet w płatnych produktach komercyjnych dostawców spotkać można często rozwiązania dostępne jako projekty open source, do których dany producent dorobił jedynie nieco przyjaźniejszy interfejs. Dlatego też nie będę tutaj polecał żadnego konkretnego dostawcy. WAF-a znajdziecie na pewno w rozwiązaniach firm Fortinet, Cisco, PaloAlto i wielu, wielu innych.

Zdecydowanie najpopularniejszym web application firewallem dostępnym na zasadach Wolnego Oprogramowania jest natomiast ModSecurity.

ModSecurity

WAF ten powstał początkowo jako moduł (mod_sec) do najpopularniejszego serwera www – Apache. Z czasem ewoluował jednak jako niezależny projekt i obecnie dostępny jest również dla serwerów Nginx czy IIS.

Instalacja ModSecurity nie powinna przysporzyć większych problemów osobom zajmującym się utrzymaniem serwerów www. Nie będę jej tutaj szczegółowo opisywał ze względu na mnogość możliwych konfiguracji i systemów, ale w wielkim skrócie cała operacja ogranicza się do zainstalowania pakietu, skopiowania domyślnego pliku konfiguracyjnego i ewentualnie drobnych modyfikacji w tym pliku.

Należy jedynie pamiętać, że domyślnie ModSecurity działa w trybie powiadamiania, a nie blokowania zagrożeń. Aby to zmienić powinniśmy w pliku konfiguracyjnym modsecurity.conf znaleźć poniższy wpis:

SecRuleEngine DetectionOnly

I dokonać jego zmiany do poniższej postaci:

SecRuleEngine On

Na zachętę zerknijcie na tę instrukcję dla systemu Ubuntu/Debian – według niej jesteście w stanie uruchomić swojego WAF-a w kilkanaście minut.

OWASP Core Rule Set dla WAF

Sam WAF to jednak nie wszystko. Bardzo istotną kwestią jest zaopatrzenie go w odpowiednie i przede wszystkim aktualne reguły filtrowania. I tutaj z pomocą przychodzi nam na szczęście projekt OWASP ModSecurity Core Rule Set (CRS).

W ramach tego projektu tworzona jest baza zawierająca tysiące reguł filtrowania obejmujących wszystkie popularne i znane zagrożenia. Jej zaaplikowanie znowu ogranicza się do pobrania kilku plików i drobnych zmian konfiguracyjnych. Jak to zrobić dowiecie się m.in. z linkowanej w poprzednim punkcie instrukcji dla systemów Ubuntu. W przypadku pozostałych systemów będzie to w praktyce wyglądało bardzo podobnie.

Podobnie jak w przypadku samego ModSecurity, domyślną akcją dla reguł w ramach CRS jest raportowanie. Aby próby złośliwej komunikacji były zamiast tego blokowane przez WAF należy pamiętać o ważnej zmianie w pliku konfiguracyjnym crs-setup.conf. Należy w nim zmienić dwie poniższe linie:

SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"

na następujące:

SecDefaultAction "phase:1,log,auditlog,deny,status:403"
SecDefaultAction "phase:2,log,auditlog,deny,status:403"

Dzięki temu wszelkie podejrzane próby komunikacji z naszym serwerem będą odrzucane ze statusem błędu 403 (dostęp zabroniony).

O czym jeszcze warto pamiętać?

ModSecurity domyślnie blokuje jedynie zapytania, które z dużym prawdopodobieństwem uznać można za podejrzane. Podobnie jednak jak w przypadku innych rozwiązań security (np. antywirusy czy firewalle) zdarzyć się mogą tzw. false positivy, czyli zablokowane prawidłowe żądania lub treści.

Jeśli uruchamiacie WAF-a na produkcyjnym systemie zdecydowanie powinniście przez dłuższy czas potestować go w trybie alertowania, zamiast blokowania. Dzięki temu będziecie mieli możliwość prześledzenia logów pod kątem alertów dotyczących prawidłowych zapytań.

Czy rzeczywiście potrzebuję WAF-a?

Jeśli nie jesteście pewni, czy web application firewall jest wam rzeczywiście potrzebny, to może przekona was trochę statystyk. Niedawno na potrzeby pewnego projektu uruchomiłem nowy serwer www. Nie był on nigdzie w Internecie reklamowany czy linkowany, nie miał jeszcze nawet przypisanej domeny. W ciągu doby od jego uruchomienia WAF ModSecurity z regułami OWASP CRS zablokował 688 prób podejrzanej komunikacji z systemem.

Co to oznacza? Dzisiaj każdy wystawiony do Internetu system zostanie w ciągu kilku godzin namierzony przez złośliwe skrypty bądź botnety, które będą go regularnie próbowały atakować. Musicie o tym pamiętać, jeśli bezpieczeństwo traktujecie poważnie.

Na koniec jeszcze drobna porada – jeśli nie utrzymujecie własnych serwerów www, a korzystacie z rozwiązań hostingowych, zorientujcie się czy wasz dostawca nie świadczy usługi typu WAF. Wiele, również polskich firm hostingowych oferuje takie rozwiązania. Często są one nawet bezpłatne, wystarczy w ustawieniach swojego panelu hostingowego włączyć ochronę WAF.

Obserwuj

Obserwuj