Implementatie van het concept van hoogbeschermde remote toegang

Terwijl we de serie artikelen over de organisatie van Remote-Access VPN toegang voortzetten, kan ik niet anders dan een interessante ervaring delen over het opzetten van een hoogbeveiligde VPN-configuratie.Een niet-triviale uitdaging werd voorgeschoteld door een klant (er zijn creatievelingen in Russische dorpen), maar uitdaging aanvaard en creatief gerealiseerd. Het resultaat is een interessant concept met de volgende kenmerken:

  1. Meerdere beschermingsfactoren tegen het vervalsen van eindapparatuur (met strikte binding aan de gebruiker);
    • Beoordeling of de computer van de gebruiker overeenkomt met de toegewezen UDID van de toegestane computer in de authenticatiedatabase;
    • Met MFA, die de UDID van de computer uit het certificaat gebruikt voor secundaire authenticatie via Cisco DUO; (Elke SAML/RADIUS-compatibele kan worden gekoppeld);
  2. Multifactorauthenticatie:
    • Een gebruikerscertificaat met controle van de velden en secundaire authenticatie op een van deze velden;
    • Inloggen (niet wijzigbaar, genomen uit het certificaat) en wachtwoord;
  3. Beoordeling van de status van de verbindende host (Posture);

Gebruikte componenten van de oplossing:

  • Cisco ASA (VPN-gateway);
  • Cisco ISE (Authenticatie / Autorisatie / Accounting, Statusbeoordeling, CA);
  • Cisco DUO (Multifactorauthenticatie); (Elke SAML/RADIUS-compatibele kan worden gekoppeld);
  • Cisco AnyConnect (multifunctionele agent voor werkstations en mobiele besturingssystemen);

Laten we beginnen met de vereisten van de klant:

  1. De gebruiker moet via zijn authenticatie Inloggen/Wachtwoord in staat zijn de AnyConnect-client van de VPN-gateway te downloaden; alle noodzakelijke AnyConnect-modules moeten automatisch worden geïnstalleerd volgens het gebruikersbeleid;
  2. De gebruiker moet in staat zijn om automatisch een certificaat te ontvangen (voor een van de scenario's, het belangrijkste scenario is echter handmatige uitgifte en uploaden naar de computer); ik heb automatische uitgifte gerealiseerd ter demonstratie (het verwijderen ervan kan nog altijd later).
  3. De primaire authenticatie moet in meerdere fasen plaatsvinden; eerst is er de certificaatauthenticatie met analyse van de benodigde velden en hun waarden, daarna inloggen/wachtwoord, maar deze keer moet in het inlogvenster de gebruikersnaam worden ingevuld zoals aangegeven in het certificaatveld Subject Name (CN) zonder bewerkingsmogelijkheden.
  4. Het moet worden bevestigd dat het apparaat waarmee wordt ingelogd de corporate laptop is die aan de gebruiker is uitgegeven voor externe toegang, en niets anders. (Er zijn verschillende opties gedaan om aan deze eis te voldoen.)
  5. Een beoordeling van de staat van het aangesloten apparaat (in deze fase de pc) moet worden uitgevoerd met een controle van de uitgebreide eisenlijst van de klant (samengevat):
    • Bestanden en hun eigenschappen;
    • Registervermeldingen;
    • Besturingssysteem patches uit de aangeleverde lijst (verder integratie SCCM);
    • Aanwezigheid van antivirus van een specifieke leverancier en actualiteit van handtekeningen;
    • Activiteit van bepaalde services;
    • Aanwezigheid van bepaalde geïnstalleerde programma's;

Eerst stel ik voor om verplicht een video-demonstratie van de gerealiseerde implementatie te bekijken op YouTube (5 minuten).

Video afspelen

Nu stel ik voor om de implementatiedetails te bespreken die niet in de video zijn behandeld.

Laten we een AnyConnect-profiel voorbereiden:

Een voorbeeld van het maken van een profiel (in termen van het menu-item in ASDM) heb ik eerder genoemd in mijn artikel over de configuratie van VPN Load-Balancing cluster. Momenteel wil ik de opties benadrukken die we nodig hebben:

In het profiel geven we de VPN-gateway en de naam van het profiel voor verbinding aan op de eindclient:

Implementatie van het concept van hoogbeschermde remote toegang

We zullen de instellingen voor het automatisch uitgeven van certificaten vanaf het profiel uitvoeren, waarbij we onder andere de certificaatparameters opgeven, en opmerkelijk genoeg, de nadruk leggen op het veld Initials (I), waarin handmatig een specifiek waarde is ingevuld UDID van de testmachine (de unieke identificatie van het apparaat, gegenereerd door de Cisco AnyConnect-client).

Implementatie van het concept van hoogbeschermde remote toegang

Hier wil ik een lyrische uitweiding maken, aangezien dit artikel het concept beschrijft, is hier voor demonstratiedoeleinden de UDID ingevuld voor het uitgeven van het certificaat in het Initials-veld van het AnyConnect-profiel. Natuurlijk, in de echte wereld, als je het zo doet, ontvangen alle klanten een certificaat met dezelfde UDID in dit veld en zal niets voor hen werken, aangezien ze een UDID van hun specifieke pc nodig hebben. AnyConnect implementeert helaas voorlopig geen substitutie in het profiel voor het aanvragen van het certificaat in het UDID-veld via een omgevingsvariabele, zoals het bijvoorbeeld doet met de variabele %USER%.

Het is vermeldenswaard dat de klant (van dit scenario) oorspronkelijk van plan is om certificaten met de opgegeven UDID handmatig uit te geven aan dergelijke Beveiligde pc's, wat voor hem geen probleem is. Echter, voor de meeste van ons willen we automatisering (nou, voor mij in ieder geval=) ).

En dit is wat ik kan voorstellen op het gebied van automatisering. Als het automatisch ophalen van een certificaat met AnyConnect, waarbij de UDID dynamisch wordt ingevuld, nog niet mogelijk is, is er een andere manier die een beetje creatief denken en vaardige handen vereist – ik zal het concept uitleggen. Laten we eerst eens bekijken hoe de UDID wordt gegenereerd op verschillende besturingssystemen door de AnyConnect-agent:

  • Windows — SHA-256 hash van de combinatie van de register sleutel DigitalProductID en Machine SID
  • OSX — SHA-256 hash van PlatformUUID
  • Linux — SHA-256 hash van de UUID van de root-partitie.
  • Apple iOS — SHA-256 hash van PlatformUUID
  • Android – Zie het document over de link

Daarom maken we een script voor onze bedrijfsbesturingssystemen Windows, met dit script berekenen we lokaal de UDID op basis van de bekende invoer en creëren we een aanvraag voor het uitgeven van een certificaat, waarbij we deze UDID in het juiste veld invoeren, overigens kan dit ook voor het machine-certificaat, dat door AD is uitgegeven (door dubbele authenticatie via certificaat aan de schema toe te voegen) Meerdere certificaten).

