Znajdujesz certyfikat główny, którego nie powinno tam być, a pierwsze pytanie brzmi, czyją tożsamość może podszyć. Uczciwa odpowiedź zależy od tego, które oprogramowanie zagląda do tego magazynu i jak twój VPN weryfikuje bramę. Przeglądarka, menedżer pakietów i klient VPN z przypiętym odciskiem palca niekoniecznie dzielą tę samą decyzję o zaufaniu. Zmapuj walidatory, zanim określisz zakres.

Główny w magazynie systemowym nie jest uniwersalnym kluczem

Zainstalowanie głównego czyni certyfikaty podpisane tym kluczem akceptowalnymi dla programów korzystających z danego magazynu. Nie czyni ich automatycznie akceptowalnymi wszędzie, ponieważ niektóre aplikacje dostarczają własny pakiet lub sprawdzają przypiętą wartość. Nie dowodzi też, że ktoś uruchomił kod na maszynie; zmiana zaufania to jedna z kilku możliwości. Traktuj certyfikat jako ustalenie do ograniczenia, a nie jako cały incydent.

Magazyn ma takie samo znaczenie jak certyfikat: pakiet na poziomie użytkownika i kotwica na poziomie systemu docierają do różnych konsumentów.

Zmapuj każdy walidator i jego źródło zaufania

Zapisz każdy komponent, który waliduje certyfikaty dla objętych przepływów pracy: przeglądarka, menedżer pakietów, klient poczty, VPN. Następnie znajdź źródło zaufania, które czyta każdy z nich.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

Listing katalogu pokazuje kotwice dodane lokalnie w systemach w stylu Debiana, a lista zaufania pokazuje, co obecnie eksponuje magazyn systemowy. Przeglądarka z własnym magazynem nie pojawi się tam, a aplikacja Java lub Python może używać jeszcze innego pakietu. Zapisz, które wpisy są oczekiwane, a które nie, używając odcisku palca, a nie tylko wyświetlanej nazwy. Ta lista jest tym, czego potrzebuje osoba reagująca na incydent, zanim cokolwiek usunie.

Sprawdź własną walidację partnera w VPN

VPN z prywatnym CA lub jawnym odciskiem palca ocenia bramę według własnej konfiguracji. Porównaj to, czego oczekuje klient, z tym, co prezentuje brama.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

Dane wyjściowe podają odcisk palca SHA-256 i temat certyfikatu prezentowanego przez punkt końcowy, które można porównać ze skonfigurowaną wartością. OpenVPN ma opcję odcisku palca partnera, która wykonuje to porównanie dla tunelu bez wymagania, by magazyn systemowy zaakceptował podpisującego. Ta niezależność jest przydatna dla tunelu i nic nie mówi o przeglądarce. Nie pomoże też, jeśli oczekiwany odcisk palca został od początku skopiowany z podejrzanego połączenia.

Określ zakres incydentu poza certyfikatem

Użyj procedury właściciela urządzenia, aby usunąć nieautoryzowane kotwice i poszukać zmian, które zwykle im towarzyszą: nowych usług, zmodyfikowanych klientów, zmienionych ustawień proxy. Na maszynie zarządzanej potwierdź legalną konfigurację, zanim usuniesz materiał, od którego zależy inne oprogramowanie. Dla każdego walidatora zapisz, skąd pochodzi jego zaufanie, jakiej tożsamości oczekuje i jak potwierdziłeś, że bieżąca konfiguracja jest poprawna. Działający tunel po czyszczeniu to jedna obserwacja, a nie dowód, że punkt końcowy jest czysty.

Następnie ponownie przetestuj przepływy pracy, które korzystały z magazynu, ponieważ usunięcie kotwicy może zepsuć usługę wewnętrzną, która zgodnie z prawem na niej polegała. Odzyskiwanie jest zakończone, gdy oczekiwane relacje zaufania działają, a nieoczekiwane nie.

Powiązane artykuły