Internetowe systemy dostępowe: ryzyko, którego nie załatasz wystarczająco szybko

Co liczy się jako internetowy system dostępowy

Ta kategoria jest szersza niż „VPN". To każda usługa, która z założenia nasłuchuje połączeń z otwartego internetu, tak by zdalna osoba lub system mogły dotrzeć do czegoś wewnętrznego. W większości środowisk obejmuje to kilka z poniższych:

• Bramki VPN i portale SSL VPN, takie jak funkcje zdalnego dostępu w Fortinet FortiGate, Palo Alto GlobalProtect, Cisco AnyConnect, Check Point, SonicWall i Citrix Gateway.
• Zdalny dostęp desktopowy: RDP wystawione bezpośrednio albo RD Gateway przed nim.
• Webmail i front-endy współpracy, w tym Microsoft Exchange i Outlook Web Access.
• Front-endy dostępu do aplikacji i load balancingu, takie jak F5 APM.
• Interfejsy zarządzania i administracyjne wszystkich powyższych, które czasem trafiają do internetu przez przypadek, a nie zamiar.

Wspólną cechą tych systemów jest to, co czyni je jednocześnie użytecznymi i niebezpiecznymi. Są zaprojektowane, żeby dało się je znaleźć. Atakujący nie musi zdobyć przyczółka gdzie indziej i dopiero z niego przejść do nich; one już nasłuchują, z publicznym adresem, czekając na połączenie. Usługi skanujące cały internet katalogują je nieprzerwanie. Pytanie rzadko brzmi, czy twoja bramka da się znaleźć. Brzmi, co się dzieje, gdy już zostanie znaleziona.

Okno ekspozycji: luka, której nie zamkniesz wystarczająco szybko

Każdy internetowy system dostępowy niesie powtarzające się ryzyko, które nie ma nic wspólnego z tym, jak dobrze jest skonfigurowany. To czas między ujawnieniem podatności w danym produkcie a przetestowaniem i wdrożeniem poprawki przez twoją organizację. Nazwijmy to oknem ekspozycji. W tym oknie system jest osiągalny, słabość jest znana atakującym, a poprawka jeszcze nie działa. Zadaniem atakującego jest działać wewnątrz tego okna szybciej, niż ty potrafisz je zamknąć.

Trzy rzeczy sprawiają, że okno trudno zamknąć szybko. Testowanie i wdrażanie łatki na produkcyjnej bramce dostępowej jest zakłócające, bo to bramka, na której działanie liczą wszyscy, więc zmiany są planowane ostrożnie, a nie stosowane w chwili, gdy się pojawią. Masowe skanowanie oznacza, że nowo ujawniona podatność jest sondowana w całym internecie w ciągu godzin, nie tygodni, więc o okno toczy się walka niemal natychmiast. A zero-day całkowicie odwraca oś czasu: podatność jest wykorzystywana, zanim dostawca opublikuje poprawkę, co oznacza, że w pełni zaktualizowane urządzenie wciąż jest narażone, bo nie ma jeszcze niczego do zainstalowania.

To jest niewygodna część tego ryzyka. Sumienne patchowanie skraca okno, ale nie potrafi go wyeliminować, a przeciwko zero-dayowi nie istnieje jako obrona w ogóle, dopóki dostawca nie nadrobi zaległości. Każda uczciwa ocena internetowego systemu dostępowego musi zakładać, że w pewnym momencie będzie on jednocześnie osiągalny i podatny na wykorzystanie, i planować, ile to kosztuje, zamiast zakładać, że da się to załatać.

Co pokazuje FortiBleed

Warto zatrzymać się przy FortiBleed, bo to przypadek świeży, duży i niepasujący do schludnej historii „pojawiło się CVE, wszyscy załatali", którą większość ludzi wyobraża sobie, myśląc o bezpieczeństwie urządzeń brzegowych.

To była kampania operacyjna, a nie pojedyncza podatność. Według badaczy z Recorded Future i innych, którzy ją śledzili, aktorzy zagrożeń systematycznie wyciągali pliki konfiguracyjne z internetowych urządzeń FortiGate i łamali przechowywane w nich hashe poświadczeń, budując na skalę przemysłową bibliotekę zweryfikowanych, działających poświadczeń administracyjnych. W momencie ujawnienia nie było pilnej łatki, którą trzeba by wypuścić w pośpiechu, bo do tego momentu szkoda, biblioteka loginów, które już działały, była już zrobiona w toku miesięcy cichego zbierania. Wiele organizacji dowiedziało się o tym po raz pierwszy z listy, na której były ich własne urządzenia.

Ten kształt jest lekcją i uogólnia się daleko poza klientów Fortinet. Dwie cechy mają znaczenie dla każdej organizacji, która prowadzi internetowy system dostępowy. Po pierwsze, produktem końcowym były działające poświadczenia. Atakujący nie musieli pokonać szyfrowania ani nawet, w wielu przypadkach, wykorzystywać świeżej luki w chwili dostępu; zbudowali bibliotekę loginów, które już działały, pochodzących z ekspozycji konfiguracji, powtórnie używanych haseł i brute force. Bramka chroniona silną polityką haseł jest słabo chroniona, jeśli hash hasła już został wyciągnięty i złamany offline. Po drugie, skala wzięła się stąd, że te systemy w ogóle były internetowe. Te same urządzenia, które pozwalają pracownikom pracować zdalnie, pozwalają atakującemu enumerować, celować i zbierać na skalę całego internetu. Ekspozycja, która czyniła je użytecznymi, jest tym, co uczyniło tę kampanię możliwą.

