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.

Reguła WAF nie zastępuje automatycznie bezpiecznego rozwoju aplikacji, łatania, silnej autoryzacji 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.

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.

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ą:

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.

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.

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 przeprowadzać autoryzację, profile ochrony, reguły krajowe i logowanie.

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

Dla certyfikatów warto wcześniej ustalić, czy zostanie zaimportowany istniejący certyfikat, 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.

Podstawowa struktura reguły WAF

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

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

Tworzenie reguły WAF

Ścieżka menu to:

Rules and policies > Firewall rules

Procedura:

1. Wybierz IPv4.
2. Otwórz Add firewall rule.
3. Wybierz New firewall rule.
4. Nadaj znaczącą nazwę regule.
5. W Action wybierz opcję Protect with web server protection.
6. Jeśli nie jest potrzebny specjalny szablon, pozostaw Preconfigured template na None.
7. W Hosted server details zdefiniuj publiczny adres, port nasłuchu, HTTPS, certyfikat i domeny.
8. W Protected servers wybierz lub utwórz nowy wewnętrzny serwer WWW.
9. Świadomie ustaw Allowed client networks. Dla publicznych stron może być potrzebne Any IPv4, dla portali lepsze jest ograniczenie.
10. W razie potrzeby ustaw Blocked client networks lub Blocked countries.
11. Sprawdź profil ochrony, IPS i opcje zaawansowane.
12. Zapisz regułę i przetestuj zewnętrznie.

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.

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.

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 autoryzuje.
• 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 znanej nieszkodliwej testowej prośby 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ę.

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.
• Przy wielu nazwach hostów na tym samym IP firewall używa SNI.
• Certyfikaty wildcard są możliwe, ale powinny być dobrze udokumentowane.
• 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.

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, czystej autoryzacji 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

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.

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.

Należy pamiętać, że firewall nie ocenia ścieżek po prostu według kolejności w tabeli. Specyficzne ścieżki muszą być starannie zaplanowane i przetestowane. Jeśli potrzebny jest WebSocket, można aktywować WebSocket passthrough. Ruch WebSocket jest wtedy przekazywany bez tej samej kontroli WAF, ponieważ protokół nie może być sprawdzany w ten sam sposób co normalny ruch HTTP.

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łnego koncepcji Load Balancing aplikacji.

Typowe błędy

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 istnieje bardziej ogólna reguła WAF, która dopasowuje się wcześniej?
8. Czy dostęp jest wyświetlany w Log Viewer jako dozwolony, zablokowany lub odrzucony?
9. Czy są wskazówki w /log/reverseproxy.log?

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.

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