We bereiden de instellingen aan de kant van Cisco ASA voor:

We creëren een TrustPoint voor de ISE CA-server, die certificaten aan klanten zal uitgeven. De procedure voor het importeren van Key-Chain zal ik niet behandelen, dit is beschreven in mijn artikel over configuratie. VPN Load-Balancing cluster.

crypto ca trustpoint ISE-CA
 enrollment terminal
 crl configure

We configureren de toewijzing op basis van regels overeenkomstig de velden in het certificaat, waarmee authenticatie plaatsvindt. Hier wordt ook het AnyConnect-profiel ingesteld, dat we in de vorige fase hebben gemaakt. Ik wil opmerken dat ik de waarde gebruik SECUREBANK-RA, om gebruikers met de uitgegeven certificaat naar de tunnelgroep te verplaatsen SECURE-BANK-VPN, let op dat dit veld bij mij is ingevuld in het aanvraagformulier voor het certificaat van het AnyConnect-profiel.

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
!

We configureren de authenticatieservers. In mijn geval is dit ISE voor de eerste fase van authenticatie en DUO (Radius Proxy) als 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
!

We creëren groepsbeleid en tunnelgroepen en hun ondersteunende componenten:

Tunnelgroep DefaultWEBVPNGroup zal worden gebruikt voor het downloaden van de AnyConnect VPN-client en het uitgeven van het gebruikerscertificaat met behulp van de SCEP-Proxy functie van ASA. Hiervoor zijn de bijbehorende opties geactiveerd, zowel in de tunnelingroep als in het bijbehorende groepsbeleid. AC-Download, en in het te downloaden AnyConnect-profiel (velden voor certificaatuitgifte, enz.). In dit groepsbeleid geven we ook aan dat download nodig is. ISE Posture Module.

