Ochrona Sophos Firewall VPN Portal przed atakami brute force

Duża liczba nieudanych logowań do Sophos Firewall VPN Portal oznacza przede wszystkim, że portal jest dostępny z Internetu i atakowany automatycznie. Nie stanowi jeszcze dowodu skutecznego włamania. Sytuacja staje się krytyczna, gdy atak trafia w prawdziwe nazwy użytkowników, konta w AD lub Microsoft Entra ID są blokowane albo pomiędzy nieudanymi próbami pojawia się nieznane udane logowanie.

Atak należy ograniczać w następującej kolejności:

1. Zabezpieczyć w logach przedział czasu, użytkowników, źródłowe adresy IP i metody uwierzytelniania.
2. Sprawdzić udane logowania i zdarzenia tożsamości w tym samym okresie.
3. Ograniczyć VPN Portal za pomocą Local Service ACL do wymaganych źródeł lub krajów.
4. Włączyć Block login i wykluczyć współdzielenie portu przez VPN Portal i SSL VPN.
5. Usunąć niepotrzebne metody uwierzytelniania oraz sprawdzić MFA lub ochronę Entra.
6. Dodatkowo blokować znane złośliwe źródła IPv4 za pomocą Threat Feeds i monitorować skuteczność.

⚠️ Nie należy wyłączać VPN Portal bez przygotowania. Sophos Connect Provisioning i Microsoft Entra ID SSO używają portu VPN Portal. Przed zmianą Device Access lub portów potrzebna jest przetestowana druga droga administracyjna oraz plan dla profili klientów, Redirect URIs i powrotu do poprzedniej konfiguracji.

Przed każdą zmianą należy zapisać bieżące ustawienia lub wykonać kopię konfiguracji. Obejmuje to zaznaczenie WAN dla VPN portal, wszystkie pola i kolejność wyjątków Local Service ACL, stan i trzy wartości Block login, porty i protokoły VPN Portal oraz SSL VPN, a także wybór i kolejność serwerów uwierzytelniania. Dla provisioningu lub Entra SSO trzeba również zapisać vpn_portal_port, adres URL portalu i Redirect URI. Dla zmienionych Threat Feeds należy zachować URL, typ wskaźnika, action, stan i opcje niestandardowe. Powrót przywraca te wartości, a nie domniemane ustawienia domyślne.

Potwierdzanie ataku w Log Viewer

W Log Viewer należy otworzyć zdarzenia uwierzytelniania i ustawić filtry:

• Log component: VPN Portal Authentication
• Status: Failed

Dla każdego wyniku istotne są czas, Source IP, Source country, Username, Authentication mechanism i Reason. Nie wszystkie są standardowymi kolumnami w każdym widoku; Detailed view i dodatkowe kolumny pokazują dane dostępne dla zdarzenia. Gdy brakuje kontekstu, trzeba sprawdzić logi surowe i Identity Provider. W SIEM filtruje się log_component po VPN Portal Authentication, a status po Failed; składnia zależy od SIEM.

Następnie dla tych samych nazw użytkowników i tego samego przedziału czasu należy również wyszukać Successful. Nieznane udane logowanie jest ważniejsze niż sama liczba nieudanych prób i musi być potraktowane jako potencjalny incydent dotyczący konta.

Jedno źródło lub atak rozproszony

Rozkład prób decyduje o skutecznej ochronie:

• Wiele prób z jednego adresu IP: Block login może tymczasowo zablokować źródło po osiągnięciu progu.
• Niewiele prób z wielu adresów IP: Rozproszony botnet może dla każdego źródła pozostać poniżej progu. Wówczas większe znaczenie mają ACL, ochrona tożsamości i Threat Feeds.
• Wiele nazw użytkowników z tego samego źródła: Pasuje to do Password Spraying lub Credential Stuffing.
• Powtarzające się próby dla tego samego prawdziwego użytkownika: Sprawdzić w logach AD, Entra lub RADIUS blokady kont i udane logowania.
• Losowe, nieistniejące nazwy: Często jest to automatyczne skanowanie, ale nadal generuje obciążenie i szum w logach.

