VPN Hardening Cookbook

Dlaczego to ma znaczenie?

VPN jest bramą do firmowej sieci – ułatwia pracę zdalną, ale dla atakujących stanowi atrakcyjny cel. Wystarczy jedno przejęte konto lub luka w VPN, by intruz zyskał dostęp do zasobów wewnętrznych. Przykładowo, głośny atak na Colonial Pipeline w 2021 rozpoczął się od wykradzionych danych dostępowych VPN bez wymuszonego MFA, co sparaliżowało krytyczną infrastrukturę. To pokazuje, iż kompromitacja VPN niesie poważne konsekwencje – od wycieku danych po zatrzymanie działalności firmy.

Statystyki potwierdzają skalę problemu. W listopadzie 2025 odnotowano gwałtowny wzrost skanowania portali Palo Alto GlobalProtect – 2,3 miliona prób w ciągu 5 dni. Takie masowe kampanie wskazują, iż botnety non-stop obierają na cel popularne VPN-y. Co ważne, analiza GreyNoise wykazała, iż w 80% przypadków skoki skanowania poprzedzają ujawnienie nowej podatności. Innymi słowy: zanim dowiemy się o luce „zero-day”, atakujący już mogą jej aktywnie szukać. W 2025 wykryto np. falę ataków na GlobalProtect łączącą podatności CVE-2025-0108 i CVE-2025-0111 – były one wykorzystywane zanim wielu administratorów zdążyło załatać system. Również Fortinet doświadczał krytycznych luk (jak CVE-2023-27997) w swoim SSL-VPN, co dowodzi iż aktualność systemu VPN jest kluczowa.

Nie można też liczyć wyłącznie na domyślne mechanizmy ochronne. Owszem, urządzenia zwykle mają wbudowane podstawy (np. blokada konta po kilku błędnych hasłach), ale sprytni przeciwnicy łatwo je obejdą. Doświadczeni atakujący rozproszą próby logowania na wiele adresów IP i będą działać wolno, by nie wywołać blokady lub DoS. Mogą używać sieci proxy/tor, przez co klasyczne reguły „3 nieudane logowania = ban” nie zadziałają. Dlatego samo poleganie na domyślnych ustawieniach to za mało – potrzebne jest wielowarstwowe „utwardzenie” VPN (hardening). Użytkownicy VPN to łakomy kąsek dla cyberprzestępców, bo przejęcie ich kont otwiera dostęp do całej sieci. Musimy więc traktować VPN jak system najwyższej krytyczności: maksymalnie utrudnić do niego dostęp niepowołanym oraz wykryć natychmiast wszelkie próby nadużyć.

Aktualizacje i łatki VPN

Pierwszym krokiem hardeningu VPN jest zapewnienie, iż samo oprogramowanie/aplikacja VPN nie zawiera znanych luk bezpieczeństwa. Producenci regularnie wydają łatki – ignorowanie ich to proszenie się o kłopoty. Aktualizuj firmware/aplikacje VPN na bieżąco i śledź biuletyny bezpieczeństwa (Fortinet PSIRT, Palo Alto Security Advisories, ogłoszenia OpenVPN etc.). Jak wspomniano, atakujący masowo skanują VPN-y w poszukiwaniu niezaktualizowanych instancji. GreyNoise podkreśla, iż nagłe skoki aktywności wokół VPN często zwiastują pojawienie się nowej podatności. jeżeli Twój system jest niezałatany, istnieje duże ryzyko, iż zostanie trafiony gotowym exploitem zanim zdążysz zareagować.

Dobrym zwyczajem jest subsrypcja alertów (np. mailing producenta, RSS z CVE dla Twojego urządzenia). Gdy pojawia się krytyczna łatka – wdrażaj ją asap (po weryfikacji na stagingu). W ostatnich latach wiele poważnych luk VPN było aktywnie wykorzystywanych: np. w 2023 krytyczna dziura w FortiOS SSL-VPN umożliwiała zdalne RCE bez uwierzytelnienia, a w 2024/2025 kolejne exploity dotknęły GlobalProtect. CISA dodaje takie błędy do katalogu KEV (Known Exploited Vulnerabilities), co oznacza obowiązek patchowania w instytucjach rządowych. Twoja organizacja także powinna traktować je priorytetowo.

Stosuj również zalecenia producenta odnośnie konfiguracji. Większość dostawców publikuje poradniki hardeningowe – warto przez nie przejść punkt po punkcie. Na przykład Fortinet udostępnia listę domyślnych zabezpieczeń SSL-VPN (rozłączenie bezczynnych sesji po 5 min, opóźnienie 30s przy niekompletnym logowaniu, blokada konta po 2 nieudanych próbach na 60s). Znajomość tych ustawień pozwoli Ci świadomie je dostroić lub zaostrzyć. Podobnie Palo Alto zaleca regularnie aktualizować treści dynamiczne (Content Updates) – zawierają one sygnatury wykrywania exploitów atakujących VPN. jeżeli używasz OpenVPN – monitoruj jego oficjalny blog/GitHub; często pojawiają się tam łatki zwiększające bezpieczeństwo protokołu. Pamiętaj też o usuwaniu/wyłączaniu nieużywanych funkcji VPN. Przykład: jeżeli urządzenie oferuje zarówno SSL-VPN jak i IPSec, a korzystasz tylko z jednego – wyłącz ten zbędny. Mniej usług to mniejsza powierzchnia ataku i mniej rzeczy do aktualizowania.