Standardowe zalecenia naprawcze dla FortiBleed, natychmiastowa rotacja wszystkich poświadczeń bramek i VPN, wymuszenie MFA na dostępie zdalnym i administracyjnym oraz przegląd logów pod kątem nietypowych sesji, są słuszne i konieczne. Są też reaktywne. To jest to, co robisz po tym, jak kampania już zebrała twoje poświadczenia. Trwalsze pytanie brzmi, co zmniejszyłoby cel, zanim którekolwiek z tego było potrzebne.

Dlaczego patchowanie i MFA pomagają, ale nie kończą roboty

Patchowanie i uwierzytelnianie wieloskładnikowe są oba niezbędne i nic z tego, co następuje, nie jest argumentem przeciwko nim. Chodzi o coś węższego: każde z nich zostawia realną lukę, a te luki pokrywają się dokładnie z warunkami, których szukają atakujący.

Patchowanie jest ograniczone opisanym wyżej oknem ekspozycji. Zależy od tego, czy poprawka istnieje, czy wiesz, że jej potrzebujesz, i czy potrafisz wdrożyć ją szybko na wrażliwym systemie produkcyjnym. Przeciwko zero-dayowi zawodzi pierwszy warunek. Przeciwko wolnemu procesowi zarządzania zmianą zawodzi trzeci.

Uwierzytelnianie wieloskładnikowe podnosi koszt użycia skradzionego hasła i powinno działać na każdej ścieżce dostępu zdalnego i administracyjnego bez wyjątków. Ale siedzi na etapie logowania, a znacząca część ataków na systemy dostępowe albo dociera do etapu logowania w stanie, w którym MFA nic nie pomaga, albo omija go w inny sposób. Podatności przed-uwierzytelnieniem pozwalają atakującemu wykorzystać urządzenie, zanim w ogóle pojawi się prompt logowania. Przejęcie sesji i kradzież tokenów pozwalają atakującemu jechać na już uwierzytelnionej sesji, zamiast logować się od nowa. Kampanie zbierania poświadczeń takie jak FortiBleed idą po dostęp administracyjny i konfiguracyjny, gdzie pokrycie MFA jest często najsłabsze. MFA zwęża drzwi. Nie przesuwa tych drzwi z ulicy.

Dlatego najbardziej aktywne grupy ransomware wciąż wracają do publicznych bramek dostępowych. Skradzione poświadczenia VPN były wektorem początkowego dostępu w 48% ataków ransomware śledzonych w trzecim kwartale 2025 roku, w górę z 38% w poprzednim kwartale, według kwartalnego raportu o zagrożeniach Beazley Security, który odnotował, że te grupy rutynowo celowały w publiczne bramki VPN przez credential stuffing, brute force i wykorzystanie znanych podatności urządzeń. Punkt wejścia jest spójny, bo spójna jest struktura: system, który musi być osiągalny, który po przejściu przez niego daje szeroki dostęp i który można osiągnąć i zaatakować, zanim uwierzytelnienie w ogóle wejdzie w grę.

Ruch strukturalny: zmniejsz to, co osiągalne przed logowaniem

Jeśli patchowanie i MFA nie potrafią w pełni zamknąć okna, pozostałą dźwignią jest wielkość celu. Wszystko, co atakujący może osiągnąć przed uwierzytelnieniem, to powierzchnia ataku. Wszystko, czego nie widzi, nią nie jest.

Są trzy trwałe sposoby, żeby uczynić system dostępowy mniejszym celem, i one się sumują:

• Uczyń systemy dostępowe niewidocznymi dla ruchu nieuwierzytelnionego. Zamiast bramki, która odpowiada na każde połączenie z internetu i pokazuje stronę logowania każdemu, system dostępowy jest ukryty za warstwą, która ujawnia go tylko ruchowi już zweryfikowanemu jako legalny. Atakujący skanujący internet nie znajduje niczego do zaatakowania, bo bramka w ogóle na niego nie odpowiada. To model stojący za ZTNA i identity-aware proxy, oraz za szerszą kategorią czasem opisywaną jako ukrywanie albo cloaking systemów dostępowych. Efekt jest taki, że przyszły zero-day w leżącej pod spodem bramce jest dużo mniej groźny, bo nieuwierzytelniony internet nie potrafi dosięgnąć bramki, żeby go wykorzystać.
• Przyznawaj dostęp do konkretnych aplikacji, nie do sieci. Tradycyjny VPN umieszcza zdalnego użytkownika wewnątrz sieci wewnętrznej, gdzie jedna skradziona sesja może dosięgnąć znacznie więcej niż tę jedną aplikację, której potrzebował użytkownik. Dostęp per aplikacja, definiująca idea zero trust network access, ogranicza skompromitowany login wyłącznie do zasobów, do których dana tożsamość była uprawniona. Jest to szczegółowo omówione w przewodniku zero trust kontra VPN; istotne tu jest to, że zmniejsza to konsekwencje naruszenia systemu dostępowego.
• Segreguj według tego, czego nie da się łatwo zmienić. Niektóre systemy dostępowe da się wycofać albo przenieść na nowoczesny odpowiednik dostarczany z chmury. Innych nie da się, bo stoją przed legacy aplikacją, systemem regulowanym albo infrastrukturą, którą kosztowne lub ryzykowne jest ruszać. To one powinny być owinięte pierwsze: systemy, których nie da się szybko wymienić albo załatać na żądanie, to dokładnie te systemy, w których zmniejszenie ekspozycji przed logowaniem daje największy zwrot.

