Twój plik .ovpn może wykonywać kod, nie tylko kierować ruchem

Większość ludzi czyta plik .ovpn tak, jak czyta stronę ustawień routera: adresy, trasy, lista szyfrów. Część wykonująca kod znajduje się blisko dołu, obok dyrektyw wyglądających jak prace hydrauliczne, i działa z uprawnieniami, które klient już ma. To luka, którą wykorzystuje nieostrożny lub złośliwy profil, i to także luka, która po trzech tygodniach zamienia pomocny skrypt DNS w problem wsparcia. Dyrektywa zdarzenia, poziom bezpieczeństwa i właściciel pliku decydują, co może się stać; zawartość skryptu decyduje, co dzieje się naprawdę. Przeczytaj wszystkie cztery, zanim się połączysz.

Profil uruchamiający pomocnik to program, a nie plik ustawień

Dyrektywy takie jak route i dhcp-option opisują stan, który klient ma ustanowić, a klient traktuje je jak dane. Skrypt up jest inny: klient uruchamia go jako proces i przekazuje środowisko pełne szczegółów połączenia, więc wszystko, co napisał jego autor, działa z prawami twojego konta. Na laptopie, gdzie użytkownik jest administratorem, to szerokie drzwi dla pliku, który przyszedł jako załącznik albo wklejka z wątku forum. Różnica nie jest stylistyczna, to różnica między konfiguracją a kodem.

Mit, który warto porzucić, głosi, że profil może tylko przekierować ruch. Pomocnik uruchamiający ip route add i ten uruchamiający curl wobec zdalnego hosta to ten sam mechanizm, a profil wygląda identycznie z zewnątrz. Nic w wyglądzie pliku nie mówi, który masz, dlatego przegląd musi dotrzeć do samego skryptu.

Co naprawdę decyduje o wykonaniu i jak wyglądają linie, które je umożliwiają

Pomocnikiem rządzą trzy rzeczy: dyrektywa zdarzenia, która go nazywa, poziom script-security, który na niego pozwala, oraz własna implementacja platformy klienta. Profil może zażądać haka i mimo to nic nie zobaczyć, bo klient mobilny albo okrojona kompilacja desktopowa może w ogóle nie implementować tego zdarzenia. Podobnie profil, który prosi o więcej uprawnień, niż potrzebuje jego funkcja, mówi coś o swoim pochodzeniu. Poziom uprawnień to możliwość, nie zgoda. Linie, które to umożliwiają, wyglądają tak, a ścieżka zastępuje twoją.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Poziom 0 odrzuca programy zewnętrzne, a poziom 1, domyślny, zezwala tylko na wbudowane pliki wykonywalne klienta, więc hak wymaga 2 lub wyższego; poziom 3 istnieje głównie do przekazywania starych haseł i lepiej go unikać. Profil dostarczony z hakiem wymaga zarówno dyrektywy, jak i tego poziomu, dlatego jedna linia przy dole pliku zasługuje na taką samą kontrolę jak blok certyfikatu. Podręcznik OpenVPN wymienia poziomy uprawnień, a jego sformułowanie warto czytać obok tego, o co profil naprawdę prosi.

Własność, ścieżka i czym karmi się pomocnik

Profil, któremu ufasz, ale który wskazuje skrypt mogący zostać przepisany przez inne konto, nie jest godnym zaufania układem, bo wczorajsza kontrola nie opisuje już tego, co działa dziś. Sprawdź właściciela i tryb pomocnika oraz to, czy skonfigurowana ścieżka prowadzi do pliku, który zbadałeś, a nie do nazwy, którą coś innego może przesłonić. Argumenty i środowisko zasługują na to samo spojrzenie: klient przekazuje szczegóły połączenia hakowi, a pomocnik rejestrujący całe swoje środowisko może zapisywać dane uwierzytelniające w zgłoszeniu do wsparcia. Przedkładaj udokumentowaną integrację od operatora lub platformy nad skrypt DNS skopiowany z niepowiązanego wpisu, bo dwóch menedżerów resolverów walczących o ten sam plik daje awarię wyglądającą jak zepsuty VPN.

Gdy zgłaszasz zawodzący hak, zredaguj środowisko, zanim wkleisz je gdziekolwiek. Zrzut pomagający w debugowaniu może też nieść token, który cię uwierzytelnia.

Awarie sprzątania pojawiają się po zniknięciu tunelu

Pomocnik up dodaje trasy i ustawienia resolvera, a pomocnik down powinien je znowu usunąć. Gdy haka down brakuje, zawodzi po cichu albo nigdy się nie uruchamia, bo klient został zabity, pozostałości przeżywają sesję. Ruch idzie wtedy drogą, której nikt nie planował, a nazwy rozwiązuje resolver, który powinien zostać usunięty, podczas gdy sam tunel wygląda zdrowo. Te objawy przychodzą po rozłączeniu, dlatego wini się sieć, a nie profil.

Przetestuj demontaż jako osobny krok: podnieś tunel, zanotuj trasy i resolver, opuść go, a potem potwierdź, że oba zniknęły. Profil, który łączy się czysto, wciąż może zostawić stan, a zerowy kod wyjścia pomocnika nie dowodzi, że resolver wylądował tam, gdzie myślisz.

Przegląd pomocnika i zachowanie wyjścia

Przeczytaj skrypt od początku do końca, szukając trzech rzeczy: poleceń wymagających uprawnień, zaszytych na stałe ścieżek, których może nie być w twoim systemie, oraz każdego wywołania sieciowego, które wykonuje. Potem zobacz, jak zawodzi, bo pomocnik połykający błędy zamienia błąd konfiguracji w zagadkę. Jeśli nie potrafisz jednym zdaniem powiedzieć, co robi skrypt i kto może go zmienić, nie jesteś gotowy, by go włączyć. Profil proszący o więcej uprawnień, niż wymaga to zdanie, jest sygnałem, by się zatrzymać.

Trzymaj ostatni działający profil i pomocnika, na który wskazywał, w chronionym magazynie, z zanotowanymi obiema wersjami, żeby wycofanie było kopią, a nie odbudową w najgorszym możliwym momencie. Jeśli pomocnik istnieje tylko dla dystrybucji lub wersji klienta, która już go nie potrzebuje, wycofaj go w konfiguracji, która posiada to ustawienie, zamiast podnosić uprawnienia, aż błędy ustaną. To jest wyjście: mniej ruchomych części, nie więcej uprawnień.