Silne uwierzytelnianie (MFA i certyfikaty)

Nawet najlepiej załatany system VPN nie obroni nas, jeżeli uwierzytelnianie użytkowników będzie słabym ogniwem. Silne uwierzytelnianie to absolutna podstawa. Co to oznacza w praktyce?

Po pierwsze, wymuś MFA (Multi-Factor Authentication) dla wszystkich użytkowników VPN. Hasło to za mało – drugi składnik (aplikacja OTP typu Google Authenticator, YubiKey, SMS lub push) znacząco zwiększa trudność ataku. Większość komercyjnych rozwiązań ma integrację z MFA: FortiGate obsługuje tokeny sprzętowe i TOTP, Palo Alto GlobalProtect zintegrujesz z serwisami typu Duo czy Azure MFA (np. przez SAML), OpenVPN również pozwala na pluginy MFA lub RADIUS. choćby jeżeli hasło wycieknie, napastnik bez dodatkowego tokenu wciąż nie wejdzie. Polityka haseł też musi być mocna – unikatowe, długie hasła, najlepiej zarządzane centralnie (np. w AD). Stosuj zalecenia NIST dotyczące tworzenia i przechowywania haseł i zawsze wymagaj MFA.

Po drugie, rozważ uwierzytelnianie oparte o certyfikaty klienta jako uzupełnienie. W wielu systemach da się skonfigurować VPN tak, iż użytkownik musi posiadać certyfikat X.509 na swoim urządzeniu (wydany przez Twoją firmę) oraz poprawne hasło, aby się połączyć. To kolejna bariera – atakujący musiałby nie tylko znać poświadczenia, ale też wykraść certyfikat (np. z laptopa pracownika). FortiGate wspiera tryb wymagający certyfikatu klienta TLS, podobnie OpenVPN (wymaga pliku .ovpn z sekcją <cert>). GlobalProtect również pozwala na konfigurację certyfikatów (Certificate Profile) i mapowanie ich do użytkowników. Wdrożenie cert-auth oznacza trochę zachodu (wydawanie i zarządzanie certyfikatami), ale znacząco utrudnia nieautoryzowany dostęp.

Kolejnym elementem jest kontekst uwierzytelnienia. Nie każde logowanie z poprawnymi danymi powinno być automatycznie wpuszczone – zastanów się nad politykami typu „risk-based authentication”. Przykłady: logowanie z nieznanego kraju albo o nietypowej porze może wymagać dodatkowej weryfikacji lub w ogóle zostać zablokowane. W GlobalProtect istnieje mechanizm Host Information Profile (HIP): sprawdza on stan urządzenia (czy ma aktualny antywirus, łatki, włączony firewall itp.) zanim przyzna dostęp. Warto włączyć takie mechanizmy zdrowia urządzeń – jeżeli ktoś próbuje się logować z niezaktualizowanego lub obcego urządzenia, lepiej dmuchać na zimne. Analogicznie, rozwiązania typu Zero Trust Network Access (ZTNA) idą jeszcze dalej: traktują każde połączenie jako nie w pełni zaufane i wymagają ciągłej walidacji kontekstu (urządzenia, użytkownika, aplikacji). jeżeli masz możliwość, rozważ stopniowe wdrażanie zasad Zero Trust przy dostępie zdalnym.

Ważnym aspektem obrony przed brute-force jest blokowanie po błędnych logowaniach, ale z głową. Ustaw limit prób logowania i czas blokady konta/IP tak, by utrudnić masowe zgadywanie haseł. FortiGate domyślnie blokuje konto SSL-VPN po 2 nieudanych próbach na 60 sekund. To dobra baza, choć krótkotrwała – możesz te wartości zwiększyć. Poniżej przykład zmiany ustawień FortiGate via CLI, by pozwolić na max 3 próby i blokować dalsze logowanie na 5 minut:

# FortiGate CLI – konfiguracja limitu logowań SSL-VPN config vpn ssl settings set login-attempt-limit 3 # maks 3 proby logowania set login-block-time 300 # blokada 300s (5 min) po przekroczeniu limitu end

Pamiętaj, iż zbyt agresywne blokady mogą powodować problemy (frustracja użytkowników wpisujących błędnie hasło). Znajdź balans – np. dłuższa blokada po serii kilkunastu nieudanych prób rozłożonych w czasie. W systemach zintegrowanych z Active Directory możesz polegać na polityce blokady kont AD. jeżeli używasz rozwiązania open-source na Linuxie, warto wdrożyć mechanizm Fail2Ban – będzie on monitorował logi (np. /var/log/openvpnas.log) i automatycznie dodawał do iptables adresy IP, z których odnotowano zbyt wiele nieudanych logowań. To w praktyce działa jak rozproszony „lockout” na źródło ataku. Pamiętaj jednak o ostrzeżeniu z poprzedniej sekcji: rozproszone ataki z wielu IP mogą nie trafić w próg blokady, dlatego dodatkowo trzeba obserwować łączną aktywność (o tym za chwilę w sekcji monitoringu).

Na koniec warto wspomnieć o SSO i tokenach w kontekście VPN. jeżeli Twój VPN korzysta z federacji (np. logowanie SAML do Azure AD Okta itp.), upewnij się, iż tokeny sesyjne (JWT) mają odpowiednie zabezpieczenia – powinny być podpisane silnym kluczem i krótko ważne. Dostęp VPN zwykle i tak wymaga odpalenia klienta, ale np. portal przeglądarkowy VPN może polegać na tokenie SAML – tu obowiązują te same reguły bezpieczeństwa co przy aplikacjach webowych (zgodnie z OWASP). Nie dopuszczaj do sytuacji, w której token istotny jest np. przez wiele godzin bez dodatkowej weryfikacji tożsamości.

Protokoły i szyfrowanie (TLSv1.3)

Konfiguracja protokołu VPN powinna odrzucać stary, podatny szrot kryptograficzny i używać jedynie nowoczesnych, sprawdzonych standardów. W kontekście SSL-VPN oznacza to TLS 1.3 (lub 1.2), a wyłączenie przestarzałych wersji TLS 1.0/1.1 oraz oczywiście SSLv3. Nowsze protokoły zapewniają lepsze mechanizmy negocjacji i bezpieczeństwo (np. TLS 1.3 eliminuje sporo słabości poprzedników). Podobnie w przypadku IPSec VPN – trzymaj się IKEv2 zamiast IKEv1, korzystaj z silnych algorytmów szyfrujących (AES-256, chociaż w wielu zastosowaniach wystarczy AES-128 GCM) i hashujących (SHA-256 lub lepsze, zamiast przestarzałego SHA-1). Ustaw również odpowiednie grupy DH (min. 2048-bit, a najlepiej krzywe eliptyczne typu ECDH). Wyłączenie starych szyfrów oznacza, iż starsze nieaktualizowane klienty mogą mieć problem – trudno, lepiej wymusić update klienta niż akceptować połączenia po staremu.

Lista szyfrów (cipher suites) – warto ją przeglądnąć i ustawić manualnie. Usuń wszystko co zawiera: RC4, DES, 3DES, MD5, anon (cipher bez uwierzytelnienia), EXPORT itd. Preferuj suite’y z Perfect Forward Secrecy (ECDHE) i silnym szyfrem (AES-GCM, CHACHA20). Przykładowo, dla OpenVPN możesz w pliku konfig wymusić tylko konkretną kombinację, np.:

# Fragment /etc/openvpn/server.conf tls-crypt /etc/openvpn/ta.key # klucz do uwierzytelniania pakietów TLS cipher AES-256-GCM # szyfrowanie symetryczne auth SHA256 # algorytm HMAC uwierzytelniania pakietów

W powyższym przykładzie tls-crypt dodaje dodatkową warstwę ochrony: wszystkie przychodzące pakiety TLS muszą być podpisane tajnym kluczem pre-shared, zanim serwer w ogóle odpowie. To oznacza, iż przypadkowy skaner portów choćby nie uzyska bannera OpenVPN – pakiety bez adekwatnego klucza są odrzucane (utrudnia to skanowanie i exploity). FortiGate czy Palo Alto zwykle mają domyślnie mocne szyfry, ale upewnij się w ustawieniach SSL/TLS Profile, iż nie dopuszczono np. TLS 1.0 dla kompatybilności z legacy klientem. GlobalProtect opiera się o TLS (portal i gateway) – w nowszych wersjach PAN-OS obsługuje TLS 1.3, warto go włączyć na portalach VPN dla przyszłości.

Dobrym nawykiem jest testowanie swojej konfiguracji SSL/TLS dzięki dostępnych narzędzi. Możesz użyć skanera Nmap z skryptem ssl-enum-ciphers, aby zobaczyć listę obsługiwanych protokołów i szyfrów. Jeszcze prostsze: użyj cURL lub openssl do wymuszenia starej wersji i sprawdź, czy zostanie odrzucona. Przykładowo, jeżeli wyłączyłeś TLS 1.0, poniższe polecenie zakończy się błędem protokołu:

$ curl -I -k --tlsv1.0 https://vpn.moje-firma.pl/ curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

Tak ma być – komunikat tlsv1 alert protocol version potwierdza, iż serwer odmówił negocjacji przestarzałego TLSv1.0. Podobnie przetestuj TLS 1.1. Możesz też skorzystać z serwisu SSL Labs (jeśli Twój portal VPN jest dostępny przez internet na porcie 443) – da Ci oceny i wskaże ewentualne słabości konfiguracyjne. Ocena A+ na SSL Labs dla portalu VPN to dobry znak, iż protokół jest należycie zahardendowany.

Kolejna kwestia to certyfikat TLS używany przez portal VPN. Nigdy nie pozostawiaj domyślnego, self-signed certyfikatu generowanego przez producenta! Atakujący mogliby wykorzystać taki cert do podszycia się pod Twój portal (łatwiej go namierzyć, bo wiele firm używa domyślnych nazw w CN). Zamiast tego, wgraj swój certyfikat od zaufanego CA (komercyjnego lub własnego, ale wtedy zadbaj by certyfikat root był w urządzeniach użytkowników). Dzięki temu użytkownicy nie będą dostawać ostrzeżeń o certyfikacie przy łączeniu (co uczy ich złych nawyków klikaj-dalej) i zapewnisz adekwatne szyfrowanie. Monitoruj datę ważności certyfikatu – wygasły cert na bramie VPN to nie tylko przestój dostępu, ale też potencjalne ryzyko (użytkownicy mogą próbować ignorować błędy i zostać przekierowani na fałszywy serwer). Rozważ włączenie HSTS na stronie logowania VPN (jeśli to portal webowy) – to drobiazg, ale wymusi połączenia HTTPS u klienta.

Podsumowując: twarde ustawienia kryptografii są fundamentem bezpieczeństwa VPN. Wyłącz to, co stare i słabe, zostaw to co nowe i mocne. Szyfruj wszystko (co oczywiste w VPN) i ufaj tylko poprawnym certyfikatom. Te zmiany nic nie kosztują, a zabezpieczają przed całym spektrum ataków typu downgrade, podsłuch czy brute-force kryptograficzne.

Ograniczanie powierzchni ataku (GeoIP, porty)

Kolejna porcja „przepisów” w naszym cookbooku dotyczy minimalizowania ekspozycji VPN. Chodzi o to, by Twoja usługa VPN była jak najmniej widoczna i dostępna tylko dla tych, co potrzeba. Im mniej potencjalnych atakujących może w ogóle próbować, tym lepiej.

Geo-blokady i filtry adresów IP

Jeżeli Twoi użytkownicy VPN łączą się wyłącznie z określonych państw lub sieci – skorzystaj z tego i zablokuj resztę. Wiele firewalli ma możliwość filtrowania ruchu po geolokalizacji (GeoIP). Przykładowo, FortiGate pozwala utworzyć obiekty adresowe typu „Country” i użyć ich w polityce firewall przed regułą wpuszczającą do SSL-VPN. Możesz więc zablokować całe regiony (np. kraje, z którymi Twoja firma nie ma żadnych relacji), zanim intruz z danego kraju w ogóle zobaczy stronę logowania. Podobnie da się blokować znane złe adresy IP – FortiGate ma funkcję External IP Lists/Threat Feeds do automatycznego pobierania listy adresów znanych botnetów i odcinania ich. jeżeli Twój VPN stoi za innym firewallem lub load balancerem, tam również możesz zastosować reguły ograniczające dostęp tylko z określonych źródeł. W skrajnym przypadku (bardzo restrykcyjne podejście) można wymagać VPN tylko z sieci firmowej (najpierw pracownik łączy się do biura przez IPsec site-to-site lub Zerotrust Access, a dopiero potem do zasobów – ale to już złożona architektura).

Niestandardowe porty i adresy

Domyślnie SSL-VPN nasłuchuje na standardowym porcie (443/TCP dla HTTPS). Zmiana portu na niestandardowy nie zwiększa realnie bezpieczeństwa (to przezroczysta „zasłona” – security by obscurity), ale odfiltrowuje najprostsze skrypty szukające otwartego 443. Jak to ujął pewien inżynier, „to nie poprawia bezpieczeństwa, ale zniechęca najmniej wytrwałych skanerów”. W praktyce: jeżeli zmienisz port np. na 10443, część automatów ominie Twój host myśląc, iż nie ma tam VPN (choć poważny skaner i tak przeskanuje wszystkie porty). Rozważ tę opcję, zwłaszcza jeżeli masz własną aplikację VPN. W OpenVPN możesz ustawić dowolny port (TCP/UDP 1194 jest domyślny – warto go zmienić, bo skanery znają ten port). W GlobalProtect zmiana portu portalu/gateway raczej nie wchodzi w grę (chodzi po 443, bo klient i tak celuje w domenę). FortiGate pozwala zmienić port portalowy (domyślnie 443, często widuje się przełożenie na 10443 lub 8443). Uwaga: jeżeli zmieniasz port, pamiętaj o fwalu i kliencie – użytkownicy muszą wiedzieć, żeby dopisać port w adresie lub dostać nowy plik konfig. To rozwiązanie traktuj jako uzupełniające, nie podstawowe – zawsze można przeskanować i znaleźć usługę na nietypowym porcie.

Wystawianie usługi VPN

Przemyśl, czy na pewno potrzebujesz ją wystawiać bezpośrednio na świat. Coraz popularniejsze jest korzystanie z pośredników typu broker Zero Trust (np. Cloudflare Access, Zscaler ZPA itp.), gdzie użytkownicy najpierw uwierzytelniają się do chmury, a dopiero stamtąd ruch tunelowany jest do Twojej sieci. Wtedy Twoje VPNy w ogóle nie są widoczne publicznie – minimalizuje to powierzchnię ataku niemal do zera (bo nie ma do czego strzelać). jeżeli jednak to przerost formy (koszt, złożoność), skup się na powyższych: filtry IP/Geo i ewentualnie zmiana portu.

Proxy przed portalem VPN. Ciekawą metodą stosowaną przez niektórych administratorów jest postawienie przed adekwatnym portalem VPN serwera reverse proxy (np. Nginx) w roli „strażnika”. Taki proxy może terminować TLS i wymuszać dodatkowe warunki – np. moduł GeoIP2 w Nginx może zwracać od razu kod 403 Forbidden dla państw spoza whitelisty, zanim ruch trafi do adekwatnego portalu. Można też pokusić się o mechanizmy typu CAPTCHA czy ograniczenie szybkości zapytań na poziomie proxy dla niezaufanych źródeł. Minusem jest dodatkowa warstwa do utrzymania i wprowadzenie punktu pojedynczego ryzyka (proxy padnie = VPN niedostępny). Jednak w niektórych scenariuszach, szczególnie dla własnych rozwiązań open-source, proxy daje elastyczność (można np. łatwo podłączyć moduł WAF Nginx, żeby wykrywać nietypowe payloady w żądaniach HTTP do portalu SSL-VPN). jeżeli używasz Nginx jako proxy, pamiętaj o odpowiedniej konfiguracji bezpieczeństwa (to temat na osobny artykuł).

Ogranicz dostęp po połączeniu. Załóżmy, iż atakujący jednak w jakimś scenariuszu uzyskał dostęp VPN (np. wykradł certyfikat i hasło). Czy to znaczy, iż ma od razu wolną rękę w Twojej sieci? Nie, jeżeli zastosujesz zasadę najmniejszych uprawnień i segmentację. Hardening VPN to nie tylko samo urządzenie VPN, ale i to, co dalej. Każdy użytkownik lub grupa VPN powinna mieć przypisane minimalne sieci, do których ma dostęp (np. tylko określony VLAN z serwerami aplikacji, ale już nie do sieci zarządzającej). Nowoczesne firewalle (w tym te same Forti/Palo) potrafią filtrować ruch także wewnątrz tunelu VPN – konfigurujesz polityki, co dany użytkownik VPN może osiągnąć. Rozważ wydzielenie kluczowych serwerów do sieci, do której VPN w ogóle nie routuje, jeżeli użytkownicy zdalni ich nie potrzebują. Micro-segmentacja i Zero Trust to szerokie tematy, ale warto je wdrażać krok po kroku: np. wymagaj osobnego uwierzytelnienia (just-in-time) do szczególnie wrażliwych systemów choćby po zestawieniu VPN. Zabezpieczysz się wtedy na wypadek, gdyby ktoś jednak przeszedł przez warstwę VPN – nie wejdzie dalej bez kolejnych autoryzacji.

Podobnie pomyśl o ograniczeniu czasu dostępu. Czy użytkownicy muszą mieć VPN 24/7? jeżeli nie – np. firma działa tylko w godzinach 8–18 – możesz ustawić reguły, iż próby połączeń poza tym oknem czasowym są blokowane lub wymagają dodatkowej akceptacji. To samo dotyczy liczby jednoczesnych sesji z jednego konta – często da się ustawić, iż użytkownik może mieć tylko jedno aktywne połączenie VPN na raz, co utrudni dzielenie się kontem. Każde takie ograniczenie dokłada kolejną przeszkodę dla potencjalnego intruza.

Sumarycznie, utwardzając powierzchnię ataku, dążysz do sytuacji, gdzie tylko uprawnione osoby, z uprawnionych miejsc i urządzeń, w uprawnionym czasie mogą w ogóle próbować się połączyć. Im bliżej tego ideału, tym mniejsze ryzyko, iż jakiś randomowy skrypt kiddie czy choćby zdeterminowana grupa wybierze na cel akurat Twój VPN – bo zwyczajnie nie będzie widoczny lub dostępny.

Monitorowanie i wykrywanie zagrożeń (SIEM/IDS)

Nawet najlepsze zabezpieczenia prewencyjne nie dają 100% gwarancji. Dlatego ostatnią, ale równie istotną częścią „cookbooka” jest monitoring VPN – tak, aby wychwycić próby ataku lub nietypowe aktywności, które jednak przenikną przez wcześniejsze warstwy. Zasada jest prosta: loguj wszystko i analizuj logi na bieżąco.

Centralne logowanie (SIEM/XDR)

Uruchom logowanie zdarzeń VPN na centralnym systemie typu SIEM lub XDR. Wszystkie nowoczesne rozwiązania mają możliwość wysyłania logów do zewnętrznego sysloga, SIEM, czy chmury producenta. Skonfiguruj to! Logi z samego urządzenia często są ulotne lub mało czytelne – w SIEM możesz je korelować i raportować. Przykładowe zdarzenia, które warto monitorować i na które ustawić alerty:

