Fortsetter serien med artikler om temaet organisasjon Fjerntilgang VPN tilgang Jeg kan ikke la være å dele min interessante distribusjonsopplevelse svært sikker VPN-konfigurasjon. En ikke-triviell oppgave ble presentert av en kunde (det er oppfinnere i russiske landsbyer), men utfordringen ble akseptert og kreativt implementert. Resultatet er et interessant konsept med følgende egenskaper:
- Flere faktorer for beskyttelse mot substitusjon av terminalenheten (med streng binding til brukeren);
- Vurdere samsvaret til brukerens PC med den tildelte UDIDen til den tillatte PCen i autentiseringsdatabasen;
- Med MFA ved bruk av PC UDID fra sertifikatet for sekundær autentisering via Cisco DUO (Du kan legge ved hvilken som helst SAML/Radius-kompatibel);
- Multifaktorautentisering:
- Brukersertifikat med feltverifisering og sekundær autentisering mot en av dem;
- Innlogging (uforanderlig, hentet fra sertifikatet) og passord;
- Estimerer tilstanden til den koblende verten (Posture)
Løsningskomponenter som brukes:
- Cisco ASA (VPN Gateway);
- Cisco ISE (Autentisering / Autorisasjon / Regnskap, State Evaluation, CA);
- Cisco DUO (Multi-Factor Authentication) (Du kan legge ved hvilken som helst SAML/Radius-kompatibel);
- Cisco AnyConnect (flerbruksagent for arbeidsstasjoner og mobilt operativsystem);
La oss starte med kundens krav:
- Brukeren må, gjennom sin påloggings-/passordautentisering, kunne laste ned AnyConnect-klienten fra VPN-gatewayen; alle nødvendige AnyConnect-moduler må installeres automatisk i samsvar med brukerens retningslinjer;
- Brukeren skal kunne utstede et sertifikat automatisk (for ett av scenariene er hovedscenarioet manuell utstedelse og opplasting på en PC), men jeg implementerte automatisk utstedelse for demonstrasjon (det er aldri for sent å fjerne det).
- Grunnleggende autentisering må foregå i flere trinn, først er det sertifikatautentisering med analyse av nødvendige felt og deres verdier, deretter innlogging/passord, kun denne gangen skal brukernavnet angitt i sertifikatfeltet settes inn i innloggingsvinduet Emnenavn (CN) uten mulighet til å redigere.
- Du må sørge for at enheten du logger på fra er bedriftens bærbare datamaskin som er utstedt til brukeren for ekstern tilgang, og ikke noe annet. (Det er gjort flere alternativer for å tilfredsstille dette kravet)
- Tilstanden til tilkoblingsenheten (på dette stadiet PC) bør vurderes med en sjekk av en hel heftig tabell over kundekrav (oppsummering):
- Filer og deres egenskaper;
- Registeroppføringer;
- OS-oppdateringer fra den medfølgende listen (senere SCCM-integrasjon);
- Tilgjengelighet av Anti-Virus fra en spesifikk produsent og relevansen av signaturer;
- Aktiviteten til visse tjenester;
- Tilgjengelighet av visse installerte programmer;
Til å begynne med foreslår jeg at du definitivt ser på videodemonstrasjonen av den resulterende implementeringen Youtube (5 minutter).
Nå foreslår jeg å vurdere implementeringsdetaljene som ikke dekkes i videoklippet.
La oss forberede AnyConnect-profilen:
Jeg ga tidligere et eksempel på å lage en profil (i form av et menyelement i ASDM) i artikkelen min om innstilling . Nå vil jeg spesielt merke oss alternativene vi trenger:
I profilen vil vi indikere VPN-gatewayen og profilnavnet for tilkobling til sluttklienten:
La oss konfigurere den automatiske utstedelsen av et sertifikat fra profilsiden, spesielt angir sertifikatparametrene og, karakteristisk, ta hensyn til feltet Initialer (I), hvor en spesifikk verdi legges inn manuelt DU GJORDE testmaskin (Unik enhetsidentifikator som genereres av Cisco AnyConnect-klienten).
Her vil jeg gjøre en lyrisk digresjon, siden denne artikkelen beskriver konseptet; for demonstrasjonsformål legges UDID for utstedelse av et sertifikat inn i Initials-feltet i AnyConnect-profilen. Selvfølgelig, i det virkelige liv, hvis du gjør dette, vil alle klienter motta et sertifikat med samme UDID i dette feltet, og ingenting vil fungere for dem, siden de trenger UDID til deres spesifikke PC. AnyConnect implementerer dessverre ennå ikke substitusjon av UDID-feltet i sertifikatforespørselsprofilen via en miljøvariabel, slik den for eksempel gjør med en variabel %BRUKER%.
Det er verdt å merke seg at kunden (av dette scenariet) i utgangspunktet planlegger å uavhengig utstede sertifikater med en gitt UDID i manuell modus til slike beskyttede PC-er, noe som ikke er et problem for ham. For de fleste av oss ønsker vi imidlertid automatisering (vel, for meg er det sant =)).
Og det er dette jeg kan tilby når det gjelder automatisering. Hvis AnyConnect ennå ikke er i stand til å utstede et sertifikat automatisk ved dynamisk å erstatte UDID, så er det en annen måte som vil kreve litt kreativ tanke og dyktige hender - jeg skal fortelle deg konseptet. La oss først se på hvordan UDID genereres på forskjellige operativsystemer av AnyConnect-agenten:
- Windows — SHA-256-hash av kombinasjonen av DigitalProductID og Machine SID-registernøkkel
- OSX — SHA-256 hashplattformUUID
- Linux — SHA-256-hash for UUID til rotpartisjonen.
- Apple iOS — SHA-256 hashplattformUUID
- Android – Se dokument på
Følgelig lager vi et skript for vårt bedrifts Windows OS, med dette skriptet beregner vi lokalt UDID ved å bruke kjente innganger og danner en forespørsel om å utstede et sertifikat ved å skrive inn denne UDID i det nødvendige feltet, forresten, du kan også bruke en maskin sertifikat utstedt av AD (ved å legge til dobbel autentisering ved hjelp av et sertifikat til ordningen Flere sertifikat).
La oss forberede innstillingene på Cisco ASA-siden:
La oss lage et TrustPoint for ISE CA-serveren, det vil være den som vil utstede sertifikater til klienter. Jeg vil ikke vurdere nøkkelkjede-importprosedyren; et eksempel er beskrevet i artikkelen min om oppsett .
crypto ca trustpoint ISE-CA
enrollment terminal
crl configureVi konfigurerer distribusjon etter Tunnel-Group basert på regler i henhold til feltene i sertifikatet som brukes til autentisering. AnyConnect-profilen vi laget på forrige trinn er også konfigurert her. Vær oppmerksom på at jeg bruker verdien SECUREBANK-RA, for å overføre brukere med et utstedt sertifikat til en tunnelgruppe SECURE-BANK-VPN, vær oppmerksom på at jeg har dette feltet i kolonnen AnyConnect-profilsertifikatforespørsel.
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
!Sette opp autentiseringsservere. I mitt tilfelle er dette ISE for det første stadiet av autentisering og 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 oppretter gruppepolicyer og tunnelgrupper og deres hjelpekomponenter:
Tunnelgruppe StandardWEBVPNGroup vil primært brukes til å laste ned AnyConnect VPN-klienten og utstede et brukersertifikat ved å bruke SCEP-Proxy-funksjonen til ASA; for dette har vi de tilsvarende alternativene aktivert både på selve tunnelgruppen og på den tilhørende gruppepolicyen AC-Last ned, og på den innlastede AnyConnect-profilen (felt for utstedelse av et sertifikat osv.). Også i denne gruppepolicyen indikerer vi behovet for å laste ned ISE Posture Module.
Tunnelgruppe SECURE-BANK-VPN vil automatisk bli brukt av klienten ved autentisering med det utstedte sertifikatet i forrige trinn, siden forbindelsen i samsvar med sertifikatkartet vil falle spesifikt på denne tunnelgruppen. Jeg vil fortelle deg om interessante alternativer her:
- sekundær-autentisering-server-gruppe DUO # Angi sekundær autentisering på DUO-serveren (Radius Proxy)
- brukernavn-fra-sertifikatCN # For primær autentisering bruker vi CN-feltet i sertifikatet for å arve brukerinnloggingen
- sekundært-brukernavn-fra-sertifikat I # For sekundær autentisering på DUO-serveren bruker vi det utpakkede brukernavnet og Initials (I)-feltene til sertifikatet.
- forhåndsutfyll-brukernavnklient # gjør brukernavnet forhåndsutfylt i autentiseringsvinduet uten mulighet til å endre
- secondary-pre-fill-username client hide use-common-password push # Vi skjuler innloggings-/passordinntastingsvinduet for sekundær autentisering DUO og bruker varslingsmetoden (sms/push/telefon) - dock for å be om autentisering i stedet for passordfeltet
!
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
!Deretter går vi videre til ISE:
Vi konfigurerer en lokal bruker (du kan bruke AD/LDAP/ODBC osv.), for enkelhets skyld opprettet jeg en lokal bruker i selve ISE og tilordnet den i feltet beskrivelse UDID PC hvorfra han får logge inn via VPN. Hvis jeg bruker lokal autentisering på ISE, vil jeg være begrenset til kun én enhet, siden det ikke er mange felt, men i tredjeparts autentiseringsdatabaser vil jeg ikke ha slike begrensninger.
La oss se på autorisasjonspolitikken, den er delt inn i fire tilkoblingsstadier:
- Stage 1 — Retningslinjer for nedlasting av AnyConnect-agenten og utstedelse av et sertifikat
- Stage 2 — Primær autentiseringspolicy Pålogging (fra sertifikat)/passord + sertifikat med UDID-validering
- Stage 3 — Sekundær autentisering via Cisco DUO (MFA) med UDID som brukernavn + tilstandsvurdering
- Stage 4 — Endelig autorisasjon er i staten:
- kompatibel;
- UDID-validering (fra sertifikat + påloggingsbinding),
- Cisco DUO MFA;
- Autentisering ved pålogging;
- Sertifikatautentisering;
La oss se på en interessant tilstand UUID_VALIDATED, det ser bare ut som om autentiseringsbrukeren faktisk kom fra en PC med en tillatt UDID tilknyttet i feltet Beskrivelse konto, ser betingelsene slik ut:
Autorisasjonsprofilen brukt i trinn 1,2,3 er som følger:
Du kan sjekke nøyaktig hvordan UDID fra AnyConnect-klienten kommer til oss ved å se på klientsesjonsdetaljene i ISE. I detalj vil vi se at AnyConnect gjennom mekanismen ACIDEX sender ikke bare informasjon om plattformen, men også UDID for enheten som Cisco-AV-PAIR:
La oss ta hensyn til sertifikatet som er utstedt til brukeren og feltet Initialer (I), som brukes til å ta det som en pålogging for sekundær MFA-autentisering på Cisco DUO:
På DUO Radius Proxy-siden i loggen kan vi tydelig se hvordan autentiseringsforespørselen er laget, den kommer med UDID som brukernavn:
Fra DUO-portalen ser vi en vellykket autentiseringshendelse:
Og i brukeregenskapene har jeg det satt ALIAS, som jeg brukte for pålogging, i sin tur er dette UDID-en til PC-en som er tillatt for pålogging:
Som et resultat fikk vi:
- Multi-faktor bruker- og enhetsautentisering;
- Beskyttelse mot forfalskning av brukerens enhet;
- Vurdere tilstanden til enheten;
- Potensial for økt kontroll med domenemaskinsertifikat, etc.;
- Omfattende beskyttelse på ekstern arbeidsplass med automatisk utplasserte sikkerhetsmoduler;
Lenker til Cisco VPN-seriens artikler:
Kilde: www.habr.com