Sophos Firewall: Device Access i Local Service ACL

W sekcji Administration > Device access określa się, z których stref są dostępne lokalne usługi Sophos Firewall. Obejmują one HTTPS dla WebAdmin i API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal oraz VPN Portal.

Połączenia z tymi usługami kończą się bezpośrednio na firewallu i tworzą jego powierzchnię zarządzania i usług. Jeśli zezwolenie jest zbyt szerokie, boty, przejęte urządzenia klienckie w sieci wewnętrznej lub zewnętrzni napastnicy mogą bezpośrednio uzyskać dostęp do stron logowania, API i SSH, aby testować dane uwierzytelniające, znane luki lub błędy konfiguracji. MFA i silne hasła pozostają ważne, ale nie ograniczają dostępności: Device Access zmniejsza powierzchnię ataku jeszcze przed logowaniem i dlatego należy do pierwszych środków hardeningu.

Źródło tożsamości pozostaje od tego oddzielone. Jeśli WebAdmin ma korzystać z centralnych danych TACACS+, artykuł TACACS+ dla administratorów Sophos Firewall opisuje połączenie z serwerem, lokalne przypisanie profilu, logowanie pilotażowe i fallback; dostępność HTTPS nadal ogranicza się tutaj.

Decydujące znaczenie ma cel połączenia:

• Tabela stref Device Access: Zasadniczo zezwala na dostęp do lokalnej usługi firewalla z określonej strefy.
• Local service ACL exception rule: Zezwala na dostęp do lokalnej usługi lub go blokuje dla konkretnych źródeł, celów i usług.
• Reguła firewalla: Steruje ruchem przez firewall, na przykład z LAN do serwera w DMZ.

Jeśli na przykład otworzy się https://172.16.16.16:4444, połączenie kończy się na firewallu. Zwykła reguła firewalla nie zastępuje więc zezwolenia w Device Access.

⚠️ WebAdmin, SSH i portale powinny być dostępne tylko z sieci, które rzeczywiście ich potrzebują. W przypadku administracji zewnętrznej Admin-VPN, Sophos Central Firewall Management w Sophos Fusion (logowanie przez fusion.sophos.com), sieć zarządzająca lub wąski wyjątek ACL są bezpieczniejsze niż szerokie zezwolenie z WAN.

Dwa przypadki szczególne mogą ominąć tabelę stref dla usług HTTP i HTTPS:

• Web Proxy: Żądania przesyłane przez Web Proxy są traktowane jako wewnętrzne i nie można nimi sterować według strefy źródłowej za pomocą Device Access. Osoba uprawniona do korzystania z proxy może przez to uzyskać dostęp do WebAdmin, Captive Portal, VPN Portal i User Portal, mimo że dana usługa jest wyłączona dla jej strefy.
• Port Sharing: Jeśli VPN Portal i SSL VPN używają tego samego portu i tego samego protokołu, VPN Portal staje się dostępny ze wszystkich stref dostępu SSL VPN. Ponadto ustawienia w sekcji Login security przestają wtedy działać.

Obie ścieżki należy przetestować oddzielnie podczas odbioru konfiguracji. Nadrzędny artykuł Hardening Sophos Firewall umieszcza Device Access w kontekście kompleksowego hardeningu systemu.

Planowanie stref i usług lokalnych

Tabela stref nadaje się do przejrzystych zezwoleń podstawowych, takich jak DNS z LAN, Ping ze strefy monitoringu lub HTTPS z sieci zarządzającej. Jeśli dostępu potrzebuje tylko pojedynczy adres IP lub mała sieć, precyzyjniejsza jest ACL Exception Rule.

Strefa grupuje interfejsy. W przypadku strefy niestandardowej na dostęp do usług lokalnych można również zezwolić lub można go zablokować w sekcji Network > Zones. Przed zmianą trzeba zatem ustalić rzeczywisty interfejs wejściowy i jego strefę. Należy też przygotować wąski obiekt źródłowy, wymagany Interface Host jako cel oraz port rzeczywiście używany przez usługę. Istniejące IP Host znajdują się w sekcji Hosts and services > IP host; Interface Host są zarządzane przez Network > Interfaces.

Traktowanie macierzy domyślnej jako punktu wyjścia

Nowa konfiguracja SFOS 22 domyślnie zezwala na usługi lokalne z następujących stref. Ta macierz nie jest docelowym stanem hardeningu: restore, migracja, kreator i późniejsze zmiany mogą dać inny stan, a niepotrzebne usługi usuwa się po teście pozytywnym i negatywnym.

Typowe decyzje:

