Test Pulse Policy Secure: Flexible NAC-Lösung für Network Visibility und Zugriffskontrolle

Host Checking

Die Host Checking-Funktion lässt sich nutzen, um sicher zu stellen, dass die Endbenutzersysteme bestimmte, zuvor festgelegte, Voraussetzungen erfüllen, bevor sie Zugriff auf das Unternehmensnetz erhalten. Dabei kann es sich beispielsweise um das Vorhandensein eines Antivirus-Programms mit aktuellen Virendefinitionen, eine aktive Firewall oder auch um einen bestimmten Patch-Level handeln.

Im Betrieb wird der Host Checker während des Logins aktiv und prüft, ob die vorgegebenen Voraussetzungen erfüllt werden. Falls ja, erteilt er den Zugriff auf die Unternehmensressourcen, falls nein, sind die Administratoren dazu in der Lage, eine Remediation Page anzulegen, die Informationen und Links darüber enthält, was der Endanwender machen muss, um sein System regelkonform zu gestalten, beispielsweise durch das Aktivieren der Firewall. Alternativ kann der Host Checker auch selbst versuchen, Compliance zu den Regeln herzustellen. Dazu hält er auf Wunsch Prozesse an, löscht Dateien oder führt Aktionen durch, die zuvor im Rahmen einer Antivirus- oder Firewall-Policy definiert wurden. Dazu später mehr.

Im Test legten wir eine Host-Checking-Regel an, die überprüfte, on der Windows Defender auf unserem Test-Client aktiv und auf dem aktuellen Stand war. Dazu wechselten wir nach „Authentication / Endpoint Security / Host Checker“ und erzeugten eine neue Antivirus-Regel. Dort selektierten wir den Eintrag „Require Specific Products“ und wählten dort den „Windows Defender“. Anschließend gaben wir an, dass das System die Virus Definition Files prüfen sollte und legten fest, wie alt diese Daten sein durften, bevor ein Alarm ausgelöst wurde. Außerdem konnten wir noch angeben, ob das System die Einhaltung der Regel nur während des Logins oder auch während des Betriebs im Auge behalten sollte und welche Remediation-Aktionen der Host Checker im Fall der Nichteinhaltung der Policies durchzuführen hatte. Hier standen uns die Optionen „Download the latest Virus Definition Files“, „Turn on Real Time Protection“ und „Start Antivirus Scan“ zur Verfügung. Wir wählten die beiden ersten aus und speicherten die Regel. Bei Bedarf lassen sich auch mehrere Policies in einer Regel zusammenfassen.

Zum Schluss war es nur noch erforderlich, die neue Regel unter „Users / User Realms / {Name der Benutzerrolle} / Authentication Policy / Host Checker“ zu aktivieren. Danach prüfte der Host Checker unseren Client während des Logins und ließ uns nur mit aktiver und aktueller Antivirus-Software ins Netz.

Das Layer 2-Enforcement

Über das Layer 2-Enforcement lässt sich – wie bereits erwähnt – eine Umgebung konfigurieren, die nur authentifizierten Geräten den Zugriff ins LAN erlaubt. In unserem Netz verwendeten wir neben der Pulse Secure-Appliance beim Einrichten dieses Szenarios einen Cisco Catalyst 2960-C-Switch, der dazu in der Lage war, das 802.1X-Protokoll zu unterstützen.

Wir planten im Test eine Konfiguration, in der sich der Anwender über den Pulse Secure Access Client auf seinem Rechner mit Benutzername und Passwort, Zertifikat oder Token beim System authentifiziert. Zunächst fragt dabei der Cisco-Switch bei der als Radius Server arbeitenden Policy Secure-Appliance nach, ob die Authentifizierung in Ordnung geht. Die Appliance und der Endpoint tauschen dann EAP-Nachrichten durch den Switch aus. Läuft die Authentifizierung erfolgreich ab, so erhält der User Zugriff auf das Netz, indem die Appliance dem Switch, der als Radius Client arbeitet, mitteilt, dass er die vorhandenen Assets nutzen darf.

Im Test verwendeten wir als Authentifizierungsmethode Benutzername und Passwort. Um das beschriebene Szenario umzusetzen, steht im Konfigurationswerkzeug der Pulse Policy Secure-Appliance ein Wizard zur Verfügung, der die Administratoren durch die Konfiguration der Layer-2-Authentifizierung der Benutzersitzungen führt.

Im ersten Schritt zeigt der Wizard einen Willkommensbildschirm an, der die durchzuführenden Schritte beschreibt. Danach geht es gleich in Medias Res und damit an die Definition des Radius Clients. In unserem Test war das, wie gesagt, der Cisco Switch. Um diesen als Radius Client einzurichten, mussten wir ihm zunächst einen Namen geben, seine IP-Adresse definieren und ein Shared Secret festlegen, um die Datenübertragungen zwischen Switch und Appliance abzusichern. Danach gaben wir an, dass es sich bei dem Gerät um eine Cisco-Lösung handelte und aktivierten den Support für Disconnect Messages.

