Którego procesu VPN dotyczy to wykrycie luki?

Wynik skanera wskazuje adres, port i coś, co tam wynegocjowano. Nie wskazuje procesu stojącego za tym gniazdem, a na hoście VPN kilka procesów może dzielić maszynę, choć tylko jeden z nich jest tunelem. Odczyt ciągu wersji z narzędzia pomocniczego lub znalezienie pliku biblioteki na dysku dodaje dowody o hoście, nie o nasłuchującym procesie. Wykrycie staje się możliwe do działania dopiero wtedy, gdy zostanie przypisane do jednego działającego komponentu, a następnie porównane z zakresem, który biuletyn faktycznie podaje.

Kolejność ma znaczenie: najpierw komponent, potem biuletyn, na końcu naprawa.

Raport wskazuje port, a nie program

Zacznij od punktu końcowego, który faktycznie oceniono. Sonda przeciw portowi administracyjnemu HTTPS zmierzyła usługę webową, jej stos TLS i dowolny proxy przed nią; nie dowiedziała się nic o nasłuchującym OpenVPN lub WireGuard na innym porcie. Odwrotne proxy i agenci zarządzania pogarszają sprawę, bo certyfikat i baner mogą należeć do frontendu, podczas gdy podatna biblioteka znajduje się za nim w procesie backendu.

Zapisz cel, transport, port i nazwę usługi razem z wynikiem, aby zakres podążał za wykryciem.

Czym jest naprawdę działająca kompilacja

Na hoście ogólnego przeznaczenia zainstalowany pakiet i wczytana biblioteka to dwa osobne pytania. Baza pakietów może wymieniać załataną wersję, podczas gdy długo działający demon wciąż trzyma stary obiekt współdzielony w pamięci, a wbudowany obraz urządzenia może nieść własne biblioteki, o których nie informuje żaden menedżer pakietów. Zapytaj menedżera usług, co działa, a następnie zbadaj proces i jego powiązania.

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

Czas uruchomienia na liście procesów to szczegół, który ludzie pomijają. Demon uruchomiony przed ostatnią aktualizacją pakietów nadal wykonuje kompilację wczytaną przy starcie, i to jest dokładnie ten przypadek, w którym inwentarz mówi załatane, a gniazdo mówi coś innego.

Dopasowanie kompilacji do zakresu biuletynu

Biuletyny opisują produkty, wersje i czasem wymagane warunki, a te trzy pola nie zawsze pokrywają się z wersją pakietu. Biuletyn OpenVPN o Heartbleed z kwietnia 2014 to użyteczny przykład historyczny, ponieważ oddziela dotknięte wydania Access Server od usług webowych i demonów VPN, które miały inną ekspozycję. Lekcja polega na czytaniu, którego komponentu dotyczy tekst, a nie na dopasowywaniu wzorca do słowa OpenSSL.

Ten biuletyn jest też przestarzały. Jego załatane numery wydań nie są dziś poradą instalacyjną, a usterka naprawiona w 2014 nic nie mówi o późniejszych problemach w gałęzi, którą dziś prowadzisz.

Rozstrzygnięcie rozbieżności, potem zamknięcie ekspozycji

Gdy inwentarz i ocena się nie zgadzają, sprawdź, czy oba opisują ten sam punkt końcowy i to samo środowisko uruchomieniowe: inny adres, proxy frontendowe, drugą usługę, stary proces wciąż związany z portem lub wbudowaną bibliotekę, której menedżer pakietów nigdy nie widział. Rozstrzygnij to na granicy, zanim przepiszesz raport.

Zastosuj obsługiwaną poprawkę, uruchom ponownie dotkniętą usługę i potwierdź, że nowa kompilacja jest teraz aktywna. Załatany plik na dysku, gdy stary proces nadal obsługuje ruch, nie jest naprawą.

Następnie zajmij się tym, co komponent mógł przechowywać w oknie ekspozycji. Łatanie i wymiana danych uwierzytelniających odpowiadają na różne pytania, a certyfikat przechowywany blisko dotkniętego hosta sam w sobie nie jest listą tego, co wyciekło. Postępuj według procedury właściciela incydentu dotyczącej unieważnienia, usuwania sesji i aktualizacji klientów, i zapisz, który komponent został dotknięty, dlaczego dowody miały zastosowanie i co go zamknęło. Ten zapis przeczyta późniejszy przegląd.