Zabezpiecz dostęp do Sophos Firewall: konfiguracja Device Access

W Administration > Device access określa się, z których stref dostępne są lokalne usługi Sophos Firewall. Należą do nich na przykład HTTPS dla WebAdmin Console, SSH dla CLI, Ping, DNS, User Portal, VPN Portal oraz inne usługi.

To obszar krytyczny dla bezpieczeństwa. Zwykłe reguły firewall kontrolują ruch przez firewall. Device access kontroluje ruch do samego firewalla. Jeśli WebAdmin lub SSH są dostępne z niezaufanej strefy, powstaje bezpośredni dostęp administracyjny do urządzenia zabezpieczającego.

⚠️ WebAdmin, SSH i portale powinny być dostępne tylko z zaufanych sieci. W środowiskach produkcyjnych lepiej ograniczyć dostęp do sieci zarządzającej, stałego adresu IP administratora, VPN albo Sophos Central Firewall Management.

Sophos Firewall Device Access z Local Service ACL i ACL Exception Rules — Device Access określa, które lokalne usługi Sophos Firewall są dostępne z danych stref. ACL Exception Rules pozwalają tworzyć bardzo precyzyjne wyjątki.

Dlaczego Device Access nie jest regułą firewall

Typowa reguła firewall zezwala na połączenia między strefami albo je blokuje, na przykład LAN do WAN albo VPN do Server. Device Access działa inaczej: dotyczy usług uruchomionych bezpośrednio na Sophos Firewall.

Przykłady:

Administrator otwiera https://172.16.16.16:4444.
Klient używa firewalla jako serwera DNS.
System monitoringu pinguje firewall.
Użytkownik otwiera User Portal albo VPN Portal.
Administrator łączy się z firewallem przez SSH.

Taki ruch nie jest kierowany do serwera za firewallem, lecz do samego firewalla. Dlatego steruje nim lokalna service ACL.

Z tego powodu Device Access należy do podstawowego hardeningu każdego Sophos Firewall. Czysty zestaw reguł LAN-to-WAN nie chroni automatycznie usług zarządzania i portali samego firewalla. Te usługi trzeba sprawdzić osobno i świadomie ograniczyć.

Zrozumieć dostęp ze stref

W górnej części Administration > Device access znajduje się tabela ze strefami i usługami. Jeśli usługa jest włączona dla strefy, dostęp do tej lokalnej usługi jest zasadniczo dozwolony z tej strefy.

Tabela stref jest praktyczna, ale ogólna. Sprawdza się dla jasnych stref wewnętrznych, takich jak LAN, Management czy VPN. Gdy usługa ma być dostępna tylko z pojedynczych adresów IP administratorów, lokalizacji, krajów albo źródeł supportu, lepszym wyborem są Local service ACL exception rules.

Typowe przykłady:

Usługa	Kiedy ma sens	Na co uważać
`HTTPS`	Dostęp WebAdmin z sieci zarządzającej	Nie zezwalać szeroko z `WAN`
`SSH`	Dostęp CLI dla administratorów lub supportu	Zezwalać tylko precyzyjnie, najlepiej z public key
`Ping/Ping6`	Monitoring i proste testy osiągalności	Nie włączać niepotrzebnie z niezaufanych stref
`DNS`	Klienci używają firewalla jako DNS resolver	Włączać tylko dla wewnętrznych stref klientów
`SSL VPN`	Użytkownicy SSL VPN łączą się z firewallem	Na zewnątrz otwierać tylko tyle, ile potrzeba, i chronić MFA
`User Portal`	Użytkownicy pobierają konfiguracje VPN lub tokeny	Z zewnątrz najlepiej przez VPN/ZTNA albo mocno ograniczyć
`VPN Portal`	Użytkownicy Remote Access VPN	Włączać tylko, gdy naprawdę potrzebne, i chronić MFA
`RED`	RED Appliances łączą się z firewallem	Zezwalać tylko dla rzeczywistych lokalizacji RED lub zdefiniowanych źródeł
`SMTP Relay`	systemy wewnętrzne używają firewalla jako SMTP Relay	Nie udostępniać jako open relay z niezaufanych stref
`SNMP`	Monitoring odpytuje wartości firewalla	Zezwalać tylko z systemu monitoringu
`Dynamic Routing`	Protokoły routingu między routerami i firewallem	Włączać tylko w przeznaczonych do tego segmentach sieci

Dla Custom Zones osiągalność usług lokalnych można też wpływać przez ustawienia strefy. Mimo to Device Access należy zawsze sprawdzać świadomie, ponieważ jest centralnym widokiem lokalnych usług firewalla.

Które usługi można ograniczać przez ACL Rules?

Przez Local Service ACL i ACL Exception Rules można bardzo precyzyjnie kontrolować lokalne usługi firewalla. Szczególnie istotne są te usługi:

Usługa	Typowe ryzyko przy zbyt szerokim udostępnieniu
`DNS`	Firewall odpowiada na zapytania DNS z sieci, których nie powinien obsługiwać.
`Dynamic Routing`	Protokoły routingu są dostępne z niewłaściwych segmentów.
`HTTPS`	WebAdmin Console jest dostępna dla zbyt wielu źródeł.
`Ping/Ping6`	Firewall jest niepotrzebnie widoczny i łatwy do skanowania.
`RED`	Usługi RED są dostępne ze zbyt szerokich zakresów źródłowych.
`SMTP Relay`	Błędna konfiguracja może sprzyjać nadużyciu relay.
`SNMP`	Dane monitoringu można odpytać z niewłaściwych sieci.
`SSH`	Bezpośredni dostęp CLI do firewalla jest zbyt otwarty.
`SSL VPN`	Punkty logowania VPN są globalnie dostępne i skanowane.
`User Portal`	Login do portalu i pobieranie VPN są niepotrzebnie wystawione.
`VPN Portal`	Remote Access Portal staje się celem botów i prób brute-force.

Im więcej tych usług jest dostępnych z WAN, sieci gościnnych, sieci IoT albo nieprecyzyjnie zdefiniowanych stref, tym większa powierzchnia ataku. Celem nie jest wyłączenie wszystkiego, lecz udostępnienie każdej usługi tylko tam, gdzie jest naprawdę potrzebna.

Definiować źródła jak najwęziej

ACL Rule nie musi po prostu zezwalać na Any. Źródło można określić bardzo dokładnie, na przykład przez:

pojedyncze adresy IP administratorów
sieci zarządzające
IP ranges
IP lists
FQDN hosts
FQDN host groups
DNS hosts albo DNS groups
Country objects albo grupy krajów
dedykowane sieci VPN lub supportu

Dzięki temu dostęp można znacznie lepiej ograniczyć. Przykład: jeśli zewnętrzna usługa supportu przychodzi tylko ze stałego FQDN albo zdefiniowanego zakresu IP, cała strefa WAN nie powinna otrzymywać dostępu do HTTPS lub SSH. Jeśli system monitoringu wymaga SNMP, cała sieć serwerowa nie powinna móc odpytywać SNMP na firewallu.

W globalnych scenariuszach Remote Access ograniczenie jest trudniejsze. Niektóre firmy nie mogą po prostu zezwolić na SSL VPN lub VPN Portal tylko ze Szwajcarii, Niemiec albo jednego kraju, ponieważ pracownicy działają globalnie. W takich przypadkach trzeba dodatkowo stosować MFA, logging, restrykcyjne ustawienia portali i Threat Feeds.

Local Service ACL Exception Rule

Jeśli usługa nie ma być udostępniona dla całej strefy, używa się Local service ACL exception rule. Pozwala to bardzo dokładnie określić, kto może korzystać z której lokalnej usługi.

Ścieżka:

Otworzyć Administration.
Wybrać Device access.
Przewinąć do Local service ACL exception rule.
Kliknąć Add.

ACL Exception Rule składa się zasadniczo z tych pól:

