Audyt konfiguracji OpenVPN: logi, szyfry, uwierzytelnianie i twarde wyłączenie słabych opcji

Po co audytować konfigurację OpenVPN i jak do tego podejść strategicznie

Różnica między „działa” a „działa bezpiecznie”

Instancja OpenVPN, która „po prostu działa”, bardzo często opiera się na starych szyfrach, słabym TLS i byle jakim logowaniu. Po stronie użytkownika wszystko wygląda dobrze: klient łączy się, tunel jest zestawiony, aplikacje mają dostęp do zasobów. Z perspektywy bezpieczeństwa może to jednak oznaczać:

• możliwość podsłuchu lub częściowego złamania ruchu przez atakującego,
• brak wiarygodnych logów pozwalających prześledzić, kto i kiedy łączył się z VPN,
• brak kontroli nad tym, jakie protokoły i szyfry są faktycznie negocjowane,
• lukę w wymaganiach compliance (np. RODO, ISO 27001, NIST, wytyczne klienta korporacyjnego).

Audyt konfiguracji OpenVPN ma więc dwa cele: techniczny (twarde wyłączenie słabych opcji: szyfrów, protokołów, metod uwierzytelniania) oraz organizacyjny (potwierdzenie, że konfiguracja spełnia wewnętrzne polityki bezpieczeństwa i zewnętrzne wymagania).

Typowe motywacje: incydent, wymagania klienta, audyt zewnętrzny, compliance

Motywacja wpływa na to, jak głęboko trzeba wejść w szczegóły. Kilka typowych scenariuszy:

• Po incydencie bezpieczeństwa – np. wyciekł laptop z konfiguracją klienta OpenVPN, pojawiły się dziwne logowania z nietypowych adresów IP. W takim przypadku audyt musi objąć:
  • analizę logów z dłuższego okresu,
  • sprawdzenie, czy nie użyto słabych haseł lub współdzielonych kont,
  • wymuszenie unieważnienia certyfikatów/kluczy i rotację.
• Wymagania klienta B2B – często padają konkretne żądania: AES-GCM, TLS 1.2+, certyfikaty min. 2048 bitów, brak SHA1, logi przechowywane 6–12 miesięcy. Audyt musi sprawdzić:
  • czy obecny serwer OpenVPN i biblioteka OpenSSL w ogóle wspierają oczekiwane funkcje,
  • czy konfiguracja nie dopuszcza słabszych fallbacków (np. data-ciphers-fallback ze starym cipherem),
  • czy polityka logowania jest zgodna z wymaganiami klienta.
• Audyt zewnętrzny / compliance – ISO, audyt bankowy, testy bezpieczeństwa. Tu priorytetem jest:
  • udokumentowanie konfiguracji (zrzuty configów, listy szyfrów, polityka logów),
  • wykazanie, że korzysta się wyłącznie z zalecanych algorytmów kryptograficznych,
  • opis procesu zarządzania kluczami i certyfikatami.

Koncepcja audytu: punkt wyjścia, stan docelowy, ograniczenia środowiska

Żeby audyt konfiguracji OpenVPN miał sens, trzeba jasno zdefiniować trzy elementy: gdzie jesteśmy, dokąd chcemy dojść i co nas ogranicza. W praktyce wygląda to jak krótka „mapa”:

• Punkt wyjścia – wersje OpenVPN i OpenSSL, aktualne szyfry, metody uwierzytelniania, poziom logowania, topologia (site-to-site, remote access).
• Stan docelowy – np. „wyłącznie TLS 1.2+, AES-GCM lub CHACHA20-POLY1305, brak SHA1, obowiązkowe certyfikaty per użytkownik, 2FA dla zdalnego dostępu, logi bez danych wrażliwych, rotowane i wysyłane do centralnego sysloga”.
• Ograniczenia – stare routery (OpenVPN 2.3), klienci na Windows 7, liczne embedded urządzenia, które nie obsługują nowszych cipher suites; wymagania wydajnościowe (router klasy SOHO nie pociągnie ECDSA 4096 i AES-GCM na pełnej przepustowości).

Bez nazwania ograniczeń łatwo wpaść w pułapkę: konfiguracja będzie „idealna na papierze”, ale klienci z legacy systemami przestaną się łączyć. Wtedy zamiast twardego wyłączenia słabych opcji wraca „tymczasowe” otwieranie szerokich drzwi, które zostaje na zawsze.

Audyt jednorazowy vs cykliczny: kiedy który model ma sens

Audyt jednorazowy bywa kuszący: przejrzeć configi, podnieść poziom bezpieczeństwa, zrobić raport i o sprawie zapomnieć. Kryptografia i ekosystem klientów VPN zmieniają się jednak na tyle dynamicznie, że po 2–3 latach świeży kiedyś hardening potrafi wyglądać archaicznie. Różnica między modelami jest prosta:

