Eksport NFS przypięty do adresu VPN: czego to nie dowodzi

Host eksportuje katalog na adres VPN, montowanie się udaje, a projekt zostaje zapisany jako uwierzytelniony. To, co ta reguła naprawdę ogranicza, to skąd pakiety wydają się pochodzić. To, czy osoba prowadząca operację na plikach jest tym, za kogo się podaje, zależy od profilu bezpieczeństwa NFS, a w większości takich eksportów nikt nie zmienił go względem domyślnego.

W jednym żądaniu mogą pojawić się trzy tożsamości

Partner VPN niesie zarejestrowaną tożsamość, taką jak certyfikat klienta lub klucz partnera. Wewnętrzny pakiet IP niesie adres źródłowy. Operacja na plikach niesie te dane uwierzytelniające użytkownika, które dostarcza jej mechanizm NFS. Projekt, który traktuje adres jako zastępstwo wszystkich trzech, po cichu założył właśnie tę część, którą należało zweryfikować.

Zapisanie tych trzech wierszy to całe ćwiczenie. Większość sporu o to, czy eksport jest bezpieczny, upada, gdy staje się jasne, w którym wierszu żyje która kontrola.

Własność adresu to szczegół implementacji

Brama może przypisać zaakceptowanemu partnerowi adres tunelu albo autoryzować dla niego trasowaną podsieć. To, czy implementacja odrzuci potem pakiet, którego wewnętrzne źródło należy do innego klienta, jest właściwością tej implementacji, i warto to sprawdzić, a nie zakładać.

Kod serwera w przestrzeni użytkownika tradycyjnego Community OpenVPN może na przykład odrzucić źródło powiązane z innym klientem, zanim pakiet zostanie dostarczony przez urządzenie TUN. To kontrola własności adresu o realnej wartości, i nadal nie jest uwierzytelnieniem użytkownika NFS, bo nic nie mówi o tym, które konto wykonuje operację.

Tłumaczenie źródła podkopuje nawet to. Brama NAT może przedstawić każdego klienta jako jeden adres, a wtedy reguła eksportu nie potrafi odróżnić osób stojących za nim. Pozorna precyzja reguły staje się wtedy fikcją podtrzymywaną przez diagram. Jeśli eksport ma znaczenie, zachowaj adresowanie jawnie, zamiast pozwalać tłumaczowi decydować, kto liczy się jako kto.

Przeczytaj profil bezpieczeństwa, zanim zaufasz eksportowi

Przewodnik Red Hat dotyczący NFS oddziela sec=sys, który używa lokalnych UID i GID systemu UNIX przez AUTH_SYS, od trybów Kerberos. krb5 dodaje uwierzytelnianie użytkownika, krb5i dodaje ochronę integralności, a krb5p dodaje ochronę prywatności ruchu.

Dane AUTH_SYS zawierają pola, takie jak UID wywołującego i identyfikatory grup, a RFC 5531 wyraźnie ostrzega, że ten profil sam w sobie nie zapewnia bezpieczeństwa i zależy od ochrony zewnętrznej. Uruchamianie go wewnątrz VPN zapewnia ochronę transportu i niczego nie zmienia w twierdzeniu wewnątrz pakietu.

exportfs -v
showmount -e nfs.example.internal

Przeczytaj profil w tym wyniku, zanim przeczytasz listę klientów. Eksport, który wygląda na ograniczony, może być ograniczony tylko adresem, podczas gdy każdy wywołujący nadal deklaruje dowolny UID.

Wybierz model, a potem zachowaj uprawnienia

Wybierz model uwierzytelniania usługi plików odpowiedni dla klientów, którymi naprawdę administrujesz. Kerberos wymaga tożsamości i wdrożenia usługi za sobą, więc zmiana jednej opcji montowania nie jest migracją i po prostu zawiedzie, dopóki nie istnieją domena Kerberos, principala i pliki keytab.

W obu modelach zachowaj uprawnienia eksportu i autoryzację systemu plików, które ograniczają to, co może robić uwierzytelniona principal. Uwierzytelnianie mówi, kto pyta; autoryzacja decyduje, czy odpowiedź powinna być twierdząca. Zlanie obu w jedno ustawienie to sposób, w jaki migracja kończy się przyznaniem więcej niż stara konfiguracja.

Używaj reguły adresu do jej rzeczywistego celu

Ograniczanie usługi do zatwierdzonej ścieżki i źródeł nadal ma sens, łącznie z polityką wejścia hosta, gdy punkt końcowy VPN i serwer NFS dzielą maszynę. Reguły przekazujące ruch nie rządzą żądaniami kierowanymi do usługi działającej lokalnie na tym samym hoście. Ta luka wyjaśnia zaskakująco wiele eksportów, które miały być prywatne. Sprawdź jawnie lokalną politykę wejścia, zamiast zakładać, że reguły tunelu ją obejmują.

Sprawdź, czy inny interfejs lub brama z tłumaczeniem źródła nie może niespodziewanie spełnić reguły, i traktuj to jako powód, by ustalić pochodzenie, a nie jako twierdzenie, że fałszowanie adresu gwarantuje działające montowanie.

Przeprowadź trzy przypadki akceptacji, a nie jeden. Zacznij od zatwierdzonego klienta działającego jako zatwierdzony użytkownik, potem powtórz z partnera, który nigdy nie został zatwierdzony, a następnie spróbuj czegoś, na co zatwierdzony użytkownik nadal nie ma zgody. Zapytaj potem, co się zmienia, jeśli autoryzowany klient zostanie przejęty, bo uwierzytelnianie transportu nie czyni każdego procesu na tej maszynie zaufanym. Skradziony certyfikat i ciekawskie konto lokalne to różne problemy z różnymi kontrolami.