• Wiele nieudanych logowań – klasyka, sygnał ataku brute-force. o ile jedno konto notuje 10 kolejnych błędnych haseł, powinien polecieć alert (lub automatyczna blokada). Rozproszony atak może próbować 1-2 hasła na wielu kontach – dlatego patrz też na łączną liczbę błędów w krótkim czasie. Np. 50 nieudanych logowań różnych użytkowników w ciągu 1 minuty z jednego IP to czerwony alarm (w SIEM ustaw regułę korelującą). Warto reagować choćby na pojedyncze błędne logowanie admina VPN – bo admin raczej zna hasło, więc błąd może sugerować, iż ktoś nieuprawniony strzela hasłem .
• Logowanie z nowej lokalizacji – o ile użytkownik Jan Kowalski zawsze łączy się z Polski, a nagle jego konto loguje się z IP w Rosji czy Chin – traktuj to podejrzanie. Być może to „Impossible Travel” (user fizycznie nie mógł w ciągu godziny przenieść się na inny kontynent). SIEM z modułem GeoIP umożliwia takie analizy. Np. Wazuh XDR posiada funkcję geolokalizacji – można ustawić alert, gdy kraj źródłowy nie należy do listy dozwolonych. Ataki często wykorzystują egzotyczne VPSy; o ile Twoja firma nie ma klientów ani pracowników w tych regionach – blokuj/alertuj każde logowanie stamtąd.
• Dziwne godziny logowań – podobnie, logowanie w nietypowym czasie (środek nocy, weekend) powinno zwrócić Twoją uwagę, zwłaszcza dla kont, które zwykle tego nie robią. Być może czyjeś poświadczenia wyciekły i napastnik próbuje wejść, licząc iż nikt tego o 3 w nocy nie zauważy. SIEM potrafi uczyć się typowego wzorca aktywności i zgłaszać anomalie (tzw. UEBA – User Entity Behavior Analytics). jeżeli nie masz tak zaawansowanego systemu, możesz choćby manualnie przejrzeć logi pod kątem timestampów lub napisać prosty skrypt do wyciągania przedziałów czasowych logowań dla wszystkich usera.
• Powtarzające się błędy techniczne – np. ciągłe zrywanie tunelu, błędy uwierzytelnienia drugiego czynnika, komunikaty typu „policy reject”. Może to wskazywać, iż ktoś próbuje wykorzystać exploit (np. generuje specyficzny ruch, który wywołuje błąd). Przykładowo, o ile w logach widzisz nagminne błędy 5xx (Internal Error) podczas prób logowania, a nikt nie zgłasza problemów – możliwe, iż to skaner exploitujący błąd (takie sygnały GreyNoise radzi traktować nie jako zwykłe błędy, ale jak malicious probes). W praktyce: alertuj nie tylko oczywiste „Access denied”, ale też nietypowe kody błędów aplikacji VPN.
• Zmiany konfiguracyjne i administracyjne – logi powinny rejestrować również kiedy ktoś loguje się do panelu administracyjnego VPN, zmienia ustawienia, aktualizuje firmware itd. Te zdarzenia muszą być pod szczególnym nadzorem (najlepiej w oddzielnym indeksie SIEM). jeżeli masz zespół SOC, niech wdroży procedurę: każde niezaplanowane zdarzenie administracyjne (szczególnie wykonane przez konto admina VPN poza zmianowym oknem) traktować jako potencjalny incydent bezpieczeństwa.

Aby to zilustrować, zobacz przykładowy fragment logu (tu akurat stylizowany log OpenVPN Access Server):

2025-11-22 08:15:27 [VPN] 203.0.113.5:54123 [jan.kowalski] AUTH_FAILED, user authentication failed (Credentials rejected) 2025-11-22 08:15:30 [VPN] 203.0.113.5:54123 [jan.kowalski] AUTH_FAILED, user authentication failed (Credentials rejected) 2025-11-22 08:15:34 [VPN] 198.51.100.77:60012 [adam.nowak] AUTH_FAILED, user not found (authentication)

W powyższym logu widać serię nieudanych prób logowania dwóch użytkowników: jan.kowalski (dwukrotnie złe hasło) oraz adam.nowak (login nie istnieje). Taki wzorzec – szczególnie wielu różnych użytkowników – najpewniej oznacza atak typu password spraying (próba odgadnięcia haseł na masową skalę). Nasz system monitoringu powinien to wykryć i np. automatycznie dodać IP 203.0.113.5 do blokowanych na firewallu. Wazuh czy inne SIEM można tak skonfigurować, by przy takich zdarzeniach generowały incydent bezpieczeństwa. W Wazuh możemy np. zdefiniować regułę liczącą unikalne adresy IP generujące błędy w krótkim czasie i oznaczyć to jako potencjalny atak. Analogicznie, Fail2Ban mógłby zbanować IP po wykryciu ciągu AUTH_FAILED.

Wykorzystanie IDS/IPS

Kolejnym narzędziem w arsenale jest monitorowanie ruchu sieciowego z pomocą systemów IDS/IPS (Intrusion Detection/Prevention System). o ile masz możliwość, rozważ odpalanie sensorów IDS (Snort/Suricata/Zeek) na ruchu przychodzącym do VPN. Taki sensor może wyłapać sygnatury znanych exploitów wymierzonych w VPN (np. pakiety charakterystyczne dla CVE-2023-XXXXX). Producenci często publikują reguły IDS na bieżąco przy okazji nowych CVE – upewnij się, iż Twój IDS je ma. Zeek (dawniej Bro) jest szczególnie ciekawy, bo pozwala na zaawansowaną inspekcję protokołów i korelację. Możesz np. użyć Zeeka do wyciągania JA3/JA4 odcisków TLS z handshake klienta VPN. GreyNoise zaobserwował, iż ostatnie kampanie skanowania GlobalProtect cechowały się powtarzalnymi fingerprintami JA4 w ruchu TCP. Możesz porównać JA3/JA4 swoich legalnych klientów VPN z tym, co pojawia się od obcych – i jeżeli widzisz nieznany fingerprint próbujący się połączyć, to sygnał alarmowy. Dla jasności: JA3 to hash identyfikujący klienta TLS (na podstawie ustawień protokołu), a JA4 to nowsza wersja uwzględniająca również kolejność rozszerzeń TLS (bardziej odporna na zmiany losowe w handshake). Atakujące boty często mają unikalny JA3/JA4, różny od oficjalnych klientów – wykorzystaj to na swoją korzyść. Zeek lub choćby logi firewall (PAN-OS potrafi logować JA3) pomogą Ci wykryć np. „tu ktoś udaje klienta GlobalProtect, ale jego JA3 się nie zgadza z prawdziwym GlobalProtect app”.

Automatyczna reakcja (SOAR/XDR)

Samo wykrycie to połowa sukcesu – dobrze by było od razu reagować. jeżeli dysponujesz rozwiązaniem XDR (Extended Detection and Response) lub SOAR, zautomatyzuj odpowiedź na typowe incydenty VPN. Prosty przykład: integracja SIEM z firewallem – gdy SIEM złapie alert „brute-force z IP X”, to SOAR wywoła API firewalla dodając IP X do blokowanych adresów na określony czas. FortiGate ma tzw. Automation Stitches (zaszyte automatyzmy), które można skonfigurować – np. „jeśli wykryjesz 5 nieudanych logowań z IP, to dodaj to IP do adresów zablokowanych”. Palo Alto z kolei może korzystać z Dynamic Address Groups i AutoTags w połączeniu z ich systemem logowania – reguła bezpieczeństwa automatycznie zablokuje host oznaczony tagiem „BruteForce” itp. Możliwości jest wiele i zależą od narzędzi w Twoim ekosystemie. Ważne, by wykorzystać je do szybkiej izolacji zagrożenia. Wspomniany wcześniej Cortex XDR (używany przez Palo Alto we własnej infrastrukturze) twierdzi, iż autonomicznie przetwarza 36 miliardów zdarzeń na najważniejsze incydenty i blokuje 1,5 mln ataków dziennie. To skala big tech, ale pokazuje kierunek: człowiek nie jest w stanie manualnie przejrzeć tysięcy logów dziennie, więc automatyzacja to mus.

Na koniec, testuj swój monitoring. Upewnij się, iż alerty faktycznie działają. Symuluj zdarzenia: np. wykonaj kontrolowaną serię błędnych logowań swoim kontem (w porozumieniu z ITSec), zobacz czy SIEM wygeneruje incydent. Przeprowadź wewnętrzny pentest/Red Team na VPN (oczywiście w uzgodnieniu) – wiele firm oferuje takie usługi, sprawdzające odporność Twojej konfiguracji. Lepiej żeby oni znaleźli słabość niż prawdziwy atakujący.

Checklista hardeningu VPN

Na koniec zbierzmy najważniejsze praktyki w formie krótkiej checklisty. Użyj jej, aby zweryfikować, czy wszystkie obszary zostały pokryte:

• Aktualizacje: Regularnie instaluj łatki bezpieczeństwa dla sprzętu/serwera VPN. Śledź nowe CVE i zalecenia producenta – nie dopuść, by Twój VPN miał znaną lukę exploatowaną przez boty.
• Hasła i MFA: Wymuś MFA dla wszystkich logowań VPN (tokeny jednorazowe, aplikacje uwierzytelniające). Zapewnij politykę silnych haseł (długie, unikatowe) i rozważ dodatkowe uwierzytelnianie klientem TLS (certyfikat na urządzeniu użytkownika).
• Protokoły/certyfikaty: Wyłącz stare protokoły (SSLv3, TLS <1.2, IKEv1) i słabe szyfry (RC4, 3DES, MD5 itp.). Używaj TLS 1.3/TLS 1.2 oraz mocnych algorytmów (AES-GCM, SHA-256, ECDHE). Wgraj własny certyfikat TLS zaufany przez urządzenia użytkowników – nie używaj domyślnego self-signed.
• Konfiguracja VPN: Zabezpiecz plik konfiguracyjny i klucze. Dla OpenVPN włącz tls-crypt/tls-auth i używaj aktualnych bibliotek OpenSSL. Dla komercyjnych rozwiązań stosuj się do hardening guide producenta – przejrzyj wszystkie ustawienia (timeouty, ograniczenia dostępu, banowanie IP, itp.) i dostosuj je do maksimum bezpieczeństwa akceptowalnego przez biznes.
• Ograniczenie dostępu: Zawęż zakres IP/geo mogących inicjować VPN. W firewallu przed VPN ustaw reguły allow tylko dla zaufanych sieci lub krajów, resztę drop. Rozważ niestandardowy port dla usługi (choć to opcjonalne). Wyłącz nieużywane funkcje VPN/portale. jeżeli to możliwe, ukryj VPN za rozwiązaniem zerotrust/brokerem dostępu.
• Segmentacja i uprawnienia: Połączenie VPN nie daje carte blanche – segmentuj sieć i przyznawaj minimalne uprawnienia zdalnym użytkownikom. Wdróż ACL/Firewall wewnątrz tunelu (reguły kto co może pingować po VPN). Krytyczne zasoby trzymaj w segmentach niedostępnych z VPN bez dodatkowego uwierzytelnienia.
• Monitoring logów: Włącz szczegółowe logowanie zdarzeń VPN i wysyłaj logi do SIEM/XDR. Przygotuj reguły alertujące na: wiele błędnych logowań, logowania z nowych lokalizacji, nietypowe godziny, błędy systemowe, działania adminów. Regularnie przeglądaj te alerty (najlepiej by robił to dedykowany SOC analyst).
• IDS/IPS na ruchu: jeżeli to możliwe, uruchom IDS/IPS obserwujące ruch do/z VPN. Wgraj aktualne reguły dla exploitów VPN. Monitoruj odciski TLS (JA3/JA4) i ruch nienależący do normalnego profilu (np. skanowanie portu). Systemy typu Zeek potrafią dać cenny wgląd w to, co adekwatnie robi klient po nawiązaniu sesji VPN.
• Automatyzacja reakcji: Skonfiguruj mechanizmy automatycznego blokowania oczywistych ataków. Fail2Ban, skrypty automatycznie aktualizujące listy zablokowanych IP na firewallu, Automation Stitches w FortiGate czy polityki dynamiczne w Palo Alto – wykorzystaj je, by w minutę od wykrycia ataku odciąć intruza, zanim spróbuje dalej.
• Testy i utrzymanie: Hardening to proces ciągły. Testuj swoje zabezpieczenia (wewnętrzne testy penetracyjne VPN, audyty konfiguracji). Symuluj incydenty (red team vs blue team), żeby sprawdzić, czy procedury działają. Szkol użytkowników – choćby najlepszy VPN nic nie da, jak dadzą się złapać na phishing i oddadzą token MFA. Utrzymuj dokumentację – miej pod ręką plan awaryjny (np. wyłączenie VPN w razie masowego ataku, procedura komunikacji itp.).

Ta lista może wydawać się długa, ale w praktyce wiele z tych kroków to jednorazowa konfiguracja, która potem procentuje latami bezpiecznej pracy zdalnej.

Dlaczego to ma znaczenie? Bo stawką jest ochrona Twojej sieci i danych przed coraz sprytniejszymi atakami. VPN to dla wielu firm „single point of failure” – pojedynczy front, którego przełamanie oznacza pełen kompromis. Warto więc zainwestować czas w jego adekwatne zabezpieczenie.

Podsumowanie

Uzbrojony w powyższe wskazówki, możesz uczynić z swojego VPN prawdziwą twierdzę. Każda warstwa zabezpieczeń – od aktualnego oprogramowania, przez silne uwierzytelnianie, po monitorowanie – znacząco podnosi poprzeczkę dla atakującego. Podejście warstwowe (defense in depth) sprawia, iż choćby jeżeli jedna kontrola zawiedzie, kolejna przejmie pałeczkę. Dążymy do sytuacji, w której atak staje się dla napastnika zbyt czasochłonny i ryzykowny, więc odpuści lub przeniesie się na łatwiejszy cel.

Co dalej? Praktyka! Skorzystaj z tej wiedzy w swoim środowisku. Przejrzyj logi VPN z ostatnich dni – czy widać w nich coś, co wymaga uwagi (dziwne IP, pora, błędy)? Sprawdź konfigurację na swoim urządzeniu: czy masz włączone wszystkie rekomendowane opcje bezpieczeństwa? Przetestuj na stagingu wyłączenie starszych protokołów, wymuszenie MFA, nowe reguły – upewnij się, iż użytkownicy przez cały czas mogą się łączyć, a atakujący już nie. Odwiedź też stronę producenta Twojego VPN – czy nie pojawił się nowy alert o podatności lub aktualizacja?

Pamiętaj, iż hardening to proces ciągły. Świat zagrożeń się zmienia – pojawiają się nowe techniki (ostatnio np. wykorzystanie AI do ataków), ale również nowe rozwiązania obronne. Bądź na bieżąco: czytaj branżowe blogi (np. SecurityBezTabu.pl ), uczestnicz w webinarach bezpieczeństwa, dziel się wiedzą z zespołem. VPN Hardening Cookbook to żywy przepis – modyfikuj go wedle potrzeb i aktualizuj składniki, gdy pojawią się lepsze.

Na koniec dnia celem jest spokojny sen administratora, który wie, iż zrobił wszystko, by chronić swoją firmę. Wdrażaj powyższe porady krok po kroku, a Twój VPN z pewnością stanie się znacznie trudniejszym celem. Powodzenia!

Teraz działaj – zaloguj się na swój serwer VPN już dziś i przejrzyj jego logi pod kątem podejrzanych zdarzeń. Następnie wybierz jeden element z checklisty (np. włączenie MFA, aktualizacja firmware lub konfiguracja geo-blokady) i wdroż go w swoim środowisku testowym. Przekonaj się, jak te zmiany zwiększają bezpieczeństwo. Nie czekaj, aż wydarzy się incydent – proaktywna obrona to najlepsza obrona. Sprawdź logi… przetestuj na stagingu… i śpij spokojniej!

Bibliografia

• https://security.paloaltonetworks.com/?product=GlobalProtect+App&sort=-date
• https://security.paloaltonetworks.com/CVE-2025-0141
• https://docs.fortinet.com/document/fortigate/7.4.99/administration-guide/869159/ssl-vpn-best-practices
• https://security.paloaltonetworks.com/CVE-2025-2183
• https://www.andrewtravis.com/blog/2024/09/30/fortigate-ssl-vpn-hardening