Sophos Firewall WAF: Bezpieczne publikowanie serwera WWW

Za pomocą Web Server Protection lub Web Application Firewall (WAF) można publikować wewnętrzne lub chmurowe aplikacje webowe przez Sophos Firewall. Firewall działa jako Reverse Proxy: klienci łączą się z publicznym adresem firewalla, który sprawdza ruch HTTP lub HTTPS i przekazuje żądanie do chronionego serwera WWW.

Szerszy kontekst utwardzania konfiguracji opisuje hub Sophos Firewall Hardening: najlepsze praktyki bezpiecznej konfiguracji.

Reguła WAF nie zastępuje automatycznie bezpiecznego rozwoju aplikacji, łatania, silnego uwierzytelniania ani utwardzania serwera. W porównaniu do prostego przekierowania portów znacznie zmniejsza jednak powierzchnię ataku, ponieważ ruch HTTP(S) może być bardziej precyzyjnie sprawdzany, ograniczany i logowany.

WAF nie zawsze jest jednak właściwą odpowiedzią na każdą publikację. Kluczowe jest, czy aplikacja rzeczywiście działa poprawnie przez HTTP lub HTTPS, czy firewall powinien analizować nazwy hostów i ścieżki oraz czy dodatkowa warstwa Reverse Proxy pasuje do aplikacji.

PHP2Shell — stan na 24 października 2026: W przypadku CVE-2026-109618 i CVE-2026-109619 Sophos w komunikacie z 22 października, wersja 4 nie wskazuje specyficznej ochrony przez Sophos Firewall WAF. Podatne środowiska uruchomieniowe PHP na backendzie trzeba zaktualizować; publikacja przez WAF nie zastępuje aktualizacji. Sygnatury IPS udostępnione od 22 października służą do wykrywania prób ataku. Osobno należy sprawdzić, czy odpowiednia polityka IPS analizuje rzeczywistą ścieżkę danych i jakie działanie wykonuje; pomaga w tym instrukcja IPS. Brak alarmu nie potwierdza bezpiecznego stanu poprawek.

Decyzja przed publikacją

Przed utworzeniem reguły WAF należy ustalić, czy do aplikacji pasuje WAF, DNAT, VPN czy ZTNA. Ta decyzja jest ważniejsza niż sam formularz konfiguracji w firewallu, ponieważ determinuje powierzchnię ataku, eksploatację i rozwiązywanie problemów.

Kiedy WAF jest lepszy niż DNAT

Dla prostych usług TCP lub UDP nadal używa się NAT i reguł firewalla. Dla aplikacji webowych WAF często jest lepszym wyborem.

DNAT pasuje do usług innych niż HTTP, prostych przekierowań portów i protokołów specjalnych. Firewall przede wszystkim wykonuje wtedy translację adresów i zezwala na ruch.
WAF / Web Server Protection pasuje do aplikacji HTTP i HTTPS, gdy istotne są nazwa hosta, certyfikat, ścieżki, profile ochrony, uwierzytelnianie lub reguły krajowe.
Reverse Proxy lub ZTNA pasuje do złożonych platform webowych, integracji tożsamości i aplikacji prywatnych, gdy dostęp ma być ściśle kontrolowany albo w ogóle niepubliczny.

Jeśli jedynym celem jest szybkie udostępnienie wewnętrznego serwera WWW przez przekierowanie portów, pomocna będzie instrukcja Publikowanie serwera przez DNAT na Sophos Firewall. Jeśli chodzi o publiczne aplikacje webowe, warto najpierw rozważyć WAF.

⚠️ WebDAV nie jest obsługiwany przez Sophos WAF. Dlatego aplikacji takich jak Nextcloud nie należy bezrefleksyjnie publikować przez WAF, lecz zaplanować ich publikację za pomocą odpowiednich reguł firewalla i NAT lub innej architektury publikacji.

Decyzja: WAF, DNAT czy dostęp prywatny

Najważniejsze pytanie nie brzmi, jak szybko można skonfigurować publikację, ale czy można ją później bezpiecznie obsługiwać, testować i wycofać. Poniższe zestawienie pomaga przed techniczną realizacją:

Publiczna strona internetowa lub prosta aplikacja HTTPS: WAF jest zwykle właściwym punktem startowym. DNS, certyfikat, nazwa hosta, profil ochrony, logowanie i dostępność backendu muszą zostać przetestowane.
Portal klienta, portal partnera lub interfejs administracyjny: WAF z ograniczeniem źródeł dostępu i opcjonalnie MFA może mieć sens. Najpierw trzeba ustalić, czy możliwe są WAF-MFA, reguły krajowe lub stałe sieci źródłowe.
Usługa działająca wyłącznie przez TCP lub UDP: DNAT zwykle pasuje lepiej. Regułę firewalla, regułę NAT, serwer docelowy, trasę zwrotną i logowanie trzeba sprawdzić razem.
Aplikacja webowa z WebDAV lub protokołem specjalnym: nie używać automatycznie WAF. Trzeba przetestować obsługiwane funkcje, zachowanie klienta i alternatywną publikację.
Aplikacja tylko dla użytkowników wewnętrznych: sprawdzić VPN, ZTNA lub mocno ograniczony WAF. Publiczną dostępność należy poddać krytycznej ocenie.

Dla aplikacji prywatnych reguła WAF dostępna na całym świecie często stanowi zbyt dużą powierzchnię ataku. Jeśli dostęp musi mieć tylko kilka osób, stałe sieci źródłowe, VPN, ZTNA lub inna architektura dostępu prywatnego są często lepszym rozwiązaniem niż publiczna publikacja webowa.

Planowanie i wymagania wstępne

Stabilna publikacja WAF wymaga DNS, certyfikatu, dostępności backendu, logowania i planu wycofania zmian. Te kwestie należy ustalić przed konfiguracją.

Wymagania wstępne

Przed utworzeniem pierwszej reguły WAF należy ustalić następujące kwestie:

Publiczna nazwa DNS, na przykład portal.example.com
Publiczny adres IP lub alias na interfejsie WAN
Certyfikat dla publikowanej nazwy hosta
Wewnętrzny adres IP lub FQDN serwera WWW
Wewnętrzny port docelowy serwera WWW
Decyzja, czy HTTP będzie przekierowywane na HTTPS
Dozwolone sieci źródłowe, kraje lub grupy użytkowników
Odpowiedni profil ochrony i opcjonalna polityka IPS
Aktywowane logowanie do późniejszej analizy
Zewnętrzny dostęp testowy poza własnym LAN

Publiczna nazwa DNS musi wskazywać na adres używany w regule WAF jako Hosted address. W przypadku HTTPS certyfikat musi pasować do publikowanej nazwy hosta.

Dodatkowo firewall potrzebuje obiektu web server w Web server > Web servers. Opisuje się tam wewnętrzny lub zewnętrzny serwer docelowy za pomocą hosta, protokołu i portu. Host jest obiektem hosta IP lub FQDN. Dla backendów możliwy jest HTTP albo HTTPS; standardowe porty to 80 i 443. Jeśli backendowy serwer WWW zwraca długie odpowiedzi albo wymaga keep-alive, Keep alive i Timeout trzeba sprawdzić świadomie, zamiast bezrefleksyjnie przejmować wartości.

Backendowy Timeout może wynosić od 1 do 65,535 sekund; wartość domyślna to 300 sekund. Po jego upływie WAF wysyła klientowi 502. Disable backend connection pooling wymusza nowe połączenie z backendem dla każdego żądania i może obniżyć wydajność. Opcji tej należy używać wyłącznie do ukierunkowanej diagnostyki, a następnie przywrócić udokumentowany stan wyjściowy.

Wcześnie trzeba też uwzględnić ograniczenia Web Server Protection. Sophos podaje między innymi limit 60 reguł WAF na firewall. Dla wielu środowisk to wystarcza, ale przy wielu portalach klientów, tenantach, systemach testowych lub rozdzielonych nazwach hostów limit może stać się istotny szybciej, niż się zakłada. Wtedy nie należy bezrefleksyjnie budować kolejnych pojedynczych reguł, tylko sprawdzić koncepcję nazewnictwa, ścieżki, wirtualne serwery WWW i alternatywne sposoby publikacji.

SFOS 22 nie obsługuje reguł WAF przez IPv6. Dlatego nie wolno planować aplikacji jako publikacji IPv6 z użyciem tej funkcji; zestawienie Obsługa IPv6 i ograniczenia w Sophos Firewall z SFOS 22 odróżnia WAF od obsługiwanych funkcji reguł i ochrony IPv6. Także szablony Exchange nie są przepustką dla nowoczesnych środowisk Exchange: Sophos dokumentuje, że reguły WAF obecnie nie obsługują wersji Exchange nowszych niż 2013.

Wstępnie skonfigurowane szablony pochodzą ze starszego środowiska aplikacji Microsoft: Exchange Autodiscover, Outlook Anywhere i Exchange General kończą się na granicy Exchange 2013; pozostałe instrukcje Sophos wymieniają Microsoft Lync, Remote Desktop Gateway lub RD Web 2008/R2 oraz SharePoint 2010/2013. Nie stanowią więc aktualnej podstawy dla Microsoft 365, nowszych wersji Exchange, Teams ani obecnych wdrożeń RDS. Przed użyciem szablonu należy porównać faktycznie wymagane ścieżki, metody uwierzytelniania i profile ochrony z bieżącą architekturą Microsoft; dla nowoczesnej aplikacji w razie wątpliwości należy pozostawić Preconfigured template ustawione na None.

Tworzenie obiektu backendu na konkretnym przykładzie

Nazwa publiczna i nazwa backendu pełnią różne funkcje. W poniższym przykładzie użytkownicy otwierają portal.example.com, a firewall dociera do serwera przez backend.example.com. Obie nazwy są przykładowe i trzeba je zastąpić własnymi nazwami DNS. Z perspektywy firewalla nazwa backendu musi być rozwiązywana na adres rzeczywistego serwera, a nie ponownie na własny publiczny adres WAF: w przeciwnym razie nie powstanie prawidłowa ścieżka do backendu.

W Hosts and services > FQDN host > Add utwórz obiekt o nazwie WAF_Backend_Portal z wartością FQDN backend.example.com i zapisz go. Alternatywnie użyj obiektu hosta IP dla serwera backendowego o stałym adresie. Według dokumentacji produktu hosty FQDN zapewniają szerszą kompatybilność z serwerami; mimo to trzeba sprawdzić rozwiązywanie DNS i serwer docelowy.
W Web server > Web servers > Add utwórz obiekt web server WAF_Portal_Server i w Host wybierz obiekt backendu.
Ustaw Type i Port zgodnie z rzeczywistym listenerem backendu: w przykładzie z HTTPS są to HTTPS i 443, a dla backendu HTTP — HTTP i na przykład 80. Zewnętrzny port nasłuchu określa się dopiero w regule WAF i nie musi on być identyczny z portem backendu. W przypadku backendu HTTP świadomie zabezpiecz nieszyfrowany segment; samo użycie HTTPS na frontendzie nie szyfruje tego segmentu.
Włącz Keep alive tylko wtedy, gdy serwer WWW obsługuje ponowne używanie połączeń. Najpierw oceń Timeout z domyślną wartością 300 sekund. Chodzi o czas oczekiwania na dane przesyłane do backendu lub z backendu, a nie o ogólny maksymalny czas trwania każdego żądania: dopóki dane napływają na czas, odpowiedź może trwać dłużej. Dlatego przy 502 sprawdź logi backendu i przerwy w przesyłaniu danych, zamiast od razu zwiększać tę wartość.
W normalnej eksploatacji nie włączaj Disable backend connection pooling jako optymalizacji wydajności. Zapisz obiekt, sprawdź jego przypisanie do reguły WAF lub ścieżki Protect w SFOS 23 i przetestuj reprezentatywne żądanie do backendu.

Planowanie publikacji WAF przed konfiguracją