• Audyt jednorazowy – dobre rozwiązanie, gdy:
  • wdraża się OpenVPN od zera w nowym środowisku,
  • migracja na nowszą wersję (np. z 2.3 na 2.5+) jest jednorazowym projektem,
  • chodzi o spełnienie doraźnych wymagań konkretnego kontraktu.
• Audyt cykliczny – konieczny, gdy:
  • OpenVPN jest kluczowym elementem infrastruktury (praca zdalna, dostęp do sieci OT/SCADA),
  • organizacja podlega regularnym audytom bezpieczeństwa,
  • dochodzi dużo nowych klientów/oddziałów, a konfiguracja stale ewoluuje.

Dobrym kompromisem bywa model: pełny audyt raz na rok plus lekki przegląd po każdej większej zmianie (np. upgrade OpenVPN lub OpenSSL, zmiana metody uwierzytelniania, nowa integracja z SSO/LDAP).

Inwentaryzacja środowiska OpenVPN – co trzeba wiedzieć zanim zacznie się grzebać w configach

Zbieranie informacji o wersjach, systemach i dystrybucji konfiguracji

Pierwszy etap audytu to prosty spis tego, z czym się pracuje. Chodzi o trzy kategorie danych:

• Wersje serwerów OpenVPN – istotne są:
  • wersja OpenVPN (np. 2.3, 2.4, 2.5, 2.6),
  • wersja biblioteki kryptograficznej (OpenSSL, mbedTLS, LibreSSL),
  • system operacyjny (Linux, *BSD, Windows, appliance typu pfSense/OPNsense).
• Wersje klientów – OpenVPN GUI na Windows, Tunnelblick, klienci mobilni, routery z wbudowanym OpenVPN. W praktyce to klienci ograniczają możliwość twardego wyłączenia słabych szyfrów.
• Sposób dystrybucji konfiguracji – czy pliki .ovpn są:
  • wysyłane mailem (z załączonym certyfikatem),
  • pobierane z portalu self-service,
  • wypychane przez system MDM/konfigurator (np. w firmie, gdzie są zarządzane laptopy).

Ten krok jest kluczowy, gdy trzeba wprowadzić zmiany w konfiguracji klientów. Twarde wyłączenie słabych cipherów czy podniesienie minimalnej wersji TLS bez świadomości, jakie klienty są używane, może skończyć się masowymi problemami z łącznością.

Mapowanie topologii: tryb tun/tap, site-to-site vs access VPN, routing vs bridging

Sposób, w jaki OpenVPN jest używany, mocno wpływa na możliwe optymalizacje i ograniczenia. Podstawowe rozróżnienia to:

• tun vs tap:
  • tun – tunelowanie na poziomie IP (routowanie), najczęściej używany, lepsza wydajność i mniejszy narzut, prostsze reguły firewall.
  • tap – tunelowanie na poziomie Ethernet (bridging), przenosi broadcasty, VLAN-y; dziś tylko tam, gdzie naprawdę jest to wymagane (np. nietypowe protokoły warstwy 2).
• site-to-site vs access VPN:
  • site-to-site – łączenie dwóch (lub więcej) sieci, zwykle z autoryzacją po certyfikacie urządzenia, rzadziej login/hasło.
  • remote access (access VPN) – dostęp użytkowników do wewnętrznej sieci firmy; tu dochodzi temat haseł, 2FA, integracji z AD/LDAP.
• routing vs bridging – bridging bywa wygodny w środowiskach „wszystko w jednej podsieci”, ale komplikuje filtrowanie, logowanie i skalowanie. Audyt często prowadzi do wniosku, że część tap-ów warto migrować na tun-y.

Znajomość topologii pozwala później interpretować logi (czy łączą się użytkownicy, czy inne routery), a także zdecydować, gdzie twardo wyłączyć słabe protokoły bez rozwalania całej sieci (np. zaczynając od nowych site-to-site, a dopiero później przełączając access VPN).

Identyfikacja metod uwierzytelniania: certyfikaty, login/hasło, hybrydy

OpenVPN pozwala mieszać różne mechanizmy uwierzytelniania. Przed zmianami warto ustalić, co faktycznie jest używane:

• Tylko certyfikaty – spotykane często w site-to-site i w starszych wdrożeniach z prostym CA:
  • bez haseł,
  • każdy klient ma swój certyfikat lub, co gorsza, współdzielony certyfikat na wiele urządzeń.
• Certyfikat + login/hasło – wygodny kompromis:
  • certyfikat identyfikuje urządzenie/klienta,
  • login/hasło pozwala powiązać sesję z kontem użytkownika (np. z AD/LDAP),
  • można dołożyć 2FA (np. przez plugin lub dodatkowy backend).