• HTTPS: WebAdmin i API tylko z sieci zarządzających lub ściśle określonych źródeł administratorów.
• SSH: Tylko do administracji lub wsparcia technicznego, w miarę możliwości z uwierzytelnianiem kluczem publicznym. W SFOS 22/23 udokumentowana ścieżka logowania przez sieciowe SSH wykorzystuje wbudowane konto admin; uprawnienie do CLI przyznane w profilu nie potwierdza możliwości logowania przez SSH na imienne konto administratora. Ustawieniami kluczy publicznych i samymi kluczami zarządza wyłącznie domyślny administrator.
• DNS: Tylko dla wewnętrznych stref klientów, które używają firewalla jako DNS Resolver. DNS z WAN nie jest zwykłym przypadkiem klienckim.
• Ping/Ping6: Do wymaganego monitoringu, nie ogólnie z niezaufanych stref.
• SNMP: Tylko z systemu lub sieci monitoringu; konfigurację opisuje artykuł Monitoring sprzętu przez SNMP.
• RADIUS SSO: Tylko od stałego nadawcy accountingu. RADIUS SSO z accountingiem wyjaśnia mapowanie adresu IP klienta i użytkownika.
• SSL VPN: Z zewnątrz otwarty tylko w niezbędnym zakresie, z MFA, Loggingiem oraz świadomie dobranym portem i protokołem.
• VPN Portal: Od SFOS 20 udostępnia Sophos Connect oraz konfiguracje IPsec i SSL VPN.
• User Portal: Służy między innymi do obsługi danych osobowych, tokenów OTP, kwarantanny, wyjątków i Policy Overrides, a nie do pobierania konfiguracji VPN.
• RED, SMTP Relay i Dynamic Routing: Tylko w przeznaczonych do tego sieciach lub dla określonych systemów zdalnych. Sposób sprawdzenia tego ograniczenia dla sąsiadów Multicast opisano w artykule Konfiguracja PIM-SM na Sophos Firewall; dla małych domen routingu IPv4 konfiguracja RIPv2 na Sophos Firewall wyjaśnia oddzielne zezwolenie dla strefy peera i ruchu danych.

W oknie usług dostępne są ponadto AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy i Wireless Protection. Możliwość wybrania usługi nie oznacza zalecenia szerokiego dostępu ze strefy; każdy wybór wymaga konkretnej ścieżki klienta, peera lub administracji. Pola wyszukiwania Source Network / Host, Destination host i Services przeszukują również atrybuty. Wpisanie 53 pozwala na przykład znaleźć usługę DNS.

WebAdmin, VPN Portal i User Portal obsługują TLS 1.3 od SFOS 22. Dobre szyfrowanie nie zmniejsza jednak powierzchni ataku niepotrzebnie dostępnej usługi.

Device Access określa tylko, z której sieci dostępna jest konsola WebAdmin. Jeśli logowanie ma odbywać się przez Microsoft Entra ID, artykuł Entra ID SSO dla WebAdmin Sophos Firewall wyjaśnia oddzielne mapowanie ról i grup Entra na lokalne profile administratorów.

Dodatkowo restrict-admin-console-wan-access może globalnie zablokować dostęp WebAdmin ze wszystkich źródeł WAN. Bezpieczne sprawdzanie Advanced Firewall Settings wyjaśnia celowo odwróconą logikę enable/disable i jej odrębność od Local Service ACL.

Ścisłe ograniczanie źródeł

ACL Exception Rule obsługuje jako źródło Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list oraz Network. Wildcard-FQDN nie są obsługiwane.

Dla WebAdmin z WAN nie wolno stosować zezwolenia dla wszystkich źródeł. SFOS nie pozwala utworzyć wyjątku ACL, gdy Source Network / Host ma wartość Any albo źródłowy adres IP to 0.0.0.0. To ograniczenie produktu nie sprawia automatycznie, że inne duże sieci są bezpieczne. Stały adres IP administratora, mała sieć zarządzająca lub utrzymywany obiekt FQDN są znacznie bezpieczniejsze. W przypadku użytkowników mobilnych, których adresy źródłowe się zmieniają, dostęp administracyjny powinien odbywać się przez VPN lub Sophos Fusion.

Szerokie zezwolenia WAN dla WebAdmin i User Portal są od SFOS 19.5 MR2 automatycznie wyłączane po 90 kolejnych dniach bez udanego logowania. Nie dotyczy to konkretnych źródeł WAN w ACL Exception Rules, które nadal wymagają regularnego przeglądu. Sophos Firewall Health Check pomaga w cyklicznym sprawdzaniu dostępu administracyjnego, MFA i konfiguracji.

Wcześniejsze sprawdzenie Web Proxy i Port Sharing