Reguła WAF nie powinna być planowana dopiero w formularzu konfiguracji. Wcześniej należy ustalić, czy Sophos Firewall ma tylko publikować aplikację, czy także obsługiwać uwierzytelnianie, profile ochrony, reguły krajowe i logowanie.

Te pytania są ważne przed produkcyjną publikacją:

Czy to naprawdę aplikacja HTTP lub HTTPS? Dla innych protokołów DNAT jest zwykle bardziej odpowiedni.
Czy aplikacja musi być publicznie dostępna? Prywatne portale administracyjne często lepiej pasują do VPN, ZTNA lub ograniczonych sieci źródłowych.
Jaka nazwa hosta i certyfikat będą używane? DNS, SNI, certyfikat i domeny WAF muszą do siebie pasować.
Ile publikacji jest planowanych? Limit reguł WAF i późniejsza łatwość obsługi wpływają na projekt.
Czy firewall ma uwierzytelniać użytkowników? Dla portali WAF-MFA może być sensowne.
Jakie profile ochrony są aktywne? Zbyt szerokie wyjątki osłabiają WAF, a zbyt restrykcyjne profile mogą zakłócić działanie aplikacji.
Jak będzie logowane i testowane? Log Viewer, reverseproxy.log i logi backendu muszą być znane przed uruchomieniem.

Dla certyfikatów warto wcześniej ustalić, czy istniejący certyfikat zostanie zaimportowany wraz z kluczem prywatnym i łańcuchem CA, czy firewall sam utworzy i odnowi certyfikat Let’s Encrypt, czy też potrzebny będzie certyfikat wygenerowany zewnętrznie. Dla certyfikatów wildcard dostępna jest osobna instrukcja: Tworzenie certyfikatu wildcard Let’s Encrypt.

Konfiguracja reguły WAF

Właściwa reguła WAF obejmuje publiczny adres, nazwy hostów, certyfikat, serwer docelowy, dozwolone źródła i profil ochrony. Te pola należy rozpatrywać łącznie, a nie jako odizolowane opcje.

Podstawowa struktura reguły WAF

Publikacja WAF składa się z kilku elementów:

Hosted address: publiczny adres IP lub alias, pod którym klienci uzyskują dostęp do aplikacji.
Listening port: publiczny port, zazwyczaj 80 lub 443.
Domains: nazwy hostów, które mają pasować do reguły WAF.
HTTPS certificate: certyfikat dla publikowanej nazwy hosta.
Web server: wcześniej utworzony obiekt web server z hostem, protokołem, portem i ustawieniami połączenia.
Allowed client networks: sieci źródłowe, które mogą uzyskać dostęp.
Blocked client networks / countries: źródła lub kraje, które są blokowane.
Protection policy: ochrona WAF przed typowymi atakami webowymi.
Authentication: opcjonalne logowanie wstępne przez firewall.

Sophos tworzy reguły WAF w sekcji reguł firewalla. Akcja nazywa się Protect with web server protection.

Ważne: reguła WAF nie jest zwykłą regułą firewalla z NAT za nią. Tworzy publikację Reverse Proxy. Dlatego Hosted address, Listening port, Domains, certyfikat, Protected server i Allowed client networks muszą do siebie pasować. Jeśli jedno z tych pól nie pasuje, błąd często wygląda jak problem z certyfikatem, DNS albo backendem.

Tworzenie reguły WAF

Ścieżka menu to:

Rules and policies > Firewall

Procedura:

Nowe reguły są domyślnie włączone. Dlatego w przypadku przygotowanej publikacji, która nie została jeszcze dopuszczona do uruchomienia, należy wyraźnie sprawdzić stan reguły i pozostawić ją wyłączoną do planowanego uruchomienia. Rule position oferuje Top lub Bottom; Rule group przypisuje regułę do istniejącej grupy lub grupy utworzonej za pomocą Create new. Automatic używa pierwszej pasującej grupy według typu reguły oraz stref źródłowych i docelowych. Grupowanie ułatwia zarządzanie, ale nie zastępuje weryfikacji dostępu.

Poniższa numerowana procedura z Protected servers dotyczy tylko SFOS 22 i pozostaje niezmieniona dla tej wersji. Reguły WAF obsługują tylko IPv4. Zewnętrzna akcja reguły Protect with web server protection nie jest tym samym co akcja dla konkretnej ścieżki Action > Protect w Traffic routing w SFOS 23; dla SFOS 23 obowiązuje osobna instrukcja bezpośrednio po tej procedurze.

Wybierz IPv4.
Otwórz Add firewall rule.
Wybierz New firewall rule.
Nadaj regule znaczącą nazwę.
Świadomie ustaw Rule position, szczególnie jeśli istnieją już bardziej ogólne reguły WAF lub stare publikacje.
W Action wybierz opcję Protect with web server protection.
Jeśli nie jest potrzebny specjalny szablon, pozostaw Preconfigured template na None.
W Hosted server details zdefiniuj publiczny adres, port nasłuchu, HTTPS, certyfikat i domeny.
W Protected servers wybierz pasujący obiekt web server albo utwórz go wcześniej w Web server > Web servers.
Świadomie ustaw Allowed client networks. Dla publicznych stron może być potrzebne Any IPv4; dla portali zwykle lepsze jest ograniczenie.
W razie potrzeby ustaw Blocked client networks lub Blocked countries.
W zaawansowanych politykach świadomie sprawdź Protection, Intrusion prevention i Traffic shaping.
Zapisz regułę i przetestuj ją z zewnątrz.

SFOS 23: Publikowanie ścieżek w Traffic routing

W Rules and policies > Firewall utwórz lub edytuj regułę IPv4. Jako zewnętrzną Action nadal wybierz Protect with web server protection i odpowiednio skonfiguruj publiczny adres, port, certyfikat HTTPS oraz domeny. Nowa reguła domyślnie zawiera / z akcją Block: bez dodatkowej konfiguracji routingu żądania są odrzucane, a aplikacja nie jest publikowana.
W Traffic routing, za pomocą Edit lub Add new path, edytuj lub dodaj konkretną planowaną ścieżkę. W Action jawnie wybierz Protect i przypisz wymagane obiekty backendu z Web server > Web servers. Szablon wprawdzie tworzy ścieżki z akcją Protect, ale nadal wymaga przypisania backendu.
Dla każdej chronionej ścieżki przypisz przewidzianą politykę uwierzytelniania w polu Authentication i świadomie ustaw Allowed client networks — nie pozostawiaj tego pola pustego. Dokładnie sprawdź Blocked client networks, Blocked countries i Block IP addresses of unknown country-origin; przy nieznanym kraju pochodzenia uwzględnij także ryzyko zablokowania własnego dostępu.
Jeśli mają być publikowane tylko określone ścieżki, świadomie pozostaw / z akcją Block jako trasę domyślną dla żądań bez bardziej specyficznego dopasowania. Ustaw Protect dla / tylko wtedy, gdy ma być publikowana cała aplikacja; dokładnie sprawdź backend, uwierzytelnianie, ograniczenia dostępu i części aplikacji, które staną się przez to dostępne. Dłuższe, bardziej specyficzne ścieżki są oceniane jako pierwsze — nie decyduje kolejność w tabeli.
Rozróżniaj akcje: Block odrzuca żądania dla wybranej ścieżki i nie przekazuje ich do backendu. Protect stosuje politykę ochrony reguły oraz skonfigurowane ustawienia uwierzytelniania i dostępu. Redirect wysyła klientowi przekierowanie do skonfigurowanego celu zamiast publikować backend. Passthrough tworzy tunel do backendu bez inspekcji WAF i bez stosowania polityki ochrony. Protection dotyczy tylko ścieżek z akcją Protect.
Po zapisaniu przetestuj z zewnątrz planowaną dozwoloną ścieżkę, ścieżkę celowo zablokowaną oraz ścieżkę bez specyficznego dopasowania. Jeśli używasz Redirect i Passthrough, sprawdź je również osobno. Skoreluj wynik po stronie klienta, Log Viewer, reverseproxy.log i logi backendu na podstawie tego samego żądania i tego samego momentu.

Ścieżkę domyślną można edytować, klonować lub usuwać. Klon nie oznacza zatwierdzenia nowej konfiguracji: ponownie sprawdź akcję, backend, uwierzytelnianie i źródła dla nowego przypisania. Nie usuwaj przypadkowo /, jeśli stanowi świadomie blokującą trasę domyślną.

Istniejące reguły po aktualizacji: Według dokumentacji Sophos istniejące reguły WAF są podczas aktualizacji do SFOS 23 automatycznie przestawiane na Protect; istniejące trasy specyficzne dla ścieżek zostają zachowane. Różni się to od domyślnej akcji Block dla / w nowych regułach oraz od starszej migracji ModSecurity Protection Policies w SFOS 18. Mimo to po aktualizacji sprawdź dla każdej ścieżki akcję, backend, uwierzytelnianie, ograniczenia dostępu i rzeczywistą trasę oraz przeprowadź zewnętrzny test akceptacyjny; automatyczna migracja nie zastępuje odbioru.

Kontekst tutorialu: Tutorial Sophos dotyczący ochrony serwera WWW przed atakami nadal używa procedury z Protected servers i podaje IPv4 or IPv6, mimo że dokumentacja referencyjna reguł WAF ogranicza WAF do IPv4. Tutorial nie jest więc kompletną instrukcją routingu dla SFOS 23. W bieżącej konfiguracji obowiązują IPv4 i jawnie określone akcje ścieżek opisane powyżej.

Po zapisaniu reguły Sophos ponownie uruchamia reguły Web Server Protection. Istniejące połączenia na żywo przez te reguły mogą zostać przerwane. Zmiany w produkcyjnych regułach WAF należy więc przeprowadzać w oknie konserwacyjnym lub przynajmniej świadomie.

Jeśli Allowed client networks pozostanie puste, reguła WAF nie działa poprawnie; przeglądarka może wtedy otrzymać 400 Bad Request. Dla publicznej aplikacji Any IPv4 jest wprawdzie możliwe, ale nie jest automatycznie właściwe. Dla portali administracyjnych, portali partnerów lub narzędzi wewnętrznych najpierw należy sprawdzić stałe sieci źródłowe, ograniczenie krajowe, WAF-MFA, VPN lub ZTNA.

Konflikty portów trzeba wyjaśnić przed zapisaniem. WebAdmin i User Portal wymagają osobnych, unikatowych portów. WAF i VPN Portal używają TCP, dlatego przy tym samym porcie ich Hosted address lub adresy IP WAN muszą się różnić. WAF może różnić się od SSL VPN adresem IP WAN, portem lub protokołem, ponieważ SSL VPN obsługuje TCP albo UDP. Sam inny FQDN lub nazwa SNI nie wystarcza do rozdzielenia tych listenerów. Jeśli na publicznym adresie IP nasłuchuje już inna usługa albo stara publikacja DNAT, przypisanie trzeba przed uruchomieniem przetestować osobno dla adresu IP, portu i protokołu.

Domyślny port User Portal to 4443; mechanizmy nasłuchiwania portali i ich ograniczenia są omówione w przeglądzie portali.

SFOS 23: Precyzyjne definiowanie odpowiedzi Block i Redirect

Jedna akcja routingu może obejmować kilka wpisów w Paths, jeśli wszystkie wymagają takiej samej obsługi. W Traffic routing > Add new path wybierz ścieżki i akcję, wypełnij pola zależne od akcji i zapisz wpis ścieżki. W przypadku różnych backendów, reguł dostępu lub celów przekierowania używaj osobnych wpisów.

Dla Block pole Response code określa odpowiedź. Przykładem jest /admin/ z Forbidden (403), podczas gdy / pozostaje trasą domyślną z akcją Block. Udokumentowany wybór obejmuje 400 do 417 oraz 422, 423, 424 i 426. Wybierz kod zgodnie z zamierzonym znaczeniem: 403 oznacza odmowę dostępu, a 404 — nieznalezioną zawartość. Wybranie kodu 401 nie konfiguruje polityki uwierzytelniania; sam kod statusu nie zapewnia ochrony przez logowanie. Podczas odbioru sprawdź skonfigurowany status oraz brak odpowiadającego mu żądania do backendu.