Ręczne zablokowanie tylko źródłowego adresu IP rzadko rozwiązuje rozproszony atak na stałe. Najpierw należy zmniejszyć dostępną powierzchnię, a następnie automatycznie dodać znane złe źródła.

Ukierunkowane sprawdzanie logów surowych

Jeśli Log Viewer nie dostarcza wystarczającego kontekstu, w Diagnostics > Tools > Troubleshooting logs należy pobrać odpowiednie pliki:

• vpnportal.log dla dostępu do portalu;
• access_server.log dla uwierzytelniania i autoryzacji użytkowników;
• oauth_sso_vpn.log dodatkowo dla Microsoft Entra ID SSO.

Natomiast sslvpn.log należy do usługi SSL VPN i jest istotny dopiero wtedy, gdy błąd występuje podczas zestawiania tunelu, a nie podczas logowania do portalu. Logi uwierzytelniania mogą zawierać nazwy użytkowników, publiczne adresy IP i inne wrażliwe dane żądań. Dlatego fragmenty należy ograniczyć czasowo i treściowo, zanonimizować przed przekazaniem i nie kopiować bez sprawdzenia do publicznych zgłoszeń. Usługi i logi Sophos Firewall przyporządkowują kolejne pliki logów; Zabezpieczanie logów Sophos Firewall opisuje uporządkowane archiwum dla supportu.

Ograniczanie VPN Portal do wymaganych źródeł

VPN Portal jest lokalną usługą firewalla. Zwykłe reguły firewall lub DNAT nie sterują tym dostępem; służy do tego Administration > Device access. Pełne podstawy opisuje artykuł Device Access i Local Service ACL.

Przed zmianą należy otworzyć i faktycznie przetestować niezależny dostęp przez konsolę, zarządzającą sieć LAN, administracyjny VPN lub Sophos Fusion (dawniej Sophos Central). Następnie najpierw tworzy się wąski wyjątek:

1. W Administration > Device access > Local service ACL exception rule kliknąć Add.
2. Rule name: na przykład vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; jeśli opublikowano IPv6, potrzebna jest również oddzielna reguła IPv6.
5. Source zone: WAN.
6. Source networks and hosts: stałe sieci partnerów, utrzymywana lista adresów IP lub Country Group obejmująca rzeczywiście potrzebne kraje.
7. Destination host: interfejs WAN lub adres IP WAN skonfigurowany na Sophos Firewall, na który dociera ruch. Za nadrzędnym routerem NAT nie oznacza to publicznego adresu tego routera.
8. Services: tylko VPN portal.
9. Action: Accept.
10. Zapisać regułę.

Po zapisaniu najpierw testuje się wyjątek z dozwolonego źródła zewnętrznego. Przez sprawdzoną drugą drogę administracyjną usuwa się ogólne zaznaczenie WAN dla VPN portal w Device Access i zapisuje zmianę. Zmiany działają natychmiast. Dozwolone źródło musi nadal docierać do portalu, a niedozwolone nie. Jeśli test pozytywny zawiedzie, należy przywrócić poprzednie WAN przez drugą drogę. Instrukcja Device Access opisuje inne warianty.

Ograniczenie do krajów ma sens, gdy grupa użytkowników jest jasno określona geograficznie. Nie jest jednak kontrolą tożsamości: podróżujący, sieci komórkowe, dostawcy VPN i błędnie przypisana geolokalizacja IP mogą zablokować prawidłowych użytkowników. Dostęp z całego świata wymaga zatem szczególnie silnej ochrony tożsamości, MFA, rejestrowania i procesu przeglądu.

Ważnym wyjątkiem jest skonfigurowany na firewallu web proxy. SFOS traktuje jego żądania HTTP i HTTPS jako wewnętrzne, a nie jako ruch ze strefy. Użytkownicy z dostępem do proxy mogą więc osiągnąć VPN Portal i inne usługi HTTP firewalla, nawet gdy Device Access wyłącza je dla ich strefy. Jeśli proxy jest używane, test negatywny wykonuje się raz bezpośrednio i raz w sposób potwierdzony przez proxy jawne lub transparentne. Device Access nie może zablokować tej wewnętrznej ścieżki według strefy; w razie potrzeby trzeba ograniczyć sam dostęp do proxy.