Przed hardeningiem należy zanotować używane porty i protokoły w sekcji Administration > Admin and user settings oraz w SSL VPN global settings.

• WebAdmin domyślnie używa TCP 4444, User Portal TCP 4443, a VPN Portal TCP 443.
• W SFOS 22/23 TCP 443 jest udokumentowanym ustawieniem domyślnym WAF; przed sprawdzeniem konfliktów należy zanotować faktycznie skonfigurowane listenery WAF.
• SSL VPN domyślnie używa TCP 8443; jako protokół można również wybrać UDP.
• WebAdmin i User Portal nie mogą współdzielić swoich portów z innymi usługami.
• VPN Portal i SSL VPN nie powinny używać tego samego portu i protokołu, ponieważ blokady stref oraz Login Security nie działają wtedy zgodnie z oczekiwaniami.

Jeśli Web Proxy jest aktywny, test bez proxy nie wystarcza. To samo wywołanie portalu lub WebAdmin należy dodatkowo sprawdzić przez jawne proxy ze strefy, która powinna być zablokowana.

Artykuł Konfiguracja Direct Web Proxy z plikiem PAC wyjaśnia, jak ograniczyć listener proxy do klienta pilotażowego i w kontrolowany sposób zweryfikować tę ekspozycję.

Tworzenie wąskiej Local Service ACL Exception Rule

Przed bezpośrednim dostępem do WebAdmin z WAN: W Device Console najpierw użyć polecenia tylko do odczytu show advanced-firewall, aby zapisać rzeczywistą wartość restrict-admin-console-wan-access i zainstalowany build. Dla SFOS 22/23 Sophos opisuje enable jako blokadę WebAdmin ze wszystkich źródeł WAN oraz jako wartość domyślną; ta wartość nie zastępuje zapisanej poprzedniej wartości. Instrukcje ACL opisują wąskie wyjątki WAN, ale nie wyjaśniają ich pierwszeństwa względem tej globalnej blokady. Nie należy więc zakładać, że poniższy wyjątek ACL sam zapewni dostępność WebAdmin z WAN. Przy enable zachować ograniczenie i użyć już przetestowanej, autoryzowanej ścieżki dostępu przez Admin-VPN, sieć zarządzającą lub Fusion. Jeśli bezpośredni dostęp WAN jest nieunikniony, a współdziałanie tych ustawień dla zainstalowanego buildu nie zostało jednoznacznie wyjaśnione, wstrzymać zmianę bezpośredniego dostępu WAN i wyjaśnić ją z Sophos Support. Także przy nieudanym teście pozytywnym najpierw sprawdzić ten warunek, zamiast rozszerzać ACL.

Ten przykład ACL nie jest instrukcją ustawienia globalnego przełącznika na disable. Zmiana globalnego ograniczenia wymaga osobno zatwierdzonej zmiany, działającej niezależnej ścieżki administracyjnej, udokumentowanej rzeczywistej poprzedniej wartości, własnych testów z dozwolonych i zablokowanych źródeł WAN oraz dokładnego przywrócenia tej poprzedniej wartości przy przerwaniu zmiany i po zakończeniu dostępu tymczasowego. Nie wprowadzać zmiany, jeśli nie można wiarygodnie ustalić wartości początkowej lub ścieżki odzyskania dostępu. Poniższy przykład wąskiego wyjątku WAN stosować dopiero po wyjaśnieniu tych warunków.

Typowy wyjątek zezwala na WebAdmin z WAN wyłącznie dla stałego adresu IP wsparcia. Ścieżka menu to Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: Dla konkretnego wyjątku WAN wybrać Top i sprawdzić pozostałe reguły pod kątem nakładania się.
3. Description: Udokumentować cel, zgłoszenie i planowaną datę wygaśnięcia.
4. IP version: Wybrać odpowiednio do źródła, najczęściej IPv4.
5. Source zone: WAN
6. Source Network / Host: Wybrać konkretny adres IP administratora lub wąski, utrzymywany obiekt.
7. Destination host: Ograniczyć do wymaganego adresu firewalla lub interfejsu. Any rozszerza dostępne adresy docelowe lub interfejsy, a nie usługi wybrane w sekcji Services.
8. Services: Wybrać tylko HTTPS, bez dodawania SSH dla wygody.
9. Action: Accept

Wartości przykładowych nie należy kopiować bez dostosowania. Dla wewnętrznej sieci zarządzającej ten sam wzorzec może używać Source zone: LAN lub niestandardowej strefy zarządzającej, Source Network / Host: mgmt-net, Interface Host adresu zarządzającego jako Destination host, HTTPS oraz Accept. Aby wykluczyć znane źródło w strefie, która poza tym wymaga dostępu, należy użyć oddzielnej, właściwie umieszczonej reguły z wąskim obiektem źródłowym, wyłącznie usługami, których dotyczy ograniczenie, oraz akcją Drop. Grupa krajów jest co najwyżej przybliżoną granicą sieciową, a nie zamiennikiem stałego źródła administratora lub VPN.

Następnie zapisuje się regułę i testuje dostęp z dozwolonego oraz niedozwolonego źródła. Pozycja reguły jest ważna: reguły znajdujące się wyżej mogą wpłynąć na wynik. W przypadku nakładających się reguł należy więc sprawdzić rzeczywiste działanie na firewallu, a nie wnioskować wyłącznie na podstawie listy.

Dostęp API

W przypadku API muszą być spełnione trzy warunki:

1. API jest aktywne w sekcji Administration > API access.
2. Adres źródłowy znajduje się w Allowed IP hosts.
3. Device Access zezwala na HTTPS z odpowiedniej strefy lub przez właściwy wyjątek ACL.

Od SFOS 22 konfiguracja API znajduje się w sekcji Administration i obsługuje obiekty IP Host dla adresów, zakresów oraz sieci. Możliwe są maksymalnie 64 obiekty. Szerokie zezwolenie HTTPS nie jest do tego potrzebne. Pełną konfigurację opisuje artykuł Bezpieczne ograniczanie dostępu do API Sophos Firewall.

Automatyzacja XML: ustawienie strefy, nie wyjątek ACL

Dokumentacja XML stref dla SFOS 22/23 umieszcza HTTPS i SSH odpowiednio pod Zone/ApplianceAccess/AdminServices/HTTPS i Zone/ApplianceAccess/AdminServices/SSH. Jest to dostęp do usług lokalnych na poziomie strefy: nie reguła firewalla dla ruchu tranzytowego ani Local service ACL exception rule ograniczona do konkretnego źródła. Zmiana tej gałęzi wpływa na dostępność zarządzania ze strefy; nie ogranicza dostępu do pojedynczego adresu IP administratora. Aby precyzyjnie zezwolić na dostęp ze źródła, nadal należy zastosować opisany wyżej wyjątek ACL.

Dokumentacja jest sprzeczna w kwestii wartości: przykład XML pokazuje Enable/Disable, natomiast wspólna tabela parametrów powtarza Enable i zawiera również 12 oraz 40. Nie pozwala to ustalić wiarygodnego kodowania logicznego ani numerycznego. Przed każdym automatycznym zapisem trzeba wyjaśnić składnię dla zainstalowanego firmware; ten opis hierarchii nie jest gotowym do wykonania szablonem nadawania dostępu.

Również Zone/MemberPorts nie jest instrukcją zapisu: komentarz w przykładzie XML wyraźnie oznacza porty należące do strefy jako przeznaczone tylko do odczytu. Opcjonalny wiersz CSV w tabeli opisuje ich wyświetlanie, a nie zweryfikowaną metodę zmiany. Przed każdą automatyczną zmianą strefy należy przetestować niezależną ścieżkę odzyskania dostępu z zalogowaną sesją, a po zmianie sprawdzić dozwolone i zablokowane źródła zgodnie z opisem wdrożenia poniżej.

Bezpieczne usuwanie strefy niestandardowej

Usunięcie Local service ACL exception rule usuwa tylko ten wyjątek, nie strefę o danej nazwie. Wyłączenie lokalnej usługi również nie jest usunięciem strefy. Strefy i interfejsy wyjaśnia powiązania.

1. W Network > Zones ustalić dokładną nazwę strefy niestandardowej, która nie jest już potrzebna w produkcji, i udokumentować jej poprzedni stan. Retired_Test to tylko przykład, nie cel usuwania do skopiowania. Najpierw zalogować się i przetestować niezależną ścieżkę administracyjną opisaną we wdrożeniu poniżej; nie może ona zależeć od tej strefy ani od zmienianych interfejsów lub reguł.
2. W Network > Interfaces sprawdzić wszystkie przypisania do tej strefy, a w Rules and policies > Firewall rules wszystkie odwołania jako Source zone lub Destination zone. Nie usuwać potrzebnych interfejsów ani reguł: przypisać je do przewidzianej pozostającej strefy wyłącznie w ramach zatwierdzonej zmiany i sprawdzić skutek. Jeśli odwołania muszą pozostać lub ich użycie jest niejasne, zachować strefę i jej zależności oraz wstrzymać usuwanie. Nie usuwać kaskadowo zależności produkcyjnych, aby wymusić operację.
3. Dopiero po wyjaśnieniu zależności usunąć wyłącznie tę strefę wskazaną nazwą. Dokumentacja XML SFOS 22/23 wymaga Name o maksymalnie 60 znakach: najpierw A-Za-z1-9 (nie 0), następnie A-Za-z0-9_. Nie potwierdza to ani obsługi symboli wieloznacznych, ani automatycznego usuwania kaskadowego; nie podaje się tutaj żądania XML ani niepotwierdzonego okna usuwania.
4. Następnie sprawdzić, że brakuje tylko zamierzonej strefy, pozostałe przypisania interfejsów i reguły firewalla są poprawne, a wymagany ruch tranzytowy nadal działa. Ponownie przetestować lokalne usługi z dozwolonych i zablokowanych źródeł oraz niezależną ścieżkę administracyjną. Przy rozbieżnościach przerwać i użyć tej ścieżki do selektywnego wycofania udokumentowanych zmian, nie rozszerzać zezwoleń.