Im nächsten Schritt wählten wir die Location Group, die für die Konfiguration zum Einsatz kommen sollte, damit war der Wizard abgeschlossen und die Konfiguration ging in Betrieb. Jetzt mussten wir nur noch den Cisco-Switch so konfigurieren, dass er mit der PPS-Appliance zusammenarbeitete. Dazu wechselten wir auf die Kommandozeile des Switches und führten dort die dafür erforderlichen Befehle aus. Es würde den Rahmen dieses Tests sprengen, im Detail auf jeden Befehl einzugehen. Das ist auch nicht nötig, da das ganze Vorgehen recht gut in der Dokumentation beschrieben wurde. Im Wesentlichen reicht es an dieser Stelle aus, zu sagen, dass wir eine Radius Server-Gruppe einrichten und die PPS-Appliance als Radius Server definieren mussten. Danach war die Konfiguration abgeschlossen und das System ging in Betrieb. Anschließend verhielt es sich so wie erwartet und oben beschrieben.

Das Layer 3-Enforcement

Die Pulse Policy Secure-Appliance ist wie gesagt nicht nur dazu in der Lage, NAC-Funktionalitäten auf Layer 2 mit Hilfe eines kompatiblen Switches zu konfigurieren, sondern kann auch in Zusammenarbeit mit Firewalls von Checkpoint, Fortinet, Juniper und Palo Alto das Netz auf Layer 3-Ebene absichern. In diesem Fall fungieren die Firewalls genauso wie zuvor der Switch als Enforcement Point.

Auch hier authentifiziert die PPS-Appliance die Anwender, stellt sicher, dass die Endpoints die Sicherheits-Policies erfüllen und leitet dann Benutzer- beziehungsweise Geräteinformationen darüber, welche Ressourcen dem jeweiligen Anwender oder Gerät zur Verfügung stehen sollen, an die Firewall weiter.

Im Test verwendeten wir eine virtuelle Firewall-Appliance von Palo Alto. Die Konfiguration läuft ähnlich ab, wie bei dem Layer 2-Enforcement. Zunächst starteten wir im PPS-Konfigurationswerkzeug den Wizard zum Einrichten des “Intranet Enforcers”. Dieser wollte im Wesentlichen wissen, welche Firewall wir für die Konfiguration verwenden wollten (mit Hersteller und IP-Adresse sowie Zugriffsdaten) und welche Policy für das Mapping der Authentifizierungs-Tables zum Einsatz kommen sollte. Die Policy gibt in diesem Zusammenhang an, welche Firewall für die jeweilige User Role Verwendung findet. Auf diese Weise verhindert das System, dass die PPS auf allen angeschlossenen Firewalls teilweise unnötige Regeln erzeugt. Die genannte Regel konnten wir gleich innerhalb des Wizards definieren.

Sobald das erledigt war, wendeten wir uns der Konfiguration der Firewall selbst zu. Auch hier würde es wieder den Rahmen des Tests sprengen, im Detail darauf einzugehen und auch hier werden die einzelnen Schritte wieder im Detail in der Dokumentation beschrieben. Es genügt an dieser Stelle zu sagen, dass wir in den Zonen der Firewall die User Identification aktivieren mussten, eine dynamische Adress-Gruppe anlegten und eine Sicherheitspolicy hinzufügten, die den Zugriff auf die Ressourcen regelte. Bei der Policy lassen sich unter anderem auch Zeiträume für die Gültigkeit der Regel hinzufügen und ähnliches. Nach dem Abschluss der Konfiguration nahmen wir das System in Betrieb und konnten auf die beschriebene Art und Weise damit arbeiten.

Fazit

Die Pulse Policy Secure-Lösung konnte uns im Test voll überzeugen. Das Produkt verfügt über einen eindrucksvollen Funktionsumfang mit vielen mächtigen Features wie beispielsweise dem Host Checking, dem Enterprise Onboarding und dem Enforcement auf Layer 2 und 3 des OSI-Schichtenmodells. Außerdem arbeitet die Appliance auch mit vielen anderen Produkten aus der IT-Sicherheit zusammen, an dieser Stelle seien nur exemplarisch die MDM-Lösungen von MobileIron, die Switches von Cisco und die Firewalls von Checkpoint sowie Palo Alto genannt.

Im Betrieb verhält sich das Produkt zuverlässig und unauffällig und die Konfiguration dürfte aufgrund der vorhandenen Wizards keinen Administratoren vor unüberwindliche Hindernisse stellen. Eine gewisse Einarbeitungszeit ist zwar erforderlich, danach können die zuständigen IT-Mitarbeiter die Sicherheit ihrer Netze aber deutlich erhöhen, weswegen sich der Aufwand in den meisten mittleren und großen Unternehmensumgebungen lohnen dürfte. Wegen des großen Funktionsumfangs verleihen wir dem Pulse Policy Secure-Produkt das Prädikat “IAITested and recommended”.

Der gesamte Test steht auch als PDF-Datei zur Verfügung:

Anmerkung:

Wir haben diesen Test im Auftrag des Herstellers durchgeführt. Der Bericht wurde davon nicht beeinflusst und bleibt neutral und unabhängig, ohne Vorgaben Dritter. Diese Offenlegung dient der Transparenz.