Dvě přihlašovací kontroly nejsou dva faktory: VPN a RADIUS

Přidání druhého autentizačního backendu k VPN bráně vypadá jako přidání druhého faktoru. Obvykle přidá druhou kontrolu, což je jiný objekt s jinými režimy selhání. Zda musí uspět obě, co každá prokazuje a co se stane, když jedna není dostupná, jsou tři samostatná rozhodnutí. Spleťte je a brána skončí přísnější při ukázce a slabší během výpadku.

Co druhý backend skutečně prokazuje

Vyhledání místního účtu prokazuje, že jméno existuje v databázi a že mu odpovídalo heslo. Výměna RADIUS prokazuje, že server RADIUS vrátil Access-Accept pro přijaté atributy. Ani jedno tvrzení nezmiňuje typ faktoru, protože obě ověřují znalost. A pokyny NIST k digitální identitě počítají různé typy faktorů a jejich autentizátory, ne servery nebo výzvy.

Existuje legitimní návrh, na kterém se podílejí oba systémy. Centrální služba může autentizovat osobu, zatímco brána nezávisle kontroluje, zda má tento účet nárok na tento tunel. To je autorizace vedle autentizace a nazývat to dvoufaktorovým zaměňuje kontrolu politiky s důkazem držení.

RADIUS může nést skutečný druhý faktor, když stojí před něčím, co jej ověřuje, například push schválením nebo hardwarovým tokenem. Obálka neříká, které autentizátory uživatel předvedl, takže čtěte politiku backendu, ne označení brány.

AND, OR a záložní režim jsou různé produkty

Než začnete porovnávat implementace, rozhodněte, co obojí znamená ve vašem požadavku. Politika AND vyžaduje, aby prošla každá pojmenovaná kontrola, politika OR přijme tu, která uspěje, a záložní režim zkouší druhou jen za uvedených podmínek selhání. Ty tři se během výpadku chovají opačně a obvykle jen jedna z nich je to, co revize zamýšlela.

Přidání dvou backendových položek na obrazovku konfigurace neprozradí, kterou politiku produkt uplatňuje. Některé brány řetězí pluginy v pořadí a zastaví se na prvním odmítnutí, což je AND jen tehdy, když je každý plugin povinný. Jiné považují místní účet za přepis, což centrální výpadek mění v obejití. Spolehlivou odpovědí je zdokumentovaný negativní test pro každou cestu, spuštěný na sestavení, které nasazujete.

Záložní režim si zaslouží nejvíc podezření, protože existuje proto, aby fungoval dál, když je něco rozbité. Záložní režim, který přijme místní heslo vždy, když je RADIUS nedostupný, proměnil centrální politiku ve druhá, slabší dveře.

Dvojitá kontrola OpenVPN je konkrétní případ

Komunitní OpenVPN 2.6 vyžaduje klientský certifikát i nakonfigurovaný skript auth-user-pass-verify, když jsou oba zapnuté. To je zdokumentovaný AND mezi ověřením certifikátu a skriptem přihlašovacích údajů a skutečně jde o dvě kontroly. Stále to ale nejsou automaticky dva typy faktorů, protože skript může ověřovat jen heslo.

Kombinace také nechává otevřenou otázku přiřazení. Certifikát obvykle identifikuje zařízení, zatímco údaje identifikují osobu, a nic ve výchozím toku nevyžaduje, aby se oba vztahovaly ke stejnému subjektu. Rozhodněte, které páry jsou povolené, a pak tuto mapu vynuťte uvnitř ověřovacího skriptu nebo v pozdějším autorizačním kroku.

Režim pouze s certifikátem je jediná kontrola, podepřená klíčem, který může a nemusí být chráněn PINem. PIN mění stejný údaj na znalost plus držení jen tehdy, když klíč nelze bez něj použít. Ponechání klíče nezašifrovaného na disku redukuje druhou část na oprávnění k souboru.

Výrobci zařízení si staví vlastní instalatérství, často modul PAM nebo plugin RADIUS za webovou konzolí. Chování komunity je referencí pro to, jak dvojité kontroly vypadají, ne popisem toho, jak je zařízení kombinuje.

Zkontrolujte kombinaci na své bráně

Přečtěte si konfiguraci, než uvěříte souhrnu konzole. Řádky, které rozhodují o politice, jsou režim certifikátu, skript údajů a pořadí pluginů.

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 ukazuje, zda je vyžadován certifikát a který skript se po něm spustí, a pořadí je důležitější, než názvy naznačují. Výpis certifikátu dává identitu, kterou brána uvidí, včetně CN a sériového čísla potřebných pro mapu přiřazení. Test RADIUS je negativní případ: špatné heslo musí dát Access-Reject a správné Access-Accept. Pokud odmítnuté údaje stále dají relaci, skript vůbec není na autentizační cestě.

Poté spusťte případ výpadku v laboratorní instanci: zastavte povinný backend a připojte se platnými údaji. Očekávaným výsledkem je odmítnutí a cokoli jiného je záložní politika, kterou nikdo nezdokumentoval.

Napište požadavek jako negativní případy

Použitelný požadavek pojmenovává důkazy, účty, které je smějí předložit, a výsledek, když ověřovatel chybí. Uvádí také povolené párování mezi identitou zařízení a identitou osoby. To je přesnější než názvy produktů v objednávce a lze to otestovat.

Přijetí by mělo zahrnovat čtyři odmítnutí: nevhodný místní účet, chybějící povinný důkaz, neplatný druhý faktor a nedostupný povinný backend. Každé odmítnutí potřebuje řádek v logu, který je odliší od ostatních, jinak příští incident začíná hádáním. Zaznamenejte, která komponenta rozhodla, protože brána, server RADIUS a adresář budou vinit jeden druhého.

Po každé změně pluginu nebo firmwaru znovu spusťte čtyři odmítnutí. Jsou levná a politika, kterou chrání, je část, kterou útočník zkouší první.