Udokumentowane statusy XML to 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) i 504 (ZoneFirewallRuleExists). Przy 503 lub 504 ponownie sprawdzić odpowiednie odwołania do interfejsów lub reguł zamiast bezwarunkowo usuwać zależne obiekty. 500 nie oznacza sukcesu; nawet 200 nie zastępuje kontroli końcowej.

DNS z WAN

Sam wyjątek DNS ACL z WAN nie powoduje, że firewall odpowiada tam na zapytania DNS. W tym celu trzeba dodatkowo utworzyć statyczny DNS Host z opcją Publish on WAN w sekcji Network > DNS. Należy to robić wyłącznie dla konkretnego zastosowania autorytatywnego DNS; firewall nie może przez to stać się publicznie dostępnym rekurencyjnym resolverem. Konfiguracja i testowanie DNS Host Entries na Sophos Firewall opisuje delegację, DNS Host Entry oraz testy pozytywne i negatywne.

Szczegóły eksploatacyjne przed zmianą

Po aktualizacji lub odtworzeniu kopii z wersji wcześniejszej niż SFOS 20 VPN Portal przejmuje dotychczasowy port User Portal, również port niestandardowy. User Portal przechodzi na 4443 lub na 65040, jeśli ten port jest zajęty. Przed szukaniem pozornie brakującego zezwolenia ACL należy sprawdzić skonfigurowany port, a nie tylko domyślny. Użytkownicy lub grupy VPN Portal muszą też należeć do odpowiedniej polityki Remote Access; sama dostępność nie nadaje uprawnień użytkownikowi.

Listener WAF musi różnić się od VPN Portal adresem IP WAN lub portem. W porównaniu z SSL VPN wystarczy także inny protokół: WAF i VPN Portal używają TCP, a SSL VPN może używać TCP lub UDP. Rozdzielenie listenerów nie jest zezwoleniem ACL; po każdej zmianie portu należy ponownie przetestować usługi, których dotyczy zmiana.

Dynamic Routing zezwala na aktualizacje routingu do firewalla, nie na ruch danych przez niego. Włącza się go dla rzeczywistej strefy peera, nie automatycznie dla WAN. W przykładzie WAN z dwoma firewallami RIP tylko strona z włączonym dostępem odbiera aktualizacje; druga je odrzuca i nie uczy się ogłaszanych sieci. Przy braku tras po jednej stronie należy sprawdzić strefę peera po obu stronach, a następnie konfigurację protokołu w powiązanym artykule o routingu.

Widget Messages w Control center może ostrzegać o dostępie WAN do HTTPS i SSH. Należy sprawdzić zezwolenia stref i wyjątki ACL oraz ograniczyć dostęp do VPN lub konkretnych hostów i sieci. Komunikatów nie można usuwać ręcznie; niektóre znikają po spełnieniu wymagania. Zniknięcie komunikatu nie zastępuje testów pozytywnych i negatywnych. Komunikaty o kluczu głównym, rejestracji, licencjach, raportach i firmware należą do odpowiednich procedur eksploatacyjnych, nie do dodatkowej reguły ACL.

Wdrażanie zmian bez blokady dostępu

Zmiany Device Access działają natychmiast.

Ścieżka awaryjna musi działać również po planowanej zmianie strefy lub portu. Druga karta przeglądarki korzystająca z tego samego zablokowanego dostępu nie jest niezależna. Przed rozpoczęciem należy zapisać dokładne poprzednie ustawienia i ustalić, kto ma dostęp do konsoli; bez działającej ścieżki odzyskania dostępu nie wolno wykonywać zmiany zdalnie. Podczas pracy zdalnej przed zmianą należy zalogować się za pomocą drugiego sposobu dostępu administracyjnego i sprawdzić, czy działa.

