Netzwerk Aufbau - WLAN Netze, Login

Ist doch prima. Professioneller und empfehlenswerter als ein offenes WLAN mit Captive Portal.



Aber nur unter XP und älter. Und diese Systeme sollten aber nun wirklich langsam mal aussterben...


Gruß
sk

Nicht unbedingt... Verrät einer der Nutzer (und das ist absehbar wann das passiert...) seinen Usernamen Passwort ist auch diese Sicherung sinnfrei. Bei einem Einmalpasswort macht das nur Sinn in dessen Laufzeit. Danach kann man das Passwort dann so oft "verraten" wie man lustig ist.
Bei Gastzugängen mit unbekannten Gästen ist und bleibt immer noch das offene WLAN mit CP und Einmalpasswort der beste Kompromiss....

Und warum sollten die 802.1x-Zugangsdaten eine unbegrenzte Laufzeit haben? Auch diese können den Charakter eines Einmalkennwortes haben, weil sie z.B. nur für einen Tag oder nur wenige Stunden Gültigkeit haben. Man benötigt dafür lediglich ein geeignetes Backendsystem und Accesspoints, welche auch die Accounting-Infos liefern.
Eines meiner Hauptprojektes dieses Jahr war das Finden, Evaluieren und Implementieren eines solchen Systems. Umgesetzt wurde das Vorhaben letzlich mit Komponenten von MeruNetworks. Kernkomponente ist der Meru Identity Manager, welchen man grundsätzlich auch mit den Systemen anderer Hersteller kombinieren kann (den IDM hat Meru ohnehin nur zugekauft).

Gruß
sk

Welche Features fehlen Dir denn nun genau bei den vorhandenen APs? VLANs und MultiSSID werden z.B. auch von den vorhandenen NWAs unterstützt und ein zentrales Management wäre ähnlich wie bei Ubiqui auch über eine Software möglich - wenngleich bei lediglich 3 APs doch etwas übertrieben.



Kann ich nicht bestätigen. Welche Authentifizierungsmethode kommt denn zum Einsatz? Wir verwenden hier PEAP in Verbindung mit einem von einer öffentlichen CA signierten Serverzertifikat. Letzteres führt zwar anders als man erwarten würde nicht dazu, dass der User das Cert nicht einmalig aktiv akzeptieren müsste, aber doch wenigstens dazu, dass er unter Vista und höher das WLAN-Profil nicht von Hand anlegen muss. In der Praxis hat sich dies bei uns als akzeptabel erwiesen.



Ja in Verbindung mit aktivierter Layer2-Isolierung/IntraBBS-Blocking durchaus. Hab ich auch lange so gehandhabt. Der Key dient nämlich nur dem Zutritt zum WLAN, nicht aber der Verschlüsselung. Die Keys dafür werden dynamisch erzeugt.



Mit geeigneten Komponenten ja.


Gruß
sk

Hallo Bernhard,



Die Dinger sind bzw. waren wirklich übel. Von einem OEM-Partner zugekaufter Murks der billigsten Sorte.



Mach mal Deinem Client das öffentliche Cert der CA bekannt, die das Cert des Radius-Servers ausgestellt hat. Das führt zwar nicht dazu, dass - wie man eigentlich erwarten würde - das Serverzertifikat nicht händisch bestätigt werden müsste, jedoch immerhin dazu, dass auch alle Windows-Versionen größer als XP nach Benutzernahme und Kennwort fragen. Wenn man darüber hinaus noch den Haken setzt bei "automatisch verbinden", dann legt Windows nach erstmaligem Durchlaufen der Anmeldeprozedur auch ein WLAN-Profil dazu an.



Das Radius-Protokoll ermöglicht optional die Übertragung diverser standardisierter und nichtstandardisierter (herstellerspezifischer) Attribute. Wenn der Accesspoint also in seiner Anfrage an den Radiusserver die Information überträgt, in welche SSID der Client die Einwahl versucht, dann kann auf einem geeignetem Radius-Server eine dementsprechende Prüfung stattfinden.
Diese könnte z.B. so aussehen:
1) "Wenn die Anfrage von AP1 kommt, der Client eine Einwahl in SSID_A versucht und der Benutzer Mitglied der Gruppe "WLAN-Berechtigung_A" ist (und das Kennwort stimmt), dann erlaube den Zugriff anderenfalls gehe zur nächsten Policy"
2) "Wenn die Anfrage von AP1 kommt, der Client eine Einwahl in SSID_B versucht und der Benutzer Mitglied der Gruppe "WLAN-Berechtigung_B" ist (und das Kennwort stimmt), dann erlaube den Zugriff anderenfalls gehe zur nächsten Policy"
3) "Verweigere den Zugriff" (=Defaultpolicy)

Übrigens geht auch der umgekehrte Weg: Der Radius-Server kann nicht nur Ja oder Nein sagen, sondern z.B. in Abhängigkeit von einer Gruppenmitgliedschaft eine VLAN-ID oder einen anderen definierten Wert zurückliefern, anhand dessen der Accesspoint den Client dann in ein spezielles VLAN packt (wenn der AP diese Funktionalität unterstützt).

Inwiefern der Radius-Server auf Deinem Synology-NAS so eine Policyabarbeitung zulässt, entzieht sich meiner Kenntnis. Es sollten sich aber im OpenSource-Umfeld relativ problemlos geeignete Alternativen finden lassen. Diesbezüglich bin ich allerdings nicht so kundig.
Wie oben geschrieben, habe ich in einem diesjährigen Projekt den Identitymanager von Meru eingesetzt. Der kann dies und vieles mehr. Allerdings überschreitet allein der IDM schon Euer Budget. Im Rahmen dieses Projektes hatte ich auch geprüft, ob eine Realisierung mittels der Buildin-Funktionalität des bereits von Dir genannten WLAN-Controllers von ZyXEL (bzw. des bei uns vorhandenen NXC5200) möglich ist. Meine spezifischen Projektanforderungen waren damit leider nicht realisierbar, aber diese lagen auch wesentlich über den Deinigen. Leider kann ich im Moment nicht sagen, ob sich Deine Anforderungen mit dem NXC umsetzen lassen - dafür ist das schon zu lange her. Ich müsste das nochmal genau austesten. Allerdings käme ich dazu wohl erst Mitte Februar. Dann hoffe ich ohnehin die neuen managed ac-Accesspoints von ZyXEL (WAC650x) testen zu können. Wenn Dein Projekt also zeitlich nicht zu sehr brennt, lohnt es sich vielleicht noch auf meine Testergebnisse zu warten. Der NXC könnte nicht nur die Funktion des WLAN-Controllers und Authentifizierungsservers übernehmen, sondern ebenso auch als Backendfirewall dienen.


Gruß
Steffen


NACHTRAG:
Mein Test des NXC würde klären, ob die mit der controllerinternen Voucherlösung namens "dynamic Guest" erzeugten Gastkonten auch zur WLAN-Authentifizierung per 802.1x herangezogen werden können und ob über unterschiedliche DynamicGuest-Gruppen auch eine granulare Zugriffsteuerung für verschiedene 802.1x gesicherte WLANs/VLANs möglich ist. Eine Captive Portal-Authentifizierung ist in jedem Fall möglich - doch von diesem antiquiertem Zeug sollte man m.E. langsam mal runterkommen. Was ebenfalls (zumindest bei CP-Authentifizierung) definitv möglich ist, ist die benutzergruppenbezogene Beregelung des Traffics per Firewall: also z.B. Gäste der Gruppe A dürfen nur vom WLAN ins Internet zugreifen, aber Gäste der Gruppe B dürfen zusätzlich auch ins interne Netz zugreifen etc.

Ich würde in der Konstellation zu einem Lancom 1781VA oder EF+ greifen, die Wlan Controller Option buchen und 3 APs kaufen, fertig. Dann noch Public Spot gebucht und gut ists.

.@sk
Hast du dir mal Aruba Clearpass angesehen ? M.E. ist das dort noch erheblich besser gelöst als bei Meru gerade auch was das Einbinden von 3rd Party Produkten anbetrifft.
Gut Aruba hat nicht das Single Channel Virtual Cell Verfahren wie Meru...oder nur mit Umwegen. Aus Security Sicht ist Clearpass aber durchaus einen Test wert.
Mal abgesehen das es dem TO sicher nicht hilft da weit über sein Budget....

Nein das hatte ich nicht auf dem Schirm. Scheint wirklich eine sehr umfangreiche Lösung zu sein. Wobei wir schon die Features des Meru IDM mit unseren spezifischen Anforderungen nicht ausgereizt haben. Selfregistration mit anschließender Prüfung und Freigabe durch einen Sponsor gibt es z.B. auch beim IDM. Das nutzen wir aber genauso wenig wie "Smart Connect".
Kernanforderung in diesem Projekt war die rechteabgestufte Delegation der Verwaltung von Benutzerzugängen und ein zentrales Logging/Monitoring derselben über verschiedene Standorte und Systeme hinweg.



Die Entscheidung für den MIDM war unabhängig von der späteren partiellen Einführung der WLAN-Lösung von Meru. Natürlich hat es den Schritt hin zu letzterem auch erleichtert, aber grundsätzlich war eine herstellerneutrale Authentifizierungslösung gesucht, da ohnehin vorhandene Systeme eingebunden werden mussten.


Gruß
Steffen

Ich kann mich nur gilligan anschließen. Ein LANCOM 1781 (in der entsprechenden Bestückung EF, VA, wie für den Internetzugang notwendig - aber ohne WLAN) + WLAN-controller-Option + Public Spot und drei L-320/321er APs und Du hast alles, was Du brauchst.

Das einfachste für den Gäste-Teil ist offen mit CP. Kommt also drauf an, was über das Gäste-Netzwerk laufen soll. Wenn es hier auch um vertrauliche Daten geht, kann man das durchaus auch verschlüsseln und das Passwort regelmäßig ändern. Missbrauch ist mit dem CP ausgeschlossen, und abhören durch das regelmässig geänderte Passwort.
Alles andere ist die Frage, was man an Aufwand dem Gast zumuten will.

Eine gute Übersicht an Pro APs findet man auch hier:
https://www.heise.de/artikel-archiv/ct/2015/01/144_Schnellfunker

Wem WPA-Enterprise für den User als zu kompliziert erscheint, für den könnte auch das proprietäre Private-PSK-Verfahren von Aerohive interessant sein. Praktikabler als z.B. die auf den ersten Blick ähnlich erscheinenden Verfahren von Aruba und Lancom.

Gruß
sk

Der Radius vom LANCOM funktioniert tatsächlich tadellos und ist eigentlich auch recht einfach einzurichten.

Der FreeRadius auf einem RasPi funktioniert ebenso tadellos und ist noch einfacher einzurichten !!
Und dann erst der NPS Radius Server auf Windows. Rein Klicki Bunti und am einfachsten von allen einzurichten !
Das ist Unsinn, da rennt ein FreeRadius und über den Shellzugriff ist der granular einzurichten. Wenn du Klicki Bunti Knecht bist und eh einen Winblows laufen hast nimm den NPS.
Die Linksammlung hier:
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
hat die weiteren Infos dazu.

Bei den alten ZyNOS-basierenden Accesspoints war dies möglich und war auch im Handbuch klar dokumentiert. Für die aktuellen ZLD-basierenden Accesspoints finde ich leider nirgends einen dementsprechenden Hinweis. Weder im Datenblatt, noch im Handbuch oder allen sonstigen Supportdokumenten. Ohne es selbst ausprobiert zu haben (könnte ich wie gesagt erst Februar), würde ich daher im Zweifel sagen: Nein, geht nicht!

Gruß
sk