OpenConnect csd-wrapper: sprawdź skrypt przed logowaniem

Dodanie --csd-wrapper do profilu przekazuje lokalny skrypt demonowi, który uruchamia go podczas logowania, więc decyzja przed tobą to przegląd kodu, a nie przełącznik preferencji. Opcja istnieje po to, by można było zastąpić komponent sprawdzania hosta bramy, i przyjmuje ścieżkę do skryptu, który dostarczasz. Wszystko poniżej zakłada, że właściciel wdrożenia powiedział już, jaki test postawy jest wymagany; jeśli ta część jest nadal otwarta, rozstrzygnij ją najpierw. Procedura ma cztery kroki: zlokalizuj nieudany etap, przeczytaj skrypt, wybierz tożsamość, w której kontekście działa, i udowodnij wynik.

Krok 1: Zlokalizuj nieudany etap

Ostatni komunikat klienta zwykle dotyczy pliku cookie, czyli końca łańcucha, a nie jego początku. Logowanie HTTPS, sprawdzenie certyfikatu serwera, wymiana uwierzytelniania i komponent postawy stoją wszystkie przed tym komunikatem.

Zapisz wersję i używany adres logowania, a następnie powtórz próbę, zostawiając szczegółowe wyjście na własnym terminalu. Czytaj pierwszy błąd, który nie jest ponowną próbą, a nie ostatnią linię transkryptu. Jeśli dziennik zatrzyma się, zanim zostanie nazwany jakikolwiek komponent oceny, opakowanie nie jest jeszcze twoim problemem. Dodanie go w tym momencie tylko poszerza powierzchnię, której będziesz musiał później bronić.

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

Trzymaj transkrypt lokalnie, bo pliki cookie i odpowiedzi uwierzytelniania to materiał dostępowy. Ślad wklejony do wątku czatu to wyciek danych logowania, nawet gdy krok oceny wygląda nieszkodliwie. Udostępniaj tekst błędu i miejsce w przepływie, w którym się pojawił, nigdy zawartości.

Krok 2: Przeczytaj skrypt, zanim trafi do profilu

Opakowanie jest tak wiarygodne, jak przeglądana wersja, więc przypnij tę wersję i zapisz jej skrót obok notatki o zatwierdzeniu. Dwie poniższe komendy dają odcisk palca i tanią kontrolę składni, zanim przeczytasz choć jedną linię. Dają też następnej osobie stały odnośnik, co ma znaczenie, gdy plik żyje poza zarządzaniem pakietami. Żadna z komend nie mówi, co robi skrypt, więc uruchom je i czytaj dalej.

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

Przeczytaj cały plik z czterema pytaniami w głowie: czy wykonuje wychodzące wywołania HTTP, czy czyta pliki danych logowania lub zmienne środowiskowe, czy pisze poza katalogiem tymczasowym, i czy któraś gałąź zgłasza zaliczoną postawę, niczego nie mierząc. Ten ostatni wzorzec to obejście polityki z doczepioną linią dziennika. Skopiowane opakowania mają zwyczaj przemycać go za pozornie wiarygodnym sprawdzeniem. Jeśli skrypt stwierdza, że urządzenie jest w porządku, zanim na nie spojrzy, zatrzymaj się tam.

Sprawdź też spakowane ładunki, bo czytelny nagłówek niczego nie dowodzi co do reszty pliku. Pobranie skryptu z wątku forum nie czyni go wiarygodnym tylko dlatego, że jego nazwa przypomina prawdziwy komponent sprawdzania hosta. Zapisz, kto go zainstalował, skąd pochodzi i jak będzie aktualizowany.

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

Krok 3: Wybierz tożsamość, w której kontekście działa opakowanie

--csd-user obniża uprawnienia, gdy wykonywany jest program CSD, TNCC lub HIP. To konto jest częścią lokalnego układu wykonywania, a nie nazwą użytkownika przekazywaną bramie.

Daj opakowaniu dedykowane konto bez interaktywnej powłoki, bez praw sudo i bez członkostw w grupach, których nie potrzebuje. Przyznaj dostęp do odczytu skryptu i konkretnych plików, które on sprawdza, a potem przetestuj obniżenie uprawnień, zanim dotkniesz profilu VPN. Znalezienie problemu tutaj jest tańsze niż znalezienie go wewnątrz klienta.

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

Obniżenie uprawnień ogranicza szkody, jakie może wyrządzić zły skrypt. Nie przegląda jednak kodu, nie czyni raportu prawdziwym i nie ustala, że administrator bramy akceptuje tę implementację jako spełnienie polityki urządzeń.

Krok 4: Utrzymaj zmianę odwracalną

Zrób kopię zapasową profilu przed edycją i trzymaj opakowanie pod kontrolą wersji, aby wycofanie przywróciło znany skrót, a nie szukało kopii. Zapisz ścieżkę skryptu, skrót, użytkownika wykonania i zatwierdzającego w jednym miejscu.

Aby wycofać, usuń opcję, uruchom ponownie klienta i potwierdź, że pierwotny błąd powraca. Jeśli brama nadal odrzuca logowanie po wycofaniu, zmieniło się też coś innego, a znalezienie tej różnicy poprzedza ponowną próbę z opakowaniem. Zachowaj poprzednią kopię przez cały okres zmian, co dla większości zespołów oznacza do końca następnego okna serwisowego.

Po udanym wdrożeniu sprawdź dwie rzeczy, a nie jedną: tunel się podnosi, a urządzenie, które powinno nie przejść testu postawy, nadal jest odrzucane. Połączenie, które działa dla wszystkich, nie jest dowodem, że ocena przetrwała twoją zmianę.

Skróty, które tworzą drugi problem

Nie pozwól pomocnikowi zgłaszać stanu zgodnego bez uruchomienia wymaganych sprawdzeń i nie nadpisuj tożsamości platformy, aby dopasować ją do innego systemu operacyjnego. Twierdzenie o innej platformie nie jest dowodem, że rzeczywiste urządzenie spełnia politykę. Zostawia cię to z klientem, który kłamie przy każdym przyszłym logowaniu.

Wyłączenie weryfikacji serwera, odtworzenie starego pliku cookie i piętrowanie nieprzejrzanych skryptów zamieniają widoczną porażkę na niewidoczną. Jeśli zainstalowany klient nie potrafi ukończyć obsługiwanego przepływu, poproś o zatwierdzoną alternatywę, zamiast naginać ten, który masz.

Podręcznik OpenConnect dokumentuje --csd-wrapper i --csd-user osobno, i to jest wskazówka, która ma znaczenie: skrypt i tożsamość to dwie decyzje. Przejrzyj je osobno i zapisz obie. Wtedy monit logowania przestaje być zagadką, którą rozwiązujesz, wklejając kod.