Niebezpiecznik

W poprzednich artykułach z cyklu Poradnik Hackera Weaplikacji poruszyliśmy temat zabezpieczania aplikacji “od strony kodu”. Dziś na tapet weźmiemy inne podejście: dodatkowa ochrona webaplikacji poprzez usługę typu Web Firewall. Wykorzystamy do tego darmowe konto na Cloudflare.

Aby nie przegapić kolejnych artykułów z serii “Poradnik Hackera Webaplikacji”, które są poświęcone narzędziom i technikom pomagającym w zabezpieczaniu serwisów internetowych przed atakami, zapisz się do naszego tematycznego newslettera — poza powiadomieniami o kolejnych artykułach otrzymasz od nas także dodatkowe przydatne materiały (linki, narzędzia i infografiki), które wysyłać będziemy tylko subskrybentom tego newslettera e-mailem (nie zostaną opublikowane na Niebezpieczniku).

Wpisz adres e-mail:

Rozwiąż Captcha:

HP

Bez obaw, podanych e-maili nikomu nie przekazujemy i wykorzystamy je wyłącznie do przekazywania Ci treści związanych z cyberbezpieczeństwem. Jeśli lubisz czytać o RODO, kliknij tutaj.

Do czego można użyć Cloudflare’a?

Klasyczne ataki jakie mogą nam grozić, to np:

• ataki DDoS
• ataki XSS, SQL Injection, itp.
• ataki siłowe (słownikowe/bruteforce)
• skanowanie nazw plików i katalogów
• ataki spamerów (spamerskie komentarze, zakładanie fake kont w systemie, itp.)

Przed częścią tych zagrożeń Cloudflare ochroni nas automatycznie. Nie musimy niczego aktywować, aby w przypadku ataków DoS/DDoS Cloudflare przejął na siebie cały ruch. Tak po prostu dzieje się domyślnie, choć niekoniecznie dotyczy to wszystkich typów ataków. Ale z syn-flood sobie poradzi.

Jeśli z jakiegoś powodu domyślne ustawienia wykrywania ataków nie sprawdzają się w Twoim przypadku, to możesz je zmienić w sekcji panelu Firewall -> DDoS. Możesz tam także zdecydować, czy ataki chcesz zupełnie blokować, czy może wolisz wyświetlać atakującym CAPTCHĘ do rozwiązania (to drugie wyjście zabezpieczy Cię przed ewentualnym false-positive).

Aby porządnie zabezpieczyć się przed niektórymi atakami, np. XSS/SQLi, konieczne będzie wykupienie komercyjnego planu w Cloudflare (wersja PRO) i aktywowanie tzw. WAFa (Web Application Firewall) w sekcji Firewall -> Managed Rules:

Ale naprawdę sporo dobrego można zrobić w wersji darmowej. I to na niej się skupimy poniżej.

Włącz blokowanie atakujących

Twoje centrum zarządzania blokadami znajduje się w zakładce Firewall -> Firewall Rules. Komunikat jaki tam zobaczysz, może na początku Cię lekko zaskoczyć. W darmowej wersji masz do wykorzystania tylko 5 reguł firewalla. Dobra wiadomość jednak jest taka, że reguły te mogą być tak mocno rozbudowane (i mogą być warunkowe), że w praktyce wystarczy Ci jedna 🧅

Jeśli będziesz w trakcie ataku na stronę, to najszybszą metodą obrony, pomijającą jakąkolwiek konfigurację jest włączenie trybu “Under Attack”. Robisz to w menu “Overwiew -> Under Attack Mode”. Aktywowanie tego trybu sprawia, że wszyscy odwiedzający Twoją stronę przechodzą przez stronę odsiewającą boty:

Dzięki temu, cały zalew zapytań HTTP najpierw uderza w serwery Cloudflare, a następnie wymagane jest rozwiązanie zadania w JavaScript. Dopiero wtedy przechodzi się do Twojej strony. Rozwiązanie to choć skuteczne, jest skrajnie nieprzyjazne dla użytkownika. Traktuj je więc jako ostatnią deskę ratunku.

Jak w takim razie zrobić to dobrze? Regułami firewalla! Ale wcześniej trzeba namierzyć kto Cię atakuje i w jaki sposób. Odpowiedz sobie na szereg pytań:

• czy ataki pochodzą z konkretnego kraju? (np. Filipiny, Tajwan)
• czy atakuijący mają podobnie wyglądające do siebie adresy IP? (np. 1.2.3.4, 1.2.3.50 i 1.2.3.222)
• czy podejrzane zapytania mają jakąś cechę wspólną? (np. ten sam user-agent albo język ustawiony w przeglądarce albo stale odświeżają tego samego URLa)

Załóżmy, że atakują Cię boty z Filipin oraz z Tajwanu. Aby je zablokować wejdź w “Firewall -> Firewall Rules” i dodaj nową regułę jak poniżej:

Dodatkowo załóżmy, że życie wyjątkowo uprzykrza Ci człowiek posługujący się adresem IP: 65.21.224.90 (losowy przykład). W takim przypadku rozbudujmy zbiór reguł o nową pozycję – zwróć uwagę na warunek “OR”.

Załóżmy, że nasz przeciwnik zorientował się, że jest blokowany i szybko zaczął łączyć się z adresu 65.21.224.95, który od poprzedniego różni się tylko jedną cyfrą. Możemy więc spróbować zablokować całą podsieć, np. z maską /24. Oto reguła po modyfikacjach — zwróć uwagę, że aby korzystać z maski, nie można użyć warunku ‘equals’, a trzeba zmienić go na ‘is in’.

Atakujący jednak nie daje za wygraną i znów pojawia nam się w logach, tym razem z adresu 5.9.98.123. Ten adres na pierwszy rzut oka nie ma nic wspólnego z poprzednim, ale czy aby na pewno?

Po rzucie oka na dane z WHOIS widzimy, że oba z tych adresów hostowane są w data center Hetznera. Niestety Hetzner ma setki tysięcy adresów i trudno byłoby nam napisać regułę lub maskę, która mogłaby je wszystkie objąć.

Ale… możemy posłużyć się numerem ASN, do którego podpięte są te adresy IP. Informację na jego temat znajdziesz również w bazie WHOIS. Szukaj ciągu znaków zaczynającego się od ‘AS’ i posiadającego po sobie duży numer.

Zmieńmy więc naszą regułę tak, aby odciąć całą serwerownię (czego oczywiście nie zalecamy, ale niekiedy nie ma wyboru). Zwróć uwagę, że do reguł dodaje się sam numer, bez liter ‘AS’ na początku.

Okazuje się, że i tym razem atakując był przebiegły — w odpowiedzi na nasze ruchy, zaczął korzystać z sieci TOR. Jak odciąć wszystkie węzły TORa od naszego serwera? Wielu początkujących użytkowników może dojść do wniosku, że nie da się tego osiągnąć, bo niezwykle trudno odnaleźć taką opcję. Jest ona jednak ukryta w sekcji… Country.

Na końcu kreatora tworzenia reguł znajduje się definicja akcji, którą ma podjąć Cloudflare. Mamy dostępne trzy akcje, które mogą nam pomóc w walce z atakującymi:

• block – zupełne wycięcie tego ruchu (error 403)
• JS Challenge – wpuści tylko ludzi/boty obsługujące javascript. Idealnie nadaje się do odsiewania bardzo prostych zautomatyzowanych ataków i skanerów
• Challenge (Captcha) – użytkownik/bot dostaje kod do przepisania lub zadanie do wykonania (wskaż witryny sklepów, mosty itp).

Najskuteczniejsza będzie oczywiście pierwsza opcja, ale może ona wyciąć także sporą część legalnego ruchu (jeśli reguły aktywujące firewall zostały źle napisane). Zakładając jednak, że wszelkie filtry zostały poprawnie ustawione, sugeruję aktywować opcję trzecią, którą zobaczą tylko źli ludzie (albo złe boty)

Po minimum kilkunastu minutach od wdrożenia nowej reguły firewalla, przejdź na zakładkę  “Firewall -> Firewall Rules” i obserwuj tam wskaźnik CSR. Jest to współczynnik przedstawiający jaki procent odwiedzających rozwiązało captchę/challenge w stosunku do tego jaki procent ją dostał. Jeśli wskaźnik ten jest niepokojąco wysoki (kilkadziesiąt procent), może to oznaczać, że błędnie zdefiniowałeś reguły firewalla i prawie każdy odwiedzający jest traktowany jako atak. Staraj się utrzymać ten wskaźnik na możliwie niskim poziomie (najlepiej, aby nie przekraczał 1-2%).

