SafeLine – skuteczna ochrona aplikacji internetowych przed atakami

Oprogramowanie WAF (Web Application Firewall) jest przeznaczone do filtrowania i blokowania różnych form ataków wymierzonych w aplikacje internetowe. Przykładami są m.in. ataki XSS, SQL injection, SSRF, path traversal, DDoS. WAF może być dostarczany przez wyspecjalizowane urządzenia sieciowe – jest to często spotykane w środowiskach o większej skali, wymagających odpowiedniej przepustowości, gdzie dostępność jest wymagana przez niemal cały czas – bądź przez zainstalowane na dedykowanym (osobnym) serwerze oprogramowanie. W najczęściej spotykanych architektach WAF to jedyny element dostępny z poziomu sieci internetowej. Ruch wejściowy (po analizie „bezpieczeństwa”) następnie jest kierowany bezpośrednio do serwera aplikacyjnego lub też do load balancera – niezależnie jednak od podejścia, dostęp do serwerów aplikacyjnych i uruchomionych usług możliwy jest wyłącznie z poziomu sieci wewnętrznej.

Korzystanie z WAF jest jak najbardziej dobrą praktyką i zalecanym podejściem. Nie można jednak stwierdzić, iż to konieczne rozwiązanie, bez którego nie powinniśmy udostępniać aplikacji. Wszystko zależy od konkretnych przypadków. Krytyczne aplikacje zdecydowanie powinny mieć zapewnioną dodatkową warstwę ochrony, ale nie wydaje się, żeby proste blogi czy tzw. strony wizytówki wymagały aż tak złożonych zabezpieczeń. Z drugiej strony nie wyobrażam sobie, aby przykładowy blog lub serwis z informacjami działał na przestarzałym systemie CMS – administracja jakąkolwiek aplikacją wymaga podejmowania rozsądnych działań i doboru odpowiednich zabezpieczeń.

Wdrożenie urządzeń pełniących rolę WAF z reguły wiąże się z dużymi kosztami. Same urządzenia mogą kosztować choćby kilkaset tysięcy złotych, a ich adekwatna konfiguracja nie jest tak naprawdę łatwa – często wręcz wymaga zaangażowania dedykowanego wsparcia technicznego. Inną opcją jest wspomniane uruchomienie WAF na własnym serwerze. Jednym z bardziej popularnych rozwiązań jest SafeLine. Już bezpłatna wersja zapewnia wyjątkowe interesujące możliwości, a konfiguracja choćby złożonych mechanizmów (takich jak SSO) ogranicza się do kilku prostych kroków.

Uruchomienie SafeLine

Wszystkie komponenty SafeLine dostarczane są jako kontenery Docker, co w znacznym stopniu ułatwia cały proces, jak również redukuje czas, jaki byłby potrzebny na manualne uruchamianie potrzebnych usług. Co więcej, autorzy przygotowali skrypt Python, który wykonuje instalację Docker’a i uruchomienie SafeLine – jednak nie jest to szczególnie przydatne w praktyce, tym bardziej iż nie działa prawidłowo na niektórych systemach. Instalacja Docker nie jest dużym wyzwaniem. Gotowa instrukcja wdrożenia SafeLine znajduje się w dokumentacji pod tym adresem.

Trzeba w tym miejscu zaznaczyć, iż daemon Docker automatycznie dodaje reguły firewall. Jednak w pliku compose.yaml nie wskazano jawnie portów dla serwisu safeline-tengine (zresztą jest ustawiony network_mode: host). Jest to w pełni uzasadnione rozwiązanie, ponieważ aplikację możemy uruchomić na dowolnym porcie TCP – pewnie w znakomitej większości przypadków będą to porty 80 i 443. W związku z tym odpowiednie reguły firewall działającego w ramach systemu operacyjnego należy dodać we własnym zakresie. Bardzo ważne jest zrozumienie, iż „z zewnątrz” powinny być dostępne wyłącznie porty, pod którymi dostępna będzie aplikacja. Rekordy DNS powiązane z aplikacją powinny dodatkowo wskazywać na zewnętrzny adres IP serwera WAF – to jest istotne zwłaszcza w sytuacji, gdy serwer aplikacyjny także jest dostępny z zewnątrz (przykładowo publiczny hosting WWW). Całość ruchu HTTP/HTTPS musi być obsługiwana przez WAF.

Oprócz pobrania pliku compose.yaml trzeba przygotować plik .env w tej postaci:

Można teraz uruchomić kontenery standardowym poleceniem docker compose up -d. Wszelkie konfiguracje będą przechowywane w katalogu /data/safeline, dzięki czemu sprawnie będzie można całkowicie „usunąć” SafeLine bądź przywrócić działającą konfigurację z kopii zapasowej.

Panel zarządzania będzie dostępny na porcie 9443 (HTTPS).

Hasło potrzebne do pierwszego zalogowania trzeba zresetować poleceniem resetadmin.

Po zalogowaniu zobaczymy przejrzysty interfejs bez nadmiarowych opcji, których ilość mogłaby zniechęcić do korzystania z SafeLine. Można przyznać, iż interfejs prezentuje się bardzo dobrze. Najlepiej od razu zmienić hasło wchodząc w zakładkę Settings i dalej w kartę MANAGEMENT. W sekcji Manager User będzie tylko jedna pozycja (dodanie kolejnego użytkownika dostępne jest w wersji płatnej) – admin – przy której wybieramy ikonę kropek i opcję EDIT. Zobaczymy zwykły formularz zmiany hasła, po którego zapisaniu zostaniemy wylogowani.

Działanie WAF i dodawanie aplikacji

Najczęściej spotykane podejście wygląda tak, iż WAF/load balancer obsługuje ruch HTTP i HTTPS, kierując zapytania do serwera aplikacyjnego wystawiającego daną usługę nieszyfrowanym protokołem. W SafeLine jest to jak najbardziej możliwe, natomiast może pojawić się problem związany z niedostępnością nagłówka X-Forwarded-Proto w wersji bezpłatnej. Jest to aż zabawny fakt, iż akurat taka opcja została uznana za funkcjonalność „premium”, ale obejście jest proste – wystarczy dodać dwie „osobne” aplikacje: jedną dla portu nieszyfrowanego, a drugą dla szyfrowanego (wtedy serwer aplikacyjny musi niestety wystawiać oba porty albo korzystać z lokalnego reverse proxy). Oczywiście tak postąpić należy tylko w przypadku, gdy aplikacja działająca w sieci wewnętrznej rozróżnia protokoły http i HTTPS – przykładowo WordPress nie załaduje poprawnie zasobów, gdy zapytania HTTPS będą kierowane na port HTTP (bez wymienionego nagłówka X-Forwarder-Proto). Jednak nie w każdym przypadku takie obejścia będą uzasadnione i potrzebne.

Aplikacje dodajemy w zakładce APPLICATIONS. Zwracam uwagę na domyślnie zawarty w formularzu wildcard – optymalne jest pozostawienie samej nazwy naszej domeny (zapytania do adresu IP serwera WAF czy też nieobsługiwanych domen będą kończyć się wtedy komunikatem o błędzie, co jest dobrą praktyką). Dla HTTPS trzeba dodać certyfikat – pojawi się przycisk Add new cert otwierający nową kartę z adekwatnymi ustawieniami. Certyfikat należy wygenerować wcześniej lub skorzystać z Let’s Encrypt bezpośrednio z poziomu panelu SafeLine.

Zalecane jest włączenie access i error log’ów wchodząc w DETAIL danej aplikacji i dalej w pozycjach ACCESS LOG/ERROR LOG zaznaczając checkbox i potwierdzając wybór.

Ochrona przed atakami

W tym momencie aplikacja jest już chroniona. Wybrane rodzaje ochrony można dostosować po wejściu w ATTACKS w ustawieniach konkretnej aplikacji. W zasadzie można pozostać na ustawieniach domyślnych. jeżeli jednak zauważmy, iż nasza aplikacja nie działa z jakiegoś powodu poprawnie (błędna klasyfikacja zapytania – false positive – może rzecz jasna wystąpić), to w takim wypadku najlepiej wybrać Audit Mode przy danym rodzaju ataku). Skończy się to odnotowaniem faktu „wykrycia” w logach, ale samo żądanie zostanie przekazane do serwera z aplikacją. W większości sytuacji domyślny Balance Mode będzie raczej najlepszym wyborem.

Ruch do aplikacji obsługiwany jest przez nginx dostarczany wraz z SafeLine. Widać, iż to „utwardzona” konfiguracja, bo zbędne nagłówki zwykle zwracane przez serwery HTTP nie są widoczne.

Aby sprawdzić działanie ochrony, uruchomiłem skanowanie narzędziem Nessus. Po chwili w zakładce Attacks pojawiły się wpisy świadczące o wykryciu i (ewentualnie) zablokowaniu próby. Nie wszystkie zapytania były blokowane, bo ich skutek niekoniecznie byłby jakkolwiek złośliwy.

Ograniczenia ruchu wejściowego i blokowanie żądań

SafeLine zapewnia również możliwość ochrony przed atakami DDoS. Odpowiednie opcje znajdują się w ustawieniach aplikacji po wejściu w HTTP FLOOD. Parametry można dostosować poprzez wybór CUSTOMIZE i edycję wybranych ustawień. Tutaj dla przykładu zmniejszyłem ilość requestów ze 100 do 10 w Basic Access Limit.

