Źródło APT VPN: co daje i jak je ograniczyć

Pobranie klienta VPN to jednorazowa decyzja; dodanie jego repozytorium APT już nie. To drugie mówi menedżerowi pakietów, skąd może pochodzić przyszłe oprogramowanie, a jest to trwałe przekazanie uprawnień, a nie pobranie. Może to być właściwe rozwiązanie, gdy dostawca należycie utrzymuje repozytorium. Mimo to zasługuje na świadomą decyzję, a większość poradników instalacji to pomija.

Podpis uwierzytelnia archiwum, a nie jego kod

APT weryfikuje podpisane metadane repozytorium, a następnie ufa sumom kontrolnym w tych metadanych w przypadku pobieranych pakietów. Dowodzi to, że archiwum odpowiada temu, co opublikował posiadacz klucza, i niczego nie mówi o kodzie w środku. Poprawnie podpisany pakiet nadal może zawierać niebezpieczne skrypty opiekuna, a skrypty te działają jako root podczas instalacji pakietu. Podręcznik apt-secure wyznacza dokładnie tę granicę między uwierzytelnieniem archiwum a przeglądem oprogramowania.

Zatem użyteczne pytanie nie brzmi, czy podpis jest ważny, bo uszkodzony podpis i tak zatrzyma instalację. Brzmi ono, czyjemu podpisowi wybierasz zaufanie od teraz. Skradziony klucz podpisujący jest gorszy niż skradziony pakiet, ponieważ atakujący nadal tworzy ważne metadane długo po pierwszym złym wydaniu. Jedyną naprawą jest rotacja klucza, a zależy ona od tego, czy dostawca opublikuje nowy klucz kanałem, który możesz niezależnie zweryfikować.

Dlatego tożsamość klucza zasługuje na tyle samo uwagi co adres URL repozytorium. Klucz wzięty z adresu w starej odpowiedzi na forum niczego nie dowodzi o wydawcy, podczas gdy HTTPS chroni transport do tego, kto odebrał telefon. Bezpieczeństwo transportu i tożsamość wydawcy to odrębne pytania, a tylko pierwsze rozwiązuje certyfikat.

Ogranicz klucz do źródła, a nie do systemu

Nowoczesny APT przyjmuje odwołanie Signed-By właściwe dla źródła. Klucz zarządzany przez operatora może znajdować się w /etc/apt/keyrings/, a wpis źródła wskazuje klucz, który może uwierzytelnić to archiwum. To węższe niż wrzucenie tego samego klucza do globalnego zaufanego zbioru, gdzie może poręczać za źródła, których nigdy nie chciałeś dopuścić. Postępuj zgodnie z zainstalowaną wersją APT i bieżącymi instrukcjami dostawcy, zamiast mieszać fragmenty poradników z różnych pokoleń.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Nigdy nie naprawiaj błędu podpisu przez wyłączenie weryfikacji lub oznaczenie nieznanego archiwum jako zaufanego. To zamienia widoczny błąd na niewidoczny, a niewidoczny trwa, dopóki ktoś nie przejrzy listy źródeł. Jeśli klucz się nie zgadza, właściwą poprawką jest znalezienie właściwego klucza, a nie usunięcie sprawdzenia.

Uzyskaj szczegóły repozytorium i tożsamość klucza od projektu lub zarządzanego administratora. Klucz skopiowany z wpisu na blogu jest twierdzeniem o autorstwie, a nie jego dowodem. Gdy dostawca publikuje kanał rotacji, zapisz go razem z kluczem, ponieważ to ten kanał umożliwia kolejną rotację.

Przypinanie źródła nie jest listą dozwolonych pakietów

Ograniczenie klucza do jednego źródła ogranicza to, które archiwum może uwierzytelnić, a nie to, które pakiety to archiwum może publikować. Repozytorium może dostarczyć znacznie więcej niż pożądany klient VPN, a o tym, która kwalifikująca się wersja wygra, decydują wybór kandydata i priorytety APT. Przejrzyj proponowaną transakcję przed potwierdzeniem, łącznie z listą zależności, ponieważ zależności pochodzą z tego samego archiwum. Zakres klucza nie potrafi wyrazić „tylko ten pakiet”.

Jeśli potrzebujesz silniejszej kontroli, wyraź ją jako politykę dotyczącą nazw lub wersji pakietów i utrzymuj tę politykę w zarządzaniu konfiguracją. Przeczytanie transakcji zajmuje minutę; odkrycie nieoczekiwanego pakietu pół roku później zajmuje przegląd.

Nieoczekiwane pakiety to moment, by się zatrzymać, a nie iść dalej, a pytanie do właściciela archiwum brzmi, dlaczego są potrzebne. Repozytorium publikujące tuzin pakietów wokół jednego klienta jest normalne u dostawcy dostarczającego pakiet biurowy. To także większa powierzchnia, niż sugerował poradnik instalacji, i właśnie tę część warto zapisać. Żaden z tych wyników nie jest powodem do nieufności wobec podpisu; oba są powodem, by zapisać, co zaakceptowałeś.

Zapisz uprawnienie i sposób jego usunięcia

Zapisz właściciela archiwum, obsługiwane wydanie systemu operacyjnego, kanał rotacji klucza i procedurę usunięcia. Te cztery fakty są tym, czego potrzebuje następca, gdy klient jest wycofywany lub dostawca rotuje swój klucz. Bez nich kolejna osoba dziedziczy wiersz źródła i plik klucza bez żadnej historii.

Usunięcie to krok, który się pomija, więc zapisz go przy instalacji. Usuń wpis źródła i jego dedykowany klucz razem, i sprawdź, czy ten klucz nie jest używany gdzie indziej, zanim usuniesz plik. Wspólny klucz usunięty bez tego sprawdzenia zamienia porządki w niezwiązany przestój, co jest najgorszym wynikiem rutynowej zmiany. Następnie potwierdź, że zwykłe aktualizacje nadal się rozwiązują, gdy wpis zniknie.

Jedna rzecz pozostaje po usunięciu repozytorium: każdy już z niego zainstalowany pakiet działa dalej, dopóki coś go nie zastąpi. Uczciwe pytanie brzmi, jakie uprawnienie dodałeś i jak wąsko wyrażono jego rolę.