1. Udokumentować aktualne zezwolenia stref, wyjątki ACL, porty i wymagane usługi.
2. Otworzyć niezależny dostęp, na przykład lokalną konsolę, Management-LAN, Admin-VPN lub Sophos Fusion.
3. Przy większych zmianach zapewnić dostęp do aktualnego Backupu i Secure Storage Master Key.
4. Utworzyć nowy, wąski wyjątek Accept, nie usuwając jeszcze istniejącego szerokiego zezwolenia.
5. Sprawdzić dozwolony dostęp jako wartość bazową. Dopóki szerokie zezwolenie strefy jest aktywne, test ten nie dowodzi jeszcze, że działa nowy wyjątek.
6. W sekcji Diagnostics > Packet capture ustawić wąski filtr na źródło, cel i port oraz aktywować Trace On.
7. Za pośrednictwem niezależnego dostępu administracyjnego usunąć stare szerokie zezwolenie strefy.
8. Natychmiast przeprowadzić funkcjonalny test usługi z dozwolonego źródła. Udane połączenie TCP/TLS lub dostęp do usługi oraz zazwyczaj Status: Consumed potwierdzają przypadek pozytywny; Reason: LOCAL_ACL nie musi się przy tym pojawić.
9. Przetestować tę samą usługę z niedozwolonego źródła. Dla zablokowanej próby zazwyczaj oczekuje się Status: Violation oraz Reason: LOCAL_ACL.
10. W przypadku HTTP/HTTPS dodatkowo sprawdzić ścieżkę Web Proxy, a w przypadku portali strefy dostępu SSL VPN.
11. Zatrzymać Packet Capture i sprawdzić uzupełniające zdarzenia usługi lub logowania w Log viewer. Rule-ID wyświetlany w Packet Capture jest identyfikatorem reguły firewalla, a nie identyfikatorem ACL Exception Rule, i dla ruchu lokalnego może mieć wartość 0.
12. Udokumentować regułę, cel, osobę odpowiedzialną, zgłoszenie, źródło, usługę oraz termin przeglądu lub wygaśnięcia.

Przerwanie i wycofanie: Jeśli dozwolony dostęp przestanie działać, należy przez niezależną ścieżkę przywrócić ostatnio zmienione ustawienie do zapisanej poprzedniej wartości i ponownie sprawdzić dostęp. Jeśli zablokowane źródło nadal dociera do usługi, nie należy rozszerzać zezwolenia: trzeba sprawdzić proxy, Port Sharing i nakładające się reguły ACL oraz ograniczyć niepożądaną ścieżkę bez utraty dostępu awaryjnego. Oba testy powtarza się dopiero po korekcie.

Zwięzłe przykłady dokumentacji ułatwiają późniejszy przegląd:

• HTTPS: Reguła admin-https-from-mgmt, źródło mgmt-net, cel WebAdmin, przegląd kwartalny.
• SSH: Źródło support-ip-temporary, cel zgłoszenie wsparcia, usunąć po zamknięciu zgłoszenia.
• SNMP: Źródło monitoring-server, cel monitoring sprzętu i interfejsów, przegląd co pół roku.
• SSL VPN: Źródło WAN, cel Remote Access, comiesięczny przegląd logów.

W przypadku wielu firewalli lub klastra HA należy najpierw zmienić system, na którym można łatwo wycofać zmianę. Zmiany ról i dostęp serwisowy opisuje instrukcja Konfiguracja High Availability w Sophos Firewall.

Przypadki szczególne i dodatkowa ochrona

User Portal, VPN Portal i SSL VPN

Najpierw należy ustalić, który portal jest rzeczywiście potrzebny. Klienty i konfiguracje VPN należą do VPN Portal; User Portal realizuje inne funkcje użytkownika. Zestawienie zawiera artykuł Porównanie portali Sophos Firewall.

Jeśli usługa Remote Access musi być dostępna na całym świecie, MFA, restrykcyjne grupy użytkowników i Logging są ważniejsze niż nieodpowiednie ograniczenie według krajów. Konfigurację opisuje artykuł Włączanie MFA dla WebAdmin, VPN Portal i Remote Access w Sophos Firewall. Nadal należy unikać Port Sharing: uwierzytelnianie nie zastępuje prawidłowego sterowania dostępnością.

Publicznie dostępne logowania WebAdmin, User Portal, VPN Portal i SSL VPN są szybko wykrywane przez skanery i boty. Nawet przy MFA powoduje to ruch Brute Force, szum w logach i dodatkowe obciążenie.

Jeśli występuje już wiele nieudanych logowań do VPN Portal lub blokad kont, artykuł Ochrona Sophos Firewall VPN Portal przed atakami brute force łączy sprawdzanie logów, kontrolę tożsamości, ograniczenie przez ACL i kontrolę końcową w jeden proces obsługi incydentu.