Dla Redirect, oprócz Paths i Action, konfiguracja obejmuje pola Response code, Protocol, Host, Path i Port. Przykład: /old-portal/ z Temporary Redirection (307), Protocol HTTPS, hostem FQDN dla portal.example.com, Path /portal/ i Port 443. Zastąp nazwy i ścieżki wartościami właściwymi dla swojej aplikacji docelowej. 307 oznacza tymczasowe przekierowanie z zachowaniem metody żądania; nadaje się to do kontrolowanego pilotażu, jeśli cel obsługuje tę samą metodę. Mimo to przetestuj osobno przeglądarkę i klienta API, zwłaszcza żądania POST. Cel /portal/ musi być sam w sobie dostępny i chroniony, na przykład przez odpowiednią ścieżkę Protect; samo przekierowanie nie tworzy tam konfiguracji backendu ani dostępu.

Dostępne kody to 300, 301, 302, 303, 304, 305, 307 i 308. Nie każdy oferowany kod jest zwykłym przekierowaniem do nowej strony: 304 opisuje walidację pamięci podręcznej. 305 jest przestarzały ze względów bezpieczeństwa i nie jest zalecany dla aplikacji publicznych. Używaj 301 lub 308 dopiero wtedy, gdy zamierzona jest trwała zmiana, i uwzględnij zachowanie klienta oraz pamięci podręcznej przy wycofywaniu zmiany. Standardowe porty celu to 80 dla HTTP i 443 dla HTTPS. Redirect nie przeprowadza inspekcji WAF i nie wysyła żądania do backendu tej trasy; dlatego sprawdź po stronie klienta status i cel przekierowania, a następnie ochronę aplikacji docelowej.

Ukierunkowane dostosowanie nagłówka Host, HTML i kompresji

Advanced settings reguły WAF pomagają w konkretnych problemach związanych z reverse proxy. Nie są to opcje, które należy zbiorczo włączać:

Pass host header przekazuje do backendu nagłówek Host żądany przez klienta. Przy wielu witrynach na jednym serwerze pozwala to wybrać właściwy host wirtualny. Skonfiguruj vHost backendu odpowiednio do publikowanej nazwy i sprawdź w logu dostępu, czy nie odpowiada inna witryna.
Rewrite HTML dostosowuje linki w zwracanych stronach. Jeśli na przykład link bezwzględny wskazuje na http://backend.example.com/, podczas gdy aplikacja jest publikowana pod publiczną nazwą, przepisanie może być konieczne. Przy już prawidłowych publicznych nazwach hostów lub wyłącznie względnych linkach zwykle nie jest wymagane. Przetwarzanie dotyczy typów Content-Type text/* i *xml*; pliki binarne do pobrania muszą być dostarczane z prawidłowym Content-Type, w przeciwnym razie grozi ich uszkodzenie. Następnie osobno przetestuj publiczne linki, pobieranie i funkcje aplikacji.
Rewrite cookies przepisuje ciasteczka w zwracanych stronach. W przypadku problemów z sesjami zbadaj faktycznie ustawiane ciasteczka oraz logowanie i wylogowanie, zamiast mylić przepisywanie ciasteczek z Cookie signing: przepisywanie i ochrona przed manipulacją pełnią różne funkcje.
Disable compression support pomaga w ukierunkowany sposób przy nieprawidłowo wyświetlanych stronach lub błędach Content-Encoding. Firewall żąda wtedy od backendu nieskompresowanych danych i dostarcza je bez kompresji niezależnie od żądanego kodowania. Udokumentuj stan wyjściowy, powtórz to samo wywołanie strony i wyłącz opcję, jeśli nie usuwa błędu.

Niektóre porty są zarezerwowane dla usług systemowych, nawet jeśli dana usługa nie jest używana. Sam brak aktywnego listenera nie sprawia, że taki port jest dostępny dla WAF; zestawienie Zarezerwowane porty Sophos Firewall pomaga w planowaniu. Traffic shaping przypisuje publikacji przepustowość i priorytety zależne od czasu. Jest to decyzja operacyjna, a nie dodatkowa ochrona aplikacji; przy włączonej polityce sprawdź przesyłanie i pobieranie również pod reprezentatywnym obciążeniem.

Go-live i odbiór

Po zapisaniu reguły publikacja nie jest jeszcze gotowa. Dopiero testy zewnętrzne, odpowiednie logi i jasno określony rollback sprawiają, że zmiana jest gotowa do pracy produkcyjnej.

Planowanie uruchomienia i wycofania

Publikacja WAF nie powinna być uznawana za zakończoną bezpośrednio po zapisaniu reguły. Kluczowe jest, czy DNS, certyfikat, Hosted address, backend, profil ochrony i logowanie działają razem. Szczególnie przy istniejących przekierowaniach portów należy traktować zmianę jak małą publikację.

Przed uruchomieniem sprawdź:

Udokumentuj aktualną konfigurację firewalla lub przynajmniej ustawienia objętych zmianą reguł i certyfikatów.
Zidentyfikuj dotychczasowe reguły DNAT lub firewalla, które dotyczą tego samego portu, publicznego IP lub nazwy hosta.
Wyłącz stare reguły DNAT lub jednoznacznie udokumentuj, dlaczego nie konkurują z regułą WAF.
Zmniejsz TTL DNS przed zmianą, jeśli publiczna nazwa hosta przechodzi z poprzedniej publikacji na WAF.
Zapewnij zewnętrzny dostęp testowy, nie testuj tylko z wewnętrznego LAN.
Zdefiniuj przypadki testowe: strona startowa, logowanie, przesyłanie, pobieranie, ścieżka API, WebSocket, wylogowanie i komunikat o błędzie.
Ustal oczekiwane miejsca logowania: Log Viewer, reverseproxy.log, log dostępu backendu i log błędów backendu.
Ustal kryterium wycofania, na przykład brak możliwości logowania, brak dostępności backendu, nieprawidłowy certyfikat, wysoka liczba błędów lub uszkodzone krytyczne części aplikacji.

Podczas zmiany powinna być aktywna tylko jedna publikacja. Jeśli stara reguła DNAT i nowa reguła WAF używają tego samego publicznego IP i portu, zachowanie jest trudne do prześledzenia. Przed przełączeniem produkcyjnym powinno być jasne, która reguła faktycznie przetwarza ruch.

Prosty rollback często polega na dezaktywowaniu nowej reguły WAF i ponownym aktywowaniu poprzedniej publikacji. Jeśli dodatkowo zmieniono DNS, należy uwzględnić TTL DNS. W przypadku problemów z certyfikatami lub nazwami hostów rollback wyłącznie przez DNS jest często zbyt wolny; w takich przypadkach stara reguła powinna dać się ponownie aktywować na tej samej Hosted address lub powinien być dostępny alternatywny dostęp.

Po uruchomieniu pierwsze dostępy powinny być aktywnie monitorowane. Ważne są nie tylko udane kody statusu HTTP, ale także blokady WAF, błędy backendu, nieoczekiwane przekierowania, problemy z sesjami i brakujące informacje o IP klienta w logach backendu.

Test akceptacyjny po uruchomieniu

Test WAF jest kompletny dopiero wtedy, gdy to samo żądanie można prześledzić z trzech perspektyw: klienta, firewalla i backendu. Dzięki temu szybciej można zidentyfikować, czy problem leży w DNS, certyfikacie, dopasowaniu WAF, profilu ochrony czy aplikacji.

Klient zewnętrzny: sprawdzić rozwiązywanie DNS, certyfikat, status HTTP, logowanie i ważne ścieżki. Aplikacja powinna otwierać się przez publiczną nazwę hosta bez ostrzeżenia o certyfikacie.
Sophos Firewall: sprawdzić Log Viewer, regułę WAF, reverseproxy.log i zablokowane sygnatury. Właściwa reguła WAF powinna przetwarzać dostęp, a logi powinny pokazywać dozwolone albo zasadnie zablokowane żądania.
Backendowy serwer WWW: sprawdzić log dostępu, log błędów, sesję aplikacji i X-Forwarded-For. Żądanie powinno docierać do właściwego vHosta lub ścieżki, a sposób obsługi IP klienta musi być zrozumiały.

Dla aplikacji produkcyjnych należy przetestować co najmniej te przypadki:

Wywołanie przez właściwą nazwę hosta i przez niepasującą domenę.
Logowanie z ważnym i nieważnym użytkownikiem, jeśli aplikacja lub WAF uwierzytelnia użytkowników.
Przesyłanie, pobieranie, funkcja API lub WebSocket, jeśli aplikacja korzysta z takich funkcji.
Dostęp z dozwolonego źródła i, jeśli to możliwe, z celowo niedozwolonego źródła.
Zachowanie znanego, nieszkodliwego testowego żądania WAF, aby widoczne były logowanie i ścieżka blokady.

Jeśli aplikacja po uruchomieniu wydaje się działać, ale nie są widoczne odpowiednie logi, test nie jest zakończony. Może to oznaczać, że dopasowuje się inna publikacja, brakuje logowania lub dostęp nie przebiega przez oczekiwaną ścieżkę.

Zabezpieczenie ochrony i dostępu

W przypadku publicznych aplikacji webowych WAF jest tylko jedną z warstw ochrony. Certyfikaty, ograniczenia źródeł, Threat Feeds, profile ochrony i logowanie na backendzie należy planować wspólnie.

Certyfikaty i nazwy hostów

Dla HTTPS reguła WAF musi używać certyfikatu, który pasuje do publicznej nazwy hosta. Certyfikat jest importowany lub tworzony w sekcji Certificates > Certificates i następnie wybierany w regule WAF.

Ważne punkty:

Nazwa DNS musi pasować do certyfikatu.
Wybrany certyfikat HTTPS może automatycznie wypełnić listę domen w regule WAF albo nadpisać istniejące wpisy domen.
Przy wielu nazwach hostów na tym samym IP firewall używa SNI.
Certyfikaty wildcard są możliwe, ale powinny być dobrze udokumentowane.
Domeny wildcard są używane dopiero po bardziej specyficznych regułach domenowych. *. jest dozwolone tylko na początku, na przykład *.example.com; w jednej regule można użyć wielu domen wildcard.
Podkreślenia w lewej etykiecie domeny nie tworzą poprawnej nazwy DNS i należy ich unikać w domenach WAF.
Backend może używać innej wewnętrznej nazwy, jeśli nagłówki Host i aplikacja mogą sobie z tym poradzić.
W przypadku problemów z linkami absolutnymi może być istotne Rewrite HTML.

Jeśli wiele wirtualnych serwerów WWW działa na tym samym IP i porcie, firewall przy HTTPS decyduje na podstawie SNI i nazwy hosta, która reguła WAF pasuje.

Domeny w regule WAF powinny więc dokładnie pasować do DNS i certyfikatu. Wildcardy mogą pomagać, ale nie powinny zastępować dobrze opracowanej koncepcji publikacji. Jeśli wiele aplikacji działa pod podobnymi nazwami hostów, potrzebna jest jasna dokumentacja reguł i certyfikatów, bo później trudno ustalić, która reguła WAF faktycznie dopasowała ruch. Przydatny jest test z celowo niepasującą subdomeną: wtedy widać, czy odpowiada konkretna reguła, reguła wildcard czy żaden pasujący wirtualny serwer WWW.

Nazwa obiektu certyfikatu może zawierać wyłącznie znaki alfanumeryczne z zestawu znaków US-ASCII; nie należy jej utożsamiać z nazwą DNS w certyfikacie. Po wybraniu certyfikatu sprawdź automatycznie przejęte Domains i w razie potrzeby edytuj, dodaj lub usuń wpisy. HTTPS udostępnia usługę nasłuchującą przez HTTPS, a nie dodatkowo przez HTTP. Redirect HTTP osobno przekierowuje dostęp z portu 80 na port 443; dlatego należy również zaplanować te usługi nasłuchujące i możliwe konflikty portów.

