Continuando la serie di articoli sull'organizzazione Remote-Access VPN non posso non condividere un'esperienza interessante di implementazione di una configurazione VPN altamente protetta. Un cliente ha lanciato una sfida non triviale (ci sono inventori nei villaggi russi), ma sfida accettata e realizzata in modo creativo. Il risultato è stato un concetto interessante con le seguenti caratteristiche:
- Diverse misure di protezione contro la sostituzione del dispositivo finale (con collegamento rigido all'utente);
- Valutazione della conformità del PC dell'utente rispetto all'UDID del PC autorizzato nel database di autenticazione;
- Con MFA, utilizzando l'UDID del PC dal certificato per la secondaria autenticazione tramite Cisco DUO (Si può collegare qualsiasi SAML/RADIUS compatibile);
- Autenticazione multifattoriale:
- Certificato utente con verifica dei campi e autenticazione secondaria su uno di essi;
- Login (immutabile, preso dal certificato) e password;
- Valutazione dello stato dell'host connesso (Postura)
Componenti utilizzati nella soluzione:
- Cisco ASA (Gateway VPN);
- Cisco ISE (Autenticazione / Autorizzazione / Contabilità, Valutazione dello Stato, CA);
- Cisco DUO (Autenticazione Multifattoriale) (Si può collegare qualsiasi SAML/RADIUS compatibile);
- Cisco AnyConnect (Agente multifunzionale per stazioni di lavoro e sistemi operativi mobili);
Iniziamo con i requisiti del cliente:
- L'utente deve avere la possibilità di scaricare il client AnyConnect dal gateway VPN con la propria autenticazione Login/Password, tutti i moduli necessari di AnyConnect devono installarsi automaticamente in conformità alla politica dell'utente;
- L'utente deve avere la possibilità di emissione automatica del certificato (per uno degli scenari, lo scenario principale è l'emissione manuale e il caricamento sul PC), io ho implementato l'emissione automatica per dimostrazione (non è mai troppo tardi per rimuoverla).
- L'autenticazione principale deve avvenire in più fasi, prima c'è l'autenticazione del certificato con analisi dei campi necessari e dei loro valori, poi login/password, solo che stavolta nella finestra di login deve essere inserito il nome utente indicato nel campo del certificato Subject Name (CN) senza possibilità di modifica.
- È necessario assicurarsi che il dispositivo da cui si accede sia il laptop aziendale assegnato per l'accesso remoto all'utente, e non qualcos'altro. (Sono state realizzate diverse varianti per soddisfare questo requisito)
- Deve essere effettuata una valutazione dello stato del dispositivo connesso (in questa fase PC) verificando l'intera e ampia tabella dei requisiti del cliente (in sintesi):
- File e le loro proprietà;
- Registrazioni del registro;
- Patch del sistema operativo dalla lista fornita (in seguito integrazione SCCM);
- Presenza di Antivirus di un determinato produttore e attualità delle firme;
- Attività di determinati servizi;
- Presenza di determinati programmi installati;
Per iniziare, propongo di guardare necessariamente la video-demonstrazione dell'implementazione ottenuta su Youtube (5 minuti).
Ora propongo di considerare i dettagli dell'implementazione non trattati nel video.
Prepariamo il profilo AnyConnect:
Un esempio di creazione del profilo (in termini di voce di menu in ASDM) l'ho fornito in precedenza nel mio articolo sulla configurazione . Ora desidero sottolineare separatamente quelle opzioni che ci serviranno:
Nel profilo indicheremo il gateway VPN e il nome del profilo per la connessione sul client finale:
Effettueremo le impostazioni per l'emissione automatica del certificato da parte del profilo, specificando, in particolare, i parametri del certificato e, ciò che è significativo, presteremo attenzione al campo Initials (I), dove è manualmente inserito un valore specifico UDID della macchina di test (Identificatore Unico Dispositivo, che viene generato dal client Cisco AnyConnect).
Qui voglio fare una piccola digressione, poiché questo articolo descrive un concetto; per scopi dimostrativi, qui è stato inserito un UDID per l'emissione del certificato nel campo Initials del profilo AnyConnect. Naturalmente, nella vita reale, se lo fai, tutti i client riceveranno un certificato con lo stesso UDID in questo campo e non funzionerà nulla, poiché hanno bisogno dell'UDID specifico del proprio PC. Purtroppo, AnyConnect non implementa ancora la sostituzione nella richiesta del certificato per il campo UDID mediante variabili ambientali, come ad esempio fa con la variabile %USER%.
Va notato che il cliente (di questo scenario) inizialmente prevede di rilasciare i certificati con l'UDID specificato in modalità manuale per tali PC Protetti, il che non rappresenta per lui un problema. Tuttavia, per la maggior parte di noi c'è il desiderio di automazione (beh, per me è così di certo =).
Ecco cosa posso proporre in termini di automazione. Se il certificato deve essere emesso automaticamente AnyConnect dinamicamente abbinando l'UDID che al momento non riesce a fare, c'è un altro modo che richiederà un po' di creatività e abilità manuali – vi spiegherò il concetto. Per cominciare, diamo un'occhiata a come viene generato l'UDID su diversi sistemi operativi dall'agente AnyConnect:
- Windows — Hash SHA-256 della combinazione della chiave del registro DigitalProductID e Machine SID
- OSX — Hash SHA-256 di PlatformUUID
- Linux — Hash SHA-256 dell'UUID della partizione root.
- Apple iOS — Hash SHA-256 di PlatformUUID
- Android – Vedi il documento su
In base a questo, prepariamo uno script per i nostri sistemi operativi aziendali Windows; utilizziamo questo script per calcolare localmente l'UDID utilizzando i parametri noti e formiamo la richiesta per l'emissione del certificato inserendo in campo appropriato questo UDID, oltretutto possiamo utilizzare anche un certificato di macchina emesso da AD (aggiungendo alla procedura una doppia autenticazione tramite certificato Certificato Multiplo).
Prepariamo le impostazioni dal lato Cisco ASA:
Creiamo un TrustPoint per il server ISE CA, che sarà quello a emettere certificati ai clienti. Non tratterò il procedimento di importazione della Key-Chain, l'esempio è descritto nel mio articolo sulla configurazione. .
crypto ca trustpoint ISE-CA
enrollment terminal
crl configureConfiguriamo la distribuzione per Tunnel-Group basandoci su regole conformi ai campi del certificato utilizzato per l'autenticazione. Qui si imposta anche il profilo AnyConnect che abbiamo preparato nel passo precedente. Vorrei sottolineare che utilizzo il valore SECUREBANK-RA, per trasferire gli utenti con il certificato emesso nel tunnel-group SECURE-BANK-VPN, si noti che questo campo è stato impostato nella richiesta del certificato per il profilo 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
!Configuriamo i server di autenticazione. Nel mio caso, si tratta di ISE per la prima fase di autenticazione e DUO (Radius Proxy) come 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
!Creiamo politiche di gruppo e tunnel groups e i relativi componenti ausiliari:
Tunnel Group DefaultWEBVPNGroup verrà utilizzata principalmente per il download del client AnyConnect VPN e l'emissione del certificato utente utilizzando la funzione SCEP-Proxy ASA; per questo sono attivate le opzioni corrispondenti sia nel gruppo di tunnel che nella politica di gruppo associata. AC-Download, nonché nel profilo AnyConnect scaricato (campi di emissione del certificato, ecc.). Inoltre, in questa politica di gruppo indichiamo la necessità del download Modulo ISE Posture.
Tunnel Group SECURE-BANK-VPN verrà utilizzato automaticamente dal client durante l'autenticazione con il certificato emesso nel passaggio precedente, poiché in conformità con il Certificate Map, la connessione sarà esattamente su questo gruppo di tunnel. Parlerò di opzioni interessanti qui:
- gruppo-server di autenticazione secondaria DUO # Задаем вторичную аутентификацию на сервере DUO (Radius Proxy)
- nome-utente-dal-certificato CN # Используем для первичной аутентификации поле CN сертификата для наследования логина пользователя
- nome-utente-secondario-dal-certificato I # Для вторичной аутентификации на сервере DUO используем имя пользователя, извлеченное и поля Initials (I) сертификата.
- pre-compilazione-nome-utente client # делаем предзаполненным имя пользователя в окне аутентификации без возможности изменения
- pre-compilazione-nome-utente-secondario client nascondi usa-password-comune push # Прячем окно ввода логина/пароля для вторичной аутентификации DUO и используем для запроса аутентификации вместо поля пароля метод уведомления (sms/push/phone) – дока
!
access-list posture-redirect extended permetti tcp qualsiasi host 72.163.1.80
access-list posture-redirect extended nega ip qualsiasi qualsiasi
!
access-list VPN-Filter extended permetti ip qualsiasi qualsiasi
!
ip pool locale vpn-pool 192.168.100.33-192.168.100.63 maschera 255.255.255.224
!
group-policy SECURE-BANK-VPN interna
group-policy SECURE-BANK-VPN attributi
dns-server valore 192.168.99.155 192.168.99.130
vpn-filter valore VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain valore ashes.cc
address-pools valore vpn-pool
webvpn
anyconnect ssl dtls abilitato
anyconnect mtu 1300
anyconnect keep-installer installato
anyconnect ssl keepalive 20
anyconnect ssl rekey time nessuno
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect moduli valore iseposture
anyconnect profili valore SECUREBANK tipo utente
!
group-policy AC-DOWNLOAD interna
group-policy AC-DOWNLOAD attributi
dns-server valore 192.168.99.155 192.168.99.130
vpn-filter valore VPN-Filter
vpn-tunnel-protocol ssl-client
split-tunnel-policy tunnelall
default-domain valore ashes.cc
address-pools valore vpn-pool
scep-forwarding-url valore http://ise.ashes.cc:9090/auth/caservice/pkiclient.exe
webvpn
anyconnect ssl dtls abilitato
anyconnect mtu 1300
anyconnect keep-installer installato
anyconnect ssl keepalive 20
anyconnect ssl rekey time nessuno
anyconnect ssl rekey method ssl
anyconnect dpd-interval client 30
anyconnect dpd-interval gateway 30
anyconnect ssl compression lzs
anyconnect dtls compression lzs
anyconnect moduli valore iseposture
anyconnect profili valore SECUREBANK tipo utente
!
tunnel-group DefaultWEBVPNGroup general-attributes
address-pool vpn-pool
authentication-server-group ISE
accounting-server-group ISE
default-group-policy AC-DOWNLOAD
scep-enrollment abilitato
tunnel-group DefaultWEBVPNGroup webvpn-attributes
authentication aaa certificate
!
tunnel-group SECURE-BANK-VPN tipo accesso-remoto
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 abilitato
dns-group ASHES-DNS
!Passiamo a ISE:
Configurare un utente locale (è possibile utilizzare anche AD/LDAP/ODBC, ecc.), per semplicità ho creato un utente locale direttamente in ISE e assegnato nel campo description UDID PC da cui è consentito l'accesso tramite VPN. Nel caso di autenticazione locale su ISE, sarò limitato a un solo dispositivo, poiché i campi disponibili non sono molti, ma non avrò tali limitazioni in database di autenticazione esterni.
Esaminiamo la politica di autorizzazione, che è divisa in quattro fasi di connessione:
- Fase 1 — Politica per il download dell'agente AnyConnect e l'emissione del certificato
- Fase 2 — Politica di autenticazione primaria Login (dal certificato)/Password + Certificato con validazione UDID
- Fase 3 — Autenticazione secondaria tramite Cisco DUO (MFA) utilizzando UDID come nome utente + Valutazione dello stato
- Fase 4 — Autorizzazione finale in stato:
- Compliant;
- validazione UDID (dal certificato + associazione al login),
- Cisco DUO MFA;
- Autenticazione tramite login;
- Autenticazione tramite certificato;
Diamo un'occhiata a una condizione interessante UUID_VALIDATED, che verifica se l'utente in fase di autenticazione proviene effettivamente da un PC con UDID autorizzato associato nel campo Descrizione dell'account, la condizione appare così:
Il profilo di autorizzazione utilizzato nelle fasi 1, 2 e 3 appare come segue:
Possiamo controllare come ci arriva l'UDID dal client AnyConnect guardando i dettagli della sessione del client in ISE. Nei dettagli vediamo che AnyConnect tramite il meccanismo ACIDEX invia non solo i dati sulla piattaforma, ma anche l'UDID del dispositivo come Cisco-AV-PAIR:
Focalizziamoci sul certificato emesso all'utente e sul campo Initials (I), che viene utilizzato come login per l'autenticazione secondaria MFA su Cisco DUO:
Dalla parte del DUO Radius Proxy nel registro vediamo chiaramente come avviene la richiesta di autenticazione, che viene effettuata utilizzando l'UDID come nome utente:
Dal portale DUO vediamo un evento di autenticazione riuscito:
E nelle proprietà dell'utente ho impostato ALIAS, che ho utilizzato per il login, e questo è l'UDID autorizzato per il login del PC:
Di conseguenza abbiamo ottenuto:
- Autenticazione multifattoriale per l'utente e il dispositivo;
- Protezione contro la sostituzione del dispositivo utente;
- Valutazione dello stato del dispositivo;
- Potenziale per rafforzare il controllo con un certificato macchina del dominio, ecc.;
- Protezione complessiva del posto di lavoro remoto con moduli di sicurezza automaticamente distribuiti;
Link agli articoli della serie Cisco VPN:
Fonte: habr.com