Jeśli portal musi pozostać dostępny na całym świecie, Threat Feeds w Sophos Firewall z akcją Block mogą dodatkowo blokować znane złośliwe źródła IPv4 pochodzące z Third-Party Feeds, takich jak Cybora, również w ruchu do samego firewalla. IoC domeny lub URL nie chroni logowania przed złośliwym źródłowym adresem IP; źródła IPv6 nie są obecnie obsługiwane. Threat Feeds stanowią więc ochronę dodatkową, a nie zamiennik wąskich list ACL. Powiązany artykuł opisuje konfigurację, testy i Allowlisting.

SSH i tymczasowe reguły wsparcia

SSH powinno być dostępne tylko w razie potrzeby, z sieci zarządzającej, przez VPN lub dla stałego adresu IP wsparcia. Preferowane jest uwierzytelnianie Public Key. Po zakończeniu zgłoszenia tymczasowy wyjątek ACL należy usunąć; nie powinno się zakładać istnienia statusu dezaktywacji, którego nie potwierdzono w aktualnym interfejsie. Dalsze kroki opisuje artykuł Łączenie z Sophos Firewall przez SSH.

Uprawnienie do CLI nie oznacza możliwości logowania przez SSH: Zgodnie z opisem profilu dla SFOS 22/23 profil Administrator zapewnia pełny dostęp do CLI, nie określając jednak sposobu transportu. Natomiast instrukcja PuTTY dla tych samych wersji wymaga przy sieciowym dostępie SSH nazwy użytkownika admin i wyklucza inne nazwy użytkowników; dotyczy to również logowania hasłem. Nie wywodzi się z tego tutaj ani możliwości korzystania z SSH przez imienne konta administratorów, ani ogólnego stwierdzenia dotyczącego każdej formy dostępu do CLI. Funkcja Console w WebAdmin otwiera konsolę w przeglądarce za pośrednictwem dostępu do WebAdmin i nie stanowi dowodu możliwości logowania przez sieciowe SSH. To, czy konkretne imienne konto może korzystać z tego dostępu w przeglądarce, należy sprawdzić oddzielnie na podstawie jego uprawnień i zainstalowanej wersji firmware. Zarządzanie kluczami, dozwolone wyłącznie domyślnemu administratorowi, również jest odrębnym uprawnieniem i nie rozstrzyga, które konta mogą logować się przez SSH za pomocą hasła.

Przed zmianą ACL sprawdzić rzeczywistą ścieżkę awaryjną: W przypadku udokumentowanej ścieżki sieciowego dostępu SSH należy użyć wbudowanego konta admin z jego aktualnymi danymi uwierzytelniającymi lub skonfigurowanym dla niego kluczem. Należy zalogować się wybraną ścieżką dostępu w nowej sesji, otworzyć wymaganą konsolę oraz odnotować konto, sposób transportu i wersję firmware w dokumentacji zmiany; sama dostępność portu TCP nie wystarcza. Działający dostęp do Console w przeglądarce nadal zależy od ścieżki WebAdmin i po jej zablokowaniu nie jest niezależną ścieżką awaryjną. Jeśli imienne konto jest wymagane jako awaryjna ścieżka dostępu przez SSH lub zaobserwowane zachowanie jest sprzeczne z instrukcją, należy wstrzymać zmianę, zachować już przetestowany, autoryzowany dostęp i wyjaśnić z Sophos Support dokładny zakres obsługiwanych kont i sposobów transportu. Nie należy ani rozszerzać ACL, ani zastępować tego wyjaśnienia ponawianymi próbami logowania.

Wygasły wyjątek usuwa się w Administration > Device access > Local service ACL exception rule przyciskiem Delete przy odpowiedniej regule, a następnie potwierdza przez OK. Najpierw należy przetestować dostęp administracyjny, który ma pozostać; potem sprawdzić, że poprzednie źródło wsparcia nie może już się połączyć. Zapisana data wygaśnięcia jest tu obowiązkiem przeglądu, a nie dowodem automatycznego usuwania.

Rozwiązywanie problemów

Gdy logowanie nagle staje się niedostępne, należy też sprawdzić Administration > Admin and user settings > Login security > Block login. Ta blokada według źródłowego IP zależy od nieudanych logowań i może dotyczyć WebAdmin, CLI, VPN Portal oraz User Portal. Nie jest regułą ACL. Nieudane próby CAPTCHA nie są liczone jako te próby logowania. Należy sprawdzić skonfigurowany czas blokady i zdarzenia zamiast zezwalać na HTTPS dla całej strefy lub bezwarunkowo wyłączać ochronę.

