CDN i WAF często są wdrażane razem, ale rozwiązują różne problemy. CDN skraca drogę danych do użytkownika i odciąża infrastrukturę, a WAF analizuje żądania, zanim dotrą do aplikacji. Najlepszy efekt daje połączenie obu mechanizmów z dodatkową ochroną serwera źródłowego.
CDN nie jest tylko serwerem dla obrazów
Content Delivery Network udostępnia zasoby z wielu lokalizacji brzegowych. Użytkownik pobiera obrazy, arkusze stylów, skrypty i inne pliki z punktu położonego bliżej niego, zamiast za każdym razem łączyć się bezpośrednio z originem.
Zmniejsza to opóźnienie i liczbę żądań obsługiwanych przez serwer źródłowy. CDN może również przechowywać dokumenty HTML, ale taka konfiguracja wymaga dokładnego rozpoznania, które odpowiedzi są publiczne, a które zależą od sesji, cookies lub uprawnień użytkownika.
Cache musi odpowiadać sposobowi działania aplikacji
Największy efekt daje świadomie ustawiona polityka pamięci podręcznej. Trzeba ustalić, które odpowiedzi można przechowywać, jak długo powinny być ważne oraz kiedy cache musi zostać wyczyszczony po publikacji nowej wersji.
- statyczne pliki mogą zwykle otrzymać długi czas przechowywania i wersjonowane nazwy,
- panel administracyjny, logowanie i formularze powinny omijać cache,
- odpowiedzi zawierające prywatne dane lub cookies sesyjne nie mogą trafić do wspólnej pamięci,
- reguły czyszczenia cache powinny być częścią procesu wdrożenia,
- po zmianie trzeba sprawdzić zarówno trafienia, jak i pominięcia cache.
WAF na brzegu sieci
Web Application Firewall analizuje ruch HTTP przed przekazaniem go do aplikacji. Może zatrzymać typowe próby SQL injection, XSS, path traversal, skanowanie podatnych ścieżek, automatyczne logowania i inne zachowania charakterystyczne dla ataków.
WAF działający w Cloudflare, Akamai lub innej sieci brzegowej blokuje część ruchu jeszcze przed połączeniem z originem. Dzięki temu nie tylko chroni aplikację, ale również ogranicza zużycie łącza, procesora i zasobów serwera.
Reguły zarządzane, OWASP i własne wyjątki
Reguły zarządzane są aktualizowane przez dostawcę i obejmują popularne klasy ataków oraz znane podatności. Dobrym punktem wyjścia są zestawy oparte na kategoriach OWASP, ale ich uruchomienie nie powinno oznaczać natychmiastowego blokowania każdego dopasowania.
Poprawne żądanie może wyglądać podejrzanie, zwłaszcza w panelach administracyjnych, edytorach kodu, API oraz formularzach przyjmujących rozbudowaną treść. Dlatego reguły warto najpierw uruchomić w trybie obserwacji, przeanalizować zdarzenia i dopiero później włączyć blokowanie. Wyjątek powinien być możliwie wąski: dla konkretnej reguły, ścieżki, parametru lub metody HTTP.
Własne reguły dla konkretnej aplikacji
Reguły własne uzupełniają ochronę ogólną. Mogą ograniczać dostęp do panelu logowania, blokować nieużywane metody HTTP, odrzucać żądania do nieistniejących punktów API, wymagać określonych nagłówków albo reagować na nietypową liczbę zapytań.
Warto budować je na podstawie logów i rzeczywistych wzorców ruchu. Reguła oparta wyłącznie na kraju, User-Agent lub pojedynczym adresie IP jest łatwa do obejścia i może blokować poprawnych użytkowników. Lepszy rezultat daje połączenie kilku sygnałów: ścieżki, metody, częstotliwości, reputacji źródła i zachowania sesji.
Blokowanie niechcianych botów
Nie każdy bot jest atakiem. Część automatów indeksuje treści, monitoruje dostępność albo integruje systemy. Problemem są skanery podatności, narzędzia zbierające adresy, automaty próbujące przejąć konta oraz boty generujące kosztowny ruch bez wartości dla serwisu.
Ochronę można budować stopniowo:
- ograniczyć liczbę prób logowania i żądań do wrażliwych ścieżek,
- stosować rate limiting osobno dla logowania, formularzy, API i wyszukiwania,
- używać wyzwania przeglądarkowego dla ruchu podejrzanego, ale niejednoznacznego,
- blokować znane skanery na podstawie wielu sygnałów, nie tylko nazwy User-Agent,
- tworzyć krótkotrwałe blokady dla adresów powtarzających ten sam niedozwolony wzorzec,
- oddzielić reguły dla użytkowników, integracji API i zweryfikowanych robotów wyszukiwarek.
Origin nie powinien być drogą na skróty
WAF na CDN nie chroni origina, jeśli jego adres IP jest publicznie znany i serwer przyjmuje bezpośrednie połączenia z całego Internetu. Atakujący może wtedy ominąć warstwę brzegową i wysłać żądanie prosto do aplikacji.
Jeżeli architektura na to pozwala, zapora sieciowa origina powinna przyjmować ruch HTTP i HTTPS tylko z aktualnych zakresów adresowych dostawcy CDN. Trzeba również poprawnie przekazać rzeczywisty adres klienta i ufać temu nagłówkowi wyłącznie wtedy, gdy połączenie pochodzi z dozwolonego proxy.
01
02
03
04
ModSecurity jako druga warstwa WAF
Na originie można wdrożyć ModSecurity wraz z OWASP Core Rule Set. Taka warstwa działa bliżej aplikacji i pozwala tworzyć bardziej restrykcyjne reguły dla konkretnego hosta, ścieżki, nagłówka lub parametru. Daje też pełną kontrolę nad wersją zestawu reguł, poziomem czułości, punktacją anomalii i wyjątkami.
ModSecurity nie zastępuje WAF działającego na brzegu. Jest kolejną barierą dla ruchu, który przeszedł przez CDN, dotarł innym dozwolonym kanałem albo wykorzystuje zachowanie specyficzne dla chronionej aplikacji.
Co daje warstwa na originie?
- niezależne logi zdarzeń dostępne po stronie własnej infrastruktury,
- dokładniejsze reguły dla paneli, API, uploadu plików i wybranych parametrów,
- możliwość ustawienia wyższej czułości tylko dla najbardziej narażonych ścieżek,
- ochronę przed częścią błędów konfiguracji reguł na warstwie CDN,
- kontrolę nad wdrażaniem, testowaniem i wersjonowaniem własnych reguł.
Większa kontrola wymaga strojenia
Bardziej restrykcyjny zestaw reguł zwiększa ryzyko fałszywych alarmów. Może również podnieść zużycie procesora, szczególnie przy dużych żądaniach, rozbudowanych formularzach i wielu regułach analizujących treść.
Najbezpieczniej uruchomić ModSecurity najpierw w trybie wykrywania, zebrać reprezentatywne logi i przygotować precyzyjne wyłączenia. Po przejściu w tryb blokowania nadal trzeba śledzić odpowiedzi 403, identyfikatory reguł oraz punkty aplikacji, przy których pojawia się najwięcej dopasowań. Reguł nie należy wyłączać globalnie tylko dlatego, że jedna funkcja aplikacji wymaga wyjątku.
Bezpieczna kolejność wdrożenia
- Zmierz czas odpowiedzi, obciążenie i strukturę ruchu przed zmianą.
- Przełącz ruch przez CDN bez agresywnego cache i blokowania.
- Ustaw cache dla bezpiecznych zasobów i sprawdź nagłówki odpowiedzi.
- Ogranicz bezpośredni dostęp do origina i skonfiguruj rzeczywisty adres klienta.
- Uruchom zarządzane reguły WAF oraz reguły OWASP w trybie obserwacji.
- Dodaj rate limiting i ochronę botów dla konkretnych punktów aplikacji.
- Włącz blokowanie po analizie logów i przygotowaniu wyjątków.
- Uruchom ModSecurity na originie w trybie wykrywania, dostrój reguły i stopniowo zwiększaj restrykcyjność.
Co monitorować po wdrożeniu?
Po wdrożeniu warto zestawiać dane z CDN, WAF, reverse proxy, ModSecurity i samej aplikacji. Pojedynczy licznik blokad nie mówi jeszcze, czy ochrona działa poprawnie.
- współczynnik trafień cache i ilość ruchu przekazanego do origina,
- czas odpowiedzi warstwy brzegowej i serwera źródłowego,
- liczbę odpowiedzi 403, 429, 4xx i 5xx,
- najczęściej uruchamiane reguły oraz ścieżki powodujące blokady,
- liczbę wyzwań rozwiązanych i odrzuconych przez boty,
- wpływ reguł ModSecurity na czas obsługi i użycie procesora,
- zgłoszenia użytkowników oraz błędy funkcji biznesowych po zmianach reguł.
Warstwy zamiast jednego przełącznika
CDN, brzegowy WAF i ModSecurity pełnią różne role. CDN przyspiesza dostarczanie treści i przejmuje część ruchu. WAF na brzegu odrzuca masowe skanowanie, nadużycia oraz typowe ataki przed originem. ModSecurity pozwala zastosować dokładniejszą i bardziej restrykcyjną kontrolę przy samej aplikacji.
Dopiero połączenie tych warstw z aktualizacjami, prawidłową walidacją danych, ograniczeniem dostępu do origina i monitoringiem daje ochronę, którą można świadomie rozwijać zamiast jedynie włączyć.