Dit document biedt informatie over de manier waarop u inline houdingen kunt instellen met een adaptieve security applicatie (ASA) en een Identity Services Engine (ISE).
Er zijn geen specifieke vereisten van toepassing op dit document.
De informatie in dit document is gebaseerd op versie 8.2(4) voor de ASA en versie 1.1.0.665 voor de ISE.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
De ISE biedt veel AAA-services (houding, profilering, verificatie, etc.). Sommige Network Devices (NAD) ondersteunen Radius Change of Authorisation (CoA), waarmee het autorisatieprofiel van een eindapparaat dynamisch kan worden gewijzigd op basis van de houding of het resultaat van de profilering. Andere NAD's zoals de ASA ondersteunen deze optie nog niet. Dit betekent dat een ISE die in Inline Positie Enforcement Mode (iPEP) loopt nodig is om het netwerktoegangsbeleid van een eindapparaat dynamisch te wijzigen.
Het basisconcept is dat al het gebruikersverkeer door de iPEP zal gaan, waarbij het knooppunt ook fungeert als een Radius Proxy.
VPN Gebruiker inlogt.
ASA stuurt het verzoek naar het iPEP-knooppunt (ISE).
De iPEP herschrijft het verzoek (door Cisco AV-pair-kenmerken toe te voegen om aan te geven dat het een iPEP-verificatie betreft) en stuurt het verzoek naar het ISE Policy Node (PDP).
De PDP antwoordt terug op de iPEP die naar het NAD zal worden gestuurd.
Als de gebruiker is geverifieerd, MOET de NAD een aanvraag voor het opstarten van een accounting verzenden (zie CSCtz84826 ). Hierdoor wordt de sessie gestart op de iPEP. In deze fase wordt de gebruiker omgeleid naar postuur. Daarnaast moet u interim-accounting-update mogelijk maken voor tunnels die vanuit het WEBVPN-portaal zijn gemaakt, omdat de ISE verwacht dat het attribuut framed-ip-adres in de radius-accounting zal zijn. Wanneer u echter verbinding maakt met het portal, is het VPN IP-adres van de client nog niet bekend, omdat de tunnel niet is geopend. Dit zal ervoor zorgen dat de ASA tussentijdse updates zal verzenden, zoals wanneer de tunnel zal worden opgezet.
De gebruiker gaat door de postuur beoordeling, en op basis van de resultaten zal de PDP de sessie met behulp van CoA op de iPEP.
Deze screenshot illustreert dit proces:
De ASA Configuration is een eenvoudige IPSEC Remote VPN:
! interface Ethernet0/0 nameif ISE security-level 50 ip address 192.168.102.253 255.255.255.0 ! interface Ethernet0/1 nameif outside security-level 0 ip address 10.48.39.236 255.255.255.0 ! access-list split extended permit ip 192.168.0.0 255.255.0.0 any ! aaa-server ISE protocol radius interim-accounting-update !--- Mandatory if tunnel established from WEBVPN Portal aaa-server ISE (ISE) host 192.168.102.254 !--- this is the iPEP IP key cisco crypto ipsec transform-set TS1 esp-aes esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto dynamic-map DMAP1 10 set transform-set TS1 crypto dynamic-map DMAP1 10 set reverse-route crypto map CM1 10 ipsec-isakmp dynamic DMAP1 crypto map CM1 interface outside crypto isakmp enable outside crypto isakmp policy 1 authentication pre-share encryption aes hash sha group 2 lifetime 86400 ! ip local pool VPN 192.168.5.1-192.168.5.100 ! group-policy DfltGrpPolicy attributes dns-server value 192.168.101.3 !--- The VPN User needs to be able to resolve the CN from the !--- ISE HTTPS Certificate (which is sent in the radius response) vpn-tunnel-protocol IPSec svc webvpn split-tunnel-policy tunnelspecified split-tunnel-network-list value split address-pools value VPN ! tunnel-group cisco general-attributes address-pool VPN authentication-server-group ISE accounting-server-group ISE !--- Does not work without this (see introduction) ! tunnel-group cisco ipsec-attributes pre-shared-key cisco ! route outside 0.0.0.0 0.0.0.0 10.48.39.5 1 route ISE 192.168.0.0 255.255.0.0 192.168.102.254 1 !--- You need to make sure the traffic to the local subnets !--- are going through the inline ISE !
Het eerste wat u moet doen is een ISE als iPEP-knooppunt toevoegen. Hier vindt u aanvullende informatie over het proces:
http://www.cisco.com/en/US/docs/security/ise/1.1/user_guide/ise_ipep_deploy.html#wp1110248.
Dit is in principe wat u in de verschillende tabbladen moet configureren (screenshots in deze sectie illustreren dit):
Configureer onbetrouwbare IP- en wereldwijde IP-instellingen (in dit geval is onbetrouwbare IP 192.168.102.254).
De implementatie is routed mode.
Plaats een statisch filter voor de ASA die door het iPEP-vak moet kunnen gaan (anders wordt de verbinding van/naar de ISE-verbinding via het iPEP-vak verbroken).
Configureer de Policy ISE als Radius-server en de ASA als Radius-client.
Voeg een route toe aan VPN Subnet die naar de ASA verwijst.
Stel de Monitoring ISE in als de Logging Host (poort 20514 standaard; in dit geval wordt ook het beleid ISE gecontroleerd).
Belangrijke vereisten voor certificaatconfiguratie:
Voordat u probeert een iPEP-knooppunt te registreren, moet u ervoor zorgen dat aan de volgende vereisten voor uitgebreid gebruik van certificaten wordt voldaan. Als de certificaten niet goed zijn geconfigureerd op de iPEP- en Admin-knooppunten, wordt het registratieproces voltooid. U verliest echter de admin-toegang tot de iPEP-knooppunt. De volgende details zijn geëxtrapoleerd uit de ISE 1.1.x iPEP-implementatiegids:
De aanwezigheid van bepaalde combinaties van attributen in de lokale certificaten van de Administratie en de Inline Posture knooppunten kan de wederzijdse authenticatie verhinderen te werken.
De eigenschappen zijn:
Extended Key Usage (EKU) - serververificatie
Extended Key Usage (EKU)—clientverificatie
Netscape Cert Type-SSL-serververificatie
Netscape Cert Type-SSL-clientverificatie
Voor het certificaat van toediening is een van de volgende combinaties vereist:
Beide EKU-kenmerken moeten worden uitgeschakeld als beide EKU-kenmerken zijn uitgeschakeld in het certificaat Inline Posture, of beide EKU-kenmerken moeten worden ingeschakeld als het serverkenmerk is ingeschakeld in het certificaat Inline Posture.
Beide eigenschappen van het type Netscape Cert moeten worden uitgeschakeld of beide moeten worden ingeschakeld.
Voor het certificaat van inline houding is een van de volgende combinaties vereist:
Beide EKU-kenmerken moeten worden uitgeschakeld, of beide moeten worden ingeschakeld, of het serverkenmerk alleen moet worden ingeschakeld.
Beide attributen van het type van Netscape Cert moeten worden uitgeschakeld, of beide moeten worden ingeschakeld, of het attribuut van de server alleen moet worden ingeschakeld.
Waar zelfondertekende lokale certificaten worden gebruikt op de knooppunten Administratie en Inline Posture, moet u het zelf-ondertekende certificaat van het knooppunt Administratie installeren in de vertrouwenslijst van het knooppunt Inline Posture. Daarnaast, als u zowel primaire als secundaire beheerknooppunten in uw implementatie hebt, moet u het zelfondertekende certificaat van beide beheerknooppunten in de vertrouwenslijst van de Inline Positie-knooppunt installeren.
Waar CA-ondertekende lokale certificaten worden gebruikt op de Administratie en de Inline Posture knooppunten, zou de wederzijdse authentificatie correct moeten werken. In dit geval wordt het certificaat van de ondertekenende CA geïnstalleerd op het beheerknooppunt voorafgaand aan de registratie, en dit certificaat wordt gerepliceerd naar het knooppunt Inline Posture.
Als door CA uitgegeven sleutels worden gebruikt voor het beveiligen van de communicatie tussen de Administratie en de Inline Posture knooppunten, voordat u het Inline Posture knooppunt registreert, moet u de openbare sleutel (CA-certificaat) van het Administratie knooppunt toevoegen aan de CA-certificaatlijst van het Inline Posture knooppunt.
Basisconfiguratie:
Configuratie implementatiemodus:
Configuratie filters:
Radiusconfiguratie:
Statische routers:
Logboekregistratie:
Er zijn drie houdingen:
Unknown: Positie is nog niet gemaakt
Voldoet aan: houding is gemaakt en het systeem is conform
Niet conform: houding is gemaakt, maar het systeem faalde ten minste één controle
Nu moeten de autorisatieprofielen worden gemaakt (dit worden inline autorisatieprofielen: dit wordt het kenmerk ipep-authz=true in het Cisco AV-paar toegevoegd) dat voor de verschillende gevallen wordt gebruikt.
Meestal, het Onbekende profiel retourneert de omleiding URL (posture discovery) die het verkeer van de gebruiker door zal sturen naar de ISE en zal vragen om de NAC Agent te installeren. Als de NAC Agent al is geïnstalleerd, kan de HTTP-detectieaanvraag worden doorgestuurd naar de ISE.
In dit profiel wordt minimaal een ACL gebruikt die HTTP-verkeer naar de ISE en DNS toestaat.
De compatibele en niet-conforme profielen retourneren doorgaans een downloadbare ACL om netwerktoegang te verlenen op basis van het gebruikersprofiel. Niet-conforme profiel kan de gebruikers toegang geven tot een webserver om bijvoorbeeld een antivirus te downloaden of beperkte netwerktoegang te verlenen.
In dit voorbeeld worden de Onbekende en Conforme profielen gemaakt, en wordt de aanwezigheid van notepad.exe als requirements gecontroleerd.
Het eerste wat u moet doen, is de downloadbare ACL’s (dACL’s) en profielen maken:
Opmerking: dit is niet verplicht om de dACL-naam te laten overeenkomen met de profielnaam.
conform
ACL: IP-onbekend
Autorisatieprofiel: ipep-onbekend
Niet conform
ACL: Ipep-niet-conform
Vergunningsprofiel: niet-conform Ipep
Onbekende dACL:
Onbekend profiel:
Conforme dACL:
Conform profiel:
Nu het profiel is gemaakt, moet u overeenkomen met de Radius-aanvraag van de iPEP en de juiste profielen op hen toepassen. De iPEP ISE’s zijn gedefinieerd met een speciaal apparaattype dat in de autorisatieregels zal worden gebruikt:
NAD’s:
Authorization:
N.B.: Als de agent niet op het apparaat is geïnstalleerd, kunt u regels voor clientprovisioning definiëren.
U wordt gevraagd de agent te installeren (in dit voorbeeld is de client provisioning al ingesteld):
Er wordt in dit stadium output gegenereerd:
ciscoasa# show vpn-sessiondb remote Session Type: IPsec Username : cisco Index : 26 Assigned IP : 192.168.5.2 Public IP : 10.48.39.134 Protocol : IKE IPsec License : IPsec Encryption : AES128 Hashing : SHA1 Bytes Tx : 143862 Bytes Rx : 30628 Group Policy : DfltGrpPolicy Tunnel Group : cisco Login Time : 13:43:55 UTC Mon May 14 2012 Duration : 0h:09m:37s Inactivity : 0h:00m:00s NAC Result : Unknown VLAN Mapping : N/A VLAN : none
En van de iPEP:
w-ise-ipep-1/admin# show pep table session Current Sessions (IP, MAC(if available), Profile ID, VLAN (if any)): 192.168.5.2 00:00:00:00:00:00 2 0 w-ise-ipep-1/admin# show pep table accesslist normal #ACSACL#-IP-ipep-unknown-4fb10ac2: deny tcp any host 192.168.101.1 eq 80 deny tcp any host 192.168.101.1 eq 443 permit ip any host 192.168.101.1 permit udp any any eq 53
Zodra de agent is gedownload en geïnstalleerd:
De agent moet automatisch de ISE detecteren en de postuur beoordeling uitvoeren (ervan uitgaande dat u de postuur regels al gedefinieerd, dat is een ander onderwerp). In dit voorbeeld, is de houding succesvol, en dit verschijnt:
Opmerking: de bovenstaande screenshot bevat twee verificaties. Omdat de iPEP box de ACL’s opslaat, wordt het niet elke keer gedownload.
Op de iPEP:
w-ise-ipep-1/admin# show pep table session Current Sessions (IP, MAC(if available), Profile ID, VLAN (if any)): 192.168.5.2 00:00:00:00:00:00 3 0 w-ise-ipep-1/admin# show pep table accesslist normal #ACSACL#-IP-PERMIT_ALL_TRAFFIC-4f57e406: permit ip any any #ACSACL#-IP-ipep-unknown-4fb10ac2: deny tcp any host 192.168.101.1 eq 80 deny tcp any host 192.168.101.1 eq 443 permit ip any host 192.168.101.1 permit udp any any eq 53 w-ise-ipep-1/admin#
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
19-Dec-2012 |
Eerste vrijgave |