Sophos Firewall Bezpieczny dostęp: poprawnie skonfiguruj Device Access

Administration > Device access określa, z jakich stref można uzyskać dostęp do lokalnych usług Sophos Firewall. Należą do nich na przykład HTTPS dla konsoli WebAdmin, SSH dla CLI, Ping, DNS, User Portal, VPN Portal i inne usługi.

Szerszy kontekst hardening opisuje hub Sophos Firewall Hardening: best practices dla bezpiecznej konfiguracji.

Ten obszar ma kluczowe znaczenie dla bezpieczeństwa. Normalne reguły firewalla kontrolują ruch przez firewall. Device Access kontroluje ruch do samego firewalla. Jeśli dostęp do WebAdmin lub SSH jest możliwy z niebezpiecznej strefy, powstaje bezpośredni dostęp administracyjny do urządzenia zabezpieczającego.

API jest również ważne: zezwolenie na dostęp do urządzenia dla HTTPS/WebAdmin wpływa również na dostęp API. Od SFOS 22, źródła dostępu API są dodatkowo utrzymywane w Administration > API access, ale dozwolony host API nie pomoże, jeśli Device Access blokuje lokalny dostęp HTTPS z tej strefy.

⚠️ WebAdmin, SSH i portale powinny być dostępne wyłącznie z zaufanych sieci. W środowiskach produkcyjnych lepiej jest ograniczyć dostęp do sieci zarządzania, stałego adresu IP administratora, VPN lub zarządzania zaporą sieciową Sophos Central.

To oddzielenie pomaga w praktyce:

• Device Access Tabela stref: Ogólnie zezwalaj lub blokuj usługi dla każdej strefy, na przykład DNS dla LAN, ping dla strefy monitorowania lub SSL VPN dla wymaganej strefy zdalnego dostępu.
• Local Service ACL Reguła wyjątku: Ściślej kontroluj dostęp według źródła, miejsca docelowego i usługi, na przykład WebAdmin tylko z sieci zarządzającej, SSH tylko z pomocniczego adresu IP lub SNMP tylko z monitorowania System.
• Normalna reguła zapory: Zezwól lub zablokuj ruch przez zaporę, na przykład gdy klient z LAN uzyskuje dostęp do serwera w DMZ lub do usługi internetowej.

To pokazuje jasno: reguła firewall nie zastępuje utwardzenia Device Access. Jeśli HTTPS lub SSH są zbyt szeroko dostępne przez Device Access, klient dociera do lokalnej usługi firewalla, zanim klasyczna reguła ruchu tranzytowego w ogóle byłaby właściwym miejscem kontroli.

Dlaczego Device Access nie działa jak reguła zapory sieciowej

Typowa reguła zapory sieciowej zezwala lub blokuje połączenia pomiędzy strefami, na przykład LAN do WAN lub VPN do Server. Device Access jest inne: chodzi o usługi działające bezpośrednio na Sophos Firewall.

Przykłady:

• Administrator otwiera https://172.16.16.16:4444.
• Klient używa zapory sieciowej jako serwera DNS.
• Monitorujący System wysyła polecenie ping do zapory ogniowej.
• Użytkownik otwiera User Portal lub VPN Portal.
• Administrator łączy się z zaporą sieciową poprzez SSH.

Celem takiego ruchu nie jest serwer znajdujący się za zaporą, lecz sama zapora. Dlatego jest kontrolowany poprzez lokalną usługę ACL.

Jest to również powód, dla którego Device Access jest częścią podstawowego wzmocnienia każdego Sophos Firewall. Czysty zestaw reguł dla LAN-to-WAN nie chroni automatycznie usług zarządzania i portalu samej zapory. Usługi te należy rozpatrywać oddzielnie i celowo ograniczać.

Zrozumienie prześwitów strefowych

W górnej części Administration > Device access widać tabelę ze strefami i usługami. Jeśli usługa jest aktywna dla danej strefy, dostęp do tej lokalnej usługi jest z tej strefy zasadniczo dozwolony.