Pole	Znaczenie
`Rule name`	Jednoznaczna nazwa, na przykład `admin-https-from-mgmt`
`Rule position`	Kolejność reguł ACL
`Source zone`	Strefa, z której przychodzi dostęp, na przykład `WAN`, `LAN` albo `VPN`
`Source Network / Host`	Dozwolony admin-IP, sieć zarządzająca, FQDN Host albo lista IP
`Destination host`	IP firewalla lub interfejs, do którego następuje dostęp
`Services`	Lokalna usługa, na przykład `HTTPS`, `SSH`, `Ping` albo `DNS`
`Action`	`Accept` albo `Drop`

Dla dostępu WebAdmin z internetu nigdy nie należy używać Any jako źródła. Sophos celowo uniemożliwia WebAdmin access ze strefy WAN dla wszystkich źródeł, ponieważ byłoby to wysokie ryzyko. Jeśli dostęp z WAN jest naprawdę konieczny, należy zezwolić na niego tylko przez konkretne źródłowe adresy IP, zdefiniowane sieci, obiekty FQDN albo inne wąskie źródła.

Ważna jest również kolejność. ACL Exception Rules są oceniane od góry do dołu. Wyższa reguła Drop może unieważnić późniejszą regułę Accept. Z kolei zbyt szeroko sformułowana reguła Accept może zniwelować zaplanowane ograniczenia. Kolejność reguł należy więc sprawdzać tak świadomie jak przy regułach firewall.

Zalecana konfiguracja bazowa

Dla wielu środowisk produkcyjnych sensowna jest taka logika:

HTTPS/WebAdmin zezwalać tylko z Management, admin-VPN lub stałego admin-IP.
SSH domyślnie wyłączyć i zezwalać tylko w razie potrzeby przez precyzyjną ACL.
DNS włączać tylko w strefach, w których klienci rzeczywiście używają firewalla jako serwera DNS.
Ping zezwalać dla wewnętrznych systemów monitoringu, ale nie ogólnie z WAN.
User Portal, VPN Portal i SSL VPN włączać tylko, gdy są potrzebne.
RED zezwalać tylko dla lokalizacji lub zakresów źródłowych, w których faktycznie znajdują się RED Appliances.
SNMP zezwalać tylko dla systemu monitoringu.
SMTP Relay zezwalać tylko dla zdefiniowanych systemów wewnętrznych.
Dynamic Routing włączać tylko w segmentach routingu, w których rzeczywiście używa się dynamicznych protokołów routingu.
Sprawdzić MFA dla WebAdmin, VPN Portal i Remote Access.
Używać Sophos Central Firewall Management, jeśli potrzebny jest bezpieczny zewnętrzny dostęp administracyjny.

Szczególna ostrożność przy SSH

SSH jest bardzo przydatne do troubleshootingu i supportu, ale nie powinno być stale szeroko otwarte. Dla SSH obowiązuje:

Tylko użytkownik admin może logować się przez SSH.
Preferowana jest autoryzacja public-key.
Dostęp z WAN powinien odbywać się tylko przez stałe źródłowe adresy IP lub VPN.
Po zakończeniu analizy trzeba sprawdzić, czy SSH nadal jest potrzebne.

Więcej informacji znajduje się w instrukcji Połączenie SSH z Sophos Firewall.

Boty, brute force i Threat Feeds

W praktyce bardzo często widać, że zbyt otwarte usługi są natychmiast znajdowane przez boty. Szczególnie dotyczy to WebAdmin, User Portal, VPN Portal i SSL VPN. Nawet jeśli usługa jest chroniona hasłem i MFA, publiczne loginy generują próby ataku, ruch brute-force, szum w logach i niepotrzebne obciążenie firewalla.

Nie oznacza to automatycznie udanego ataku. Pokazuje jednak, że usługa jest częścią publicznej powierzchni ataku. Im mniej źródeł w ogóle dociera do logowania, tym lepiej.

Jeśli portal musi być dostępny globalnie, filtry krajów albo pojedyncze źródłowe adresy IP często nie wystarczają. W takich środowiskach zalecamy dodatkowo Third-Party Threat Feeds. Threat Feeds stale dostarczają firewallowi aktualne Indicators of Compromise, na przykład złośliwe adresy IP, domeny lub URL-e. Znane skanery, botnety i atakujący mogą zostać zablokowani, zanim dotrą do WebAdmin, VPN Portal, SSL VPN lub innych opublikowanych usług.

