Continuació de la sèrie d'articles sobre el tema de l'organització VPN d'accés remot accés No puc evitar compartir la meva interessant experiència de desplegament configuració VPN altament segura. Un client va presentar una tasca no trivial (hi ha inventors als pobles russos), però el repte va ser acceptat i implementat de manera creativa. El resultat és un concepte interessant amb les següents característiques:
- Diversos factors de protecció contra la substitució del dispositiu terminal (amb estricte vinculació a l'usuari);
- Avaluar el compliment de l'ordinador de l'usuari amb l'UDID assignat de l'ordinador permès a la base de dades d'autenticació;
- Amb MFA utilitzant l'UDID del PC del certificat per a l'autenticació secundària mitjançant Cisco DUO (Podeu adjuntar-ne qualsevol compatible amb SAML/Radius);
- Autenticació multifactor:
- Certificat d'usuari amb verificació de camp i autenticació secundària contra un d'ells;
- Inici de sessió (incanviable, extret del certificat) i contrasenya;
- Estimació de l'estat de l'amfitrió de connexió (Postura)
Components de la solució utilitzats:
- Cisco ASA (VPN Gateway);
- Cisco ISE (Autenticació / Autorització / Comptabilitat, avaluació estatal, CA);
- Cisco DUO (autenticació multifactor) (Podeu adjuntar-ne qualsevol compatible amb SAML/Radius);
- Cisco AnyConnect (agent polivalent per a estacions de treball i sistema operatiu mòbil);
Comencem amb els requisits del client:
- L'usuari ha de poder, mitjançant la seva autenticació d'inici de sessió/contrasenya, poder descarregar el client AnyConnect des de la passarel·la VPN; tots els mòduls AnyConnect necessaris s'han d'instal·lar automàticament d'acord amb la política de l'usuari;
- L'usuari hauria de poder emetre automàticament un certificat (per a un dels escenaris, l'escenari principal és l'emissió manual i la càrrega a un ordinador), però he implementat l'emissió automàtica per a la demostració (mai és massa tard per eliminar-lo).
- L'autenticació bàsica s'ha de realitzar en diverses etapes, primer hi ha l'autenticació del certificat amb anàlisi dels camps necessaris i els seus valors, després inici de sessió/contrasenya, només que aquesta vegada s'ha d'inserir el nom d'usuari especificat al camp del certificat a la finestra d'inici de sessió. Nom de l'assumpte (CN) sense poder editar.
- Heu d'assegurar-vos que el dispositiu des del qual inicieu sessió és l'ordinador portàtil corporatiu que s'ha lliurat a l'usuari per a l'accés remot, i no una altra cosa. (S'han fet diverses opcions per satisfer aquest requisit)
- L'estat del dispositiu de connexió (en aquesta etapa PC) s'ha d'avaluar amb una comprovació d'una àmplia taula de requisits del client (resum):
- Fitxers i les seves propietats;
- Entrades del registre;
- Pedaços del sistema operatiu de la llista proporcionada (posterior integració SCCM);
- Disponibilitat de l'antivirus d'un fabricant específic i rellevància de les signatures;
- Activitat de determinats serveis;
- Disponibilitat de certs programes instal·lats;
Per començar, us suggereixo que mireu definitivament el vídeo de demostració de la implementació resultant Youtube (5 minuts).
Ara proposo tenir en compte els detalls de la implementació que no es tracten al videoclip.
Preparem el perfil AnyConnect:
Anteriorment vaig donar un exemple de creació d'un perfil (en termes d'element de menú a ASDM) al meu article sobre la configuració . Ara m'agradaria assenyalar per separat les opcions que necessitarem:
Al perfil, indicarem la passarel·la VPN i el nom del perfil per connectar-se al client final:
Configurem l'emissió automàtica d'un certificat des del costat del perfil, indicant, en particular, els paràmetres del certificat i, característicament, prestem atenció al camp Inicials (I), on s'introdueix manualment un valor específic UDID màquina de prova (identificador de dispositiu únic que genera el client Cisco AnyConnect).
Aquí vull fer una digressió lírica, ja que aquest article descriu el concepte; a efectes de demostració, l'UDID per emetre un certificat s'introdueix al camp Inicials del perfil AnyConnect. Per descomptat, a la vida real, si ho fas, tots els clients rebran un certificat amb el mateix UDID en aquest camp i res els funcionarà, ja que necessiten l'UDID del seu ordinador específic. AnyConnect, malauradament, encara no implementa la substitució del camp UDID al perfil de sol·licitud de certificat mitjançant una variable d'entorn, com ho fa, per exemple, amb una variable %USER%.
Val la pena assenyalar que el client (d'aquest escenari) té previst inicialment emetre certificats de manera independent amb un determinat UDID en mode manual a aquests ordinadors protegits, cosa que no és un problema per a ell. Tanmateix, per a la majoria de nosaltres volem l'automatització (bé, per a mi és cert =)).
I això és el que puc oferir en termes d'automatització. Si AnyConnect encara no pot emetre un certificat automàticament substituint dinàmicament l'UDID, hi ha una altra manera que requerirà una mica de pensament creatiu i mans hàbils: us explicaré el concepte. En primer lloc, mirem com es genera l'UDID en diferents sistemes operatius per l'agent AnyConnect:
- Windows — Hash SHA-256 de la combinació de la clau de registre DigitalProductID i Machine SID
- OSX — SHA-256 hash PlatformUUID
- Linux — Hash SHA-256 de l'UUID de la partició arrel.
- apple iOS — SHA-256 hash PlatformUUID
- Android – Vegeu document a
En conseqüència, creem un script per al nostre sistema operatiu Windows corporatiu, amb aquest script calculem localment l'UDID mitjançant entrades conegudes i formem una sol·licitud d'emissió d'un certificat introduint aquest UDID al camp obligatori, per cert, també podeu utilitzar una màquina certificat emès per AD (afegint una doble autenticació mitjançant un certificat a l'esquema Certificat múltiple).
Preparem la configuració del costat de Cisco ASA:
Creem un TrustPoint per al servidor ISE CA, serà el que emetrà els certificats als clients. No consideraré el procediment d'importació de la cadena de claus; un exemple es descriu al meu article sobre la configuració .
crypto ca trustpoint ISE-CA
enrollment terminal
crl configureConfigurem la distribució per Tunnel-Group en funció de regles d'acord amb els camps del certificat que s'utilitza per a l'autenticació. El perfil AnyConnect que vam fer a l'etapa anterior també es configura aquí. Tingueu en compte que estic utilitzant el valor SECUREBANK-RA, per transferir usuaris amb un certificat emès a un grup de túnels SECURE-BANK-VPN, tingueu en compte que tinc aquest camp a la columna de sol·licitud de certificat de perfil AnyConnect.
tunnel-group-map enable rules
!
crypto ca certificate map OU-Map 6
subject-name attr ou eq securebank-ra
!
webvpn
anyconnect profiles SECUREBANK disk0:/securebank.xml
certificate-group-map OU-Map 6 SECURE-BANK-VPN
!Configuració de servidors d'autenticació. En el meu cas, això és ISE per a la primera etapa d'autenticació i DUO (Radius Proxy) com a MFA.
! CISCO ISE
aaa-server ISE protocol radius
authorize-only
interim-accounting-update periodic 24
dynamic-authorization
aaa-server ISE (inside) host 192.168.99.134
key *****
!
! DUO RADIUS PROXY
aaa-server DUO protocol radius
aaa-server DUO (inside) host 192.168.99.136
timeout 60
key *****
authentication-port 1812
accounting-port 1813
no mschapv2-capable
!Creem polítiques de grup i grups de túnels i els seus components auxiliars:
Grup de túnels Grup WEBVPNG per defecte s'utilitzarà principalment per descarregar el client VPN AnyConnect i emetre un certificat d'usuari mitjançant la funció SCEP-Proxy de l'ASA; per a això tenim les opcions corresponents activades tant al propi grup de túnel com a la política de grup associada. AC-Descàrrega, i al perfil AnyConnect carregat (camps per emetre un certificat, etc.). També en aquesta política de grup indiquem la necessitat de descarregar Mòdul de Postura ISE.
Grup de túnels SECURE-BANK-VPN serà utilitzat automàticament pel client en l'autenticació amb el certificat emès en l'etapa anterior, ja que, d'acord amb el Mapa de Certificats, la connexió recaurà específicament en aquest grup de túnels. Us explicaré opcions interessants aquí:
- grup de servidors d'autenticació secundària DUO # Estableix l'autenticació secundària al servidor DUO (Radius Proxy)
- nom d'usuari-del-certificatCN # Per a l'autenticació principal, utilitzem el camp CN del certificat per heretar l'inici de sessió de l'usuari
- nom-usuari-secundari-del-certificat I # Per a l'autenticació secundària al servidor DUO, utilitzem el nom d'usuari extret i els camps Inicials (I) del certificat.
- client de pre-emplenament de nom d'usuari # feu que el nom d'usuari s'emplena prèviament a la finestra d'autenticació sense poder canviar-lo
- secundari-pre-completar-nom d'usuari client oculta l'ús de la contrasenya comuna push # Ocultem la finestra d'entrada d'inici de sessió/contrasenya per a l'autenticació secundària DUO i utilitzem el mètode de notificació (sms/push/telèfon) - dock per sol·licitar l'autenticació en lloc del camp de la contrasenya
!
access-list posture-redirect extended permit tcp any host 72.163.1.80
access-list posture-redirect extended deny ip any any
!
access-list VPN-Filter extended permit ip any any
!
ip local pool vpn-pool 192.168.100.33-192.168.100.63 mask 255.255.255.224
!
group-policy SECURE-BANK-VPN internal
group-policy SECURE-BANK-VPN attributes
dns-server value 192.168.99.155 192.168.99.130
vpn-filter value VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain value ashes.cc
address-pools value vpn-pool
webvpn
anyconnect ssl dtls enable
anyconnect mtu 1300
anyconnect keep-installer installed
anyconnect ssl keepalive 20
anyconnect ssl rekey time none
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect modules value iseposture
anyconnect profiles value SECUREBANK type user
!
group-policy AC-DOWNLOAD internal
group-policy AC-DOWNLOAD attributes
dns-server value 192.168.99.155 192.168.99.130
vpn-filter value VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain value ashes.cc
address-pools value vpn-pool
scep-forwarding-url value http://ise.ashes.cc:9090/auth/caservice/pkiclient.exe
webvpn
anyconnect ssl dtls enable
anyconnect mtu 1300
anyconnect keep-installer installed
anyconnect ssl keepalive 20
anyconnect ssl rekey time none
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect modules value iseposture
anyconnect profiles value SECUREBANK type user
!
tunnel-group DefaultWEBVPNGroup general-attributes
address-pool vpn-pool
authentication-server-group ISE
accounting-server-group ISE
default-group-policy AC-DOWNLOAD
scep-enrollment enable
tunnel-group DefaultWEBVPNGroup webvpn-attributes
authentication aaa certificate
!
tunnel-group SECURE-BANK-VPN type remote-access
tunnel-group SECURE-BANK-VPN general-attributes
address-pool vpn-pool
authentication-server-group ISE
secondary-authentication-server-group DUO
accounting-server-group ISE
default-group-policy SECURE-BANK-VPN
username-from-certificate CN
secondary-username-from-certificate I
tunnel-group SECURE-BANK-VPN webvpn-attributes
authentication aaa certificate
pre-fill-username client
secondary-pre-fill-username client hide use-common-password push
group-alias SECURE-BANK-VPN enable
dns-group ASHES-DNS
!A continuació, passem a ISE:
Configurem un usuari local (podeu utilitzar AD/LDAP/ODBC, etc.), per senzillesa, vaig crear un usuari local al mateix ISE i l'he assignat al camp descripció UDID PC des del qual se li permet iniciar sessió mitjançant VPN. Si faig servir l'autenticació local a ISE, em limitaré a un sol dispositiu, ja que no hi ha molts camps, però a les bases de dades d'autenticació de tercers no tindré aquestes restriccions.
Vegem la política d'autorització, es divideix en quatre etapes de connexió:
- Etapa 1 — Política per descarregar l'agent AnyConnect i emetre un certificat
- Etapa 2 — Política d'autenticació principal Inici de sessió (des del certificat)/Contrasenya + Certificat amb validació UDID
- Etapa 3 — Autenticació secundària mitjançant Cisco DUO (MFA) utilitzant UDID com a nom d'usuari + avaluació de l'estat
- Etapa 4 - L'autorització definitiva es troba en l'estat:
- Compleix;
- Validació UDID (des del certificat + vinculació d'inici de sessió),
- Cisco DUO MFA;
- Autenticació mitjançant inici de sessió;
- Autenticació del certificat;
Vegem una condició interessant UUID_VALIDAT, sembla que l'usuari que s'autentica realment prové d'un ordinador amb un UDID permès associat al camp Descripció compte, les condicions són les següents:
El perfil d'autorització utilitzat en les etapes 1,2,3, XNUMX, XNUMX és el següent:
Podeu comprovar exactament com ens arriba l'UDID del client AnyConnect mirant els detalls de la sessió del client a ISE. En detall veurem que AnyConnect a través del mecanisme ACIDEX envia no només informació sobre la plataforma, sinó també l'UDID del dispositiu com Cisco-AV-PAIR:
Fixem-nos en el certificat emès a l'usuari i al camp Inicials (I), que s'utilitza per prendre-lo com a inici de sessió per a l'autenticació MFA secundària a Cisco DUO:
Al costat del DUO Radius Proxy al registre, podem veure clarament com es fa la sol·licitud d'autenticació, utilitza UDID com a nom d'usuari:
Des del portal DUO veiem un esdeveniment d'autenticació reeixit:
I a les propietats de l'usuari ho tinc configurat ÀLIES, que vaig utilitzar per iniciar sessió, al seu torn, aquest és l'UDID de l'ordinador permès per iniciar sessió:
Com a resultat hem obtingut:
- Autenticació multifactor d'usuari i dispositiu;
- Protecció contra la falsificació del dispositiu de l'usuari;
- Avaluació de l'estat del dispositiu;
- Potencial per augmentar el control amb certificat de màquina de domini, etc.;
- Protecció integral del lloc de treball remot amb mòduls de seguretat desplegats automàticament;
Enllaços a articles de la sèrie VPN de Cisco:
Font: www.habr.com