Biała lista
Jeśli chcesz dodać do zaufanych adresów swoją własną lokalizację lub np. adresy VPNa czy VPSa z którego często korzystasz, to możesz to zrobić w zakładce “Firewall -> Tools”. Jest to bardzo ważne, zwłaszcza, gdy wystawiasz API dla zewnętrznych partnerów, które mogłoby być “zakryte” np. captchą w chwili uruchomienia ‘Under Attack Mode’.

Dodatkowe usprawnienia

W panelu Cloudflare znaleźć można jeszcze kilka modułów, które mogą pozytywnie wpłynąć na działanie naszej aplikacji. Możemy np. wymuszać połączenie po HTTPS dla całej domeny i wszystkich plików na niej się znajdujących. Od strony programistycznej osiąga się to dodając przekierowanie z wersji HTTP na HTTPS oraz dorzucają nagłówek HSTS (Hypertext Strict Transport Security) do odpowiedzi serwera.

Aby to zrobić, wejdź do sekcji “SSL/TLS -> Edge Certyficates” i aktywuj kolejno:

Always use HTTPS
Hypertext Strict Transport Security (HSTS)
Automatic HTTPS Rewrites

Ochrona przed scrapingiem

Jeśli prezentujesz na swojej stronie sporo danych, które są łakomym kąskiem dla wszelkiego rodzaju scraperów, to możesz aktywować ochronę przed takimi robotami. Robisz to ustawiając odpowiednie opcje w sekcji “Scrape Shield”.

Szczególnie interesującą może być opcja “Server-side-excludes” (SSE), która potrafi ukrywać niektóre fragmenty strony przed robotami. Praktyczne wdrożenie (po włączeniu jej w panelu) tej funkcji może wyglądać np. tak:

<!--sse-->
tutaj formularz kontaktowy lub dowolne dane, którymi może być zainteresowany robot
<!--/sse-->

Formularz wyświetli się każdemu ‘człowiekowi’, ale nie zobaczy go już np. robot skanujący Twoją stronę.

Jeśli Twój serwis to np. wielki katalog memów i bardzo nie chcesz, aby ludzie hotlinkowali obrazki prosto od Ciebie, możesz aktywować “Hotlink Protection”, którą to opcje znajdziesz także w sekcji ‘Scrape Shield’.

Spadochron awaryjny…

Traktuj Cloudflare jak spadochron awaryjny u skoczka. Nikt nie wyskakuje z samolotu bez poprawnie działającego i przetestowanego spadochronu podstawowego. Podobnie powinno być też z Twoją aplikacją. Cloudflare nie służy do łatania dziurawej aplikacji, a do wspierania poprawnie działającego kodu w przypadku ewentualnej wpadki.

Bardzo częstym błędem przy wdrażaniu CloudFlare jest ujawnienie prawdziwego adresu IP serwera stojącego za usługą. Jeśli taki adres wycieknie, a routing i friewall na webserwerze nie jest poprawnie skonfigurowany, to możliwe staje się wysyłanie zapytań bezpośrednio do aplikacji z pominięciem filtrowania przez Cloudflare. Co może się źle skończyć.

Dobrą praktyką (o ile serwer spełnia jedynie funkcję hostowania aplikacji webowej) jest odcięcie na firewallu wszelkiego ruchu przychodzącego z wyjątkiem serwerów CF (tutaj ich lista). Pamiętaj oczywiście o pozostawieniu sobie możliwości wejścia na serwer poprzez SSH ;)

Uwaga na koniec

Ale zarówno dobrych praktyk jak i narzędzi, które podnoszą bezpieczeństwo aplikacji webowych jest więcej. Jeśli chcesz je wszystkie poznać, to zapraszamy do udziału w naszym szkoleniu z Atakowania i Ochrony Aplikacji Webowych — w trakcie szkolenia większość czasu spędzamy przed labami, w ramach których nauczymy Cię jak wykrywać błędy bezpieczeństwa w webaplikacjach i jak najsensowniej je usuwać. Oto najbliższe terminy tego szkolenia: