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 hardening opisuje hub Sophos Firewall Hardening: best practices dla 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 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.

Decyzja przed publikacją

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 głównie tłumaczy i zezwala wtedy 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. Aplikacje takie jak Nextcloud nie powinny być publikowane przez WAF bez odpowiedniego planowania reguł firewalla i NAT lub innej architektury publikacji.

Decyzja: WAF, DNAT czy dostęp prywatny

Najważniejsze pytanie nie brzmi, jak szybko można zbudować publikację, ale czy można ją później bezpiecznie obsługiwać, testować i wycofać. Ta klasyfikacja 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ódła i opcjonalnie MFA może mieć sens. Najpierw trzeba wyjaśnić, czy możliwe są WAF-MFA, reguły krajowe lub stałe sieci źródłowe.
• Czysta usługa 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. Publiczna dostępność powinna zostać krytycznie zakwestionowana.

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

Wymagania wstępne

Przed utworzeniem pierwszej reguły WAF należy rozważyć 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 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 przypadkowo 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ć granice 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 ślepo budować kolejnych pojedynczych reguł, tylko sprawdzić koncepcję nazw, ś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 polityki ochrony z bieżącą architekturą Microsoft; dla nowoczesnej aplikacji w razie wątpliwości należy pozostawić Preconfigured template ustawione na None.

Planowanie publikacji WAF przed konfiguracją

Reguła WAF nie powinna być planowana dopiero w interfejsie. Przedtem należy ustalić, czy Sophos Firewall ma tylko publikować, 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 obsługa 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, zbyt restrykcyjne profile mogą zepsuć aplikacje.
• 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

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 osiągają aplikację.
• 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:

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.

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

SFOS 23: Publikowanie ścieżek w Traffic routing

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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 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 może być 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.

Go-live i odbiór

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 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 przewidzenia. 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 przez DNS jest często zbyt wolny; w takich przypadkach stara reguła powinna być ponownie aktywowalna 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 logika IP klienta musi być zrozumiała.

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

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.
• Podkreślenia w lewym labelu domeny nie są czystą nazwą DNS i należy ich unikać dla domen 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. Wildcards mogą pomagać, ale nie powinny zastępować czystej 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.

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ć 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 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 adresy IP źródłowe lub sieci partnerskie.
• Blokuj niepotrzebne kraje.
• Blokuj adresy IP z nieznanych krajów tylko wtedy, gdy ryzyko własnego zablokowania 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łych IP pomocne jest 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 są również istotne dla ruchu przychodzącego, przekazywanego jak publikacje 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, 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 i utwardzania aplikacji.

Praktycznie warto sprawdzić:

• Czy Active Threat Response jest sensownie skonfigurowany w środowisku?
• Czy stosowane są odpowiednie Threat Feeds i regularnie sprawdzane?
• Czy w działaniu widoczne są zdarzenia WAF, logi Active-Threat-Response i logi backendu?
• Czy istnieje proces dla fałszywych alarmów, listy dozwolonych i awaryjnych zwolnień?
• Czy wiadomo, kto reaguje na trafienia i czy tylko loguje, czy aktywnie blokuje?

Szczególnie przy portalach klienta, interfejsach administracyjnych lub dostępach partnerskich ta kontrola powinna odbyć się przed uruchomieniem. Jeśli później feed zablokuje ruch produkcyjny, działanie musi wiedzieć, gdzie zobaczyć trafienie i jak podjąć decyzję: prawdziwy atak, fałszywy alarm czy źle opublikowana aplikacja.

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ń we wszystkich 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; cipher suites 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 obejmować poprzednie wartości, kopię zapasową konfiguracji, okno serwisowe i alternatywny dostęp administracyjny. Następnie należy przetestować wszystkie publikacje WAF i sprawdzić reverseproxy.log; jeśli usługa nie uruchomi się, należy przywrócić ostatnie wartości niestandardowe zamiast testować kolejne warianty w środowisku produkcyjnym.

W Protection Policies ważny jest tryb. Reject blokuje i generuje widoczne zdarzenia 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 false positives. Poszczególne reguły należy pomijać tylko na podstawie potwierdzonego w logu Rule ID w Skip filter rules. Wyłączenie całej kategorii lub wyższego poziomu nie zastępuje 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 poprawić Content-Type backendu, zamiast szeroko wyłączać ochronę.