W przypadku niepasującej nazwy subdomeny nie musi pojawić się graficzna strona blokady. Dokumentacja pokazuje na przykład 403 przy wywołaniu innej subdomeny. Dlatego należy sprawdzić status HTTP i reverseproxy.log, a nie tylko wygląd strony w przeglądarce.

Planowanie IP klienta i logów backendu

Przy publikacjach WAF wewnętrzny serwer WWW często nie widzi prawdziwego IP klienta jako bezpośredniego adresu źródłowego. Sophos Firewall działa jako Reverse Proxy i sam nawiązuje połączenie z backendem. Dla aplikacji i logów serwera WWW może być więc widoczny najpierw adres firewalla.

Jeśli aplikacja lub backend potrzebuje oryginalnego IP klienta, warto wcześniej sprawdzić, czy X-Forwarded-For lub podobny nagłówek jest analizowany. Jest to ważne dla:

Logów aplikacji i analizy bezpieczeństwa
Ograniczeń szybkości lub ochrony logowania na poziomie aplikacji
Analizy błędów z odniesieniem do użytkownika lub IP źródłowego
Korelacji SIEM lub monitoringu
Analizy kryminalistycznej po incydencie

Ważna jest granica zaufania: backend powinien traktować takie nagłówki jako zaufane tylko wtedy, gdy żądanie rzeczywiście pochodzi od Sophos Firewall lub zdefiniowanego Reverse Proxy. Publiczni klienci nie powinni móc bezpośrednio ustawiać X-Forwarded-For jako dowodu bezpieczeństwa. W praktyce serwer WWW powinien więc ufać tylko adresowi IP firewalla i ignorować lub nadpisywać nagłówki z innych źródeł.

Dla rozwiązywania problemów oznacza to: Log Viewer, reverseproxy.log i log backendu muszą obejmować ten sam czas testu. Jeśli w backendzie widoczny jest tylko adres IP firewalla, nie jest to automatycznie błąd WAF, lecz często normalne zachowanie Reverse Proxy.

Ograniczanie dostępu klienta

Nie każda aplikacja webowa musi być dostępna na całym świecie. Już w regule WAF można ograniczyć dostęp.

Sensowne ograniczenia:

Zezwalaj tylko na znane źródłowe adresy IP lub sieci partnerskie.
Blokuj niepotrzebne kraje.
Blokuj adresy IP o nieznanym kraju pochodzenia tylko wtedy, gdy ryzyko zablokowania własnego dostępu zostało sprawdzone.
Dla portali dodatkowo używaj WAF-MFA lub logowania wstępnego.
Blokuj znane złośliwe źródła za pomocą Threat Feeds.

Dla blokowania krajów i złośliwych IP pomocna jest instrukcja Sophos Firewall: Blokowanie krajów i złośliwych IP. Dla dynamicznych list zagrożeń istotne są Sophos Firewall Threat Feeds.

Planowanie Threat Feeds i Active Threat Response

Przy publicznie dostępnych aplikacjach webowych nie należy skupiać się tylko na samej regule WAF. Od SFOS 22 Threat Feeds nabierają znaczenia również dla ruchu przychodzącego, przekazywanego w ramach publikacji WAF i DNAT. Firewall może porównywać takie trafienia z MDR Threat Feeds, NDR Essentials i Third-Party Threat Feeds.

Dla administratorów oznacza to: WAF to warstwa publikacji, a Threat Feeds i Active Threat Response mogą blokować lub ujawniać dodatkowe znane złośliwe źródła. Nie zastępuje to jednak zarządzania łatkami, prawidłowego uwierzytelniania ani utwardzania aplikacji.

W praktyce warto sprawdzić:

Czy Active Threat Response jest sensownie skonfigurowany w środowisku?
Czy stosowane są odpowiednie Threat Feeds i czy są regularnie sprawdzane?
Czy podczas eksploatacji widoczne są zdarzenia WAF, logi Active Threat Response i logi backendu?
Czy istnieje proces obsługi fałszywych alarmów, list dozwolonych i awaryjnego zezwalania na dostęp?
Czy wiadomo, kto reaguje na trafienia i czy ruch jest tylko logowany, czy aktywnie blokowany?

Szczególnie przy portalach klientów, interfejsach administracyjnych lub dostępach partnerskich ta kontrola powinna odbyć się przed uruchomieniem. Jeśli później feed zablokuje ruch produkcyjny, zespół operacyjny musi wiedzieć, gdzie zobaczyć trafienie i jak prawidłowo rozstrzygnąć, czy chodzi o rzeczywisty atak, fałszywy alarm czy nieprawidłowo opublikowaną aplikację.

Profile ochrony i wyjątki

Reguła WAF powinna nie tylko publikować, ale także chronić. W tym celu używa się Protection Policies, opcjonalnych polityk IPS i wyjątków.

Typowe obszary ochrony:

Manipulacja ciasteczkami
Utwardzanie URL
Utwardzanie formularzy
Cross-Site Scripting
Ataki na aplikacje
Kontrola antywirusowa
Klienci o złej reputacji

W Web server > General settings znajdują się dodatkowe globalne ustawienia Web Server Protection, między innymi sterowanie wersjami TLS i ochrona przed wolnymi wzorcami HTTP DoS. Te ustawienia nie dotyczą tylko jednej reguły. Zmiany należy więc planować świadomie i uzgadniać z istniejącymi publikacjami WAF.

SFOS 23: Ukierunkowane dostosowanie profilu workerów

W Web server > General settings > Worker customization firewall oblicza wartości domyślne na podstawie dostępnych zasobów CPU i RAM; są one odpowiednie dla większości instalacji. Wyższe wartości mogą negatywnie wpływać na wydajność WAF i zasoby systemowe. Dlatego aktywuj Use custom worker profile tylko po potwierdzeniu potrzeby i ocenie skutków. Wcześniej udokumentuj dotychczasowe wartości oraz to, czy profil jest obliczany automatycznie, czy niestandardowy, utwórz kopię zapasową konfiguracji i zaplanuj okno konserwacyjne oraz rollback dokładnie do tego poprzedniego stanu. To dostosowanie nie jest zmianą Maximum sessions.

Start servers: Liczba procesów worker uruchamianych przy starcie serwera WWW.
Server limit: Maksymalna liczba procesów worker, które mogą działać jednocześnie.
Minimum spare threads: Minimalna liczba nieaktywnych wątków utrzymywanych w gotowości do obsługi nowych żądań.
Maximum spare threads: Maksymalna liczba nieaktywnych wątków, powyżej której nadmiarowe wątki są usuwane.
Threads per child: Maksymalna liczba wątków worker na proces worker.
Asynchronous request worker factor: Steruje skalowaniem procesów worker dla asynchronicznych połączeń i żądań.

Przy uwierzytelnianiu Reverse Proxy opartym na formularzu globalne pole Maximum sessions ogranicza łączną liczbę równoczesnych sesji użytkowników we wszystkich regułach WAF, które korzystają z tej metody uwierzytelniania. Wartość domyślna to 25,000, a dozwolony zakres wynosi od 100 do 100,000. Po osiągnięciu limitu firewall zamyka stare lub wygasłe sesje, aby dopuścić nowe. Nie jest to więc pojemność jednej reguły: wartość należy dobrać do równoczesnych logowań w objętych tym limitem aplikacjach, a po zmianie sprawdzić logowanie, wylogowanie i przełączanie sesji.

W przypadku Slow HTTP protection parametr Soft limit oznacza początkowy limit czasu na odebranie nagłówka żądania. Hard limit wyznacza bezwzględną górną granicę. Extension rate określa, ile kolejnych odebranych bajtów wydłuża soft limit o jedną sekundę. Te trzy wartości należy testować łącznie i z rzeczywiście wolnymi klientami; jeden zbyt liberalny parametr może niepotrzebnie osłabić ochronę.

W przypadku Slow HTTP protection wyjątki należy ograniczyć do najmniejszego wymaganego adresu IP lub sieci. Sophos obsługuje w tym miejscu obiekty hosta IP i sieci, ale nie zakresy adresów IP ani listy hostów. Minimum TLS version jest również ustawieniem globalnym; przed jego zaostrzeniem należy przetestować starsze klienty i wszystkie opublikowane aplikacje przez rzeczywiste połączenie zewnętrzne.

Jako globalne ustawienia TLS SFOS oferuje między innymi TLS v1.2 (wide compatibility), TLS v1.2 (strict) i TLS v1.3. Ustawienia Custom protocol configuration i Custom cipher configuration należy zmieniać tylko za pomocą udokumentowanych i przetestowanych wartości OpenSSL; zestawy szyfrów dla TLS 1.3 są zarządzane oddzielnie. Nieprawidłowe wartości mogą uniemożliwić uruchomienie zarządzanej przez SFOS usługi Apache, a tym samym Web Server Protection. Plan zmiany musi więc obejmować poprzednie wartości, kopię zapasową konfiguracji, okno konserwacyjne i alternatywny dostęp administracyjny. Następnie należy sprawdzić wszystkie publikacje WAF i reverseproxy.log; jeśli usługa nie uruchomi się, należy wycofać ostatnie wartości niestandardowe zamiast testować kolejne warianty w środowisku produkcyjnym.

W Protection Policies ważny jest tryb. Reject blokuje i generuje widoczne zdarzenia w Log Viewer dla reguł WAF. Monitor tylko loguje, ale te komunikaty WAF nie muszą pojawiać się w Log Viewer; wtedy trzeba sprawdzić reverseproxy.log. Monitor może być przydatny w pilotażu, ale przy ochronie produkcyjnej musi być jasne, czy ataki są tylko obserwowane, czy rzeczywiście odrzucane.

Common threat filter działa z czterema poziomami Filtering Strengths. Level 1 jest najbardziej tolerancyjny i nie jest logowany; od Level 2 trafienia pojawiają się w /log/reverseproxy.log, ale rośnie też ryzyko fałszywych alarmów. Poszczególne reguły należy wyłączać z kontroli tylko na podstawie potwierdzonego w logu Rule ID w Skip filter rules. Całkowite wyłączenie całej kategorii lub wyższego poziomu nie jest właściwym zamiennikiem tej analizy.

Static URL hardening rozróżnia wielkość liter, nie przyjmuje wildcardów i nie pomaga przy adresach URL tworzonych dynamicznie przez JavaScript. Form hardening porównuje strukturę formularza i obsługuje formularze do 8,000 bajtów. Jeśli zawartość binarna jest błędnie dostarczana jako HTML lub XML, obie funkcje mogą ją uszkodzić; najpierw należy więc poprawić Content-Type backendu, zamiast szeroko wyłączać ochronę.

W skanowaniu antywirusowym limit rozmiaru dotyczy łącznej objętości danych przesyłanych w jednym żądaniu, a nie każdego pliku osobno. Dodatkowy Request size limit dla treści HTTP wynosi od 1 do 1,024 MB, domyślnie 10 MB. HTTP Strict Transport Security dodaje nagłówek HSTS tylko wtedy, gdy reguła WAF używa Redirect HTTP; MIME-type sniffing protection ustawia X-Content-Type-Options: nosniff. Przesyłanie, pobieranie i nagłówki trzeba więc sprawdzić z rzeczywistą aplikacją.

IPS w regule WAF należy oceniać osobno. Sophos stosuje IPS dla WAF tylko wtedy, gdy komunikacja między firewallem a serwerem WWW odbywa się przez HTTP. Jeśli backend jest podłączony przez HTTPS, nie należy automatycznie oczekiwać, że wybrana polityka IPS będzie miała taki sam efekt.

Wyjątki powinny mieć wąski zakres. Jeśli aplikacja nie działa z powodu jednej ścieżki lub określonego źródła, nie należy wyłączać całego profilu ochrony. Lepszym rozwiązaniem jest ukierunkowany wyjątek z określoną ścieżką, źródłem i jasnym uzasadnieniem.

⚠️ Każdy wyjątek zmniejsza skuteczność ochrony. Ścieżka, źródło, powód, data i termin przeglądu powinny być udokumentowane, aby tymczasowe obejścia nie stały się trwałe.

Tworzenie Protection Policy i zrozumienie jej działania ochronnego

W Web server > Protection policies > Add nadaj opisową nazwę, na przykład WAF_Portal_Protection, skonfiguruj wymagane funkcje ochrony i wybierz Save. Następnie wybierz tę politykę w polu Protection reguły WAF; w SFOS 23 działa ona tylko na ścieżkach Protect. Istniejącej polityki standardowej, na przykład dla Exchange Autodiscover, należy używać wyłącznie w odpowiadającym jej przypadku zastosowania.

Przy pilotażowym wdrożeniu własnej aplikacji najpierw świadomie wybierz między Monitor a Reject. Monitor nie blokuje i nie wyświetla odpowiednich komunikatów WAF w Log Viewer; do ich analizy potrzebny jest reverseproxy.log. Większej widoczności zapewnianej przez Reject nie należy mylić z już przetestowaną zgodnością aplikacji. Pass Outlook anywhere pozwala zewnętrznym klientom Outlook omijać ochronę serwera WWW przy dostępie do Exchange. Opcja ta nie jest ogólnym rozwiązaniem problemów zgodności nowoczesnych portali i powinna pozostać wyłączona, jeśli nie ma uzasadnionego przypadku zastosowania starszej aplikacji.

Cookie signing dodaje do pliku cookie ustawionego przez serwer drugi plik cookie ze skrótem obliczonym z nazwy, wartości i sekretu znanego tylko firewallowi. Jeśli klient nie dostarczy pasującej pary, plik cookie zostanie odrzucony. Chroni to przed manipulacją, ale nie zastępuje bezpiecznych sesji aplikacji ani prawidłowej konfiguracji plików cookie backendu. Po aktywacji przetestuj logowanie, koszyk zakupowy i inne procesy zależne od plików cookie.

Przy Static URL hardening firewall podpisuje statyczne linki i na podstawie odpowiedzi serwera ocenia, które kolejne linki są dozwolone. Entry URLs definiuje wejściowe adresy URL, które mogą być dostępne bez podpisu funkcji hardening; dla prostej witryny takim punktem wejścia może być /. Lista ta nie jest ogólną listą routingu. Należy uwzględnić wielkość liter i nie wpisywać wildcardów. Aplikacje z adresami URL generowanymi przez JavaScript lub prawidłowymi bezpośrednimi linkami do podstron wymagają osobnego sprawdzenia. Form hardening podpisuje pierwotną strukturę formularza i odrzuca formularze, w których dokonano manipulacji. Nadal kluczowe są limit 8,000 bajtów i prawidłowy Content-Type HTML/XML.

Udokumentowany prosty przykład ochrony przed atakami wykorzystuje Reject, Static URL hardening z punktem wejścia /, Form hardening, Antivirus, Block clients with bad reputation i Common threat filter. Cookie signing, Pass Outlook anywhere i Skip remote lookups for clients with bad reputation są w nim wyłączone. Jest to profil testowy dla tego konkretnego scenariusza, a nie uniwersalne zalecenie ani dowód, że ustawienia domyślne są odpowiednie dla każdej aplikacji. W przypadku nowoczesnego portalu oceń każdy z tych przełączników na podstawie rzeczywistego ruchu aplikacji. Również wymienione tam Basic with passthrough nie jest zaleceniem dotyczącym MFA; tryb klienta, przekazywanie danych logowania i szablony wyjaśniono w podlinkowanym artykule o uwierzytelnianiu WAF i MFA.

Świadoma konfiguracja ochrony antywirusowej i reputacji

W Antivirus pole Mode określa, czy używany jest jeden, czy dwa silniki skanowania; przy skanowaniu pojedynczym należy wybrać silnik. Direction określa skanowanie przesyłania, pobierania lub obu kierunków. Block unscannable content blokuje na przykład zaszyfrowane lub uszkodzone pliki, których nie można sprawdzić. Zwiększa to skuteczność egzekwowania ochrony, ale może dotyczyć również prawidłowych zaszyfrowanych dokumentów; dlatego wcześniej należy ustalić dozwolone procesy biznesowe i sposób uzyskania wsparcia.

Limit scan size ogranicza objętość danych podlegających skanowaniu; 0 lub puste pole oznacza brak limitu rozmiaru skanowania. Przykład: przy limicie skanowania 50 MB i plikach o rozmiarach 45, 5 i 10 MB przesyłanych jednocześnie ostatni plik nie zostanie przeskanowany. Udane przesłanie nie dowodzi więc, że sprawdzono każdy zawarty w nim plik. Ten limit skanowania należy odróżnić od Request size limit dla całej treści HTTP: większy limit treści nie oznacza automatycznie, że więcej danych będzie można przeskanować. Dobierz limity do rzeczywistych potrzeb przesyłania, zasobów i wymagań bezpieczeństwa oraz sprawdź przesyłanie wielu plików i zawartość niemożliwą do przeskanowania w środowisku dopuszczonym do testów.

Block clients with bad reputation wykorzystuje informacje RBL i GeoIP: Sophos SXL dla RBL oraz MaxMind dla GeoIP. Udokumentowane są również blokady dla klasyfikacji A1 (anonimowe proxy lub usługi VPN) i A2 (satelitarny dostawca internetu). Może to wpływać na prawidłowy dostęp partnerów. Skip remote lookups for clients with bad reputation może poprawić wydajność, ale zmienia ocenę opartą na zdalnych zapytaniach; nie włączaj tej opcji bez świadomej decyzji i nie utożsamiaj jej z listą dozwolonych źródeł.

Ocena Common threat filter według kategorii i siły filtrowania

Kategorie odpowiadają na różne pytania i należy świadomie dobierać je do aplikacji:

Application attacks: Wykrywa między innymi niedozwolony dostęp do ścieżek i typowe próby wykonania poleceń, również po ewentualnym włamaniu.
SQL injection attacks: Sprawdza argumenty żądania pod kątem osadzonych poleceń SQL i znaków ucieczki.
XSS attacks: Sprawdza dane wejściowe pod kątem osadzonych znaczników skryptów i kodu.
Protocol enforcement: Sprawdza zgodność z protokołem, typowe nagłówki, takie jak Host i User-Agent, limity argumentów i dozwolone użycie HTTP. Nietypowy, ale prawidłowy klient również może więc zostać wykryty.
Scanner detection: Wykrywa typowe wzorce botów, crawlerów i skanowania; mimo to należy przetestować pożądany dostęp wyszukiwarek i monitoringu.
Data leakage: Zapobiega przedostawaniu się poufnych informacji do klienta, na przykład przez komunikaty o błędach serwera. Przy aktywnym Application attacks lub SQL injection attacks należy również sprawdzić tę kategorię, ponieważ zakresy wykrywania się pokrywają.

Filter strength jest domyślnie ustawione na Level 1 i generuje najmniej fałszywych alarmów. Level 2 dodaje na przykład wyrażenia regularne dla SQL/XSS Injection i kolejne słowa kluczowe związane z wstrzykiwaniem kodu; Level 3 dodaje reguły, listy słów kluczowych i limity znaków specjalnych; Level 4 jeszcze bardziej ogranicza znaki specjalne i wymaga szczególnie dokładnych testów pod kątem fałszywych alarmów przed uruchomieniem produkcyjnym. Wcześniej opisane ograniczenia logowania pozostają w mocy: Level 1 nie jest logowany, a Level 2 i wyższe pojawiają się w /log/reverseproxy.log. Nie uznawaj wyższej siły filtrowania za bezpiecznie zweryfikowaną tylko dlatego, że otwiera się strona startowa.

Sprawdzenie HSTS i ochrony MIME przed włączeniem

Przy HTTP Strict Transport Security i aktywnym Redirect HTTP firewall dodaje następujący nagłówek:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 odpowiada jednemu rokowi. Dotyczy to nie tylko testowanego punktu wejścia: includeSubDomains obejmuje subdomeny, a przeglądarki mogą zapisać tę dyrektywę. Przed aktywacją HTTPS, certyfikaty i wszystkie objęte nią subdomeny muszą działać niezawodnie w dłuższej perspektywie; późniejsze odznaczenie pola wyboru nie cofa natychmiast dyrektyw już zapisanych przez przeglądarki. Samo preload w nagłówku nie dowodzi umieszczenia na liście preload przeglądarki. MIME-type sniffing protection dodaje X-Content-Type-Options: nosniff; dlatego błędne typy MIME należy poprawić na backendzie, zamiast całkowicie usuwać nagłówek. Sprawdź oba nagłówki na kliencie zewnętrznym.

Tworzenie wyjątków o niezbędnym, możliwie wąskim zakresie