Tabela stref jest praktyczna, ale dość prosta i pasuje do przejrzystych stref wewnętrznych, na przykład LAN, Management lub VPN. Jeśli usługa ma być dostępna tylko dla pojedynczych adresów IP administratorów, lokalizacji, krajów lub celów supportu, lepszym wyborem są Local service ACL exception rules.

W przypadku stref niestandardowych należy również sprawdzić ustawienia strefy. Może to również mieć wpływ na usługi lokalne. Niemniej jednak Administration > Device access pozostaje centralnym miejscem, w którym można świadomie włączyć lub ograniczyć lokalne usługi firewall.

Typowe przykłady:

• HTTPS: Dostęp WebAdmin z sieci zarządzania. Nie zezwalaj szeroko z WAN.
• SSH: Dostęp CLI dla administratorów lub wsparcia. Zezwalaj tylko specjalnie, najlepiej z kluczem publicznym.
• Ping/Ping6: Monitoring i proste testy dostępności. Nie aktywuj niepotrzebnie z niebezpiecznych stref.
• DNS: Klienci używają zapory sieciowej jako narzędzia rozpoznawania nazw DNS. Włącz tylko dla wewnętrznych stref klienta.
• SSL VPN: Użytkownicy SSL VPN łączą się z firewallem. Z zewnątrz otwieraj tylko tak szeroko, jak to konieczne, i zabezpieczaj MFA; port sprawdzaj osobno w obszarze Remote Access.
• User Portal: Użytkownicy ładujący konfiguracje VPN lub tokeny. Zewnętrznie przez VPN/ZTNA, jeśli to możliwe lub z wąskim limitem.
• VPN Portal: Użytkownicy Remote Access VPN. Tylko jeśli jest naprawdę potrzebny i zabezpieczony MFA.
• RED: Urządzenia RED łączą się z zaporą sieciową. Zezwalaj tylko na rzeczywiste lokalizacje RED lub określone źródła.
• SMTP Relay: Systemy wewnętrzne używają zapory ogniowej jako SMTP Relay. Nie zwalniaj jako przekaźnika otwartego z niebezpiecznych stref.
• SNMP: Monitorowanie odpytuje wartości zapory ogniowej. Zezwalaj tylko na monitorowanie System; Szczegóły można znaleźć w SNMP Monitorowanie sprzętu.
• Dynamic Routing: Protokoły routingu między routerami a firewallem. Aktywuj tylko w przeznaczonych do tego segmentach sieci.

W SFOS 22, WebAdmin, VPN Portal i User Portal obsługują TLS 1.3. Jest to dobre rozwiązanie do szyfrowania, ale nie zmienia podstawowej zasady: usługa, do której można uzyskać dostęp ze zbyt wielu źródeł, pozostaje niepotrzebną powierzchnią ataku. Szyfrowanie transportu nie zastępuje czystej listy ACL.

Które usługi można ograniczyć za pomocą reguł ACL?

Lokalnymi usługami firewalla można bardzo precyzyjnie sterować przez Local Service ACL i ACL Exception Rules. Szczególnie istotne są te usługi:

• DNS: Zapora odpowiada na żądania DNS z sieci, których nie powinna obsługiwać.
• Dynamic Routing: Protokoły routingu są osiągalne z niewłaściwych segmentów.
• HTTPS: Konsola WebAdmin jest dostępna dla zbyt wielu źródeł.
• Ping/Ping6: Zapora sieciowa jest niepotrzebnie łatwa do zobaczenia i przeskanowania.
• RED: Usługi RED są dostępne ze zbyt szerokich źródeł.
• SMTP Relay: Błędne konfiguracje mogą sprzyjać nadużyciom przekaźnika.
• SNMP: Dane monitorowania można uzyskać z nieprawidłowych sieci.
• SSH: Bezpośredni dostęp CLI do zapory jest zbyt otwarty.
• SSL VPN: Punkty logowania VPN są dostępne i skanowane na całym świecie.
• User Portal: Logowanie do portalu i pobieranie plików VPN są niepotrzebnie ujawniane.
• VPN Portal: Portal zdalnego dostępu jest celem botów i prób użycia siły.

Im więcej tych usług jest dostępnych z WAN, sieci gościnnych, sieci IoT lub niejasno zdefiniowanych stref, tym większa staje się powierzchnia ataku. Celem nie jest dezaktywacja wszystkiego, ale udostępnienie każdej usługi tylko tam, gdzie jest naprawdę potrzebna.

Zdefiniuj źródła dostępu tak wąsko, jak to możliwe

Reguła ACL nie musi po prostu zezwalać na Any. Możesz bardzo dobrze pracować jako źródło, na przykład z:

• indywidualne adresy IP administratora
• Sieci zarządzania
• Zakresy adresów IP
• Listy adresów IP
• FQDN hosty
• FQDN grupy hostów
• DNS hosty lub grupy DNS
• Obiekty krajowe lub grupy krajów
• dedykowana sieć VPN lub sieci wsparcia

Dzięki temu znacznie łatwiej jest ograniczyć dostęp. Na przykład: Jeśli zewnętrzna usługa wsparcia pochodzi tylko ze stałego FQDN lub określonego zakresu adresów IP, cała strefa WAN nie powinna mieć dostępu do HTTPS lub SSH. Jeśli monitorowanie System wymaga SNMP, cała sieć serwerów nie powinna mieć możliwości wysyłania zapytań SNMP do zapory ogniowej.

Określenie jest trudniejsze w scenariuszach globalnego dostępu zdalnego. Niektóre firmy nie mogą po prostu zwolnić SSL VPN lub VPN Portal dla Szwajcarii, Niemiec lub pojedynczego kraju, ponieważ pracownicy podróżują po całym świecie. W takich przypadkach powinieneś także pracować z MFA, logowaniem, restrykcyjnymi ustawieniami portalu i źródłami zagrożeń.

Model decyzji dotyczących usług lokalnych

Dla każdej usługi lokalnej powinieneś świadomie decydować, który poziom dostępu jest odpowiedni. Rzadko ma sens traktowanie WebAdmin, SSH, User Portal, VPN Portal, DNS i SNMP w ten sam sposób.

• Wyłączone: Odpowiednie, jeśli usługa nie jest potrzebna w środowisku. Przykład: SSH trwale wyłączone, jeśli nie jest zapewniony dostęp CLI.
• Tylko strefa wewnętrzna: Odpowiednia, gdy usługa jest potrzebna wielu klientom wewnętrznym. Przykład: DNS z LAN, gdy klienci używają zapory sieciowej jako programu tłumaczącego DNS.
• Sieć zarządzająca: Odpowiednia do usług administracyjnych lub związanych z monitorowaniem. Przykład: HTTPS, SSH i SNMP tylko z Management.
• Admin VPN: Odpowiedni, jeśli administratorzy mają pracować zewnętrznie, ale nie bezpośrednio z Internetu. Przykład: WebAdmin dostępny tylko przez VPN.
• Reguła wyjątku ACL: Odpowiednia, gdy dostęp powinien pochodzić z bardzo określonego źródła. Przykład: pomocniczy adres IP może tymczasowo uzyskać dostęp do HTTPS lub SSH.
• WAN szeroko dostępny: Tylko dla usług rzeczywistego zdalnego dostępu i z dodatkową ochroną. Przykład: SSL VPN dla użytkowników mobilnych z MFA, logowaniem i źródłami zagrożeń.

Tę decyzję należy udokumentować. Zwłaszcza w przypadku wyjątków od WAN musi być możliwe późniejsze zrozumienie, dlaczego usługa jest dostępna, kto jej potrzebuje i kiedy wyjątek zostanie ponownie sprawdzony.

Dostęp WAN jest wyjątkiem

WAN to nie tylko kolejna strefa. Wszystko, co będzie dostępne z WAN, zostanie znalezione przez skanery, boty i narzędzia brute-force. Dlatego WebAdmin z WAN nie powinno być planowane jako normalny wariant działania.

Jeśli potrzebny jest zewnętrzny dostęp do zarządzania, te warianty są zwykle bezpieczniejsze:

• Sophos Central Zarządzanie zaporą ogniową do zadań administracyjnych.
• Admin VPN z MFA i wyczyść grupę użytkowników.
• Tymczasowa reguła wyjątku listy ACL dla stałego źródłowego adresu IP.
• Dedykowana sieć zarządzania poprzez VPN typu site-to-site.

Jeśli chodzi o ogólny obraz wzmocnienia, Sophos Firewall Prawidłowe użycie Health Check również pasuje, ponieważ dostęp do zarządzania, MFA, kopie zapasowe i regularna higiena są tam oceniane razem.

Sophos dodatkowo chroni WebAdmin przed udostępnieniem wszystkim źródłom WAN. Jeśli dostęp WAN jest naprawdę konieczny, należy go ograniczyć poprzez określone źródła, takie jak indywidualne adresy IP, sieci lub obiekty FQDN. Istniejące starsze wersje starszych konfiguracji powinny być regularnie sprawdzane: Sophos może automatycznie dezaktywować niektóre szerokie wersje WAN dla WebAdmin lub User Portal po długim okresie bezczynności, podczas gdy ukierunkowane wyjątki ACL dla określonych źródeł WAN mogą nadal obowiązywać.

Local Service ACL Reguła wyjątku

Jeśli usługa nie powinna zostać zwolniona dla całej strefy, użyj Reguły wyjątku listy ACL usług lokalnych. Pozwala to na bardzo precyzyjne zdefiniowanie, kto może uzyskać dostęp do danej usługi lokalnej.

Ścieżka:

1. Otwórz Administration.
2. Wybierz Device access.
3. Przewiń do Local service ACL exception rule.
4. Kliknij Add.

Typowy przepływ dla wąskiego wyjątku administratora z WAN:

1. Ustaw Rule name, na przykład admin-https-from-support-ip.
2. Ustaw Rule position na Top, jeśli istniejąca reguła Drop lub Allow mogłaby w przeciwnym razie zacząć obowiązywać wcześniej.
3. Wybierz IP version, aby dopasować źródło, zwykle IPv4.
4. Ustaw Source zone na WAN.
5. Ustaw Source Network / Host na konkretny adres IP administratora, małą sieć administratora lub obsługiwany obiekt FQDN/IP.
6. Ogranicz Destination host do adresu zapory lub interfejsu, którego dotyczy problem, jeśli nie wszystkie lokalne cele są celowo brane pod uwagę.
7. Ustaw Services na wymaganą usługę lokalną, na przykład HTTPS dla WebAdmin lub API, a nie jednocześnie HTTPS i SSH dla wygody.
8. Ustaw Action na Accept.
9. Zapisz i natychmiast przetestuj z dozwolonych i niedozwolonych źródeł.

Reguła wyjątku listy ACL zasadniczo składa się z następujących pól:

• Rule name: Unikalna nazwa, na przykład admin-https-from-mgmt.
• Rule position: Kolejność reguł ACL.
• Source zone: Strefa, z której następuje dostęp, na przykład WAN, LAN lub VPN.
• Source Network / Host: Dozwolony adres IP administratora, sieć zarządzająca, host FQDN lub lista adresów IP.
• Destination host: Dostęp do adresu IP lub interfejsu zapory sieciowej.
• Services: Usługa lokalna, na przykład HTTPS, SSH, Ping lub DNS.
• Action: Accept lub Drop.

Nigdy nie używaj Any jako źródła dostępu WebAdmin z Internetu. Sophos celowo uniemożliwia dostęp WebAdmin ze strefy WAN dla wszystkich źródeł, ponieważ wiązałoby się to z wysokim ryzykiem. Jeśli dostęp WAN jest naprawdę konieczny, powinien być dozwolony jedynie za pośrednictwem określonych źródłowych adresów IP, zdefiniowanych sieci, obiektów FQDN lub innych wąskich źródeł.

Ta sama logika dotyczy automatyzacji API. Host może zostać dopuszczony do Administration > API access, a mimo to nie powiedzie się, jeśli brakuje uprawnienia HTTPS w Device Access. I odwrotnie, udział HTTPS nie powinien być szerszy tylko dlatego, że podłączone jest narzędzie API. W przypadku szczegółów API odpowiednia jest opcja Sophos Firewall API Bezpiecznie ogranicz dostęp.

