Fortsätter serien av artiklar om ämnet organisering Remote-Access VPN av tillgång kan jag inte undanhålla en intressant erfarenhet av implementeringen av en högsäkerhetskonfiguration av VPN. En utmanande uppgift gavs av en kund (det finns påhittiga personer i ryska byar), men Challenge Accepted och kreativt genomfört. Resultatet blev ett intressant koncept med följande egenskaper:
- Flera skyddsfaktorer mot förfalskning av den slutliga enheten (med strikt koppling till användaren);
- Bedömning av användarens dator mot den tilldelade UDID för den godkända datorn i autentiseringsdatabasen;
- Med MFA som använder UDID för datorn från certifikatet för sekundär autentisering via Cisco DUO (Kan kopplas till vilket SAML/RADIUS-kompatibelt system som helst);
- Multifaktorsautentisering:
- Användarcertifikat med kontroll av fälten och sekundär autentisering enligt ett av dem;
- Inloggning (oförändrad, hämtad från certifikatet) och lösenord;
- Bedömning av den anslutna värden (Posture)
Använda komponenter i lösningen:
- Cisco ASA (VPN-gateway);
- Cisco ISE (Autentisering / Auktorisering / Redovisning, Bedömning av Status, CA);
- Cisco DUO (Multifaktorsautentisering) (Kan kopplas till vilket SAML/RADIUS-kompatibelt system som helst);
- Cisco AnyConnect (Mångsidig agent för arbetsstationer och mobila operativsystem);
Låt oss börja med kundens krav:
- Användaren ska ha möjlighet att ladda ner AnyConnect-klienten från VPN-gatewayen med sin autentisering av Inloggning/Lösenord, alla nödvändiga AnyConnect-moduler ska automatiskt installeras enligt användarens policy;
- Användaren ska ha möjlighet till automatisk utfärdande av certifikat (för ett av scenarierna, huvudsakligen är scenariot manuell utfärdande och uppladdning på datorn), jag har implementerat automatisk utfärdande för demonstration (det är aldrig för sent att ta bort).
- Den primära autentiseringen ska ske i flera steg, först ges certifikatets autentisering med analys av nödvändiga fält och deras värden, därefter inloggning/lösenord, fast nu ska användarnamnet som anges i certifikatets fält Subject Name (CN) ställas in utan möjlighet till redigering.
- Det är nödvändigt att säkerställa att enheten som används för inloggningen är den företagsbärbara dator som har utfärdats till användaren för fjärråtkomst, och inget annat. (Flera alternativ har skapats för att uppfylla detta krav)
- Det ska göras en bedömning av det anslutande enhetens tillstånd (vid detta steg PC) med en kontroll av en heltäckande kravtabell från kunden (för att sammanfatta):
- Filer och deras egenskaper;
- Registerposter;
- Operativsystemspatchar från den angivna listan (i framtiden integration av SCCM);
- Närvaro av antivirus från en viss tillverkare och aktuell signatur;
- Aktivitet hos vissa tjänster;
- Närvaro av vissa installerade program;
Först föreslår jag att vi obligatoriskt tittar på videodemonstrationen av den resulterande implementationen på Youtube (5 minuter).
Nu föreslår jag att vi ser på detaljerna i implementationen som inte belyses i videon.
Låt oss förbereda en AnyConnect-profil:
Exempel på hur man skapar en profil (i menypunkt i ASDM) har jag tidigare tagit upp i min artikel om inställning av . Nu vill jag särskilt nämna de alternativ som vi behöver:
I profilen anger vi VPN-gatewayen och profilnamnet för anslutning på klienten:
Vi utför inställningar för automatisk utfärdande av certifikat från profilen, där vi anger bland annat certifikatparametrarna, och som är relevant, noterar vi fältet Initials (I), där ett specifikt värde har skrivits in för hand UDID för testmaskinen (Unik enhetsidentifierare som genereras av Cisco AnyConnect-klienten).
Här vill jag göra en poetisk avvikelse, eftersom denna artikel beskriver konceptet; för demonstrationssyften har UDID angetts för utfärdande av certifikatet i fältet Initials av AnyConnect-profilen. Självklart, i verkliga livet, om du gör så, kommer alla klienter att få certifikatet med samma UDID i detta fält, och inget av dem kommer att fungera, eftersom de behöver UDID specifikt för sin egen PC. Tyvärr implementerar AnyConnect ännu inte ersättning i profilen för certifikatförfrågan i UDID-fältet via miljövariabeln, som den till exempel gör med variabeln %USER%.
Det är värt att notera att kunden (i detta scenario) ursprungligen planerar att själv utfärda certifikat med angiven UDID manuellt till dessa skyddade PC, vilket inte är något problem för honom. Men för de flesta av oss vill vi ha automatisering (åh, för mig i alla fall=).
Och här är vad jag kan erbjuda när det kommer till automatisering. Om man automatiskt skulle utfärda ett certifikat i AnyConnect genom att dynamiskt infoga UDID, vilket inte är möjligt just nu, finns det en annan metod som kräver lite kreativt tänkande och skickliga händer – jag ska förklara konceptet. Låt oss börja med att titta på hur UDID skapas på olika operativsystem av AnyConnect-agenten:
- Windows — SHA-256 hash av kombinationen av registret DigitalProductID och Machine SID
- OSX — SHA-256 hash av PlatformUUID
- Linux — SHA-256 hash av UUID för root-partitionen.
- Apple iOS — SHA-256 hash av PlatformUUID
- Android – Se dokumentet om
Därför skapar vi ett skript för våra företags-operativsystem Windows, där detta skript lokalt beräknar UDID baserat på kända indata och genererar en begäran om utfärdande av certifikat genom att fylla i UDID i det nödvändiga fältet, förresten kan det också vara ett maskincertifikat som utfärdats av AD (genom att lägga till dubbel autentisering genom certifikat) Multiple Certificate).
Vi förbereder inställningar från Cisco ASA:
Vi skapar TrustPoint för ISE CA-servern, som kommer att utfärda certifikat till klienterna. Jag kommer inte att gå igenom proceduren för att importera Key-Chain, det exemplet beskrivs i min artikel om inställning .
crypto ca trustpoint ISE-CA
enrollment terminal
crl configureVi konfigurerar distributionen för Tunnel-Group baserat på regler i enlighet med fälten i certifikatet, som används för autentisering. Här konfigurerar vi också profil för AnyConnect, som vi skapade i föregående steg. Jag vill påpeka att jag använder värdet SECUREBANK-RA, för att överföra användare med utfärdat certifikat till tunnelgruppen SECURE-BANK-VPN, observera att detta fält har angetts i begäran om certifikat för profilen 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
!Vi konfigurerar autentiseringstjänster. I mitt fall är det ISE för det första steget i autentisering och DUO (Radius Proxy) som 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
!Vi skapar grupprinciper och tunnelgrupper samt deras stödkomponenter:
Tunnelgrupp DefaultWEBVPNGroup kommer primärt att användas för att ladda ner AnyConnect VPN-klienten och utfärda användarcertifikat med SCEP-Proxy-funktionen i ASA. För detta har vi aktiverat motsvarande alternativ både i tunnelgruppen och i den associerade gruppolisen. AC-Nedladdning, samt i den nedladdade AnyConnect-profilen (fälten för certifikatutfärdande osv.). I denna gruppolicy anger vi också behovet av nedladdning. ISE Posture Module.
Tunnelgrupp SECURE-BANK-VPN kommer automatiskt att användas av klienten vid autentisering med det utfärdade certifikatet från föregående steg, eftersom kopplingen enligt Certificate Map kommer att tillhöra just denna tunnelgrupp. Jag kommer att berätta om intressanta alternativ här:
- secondary-authentication-server-group DUO # Задаем вторичную аутентификацию на сервере DUO (Radius Proxy)
- användarnamn-från-certifikat CN # Используем для первичной аутентификации поле CN сертификата для наследования логина пользователя
- sekundärt-användarnamn-från-certifikat I # Для вторичной аутентификации на сервере DUO используем имя пользователя, извлеченное и поля Initials (I) сертификата.
- förifyllda-användarnamn klient # делаем предзаполненным имя пользователя в окне аутентификации без возможности изменения
- sekundärt-förifyllt-användarnamn klient göm använd-gemensamt-lösenord push # Прячем окно ввода логина/пароля для вторичной аутентификации DUO и используем для запроса аутентификации вместо поля пароля метод уведомления (sms/push/phone) – дока
!
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
!Låt oss gå vidare till ISE:
Vi konfigurerar en lokal användare (AD/LDAP/ODBC etc. kan också användas), för enkelhetens skull har jag skapat en lokal användare i ISE och tilldelat fältet description PC:s UDID från vilken inloggning via VPN är tillåten. Vid användning av lokal autentisering på ISE kommer jag att vara begränsad till en enhet, eftersom det inte finns så många fält, men det kommer inte att finnas några sådana begränsningar i externa autentiseringsdatabaser.
Låt oss titta på auktoriseringspolicyn, den är uppdelad i fyra faser av anslutning:
- Steg 1 — Policyn för nedladdning av AnyConnect-agenten och utförande av certifikat
- Steg 2 — Policyn för primär autentisering Inloggning (från certifikat)/Lösenord + Certifikat med UDID-validering
- Steg 3 — Sekundär autentisering via Cisco DUO (MFA) med UDID som användarnamn + tillståndsvärdering
- Steg 4 — Slutlig auktorisering i tillstånd:
- Efterlevande;
- validering av UDID (från certifikat + koppling till inloggning),
- Cisco DUO MFA;
- Inloggningsautentisering;
- Certifikatautentisering;
Låt oss titta på en intressant villkor UUID_VALIDATED, som just kontrollerar att den autentiserande användaren verkligen kommer från en PC med den godkända UDID kopplad i fältet Beskrivning kontot, villkoren ser ut så här:
Auktoriseringsprofilen som används i steg 1, 2, 3 ser ut som följer:
Vi kan kontrollera hur UDID kommer från klienten AnyConnect genom att titta på ISE:s sessionsdetaljer. I detaljerna ser vi att AnyConnect via mekanismen ACIDEX skickar inte bara plattformsdata, utan även UDID för enheten som Cisco-AV-PAIR:
Låt oss notera det utfärdade certifikatet för användaren och fältet Initials (I), som används för att ta det som inloggningsnamn för sekundär MFA-autentisering på Cisco DUO:
På DUO Radius Proxy-sidan ser vi tydligt hur autentiseringsförfrågan går, den sker med UDID som användarnamn:
Från DUO-portalen ser vi en lyckad autentisering:
Och i användarens egenskaper har jag angett ALIAS, som jag använde för inloggning, och detta är UDID för den godkända inloggnings-PC:n:
Som ett resultat fick vi:
- Flerfaktorautentisering för användare och enhet;
- Skydd mot förfalskning av användarens enhet;
- Utvärdering av enhetens tillstånd;
- Potential för ökad kontroll med maskincertifikat för domänen etc.;
- Omfattande skydd för fjärrarbetsplatsen med automatiskt distribuerade säkerhetsmoduler;
Länkar till artiklar i Cisco VPN-serien:
Källa: habr.com