Warto wspomnieć, iż architektura z jednym serwerem aplikacyjnym nie będzie wystarczająca w przypadku mocno obciążonych środowisk. Istnieją odpowiednie praktyki high availibility i balansowania ruchu, które w tych sytuacjach należałoby wdrożyć. Natomiast zastosowanie ograniczenia dostępu dla adresów IP wykazujących „nadmierną” aktywność także ma znaczenie i choćby tak trywialna ochrona (blokowanie dostępu po przekroczeniu pewnej ilości żądań w danej jednostce czasu) może sprawdzić się całkiem dobrze.

Ochrona przed scrappingiem i znaki wodne

SafeLine oferuje świetne rozwiązanie do stosowania w celu uniemożliwienia automatycznej analizy kodu HTML naszej aplikacji i wydobywania określonych danych (scrapping). W tym celu przed załadowaniem adekwatnego kodu HTML/CSS/JavaScript wykonywana jest dynamiczna obfuskacja. Inną interesującą opcją jest możliwość dodawania znaków wodnych do grafik (w wersji bezpłatnej nie można ustawić własnych napisów) – to również wykonywane jest „w locie”. Użytkownik końcowy przed załadowaniem treści aplikacji zobaczy odpowiedni komunikat.

Wszystkie związane z tym opcje znajdziemy w BOT PROTECT. Aktywowałem Anti-Bot Challenge, „szyfrowanie” kodu HTML i funkcję Picture dynamic watermark.

Od tej pory wszystkie grafiki umieszczone w naszej aplikacji będą widoczne ze znakiem wodnym. Wygląda to w ten sposób:

Działanie funkcji obfuskacji kodu najlepiej zaprezentować porównując obie wersje – bez włączonej „dynamic encryption” i z aktywną opcją.

Przed załadowaniem aplikacji wyświetlany jest następujący komunikat.

Obsługa logowania i SSO

Kolejną możliwością dostępną w SafeLine jest obsługa logowania do aplikacji. Może to być forma kontroli dostępu, jeżeli przykładowo nasza aplikacja z jakiegoś powodu nie zapewnia takiej funkcji. Oprócz zwykłego formularza logowania SafeLine posiada też wsparcie dla SSO, które możemy w łatwy sposób ustawić.

Najlepiej zacząć od dodania użytkownika w zakładce Auth wybierając SETTINGS i oczywiście ADD USER.

Pozostałe wymagane czynności należy przeprowadzić już w ustawieniach danej aplikacji – AUTH. Jak jednak widać, nie stanowi to znaczącej trudności.

Krótkiego wyjaśnienia wymagają opcje Need to approve access i Access directly after authentication. Pozostawienie domyślnego wyboru, czyli pierwszej z tych opcji, spowoduje, iż każde logowanie będzie oznaczało konieczność zatwierdzenia przez administratora SafeLine w zakładce Auth. Z reguły już samo logowanie będzie wystarczającym zabezpieczeniem, dlatego lepiej użyć drugiej opcji.

Panel logowania nie jest może zachwycający z perspektywy bieżących trendów projektowania serwisów internetowych, natomiast spełnia swoje zadania.

Bardziej zaawansowanym sposobem logowania dostępnym w SafeLine jest SSO (Single Sign-On). W tym przypadku proces logowania realizowany jest w ramach osobnej, dedykowanej domeny, co wygląda profesjonalnie. Próba dostępu do aplikacji ze skonfigurowanym SSO użytkownika, który nie został „zautoryzowany”, zakończy się przekierowaniem na dodaną domenę przeznaczoną dla SSO i wymogiem zalogowania.

W AUTH wystarczy wybrać SSO i dalej click to go, co otworzy nową kartę z odpowiednimi ustawieniami. Aktywujemy SSO i podajemy wymagane informacje. Certyfikat należy dodać w sposób analogiczny do konfiguracji domeny. Modyfikacja logo czy kolorystyki strony SSO dostępna jest w wersji premium.

Po dodaniu SSO w ustawieniach aplikacji pozostaje wybrać tę formę logowania.

Zgodnie z opisem logowanie odbywa się teraz pod osobną domeną.

Podsumowanie

WAF to istotny element bezpieczeństwa aplikacji internetowych. Nie można polegać całkowicie na jednym zabezpieczeniu – nic nie zapewni idealnej skuteczności, a dodatkowo możliwe są wykrycia false positive – natomiast wdrożenie i prawidłowa konfiguracja WAF będzie krokiem w odpowiednią stronę pod kątem ogólnego bezpieczeństwa. Warto zaznaczyć, iż SafeLine w testach wykazał większą skuteczność od bezpłatnego planu Cloudflare.