Kolejność jest również ważna. ACL Exception Rules są oceniane od góry do dołu. Wyższa reguła Drop może unieważnić późniejszą regułę Accept. I odwrotnie, zasada Accept sformułowana zbyt szeroko może podważyć późniejsze zaplanowane ograniczenia. Kolejność reguł należy zatem sprawdzać równie świadomie, jak w przypadku reguł firewalla.

Parametr Destination host jest szczególnie ważny, jeśli zapora sieciowa ma wiele interfejsów, adresów aliasów, adresów VPN lub oddzielnych celów portalu/administratora. Reguła powinna wskazywać możliwie najdokładniej adres zapory ogniowej, która ma być faktycznie administrowana lub używana. W przeciwnym razie wydanie o wąskim źródle nagle wpłynie na większą liczbę lokalnych usług lub interfejsów, niż planowano.

Unikaj blokowania przed zmianą

Zmiany w dostępie do urządzenia mają bezpośredni wpływ na zarządzanie i dostęp do portalu. Dlatego przed jakimkolwiek ograniczeniem powinno być jasne, jak wrócić do zapory sieciowej, jeśli reguła jest niepoprawna.

Przed zapisaniem ryzykownej zmiany powinieneś sprawdzić:

• Czy dostępny jest drugi administrator z odpowiednim profilem uprawnień?
• Czy jest dostęp przez inną sieć, na przykład zarządzanie LAN, administrator VPN lub Sophos Central?
• Czy dostępna jest konsola lokalna lub osiągalność poza pasmem, jeśli WebAdmin stanie się nieosiągalny?
• Czy obecnie pracujesz nad klastrem HA, w którym zmiana roli może zmienić ścieżkę dostępu?
• Czy udokumentowano bieżący plik kopii zapasowej, Secure Storage Master Key i dostęp awaryjny?
• Czy istnieje krótki okres konserwacji, w którym nieprawidłowe próby dostępu są natychmiast wykrywane?

Szczególnie w przypadku odległych lokalizacji nie należy najpierw usuwać wersji ogólnej, a następnie ją testować. Proces odwrotny jest bezpieczniejszy: utwórz nową regułę wyjątku wąskiej listy ACL, przetestuj dozwolony dostęp, potwierdź drugą ścieżkę administratora i dopiero wtedy zmniejsz starą wersję szerokiej strefy.

Bezpiecznie wdrażaj zmiany

Zmiany dostępu do urządzenia mogą zablokować administratorów. Dlatego nie należy ich zmieniać przypadkowo, ale raczej traktować je jak zmianę w zarządzaniu.

Najlepsza praktyka:

1. Bieżący dostęp do dokumentu: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP i Ping.
2. Upewnij się, że istnieje druga ścieżka administratora, na przykład konsola lokalna, VPN administratora lub Sophos Central.
3. Utwórz kopię zapasową przed wprowadzeniem poważnych zmian na liście ACL.
4. Utwórz nową regułę wyjątków ACL tak szczegółowo, jak to możliwe.
5. Testuj dostęp z dozwolonego źródła.
6. Sprawdź dostęp z nieautoryzowanego źródła.
7. Log Viewer sprawdź, czy oczekiwane zdarzenia są widoczne.
8. Nie usuwaj starego udziału w szerokiej strefie do czasu potwierdzenia nowego dostępu.
9. Zmiana dokumentu z datą, źródłem, usługą i osobą odpowiedzialną.

Jeśli problem dotyczy wielu zapór sieciowych lub klastrów HA, zmianę należy najpierw przetestować na System z dobrą możliwością powrotu do pracy. W przypadku środowisk HA odpowiednia jest także opcja Sophos Firewall Skonfiguruj wysoką dostępność, ponieważ w tym przypadku dostęp do zarządzania, zmiany ról i okresy konserwacji należy uwzględnić łącznie.

Kontrola uzupełniająca po zmianach dostępu do urządzenia

Po dostosowaniu nie wystarczy po prostu sprawdzić własny dostęp WebAdmin. Powinieneś przetestować zarówno dozwolone, jak i niedozwolone źródła, w przeciwnym razie nie będzie jasne, czy utwardzanie naprawdę działa.

• WebAdmin z sieci zarządzania: Dostęp działa zgodnie z planem.
• WebAdmin ze zwykłej sieci klienckiej: Dostęp jest zablokowany, chyba że wyraźnie zezwolono.
• SSH z sieci administracyjnej: Dostęp działa tylko wtedy, gdy SSH jest świadomie włączony.
• SSH z WAN lub sieci gościnnej: Dostęp jest zablokowany.
• DNS z sieci klienckiej: DNS działa tylko w sieciach, które powinny używać zapory ogniowej jako mechanizmu rozpoznawania nazw.
• User Portal lub VPN Portal: Można uzyskać dostęp tylko do wymaganych portali.
• SNMP z monitoringu-System: Monitoring działa, inne źródła są zablokowane.

Jeśli dostęp działa nieoczekiwanie, należy sprawdzić nie tylko regułę wyjątku listy ACL. Przyczyną może być również tabela stref w górnym obszarze dostępu do urządzenia, niestandardowe ustawienia strefy, strefa VPN, zachowanie serwera proxy i istniejące ogólne reguły Accept.

Krótka lista poszczególnych usług jest często wystarczająca do udokumentowania:

• HTTPS: dozwolone źródło mgmt-net, powód dostęp administracyjny do WebAdmin, przegląd kwartalny.
• SSH: dozwolone źródło support-ip-temporary, powód sprawa wsparcia, przegląd po zamknięciu zgłoszenia.
• SNMP: dozwolone źródło monitoring-server, powód monitoring sprzętu i interfejsów, przegląd co pół roku.
• SSL VPN: dozwolone źródło WAN, przyczyna Remote Access, przeglądaj z comiesięcznym sprawdzaniem dziennika.

Każda kontrola następcza powinna również sprawdzić, czy udane i zablokowane dostępy są w ogóle widoczne. Do krótkich testów często wystarcza Log Viewer. W przypadku dłuższego przechowywania lub pytań audytowych lepiej nadają się Central Reporting albo Syslog, ponieważ lokalne logi mogą rotować lub zostać utracone w razie awarii.

Zalecana konfiguracja podstawowa

W wielu środowiskach produkcyjnych następująca logika ma sens:

• Zezwalaj na HTTPS/WebAdmin tylko z Management, VPN administratora lub stały adres IP administratora.
• Zezwalaj na API tylko ze zdefiniowanych hostów automatyzacji lub monitorowania i dodatkowo odpowiednio ograniczaj HTTPS poprzez Device Access.
• SSH jest domyślnie dezaktywowany i pozwala na to tylko poprzez ACL, jeśli to konieczne.
• Włącz DNS tylko w strefach, w których klienci faktycznie używają zapory jako serwera DNS.
• Zezwól na ping dla wewnętrznych systemów monitorowania, ale nie ogólnie z WAN.
• User Portal, VPN Portal i SSL VPN aktywują się tylko w razie potrzeby.
• Zezwalaj na RED tylko w przypadku lokalizacji lub obszarów źródłowych, w których faktycznie znajdują się urządzenia RED.
• Zezwól SNMP tylko na monitorowanie System.
• Zezwalaj na SMTP Relay tylko dla zdefiniowanych systemów wewnętrznych.
• Aktywuj Routing dynamiczny tylko w segmentach routingu, w których faktycznie używane są protokoły routingu dynamicznego.
• Sprawdź MFA pod kątem WebAdmin, VPN Portal i dostępu zdalnego; Obiekt znajduje się w MFA dla Sophos Firewall WebAdmin, VPN Portal i aktywuje dostęp zdalny.
• Użyj Sophos Central Zarządzanie zaporą sieciową, gdy wymagany jest bezpieczny dostęp do zarządzania z zewnątrz.

Aby zapewnić dłuższą identyfikowalność, należy również sprawdzić strategię dziennika. Lokalne dzienniki są wystarczające do szybkiego rozwiązywania problemów, ale nie do każdego pytania dotyczącego audytu lub reakcji na incydent. Jeśli w dłuższej perspektywie konieczne jest śledzenie dostępu do portalu lub zarządzania, bardziej odpowiednimi elementami są Centralne raportowanie zapory ogniowej lub Sophos Firewall Syslog wysłane do SIEM.

Z SSH należy obchodzić się szczególnie ostrożnie