Prawidłowa konfiguracja Login Security i portów

W Administration > Admin and user settings > Login security należy włączyć Block login i wypełnić trzy pola: liczbę prób, przedział czasu i czas blokady. Pięć prób w 60 sekund i pięć minut blokady to wyłącznie przykład, nie uniwersalna wartość domyślna Sophos ani ustawienie produkcyjne do wdrożenia bez pilota. Wartości dobiera się do liczby użytkowników, helpdesku i współdzielonego NAT. Test wykonuje się z kontrolowanego IP przy otwartej drugiej drodze administracyjnej.

Blokada działa dla źródłowego IP i po osiągnięciu progu obejmuje wszystkie usługi, w tym WebAdmin, CLI, VPN Portal i User Portal. Za NAT biura, hotelu lub operatora może jednocześnie dotknąć wielu użytkowników i administratora. Testu negatywnego nie wykonuje się przez jedyną drogę administracyjną.

W ataku rozproszonym Block login jest tylko jedną warstwą ochrony. Wiele botów może pojedynczo pozostać poniżej progu. Błędy CAPTCHA nie są liczone jako nieudane logowania i nie uruchamiają blokady.

Wykluczanie współdzielenia portów

Należy porównać te dwie wartości:

• Administration > Admin and user settings > VPN portal HTTPS port, domyślnie TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, domyślnie 8443 z TCP lub UDP

Jeśli VPN Portal i SSL VPN używają tego samego portu i tego samego protokołu, ustawienia Login Security nie działają. Ponadto VPN Portal staje się dostępny ze stref dozwolonych dla SSL VPN, nawet jeśli jest tam wyłączony w Device Access.

Kombinacja musi być zatem jednoznaczna. Samo przeniesienie na losowy port nie zapobiega atakowi. Jeśli port VPN Portal zostanie zmieniony, trzeba dostosować adres URL portalu, Entra Redirect URI i wartość vpn_portal_port dla Sophos Connect Provisioning, a następnie ponownie przetestować z użytkownikiem pilotażowym.

Ochrona uwierzytelniania i dotkniętych kont

W Authentication > Services > VPN portal authentication methods pozostawia się tylko potrzebne serwery. Nieużywana ścieżka lokalna, AD, LDAP lub RADIUS pozwala na zbędne próby wobec kolejnego katalogu. Co najmniej jeden serwer musi pozostać wybrany. VPN Portal nie obsługuje RADIUS z challenge-based MFA, więc nie należy planować go jako MFA portalu.

MFA nie zapobiega każdej nieudanej próbie, ale ogranicza ryzyko, że wystarczy znane lub odgadnięte hasło. MFA dla VPN Portal i Remote Access opisuje konfigurację dla użytkowników lokalnych i katalogowych. W przypadku Microsoft Entra ID SSO należy dodatkowo sprawdzić Entra MFA, Conditional Access, Sign-in Logs i Risk Events.

Prawdziwego użytkownika z podejrzanymi nieudanymi próbami należy sprawdzić nie tylko na firewallu:

1. Sprawdzić blokady kont i udane logowania we właściwym Identity Provider.
2. Zakończyć nieznane udane sesje zgodnie z procesem obsługi incydentów.
3. Zresetować hasło i zarejestrowane metody MFA, jeśli istnieje podejrzenie przejęcia konta.
4. Sprawdzić członkostwo w grupach i uprawnienie Remote Access.
5. Dopiero potem za pomocą udokumentowanego logowania pilotażowego sprawdzić, czy prawidłowy dostęp znów działa.

VPN Portal można usunąć z WAN tylko wtedy, gdy żaden wymagany proces od niego nie zależy. Provisioning .pro łączy się przez vpn_portal_port. Przy Entra SSO adres URL używany przez VPN Portal i Remote Access oraz zarejestrowany Redirect URI muszą odpowiadać opublikowanej bramie i portowi. Ręcznie rozprowadzane .ovpn mogą pozwolić na węższą publikację, ale zmiany profilu wymagają kontrolowanej dystrybucji i testów.