Więcej informacji: Threat Feeds w Sophos Firewall

Typowe błędy

Sprawdzanie reguły firewall zamiast Device Access

Jeśli WebAdmin, SSH, DNS albo Ping do firewalla nie są dostępne, zwykła reguła firewall nie pomoże. Ruch nie przechodzi przez firewall, lecz kończy się na nim samym. Dlatego trzeba sprawdzić Administration > Device access.

WebAdmin dostępny ze zbyt wielu stref

WebAdmin nie powinien być dostępny z każdej strefy wewnętrznej. Sieć gościnna, IoT albo VoIP zwykle nie potrzebuje dostępu do zarządzania firewallem. Także wewnątrz należy zakładać możliwość istnienia skompromitowanych klientów. Oddzielna sieć zarządzająca lub admin-VPN znacząco redukuje to ryzyko.

DNS nieaktywny dla strefy klientów

Jeśli klienci mają używać firewalla jako serwera DNS, DNS musi być dozwolony dla właściwej strefy. W przeciwnym razie klienci osiągają adres IP firewalla, ale nie otrzymują odpowiedzi DNS. Odwrotnie, DNS nie powinien być dozwolony ze stref, w których firewall nie ma działać jako DNS resolver.

Pomylenie User Portal i VPN Portal

User Portal i VPN Portal to różne usługi. W zależności od koncepcji Remote Access trzeba sprawdzić, który portal jest naprawdę potrzebny. Często portal zostaje aktywowany, bo użytkownik raz musiał pobrać konfigurację, a potem pozostaje otwarty przez lata. Takie pozostałości należy regularnie usuwać.

Pominięcie szczególnego przypadku Web Proxy

Jeśli używany jest Web Proxy, żądania HTTP i HTTPS mogą z perspektywy proxy wyglądać jak wewnętrzne. Może to wpływać na kontrolę dostępu do WebAdmin, Captive Portal, VPN Portal lub User Portal. W środowiskach z proxy trzeba więc szczególnie dokładnie testować, jakie dostępy są naprawdę możliwe.

Zbyt szeroko sformułowana reguła ACL

ACL Exception Rule z Source zone: Any, Source Network / Host: Any i Services: HTTPS, SSH prawie nigdy nie jest dobrym pomysłem. Takie reguły obchodzą właściwą korzyść bezpieczeństwa z wyjątku ACL. Lepsza jest mała, jasna reguła z jednoznacznym źródłem i dokładnie potrzebnymi usługami.

Reguła Drop w złej pozycji

Jeśli reguła Drop znajduje się nad regułą Accept, dozwolony dostęp mimo to może zostać zablokowany. Przy ACL Exception Rules kolejność jest więc tak samo ważna jak przy regułach firewall.

SSL VPN i VPN Portal pozostawione zbyt otwarte

Remote Access często musi być dostępny z zewnątrz. Mimo to trzeba sprawdzić, czy wszystkie kraje, sieci i grupy użytkowników naprawdę potrzebują dostępu. Jeśli nie da się wąsko ograniczyć źródeł, MFA, logging i Threat Feeds powinny być stosowane tym bardziej konsekwentnie.

Troubleshooting

Jeśli lokalna usługa nie jest dostępna, pomaga taka kolejność:

Czy docelowy adres IP firewalla jest prawidłowy?
Czy klient pochodzi z oczekiwanej strefy?
Czy usługa jest dozwolona dla tej strefy w Administration > Device access?
Czy istnieje pasująca Local service ACL exception rule?
Czy pasuje wyższa reguła ACL z Drop?
Czy usługa jest skonfigurowana na innym porcie?
Czy dostęp jest widziany inaczej przez VPN, proxy albo NAT?
Czy Log Viewer pokazuje wskazówkę?
Czy Packet Capture widzi próbę połączenia na interfejsie?

Dla dostępu supportu może mieć sens utworzenie precyzyjnej ACL Exception Rule i usunięcie albo dezaktywowanie jej po zakończeniu pracy.