• Tylko login/hasło – konfiguracje „pod Windows”, oparte na samym auth-user-pass. Wygodne, ale kryptograficznie słabsze: brak indywidualnych certyfikatów utrudnia twardą separację i odwoływanie dostępu per urządzenie.

Model uwierzytelniania wpływa na strategię hardeningu. Tam, gdzie nie ma indywidualnych certyfikatów, trzeba nadrobić bezpieczeństwem haseł, 2FA, dobrym logowaniem i mechanizmami blokowania po wielu nieudanych próbach.

Ograniczenia biznesowe: legacy systemy, stare routery, mobilni klienci

Najczęstsze blokery twardego wyłączenia słabych opcji w OpenVPN nie mają natury technicznej, tylko biznesową. Typowe przykłady:

• Stare routery z OpenVPN 2.3 – nie wspierają nowej składni data-ciphers, a jedynie pojedynczy cipher; mają ograniczenia co do tls-version-min i tls-cipher.
• Urządzenia mobilne – starsze wersje aplikacji OpenVPN na Android/iOS, które nie obsługują nowoczesnych protokołów TLS lub nowych szyfrów (np. CHACHA20-POLY1305 w konkretnych wersjach).
• Systemy, których nie da się zaktualizować – np. Windows 7 z klientem OpenVPN, bo działa na nim jakiś stary system produkcyjny, którego migracja jest osobnym, dużym projektem.

Tu pojawiają się dwie strategie:

• Segmentacja – wydzielić osobną instancję OpenVPN z bardziej „miękką” konfiguracją tylko dla legacy, z agresywnym logowaniem i dodatkowymi ograniczeniami (np. tylko określone adresy IP, bardzo wąski zakres dostępnych zasobów).
• Plan wygaszania – ustalić twardą datę końca wsparcia dla starych klientów/urządzeń, komunikować to biznesowi i równolegle przygotowywać migrację na nowe rozwiązania.

Przegląd plików konfiguracyjnych serwera i klientów – metodyka krok po kroku

Główne pliki: server.conf, openvpn.conf, client.conf, includowane fragmenty

Konfiguracje OpenVPN potrafią być rozsiane po kilku plikach. Dla rzetelnego audytu trzeba ustalić, gdzie szukać:

• Plik główny serwera – najczęściej /etc/openvpn/server.conf lub /etc/openvpn/openvpn.conf, na systemach typu pfSense/OPNsense generowany automatycznie i trzymany w konkretnym katalogu.
• Pliki include – linie typu config, include lub crl-verify odwołujące się do:
  • listy odwołanych certyfikatów (CRL),
  • dodatkowych reguł push,
  • konfiguracji specyficznych dla użytkowników (client-config-dir).
• Konfiguracje klientów – pliki .ovpn lub client.conf:
  • czasem zawierają wbudowane certyfikaty i klucze,
  • czasem tylko odwołują się do plików w katalogach (cert, key, ca).

Dobrym nawykiem jest utworzenie lokalnej kopii wszystkich badanych plików i zrobienie prostego przeszukania (grep) dla kluczowych dyrektyw (cipher, auth, tls-version-min, verb itd.), aby szybko „zmapować” ryzyka kryptograficzne i logowania.

Analiza kluczowych dyrektyw bezpieczeństwa w konfiguracji

Po ogólnym przeglądzie plików pora na filtrowanie tego, co faktycznie wpływa na bezpieczeństwo. W praktyce audyt dzieli się na kilka grup dyrektyw:

• Kryptografia i TLS – m.in. cipher, data-ciphers, ncp-ciphers, auth, tls-version-min, tls-cipher, tls-ciphersuites, dh/dh none, ecdh-curve.
• Uwierzytelnianie – ca, cert, key, pkcs12, auth-user-pass, auth-nocache, verify-x509-name, remote-cert-tls, username-as-common-name.
• Kontrola dostępu – client-config-dir, ifconfig-pool, ifconfig-push, iroute, push, topology, client-to-client.
• Ochrona przed nadużyciami – tls-auth/tls-crypt/tls-crypt-v2, tls-verify, client-connect/ client-disconnect, limity połączeń (np. przez firewall, max-clients), parametry keepalive.

Najprościej wypisać je komendą:

grep -Ei 'cipher|auth|tls-|dh |ecdh|client-config-dir|ifconfig-pool|topology|client-to-client' /etc/openvpn/*.conf

Później można już pracować „blokami”: osobno przejrzeć wszystkie kwestie TLS, osobno topologię i routing. Ułatwia to uchwycenie rozbieżności między instancjami – np. jedna instancja wymaga TLS 1.2, druga zezwala jeszcze na 1.0, bo nikt nie scalił konfiguracji według wspólnego standardu.

Wyszukiwanie anty-wzorów: czego szukać, żeby złapać słabe ustawienia

W wielu środowiskach problemem są nie tyle błędne, co „historyczne” konfiguracje. Kilka dyrektyw lub wartości powinno od razu zapalać lampkę ostrzegawczą:

• Przestarzałe szyfry i HMAC:
  • cipher BF-CBC, cipher DES*, cipher RC2* – typowe relikty starych tutoriali.
  • auth MD5, auth SHA1 – akceptowalne tylko tymczasowo i z jasnym planem migracji.
• Stare wersje TLS:
  • brak tls-version-min albo ustawienie na 1.0 / 1.1,
  • brak ograniczenia tls-cipher przy starych wersjach OpenVPN/OpenSSL.
• Słabe praktyki kluczy i CA:
  • współdzielone certyfikaty (ten sam CN dla wielu urządzeń),
  • brak crl-verify lub nieaktualna CRL,
  • klucze prywatne bez ochrony systemowej, trzymane w katalogach użytkowników.
• Ryzykowne ułatwienia:
  • client-to-client w access VPN bez dodatkowego filtrowania,
  • brak auth-user-pass-verify/plugin, gdy w polityce jest wymagane uwierzytelnianie użytkownika,
  • brak tls-auth lub tls-crypt na serwerze wystawionym do Internetu.

Przy takim przeglądzie widać szybko różnicę między konfiguracją „zamrożoną 10 lat temu” a aktualną. W jednej spotyka się BF-CBC, SHA1 i TLS 1.0, w drugiej AES-GCM, SHA256 i twardsze ograniczenia TLS. Audyt polega w dużej mierze na doprowadzeniu wszystkich instancji do wspólnego, nowego minimum.

Logowanie w OpenVPN – poziomy, format, bezpieczeństwo i użyteczność

Poziomy verb – balans między ciszą a szumem

Podstawową dźwignią przy logach jest parametr verb. W praktycznych wdrożeniach najczęściej występują trzy poziomy:

• verb 3 – sensowny kompromis na produkcję:
  • loguje nawiązanie/zerwanie połączenia,
  • pokazuje błędy TLS, ale nie zaśmieca logu każdą wymianą pakietów.
• verb 4–5 – tryb diagnostyczny:
  • dobry przy problemach z łącznością,
  • dużo więcej szczegółów o TLS i routingu,
  • na dłuższą metę generuje zbyt duży wolumen logów.
• verb 6+ – tylko do krótkotrwałego debugowania:
  • bardzo wysoki poziom szczegółowości,
  • realne ryzyko, że w logach pojawią się fragmenty danych lub nadmierne informacje o strukturze sieci.

Na serwerach produkcyjnych zwykle kończy się na verb 3 plus dodatkowe logi zewnętrzne (np. z management interface albo systemu uwierzytelniania). Wyższe poziomy przydają się czasowo, najlepiej z ograniczeniem przez log-append i rotację logów.

Format logów i integracja z syslog/ELK/SIEM

OpenVPN potrafi logować do pliku lub do sysloga. Z punktu widzenia audytu ważne jest, czy logi trafiają w jedno, centralne miejsce, czy rozlewają się po dyskach poszczególnych serwerów.

• Log do pliku (log, log-append):
  • proste do szybkiego podglądu lokalnie,
  • wymagana rotacja (np. logrotate) i kontrola uprawnień,
  • bez centralizacji trudniej wykrywać wzorce ataków na wiele instancji.
• Log do syslog (syslog openvpn):
  • naturalna integracja z rsyslog/journald,
  • łatwe przekazanie dalej do ELK / Graylog / SIEM,
  • trzeba skontrolować filtry, aby nie wycinały istotnych komunikatów.

Przy centralizacji logów przydaje się ustandaryzowanie wzorca: wszędzie ten sam format timestampu, ta sama nazwa procesu, ta sama polityka rotacji. Ułatwia to później budowę dashboardów – np. prostego widoku: „10 najczęściej łączących się użytkowników”, „Top 20 źródeł nieudanych logowań”.

Dane osobowe i wrażliwe w logach – minimalizacja vs forensic

Logi OpenVPN często zawierają adresy IP użytkowników, nazwy hostów i czasem loginy. W organizacjach objętych RODO zwykle trzeba pogodzić dwa cele: przydatność logów w razie incydentu i ograniczanie zakresu danych.

Porównując dwa skrajne podejścia:

• Maksymalna szczegółowość:
  • logowane są loginy, adresy IP, błędy uwierzytelniania,
  • łatwa analiza incydentów (kto, kiedy, z jakiego adresu),
  • większe wymagania co do ochrony i retencji logów.
• Minimalizacja danych:
  • logowane głównie identyfikatory techniczne (CN certyfikatu, skrócone IP),
  • trudniej później zrekonstruować incydent,
  • łatwiej spełnić wymogi compliance i krótkiej retencji.

Rozsądny kompromis to logowanie CN certyfikatu powiązanego z kontem użytkownika (np. user@firma) i publicznego IP źródłowego, przy jednoczesnym ograniczeniu czasu przechowywania logów z detalami – np. 90 lub 180 dni, zgodnie z polityką bezpieczeństwa.

Parametry pomocnicze: status, management interface, eventy

Poza klasycznym logiem do pliku przydatne są dwa dodatkowe mechanizmy:

• status – plik generowany przez dyrektywę status /ścieżka/do/pliku:
  • zawiera bieżącą listę połączeń, mapowanie CN → adres, transfer, czas trwania,
  • dobry do integracji z prostymi skryptami monitoringu.
• management interface – gniazdo TCP, z którego można odczytać stan serwera:
  • umożliwia zewnętrznym narzędziom odpytywanie o listę sesji,
  • pozwala na automatyczne rozłączanie podejrzanych sesji lub blokowanie użytkowników,
  • wymaga dodatkowego zabezpieczenia (hasło, firewall, tunelowanie).

W audycie warto sprawdzić, czy status i management są w ogóle używane. Jeśli tak, trzeba sprawdzić ich dostępność z sieci – plik statusu wystawiony na udział SMB bez kontroli uprawnień albo management słuchający na 0.0.0.0 bez firewalla potrafią być osobnym wektorem ataku.

Transport i protokół – UDP czy TCP, porty, obfuskacja i wpływ na bezpieczeństwo

UDP vs TCP w OpenVPN – kiedy który ma sens

Wybór między UDP i TCP bywa traktowany jako kwestia „czy działa za NAT-em”, ale z perspektywy bezpieczeństwa i niezawodności różnic jest więcej.

• UDP (domyślny i preferowany):
  • mniejszy narzut, brak zjawiska „TCP over TCP meltdown”,
  • lepsza wydajność przy dużej liczbie równoległych sesji,
  • nieco mniejsza wykrywalność wzorców „VPN over HTTPS”, bo nie udaje HTTP.
• TCP:
  • przydatny przy restrykcyjnych firewallach (np. tylko port 443/tcp),
  • łatwiej „wtopić się” w ruch HTTPS (przynajmniej na poziomie 5-tki),
  • gorzej znosi wysokie RTT i straty pakietów; przy intensywnym ruchu aplikacji TCP nakładają się retransmisje.

Modelowo, jeśli nie ma twardych ograniczeń sieciowych, access VPN i site-to-site lepiej trzymać na UDP. TCP warto zostawić jako wariant awaryjny (drugi remote) dla użytkowników za szczególnie problematycznymi zaporami.

Dobór portów – standard vs niestandard i ich implikacje

Klasyczne wdrożenia używają 1194/udp albo 443/tcp. Oba podejścia mają plusy i minusy:

• Port standardowy (1194/udp):
  • łatwa identyfikacja w inwentaryzacji,
  • nieco łatwiej dla IDS/IPS odróżnić ruch VPN od reszty,
  • bardziej podatny na proste blokady „block OpenVPN by port”.
• Port „udający” HTTPS (443/tcp/udp):
  • przechodzi przez większość firewalli wychodzących,
  • często wykorzystywany w środowiskach z proxy,
  • zwiększa potrzebę dobrej separacji ruchu VPN i faktycznego HTTPS na tym samym hostcie.
• Niestandardowe porty (np. 8443, 1195 itp.):
  • redukują przypadkowe skany pod default, ale nie są „bezpieczeństwem przez ukrycie”,
  • czasem pomagają obejść prymitywne ACL-e, które blokują tylko 1194.

Przy audycie przydaje się porównać konfigurację OpenVPN z konfiguracją zewnętrznego firewalla. Jeśli firewall przepuszcza „any to port 443”, a na tym porcie stoi zarówno reverse proxy, jak i OpenVPN, dobrze jest przeanalizować scenariusze DoS i politykę rate limiting.

Obfuskacja i ukrywanie OpenVPN – tls-crypt, pluggable transports, DPI

W niektórych krajach i sieciach korporacyjnych ruch OpenVPN jest aktywnie blokowany przez DPI. Tutaj wchodzą w grę różne techniki „maskowania” tunelu:

• tls-auth:
  • dodatkowy HMAC dla nagłówków TLS,
  • utrudnia rozpoznanie serwera OpenVPN, bo odrzuca pakiety bez poprawnego HMAC bez generowania widocznej odpowiedzi,
  • ochrona przed prostymi atakami typu port scanning i niektórymi DoS.
• tls-crypt:
  • szyfruje nie tylko payload, ale i metadane TLS w pierwszej fazie,
  • jeszcze trudniej DPI odróżnić od losowego strumienia,
  • wymaga synchronizacji statycznego klucza między klientem a serwerem.

Proxy, mostkowanie i tunelowanie w tunelu

Poza wyborem UDP/TCP konfiguracje produkcyjne często korzystają z dodatkowych warstw pośrednich: proxy HTTP/SOCKS, mostków L2 czy tuneli „w tunelu” (kaskadowanie VPN). Każda z tych opcji ma inne skutki dla audytowalności i powierzchni ataku.

• Połączenie przez proxy (http-proxy / socks-proxy):
  • pozwala wyjść z ograniczonej sieci korporacyjnej, gdzie jedyną drogą na zewnątrz jest serwer proxy,
  • część metadanych użytkownika (IP źródłowe, czas) ląduje w logach proxy, a nie bezpośrednio w logach OpenVPN,
  • utrudnia korelację zdarzeń, bo ślad użytkownika jest rozproszony między kilka systemów.
• Mostkowanie (dev tap):
  • przenosi ramki L2 zamiast pakietów IP,
  • z punktu widzenia audytu ruch jest mniej przejrzysty – klient „wygląda” jak host w tej samej sieci LAN,
  • łatwiej o problemy z broadcastami, VLAN-ami i inspekcją ruchu (nie wszystkie sondy lubią całe L2 przez tunel).
• Kaskadowanie tuneli (VPN w VPN):
  • czasem świadome: lokalny VPN użytkownika + centralny OpenVPN organizacji,
  • czasem nieświadome: użytkownik łączy się do komercyjnego VPN, a potem wchodzi w tunel firmowy,
  • utrudnia identyfikację realnego IP końcowego oraz reagowanie na nadużycia.

Przy audycie warto skonfrontować konfigurację klienta z polityką bezpieczeństwa: czy dopuszczalny jest ruch przez proxy zewnętrzne, czy wymagane jest blokowanie innych VPN-ów na stacjach (np. przez EDR), czy mostkowanie TAP nie rozciąga płaskiej sieci LAN poza zaplanowane granice.

Segmentacja ruchu: full-tunnel vs split-tunnel

OpenVPN może wymuszać przekierowanie całego ruchu klienta przez tunel lub tylko wybranych podsieci. Bez znajomości tego wyboru trudno poprawnie zinterpretować logi i ryzyko wycieku danych.

• Full-tunnel (redirect-gateway):
  • cały ruch IP klienta (domyślnie 0.0.0.0/0) leci przez VPN,
  • łatwiejsza centralna inspekcja (DLP, IDS/IPS) i logowanie,
  • większe obciążenie infrastruktury VPN i łącz wyjściowych.
• Split-tunnel (push „route …”):
  • przez VPN idą tylko sieci firmowe, reszta wychodzi lokalnym wyjściem do Internetu,
  • lepsza wydajność i mniejszy wpływ na user experience (np. serwisy streamingowe),
  • większe ryzyko ataków typu pivoting: host jest jednocześnie w sieci domowej i firmowej.

Dla środowisk o wysokich wymaganiach bezpieczeństwa częściej wybiera się full-tunnel plus solidny breakout Internetu z centrum danych. Split-tunnel bywa kompromisem dla mobilnych użytkowników, ale wymaga mocniejszej ochrony stacji końcowych i jasnej dokumentacji, które podsieci są dostępne przez VPN.

Szyfrowanie danych (data channel) – dobór cipher, algorytmu HMAC i PFS

Stare a nowe szyfry – co jeszcze bywa spotykane w configach

Wiele instalacji OpenVPN powstawało lata temu i do dziś wykorzystuje parametry, które obecnie uchodzą za słabe. Podstawowy przegląd zwykle ujawnia takie konstrukcje jak:

• cipher BF-CBC (Blowfish) – domyślka w starych wersjach:
  • 64-bitowy blok, przez co przy większych wolumenach danych rośnie ryzyko kolizji bloków,
  • brak sprzętowej akceleracji AES-NI, co szkodzi wydajności na nowszym sprzęcie,
  • odradzany w aktualnych wytycznych kryptograficznych.
• cipher AES-128-CBC:
  • wciąż kryptograficznie akceptowalny, ale tryb CBC jest bardziej podatny na błędy implementacyjne,
  • brak wbudowanej integralności (HMAC osobno),
  • gorsza odporność na pewne klasy ataków paddingowych przy nieostrożnej konfiguracji.

W nowszych wersjach OpenVPN preferowany jest AES w trybie GCM, najlepiej wynegocjowany przez ncp-ciphers, a nie literalnie wbity pojedynczy cipher. Przejście z CBC na GCM poprawia zarówno bezpieczeństwo (AEAD), jak i wydajność (sprzętowe AES-GCM na współczesnych CPU).

AES-GCM vs CHACHA20-POLY1305 – wady, zalety, kiedy co wybrać

W praktyce wybór zwykle sprowadza się do dwóch rodzin szyfrów: AES-GCM i ChaCha20-Poly1305. Każdy z nich ma swoje naturalne środowisko, w którym świeci najjaśniej.

• AES-256-GCM / AES-128-GCM:
  • świetna wydajność na serwerach z AES-NI (Intel/AMD),
  • powszeczne wsparcie w bibliotekach kryptograficznych i HSM,
  • dobry kompromis między mocą a zużyciem CPU w data center.
• CHACHA20-POLY1305:
  • lepsza wydajność na sprzęcie bez AES-NI (np. wiele ARM-ów),
  • prostsza konstrukcja, sprzyjająca poprawnym implementacjom,
  • dobry wybór dla klientów mobilnych i appliance’y o słabszych CPU.

Audytowo sensowne jest skonfigurowanie listy data-ciphers / ncp-ciphers tak, aby dało się negocjować obie opcje, z priorytetem dopasowanym do profilu środowiska (np. AES-GCM pierwsze dla serwerów x86 w DC, ChaCha20-POLY1305 jako preferencja w profilu klienckim dla floty ARM).

Integralność i HMAC – SHA1 do lamusa

Nawet mocny szyfr symetryczny niewiele daje, jeśli warstwa integralności stoi na glinianych nogach. W wielu starych konfiguracjach nadal można trafić na:

• auth SHA1:
  • formalnie wciąż niekatastrofalny w kontekście HMAC,
  • ale z punktu widzenia standardów (NIST, wytyczne branżowe) wypychany z nowych wdrożeń,
  • często pozostaje z przyzwyczajenia lub lenistwa migracyjnego.

Przy nowym projekcie rozsądniej używać auth SHA256 lub mocniejszych wariantów, a w konfiguracjach AEAD (AES-GCM, ChaCha20-Poly1305) opierać się na wbudowanym MAC i nie mieszać różnych poziomów integralności bez powodu. Z punktu widzenia audytu ważne jest sprawdzenie, czy używany algorytm HMAC nie jest słabszy niż reszta łańcucha – niespójność bywa pierwszym sygnałem, że konfiguracja „dojrzewała” latami bez całościowego przeglądu.

PFS na kanale danych – reneg-sec, key-method i rotacja kluczy

OpenVPN potrafi okresowo renegocjować klucze dla kanału danych. W praktyce zwykle robi się to przez:

• reneg-sec – interwał czasowy, po którym klucze są odnawiane,
• reneg-bytes – graniczna ilość danych na jedną „epokę” klucza.

Na papierze im częściej, tym bezpieczniej, ale każde odświeżenie to dodatkowy narzut na CPU i potencjalne krótkie przerwy. Dla przeciętnego access VPN ustawienia rzędu kilkunastu minut do godziny bywają sensownym kompromisem, przy czym trzeba zwrócić uwagę, aby nie pozostawiać tej funkcji wyłączonej („na zawsze ten sam klucz”) w konfiguracjach site-to-site pomiędzy zaufanymi, lecz krytycznymi lokalizacjami.

Kompatybilność wsteczna – mixed fleets i polityka „najmniejszego wspólnego mianownika”

Jedną z częstszych wymówek przeciwko twardemu odcięciu słabych szyfrów jest obecność starych klientów: stare Androidy, zapomniane routery, stare wersje OpenVPN GUI. W takim środowisku zderzają się dwie strategie:

• Najmniejszy wspólny mianownik:
  • pozwala na BF-CBC i SHA1 „bo jeszcze 3 użytkowników na tym chodzi”,
  • upraszcza wsparcie, ale obniża bezpieczeństwo wszystkich,
  • sygnał, że brakuje formalnego end-of-life dla starych klientów.
• Twardy cutoff + segmentacja:
  • główna infrastruktura akceptuje tylko nowoczesne szyfry,
  • dla wyjątków tworzy się odrębny serwer z wyraźnie opisanym ryzykiem i krótkim horyzontem życia,
  • ułatwia komunikację z biznesem: „ta usługa działa, ale tylko do daty X, potem sprzęt musi być wymieniony”.

Z perspektywy audytu korzystniejszy jest drugi model – słabsze profile są wtedy widoczne i łatwiej je wyłączyć, zamiast ciągnąć nieskończony ogon słabego szyfrowania w głównej instancji.

Warstwa TLS – wersje protokołu, zestawy szyfrów, klucz DH/ECDH

Wersja TLS – eliminacja TLS 1.0/1.1 i „legacy-only”

OpenVPN od dawna potrafi wykorzystywać nowsze wersje TLS, ale konfiguracje sprzed lat często nie zawierają jawnych ograniczeń typu tls-version-min. Skutek jest taki, że serwer zezwala na negocjację przestarzałych wersji, jeśli klient je zaproponuje.

• Środowiska konserwatywne (legacy):
  • często wciąż działają na TLS 1.0/1.1, żeby nie „odciąć” starszych klientów,
  • łatwiejsza eksploatacja, ale znacznie większa powierzchnia ataku (downgrade, stare bugi w bibliotekach TLS),
  • z punktu widzenia compliance (np. PCI-DSS) coraz trudniejsze do obrony.
• Środowiska utrzymujące minimum TLS 1.2 lub 1.3:
  • z reguły wymagają aktualnych klientów,
  • lepsza kryptografia i szybsze zestawianie połączeń,
  • wzorcowe podejście dla nowych instalacji.

Podczas audytu dobrze jest szukać jawnych dyrektyw typu tls-version-min 1.2 i sprawdzać, czy nie ma ukrytego wsparcia dla starszych wersji. Jeśli istnieje nacisk biznesowy na kompatybilność, dobrym kompromisem bywa wydzielenie osobnego frontu „legacy” z mocno ograniczonym zakresem użytkowników i jasno opisanym ryzykiem.

Profile TLS – tls-cipher vs tls-ciphersuites

Dla TLS 1.2 i 1.3 wybór zestawów szyfrów odbywa się innymi mechanizmami. Konfiguracje z epoki „wszystko w jednym worku” bywają mylące i prowadzą do niekonsekwencji, np.:

• akceptowania w TLS 1.2 szyfrów z RSA key exchange bez PFS,
• koegzystencji nowoczesnych ECDHE z historycznymi zestawami, „bo może się przyda”.

W nowym podejściu lepiej jasno zadeklarować:

• tls-version-min 1.2 plus ograniczony, przemyślany tls-cipher dla TLS 1.2,
• oddzielny tls-ciphersuites dla TLS 1.3, zawierający tylko rekomendowane kombinacje, np. z AES-GCM lub ChaCha20-Poly1305.

W audycie użyteczne bywa porównanie tych list z wewnętrzną polityką kryptograficzną organizacji (jeśli istnieje). Nierzadko okazuje się, że OpenVPN „żyje własnym życiem” obok serwerów WWW, które dawno przeszły na nowoczesne profile TLS.

DH vs ECDH – długość klucza i parametry krzywych

Parametry wymiany kluczy dla sesji TLS są równie istotne jak sam wybór szyfru. Typowy obraz w starych konfiguracjach to:

• dh 1024:
  • parametr Diffie–Hellmana zbyt krótki jak na obecne standardy,
  • zwiększone ryzyko złamania w dłuższej perspektywie,
  • często generowany raz „na zawsze” i nigdy nie odświeżany.

W nowszych configach lepiej jest iść w stronę ECDH z dobrze znanymi krzywymi (np. ECDHE-ECDSA / ECDHE-RSA na krzywych prime256v1 lub X25519), przy jednoczesnym utrzymaniu odpowiedniej długości kluczy RSA/EC dla certyfikatów serwera. Z audytowego punktu widzenia szczególnie istotne jest, czy:

• parametry DH nie są poniżej rekomendowanego minimum (2048 bitów),
• nie używa się statycznych, publicznie znanych parametrów DH z przykładowych configów,

Kluczowe Wnioski

• „Działa” nie oznacza „działa bezpiecznie” – konfiguracja OpenVPN oparta na starych szyfrach i słabym TLS może wyglądać poprawnie z perspektywy użytkownika, a jednocześnie umożliwiać podsłuch, utrudniać analizę incydentów i łamać wymagania compliance.
• Audyt ma dwa równorzędne cele: techniczny (twarde wyłączenie słabych szyfrów, protokołów i metod uwierzytelniania) oraz organizacyjny (udokumentowanie zgodności z politykami bezpieczeństwa, normami i wymaganiami klientów B2B).
• Motywacja do audytu zmienia jego zakres: po incydencie priorytetem są logi i rotacja kluczy, przy wymaganiach klienta – konkretne algorytmy i retencja logów, a przy audycie zewnętrznym – pełna dokumentacja konfiguracji i procesu zarządzania kluczami.
• Skuteczny audyt opiera się na trzech jasno nazwanych elementach: punkcie wyjścia (obecne wersje, szyfry, topologia), stanie docelowym (jakie szyfry/TLS/uwierzytelnianie chcemy wymusić) oraz ograniczeniach środowiska (legacy routery, stare systemy, limity wydajności).
• Brak uwzględnienia ograniczeń kończy się „konfiguracją idealną na papierze” – po twardym wyłączeniu słabych opcji część klientów przestaje się łączyć, co prowokuje doraźne, szerokie otwieranie konfiguracji i trwały spadek bezpieczeństwa.
• Audyt jednorazowy sprawdza się przy nowych wdrożeniach lub pojedynczych projektach (np. migracja wersji), natomiast dla krytycznej infrastruktury i środowisk regularnie audytowanych sens ma model cykliczny, np. pełny przegląd roczny plus lekkie kontrole po większych zmianach.