Dodawanie Threat Feeds dla znanych źródeł

Sophos Firewall może porównywać znane złośliwe źródłowe IP także w ruchu do własnych usług, w tym VPN Portal, WebAdmin i VPN. Według pomocy SFOS 22 dotyczy to MDR, NDR Essentials i Third-Party Threat Feeds, ale nie Sophos X-Ops Threat Feeds. Utrzymywany Third-Party Feed IPv4 jest więc dodatkową warstwą dla znanych źródeł.

Konfigurowanie Threat Feeds na Sophos Firewall opisuje pełną konfigurację, wymagania licencyjne, pilotaż Monitor, tryb Block, False Positives oraz feedy Cybora przetestowane przez Avanet. W przypadku nowego feedu nadal należy sprawdzić pobieranie i zawartość IoC, najpierw obserwować działanie, a dopiero potem w kontrolowany sposób włączyć blokowanie.

Aby trafienia pojawiały się lokalnie w Log Viewer, należy włączyć Local reporting dla Active threat response w System services > Log settings. XGS 87/87w i 107/107w nie obsługują lokalnego raportowania; używa się Sophos Fusion lub serwera Syslog.

Threat Feeds nie zastępują ACL ani silnego uwierzytelniania. Porównują tylko adresy z listy. Third-Party Feeds przyjmują pojedyncze IPv4, ale nie IPv6, zakresy IP ani adresy sieci; nowe adresy botów pozostają dostępne. False Positive może zablokować prawidłowych użytkowników. Nowy feed uruchamia się w Monitor, sprawdza błędy i nieoczekiwane trafienia, a dopiero potem przełącza na Block. Threat Exclusion działa dla wszystkich modułów Active Threat Response, więc musi być wąski, uzasadniony i czasowy. Trafienia i wyjątki są regularnie przeglądane.

Przy powrocie zmieniony feed otrzymuje poprzednią action; nowy feed wyłącza się bez niekontrolowanego usuwania. Następnie sprawdza się, czy źródło dotknięte False Positive ponownie osiąga portal i czy pozostałe zabezpieczenia działają.

Kontrola skuteczności i dalsze monitorowanie

Po każdej zmianie należy powtórzyć ten sam zdefiniowany test:

1. Dozwolone źródło zewnętrzne osiąga VPN Portal, a użytkownik pilotażowy może się zalogować.
2. Niedozwolone źródło nie może już osiągnąć portalu.
3. VPN Portal i SSL VPN używają jednoznacznej kombinacji portu i protokołu.
4. Kontrolowana nieudana próba pojawia się w Log Viewer z oczekiwanym źródłowym adresem IP i metodą uwierzytelniania.
5. Sophos Connect Provisioning, Entra SSO i właściwy tunel VPN nadal działają.
6. Trafienia Threat Feed pojawiają się w skonfigurowanym miejscu logowania, jeśli ta warstwa jest używana.
7. W ustalonym okresie obserwacji nie pojawiają się nowe blokady AD lub Entra ani nieznane udane logowania.

Jeśli test zawiedzie, najpierw przywraca się tylko ostatnią zmianę do udokumentowanej poprzedniej wartości. Może to być action feedu, serwer, Block login, port i Redirect URI albo Device Access. Przy Device Access najpierw przywraca się stare WAN przez drugą drogę, a potem usuwa nowy wyjątek ACL. Przy porcie przywraca się razem port i protokół, .pro, URL portalu i Redirect URI, po czym powtarza test dozwolony i niedozwolony.

W celu długoterminowego wykrywania należy wysyłać logi uwierzytelniania do SIEM. Przydatne alerty uwzględniają nie tylko liczbę błędów, ale również wiele różnych źródeł przeciwko temu samemu użytkownikowi, wiele nazw użytkowników z jednego źródła oraz udane logowania po serii nieudanych prób.

Często zadawane pytania