13:07
1/2/2024

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).



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.

Pamiętaj, że “dobezpieczanie” aplikacji Cloudflarem wymaga posiadania kontroli nad domeną webaplikacji, bo trzeba odpowiedni zmienić ustawienia DNS. Jeśli Twoja aplikacja webowa jest już osiągalna pod własną domeną, to powiąż ją z Cloudflare. Po prostu po zaloowaniu na konto Cloudflare użyj opcji “Add a Site”, a następnie postępuj zgodnie z instrukcjami pojawiającymi się na ekranie. Pamiętaj, aby wybrać opcję “Free Site”, aby nie wygenerować dodatkowych kosztów utrzymania domeny. Finalnym krokiem będzie zmiana delegacji DNS. Aby to zrobić, musisz zalogować się do panelu sprzedawcy domeny i poszukać opcji dotyczących ustawienia strefy DNS.

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.

W ten sam sposób możemy wykrywać agresorów po user-agencie albo stronie z której do nas przychodzą (np. możemy wyciąć ludzi wchodzących z 4chana).

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)

Jeśli doczytałeś do tego miejsca, to tematyka zabezpieczenia aplikacji webowych chyba Cię interesuje. W takim razie obowiązkowo zapisz się na nasz newsletter poświęcony tej tematyce:



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.

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:

Warszawa: 27-28 maja 2024r. — UWAGA: zostało tylko 1 wolne miejsce
Ostatnio ktoś zarejestrował się 16 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 20 maja)
    2699 PLN netto (od 21 maja)

Poznań: 12-13 czerwca 2024r. — UWAGA: zostały tylko 2 wolne miejsca
Ostatnio ktoś zarejestrował się 20 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 24 maja)
    2699 PLN netto (od 25 maja)

Gdańsk: 17-18 czerwca 2024r. — zostało 5 wolnych miejsc
Ostatnio ktoś zarejestrował się 22 kwietnia 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 24 maja)
    2699 PLN netto (od 25 maja)

Kraków: 15-16 lipca 2024r. — zostało 8 wolnych miejsc
Ostatnio ktoś zarejestrował się 18 maja 2024r. → zarejestruj się na to szkolenie

    2399 PLN netto (do 24 maja)
    2699 PLN netto (od 25 maja)

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

6 komentarzy

Dodaj komentarz
  1. Super poradnik. Cloudflare robi robotę nie tylko w zabezpieczaniu webaplikacji, ale też standardowych stron internetowych. Rzetelna wiedza, dodaję do zakładek :)

  2. ale sie wstrzeliliscie z tym cloudflarem :D

  3. Ech… Szkoda, że te mity i uproszczenia trafiają nawet na profesjonalne serwisy zajmujące się bezpieczeństwem…

    No więc nie – w ten sposób nie zabezpiecza się aplikacji, ani serwera. Pokazane powyżej sposoby nadal w pełni pozwalają atakującym atakować aplikacje, waląc requesty bezpośrednio w serwer aplikacji, bo nijak serwer ten nie został nigdzie ukryty ani zabezpieczony.

    CF to jedynie dodatkowa warstwa, która część ataków, najprostszych, może na siebie zgarnąć, o ile atakujący będzie je wykonywał celując w domenę. Tyle, że coraz częściej obserwujemy już ataki omijające CF. Jak? Prosto – w przypadku hostingów współdzielonych odkrycie prawdziwego adresu IP serwera obsługującego domenę jest dość proste (pozostałe rekordy DNS lub historia rekordów DNS domeny).

    Czy CF może być użyty do zwiększenia bezpieczeństwa? Zdecydowanie. Ale to jest wisienka na torcie, a nie „zabezpieczenie przed atakami”…

    • W artykule Kuba napisał, że

      “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 ;)”

      a dwa akapity wcześniej jest napisane zarówno o odkrywaniu adresu IP jak i o tym, żeby CF traktować jako spadochron zapasowy a nie podstawowy:

      “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.”

  4. Ach ten okropny Cloudflare który odcina wiele stron z powodu nierozwiązywalnych captcha.

  5. CF, czy to ta amerykańska firma zamieszczona na Yale’s “List of shame”? Ciągle Digging In. Kiedyś namiętnie korzystałem, dzisiaj kontestuję.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: