VPN-Inline-Status mit iPEP ISE und ASA

Einleitung

Dieses Dokument enthält Informationen zur Einrichtung des Inline-Status mit einer Adaptive Security Appliance (ASA) und einer Identity Services Engine (ISE).

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Version 8.2(4) für ASA und Version 1.1.0.665 für ISE.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

Die ISE bietet zahlreiche AAA-Services (Status, Profilerstellung, Authentifizierung usw.). Einige Netzwerkgeräte (Network Devices, NAD) unterstützen Radius Change Of Authorization (CoA), mit dem das Autorisierungsprofil eines Endgeräts basierend auf dessen Status oder Profilierungsergebnis dynamisch geändert werden kann. Andere NADs wie die ASA unterstützen diese Funktion noch nicht. Das bedeutet, dass eine ISE im Inline Posture Enforcement Mode (iPEP) erforderlich ist, um die Netzwerkzugriffsrichtlinie eines Endgeräts dynamisch zu ändern.

Das grundlegende Konzept besteht darin, dass der gesamte Benutzerdatenverkehr über das iPEP läuft, wobei der Knoten auch als Radius-Proxy fungiert.

Grundlegender Flow

1. Der VPN-Benutzer meldet sich an.

2. ASA sendet die Anforderung an den iPEP-Knoten (ISE).

3. Der iPEP schreibt die Anforderung neu (indem er Cisco AV-PAIR-Attribute hinzufügt, um anzugeben, dass es sich um eine iPEP-Authentifizierung handelt) und sendet die Anforderung an den ISE Policy Node (PDP).

4. Die PDP antwortet auf den iPEP, der den NAD weiterleitet.

5. Wenn der Benutzer authentifiziert ist, MUSS die NAD eine Accounting-Startanforderung senden (siehe CSCtz84826 ). Dadurch wird der Sitzungsaufbau auf dem iPEP ausgelöst. In diesem Stadium wird der Benutzer auf die Körperhaltung umgeleitet. Außerdem müssen Sie das Interim Accounting-Update für den Tunnel aktivieren, der über das WEBVPN-Portal eingerichtet wurde, da die ISE erwartet, dass das Attribut framed-ip-address in der Radius-Abrechnung vorhanden ist. Bei der Verbindung mit dem Portal ist die VPN-IP-Adresse des Clients jedoch noch nicht bekannt, da der Tunnel nicht eingerichtet ist. So wird sichergestellt, dass die ASA vorläufige Updates sendet, z. B. wann der Tunnel eingerichtet wird.

6. Der Benutzer führt die Statusüberprüfung durch, und basierend auf den Ergebnissen aktualisiert die PDP die Sitzung mithilfe der CoA auf dem iPEP.

Dieser Screenshot veranschaulicht diesen Vorgang:

Beispieltopologie

ASA-Konfiguration

Die ASA-Konfiguration ist ein einfaches 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

!

ISE-Konfiguration

iPEP-Konfiguration

Zuerst muss eine ISE als iPEP-Knoten hinzugefügt werden. Weitere Informationen zum Prozess finden Sie hier:

http://www.cisco.com/en/US/docs/security/ise/1.1/user_guide/ise_ipep_deploy.html#wp1110248

Dies ist im Wesentlichen, was Sie in den verschiedenen Registerkarten konfigurieren müssen (Screenshots in diesem Abschnitt veranschaulichen dies):

• Konfigurieren Sie nicht vertrauenswürdige IP-Adressen und globale IP-Einstellungen (in diesem Fall ist nicht vertrauenswürdige IP 192.168.102.254).

• Die Bereitstellung erfolgt im Routing-Modus.

• Setzen Sie einen statischen Filter ein, damit die ASA die iPEP-Box passieren kann (andernfalls wird die Verbindung zur/von der ISE über die iPEP-Box unterbrochen).

• Konfigurieren Sie die Richtlinien-ISE als Radius-Server und die ASA als Radius-Client.

• Fügen Sie eine Route zum VPN-Subnetz hinzu, die auf die ASA verweist.

• Legen Sie die Überwachungs-ISE als Protokollierungshost fest (standardmäßig Port 20514, in diesem Fall auch die Richtlinie, die von der ISE überwacht wird).

Wichtige Konfigurationsanforderungen für Zertifikate:

Bevor Sie versuchen, einen iPEP-Knoten zu registrieren, stellen Sie sicher, dass die folgenden Anforderungen an die Verwendung des erweiterten Schlüssels für Zertifikate erfüllt sind. Wenn die Zertifikate auf den iPEP- und Admin-Knoten nicht ordnungsgemäß konfiguriert sind, wird der Registrierungsvorgang abgeschlossen. Sie verlieren jedoch den Administratorzugriff auf den iPEP-Knoten. Die folgenden Details wurden aus dem ISE 1.1.x iPEP-Bereitstellungsleitfaden extrapoliert:

Das Vorhandensein bestimmter Attributkombinationen in den lokalen Zertifikaten der Knoten Administration und Inline Posture kann die gegenseitige Authentifizierung verhindern.

Die Attribute sind:

• Extended Key Usage (EKU) - Serverauthentifizierung

• Extended Key Usage (EKU)-Client-Authentifizierung

• NetScape-Zertifikattyp - SSL-Serverauthentifizierung

• Netscape-Zertifikattyp - SSL-Client-Authentifizierung

Für das Verwaltungszertifikat ist eine der folgenden Kombinationen erforderlich:

• Beide EKU-Attribute sollten deaktiviert werden, wenn beide EKU-Attribute im Inline-Posture-Zertifikat deaktiviert sind, oder wenn beide EKU-Attribute aktiviert werden sollen, wenn das Serverattribut im Inline-Posture-Zertifikat aktiviert ist.

• Beide Netscape-Zertifikatstypattribute sollten deaktiviert oder beide sollten aktiviert sein.

Für das Inline-Statuszertifikat ist eine der folgenden Kombinationen erforderlich:

• Beide EKU-Attribute sollten deaktiviert sein, oder beide sollten aktiviert sein, oder nur das Serverattribut sollte aktiviert sein.

• Beide Netscape-Zertifikatstypattribute sollten deaktiviert oder beide sollten aktiviert sein, oder nur das Serverattribut sollte aktiviert sein.

• Wenn selbstsignierte lokale Zertifikate für die Knoten Administration und Inline Posture verwendet werden, müssen Sie das selbstsignierte Zertifikat des Knotens Administration in der Vertrauensliste des Knotens Inline Posture installieren. Wenn Sie in Ihrer Bereitstellung sowohl über einen primären als auch über einen sekundären Administrationsknoten verfügen, müssen Sie das selbstsignierte Zertifikat beider Administrationsknoten in der Vertrauensliste des Inline Posture-Knotens installieren.

• Wenn lokale Zertifikate mit CA-Signatur auf den Administrations- und Inline-Posture-Knoten verwendet werden, sollte die gegenseitige Authentifizierung ordnungsgemäß funktionieren. In diesem Fall wird das Zertifikat der signierenden Zertifizierungsstelle vor der Registrierung auf dem Administrationsknoten installiert, und dieses Zertifikat wird auf den Inline-Status-Knoten repliziert.

• Wenn von der Zertifizierungsstelle ausgegebene Schlüssel zum Sichern der Kommunikation zwischen den Knoten Administration und Inline Posture verwendet werden, müssen Sie vor dem Registrieren des Knotens Inline Posture den öffentlichen Schlüssel (Zertifizierungsstellenzertifikat) aus dem Knoten Administration zur Zertifizierungsstellenzertifikatliste des Knotens Inline Posture hinzufügen.

Basiskonfiguration:

Konfiguration des Bereitstellungsmodus:

Konfiguration der Filter:

Radius-Konfiguration:

Statische Routen:

Protokollieren:

Konfiguration von Authentifizierung und Status

Es gibt drei Statuszustände:

• Unbekannt: Haltung ist noch nicht gemacht

• Konformität: Status ist hergestellt und das System ist konform

• Nicht konform: Status wurde erstellt, aber das System hat mindestens eine Überprüfung nicht bestanden.

Nun müssen die Autorisierungsprofile erstellt werden (dies sind Inline-Autorisierungsprofile: Dadurch wird das Attribut ipep-authz=true im Cisco AV-Pair hinzugefügt), das für den unterschiedlichen Fall verwendet wird.

In der Regel gibt das Profil "Unbekannt" die Umleitungs-URL (Statuserkennung) zurück, die den Datenverkehr des Benutzers an die ISE weiterleitet und den NAC-Agenten installiert. Wenn der NAC Agent bereits installiert ist, kann seine HTTP-Erkennungsanforderung an die ISE weitergeleitet werden.

In diesem Profil wird eine ACL verwendet, die mindestens den HTTP-Datenverkehr zur ISE und zum DNS zulässt.

Die konformen und nicht konformen Profile geben in der Regel eine herunterladbare ACL zurück, um den Netzwerkzugriff auf Basis des Benutzerprofils zu gewähren. Ein nicht konformes Profil kann es Benutzern beispielsweise ermöglichen, auf einen Webserver zuzugreifen, um einen Virenschutz herunterzuladen, oder ihnen einen eingeschränkten Netzwerkzugriff gewähren.

In diesem Beispiel werden das Profil Unbekannt und das Profil Kompatibel erstellt, und das Vorhandensein von notepad.exe als Anforderungen wird überprüft.

Konfiguration von Statusprofilen

Zunächst müssen die herunterladbaren ACLs (dACLs) und Profile erstellt werden:

Hinweis: Dies ist nicht obligatorisch, damit der dACL-Name mit dem Profilnamen übereinstimmt.

• Konformität

  • ACL: ipep-unbekannt

  • Autorisierungsprofil: ipep-unknown

• Nicht konform

  • ACL: ipep-non-compliance

  • Autorisierungsprofil: ipep-non-compliance

Unbekannte dACL:

Unbekanntes Profil:

Kompatible dACL:

Konformitätsprofil:

Konfiguration der Autorisierung

Nachdem das Profil erstellt wurde, müssen Sie die Radius-Anforderung aus dem iPEP anpassen und die richtigen Profile auf sie anwenden. Die iPEP-ISEs werden mit einem speziellen Gerätetyp definiert, der in den Autorisierungsregeln verwendet wird:

NAD:

Autorisierung:

Hinweis: Wenn der Agent nicht auf dem Computer installiert ist, können Sie Client-Bereitstellungsregeln definieren.

Ergebnis

Sie werden aufgefordert, den Agenten zu installieren (in diesem Beispiel ist die Client-Bereitstellung bereits festgelegt):

Gewisse Ausgabe in dieser Phase:

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

Und aus dem 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

Sobald der Agent heruntergeladen und installiert wurde:

Der Support-Mitarbeiter sollte die ISE automatisch erkennen und die Schwachstellenüberprüfung durchführen (vorausgesetzt, Sie haben die Schwachstellenregeln bereits definiert, was ein weiterer Betreff ist). In diesem Beispiel ist der Status erfolgreich, und es wird Folgendes angezeigt:

Hinweis: Im obigen Screenshot befinden sich zwei Authentifizierungen. Da die iPEP-Box jedoch die ACLs zwischenspeichert, wird sie nicht jedes Mal heruntergeladen.

Auf dem 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#

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme

Revisionsverlauf