SSH jest bardzo przydatne przy rozwiązywaniu problemów i wsparciu, ale nie powinno być stale otwarte. Poniższe informacje dotyczą SSH:

• Tylko użytkownik admin może zalogować się poprzez SSH.
• Preferowany sposób uwierzytelniania za pomocą klucza publicznego.
• Dostęp z WAN powinien odbywać się wyłącznie poprzez stałe źródłowe adresy IP lub VPN.
• Po zakończeniu analizy należy sprawdzić, czy SSH jest nadal wymagany.

Więcej informacji można znaleźć w instrukcjach Sophos Firewall połącz przez SSH.

Boty, brutalna siła i źródła zagrożeń

W praktyce często zdarza się, że boty natychmiast znajdują zbyt otwarte usługi. Szczególnie dotknięte są WebAdmin, User Portal, VPN Portal i SSL VPN. Nawet jeśli usługa jest chroniona hasłem i MFA, publiczne logowania powodują próby ataków, ruch siłowy, szum w logach i niepotrzebne obciążenie zapory ogniowej.

Nie oznacza to automatycznie, że ma miejsce udany atak. Pokazuje jednak, że usługa jest częścią publicznej powierzchni ataku. Im mniej źródeł dotrze do loginu, tym lepiej.

Jeśli portal musi być dostępny na całym świecie, filtry krajów lub indywidualne źródłowe adresy IP często nie wystarczą. W takich środowiskach zalecamy również źródła zagrożeń innych firm. Kanały zagrożeń stale dostarczają zaporze aktualne wskaźniki naruszenia, takie jak złośliwe adresy IP, domeny lub adresy URL. Może to uniemożliwić znanym skanerom, botnetom i atakującym dostęp do WebAdmin, VPN Portal, SSL VPN lub innych opublikowanych usług.

Specjalny artykuł Sophos Firewall Kanały o zagrożeniach wyjaśnia planowanie, umieszczanie na liście dozwolonych i działanie.

Typowe błędy

Sprawdzono regułę zapory sieciowej zamiast Device Access

Jeśli nie można osiągnąć WebAdmin, SSH, DNS lub polecenia ping do zapory ogniowej, zwykła reguła zapory nie pomoże. Ruch nie przechodzi przez zaporę, ale kończy się na samej zaporze. Dlatego należy sprawdzić Administration > Device access.

Dozwolony WebAdmin ze zbyt wielu stref

WebAdmin nie powinien być dostępny z każdej strefy wewnętrznej. Sieć gościnna, sieć IoT czy sieć VoIP zwykle nie wymagają dostępu do zarządzania zaporami sieciowymi. Wewnętrznie należy również założyć, że mogą istnieć klienci zagrożeni. Oddzielna sieć zarządzająca lub VPN administratora znacznie zmniejsza to ryzyko.

DNS nie jest włączone dla strefy klienta

Jeśli klienci mają używać zapory sieciowej jako serwera DNS, DNS musi być dopuszczony dla odpowiedniej strefy. W przeciwnym razie klienci osiągną adres IP zapory, ale nie otrzymają odpowiedzi DNS. I odwrotnie, DNS nie powinno być dozwolone ze stref, w których zapora ogniowa nie jest przeznaczona do stosowania jako moduł rozpoznawania nazw DNS.

User Portal i VPN Portal pomieszane

User Portal i VPN Portal to różne usługi. W zależności od koncepcji zdalnego dostępu należy sprawdzić, który portal jest naprawdę potrzebny. Często portal jest aktywowany, ponieważ użytkownik musiał raz pobrać konfigurację, ale potem pozostaje otwarty przez lata. Takie skażone miejsca należy regularnie usuwać.

Jeśli portale muszą pozostać dostępne z Internetu, nie należy po prostu zaznaczać tego pola wyboru. Ważne jest MFA, grupy użytkowników, proces tokenu/aprowizacji, wygaśnięcie użytkowników tymczasowych, logowanie i pytanie, czy po wdrożeniu portal będzie nadal potrzebny na stałe.

Pominięto specjalny przypadek serwera proxy sieci Web

