Dwie kontrole logowania to nie dwa czynniki: VPN i RADIUS

Dodanie drugiego backendu uwierzytelniania do bramy VPN wygląda jak dodanie drugiego czynnika. Zwykle dodaje drugą kontrolę, czyli inny obiekt z innymi trybami awarii. Czy obie muszą się powieść, co każda dowodzi i co się dzieje, gdy jedna jest niedostępna, to trzy osobne decyzje. Jeśli je pomylisz, brama będzie surowsza w demonstracji i słabsza podczas awarii.

Co naprawdę dowodzi drugi backend

Wyszukanie lokalnego konta dowodzi, że nazwa istnieje w bazie danych i że hasło do niej pasowało. Wymiana RADIUS dowodzi, że serwer RADIUS zwrócił Access-Accept dla otrzymanych atrybutów. Żadne z tych stwierdzeń nie wymienia typu czynnika, ponieważ oba weryfikują wiedzę. A wytyczne NIST dotyczące tożsamości cyfrowej liczą odrębne typy czynników i ich authenticatory, a nie serwery czy monity.

Istnieje uzasadniony projekt, w którym uczestniczą oba systemy. Usługa centralna może uwierzytelnić osobę, podczas gdy brama niezależnie sprawdza, czy to konto ma prawo do tego tunelu. To autoryzacja obok uwierzytelniania, a nazywanie tego dwuczynnikowym myli kontrolę polityki z dowodem posiadania.

RADIUS może przenosić prawdziwy drugi czynnik, gdy stoi przed czymś, co weryfikuje jeden, na przykład zatwierdzeniem push lub tokenem sprzętowym. Koperta nie mówi, jakie authenticatory przedstawił użytkownik, więc czytaj politykę backendu, a nie etykietę bramy.

AND, OR i zasada zapasowa to różne produkty

Zanim porównasz implementacje, zdecyduj, co oznacza oba w twoim wymaganiu. Zasada AND wymaga przejścia każdej nazwanej kontroli, zasada OR akceptuje tę, która się powiedzie, a zasada zapasowa próbuje drugiej tylko w podanych warunkach awarii. Te trzy zachowują się przeciwnie podczas awarii i zwykle tylko jedna z nich jest tym, co miał na myśli przegląd.

Dodanie dwóch wpisów backendu do ekranu konfiguracji nie ujawnia, jaką politykę wdraża produkt. Niektóre bramy łączą wtyczki w kolejności i zatrzymują się na pierwszej odmowie, co jest AND tylko wtedy, gdy każda wtyczka jest wymagana. Inne traktują konto lokalne jako nadpisanie, co zamienia centralną awarię w obejście. Wiarygodna odpowiedź to udokumentowany test negatywny dla każdej ścieżki, uruchomiony na kompilacji, którą wdrażasz.

Zasada zapasowa zasługuje na największą nieufność, ponieważ istnieje po to, by działać dalej, gdy coś jest zepsute. Zasada zapasowa, która akceptuje lokalne hasło za każdym razem, gdy RADIUS jest nieosiągalny, zamieniła centralną politykę w drugie, słabsze drzwi.

Podwójna kontrola OpenVPN to konkretny przypadek

Wspólnotowy OpenVPN 2.6 wymaga zarówno certyfikatu klienta, jak i skonfigurowanego skryptu auth-user-pass-verify, gdy oba są włączone. To udokumentowany AND między weryfikacją certyfikatu a skryptem poświadczeń, i to naprawdę dwie kontrole. Nadal nie są to automatycznie dwa typy czynników, ponieważ skrypt może weryfikować tylko hasło.

Kombinacja pozostawia też otwarte pytanie o powiązanie. Certyfikat zwykle identyfikuje urządzenie, podczas gdy poświadczenia identyfikują osobę, i nic w domyślnym przepływie nie wymaga, by oba odnosiły się do tego samego podmiotu. Zdecyduj, które pary są dozwolone, a następnie egzekwuj tę mapę w skrypcie weryfikacji lub w późniejszym kroku autoryzacji.

Tryb tylko certyfikatu to jedna kontrola, oparta na kluczu, który może, ale nie musi być chroniony numerem PIN. PIN zmienia te same poświadczenia w wiedzę plus posiadanie tylko wtedy, gdy klucza nie można użyć bez niego. Pozostawienie klucza niezaszyfrowanego na dysku redukuje drugą część do uprawnienia pliku.

Producenci urządzeń budują własną instalację, często moduł PAM lub wtyczkę RADIUS za konsolą webową. Zachowanie społeczności jest odniesieniem do tego, jak wyglądają podwójne kontrole, a nie opisem, jak urządzenie je łączy.

Sprawdź kombinację na swojej bramie

Przeczytaj konfigurację, zanim zaufasz podsumowaniu konsoli. Linie decydujące o polityce to tryb certyfikatu, skrypt poświadczeń i kolejność wtyczek.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep pokazuje, czy certyfikat jest wymagany i który skrypt uruchamia się po nim, a kolejność ma większe znaczenie, niż sugerują nazwy. Zrzut certyfikatu daje tożsamość, którą zobaczy brama, w tym CN i numer seryjny potrzebne do mapy powiązań. Test RADIUS to przypadek negatywny: błędne hasło musi dać Access-Reject, a poprawne Access-Accept. Jeśli odrzucone poświadczenia nadal dają sesję, skrypt w ogóle nie jest na ścieżce uwierzytelniania.

Następnie uruchom przypadek awarii na instancji laboratoryjnej: zatrzymaj wymagany backend i połącz się z prawidłowymi poświadczeniami. Oczekiwanym wynikiem jest odmowa, a wszystko inne to zasada zapasowa, której nikt nie udokumentował.

Zapisz wymaganie jako przypadki negatywne

Użyteczne wymaganie nazywa dowody, konta uprawnione do ich przedstawienia i wynik, gdy brakuje weryfikatora. Określa też dozwolone parowanie tożsamości urządzenia i tożsamości osoby. To jest precyzyjniejsze niż nazwy produktów w zamówieniu i można to przetestować.

Akceptacja powinna obejmować cztery odmowy: nieodpowiednie konto lokalne, brak wymaganego dowodu, nieprawidłowy drugi czynnik i nieosiągalny wymagany backend. Każda odmowa potrzebuje linii dziennika, która odróżnia ją od pozostałych, inaczej następny incydent zaczyna się od domysłów. Zapisz, który komponent podjął każdą decyzję, ponieważ brama, serwer RADIUS i katalog będą obwiniać się nawzajem.

Powtórz cztery odmowy po każdej zmianie wtyczki lub oprogramowania sprzętowego. Są tanie, a polityka, którą chronią, to część, którą atakujący bada najpierw.