W skanowaniu antywirusowym limit rozmiaru dotyczy łącznej objętości uploadu w jednym requeście, a nie każdego pliku osobno. Dodatkowy Request size limit dla body 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. Upload, download i nagłówki trzeba więc sprawdzić z prawdziwą aplikacją.

IPS w regule WAF trzeba oceniać osobno. Sophos stosuje IPS dla WAF tylko wtedy, gdy komunikacja między firewallem a serwerem WWW używa 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 być ustawiane wąsko. 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. Lepiej jest zastosować celowy 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.

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, Rule IDs przypisano ponownie, a także 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 inna część była wcześniej wyłączona.

Po takim uaktualnieniu nie wystarczy porównać samej nazwy policy. 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. Zmigrowana policy zostaje zatwierdzona dopiero wtedy, gdy prawidłowe requests nadal działają, a oczekiwane ataki testowe są wykrywane.

Routing specyficzny dla ścieżki, WebSocket i Load Balancing

WAF może przekierowywać żądania w zależności od ścieżki do różnych serwerów backendowych. Jest to przydatne, gdy aplikacja ma wiele komponentów lub jeden host ma być rozdzielony na 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 normalnego 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 Load Balancing aplikacji.

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 przez łącza lokalizacji, 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ą.

Projekt udokumentowany 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 peer, zaadresowanym interfejsem XFRM i niezawodnym hostem monitorującym za peerem. Dopiero potem w Routing > SD-WAN routes tworzy się ukierunkowaną trasę dla ruchu proxy WAF:

1. Destination networks odpowiada publicznemu interfejsowi WAN lub Hosted address, przez które klient dociera do reguły WAF.
2. Services zawiera zewnętrzny Listening Port reguły WAF. Jeżeli różni się on od wewnętrznego portu backendu, należy tu wyraźnie użyć portu zewnętrznego.
3. W Primary gateway wybiera się wcześniej utworzony gateway XFRM.
4. 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.

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 backend musi otrzymać żądanie i odpowiedzieć przewidzianą ścieżką. Sam zielony tunel nie potwierdza ani dopasowania SD-WAN, ani osiągalności backendu.

Eksploatacja i rozwiązywanie problemów

Typowe błędy

• Publiczna nazwa DNS wskazuje na niewłaściwe IP: reguła WAF nigdy nie jest osiągana.
• Certyfikat nie pasuje do nazwy hosta: przeglądarki pokazują błędy certyfikatu albo dopasowanie SNI nie pasuje.
• Wybrano niewłaściwą Hosted address: firewall dopasowuje inną regułę albo nie widzi 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ż czysto odwzorować.
• Wersja Exchange nowsza niż 2013 planowana z szablonem WAF: szablon nie pasuje do obsługiwanej granicy 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 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ć:

1. Czy publiczna nazwa DNS wskazuje na właściwe publiczne IP?
2. Czy w regule WAF wybrano właściwą Hosted address?
3. Czy port nasłuchu jest wolny i nie zajęty przez WebAdmin, User Portal, VPN Portal lub inną publikację?
4. Czy certyfikat pasuje do wywołanej nazwy hosta?
5. Czy wewnętrzny serwer WWW jest dostępny z firewalla?
6. Czy Allowed client networks, Blocked client networks i Blocked countries są poprawnie ustawione?
7. Czy Protected Server znajduje się za trasą, SD-WAN Route lub połączeniem VPN, które naprawdę pasuje z perspektywy firewalla?
8. Czy istnieje bardziej ogólna reguła WAF, która dopasowuje się wcześniej?
9. Czy dostęp jest wyświetlany w Log Viewer jako dozwolony, zablokowany lub odrzucony?
10. Czy są wskazówki w /log/reverseproxy.log?
11. Czy Protection Policy jest ustawiona na Monitor czy Reject?
12. 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 przy bezpośrednim dostępie do backendu. Sophos śledzi to zachowanie pod numerem NC-159041 i obecnie nie wskazuje ani konkretnej dotkniętej lub poprawionej wersji SFOS, ani obsługiwanego obejścia.

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

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

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.

Często zadawane pytania