Jeśli lokalna usługa nie jest dostępna lub blokowana zgodnie z oczekiwaniami, należy sprawdzić kolejno:

1. Cel i port: Czy adres IP firewalla jest prawidłowy i czy usługa używa oczekiwanego portu?
2. Strefa źródłowa: Czy klient łączy się bezpośrednio z oczekiwanej strefy, przez VPN czy przez Web Proxy?
3. Tabela stref: Czy usługa jest dozwolona dla tej strefy w sekcji Administration > Device access?
4. Wyjątki ACL: Czy zgadzają się IP version, Source zone, obiekt źródłowy, Destination host, Service, Action i Position?
5. Port Sharing: Czy VPN Portal i SSL VPN współdzielą port oraz protokół?
6. API: Czy API jest aktywne, Allowed IP hosts są poprawne, a HTTPS Device Access pasuje do konfiguracji?
7. DNS: Czy DNS jest dozwolony dla klientów wewnętrznych? Przy publikacji w WAN dodatkowo wymagane jest Publish on WAN.
8. Logi: Czy Log Viewer pokazuje uzupełniające zdarzenia usługi lub logowania?
9. Packet Capture: Uruchomić Trace przed ponownym testem. Dozwolony dostęp musi działać funkcjonalnie i zazwyczaj pokazuje Status: Consumed; zablokowana próba zazwyczaj pokazuje Status: Violation oraz Reason: LOCAL_ACL. Rule-ID nie jest identyfikatorem wyjątku ACL. Obsługę opisuje artykuł Packet Capture w Sophos Firewall.

Jeśli WebAdmin lub portal pozostaje dostępny mimo wyłączonej strefy źródłowej, w pierwszej kolejności należy przetestować Web Proxy i Port Sharing. Dodatkowa reguła firewalla nie rozwiąże tego problemu.

Do długoterminowego śledzenia zdarzeń nadają się Central Firewall Reporting lub Wysyłanie Syslog z Sophos Firewall do SIEM.

Lista kontrolna eksploatacji

• WebAdmin nie jest szeroko dostępny z WAN ani ze stref gościnnych, IoT lub VoIP.
• HTTPS, SSH i SNMP są ograniczone do konkretnych źródeł zarządzania lub monitoringu.
• User Portal, VPN Portal i SSL VPN są aktywne tylko wtedy, gdy wymaga tego koncepcja eksploatacji.
• VPN Portal i SSL VPN nie współdzielą tego samego portu i protokołu.
• Dostęp przez Web Proxy do lokalnych usług HTTP/HTTPS został przetestowany oddzielnie.
• API access, Allowed IP hosts i HTTPS Device Access są ze sobą zgodne.
• Tymczasowe wyjątki ACL zawierają cel i datę wygaśnięcia oraz są usuwane po zakończeniu prac.
• Przetestowano dozwolone i zablokowane źródła, a logi potwierdzają wynik.
• Reguły są regularnie sprawdzane pod kątem nieaktualnych źródeł, zbędnych usług i szerokich wyjątków Accept.

Zastrzeżenia dotyczące źródeł

STAS zapewnia uwierzytelnianie użytkowników; nie jest VPN ani szyfrowanym kanałem administracyjnym. Zezwolenie dla tej usługi uwierzytelniania nie zastępuje chronionej ścieżki zarządzania.

Zachowane instrukcje dotyczące kluczy SSH w SFOS 22/23 są niejednoznaczne: wskazują RSA/DSA o długości co najmniej 2048 bitów i wymieniają ECDSA z wyłączeniem ED25519. Nie należy z tego wywodzić obsługi ED25519 ani traktować DSA jako zalecenia. Przed rejestracją należy potwierdzić algorytm obsługiwany przez rzeczywistą wersję firmware; przesłać tylko klucz publiczny i zachować oddzielną ścieżkę odzyskiwania dostępu. Zezwolenie Device Access nie potwierdza obsługi algorytmu klucza.

Adaptive Learning obejmuje także adresy URL wykrytych wirusów, nazwy/URL/adresy IP zagrożeń, źródłowe adresy IP i używane aplikacje. Domyślne raportowanie przez HTTPS obejmuje dane urządzenia, firmware i licencji (bez informacji o właścicielu), stan funkcji/HA/zarządzania w chmurze, liczby obiektów, błędy oraz procentowe użycie CPU/pamięci/dysku. To decyzja o udostępnianiu danych, a nie kontrola ACL. Sophos Assistant jest domyślnie włączony; aby go wyłączyć, należy odznaczyć Turn on Sophos Assistant w Administration > Admin and user settings, kliknąć Apply, a następnie wylogować się i zalogować ponownie. Nie wyłącza to telemetrii.

FAQ