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.

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. W systemie SIEM używa się odpowiednio pól Syslog log_component z wartością VPN Portal Authentication oraz status z wartością Failed; dokładna składnia zapytania zależy od używanego 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 Central. Następnie najpierw tworzy się wąski wyjątek:

1. W Administration > Device access > Local service ACL exception rule kliknąć Add.
2. 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łę.

W stanie docelowym VPN Portal nie jest ogólnie włączony dla WAN w macierzy Device Access, lecz jest dostępny wyłącznie przez wymagane wyjątki ACL. Zmiany Device Access obowiązują natychmiast; dlatego bezpieczne przełączenie z testem pozytywnym, testem negatywnym i drogą powrotu opisano szczegółowo w instrukcji Device Access.

Następnie należy sprawdzić wyjątek z dozwolonego i niedozwolonego źródła zewnętrznego. Dopóki aktywne jest szerokie zezwolenie WAN, sam udany test pozytywny nie dowodzi, że wyjątek ogranicza dostęp zgodnie z oczekiwaniami.

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.

Prawidłowa konfiguracja Login Security i portów

W Administration > Admin and user settings > Login security należy włączyć Block login. Sophos Firewall Health Check przyjmuje jako punkt wyjścia pięć nieudanych logowań w ciągu 60 sekund i blokadę trwającą pięć minut. Właściwa wartość produkcyjna zależy jednak od liczby użytkowników, procesu helpdesku i współdzielonych źródeł NAT.

Blokada działa dla źródłowego adresu IP i po osiągnięciu progu dotyczy nie tylko VPN Portal. WebAdmin, CLI, VPN Portal i User Portal również przestają otwierać się z tego źródła. Biuro, hotel lub NAT dostawcy może przez to jednocześnie dotknąć kilku prawidłowych użytkowników i administratora. Dlatego testu negatywnego nigdy nie wykonuje się z jedynej dostępnej drogi administracyjnej.

W ataku rozproszonym Block login jest tylko jedną warstwą ochrony. Wiele botów może pojedynczo pozostać poniżej progu.

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 powinny pozostać aktywne tylko serwery, których rzeczywiście wymaga bieżąca koncepcja Remote Access. Nieużywana ścieżka lokalna, AD, LDAP lub RADIUS nie daje żadnych korzyści, ale może umożliwić sprawdzanie kolejnych danych logowania w publicznym 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 całkowicie usunąć z WAN tylko wtedy, gdy żaden wymagany proces od niego nie zależy. Entra SSO i provisioning przez .pro używają portu portalu. Przy ręcznie dystrybuowanych plikach .ovpn może być możliwy bardziej restrykcyjny proces publikacji, ale zmiany profilu muszą być wtedy rozprowadzane i testowane w kontrolowany sposób.

Dodawanie Threat Feeds dla znanych źródeł

Sophos Firewall może również porównywać znane złośliwe źródłowe adresy IP w ruchu skierowanym do systemu i usług takich jak VPN Portal, WebAdmin oraz VPN. Utrzymywane feedy IPv4 nadają się jako dodatkowa warstwa ochrony.

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 Active Threat Response pojawiały się w Log Viewer, w System services > Log settings dla Active threat response musi być włączona opcja Local reporting.

Threat Feeds nie zastępują ACL ani silnej ochrony tożsamości. Wykrywają tylko zawarte wskaźniki, Third-Party Feeds obsługują obecnie IPv4 dla IoC źródłowych adresów IP, a nowy lub niewymieniony adres IP bota pozostaje dostępny. Z drugiej strony False Positive może zablokować prawidłowego użytkownika, dlatego potrzebny jest udokumentowany proces wyjątków i przeglądu.

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 logu Active Threat Response, jeśli ta warstwa ochrony jest używana.
7. Nie występują blokady kont AD lub Entra ani nieznane udane logowania.

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