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

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, autoryzacja 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.

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.

Reguły WAF są ukierunkowane na publikacje IPv4. Jeśli aplikacja musi być koniecznie publikowana przez IPv6, projekt trzeba sprawdzić osobno. 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.

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

• 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 autoryzować 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 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.

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 rules

Procedura:

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łącz Log firewall traffic, jeśli reguła ma być widoczna w Log Viewer i raportach.
9. W Hosted server details zdefiniuj publiczny adres, port nasłuchu, HTTPS, certyfikat i domeny.
10. W Protected servers wybierz pasujący obiekt web server albo utwórz go wcześniej w Web server > Web servers.
11. Świadomie ustaw Allowed client networks. Dla publicznych stron może być potrzebne Any IPv4; dla portali lepsze jest ograniczenie.
12. W razie potrzeby ustaw Blocked client networks lub Blocked countries.
13. Sprawdź profil ochrony, IPS i opcje zaawansowane.
14. 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.

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. W zależności od Hosted address WAF może używać tego samego portu co SSL VPN, ale nie tego samego portu co User Portal. Jeśli na publicznym IP nasłuchuje już WebAdmin, VPN Portal, User Portal albo stara publikacja DNAT, przypisanie musi być jednoznaczne. W przeciwnym razie późniejszy błąd wygląda jak problem WAF, chociaż odpowiada inna funkcja.

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

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

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.

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.

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.

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. Sophos priorytetyzuje dłuższe, a więc bardziej specyficzne ścieżki. 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.

Domyślna ścieżka / powinna pozostać świadomie ustawiona. Jeśli zostanie usunięta, niepasujące ścieżki nie będą przekazywane do standardowego serwera, lecz odrzucane z 404 Not Found. Może to być celowe, ale w przypadku błędu szybko wygląda jak problem backendu.

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.

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ą drogą.

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

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