W Add new exception określ Paths, Sources, Operation oraz konkretne kontrole, które mają być pomijane. Ścieżki wyjątków rozróżniają wielkość liter i dopuszczają wildcardy, na przykład /products/*/images/*. Odróżnia je to od Entry URLs polityki Static URL Hardening, które nie dopuszczają wildcardów. W Operation kluczowy jest operator logiczny: jednoczesne dopasowanie ścieżki i źródła ma węższy zakres niż dopasowanie ścieżki lub źródła. Przed zapisaniem sprawdź zamierzoną część wspólną warunków, aby przypadkowo nie wyłączyć ochrony dla źródła partnera we wszystkich ścieżkach.

Dla Sources wyjątku udokumentowano adresy IP, zakresy, listy i sieci. Nie należy przenosić tego na inne pola: w Path-specific routing w SFOS 22 oraz w polach Allowed client networks i Blocked client networks dla Passthrough w SFOS 23 udokumentowano tylko typy hostów IP i Network, a nie IP ranges ani IP lists. Aby zapewnić przewidywalne ograniczenie dostępu, używaj tam pojedynczych obiektów IP lub sieci.

Przełączniki wyjątku pomijają między innymi Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation i wybrane kategorie Common Threat. Dwie opcje wymagają dodatkowej ostrożności:

Never change HTML during static URL hardening or form hardening zapobiega modyfikowaniu strony HTML, na przykład gdy aplikacja wymaga niezmienionych linków. Nie oznacza to automatycznie, że niepodpisane linki będą akceptowane; do tego może być potrzebny ukierunkowany wyjątek od funkcji hardening.
Accept unhardened form data akceptuje dane formularza bez podpisu funkcji hardening. Sam wyjątek od Form hardening tego nie zapewnia. To dodatkowe zezwolenie usuwa kolejną kontrolę i jest odpowiednie tylko dla precyzyjnie ograniczonego, uzasadnionego procesu.

Najpierw zachowaj prawidłowe żądanie, które powoduje błąd, czas jego wykonania i potwierdzony Rule ID. Następnie powtórz to samo żądanie i przeprowadź kontrolę porównawczą ze źródłem lub ścieżką nieobjętymi wyjątkiem. Wyjątek ma właściwie ograniczony zakres dopiero wtedy, gdy wymagany proces działa, a pozostała ochrona zostaje zachowana; w razie wątpliwości wyłącz z kontroli pojedynczy potwierdzony Rule ID w Skip filter rules, zamiast całego obszaru ochrony.

Ponowna walidacja zmigrowanych Protection Policies

Od SFOS 18 Web Server Protection używa OWASP ModSecurity Core Rule Set 3.0. Podczas migracji starszych Protection Policies wcześniejsze kategorie zostały połączone, identyfikatory reguł przypisano ponownie i wprowadzono Filtering Strengths. Jeśli jedna z połączonych kategorii była wcześniej aktywna, nowa wspólna kategoria może być aktywna nawet wtedy, gdy inny obszar był wcześniej wyłączony.

Po takim uaktualnieniu nie wystarczy porównać samej nazwy polityki. Aktywne kategorie, wyjątki i Filtering Strengths trzeba sprawdzić względem wcześniejszej dokumentacji. Następnie należy przeprowadzić kontrolowane testy pozytywne i negatywne z rzeczywistym ruchem aplikacji oraz sprawdzić Log Viewer i reverseproxy.log. Dopiero gdy prawidłowe żądania nadal działają, a oczekiwane ataki testowe są wykrywane, zmigrowaną politykę można uznać za zweryfikowaną.

Dla dawnej migracji SFOS 18 istotne są następujące przyporządkowania: Protocol violations, Protocol anomalies, Request limits i HTTP policy zostały połączone w Protocol enforcement; Generic attacks i Tight security w Application attacks; Bad robots przekształcono w Scanner detection, a Outbound w Data leakage. Rigid filtering jest migrowane do Level 1 i wymaga świadomej ponownej oceny. Kategoria Trojans została usunięta; odpowiednią ochronę przejmuje Antivirus. Reguły już wyłączone z kontroli, którym przypisano nowy Rule ID, pozostają wyłączone, natomiast identyfikatory bez przyporządkowania, usunięte lub połączone w nową regułę są usuwane z listy pomijanych reguł. Dlatego nie kopiuj starej listy wyjątków bez sprawdzenia, lecz porównaj ją z bieżącą polityką i aktualnymi logami.

Routing specyficzny dla ścieżki, WebSocket i równoważenie obciążenia

WAF może przekazywać żądania do różnych serwerów backendowych w zależności od ścieżki. Jest to przydatne, gdy aplikacja ma wiele komponentów lub jedna nazwa hosta ma obsługiwać kilka wewnętrznych usług.

Przykłady:

/api/ trafia do serwera API.
/shop/ trafia do systemu sklepowego.
/ trafia do domyślnego serwera WWW.

Firewall nie ocenia ścieżek według kolejności w tabeli, lecz nadaje priorytet dłuższym, a więc bardziej specyficznym ścieżkom przed trasą domyślną. To przypisanie trzeba przetestować w sposób ukierunkowany. Tylko dla SFOS 22: Dla wymaganej ścieżki witryny można aktywować pole wyboru WebSocket passthrough; ruch WebSocket jest wtedy przekazywany bez ochrony WAF, ponieważ danych WebSocket nie można sprawdzać tak jak zwykłego ruchu HTTP. Dla SFOS 23: W Traffic routing skonfiguruj wyłącznie wymaganą ścieżkę WebSocket z Action > Passthrough i przewidzianym backendem. Ten tunel działa bez inspekcji WAF i bez polityki ochrony; pozostałe ścieżki aplikacji pozostają ustawione na Protect. Nigdy nie przestawiaj całego portalu na Passthrough jako obejście problemu. Osobno przetestuj upgrade połączenia, transmisję danych i ponowne połączenie. Nie można z tego wyciągać żadnych wniosków o wymuszaniu MFA przez Passthrough; jeśli wymagane jest uwierzytelnianie, ustal odpowiedzialność z osobą odpowiedzialną za uwierzytelnianie.

Tylko dla SFOS 22: W procedurze z Protected servers domyślna ścieżka / przekazuje żądania bez bardziej specyficznego dopasowania do przypisanego serwera domyślnego. Po usunięciu tej trasy domyślnej firewall odrzuca takie żądania z 404 Not Found. Dla SFOS 23: Żądania bez bardziej specyficznego dopasowania używają akcji przypisanej do /; w nowych regułach jest to domyślnie Block. Świadomie zachowaj tę trasę domyślną, jeśli mają być publikowane tylko pojedyncze ścieżki. Protect dla / ma sens tylko wtedy, gdy zamierzona jest publikacja całej aplikacji, i wymaga sprawdzenia dodatkowej dostępności. Dla SFOS 23 nie jest gwarantowany stały status 404: odpowiedź akcji Block konfiguruje się przez Response code.

Przy wielu serwerach backendowych możliwe są Sticky Sessions lub Hot-standby. Pomaga to w prostych przypadkach wysokiej dostępności lub rozkładania obciążenia, ale nie zastępuje pełnej koncepcji równoważenia obciążenia aplikacji.

Bez dodatkowego powiązania żądania są rozdzielane między kilka wybranych serwerów WWW. Sticky session cookie wiąże przeglądarkę z jednym serwerem backendowym; jeśli ten serwer ulegnie awarii, ciasteczko zostaje zaktualizowane, a sesja przełączona na inny serwer. Nie gwarantuje to przeniesienia stanu aplikacji: na przykład koszyk zakupowy może wymagać wspólnego magazynu sesji.

Hot-standby mode początkowo wysyła wszystkie żądania do pierwszego wybranego serwera, a pozostałe wykorzystuje jako zapasowe. Po przywróceniu serwera głównego sesje co do zasady wracają na niego; przy włączonym Sticky session cookie istniejąca sesja pozostaje na serwerze zapasowym. Dlatego w ramach odbioru należy osobno sprawdzić serwer główny, kolejność serwerów zapasowych, awarię, przywrócenie działania oraz rzeczywisty proces logowania lub obsługi koszyka, który wymaga zachowania stanu.

Pole Authentication jest wymienione również w tabeli SFOS 23 dla Passthrough, podczas gdy przegląd funkcji przypisuje uwierzytelnianie do Protect. Tej rozbieżności w dokumentacji nie należy rozstrzygać na podstawie przypuszczeń. Jeśli wymagane jest WAF-MFA, chroniona część powinna opierać się na Protect i jawnie określonej polityce; rozgraniczenie i testy opisano w Uwierzytelnianie WAF z MFA.

Dostęp do zdalnych backendów WAF przez SD-WAN

Jeśli chroniony serwer WWW nie znajduje się w lokalnej sieci firewalla, routing i SD-WAN trzeba sprawdzić szczególnie świadomie. Dla backendów dostępnych przez łącza między lokalizacjami, MPLS lub route-based IPsec może być potrzebna pasująca SD-WAN Route, aby firewall niezawodnie osiągał Protected Server i aby zgadzała się ścieżka powrotna. Przy route-based IPsec ważne jest dodatkowo: WAF przez route-based IPsec z Traffic Selectors dla podsieci nie jest obsługiwany przez Sophos; połączenia Any-to-Any są udokumentowaną alternatywą.

Konfiguracja udokumentowana przez Sophos rozpoczyna się od działającej reguły WAF i osiągalnego tunelu route-based. W Routing > Gateways należy utworzyć obiekt gateway dla zdalnej ścieżki z adresem IP drugiej strony, zaadresowanym interfejsem XFRM i niezawodnym hostem monitorującym za drugą stroną tunelu. Dopiero potem w Routing > SD-WAN routes tworzy się ukierunkowaną trasę dla ruchu proxy WAF:

W Routing > Gateways > IPv4 gateway > Add utwórz i zapisz gateway. W przykładzie nosi on nazwę gw6, ma Gateway IP 10.12.13.2 i Interface xfrm1-10.12.13.1. W Monitoring condition użyj hosta za gatewayem, który niezawodnie odpowiada; udokumentowany przykład wykorzystuje 10.12.13.2. Te prywatne adresy i interfejs zastąp rzeczywistą adresacją tunelu oraz odpowiednim hostem monitorującym.
W Routing > SD-WAN routes wybierz IPv4 i Add, nadając na przykład nazwę SD-WAN_WAF_Portal. W Destination networks usuń Any i wybierz publiczny interfejs WAN lub Hosted address, przez który klient dociera do reguły WAF; w przykładzie jest to #Port1. W tej udokumentowanej trasie WAF nie chodzi po prostu o prywatny adres IP backendu.
W Services usuń Any i wybierz zewnętrzny Listening Port reguły WAF, w przykładzie TCP 8080. Jeżeli różni się on od wewnętrznego portu backendu, należy tu wyraźnie użyć portu zewnętrznego. Niestandardowy port trzeba również uwzględnić w zewnętrznym wywołaniu testowym.
W Link selection settings wybierz Primary and Backup gateways, a w Primary gateway ustaw wcześniej utworzony gateway XFRM gw6. Zapisz trasę. Jeżeli kilka publikacji korzysta z tego samego gatewaya, ta sama SD-WAN Route może zawierać kilka publicznych adresów WAN i Listening Ports. Dla różnych gatewayów potrzebne są osobne trasy.

Procedura SD-WAN odsyła do instrukcji konfiguracji route-based VPN z Traffic Selectors; dokumentacja referencyjna reguł WAF wyraźnie wyklucza jednak Traffic Selectors oparte na podsieciach. Dlatego dla tego zastosowania WAF należy zaplanować połączenie Any-to-Any i nie traktować tytułu podlinkowanej instrukcji jako potwierdzenia obsługi konfiguracji selektorów podsieci.

Odbiór rozdziela następnie warstwy: test zewnętrzny musi trafić w oczekiwaną regułę WAF; w Log Viewer należy skorelować regułę WAF, błędy reverse proxy i czas; na firewallu muszą być aktywne interfejs XFRM, monitor gatewaya i SD-WAN Route; serwer backendowy musi otrzymać żądanie i odpowiedzieć przewidzianą ścieżką. Sam zielony status tunelu nie potwierdza ani dopasowania SD-WAN, ani osiągalności backendu.

Eksploatacja i rozwiązywanie problemów

W eksploatacji ważne jest, aby można było nadal prześledzić działanie publikacji: która reguła dopasowuje ruch, które logi są istotne, jakie wyjątki istnieją i jak postępować w razie problemów.

Typowe błędy

Publiczna nazwa DNS wskazuje na niewłaściwy adres IP: reguła WAF nigdy nie jest osiągana.
Certyfikat nie pasuje do nazwy hosta: przeglądarki pokazują błędy certyfikatu albo dopasowanie SNI jest nieprawidłowe.
Wybrano niewłaściwą Hosted address: firewall dopasowuje inną regułę albo nie dopasowuje żadnego ruchu WAF.
Allowed client networks puste: reguła nie działa zgodnie z oczekiwaniami.
Limit reguł WAF nie został uwzględniony: kolejnych publikacji nie da się już prawidłowo odwzorować.
Wersja Exchange nowsza niż 2013 planowana z szablonem WAF: szablon nie odpowiada zakresowi wersji obsługiwanych przez WAF.
Konflikt portu z User Portal, VPN Portal lub inną usługą: aplikacja nie jest dostępna albo odpowiada usługa firewalla.
Backend nie jest dostępny wewnętrznie: zewnętrzni klienci otrzymują błędy, mimo że DNS i certyfikat są poprawne.
Timeout backendu ustawiony nieprawidłowo: długie odpowiedzi kończą się błędami, chociaż aplikacja zasadniczo jest osiągalna.
Backend dostępny przez VPN lub SD-WAN bez pasującej trasy: reguła WAF dopasowuje ruch, ale Protected Server nie jest niezawodnie osiągalny.
Route-based IPsec z Traffic Selectors do backendu: WAF przez tę ścieżkę nie jest obsługiwany.
Zbyt szeroko ustawiony wyjątek WAF: skuteczność ochrony niepotrzebnie maleje.
Aplikacja WebDAV opublikowana przez WAF: aplikacja nie działa niezawodnie albo nie jest obsługiwana.
Ścieżka URL zawiera %2F: WAF odpowiada kodem 404 Not Found, mimo że zasób jest dostępny bezpośrednio na backendzie. %2F to zakodowana w URL postać ukośnika / i trzeba ją odróżnić od zwykłego błędu 404 backendu.
Zmiana reguły bez okna konserwacyjnego: istniejące połączenia mogą zostać przerwane przy ponownym uruchomieniu reguł WAF.
Stara reguła DNAT i nowa reguła WAF konkurują: nie jest jasne, która publikacja przetwarza ruch.

Rozwiązywanie problemów

Jeśli publikacja WAF nie działa, należy systematycznie sprawdzić:

Czy publiczna nazwa DNS wskazuje na właściwy publiczny adres IP?
Czy w regule WAF wybrano właściwą Hosted address?
Czy port nasłuchu jest wolny i nie jest zajęty przez WebAdmin, User Portal, VPN Portal lub inną publikację?
Czy certyfikat pasuje do wywołanej nazwy hosta?
Czy wewnętrzny serwer WWW jest dostępny z firewalla?
Czy Allowed client networks, Blocked client networks i Blocked countries są poprawnie ustawione?
Czy Protected Server jest dostępny przez trasę, SD-WAN Route lub połączenie VPN, które rzeczywiście pasuje z perspektywy firewalla?
Czy istnieje bardziej ogólna reguła WAF, która dopasowuje się wcześniej?
Czy dostęp jest wyświetlany w Log Viewer jako dozwolony, zablokowany lub odrzucony?
Czy są wskazówki w /log/reverseproxy.log?
Czy Protection Policy jest ustawiona na Monitor czy Reject?
Czy timeout obiektu web server pasuje do aplikacji?

Do pierwszej analizy przydatny jest Log Viewer. Do głębszego rozwiązywania problemów pomocne są logi Web Server Protection na firewallu. Przegląd plików logów i usług znajduje się w Sophos Firewall Troubleshooting: Services i Logs.

WAF odpowiada błędem 404, gdy ścieżka zawiera `%2F`

Szczególny problem dotyczy adresów URL zawierających zakodowany ukośnik. Wywołanie takie jak https://portal.example.com/api/files/project%2Freport.pdf może przez Sophos WAF zwrócić 404 Not Found, mimo że zasób istnieje bezpośrednio na backendzie. Sophos śledzi to zachowanie pod numerem NC-159041 i obecnie nie wskazuje ani konkretnej dotkniętej problemem lub poprawionej wersji SFOS, ani obsługiwanego obejścia.

Aby zawęzić przyczynę, należy w kontrolowany sposób porównać to samo żądanie przez WAF i bezpośrednio na backendzie. Ważne są dokładny URL i czas testu:

Sprawdź, czy ścieżka rzeczywiście zawiera %2F. Zwykły ukośnik / lub brak domyślnej ścieżki oznacza inny problem.
Porównaj czas w Log Viewer, /log/reverseproxy.log i logu dostępu serwera WWW.
Jeśli na backendzie nie pojawia się pasujący wpis dla żądania, prawdopodobnie zostało ono odrzucone jeszcze przed serwerem WWW. Bezpośredni test backendu pozwala jednocześnie wykluczyć brak samego zasobu.

Szeroki wyjątek WAF nie rozwiązuje tego problemu w sposób ukierunkowany i niepotrzebnie osłabiłby ochronę. Nie należy też zmieniać konfiguracji Apache zarządzanej przez SFOS: restrykcyjna obsługa zakodowanych ukośników pomaga zapobiegać omijaniu kontroli ścieżek lub dostępu.

Najczystszym rozwiązaniem jest generowanie przez aplikację lub jej producenta adresów URL bez zakodowanych ukośników. Jeśli nie jest to możliwe, należy świadomie zestawić inną metodę publikacji, taką jak DNAT, odpowiedni reverse proxy lub dostęp prywatny, z utratą ochrony WAF. W przypadku aplikacji, których nie można zmienić, Sophos Support powinien sprawdzić konkretną kompilację SFOS i przypadek użycia. Zapisy project%2Freport.pdf oraz project/report.pdf są jedynie wzorcem diagnostycznym i nie są automatycznie funkcjonalnie równoważne.

Lista kontrolna dla produkcyjnych reguł WAF

Nazwa reguły opisuje aplikację, nazwę hosta i środowisko.
Odpowiedzialna osoba lub właściciel systemu jest udokumentowany.
DNS, certyfikat i Hosted address są sprawdzone.
Dostępność backendu została przetestowana z firewalla.
Poprzednia publikacja i rollback są udokumentowane.
Stare reguły DNAT lub firewalla nie konkurują z regułą WAF.
Zdefiniowane są zewnętrzne testy uruchomieniowe.
Dostęp jest ograniczony do niezbędnych źródeł lub krajów.
Threat Feeds i Active Threat Response zostały ocenione dla publicznych aplikacji.
Logowanie jest aktywne.
Profil ochrony nie jest niepotrzebnie dezaktywowany.
Wyjątki są wąskie, uzasadnione i ograniczone czasowo.
Zmiana została przetestowana zewnętrznie.
Data wygaśnięcia lub termin przeglądu jest udokumentowany.

Klasyfikacja obiektów WAF w XML API

W automatyzacji publikacja, backend i polityka ochrony są ze sobą powiązane, ale pozostają odrębnymi obiektami. FirewallRule z PolicyType HTTPBased zawiera HTTPBasedPolicy; RealServers opisuje serwer WWW backendu, a ProtocolSecurity — politykę ochrony. Reguła WAF odwołuje się do tych obiektów, ale nie zastępuje ich konfiguracji. Dostęp, weryfikację TLS, sekrety, jawne operacje zapisu i ocenę statusu XML wyjaśnia artykuł Bezpieczne ograniczanie dostępu do XML API.

Poniższe mapowania wyjaśniają dokumentację referencyjną SFOS 22 i 23, ale nie są gotowymi do wykonania szablonami żądań. Przed każdym zapisem należy porównać API help zainstalowanej kompilacji z istniejącym obiektem, przygotować kopię zapasową i sposób wycofania zmian oraz najpierw sprawdzić nieszkodliwe zapytanie odczytu. Jeśli składnia, jednostka lub mapowanie akcji pozostają niejasne, nie należy wykonywać zapisu, lecz zwrócić się do pomocy technicznej o wyjaśnienie. Dotyczy to szczególnie sytuacji po zmianie wersji.

Nie myl publikacji ze ścieżkami dostępu

Name identyfikuje FirewallRule; dokumentacja referencyjna dopuszcza najwyżej 60 znaków, bez przecinków, w UTF-8. Position jest wymagane i przyjmuje Bottom, Top, After lub Before; w dwóch ostatnich wariantach należy również wskazać nazwaną regułę odniesienia. Dla Status tabela podaje wartość domyślną ON oraz wartości zapisu Disable i Enable: pominięcie pola nie jest bezpiecznym sposobem przygotowania wyłączonej publikacji. Według tabeli LogTraffic ma domyślną wartość Disable; logowanie należy jawnie sprawdzić. IPFamily we wspólnym kontrakcie FirewallRule oferuje również IPv6, jednak HTTPBasedPolicy jest wyraźnie ograniczone do IPv4. Reguły sieciowe i użytkowników opisano w artykule Reguły zapory; nie należy przenosić ich jako treści żądania WAF.

W części WAF pola HostedAddress, ListenPort, HTTPS, HTTPSCertificate i Domains/Domain odpowiadają publicznemu listenerowi. Tabela wymienia HostedAddress, ListenPort, HTTPS i Domains jako pola wymagane. ListenPort jest liczbą całkowitą od 1 do 65535; udokumentowane wartości to 80 przy wyłączonym HTTPS i 443 przy włączonym HTTPS. Nie jest to port backendu. RedirectHTTP odpowiada za osobne przekierowanie HTTP. Po każdej zmianie należy sprawdzić łącznie publiczną nazwę, certyfikat i listener.

Mapowania ścieżek znajdują się w HTTPBasedPolicy/AccessPaths/AccessPath. W tym bloku backend odwołuje się do obiektów serwerów WWW; allowed_networks, denied_networks, blocked_countries i block_unknown_country opisują dostęp klientów. stickysession_status i hot_standby dotyczą przypisania sesji do backendu i wyboru backendu. Politykę uwierzytelniania, do której istnieje odwołanie, omówiono w artykule o uwierzytelnianiu WAF; samo istnienie pola nie oznacza przetestowanego wymuszania MFA dla każdej akcji.

Różnica między wersjami: Tabela SFOS 22 opisuje path jako pojedynczy ciąg znaków, a backend jako wymaganą tablicę. W SFOS 23 path jest tablicą z wieloma wartościami, natomiast backend jest oznaczone jako opcjonalne. Według tabeli wartości ścieżek są ograniczone do 63 znaków i nie mogą zawierać przecinków. Opcjonalność nie oznacza tutaj, że publikacja ścieżki Protect lub Passthrough bez przypisanego backendu ma sens: bieżący interfejs wymaga wyboru backendu dla tych akcji, natomiast Block i Redirect nie publikują backendu.

SFOS 23 dodaje zapisane małymi literami action z dozwolonymi wartościami 0, 1, 2, 3, a także response_code, redirect_protocol, redirect_host, redirect_port i redirect_path. Dokumentacja referencyjna nie przypisuje tych czterech liczb do akcji interfejsu. Nie należy tworzyć mapowania na podstawie kolejności ani przypuszczeń; potwierdzone mapowanie dla zainstalowanej kompilacji jest warunkiem każdej automatycznej zmiany. Zapisane wielką literą Action z wartościami Accept, Drop, Reject występuje w przykładzie w UserPolicy lub NetworkPolicy, a nie w bloku WAF. Nie zastępuje ani nadrzędnej akcji WAF w interfejsie, ani AccessPath/action. Dla redirect_protocol tabela podaje dosłownie http i https, dla redirect_port zakres od 1 do 65535, a dla redirect_path najwyżej 8192 znaków. response_code jest tam opisane jedynie jako liczba całkowita; dla konkretnej konfiguracji rozstrzygający pozostaje opisany wyżej wybór w interfejsie.

Również przykład nie jest dowodem poprawności schematu: miesza path i Path, zawiera puste odwołania i symbole zastępcze oraz nie pokazuje w pełni HTTPSCertificate ani LogTraffic w bloku WAF. SFOS 22 nadal pokazuje websocket_passthrough; SFOS 23 używa modelu akcji. Pisownię, zagnieżdżenie, wymagane pola i logowanie należy zatem potwierdzić w kontrakcie właściwym dla danej kompilacji, zamiast mechanicznie uzupełniać przykład. ProtocolSecurity w bloku WAF odwołuje się do polityki ochrony. Zaawansowane przełączniki PassHostHeader, RewriteHTML, RewriteCookies i CompressionSupport należą do opisanych wyżej ustawień odwrotnego proxy; nie należy ujednolicać sprzecznych wartości z przykładu i tabeli w samodzielnie utworzone zestawy wartości wyliczeniowych.

Przykład pokazuje ponadto SourceNetworks/Network i ExceptionNetworks/Network, podczas gdy jego komentarz wymienia alternatywnie Authentication, AllowFrom, BlockFrom lub AccessPaths. Nie należy z tego wywodzić równoważności aliasów, dozwolonych kombinacji ani reguł pierwszeństwa. W przypadku istniejących obiektów z takim sposobem przedstawienia dostępu należy wyjaśnić strukturę i działanie w zainstalowanej kompilacji; jeśli pozostają niejasne, nie należy wykonywać automatycznego zapisu.

Dla wyjątków istnieje osobny blok Exceptions/Exception. Pola path, source i op łączą w nim warunki; dla op tabela podaje dosłownie and, or, AND, OR. skipcookie, skipurl, skipform, skipav i skipbadclients pomijają odpowiednie kontrole. Natomiast skiphtmlrewrite zapobiega modyfikacji pasujących treści, a skipform_missingtoken dodatkowo, oprócz wyjątku dotyczącego formularza, dopuszcza dane formularza bez podpisu mechanizmu hardeningu. Odpowiedni wiersz tabeli zamienia miejscami opis i wartość domyślną; nie należy na tej podstawie ustalać wiarygodnej wartości domyślnej. Decydujące pozostają opisane wyżej skutki obu opcji dla bezpieczeństwa. skip_threats_filter_categories używa innych tokenów niż polityka ochrony, na przykład application_attacks i data_leakages. Nie należy zamieniać tych tokenów wyjątków z nazwami wyświetlanymi w polityce. Nieaktualny opis wcześniejszych kategorii również nie stanowi potwierdzenia dopuszczalności starych tokenów. Po zmianie należy osobno sprawdzić dozwoloną ścieżkę, zablokowaną ścieżkę, trasę przechwytującą pozostałe żądania oraz żądanie nieobjęte wyjątkiem.

Tabela opisuje path dla tras Site-Path; przykład wyjątku pokazuje natomiast wiele elementów path w obrębie Exception, bez jednoznacznego, odrębnego kontraktu tabelarycznego. Dlatego nie należy przenosić kardynalności ani ograniczeń ścieżek routingu na wyjątki. Przed automatycznymi zmianami wyjątków należy potwierdzić strukturę, liczbę i dopuszczalne wartości w zainstalowanym buildzie; jeśli kontrakt pozostaje niejasny, nie należy dokonywać zapisu.

Bezpiecznie sprawdzaj kontrakt backendu i limit czasu

Dla RealServers pola Name, Host, Port i TimeOut są udokumentowane jako wymagane. Name dopuszcza najwyżej 60 znaków UTF-8 bez przecinka. Host jest odwołaniem do obiektu hosta IP lub FQDN, a nie dowolnie wymienną publiczną nazwą WAF. Port ma zakres od 1 do 65535, z domyślną wartością API 80; Type podaje dosłownie Plaintext (HTTP) lub Encrypted (HTTPS). W przypadku backendu HTTPS należy więc jawnie porównać rzeczywisty listener i port, zamiast przyjmować domyślny port API.

API opisuje TimeOut z wartością domyślną 300, zakresem od 1 do 65535 i uwagą, że obowiązuje tylko przy włączonym Keep alive. GUI wyjaśnia natomiast Timeout jako czas oczekiwania na dane przesyłane do backendu lub z backendu i wskazuje HTTP-502 po jego upływie. Jest to odmienny opis, a nie dowód identycznego zachowania przy wyłączonym Keep-alive. Dla konfiguracji w interfejsie należy zastosować opisany wyżej test przerw w przesyłaniu danych; przed automatyzacją należy wyjaśnić zależność i zapisaną wartość w zainstalowanej kompilacji. Nie należy wywodzić z tego potrzeby globalnego zwiększenia limitu czasu.

Dla KeepAlive przykład pokazuje Enable/Disable, ale tabela podaje jedynie 0 i Enable oraz wartość domyślną ON. Nie należy po cichu naprawiać tej rozbieżności przez przyjęcie domniemanego Disable. DisableReuse podaje Disable i Enable i odpowiada Disable backend connection pooling. Należy zachować stan sprzed zmiany, ponownie odczytać zmieniony obiekt i dopiero potem sprawdzić reprezentatywny transfer danych oraz logi backendu. Sama odpowiedź API nie dowodzi ani osiągalności backendu, ani właściwych ustawień połączeń.

Polityka ochrony i opcje zależne

Według tabeli ProtocolSecurity wymaga Name, Mode i RequestSizeLimit. Dla Name obowiązuje limit 60 znaków UTF-8 bez przecinka; Mode podaje Monitor i Reject. Przełączniki CookieSigning, StaticUrlHardening i FormHardening odpowiadają opisanej wyżej ochronie plików cookie, adresów URL i formularzy. Według tabeli PassOutlookAnywhere ma domyślną wartość OFF: API opisuje dostęp do Exchange jedynie skrótowo, podczas gdy GUI wyraźnie wskazuje ominięcie Web Server Protection. Bez uzasadnionego zastosowania dla starszych systemów należy więc pozostawić tę opcję wyłączoną, a nie traktować jej jako zwykłego przełącznika zgodności. Przy włączonym StaticUrlHardening dokumentacja referencyjna opisuje EntryURLType z wartościami Manual, SitemapFile, SitemapURL; dla wariantu ręcznego przykład pokazuje EntryURLList/EntryURL z wieloma adresami Entry URL, każdy o długości najwyżej 255 znaków. Nie należy z tego wywodzić, że GUI oferuje wszystkie warianty API w identyczny sposób.

Tabela API podaje dla CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation i ThreatsFilter wartość Default OFF, a dla ParanoiaLevel wartość Default 1. Nowa lub wskazana przez odwołanie Policy nie stanowi więc jeszcze dowodu na włączenie kontroli ochronnych. Przy tworzeniu należy jawnie ustawić zamierzone przełączniki i odczytać je ponownie. Przy Edit bez potwierdzonego kontraktu aktualizacji nie należy zakładać ani zachowania pominiętych pól, ani przywrócenia wartości Defaults.

Przy włączonym AntiVirus znaczenie mają AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent i LimitScanSize. Liczba całkowita Megabytes zależy dodatkowo od włączonego LimitScanSize. Pozostaje to niezależne od limitu treści żądania. SkipRemoteLookups zależy od BlockClientsWithBadReputation; nie należy wywodzić działania kontroli reputacji wyłącznie ze skrótowego opisu API.

ThreatsFilter włącza Common threat filter. Należą do niego ThreatFilters/Filter, ParanoiaLevel z zakresem od 1 do 4 oraz SkipFilterRules/FilterRules jako lista całkowitoliczbowych identyfikatorów reguł. Dozwolone tokeny filtrów brzmią dosłownie Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. Ostatni token różni się od nazwy w GUI Data leakage. Wyjątkami należy obejmować w sposób ukierunkowany tylko potwierdzone fałszywe alarmy, a następnie kontrolnie sprawdzić pozostałą ochronę; poziom, kategoria i wyjątek to odrębne decyzje.

RequestSizeLimit pozostaje konfliktem między źródłami: Tabela API wskazuje, że pole jest wymagane, podaje wartość domyślną 10, opis „Megabytes” i zakres liczb całkowitych od 1 do 1073741824. Aktualne GUI dokumentuje natomiast zakres od 1 do 1024 MB i wartość domyślną 10 MB. W przykładzie API całkowicie brakuje RequestSizeLimit. Nie należy z tego wywodzić ani przeliczenia bajtów na MB, ani rozszerzonego limitu dla środowiska produkcyjnego, ani bezpiecznej opcjonalności pola. W GUI należy stosować udokumentowany zakres w MB; wartości zapisu API należy użyć dopiero po potwierdzeniu jednostki, zakresu i zachowania pola wymaganego w zainstalowanej kompilacji. To samo dotyczy oznaczenia tabeli HSTS Enforcement, którego brakuje w przykładzie: nie należy wymyślać znacznika XML na podstawie nazwy. XContentTypeOptions opisuje ochronę MIME; zapisane przypisanie polityki i rzeczywiste nagłówki należy skontrolować z zewnątrz.

Rozróżniaj odpowiedzi XML według operacji

Poniższe liczby to statusy obiektów XML, a nie kody statusu HTTP. Message.* oznacza tutaj nierozwiązany symbol z dokumentacji referencyjnej, a nie przetłumaczony komunikat błędu ani dowód konkretnej przyczyny. Odpowiedź, operację i zapisany stan obiektu należy sprawdzać łącznie; w przypadku błędów, ostrzeżeń lub możliwej częściowej zmiany nigdy nie należy ponawiać zapisu w ciemno. Główny poradnik bezpieczeństwa API wyjaśnia bezpieczną ścieżkę weryfikacji i eskalacji.

Dla odpowiedzi FirewallRule istotnych dla WAF szczególnie ważne są następujące różnice:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Przy 202 należy również odczytać nazwę obiektu i odwołania, a nie tylko ponownie użyć starej nazwy.
Add firewall rule 541 → Message.VHIPRangeConflict. Natomiast Edit firewall rule 541 ma Message.FWRuleFailMaxUser; ten sam kod nie może prowadzić do tej samej diagnozy.
Add firewall rule 543 i Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 i Edit firewall rule 543 → Message.CannotUseDefaultPort. Mapowanie jest odwrócone między Add i Edit: należy sprawdzić listener, port i przekierowanie, a nie klasyfikować wyłącznie na podstawie liczby.
Dla Add firewall rule i Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Należy porównać istniejącą konfigurację listenera i domen; nie należy zmieniać udostępniania portów na podstawie przypuszczeń.
Dla obu operacji: 547 → Message.warn_update_business_policy; 548 i 549 używają tego samego Message.MaxIPv4ForAppServerAllowed. Podwójne przypisanie symbolu nie dowodzi istnienia różnych, samodzielnie wymyślonych limitów. Należy sprawdzić ostrzeżenie i rzeczywiście zapisany stan WAF.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Nie należy mylić publicznych domen z symbolem wieloznacznym z odpowiednim hostem backendu. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: należy sprawdzić nazwę i typ polityki, a nie nadpisywać innego obiektu.
Dla Add, Edit i Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Dla Delete podano ponadto 200 → Message.FWDelSuccess i 500 → Message.FWRuleDeleteFail. Przed ponowną próbą należy wyjaśnić odpowiedzialność za zarządzanie i odwołania. Strona Delete oznacza Name jako opcjonalne i używa niepasującego opisu dotyczącego Before/After; nie jest to bezpieczny szablon usuwania. Należy potwierdzić dokładny obiekt docelowy i kontrakt Remove właściwy dla kompilacji, w przeciwnym razie nie usuwać.

Backend i polityka ochrony również mają własne zestawy odpowiedzi: Add Web Server 200/500/502 oznaczają Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 oznaczają Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 oznaczają Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 oznaczają Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Pisownia RecodExist została zachowana dosłownie; nie są to poprawione nazwy symboli. W przypadku kolizji nazw należy najpierw odczytać istniejący obiekt; usunięcie i ponowne utworzenie nie jest bezpiecznym standardowym sposobem ponowienia próby.

Dla globalnego obiektu WAFSlowHTTP pola RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit i RequestHeaderTimeoutExtensionRate odpowiadają przełącznikowi i trzem opisanym wyżej limitom. Wszystkie cztery są udokumentowane jako wymagane; przełącznik podaje Disable i Enable, pozostałe wartości są liczbami całkowitymi bez wskazanego zakresu. NetworkExceptions/Host jest opcjonalną listą odwołań do hostów. Wartości z przykładu 10, 30, 5000 nie są potwierdzonymi wartościami domyślnymi. SlowHTTP Protection podaje 200 z Operation Successful. i 500 z Operation Fail.. Zmiany pozostają globalne: należy sprawdzić zapisane wartości i ściśle ograniczone wyjątki oraz przeprowadzić testy odbiorcze wszystkich objętych zmianą publikacji z użyciem wolnych, uprawnionych klientów.

Często zadawane pytania

Czy WAF zastępuje łatanie serwera WWW?

Nie. WAF może wykrywać lub blokować ataki, ale nie może trwale kompensować niebezpiecznej aplikacji. System operacyjny, serwer WWW, frameworki, wtyczki i kod aplikacji muszą być nadal utrzymywane.

Czy potrzebne jest dodatkowo DNAT?

Dla tej samej publikacji webowej zazwyczaj nie. Reguła WAF przejmuje publikację przez Hosted address i przekazuje żądania do chronionego serwera WWW. DNAT pozostaje istotny dla innych protokołów lub nieobsługiwanych aplikacji webowych.

Dlaczego serwer WWW nie widzi prawdziwego IP klienta?

Firewall działa jako Reverse Proxy. Serwer WWW często widzi więc firewall jako adres źródłowy. Oryginalne IP klienta znajduje się w nagłówku X-Forwarded-For, o ile aplikacja lub serwer WWW analizuje ten nagłówek.

Czy można publikować wiele stron przez to samo publiczne IP?

Tak, przy HTTPS firewall używa SNI i nazwy hosta, aby wybrać odpowiednią regułę WAF lub odpowiedni wirtualny serwer WWW. DNS, certyfikat i domeny w regule WAF muszą być do tego dobrze dopasowane.

Czy powinno się używać WAF dla Nextcloud?

Nie bez dokładnej analizy. WebDAV jest dokumentowany jako nieobsługiwany przypadek WAF. Ponieważ Nextcloud intensywnie korzysta z WebDAV, publikacja przez WAF w wielu środowiskach nie jest odpowiednia.

Czy Threat Feeds chronią również reguły WAF?

W SFOS 22 Threat Feeds mogą być istotne również dla ruchu przychodzącego, przekazywanego jak publikacje WAF i DNAT. Aby z tego wynikła rzeczywista ochrona, feedy, logowanie, alarmy, odpowiedzialność i proces obsługi fałszywych alarmów muszą być jednak prawidłowo zarządzane.