Twee aanmeldkontroles is nie twee faktore nie: VPN en RADIUS

Om ’n tweede verifikasie-agtergrond aan ’n VPN-grendel toe te voeg, voel soos om ’n tweede faktor by te voeg. Dit voeg gewoonlik ’n tweede kontrole by, wat ’n ander objek met ander foutmodusse is. Of albei moet slaag, wat elkeen bewys, en wat gebeur wanneer een nie beskikbaar is nie, is drie afsonderlike besluite. Kry dit verkeerd en die grendel eindig strenger in die demonstrasie en swakker tydens ’n onderbreking.

Wat ’n tweede agtergrond werklik bewys

’n Plaaslike rekeningsoektog bewys dat ’n naam in ’n databasis bestaan en dat ’n wagwoord daarby pas. ’n RADIUS-uitruiling bewys dat ’n RADIUS-bediener Access-Accept teruggegee het vir die kenmerke wat dit ontvang het. Nie een van die stellings noem ’n faktortipe nie, want albei verifieer kennis. Die NIST-riglyn vir digitale identiteit tel afsonderlike faktortipes en hul aanduiders, nie bedieners of vrae nie.

Daar is ’n wettige ontwerp waar albei stelsels deelneem. ’n Sentrale diens kan die persoon verifieer terwyl die grendel onafhanklik nagaan of daardie rekening op hierdie tonnel geregtig is. Dit is magtiging langs verifikasie, en om dit tweefaktor te noem, verwar ’n beleidskontrole met bewys van besit.

RADIUS kan ’n werklike tweede faktor dra wanneer dit iets front wat een verifieer, soos ’n stootgoedkeuring of ’n hardeware-token. Die koevert sê nie watter aanduiders die gebruiker gedemonstreer het nie, so lees die agtergrondbeleid eerder as die grendel se etiket.

AND, OR en terugval is verskillende produkte

Voordat jy implementerings vergelyk, besluit wat beide in jou vereiste beteken. ’n AND-beleid vereis dat elke genoemde kontrole slaag, ’n OR-beleid aanvaar enigeen wat slaag, en ’n terugval probeer die tweede slegs onder bepaalde fouttoestande. Dié drie tree teenoorgesteld op tydens ’n onderbreking, en gewoonlik is net een daarvan wat die oorsig bedoel het.

Om twee agtergrondinskrywings by ’n konfigurasieskerm te voeg, openbaar nie watter beleid die produk implementeer nie. Sommige grendels ketting plugins in volgorde en stop by die eerste weiering, wat net AND is wanneer elke plugin vereis word. Ander behandel ’n plaaslike rekening as ’n oorheersing, wat ’n sentrale onderbreking in ’n omseiling verander. Die betroubare antwoord is ’n gedokumenteerde negatiewe toets vir elke pad, uitgevoer teen die bou wat jy ontplooi.

Terugval verdien die meeste agterdog, want dit bestaan om te bly werk wanneer iets stukkend is. ’n Terugval wat ’n plaaslike wagwoord aanvaar wanneer RADIUS onbereikbaar is, het ’n sentrale beleid in ’n tweede, swakker deur verander.

OpenVPN se dubbele kontrole is ’n konkrete geval

Gemeenskaps-OpenVPN 2.6 vereis beide ’n kliëntsertifikaat en die gekonfigureerde auth-user-pass-verify-skrip wanneer albei geaktiveer is. Dit is ’n gedokumenteerde AND tussen sertifikaatverifikasie en ’n geloofsbriewe-skrip, en dit is werklik twee kontroles. Dit is steeds nie outomaties twee faktortipes nie, want die skrip mag net ’n wagwoord valideer.

Die kombinasie laat ook die assosiasievraag oop. ’n Sertifikaat identifiseer gewoonlik ’n toestel, terwyl die geloofsbriewe ’n persoon identifiseer, en niks in die verstekvloei vereis dat albei na dieselfde prinsipaal verwys nie. Besluit watter pare toegelaat word, en handhaaf dan daardie kaart in die verifieer-skrip of in ’n latere magtigingsstap.

Slegs-sertifikaat-modus is ’n enkele kontrole, gerugsteun deur ’n sleutel wat dalk deur ’n PIN beskerm word of nie. ’n PIN verander dieselfde geloofsbrief in kennis plus besit slegs as die sleutel nie daarsonder gebruik kan word nie. Om daardie sleutel onversleuteld op skyf te laat, verminder die tweede deel tot ’n lêertoestemming.

Toestelverkopers bou hul eie loodgieterswerk, dikwels ’n PAM-module of ’n RADIUS-inprop agter ’n webkonsole. Gemeenskapsgedrag is ’n verwysing vir hoe dubbele kontroles lyk, nie ’n beskrywing van hoe ’n toestel hulle kombineer nie.

Kontroleer die kombinasie op jou grendel

Lees die konfigurasie voordat jy die konsole-opsomming vertrou. Die reëls wat die beleid bepaal, is die sertifikaatmodus, die geloofsbriewe-skrip en die inpropvolgorde.

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

Die grep wys of ’n sertifikaat vereis word en watter skrip daarna loop, en die volgorde maak meer saak as wat die name suggereer. Die sertifikaat-uitdrukking gee die identiteit wat die grendel sal sien, insluitend die CN en reeksnommer wat jy vir die assosiasiekaart nodig het. Die RADIUS-toets is die negatiewe geval: ’n verkeerde wagwoord moet Access-Reject lewer, en ’n korrekte een Access-Accept. As ’n verworpe geloofsbrief steeds ’n sessie oplewer, is die skrip glad nie op die verifikasiepad nie.

Voer dan die onderbrekingsgeval op ’n laboratorium-instansie uit: stop die vereiste agtergrond en koppel met geldige geloofsbriewe. Die verwagte resultaat is ’n weiering, en enigiets anders is die terugvalbeleid wat niemand gedokumenteer het nie.

Skryf die vereiste as negatiewe gevalle

’n Bruikbare vereiste noem die bewyse, die rekeninge wat toegelaat word om dit voor te lê, en die resultaat wanneer ’n verifieerder ontbreek. Dit noem ook die toegelate paring tussen toestelidentiteit en persoonidentiteit. Dit is meer presies as die produkname op die bestelorder, en dit kan getoets word.

Aanvaarding moet vier weierings insluit: ’n ongeskikte plaaslike rekening, ’n ontbrekende vereiste bewys, ’n ongeldige tweede faktor, en ’n onbereikbare vereiste agtergrond. Elke weiering het ’n logreël nodig wat dit van die ander onderskei, anders begin die volgende voorval met raaiwerk. Teken aan watter komponent elke besluit geneem het, aangesien die grendel, die RADIUS-bediener en die gids elk die ander twee sal blameer.

Herhaal die vier weierings ná enige inprop- of firmware-verandering. Hulle is goedkoop, en die beleid wat hulle beskerm, is die deel wat ’n aanvaller eerste ondersoek.