Podczas korzystania z serwera proxy sieci Web żądania HTTP i HTTPS mogą wydawać się wewnętrzne z perspektywy serwera proxy. Może to mieć wpływ na sposób kontroli dostępu do WebAdmin, Captive Portal, VPN Portal lub User Portal. Dlatego w środowiskach z serwerem proxy należy szczególnie dokładnie sprawdzić, jaki dostęp jest naprawdę możliwy.

Reguła ACL została sformułowana zbyt szeroko

Reguła wyjątku ACL z Source zone: Any, Source Network / Host: Any i Services: HTTPS, SSH prawie nigdy nie jest dobrym pomysłem. Takie reguły omijają faktyczne korzyści związane z bezpieczeństwem, jakie zapewnia wyjątek listy ACL. Lepiej mieć małą, jasną regułę z jasnym źródłem i dokładnie wymaganymi usługami.

Reguła Drop w złym położeniu

Jeśli reguła Drop jest wyższa niż reguła Accept, dozwolony dostęp może być nadal blokowany. Dlatego w przypadku ACL Exception Rules kolejność jest tak samo ważna, jak w przypadku reguł zapory sieciowej.

I odwrotnie, szeroka reguła Accept na górze listy może sprawić, że późniejsze reguły Drop będą praktycznie bezwartościowe. Po każdej zmianie reguły należy sprawdzić nie tylko nową regułę, ale także logikę trafień reguł powyżej niej.

SSL VPN i VPN Portal pozostały zbyt otwarte

Zdalny dostęp często musi być dostępny z zewnątrz. Niemniej jednak powinieneś sprawdzić, czy wszystkie kraje, sieci i grupy użytkowników naprawdę potrzebują dostępu. Jeżeli ścisłe ograniczenia źródeł nie są możliwe, należy jeszcze bardziej konsekwentnie wykorzystywać MFA, rejestrowanie i źródła zagrożeń.

Rozwiązywanie problemów

Jeśli nie można uzyskać dostępu do usługi lokalnej, pomoże ta sekwencja:

1. Czy docelowy adres IP zapory jest poprawny?
2. Czy klient pochodzi z oczekiwanej strefy?
3. Czy w Administration > Device access dozwolona jest obsługa tej strefy?
4. Czy istnieje odpowiednia Reguła wyjątku ACL usługi lokalnej?
5. Czy może mieć zastosowanie wyższa reguła ACL z Drop?
6. Czy usługa jest skonfigurowana na innym porcie?
7. Czy dostęp przez VPN, proxy lub NAT jest wyświetlany inaczej niż oczekiwano?
8. Czy Log Viewer pokazuje podpowiedź?
9. Czy Packet Capture może zobaczyć próbę połączenia w interfejsie?

W przypadku dostępu do pomocy technicznej rozsądne może być utworzenie docelowej reguły wyjątku listy ACL i usunięcie jej lub dezaktywacja po zakończeniu.

Operacyjna lista kontrolna

• WebAdmin nie jest powszechnie dostępny z WAN.
• SSH dozwolone tylko tymczasowo lub z sieci zarządzania/administracji.
• DNS aktywne tylko dla stref klienckich, które faktycznie używają zapory ogniowej jako modułu rozpoznawania nazw.
• SNMP dozwolone tylko przez monitor System lub sieć monitorującą.
• User Portal, VPN Portal i SSL VPN są aktywne tylko wtedy, gdy są potrzebne w koncepcji zdalnego dostępu.
• MFA sprawdzone pod kątem WebAdmin, VPN Portal i dostępu zdalnego.
• Dostęp API dozwolony tylko ze zdefiniowanych hostów i sprawdzany względem Device Access.
• ACL Exception Rules o nazwie z jasnym źródłem, usługą i celem.
• Tymczasowe zasady wsparcia udokumentowane datą wygaśnięcia.
• Testowano dostęp z dozwolonych i niedozwolonych źródeł.
• Rejestrowanie, Central Reporting lub Syslog sprawdzone pod kątem odpowiedniego dostępu do portalu i zarządzania.
• Przegląd kwartalny zaplanowany dla WebAdmin, SSH, SNMP, User Portal, VPN Portal i SSL VPN.

Często zadawane pytania