Tunnelgroep SECURE-BANK-VPN zal automatisch door de client worden gebruikt bij authenticatie met het uitgegeven certificaat in de vorige fase, omdat volgens de Certificate Map de verbinding precies op deze tunnelingroep zal vallen. Ik zal hier meer vertellen over interessante opties:

  • secondary-authentication-server-group DUO # Задаем вторичную аутентификацию на сервере DUO (Radius Proxy)
  • username-from-certificate CN # Используем для первичной аутентификации поле CN сертификата для наследования логина пользователя
  • secondary-username-from-certificate I # Для вторичной аутентификации на сервере DUO используем имя пользователя, извлеченное и поля Initials (I) сертификата.
  • pre-fill-username client # делаем предзаполненным имя пользователя в окне аутентификации без возможности изменения
  • secondary-pre-fill-username client hide use-common-password push # Прячем окно ввода логина/пароля для вторичной аутентификации DUO и используем для запроса аутентификации вместо поля пароля метод уведомления (sms/push/phone) – дока here

!
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
!

Laten we verder gaan met ISE:

We stellen een lokale gebruiker in (ook AD/LDAP/ODBC kan gebruikt worden), voor de eenvoud heb ik een lokale gebruiker in ISE gemaakt en toegewezen in het veld description PC UDID waarvan toegang via VPN is toegestaan. In het geval van lokale authenticatie op ISE ben ik beperkt tot slechts één apparaat, omdat er niet veel velden zijn, maar bij externe authenticatiedatabases heb ik deze beperkingen niet.

Implementatie van het concept van hoogbeschermde remote toegang

Laten we kijken naar het autorisatiebeleid, dit is verdeeld in vier verbindingsfasen:

  • Stap 1 — Beleid voor het downloaden van de AnyConnect-agent en het uitgeven van een certificaat
  • Stap 2 — Primair authenticatiebeleid Inloggen (uit het certificaat)/Wachtwoord + Certificaat met UDID-validatie
  • Fase 3 — Secundaire authenticatie via Cisco DUO (MFA) op UDID als gebruikersnaam + Statusbeoordeling
  • Fase 4 — Eindautorisation in status:
    • Compliant;
    • met UDID-validatie (uit het certificaat + gekoppeld aan de inlognaam),
    • Cisco DUO MFA;
    • Authenticatie op basis van inloggen;
    • Authenticatie op basis van certificaat;

Implementatie van het concept van hoogbeschermde remote toegang

Laten we eens kijken naar een interessante voorwaarde UUID_VALIDATED, deze controleert of de aanmeldende gebruiker daadwerkelijk is ingelogd vanaf een PC met de toestemming van de UDID die aan het veld is gekoppeld Beschrijving van het account, de voorwaarden zien er als volgt uit:

Implementatie van het concept van hoogbeschermde remote toegang

Het autorisatieprofiel dat wordt gebruikt in fasen 1, 2, 3 ziet er als volgt uit:

Implementatie van het concept van hoogbeschermde remote toegang

We kunnen controleren hoe de UDID van de AnyConnect-klant binnenkomt door in ISE naar de sessiedetails van de cliënt te kijken. In de details zien we dat AnyConnect via het mechanisme ACIDEX niet alleen gegevens over het platform verzendt, maar ook de UDID van het apparaat als Cisco-AV-PAIR:

Implementatie van het concept van hoogbeschermde remote toegang

Laten we kijken naar het uitgegeven certificaat aan de gebruiker en het veld Initials (I), dat wordt gebruikt om het als inlognaam voor secundaire MFA-authenticatie op Cisco DUO te nemen:

Implementatie van het concept van hoogbeschermde remote toegang

Aan de DUO Radius Proxy-kant zien we duidelijk hoe het verzoek voor authenticatie wordt gedaan, dit gaat met gebruik van de UDID als gebruikersnaam:

Implementatie van het concept van hoogbeschermde remote toegang

Aan de DUO-portaalzijde zien we een succesvolle authenticatie gebeurtenis:

Implementatie van het concept van hoogbeschermde remote toegang

En in de eigenschappen van de gebruiker is er een ALIAS, die ik heb gebruikt voor inloggen, dit is de UDID die is toegestaan voor inloggen op de PC:

Implementatie van het concept van hoogbeschermde remote toegang

Als resultaat hebben we gekregen:

  • Multi-factor authenticatie voor de gebruiker en het apparaat;
  • Bescherming tegen apparaten van gebruikers die zijn vervangen;
  • Beoordeling van de status van het apparaat;
  • Potentieel voor versterkte controle met een machines certificaat van het domein, enz.;
  • Integrale bescherming van de externe werkplek met automatisch uitrolbare beveiligingsmodules;

Links naar de artikelen in de Cisco VPN-serie:

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster