Fehlerseite bei zufälligen MAC-Adressen mit ClearPass anzeigen

In einem vorherigen Beitrag haben wir die Auswirkung zufälliger MAC-Adressen im Netz (MAC-Address Randomization) beschrieben. In diesem Artikel zeigen wir, wie Nutzern bei zufälligen MAC-Adressen mit ClearPass eine Fehlerseite angezeigt werden kann. Dabei werden ein Aruba-WLAN mit Controller und Aruba ClearPass eingesetzt. Bitte beachten Sie, dass zufällige MAC-Adressen durchaus sinnvoll sind und in vielen Fällen nicht verboten werden müssen. Ein Beispiel, bei dem es nötig ist, zufällige MAC-Adressen zu verbieten, sind Abfragen von ClearPass bei MDM-Systemen.

Erkennen von zufälligen MAC-Adressen

Auch wenn das zunächst verwunderlich klingt, folgen zufällige MAC-Adressen einem gewissen Schema. Sie haben an der zweiten Stelle die Ziffer 2 oder 6, oder den Buchstaben A oder E. Damit ist es möglich, eine zufällige MAC-Adresse eindeutig zu erkennen. Auf dieser Grundlage können wir das ClearPass Role Mapping nutzen, um einen Benutzer mit zufälliger MAC Adresse zu kennzeichnen. Die folgende Abbildung zeigt den ClearPass Regeleditor und eine Regel, die hierzu einen regulären Ausdruck einsetzt.

Alle Geräte, die sich jetzt mit einer zufälligen MAC-Adresse anmelden, bekommen die Rolle ING_Random_MAC zugewiesen. Das ist die erste Voraussetzung dafür, dass wir eine Fehlerseite anzeigen können.

Fehlerseite im ClearPass konfigurieren

Als Nächstes müssen Sie eine Fehlerseite im ClearPass anlegen. Dazu kann im Gast-Modul von ClearPass eine bereits existierende Seite kopiert und angepasst werden.

Hier ist ein Beispiel wie die Fehlerseite aussehen kann:

Passende Rolle im Controller anlegen

Damit Benutzer auf die Fehlerseite umgeleitet werden, müssen Sie im Controller eine neue Rolle anlegen. Als Policies müssen hier logon-control und captiveportal hinzugefügt werden.

Unter Captive Portal müssen die URL des ClearPass Servers und die entsprechende Fehlerseite angegeben werden. Auch ein Authentifizierung-Server muss angegeben werden. Da hier keine Anmeldung stattfindet, kann der interne Server angegeben werden.

Ein Benutzer, der die Rolle ing-random-mac zugewiesen bekommt, darf per DHCP eine IP-Adresse bekommen, DNS Anfragen stellen und wird beim Aufruf einer http Seite auf die entsprechende Fehlerseite umgeleitet.

ClearPass Enforcement Profile und Enforcement Policies anlegen

Damit Clearpass einem User die Rolle ing-random-mac zuweist, müssen Sie zunächst ein Enforcement Profile dafür anlegen:

Diese Rolle kann dann in einer Policy zugewiesen werden:

Damit können Sie einem User mit ClearPass eine Fehlerseite anzeigen, falls diese versuchen, sich mit zufälligen MAC-Adressen im WLAN anzumelden.

Mac Address Randomization

Zufällige MAC-Adressen (aka MAC-Address Randomization)

Um den Datenschutz bei Mobilgeräten zu erhöhen, haben die großen Software Hersteller Apple, Google und Microsoft in ihren neuen Software Releases ein neues Feature eingeführt: Zufällige MAC-Adressen (engl. MAC-Address Randomization). Wozu dieses Feature da ist und was das für ein Unternehmens-WLAN bedeutet, zeigt dieser Artikel.

Wozu dienen zufällige MAC-Adressen?

Um zu verstehen, warum MAC-Address Randomization ein nützliches Feature ist, ist es wichtig zu wissen, was eine MAC-Adresse eigentlich ist. So wie eine IP-Adresse auf Layer 3 ermöglicht die MAC-Adresse eine eindeutige Identifizierung in einem Layer 2 Netz. MAC steht dabei für Media Access Control. Diese nutzt man also dafür, den Zugriff auf das physikalische Medium zu koordinieren. Mit einer MAC-Adresse können wir ein Gerät identifizieren und Frames (Dateneinheiten auf L2) an das Gerät senden. Umgekehrt sendet das Gerät bei allen Frames seine MAC-Adresse mit, damit der Empfänger weiß, wem er antworten soll.

Eine MAC-Adresse ist also ein essenzieller Teil der Kommunikation auf Layer 2. Ein Client sendet sie immer mit und selbst wenn im WLAN WPA2/3 mit Verschlüsselung eingesetzt wird, ist die MAC-Adresse selbst immer unverschlüsselt. Denn nur so kann ein Empfänger ermitteln, ob ein Paket für ihn bestimmt ist und macht sich die Arbeit, es zu entschlüsseln.

Wenn die MAC-Adresse so wichtig ist, warum sollte man dann eine zufällige Adresse nehmen und was hat das mit Datenschutz zu tun? Wie im vorigen Absatz erwähnt, wird die MAC-Adresse im Frame immer unverschlüsselt gesendet. Das ist gerade im WLAN ein Problem, weil jeder mithören kann. Es ist also möglich festzustellen, wer mit einem WLAN verbunden ist und damit auch, wer sich in der Nähe aufhält.

Und es wird noch problematischer. Um festzustellen, welche WLANs in der Reichweite eines Gerätes sind, sendet jeder WLAN-Client sogenannte Probe-Requests. Damit fordert der Client alle Access Points in der Nähe auf, ihm Informationen über die SSIDs die sie ausstrahlen, zu senden. In diesen Probe-Requests steht ebenfalls die MAC-Adresse des Clients als Absender. Damit ist es möglich, die Position eines WLAN Clients zu verfolgen, ohne dass er mit einem WLAN verbunden ist.

Diese Techniken werden in kommerziellen Lösungen zur Verfolgung von Endgeräten tatsächlich eingesetzt. Ein möglicher Anwendungsfall ist die Analyse von Besuchern von Shoppingcentern. Dabei werden Besucherströme analysiert oder wiederkehrende Besucher identifiziert.

Um diese Analysen zu erschweren, können Sie zufällige MAC Adressen verwenden.

Wie funktionieren zufällige MAC-Adressen?

Da die MAC-Adresse ein so wichtiges Merkmal in der Kommunikation ist, muss es eine gewisse Regelmäßigkeit geben. Sucht Ihr Endgerät nach vorhandenen WLANs mit einem Probe-Request, verwendet es bei den Betriebssystemen Android ab Version 6 und Apple iOS 9 immer eine neue zufällige MAC-Adresse. Das bedeutet, dass eine Lokalisierung erschwert wird, da die MAC-Adresse häufig wechselt.

Wenn man sich jedoch mit einem WLAN verbindet, wurde bisher immer die physikalische MAC Adresse verwendet. Es war also immer noch möglich, ein Gerät zu verfolgen, wenn es sich mit verschiedenen WLANs verbindet. Das hat sich mit iOS 14 und Android 10 geändert. Hier generiert der Client für jede WLAN-SSID mit der er sich verbindet, eine neue zufällige MAC-Adresse. Die MAC-Adresse ist also unterschiedlich für jedes WLAN und ein Gerät kann so nicht über verschiedene WLANs verfolgt werden.

Dabei folgen die zufälligen MAC-Adressen einem gewissen Schema. Wenn wir uns die MAC-Adresse 92:B1:C8:52:D3:84 ansehen, kann man feststellen, dass dies eine zufällige MAC-Adresse ist. Die generierten MAC-Adressen haben an der zweiten Stelle immer die Zahl 2 oder 6, oder den Buchstaben A oder E. Der Rest der MAC Adresse ist dann tatsächlich zufällig.

Verbindet sich ein Client mit einem WLAN, generiert er eine neue zufällige MAC-Adresse. Diese MAC-Adresse bleibt dann für alle zukünftigen Verbindungen mit diesem WLAN bestehen. Das kann man umgehen, indem man das WLAN “vergisst” und sich neu verbindet. Dann generiert er eine neue MAC-Adresse.

In Android 11 und Windows 10 ist es außerdem möglich, dass das System die MAC-Adresse alle 24 Stunden neu generiert. Diese Option ist normalerweise deaktiviert.

Was bedeutet das für ein Unternehmens-WLAN?

Eine gute Nachricht vorweg: Für ein 802.1X gesichertes WLAN ist die MAC-Address Randomization nicht relevant. Hier prüft der Accesspoint keine MAC-Adresse, sondern diese dient nur der Kommunikation von Client und AP.

Verwenden Sie die MAC-Adresse zur Authentifizierung, zum Beispiel in einem WPA2/3-PSK WLAN kann etwas Arbeit auf den Administrator zukommen. Zwar soll zum Beispiel iOS nach dem Update auf iOS 14 alle bis dahin bekannten Netzwerke mit der physikalischen MAC-Adresse ansprechen, jedoch verändert sich diese, sobald der Benutzer das Netzwerk löscht und neu anlegt. Sobald das geschehen ist, muss der Administrator die Liste der erlaubten MAC-Adressen anpassen. Hier ist es besser, auf eine Anmeldung mit 802.1X zu setzen, sofern die Geräte das unterstützen.

Probleme kann es geben, wenn bei der Anmeldung weitere externe Dienste angefragt werden. Ein typisches Beispiel ist ein ClearPass Server der bei der Anmeldung von mobilen Endgeräten ein MDM-System anfragt. Denn die Zuordnung von Anmeldeversuch und Gerät im MDM geschieht meist über die MAC-Adresse. In diesem Fall wäre für alle Endgeräte eine Anmeldung nicht möglich, da eine Abfrage vom MDM keine Ergebnisse liefern kann. In diesem Artikel ist eine Anleitung zu finden, wie man Benutzern mit einer zufälligen MAC Adresse eine Fehlerseite anzeigt.

Aruba Controller Benutzername aus DHCP Option 12

Wenn Sie ein WPA2/WPA3- Enterprise gesichertes WLAN mit Aruba verwenden, sind sie es gewohnt in der Client Ansicht die Benutzernamen der Geräte zu sehen. Wenn Sie allerdings ein WLAN mit Pre-Shared Key verwenden, so zeigt Ihnen Aruba die IP-Adresse als Benutzernamen an. Das liegt daran, dass hier kein Benutzername zur Authentifizierung genutzt wird. Wenn Sie sich vom Aruba Controller lieber den Hostnamen des Client Gerätes DHCP Option 12 als Benutzernamen anzeigen lassen wollen, zeigen wir Ihnen in diesem Blogbeitrag, wie das geht.

Aruba Controller DHCP Option 12

Für den Admin ist es jedoch hilfreich, hier mehr Informationen gezeigt zu bekommen. Tatsächlich gibt es eine Möglichkeit, sich den Hostnamen des Gerätes anzeigen zu lassen. Voraussetzung ist allerdings, dass DHCP genutzt wird. Denn ein Client kann in einer DHCP Option seinen Hostnamen an den DHCP Server senden. Der Aruba Controller kann in die DHCP Pakete schauen und die Information aus der DHCP Option 12 nutzen, um sie in der Client Ansicht zu zeigen.

DHCP Option 12

Das muss allerdings manuell eingeschaltet werden, denn die Option ist standardmäßig deaktiviert. Das ganze passiert im AAA Profil der SSID. Dort muss die Option Set username from dhcp option 12: eingeschaltet werden, damit Sie den Hostnamen aus DHCP Option 12 als Buntzernamen vom Aruba Controller anzeigen lassen.

AAA Profile des Aruba Controllers

Jetzt wird bei jedem Client der Hostname angezeigt, sobald er eine DHCP Anfrage gestellt hat. Voraussetzung ist hier, dass der Hostname mit gesendet wird, was allerdings bei fast allen Geräten der Fall ist.

Wireless Clients auf einem Aruba Controller

 

Aruba 2930M PoE Switch

ArubaOS: Optimierung der PoE-Leistung mit Hilfe von LLDP

Device-Profile

Wer LLDP-fähige Access Points an einem Aruba switch betreibt, weiß wie sehr die LLDP-Informationen im Arbeitsalltag weiterhelfen können. So liefern sie beispielsweise die Information über Hostnamen, Mac Adresse,IP-Adresse und PoE-Leistung des LLDP-Gerätes pro Switchport. Neben der reinen Informationsübermittlung sind ArubaOS Switches auch in der Lage auf Basis der LLDP-Informationen Portkonfigurationen eigenständig auszuführen. Dazu muss lediglich ein so genanntes „Device Profile“ erstellt werden, unter welchem Sie beispielsweise VLAN-Zuweisungen konfigurieren können. Wird dann ein Access Point an einen Switchport angeschlossen, so erhält der Port automatisch diese VLAN-Konfiguration, solange der Access Point an dem Port angeschlossen bleibt.

Device Profile ArubaOS LLDP PoE-Leistung

Konfiguration einens Device Profiles

PoE – benötigte Leistung

Neben den Netzwerkinformationen liefert LLDP für PoE- und PoE+-Geräte auch Informationen zu der benötigten elektrischen Leistung und der PoE-Klasse. Dabei wird zwischen dem aktuellen Verbrauch und der maximal benötigten Leistung unterschieden. Letztere ist ausschlaggebend für die Berechnung der gesamten benötigten elektrischen Leistung und somit auch für die maximale Anzahl an Access Points, welche am Switch angeschlossen werden können. Dabei kann sich die maximale Leistung von dem eigentlichen Verbrauch drastische unterscheiden. Sind bei einem Access Point gewissen Features, wie zum Beispiel Bluetooth, ausgeschaltet, weil diese nicht benötigt werden, kann der eigentliche Verbrauch auch nur halb so groß sein wie der maximale Verbrauch. Das Resultat wäre die doppelte Anzahl an möglichen Access Points, die mit einem Switch betrieben werden können.

Ein von Aruba häufig verwendeter Access Switch ist der Aruba 2530 J9853A. Dieser stellt auf 48 Ports insgesamt eine PoE-Leistung von 382W zur Verfügung. Damit können bei einem durchschnittlichen Verbrauch von 13W (Durschnitt von einem Aruba AP 515 Access Point mit deaktiviertem Bluetooth und Zigbee) 29 Access Points betrieben werden. Allerdings liefert die LLDP-Information der Access Points eine Maximale Leistung von 25W. Damit sinkt die Anzahl der maximalen Access Points, welche mit demselben Switch betrieben werden können, auf gerade mal 15.

Workaround für ältere Firmwareversionen

Unter den letzten Firmwareversionen von ArubaOS, konnte die Berechnung der gesamten Leistung für PoE+-Geräte, auf Basis des maximalen Verbrauchs nur verändert werden, wenn LLDP deaktiviert worden ist. Danach konnte die gesamte Leistung aus dem tatsächlichen Verbrauch errechnet werden und somit die maximale Anzahl der möglichen Access Points erhöht werden. Diese Prozedur barg leider den Nachteil, dass man auf die sonst so hilfreichen LLDP-Informationen verzichten musste.

Admin Status ArubaOS LLDP PoE-Leistung

Befehl LLDP admin-status

poe-allocated-by ArubaOS LLDP PoE-Leistung

Befehl poe-allocated-by

ArubaOS Firmware Version 16.10.001

Seit dem letzten Firmwareupdate von Aruba auf die Version 16.10.0000, kann der Verbrauch nun auch trotz LLDP-Informationen aus dem tatsächlichen Verbrauch berechnet werden. Dies geschieht, genau so wie bisher für PoE-Geräte, mit dem „poe-allocate-by usage“ Befehl. Dieser kann nun auch innerhalb eines Geräteprofils gesetzt werden, sodass er nicht händisch auf alle Interfaces konfiguriert werden muss.

Die Release-Notes zu ArubaOS Version 16.10.0001 finden Sie unter: https://support.hpe.com/hpesc/public/docDisplay?docId=a00090303en_us

Schulungen zum Thema ArubaOS finden Sie unter: https://www.ingentive.net/schulungen/alle-schulungen/aruba-switches

Continuous Monitoring mit Aruba UXI Sensoren

Continuous Monitoring

UXI Sensor

Aruba UXI Sensor

Nahezu jedes Unternehmen nutzt heutzutage Computerarbeitsplätze und kommt dabei nicht mehr um eine belastbare und zuverlässige Netzwerkanbindung der Computer und Endgeräte herum. Im Arbeitsalltag kommen dabei eine Vielzahl an Applikationen und Diensten zum Einsatz für deren Nutzung die Firmennetzwerke in der Regel dimensioniert sind. Die Verfügbarkeit der Verbindung zu einzelnen Anwendungen wird in dem Kontext zunehmend unternehmenskritischer. Dadurch erhält diese Verfügbarkeit einen immer größer werdenden Stellenwert. Im März 2018 kaufte Aruba die Firma und das Knowhow von Cape Networks auf. Cape Networks ist ein Startup-Unternehmen, welches Sensoren zum Überwachen von kabellosen und kabelgebunden Netzwerken produziert. Aruba vermarktet diese seitdem als Aruba UXI Sensoren.

 

Aruba UXI Sensoren

Mit den Aruba User Experience Insight Sensoren können sowohl kabelgebundene als auch kabellose Netzwerke fortlaufend überwacht und auf eventuelle Engpässe und Fehlfunktionen kontrolliert werden. Der Fokus liegt bei den Sensoren nicht nur auf dem Netzwerk, sondern auch konkret auf einzelnen Anwendungen aus Sicht des Clients. Durch die Kombination aus infrastruktureller Perspektive und Nutzerperspektive differenzieren sich die Aruba UXI Sensoren von klassischen Netzwerkmonitoring-Anwendungen. Die Sensoren testen im Einsatz alle Aspekte der Verbindung zu Anwendungen und Diensten sowohl ins eigene Datacenter als auch in die Cloud.

Aruba User Experience Insight Sensoren werden an einem beliebigen Userport ins kabelgebundene Netzwerk oder in der Nähe der Computerarbeitsplätze ins drahtlose Netzwerk eingebunden. Sie benötigen keine komplizierte Konfiguration. Alle gesammelten Daten werden über die Cloud in einem intuitiven Dashboard zur Auswertung und Inspektion zur Verfügung gestellt.

Dashbaord

Dashbaord eines Aruba UXI Sensors

Über die Dashboard-Webseite können sowohl die zu untersuchenden Applikationen und Dienste als auch die durchzuführenden Tests konfiguriert werden. Für eine Großzahl an populären Applikationen stehen dafür bereits Templates mit Adressen sowie Testmethoden zur Verfügung. Sie können aber auch beliebige Anwendungen als Test konfigurieren.

Test

App-Test eines Aruba UXI Sensors

Für die Benachrichtigung im Fehlerfall können Sie die Dienste E-Mail, ServiceNow und Slack sowie beliebige Webhooks verwenden. Somit lassen sich die Sensoren in bestehende Monitoring-Umgebungen problemlos integrieren. Neben der Benachrichtigung im Fehlerfall können die UXI Sensoren ebenso wöchentliche Reports erstellen. Mit der Hilfe dieser Reports ist es möglich Netzwerkbelastung und Applikationsverfügbarkeit sowie weitere Parameter zu beobachten.

Report

Wöchentlicher Netzwerkreport eines Aruba UXI Sensors.

Die von Aruba angebotenen UXI Sensoren sind ein praktisches Tool zum Überwachen von Netzwerken in unternehmenskritischen Bereichen. Sie sind leicht zu konfigurieren, benötigen wenig Pflege und liefern aufschlussreiche Statistiken über Netzwerke aus Nutzersicht.

Mehr Informationen zu Aruba UXI Sensoren finden Sie unter: https://www.arubanetworks.com/products/networking/analytics-and-assurance/user-experience-insight-sensors/

Schulungen zum Thema Aruba WLAN finden Sie unter: https://www.ingentive.net/schulungen/alle-schulungen/aruba-wlan/

ClearPass Captive Portal Login

Sie kennen das aus eigener Erfahrung: Man ist auf Geschäftsreise im Hotel oder beim Kunden und erwartet schon fast automatisch ein Gäste-WLAN. Damit jedoch der Zugang nicht ganz unkontrolliert ist, verwenden viele Unternehmen eine Gästeverwaltung mit einem Login über ein Captive Portal. Das bedeutet, man kann sich als Gast zwar mit einer offenen SSID verbinden, bevor man jedoch ins Internet kommt, muss man sich auf eine Webseite anmelden. Meist bekommt man die Anmeldedaten vom Gastgeber, manchmal kann man sich aber auch mit einer E-Mailadresse oder einer Handynummer selbst registrieren.Eine mögliche Gästeverwaltung ist Aruba ClearPass mit einem Captive Portal.

Es stellt verschiedene Möglichkeiten zur Selbstregistrierung, Registrierung durch einen Administrator, verschiedene Captive Portals und auch Anbindung an Bezahldienste wie PayPal bereit. Doch was genau passiert eigentlich bei einem Captive Portal? Wo genau meldet sich der Gast eigentlich an und warum merkt ein Smartphone, dass ein Captive Portal vorhanden ist, ein Laptop aber nicht? Um diese Fragen zu klären soll hier der Ablauf einer Captive Portal Anmeldung detailliert beschrieben werden. Dabei wird angenommen, dass es sich um einen ClearPass Server und einen Aruba WLAN Controller handelt.

Ablauf eines Logins

Zuerst verbindet sich ein Gast mit der offenen Gast-SSID und bekommt per DHCP eine IP-Adresse zugewiesen. Da er noch nicht angemeldet ist, hat er im WLAN Controller eine spezielle Login-Rolle. Diese Rolle enthält unter anderem die Information, dass der DHCP-Traffic erlaubt ist, dass DNS-Traffic erlaubt ist und dass alle http Request mit einem Redirect beantwortet werden.

Captive Portal Login

Wenn ein nicht angemeldeter Client versucht eine Webseite aufzurufen (Schritt 1), antwortet der Controller mit einem http 302 Redirect (Schritt 2). In diesem Redirect steht die URL des Captive Portal auf dem ClearPass Server. Der Client wird also dorthin umgeleitet (Schritt 3). Die Seite enthält eine Anmeldemaske oder eine Möglichkeit der Selbstregistrierung. Wenn der Gast seine Anmeldedaten eingegeben hat (Schritt 4), prüft der ClearPass Server ob die Angaben korrekt sind (Schritt 5). Das Captive Portal muss daher unbedingt über https angesprochen werden. Doch auch wenn die Daten korrekt sind, ist der Gast noch nicht angemeldet, denn der WLAN Controller weiß noch nichts von einer Anmeldung.

Wenn die Anmeldedaten korrekt sind erfolgt daher noch eine Weiterleitung auf den WLAN Controller (Schritt 6). In der URL dieser Weiterleitung stehen neben anderen Informationen auch der Benutzername und das Passwort des Gastes. Daher muss auch der Controller mit https angesprochen werden. Mit den Anmeldedaten aus der URL wird vom Controller eine RADIUS Anmeldung an ClearPass vorgenommen (Schritt 8). Bei korrekten Daten sendet ClearPass ein RADIUS Accept an den Controller, zusammen mit Informationen wie der Rolle des Gastes (Schritt 9). Erst dann ist der Gast wirklich am WLAN angemeldet. Danach erfolgt ein Redirect auf die Ursprünglich aufgerufene Seite (Schritt 10). Es besteht auch die Möglichkeit den Gast auf eine andere Seite, wie zum Beispiel die Firmen Homepage, umzuleiten.

Erkennung eines Captive Portals

Damit ist geklärt, was genau bei einer Captive Portal Anmeldung passiert und wer die eigentliche Anmeldung des Gastes übernimmt. Aber warum merkt ein Smartphone, dass ein Captive Portal vorhanden ist, ein Computer aber nicht?

Sobald sich ein Smartphone mit einem WLAN verbindet, wird im Hintergrund versucht eine bestimme Webseite aufzurufen. Bei Android Geräten ist das (ab Android 6) http://connectivitycheck.gstatic.com/generate_204 und bei iOS Geräten http://captive.apple.com/hotspot-detect.html. Liefern diese Webseiten nicht den erwarteten wert, vermutet das Smartphone, dass ein Captive Portal vorhanden ist. Ein Browser, der das Captive Portal anzeigt, öffnet sich automatisch.

Auch Windows-Computer prüfen Regelmäßig eine Ressource im Internet um festzustellen, ob eine Internet Verbindung vorhanden ist. Falls diese Überprüfung fehlschlägt, erkennt man das an einem gelben Ausrufezeichen in der Taskleiste, bzw. an dem Zusatz „Kein Internet“ in den Netzwerkdetails. Allerdings wird hier nicht automatisch ein Browser geöffnet, weshalb man auf einem Computer händisch eine Webseite aufrufen muss um zum Captive Portal zu gelangen.

Wie Sie sehen, ist ein Captive Portal eine gute Möglichkeit, Gästen ein WLAN bereit zu stellen, ohne dabei die Kontrolle darüber zu verlieren, wer sich im Netzwerk befindet.

 

Role Based Access Control mit Aruba WLAN

Role Based Access Control (RBAC) ist tief in Aruba WLAN integriert. Es ist nicht möglich, ein Aruba WLAN ohne RBAC zu nutzen. Jede SSID hat eine default Rolle, die ein Benutzer zugewiesen bekommt, sobald er sich verbindet.

Rollen im Aruba WLAN

Eine Rolle im Aruba WLAN kann mehrere Eigenschaften enthalten. Dazu gehören:

  • Firewall Regeln
  • VLAN Zuweisung
  • Bandbreitenbeschränkungen
  • Einstellungen zu Captive Portals

Durch die in einem Aruba WLAN Controller integrierte Firewall können hiermit unterschiedliche Beschränkungen für Benutzer im gleichen WLAN durchgesetzt werden. Das ist möglich, da die Firewall in den Traffic eingreift, bevor er die WLAN Infrastruktur verlässt. Die Filterung findet damit direkt am Netzzugangspunkt statt.

Konfiguration von Access Control Rollen im Aruba Controller

Rollen werden auf dem Aruba Controller unter Configuration -> Roles & Policies -> Roles angelegt.

Controller Einstellungen Role Based Access Control mit Aruba WLAN

Mit einem Klick auf das blaue “Plus” können Sie  eine neue Rolle hinzugefügen. Dabei sollten Sie einen “sprechenden” Name wählen:

Rolleneinstellungen Role Based Access Control mit Aruba WLAN

Danach kann Sie die neuangelegte Rolle aus der Liste der Rollen ausgewählen, um sich weitere Details anzeigen zu lassen. Dabei ist es wichtig, den sogenannten Advanced View zu nutzen.

Rolleneinstellungen Role Based Access Control mit Aruba WLAN

Nur so werden alle Details zu den Rollen angezeigt.

Rolleneinstellungen

Hier können Sie zum Beispiel Firewall Regeln oder Bandbreitenlimitierungen konfigurieren. Damit können Sie Zugangsbeschränkungen für die WLAN Benutzer granular definieren. Eine Unterscheidung von Usern im selben VLAN ist ebenfalls möglich.

Zuweisen von Rollen

Rollen können auf verschiedene Weise zugewiesen werden. Zunächst besteht die Möglichkeit, die Rollen von einem RADIUS Server mittels eines RADIUS Attributes zuzuweisen. Das ist insbesondere in Verbindung mit Aruba ClearPass verbreitet.

Eine weitere Möglichkeit ist die Verwendung von Server Rules. Diese werden häufig in Verbindung mit LDAP Servern genutzt und können anhand verschiedener Rückgabewerte des LDAP Servers Rollen zuweisen. So können Sie zum Beispiel das Attribut memberOf nutzen um Rollen zuzuweisen.

Server Regeleinstellungen Role Based Access Control mit Aruba WLAN

 

Aruba Instant WLAN Access Point

Aruba Instant WLAN in 5 Minuten

In diesem Beitrag möchten wir zeigen welche Schritte für das Aussenden einer neuen SSID mit Hilfe von Aruba Instant WLAN Access Points nötig sind. Wir arbeiten mit einem aktuellen Modell AP-515. Bei diesem Access-Point handelt es sich um einen sog. „Unified“ Access-Point, der Instant, Standalone oder auch einen Controllerbasierten Betrieb erlaubt.

Die verwendete Hardware finden Sie bei uns im Shop: Aruba AP-515

Wie der Name bei Aruba Instant WLAN schon sagt, bietet die controllerlose Variante „Instant“ die Möglichkeit sehr schnell ein WLAN bereitzustellen.

Die gezeigten Schritte sind aber nur die absolute Minimalkonfiguration und beinhalten keine Implementierung von Sicherheitsfunktionen, RF-Optimierung oder sonstigen Einstellungen, die normalerweise in einer Produktivumgebung durchgeführt werden müssen.

Die gezeigten Konfigurationsschritte sind mit einem AP-515 mit ArubaOS 8.4.0.0 entstanden.

Konfiguration eines Aruba Instant Access Point

Allgemeine Einstellungen

Wenn der Access-Point im Werkszustand wird eine der MAC-Adresse abgeleitete SSID ausgestrahlt mit der man sich verbinden kann.

Sichtbarkeit der Default-SSID

Alternativ kann man auch über die LAN-Seite des Access-Points zugreifen. Die LAN IP Adresse wird per DHCP bezogen und kann am Switchport über das LLDP Protokoll ausgelesen werden. Bei uns hat der AP die IP 192.168.1.100 bekommen:

Wir nehmen also einen Browser unserer Wahl und öffnen folgende URL:
https://192.168.1.100:4343

Es öffnet sich ein Anmeldefenster, an dem wir uns mit admin/admin einloggen können. Ab Version 8.5 muss als Passwort die Seriennummer des APs eingegeben werden:

Login Seite des virtuellen Controllers

Als erste Einstellung muss der Ländercode eingetragen werden:

Auswahl der Spracheinstellungen

Anschließend findet man sich im 8.x Webinterface wieder, welches in die Bereiche Dashboard, Konfiguration, Wartung und Support gegliedert ist. Im Dashboard findet man zudem eine Übersicht über die ausgesendeten Netzwerke, Access-Points und Clients:

Dashboard des virtuellen Controllers

Unter dem Konfigurationsmenüeintrag “System” kann man einige generelle Einstellungen vornehmen. Wir vergeben anschließend einen Namen, den Standort und eine virtuelle IP Adresse im gleichen Subnetz unter der der virtuelle Controller erreichbar sein soll.

Systemeinstellungen des virtuellen Controllers

Um die Aruba Instant WLAN Access Points identifizieren zu können vergeben wir noch einen Namen:

Access Point Einstellungen des Client Dashboards des Aruba Instant WLAN Access Points

Zur Verbesserung des Roaming-Verhaltens ist es immer ratsam das Bandsteering und das Client-Match-Feature zu aktivieren. Client-Match verhindert das Sticky-Client Problem – also das Thema, dass ein sich bewegender Client zu lange an einem Acccess-Point verharrt und dadurch Verbindungsprobleme entstehen. Client-Match adressiert dieses Problem und verhilft einem trägen Client zu einem schnellerem Roaming.

RF Einstellungen des Aruba Instant WLAN Access Points

Erstellen einer SSID

Die eigentliche Konfiguration eines neuen Netzwerks gliedert sich in 4 Schritte:

Erstellen einer neuen SSID auf Aruba Instant WLAN Access Points

Der Name ist gleichzeitig die SSID, die der Aruba Instant WLAN Access Point aussenden soll. Mögliche Verwendungszwecke sind Mitarbeiter, Gast oder Sprache, die einen Einfluss auf die Parametrisierung in den weiteren Schritten haben. Für den Zugriff von mobilen Geräten (Notebooks, Handy, Tablets) verwenden wir „Mitarbeiter“:

Allgemeine SSID Einstellungen auf Client Dashboard des Aruba Instant WLAN Access Points

Zur logischen Trennung der restlichen Umgebung lässt sich der Datenstrom am Access-Point in ein VLAN auskoppeln. In unserem Fall ist das VLAN 10. Wichtig hier das mit dieser Konfiguration das VLAN auf dem Switch angelegt werden muss und jeder Aruba Instant WLAN Access Point mit diesem VLAN versorgt werden muss (Tagging):

VLAN Einstellungen der neuen SSID auf Client Dashboard des Aruba Instant WLAN Access Points

Ein wichtiger Punkt sind die Absicherungsmöglichkeiten. Hier besteht die Möglichkeit zwischen “Enterprise”, “Persönlich” und “offen” zu wählen. Die maximale Sicherheit bietet die Stufe Enterprise, da hier eine Authentfizierung mit 802.1X und Zertifikaten möglich ist. Dazu sind aber weitere Infrastrukturkomponenten (z.B. Clearpass als RADIUS Server) nötig, die wir hier nicht vertiefen wollen. Daher wählen wir die Sicherheitsstufe “Persönlich”, wo nur ein Pre-Shared-Key eingegeben werden muss. Wir wählen noch weitere Optimierungsparameter bezüglich Roaming:

Sicherheitseinstellungen der neuen SSID

Im letzten Schritt können die Zugriffe festgelegt werden. Denkbar sind ein rollenbasierte Zugriff über einen ClearPass RADIUS Server oder netzwerkbasiert über Zugriffsregeln. Wir verwenden die Einstellung für Vollzugriff:

Zugriffsbeschränkungen der neuen SSID auf dem Client Dashboard des Aruba Instant WLAN Access Point

Mit dem Klick auf „Finish“ rollen Sie die Konfiguration auf dem virtuellen Controller aus und nach wenigen Sekunden steht das neue WLAN Netzwerk zur Verfügung:

Sichtbarkeit der neuen SSID

Im Dashboard kann man dann verschiedenste Informationen über die Clients abrufen. In unserem Fall handelt es sich um einen handelsübliches Notebook, welches sich mit einer Datenrate von 866 Mbit verbinden kann:

Client Dashboard des Aruba Instant WLAN Access Point

Fertig: ich habe es in 4 Minuten 30 geschafft und hoffe Sie können das noch unterbieten 😉
Die passenden Produkte finden Sie bei uns im Shop.

Nutzungsbedinungen

Die Nutzung, Vervielfältigung und Verbreitung dieser Publikation und von verbundenen Grafiken wird hiermit unter der Bedingung gestattet, dass der Urheberrechtshinweis auf allen Kopien erscheint und dass sowohl der Urheberrechtshinweis als auch dieser Zustimmungshinweis erscheinen. Alle sonstigen Rechte bleiben vorbehalten. Der Name der Ingentive Networks GmbH darf im Zusammenhang mit der Verbreitung dieser Publikation durch Werbung oder sonstige Veröffentlichung, nur mit ausdrücklicher vorheriger schriftlicher Zustimmung verwendet werden. Ingentive Networks GmbH übernimmt keine Gewähr für die Verwendbarkeit dieser Information zu irgendwelchen Zwecken.

Diese Publikation wird so wie hier bestehend zugänglich gemacht, ohne jegliche Gewähr oder sonstige Verpflichtung. Jegliche Gewährleistung im Zusammenhang mit dieser Information und deren Verwendung, ausdrücklich oder stillschweigend, gesetzlich oder aus sonstigem Rechtsgrund (einschließlich der Gewährleistung für bestimmte Eigenschaften oder der Verwendbarkeit für einen bestimmten Zweck) ist ausgeschlossen. Ingentive Networks GmbH haftet nicht für Bearbeitungsfehler oder Nutzungsausfall, entgangenen Gewinn oder erwartete ersparte Aufwendungen, Verlust des Firmenwerts (goodwill) oder Verlust von Daten oder Verträgen sowie für jegliche Art von indirekten Vermögens- oder Folgeschäden (einschließlich Schäden aufgrund von Ansprüchen Dritter), welche im Zusammenhang mit der Verwendung dieser Publikation entstehen.

Die Nutzung dieser Publikation ist unter den Bedingungen erlaubt, dass (1) der unten angeführte CopyrightVermerk auf allen Kopien erscheint, und dass der Copyright-Vermerk und dieser Genehmigungsvermerk erscheinen, (2) die Dokumente dieser Web-Site nur zu informatorischen, nichtkommerziellen oder privaten Zwecken genutzt und nicht über Computernetze oder sonstigen Medien veröffentlicht werden, und (3) die Dokumente nicht verändert werden. Die Nutzung zu anderen Zwecken erfordert eine explizite Genehmigung seitens Ingentive Networks GmbH Diese Publikation kann technische Ungenauigkeiten oder typographische Fehler enthalten. Die darin enthaltenen Informationen werden regelmäßig verändert oder ergänzt. Die Ingentive Networks GmbH behält sich vor, jederzeit Änderungen und/oder Verbesserungen an einem oder mehreren der darin beschriebenen Produkte und/oder einem oder mehreren der Programme vorzunehmen. „HP“, „Procurve“ und „Ingentive Networks“ sind eingetragene Warenzeichen.