Czy ta poprawka bezpieczeństwa OpenVPN dotyczy w ogóle twojej instalacji?

Rada, by załatać klienta tak, aby weryfikował certyfikaty, jest zbyt ogólna, by na niej działać. Może opisywać naprawiony błąd oprogramowania, stary build jednego dostawcy lub profil, który nigdy nie prosił o tę kontrolę. To trzy różne zmiany z trzema różnymi właścicielami. Działanie na podstawie tego zdania bez wiedzy, z którą z nich masz do czynienia, to sposób, w jaki działający klient zostaje zmieniony bez powodu.

Oddziel trzy twierdzenia

Błąd oprogramowania ma biuletyn, dotknięte wersje i naprawione wydanie. Build dostawcy ma własny kanał dystrybucji i własne tempo aktualizacji. Pominięcie w profilu nie ma żadnego z nich, bo plik wykonywalny jest w porządku, a konfiguracja wymaga mniej, niż zakładałeś. Dopóki twierdzenie nie nazwie jednego z tych trzech, nie ma czego testować.

Zapisz twierdzenie w jednym zdaniu, zanim go poszukasz. Jeśli zdanie nie potrafi nazwać, co jest zepsute, wyszukiwanie nie ma celu i każdy wynik wydaje się trafny.

Znajdź plik wykonywalny, który naprawdę działa

Zidentyfikuj, co uruchamia połączenie, zanim spojrzysz na jakąkolwiek wersję. Usługa dystrybucyjna, wtyczka pulpitu i aplikacja dostawcy mogą każda używać innego pliku wykonywalnego lub silnika. Wersja wypisana przez dowolny plik binarny, który przypadkiem znajduje się w ścieżce wyszukiwania powłoki, nie jest inwentarzem maszyny. Przeczytaj jednostkę lub proces, który faktycznie wykonał połączenie.

systemctl cat openvpn-client@*.service
ps -o pid,cmd -C openvpn
apt-cache policy openvpn network-manager-openvpn

Zapytanie o pakiet podaje, co lokalne metadane uważają za zainstalowane i dostępne, a ten cache może być nieaktualny, więc najpierw go odśwież. Nie mówi też nic o tym, czy działająca usługa załadowała plik binarny zainstalowany pięć minut temu. Porównaj rekord pakietu z procesem, który jest faktycznie połączony.

Dowody z pakietu zamiast wrażeń o wersji

Utrzymanie bezpieczeństwa dystrybucji często przenosi poprawki wstecz, więc starsza wyglądająca wersja upstream może nadal zawierać łatkę. Jest też odwrotnie: pakiet z nieznanego repozytorium nie ma automatycznego prawa do bieżącego utrzymania. Czytaj status wsparcia wydania, a nie numer wersji.

Ta różnica to różnica między prawdziwą luką a liczbą, która tylko wygląda staro. Zanotuj repozytorium, z którego pochodzi pakiet, bo ten sam ciąg wersji może przyjść bardzo różnymi kanałami z bardzo różnym wsparciem.

Konfiguracja to druga połowa

Utrzymywany plik wykonywalny nadal potrzebuje profilu, który wymaga kontroli, które uważasz za obecne. Kotwice zaufania, zamierzona rola drugiej strony i oczekiwana nazwa serwera to decyzje powiązane, ale odrębne. Sprawdzenie roli nie jest sprawdzeniem nazwy i żadne nie zastępuje drugiego. Jeśli ostrzeżenie dotyczy konfiguracji, poprawka należy do tego, kto posiada profil.

Nie instaluj dowolnej łatki, aby zrekompensować niezweryfikowany profil, i nie dodawaj dyrektywy, aby naprawić prawdziwy błąd implementacji. Oba błędy wydają się postępem, dlatego oba wciąż się zdarzają.

Decyduj na podstawie dowodów w rejestrze

Decyzja wynika z tego, co ustaliłeś. Udokumentowany dotknięty pakiet wymaga wspieranej aktualizacji, nieobsługiwana platforma potrzebuje ścieżki migracji, a klient dostawcy potrzebuje wskazówek tego dostawcy. Niejednoznaczna instrukcja wymaga biuletynu i dotkniętego komponentu, zanim cokolwiek z tego zostanie zastosowane.

Trzymaj aktywnego klienta, pełną wersję, biuletyn i właściciela profilu razem w rejestrze zmian. To mocniejsze niż odwołanie do poradnika i to jest to, czego naprawdę będzie potrzebować następna osoba.