Nic z tego nie zastępuje patchowania ani MFA. To zmienia stawkę, gdy patch się spóźnia, a MFA zostaje obejście. Bramka, której otwarty internet nie widzi, nie jest bramką, którą kampania na skalę całego internetu może zebrać masowo.

Co faktycznie zrobić

Praktyczna kolejność, w przybliżonym porządku priorytetu, która skaluje się od jednej bramki do dużego środowiska:

Po pierwsze, zbuduj inwentarz. Wypisz każdy system osiągalny z internetu, który daje dostęp, w tym interfejsy zarządzania twoich urządzeń, które są tymi najczęściej wystawionymi bez niczyjej decyzji, żeby je wystawić. Nie zmniejszysz powierzchni, której nie zmapowałeś, a większość zespołów znajduje na tej liście przynajmniej jedną rzecz, po której nie spodziewali się, że jest publiczna.

Po drugie, w pełni pokryj podstawy na każdej pozycji. Uwierzytelnianie wieloskładnikowe na całym dostępie zdalnym i administracyjnym, bez wyjątków dla kont serwisowych czy administracyjnych. Zdefiniowana, szybka ścieżka patchowania dla tych systemów konkretnie, osobna od twojego ogólnego rytmu patchowania, bo internetowa bramka dostępowa nie powinna czekać na comiesięczne okno. Rotacja poświadczeń, gdy urządzenie jest zamieszane w ujawnioną kampanię, przy założeniu, że ekspozycja już się wydarzyła.

Po trzecie, zmniejsz powierzchnię. Dla każdego internetowego systemu dostępowego zapytaj, czy musi odpowiadać całemu internetowi, czy tylko zweryfikowanym użytkownikom, i czy daje dostęp do sieci, czy do pojedynczej aplikacji. Przenieś te systemy, które możesz, na dostęp per aplikacja, domyślnie ukryty. Dla tych, których nie możesz przenieść, postaw przed nimi warstwę cloakingu, tak żeby leżący pod spodem system przestał być bezpośrednio osiągalny.

Po czwarte, zaplanuj okno, którego nie zamkniesz. Załóż, że w pewnym momencie jeden z tych systemów będzie jednocześnie podatny i osiągalny. Wiedz, które zaszkodziłyby najbardziej, wiedz, jak wykryjesz na nich nietypowy dostęp, i wiedz, co wyłączysz i zrotujesz, jeśli zero-day w jednym z nich wypłynie jutro. Dla organizacji w zakresie ram takich jak DORA czy NIS2 ta zdolność wykazania kontroli nad dostępem zdalnym i uprzywilejowanym to też coraz częściej coś, o co audytorzy i klienci pytają wprost.

Uczciwe podsumowanie jest takie, że internetowe systemy dostępowe to ryzyko, którym zarządzasz, a nie ryzyko, które usuwasz. Patchowanie skraca okno ekspozycji, MFA podnosi koszt skradzionego loginu, a zmniejszenie tego, co osiągalne przed uwierzytelnieniem, zmniejsza cel tam, gdzie te dwa pierwsze nie potrafią w pełni chronić. To połączenie sprawia, że jeden zły tydzień, zero-day albo kampania zbierania poświadczeń, nie zamienia się w naruszenie.

Źródła

• Recorded Future, Critical FortiBleed Campaign Exposing Credentials for 73,932 FortiGate Systems · https://www.recordedfuture.com/blog/critical-fortibleed-campaign (campaign scope, mechanism, device counts)
• CSO Online, FortiBleed campaign exposes 75,000 Fortinet firewalls worldwide · https://www.csoonline.com/article/4186790/fortibleed-campaign-exposes-75000-fortinet-firewalls-worldwide.html (secondary reporting, timeline, discovery)
• Arctic Wolf, Active FortiBleed Campaign Impacting Fortinet Devices Across 194 Countries · https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/ (scale, affected geographies, remediation guidance)
• Beazley Security, Quarterly Threat Report: Third Quarter 2025 · https://beazley.security/insights/quarterly-threat-report-third-quarter-2025 (compromised VPN credentials as initial access vector in 48% of Q3 2025 ransomware attacks, up from 38%; ransomware groups targeting public VPN gateways)
• NIST Special Publication 800-207, Zero Trust Architecture · https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf (per-application access and the removal of implicit trust based on network location)