Twój klucz VPN jest czytelny dla wszystkich: co naprawić

Pierwszym sygnałem jest zwykle ostrzeżenie, a nie awaria. Klient odmawia wczytania klucza, ponieważ plik jest czytelny dla grupy lub dla wszystkich, albo audyt bezpieczeństwa znajduje client.key w trybie 644 w katalogu profilu, w którym są też wyeksportowane pakiety. Nic jeszcze nie zawiodło i właśnie dlatego ostrzeżenie jest ignorowane. Klucz działa, tunel się podnosi, a plik jest czytelny dla każdego konta na maszynie.

Objawem jest ostrzeżenie o uprawnieniach, nie awaria

W systemie typu Unix klucz prywatny powinien być czytelny tylko dla konta, które uruchamia usługę. Tryb 600 z właściwym właścicielem to zwykłe rozwiązanie. Tryb 644 oznacza, że każdy lokalny użytkownik może skopiować klucz, a na współdzielonym hoście budowania to realna publiczność.

Klienci, którzy to sprawdzają, wyświadczają ci przysługę. Ci, którzy nie sprawdzają, nie są dowodem, że plik jest bezpieczny, a udane połączenie nic nie mówi o tym, kto jeszcze może czytać materiał, który je umożliwił. Traktuj ostrzeżenie jako całe ustalenie. Jest trafne i przyszło, zanim ktokolwiek skopiował plik.

Dopasuj tryb do tożsamości usługi

Dostęp tylko dla właściciela pasuje do klucza używanego przez tego właściciela. Usługa z celowo współdzieloną grupą może potrzebować innego kontrolowanego układu, na przykład odczytu grupowego klucza należącego do konta usługi. Ustawianie wszystkim plikom na ślepo jednego trybu liczbowego psuje obsługiwane klienty, a chmod -R 777 nie jest rozwiązaniem niczego.

Sprawdź właściciela i konto usługi, zanim cokolwiek zmienisz. Publiczne certyfikaty CA i prywatne klucze tożsamości mają różne wymagania dotyczące tajności, nawet gdy leżą w tym samym katalogu, więc tryb rekurencyjny na całym folderze traktuje oba jak ten sam obiekt.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

Na innych platformach używaj udokumentowanego magazynu kluczy lub modelu kontroli dostępu, zamiast tłumaczyć tryby Unix na zgadywanie. Nazwa pliku kończąca się na private to etykieta, a nie mechanizm egzekwowania.

Znajdź kopie, których tryb nie obejmuje

Edytory, archiwa kopii zapasowych, wyeksportowane profile i tymczasowe pakiety mogą każdy zachować tę samą tożsamość. Chroń te kopie zgodnie z ich zawartością, bo zaostrzenie oryginalnego pliku nic nie daje kopii w tarze z zeszłego miesiąca.

Hasło na pliku klucza jest przydatne dla przechowywanego materiału i nie uzasadnia publikowania zaszyfrowanego pliku obok jego hasła. Uprawnienia chronią bieżący obiekt systemu plików; nie mówią nic o danych logowania skopiowanych już gdzie indziej.

Poszukaj kopii, zanim uznasz pracę za skończoną: grep -rl wiersza nagłówka klucza w prawdopodobnych katalogach i rzut oka na wyjątki kopii zapasowych. Wynik jest zwykle ciekawszy niż plik, od którego zacząłeś.

Po poprawce zweryfikuj i wymień

Sprawdź, czy docelowa usługa nadal się uwierzytelnia, a potem potwierdź, że żadne niepotrzebne konto nie uzyskało dostępu. Ogranicz dane diagnostyczne do metadanych, bo drukowanie klucza nie jest potrzebne, by udowodnić czytelność pliku a umieszcza materiał w logu.

Jeśli klucz został ujawniony, zaostrz tryb, a następnie wymień dane logowania i unieważnij stare. Specyfikacja POSIX chmod wyjaśnia, co oznacza każdy bit trybu, co warto wiedzieć, zanim następny audyt poprosi cię o uzasadnienie wybranej liczby.