in der Dokumentation der v7 sind zwei neue Kapitel hinzugekommen:
a) Radius: Neben der Installation auf der OPNSense, ist nun die Dokumentation zur Installation
des Radius auf dem lmn7 Server hinzugekommen. Diese entspricht weitgehend der Installationsanleitung von Dominik @foer - vielen Dank ! http://docs.linuxmuster.net/de/v7/systemadministration/network/radius/index.html#
b) Authentifizierung eines externen Moodle-Systems:
Es ist ein neues Kapitel zur Umsetzung der Authentifizierung eines extern betriebenen Moodle-Systems gegen den AD der v7 hinzugekommen. Dies entspricht der Anleitung die @thomas als PDF verfasst hatte. Danke dafür !
In diesen Zeiten könnten einige ggf. die Anleitung sinnvoll nutzen
sehe ich es richtig, das die Anleitung von @foer PEAP-MSChapv2 nimmt, während @zefanja EAP-TTLS verwendet und das zwei unterschiedliche Verfahren sind? Ich vermute, dass der Unterschied in der default-einrichtung im Client ist und evtl. ältere Win-Versionen das eine oder andere nicht beherrschen. Gut wäre, wenn hier eine „works-best-with“ Erklärung mal liefern könnte, der sich auskennt und es ausprobiert hat
@foer hat „ntlm auth = yes“ in samba aktiviert, was mir suggeriert, das hier ntmlv1 verwendet wird, was bei samba aus sicherheitsgründen standardmäßig deaktiviert wurde. Wieder die Frage hier, ob wir das so propagieren sollten. Wer sich sicherheitstechnisch hier auskennt: bitte melden.
Die Zertifikate/Erstellung scheinen bei @foer nicht nötig zu sein. Vermutlich liegt das an den Unterschieden, die ich in 1. erwähne. Ist das so?
Am Ende sollten wir wohl noch ein paar SCreenshots aus Endusersicht in die Doku bringen.
…ja, das siehst du richtig. Ich kenne mich nicht in der Tiefe aus, aber ich habe nicht EAP-TTLS verwendet, weil ich da Zertifikate für die Clients brauche und genau das geht überhaupt nicht…man stelle sich vor, man müsste seinen Kollegen und Schülern beibringen, wie sie auf der ganzen Bandbreite von heterogener Hardware (PC, Smartphone, Tablets mit unterschiedlichsten Betriebssystemen und Versionen) das Zertifikat importieren und bei der WPA2-Enterprise Verbindung einbinden…es ist so (peap mit mschapv2) schon komplex genug.
…das suggeriert es dir richtig (schreibt man das so ?) Und du hast recht…nein das sollte so nicht in die Anleitung…ich habe da seit langem auch eine andere Konfiguration. In der smb.conf steht bei mir: ntlm auth = mschapv2-and-ntlmv2-only. Damit das mit dem Freeradius klappt muss noch in /etc/freeradius/3.0/mods-enabled/mschap und /etc/freeradius/3.0/mods-enabled/ntlm_auth in den Aufruf von ntlm_auth = "/usr/bin/ntlm_auth… die Option: --allow-mschapv2.
Jepp…wie schon gesagt für den usercase elementar…da wurde schon bei der lmn6 viel diskutiert und letztendlich wurde auch dort PEAP mit MSChapv2 eingesetzt (im linuxmuster-freeradius-Paket) allerdings über das ldap-Plugin und nicht über ntlm_auth angebunden.
Noch eine Anmerkung zum Freeradius auf der Opnsense…der funktioniert schon irgendwie aber halt nicht zusammen mit Unifi…ich habe nach ein paar Tagen einfach aufgegeben da weiter zu machen…
danke für die Richtigstellungen. Werde ich in die Doku übernehmen.
ok. Das vergaß ich noch zu fragen: Ich sehe die Abhängigkeiten, dass freeradius Zugriff auf winbindd haben muss und da schließe ich, dass das genau mit dem ntlm_auth Plugin zu tun hat - denn in diesem Fall wird ja ein bind-user wie bei LDAP umgangen. Diese Variante wird ja auch nur (sicher) auf dem Server direkt funktionieren. (Deswegen ist es bei der OpnSense-Variante ja über LDAP).
Gibt es einen triftigen Grund, weswegen du das ntlm_auth dem ldap-plugin den Vorzug gegeben hast?
Sobald es bei mir mit den APs über den Server läuft, werde ich das mal auf der OpnSense probieren.
Ok, das ist gut zu wissen. Dann werde ich das auch in der Doku anmerken.
Bei mir sind die APs/der Controller ja nicht in meiner Hand, daher nehme ich auch gerne den Weg, bei dem ich sicherer weiß dass er funktioniert.
ich verstehe. Bei mir ist gerade „nur“ ein Captive Portal eingerichtet, das auch Voucher bieten würde. Meine Vermutung geht dahin, dass man WPA-Enterprise + Vouchersystem nicht unter einen Hut bringt. Was denkst du?
(Ich meine jetzt nicht das ich lmn-Konten als voucher-konten anlege, so dass die Voucher dann regulär über WPA-Enterprise reinkommen)
was jetzt nicht das erste ist, was böse Menschen machen, aber auch nicht nur theoretischer Natur.
die usability: das ist ja der Grund, es nicht über EAP-TTLS zu machen. Allerdings könnte @zefanja noch kommentieren, ob man wirklich „Zertifikate einbauen“ braucht, wenn man über letsencrypt einfache oder Wildcard Zertifikate nimmt.
Kriegt man dadurch halbwegs moderne Geräte dazu, die Serverzertifikate automatisch zu akzeptieren, so dass auch nur einen „username“ + „passwort“ Eingabe bei den Endgeräten notwendig wird?
Dort findet man eigentlich alles rund um den RADIUS Server, welche Verfahren es für die verschiedenen Stufen des ganzen Verfahrens gibt usw. Es lohnt sich, sich damit mal auseinander zusetzen.
RADIUS unterstützt viele verschiedene Protokolle. Im verlinkten Artikel habe ich beschrieben, wie man EAP-TTLS einrichtet (nicht EAP-TLS, hier gibt es eine Übersicht über alle EAP Protokolle). Für EAP-TTLS braucht man nur Zertifikate auf dem Server, aber nicht auf dem Client, d.h. es reicht username / password um sich mit dem WLAN zu verbinden. Unter manchen Betriebssystemen muss man noch einen Haken machen, um das (selbst signierte) Zertifikat nicht zu validieren. Wenn man hier ein valides Zertifikat einsetzt ist der Schritt nicht notwendig.
Ok. Hatte mich schon mit Wikipedia fortgebildet, aber nach Lesen von freeradius.org, komme ich zu dem Schluss, dass
PEAPv0/EAP-MSChapv2 vermutlich von jedem erdenklich vorkommenden OS unterstützt werden würde und sich von der Usability für die Schule eignet. Es gibt noch Probleme das über unifi-APs auf der Opnsense einzurichten und evtl. gibt es noch Bedenken bezüglich der Sicherheit der ntlmv1-Authentifizierung. Aber hier könnte das auch gar nicht mit WPA zusammenhängen, sondern nur die HASH-Variante sein, die verwendet wird.
EAP-TTLS hat evlt. weniger gute Unterstützung bei älteren Systemen und für den Schulbetrieb ist es vermutlich dann super, wenn die Zertifikate nicht selbst-signiert sind. Ich lese noch, dass dieser Tunnelbetrieb noch nichts darüber sagt, welches ungetunnelte Protokoll verwendet wird (PAP), und daher vermute ich, dass wenn es wg. ntlmv1 Sicherheitsbedenken gäbe, träfen die hier auch zu.
Ich finde also beide Varianten tauglich. Evlt. funktioniert EAP-TTLS auch mit unifi auf der opnsense, dann spricht sogar mehr für diese Lösung (wenn man seinem server ein letsencrypt-zertifikat spendiert).
Meine Analyse bohre ich jetzt nicht tiefer. Da darf gerne jemand anderes loslegen.
Ich hatte mich auch einmal mit den Verfahren befasst, weil wir das noch umstellen wollen. Das Zertifikat hat auch die Aufgabe den Radius-Server/den Netzzugang auf Client-Seite zu validieren ("Ist das wirklich der Access-Point, mit dem ich mich verbinden will, oder heißt der nur so? → MITM-Angriffe). Bei den Zertifikaten findet keine Überprüfung der FQDN oder IP statt!
Es gibt im Hinblick auf die Zertifikate folgende Möglichkeiten:
selbst-signiertes Zertifikat; Validierung wird auf Client deaktiviert; Verbindung wird dann verschlüsselt; die Verbindung aber nicht auf Client-Seite validiert.
Let’s-Encrypt-Zerti (oder anderes): Wenn die Clients das nicht im Browser haben, sondern im System, funktioniert auch die Validierung. Allerdings könnte dies umgangen werden, indem sich ein eigenes Rouge-Accesspoint ein Let’s-Encrypt-Zertifikat holt, das dann auch validiert wird. Die Verbindung ist in diesem Fall auch wieder verschlüsselt, die Verbindung wird auch validiert, allerdings kann man der Validierung eigentlich nicht trauen.
selbst-signiertes Zertifikat; das public-Zertifikat wird auf den Clients installiert; In diesem Fall wird die Verbindung verschlüsselt und validiert; Solange der Private-Key sicher ist, kann man der Validierung trauen und ein MITM-Angriff mit Rouge-AP ist nicht möglich.
Unsere Überlegung dazu: EAP-TTLS einsetzen mit selbst-signiertem Zertifikat und in der Anleitung nicht-validieren darstellen; zusätzlich für mehr Sicherheit das imporieren des public-Keys erklären.
danke!
Ok. Ich sehe, dass der Angriffsvektor „Rogue-AP“ viel wahrscheinlicher ist als veraltete Hash-verfahren, so dass die Verschlüsselung des Passworts oder des Transports geknackt wird.
Guter Punkt! Hatte mich schon gewundert, weil ich ja noch nie den radius als FQDN irgendwo eingetragen hatte. Dann ist diese scheinbare Sicherheit auch nur scheinbar. Dann würde ich das auf alle Fälle nicht in der offiziellen Doku als „sichere Variante“ verkaufen wollen.
Außerdem finde ich die Überlegung für die linuxmuster.net - Anleitung auch sinnvoll. So kann jede Schule auf die Anleitung verweisen, dass man zunächst mal nicht-validiert und zur Erhöhung der Sicherheit kann jede Schule für sich entscheiden, wie weit sie es mit Schulung von Schülern und Lehrern treibt…
Hi.
Ich hatte vor einiger Zeit auch die 1. Anleitung von Dominik verwendet … das kann ich aber nachjustieren, wenn es mit mschapv2-and-ntlmv2-only besser wird??
Aber …
der Post von Fabian klärt einiges für mich.
Ich denke, es gibt seeeehr viele Arten es zu machen, die verbreitetsten sind wohl
PEAP/EAP-MSChapv2 nach Anleitung von @foer und momentan offiziell und
EAP-TTLS nach Anleitung von @zefanja s blog mit der Ergänzung, dass man es so machen kann wie Fabian vorschlägt: erstmal das Zertifikat ignorieren und als sicherere Variante ein selbstsigniertes Zertifikat importieren. Die Sicherheit kommt daher, dass du gezwungen wirst das korrekte Zertfikat zu installieren und damit die Validierung einmal selbst vornimmst, während bei LE-Zertifikaten man einfacher einen MiTM-Angriff machen kann.
„Gleich richtig“ ist so eine Sache: Erstens ist es schwerwiegend, wenn linuxmuster.net irgendwas empfiehlt und zweitens ist hier vllt. eine Abwägung im Spiel, zwischen Komfort und Sicherheit.
Aber ich tendiere gerade auch zu @zefanja und @fkretzschmar: EAP-TTLS mit selbstsigniertem Zertifikat, das man - wenn einem die Sicherheit egal ist - auch einfach ignoriert.
ich habe ja meinen freeradius nach der docs.linuxmuster.net Anleitung eingerichtet, fazit:
PEAP/MSChapv2 funktioniert, aber auch hier muss ich das Zertifikat ignorieren klicken
EAP-TTLS/PAP funjktioniert auch (!), wusste gar nicht, dass ich das sozusagen auch mitkonfiguriert hatte (?), auch hier muss ich das Zertifikat ignorieren
EAP-TTLS/MSChapv2 funktioniert auch, auch hier muss ich das Zert. ignorieren
„Zertifikat ignorieren“ bezieht sich auf einen ubuntu 18.04 client mit MATE network-manager frontend.
beim IPAD gab es eine auswahl zwischen „Automatisch“ und „EAP-TLS“ und hier funktioniert nur „Automatisch“, weil EAP-TLS ja ein client-zertifikat erfordern würde. Dann muss man beim IPAD das Zertifikat von „server“ akzeptieren.
Beim letzten Punkt bin ich aufgrund der super benutzerfreundlichen Oberfläche der Apfelprodukte natürlich jetzt mir nicht bewusst, welches Protokoll verwendet wird. Evtl. nutzt der EAP-TTLS/PAP und das Zertifikat muss abgenickt werden. Evtl. nutzt der auch PEAP/MSChapv2 und auch da muss vllt. ein Zertifikat abgenickt werden.
Ist irgendwie nicht das gelbe vom Ei, wenn man selbst nicht weiß, welche Protokolle funktionieren. Da ist eine downgrading-Attacke ja geradezu vorprogrammiert…
Bei EAP-TTLS ist MSCHAPv2 Standard. Das Zertifikat muss immer abgenickt werden.
Bei Apple steuert man sowas im Firmen-/Schulumfeld am Besten über eine network payload in Form eines Device Management Profils. So kann man den EAP-Typ festlegen oder vertrauenswürdige FQDN festlegen.
Diese Profile installiert man am besten per MDM oder AppleConfigurator (für schuleigene Geräte; auch AppleTV).
Man kann die Profile aber auch irgendwie anders (Download, Mail, Airdrop) auf die Geräte bringen und manuell installieren (lassen). Das hatte ich mal gemacht, als wir noch knapp 20 Accesspoints mit unterschiedlichen SSID und teilweise auch unterschiedlichen WPA2-Passwörtern hatten
danke, du bist ja voll der Profi. Vllt. hast du im Parallelthread die Diskussion mitbekommen, dass mind. ein Entwickler nicht wünscht, dass in der Doku der „freeradius auf dem server“ als empfohlene default Variante drin steht.
Kannst du nicht deine Ansicht sagen, was ein gutes Vorgehen wäre.?
Ich erläutere mal, was ich meine:
der standard-install-admin oder der dienstleister setzt einen freeradius auf. Je nachdem, ob der das auf der OpnSense, auf dem Unifi-Controller, auf einer eigenen VM oder auf dem Server macht, kommt beim Enduser ja ein anderes Zertifikat an. Bei mir z.B. jetzt das Zertifikat von „server“, weil ich es auf dem Server installiert hatte. Du würdest das Zertifikat per MDM in Apple einbauen bzw. ein FQDN als vertrauenswürdig markieren. Bei anderen Systemen geht das sicher auch (linux → postsync, windows → postsync o. opsi o. gruppenrichtlinien) usw.
Dazu wundert es mich jetzt doch zusätzlich, dass so wie ich das nach Anleitung installiert habe, ich soviele verschiedene Verbindungsarten zu stande bekommen habe. Ich hätte vermutet, das es am sichersten ist, wenn man sich auf die sicheren Varianten beschränkt - und EAP-TTLS/PAP bedeutet doch, dass innerhalb der EAP-TTLS Handshake verschlüsselung mit PAP das Passwort (?) im Klartext übergeben wird? Von mir aus kann auch alles möglich „angeschalten“ bleiben, aber hast du deinen freeradius so eingeschränkt, dass nur deiner Ansicht nach sichere Verfahren zum Einsatz kommen?
Dass irgendein Zertifikat auf alle Fälle abgenickt (oder „CA ignoriert“) werden muss, war mir nicht klar. Irgendwie hatte ich das Gefühl, dass nur EAP-TTLS so eine Validierung will. DAs sollte vllt. auch in die Anleitung
Dass bei mir jetzt „server“ im Zertifikat steht und nicht „server.meine-domäne.de“ - das wundert mich, da ich ja nach der Anleitung gar nichts an Zertifikaten gemacht hatte - vermutlich ist das das snake-oil-zert.
Ich bin ziemlich euphorisch, dass das WLAN jetzt so reibungslos bei mir läuft, bin aber auch skeptisch, weil ich a.) der Anleitung folgend und weiterem Studium nicht guten Gewissens für die Sicherheit bürgen will (siehe oben, so viele Verfahren möglich) und b.) ich mit dem <<snake-oil-Zertifikat „server“ Abnicken>> meinen Kollegen nicht guten Gewissens die Vertrauenswürdigkeit meines WLANs verkaufen will und c.) es gerne auch richtig gemacht hätte und z.B. freeradius auf einem eigenen Server oder auf der OpnSense laufen lassen würde, dann meldet sich vermutlich derjenige Server mit seinen selbst-signierten Zertifikaten zurück.
Ist denn dann nicht eine kluge Empfehlung, wie bei zefanjas Blogeintrag eine CA + zertifikat zu erstellen mit „wlan.meine-schule.de“ und dann den Kollegen zu empfehlen, den Fingerprint zu vergleichen und abzunicken? also besser als „server“ wäre das allemal und laut deinen Aussagen auch besser, als ein letsencrypt zu nehmen und die Kollegen dahingehend gar nicht schulen.
Danke ,wenn du noch ein STatement abgeben könntest, so dass hinter den Doku-Empfehlungen auch ein schlüssiges Konzept steht.
TLDR: Ich fänd’ im Hinblick auf den Radius Optionen gut (vgl. Installationsoptionen für den Server). Im Hinblick auf die Zertifikate (CA) habe ich noch keinen Überblick, würde aber versuchen eine selbst signierte Intermediate-CA zu nutzen.
Ausführlich…
Ein Profi bin ich sicherlich nicht; ich habe nur meist nutzloses Spezialwissen. Ich hatte aus der Not heraus (unsere AP lassen sich nicht zentral verwalten) vor einiger Zeit einiges zu WPAe gelesen und ein Testsetup mit OPNsense (und noch ohne Linuxmuster) gebastelt, weil man nur so die Zugangsdaten zentral verwalten kann; produktiv nutze ich das noch nicht, weil ich eigentlich seit 1 1/2 Jahren die Hoffnung habe, dass bald eine zentral verwaltbare Infrastruktur kommt…
Wo der Radius läuft ist doch im Grunde egal. Bei uns läuft der auf der OPNsense; das geht auch, aber dort kann man nicht alle Einstellungen, die man vielleicht machen möchte, über das UI machen (EAP-Typen abschalten; maximale Simultane Verbindungen setzen). Da der Radius meiner Meinung nach eine Art Addon zur Musterlösung darstellt, finde ich es gut, dass mehrere Installationsmöglichkeiten dokumentiert sind; man könnte dazu ergänzen, welche Beschränkungen es bei den einzelnen Lösungen gibt, aber letztlich kommt es doch auch darauf an, mit welcher Lösung sich der Admin wohler fühlt. Vielleicht sollte man auch bei RADIUS von „Optionen“ sprechen, wie beim Server.
Vielleicht noch ein paar technische Infos (an die ich mich hoffentlich richtig erinnere):
Zertifikate: Eine „saubere“ Lösung wäre: Wenn man Identity-Zertifikate (TLS und optional die anderen Verfahren) machen möchte, baut man sich eine Intermediate-CA.
Die könnte man auch alternativ zur neuen Root-CA (vgl. zefanjas Blogeintrag) nutzen; dann müsste man auf Schuleigenen Geraten (oder auch bei Kollegen) trotzdem nur das public Zertifikat der Root-CA importieren und WLAN, aber auch anderes, intern signiertes funktioniert.
Die Root-CA sollte man eigentlich nicht online auf irgendwelchen Servern haben; ich habe aber zur Zeit keinen Überblick, wofür die bei Linuxmuster noch genutzt wird.
Authentifizierungsverfahren: EAP-TTLS/MSCHAPv2 und PEAP ist im wesentlichen das gleiche (PEAP vielleicht etwas verbreiteter). Bei der Authentifizerung ist vermutlich MSCHAPv2 vorzuziehen, aber es gibt bestimmte Backends, die nicht mit MSCHAPv2 umgehen können und PAP nutzen müssen (Samba4 kann das aber vermutlich).
Dokumentation Radius OPNsense: Im Screenshot der OPNsense ist MSCHAPv2 dargestellt. Das ist vermutlich EAP/MSCHAPv2 und damit ohne TLS… Das sollte man vielleicht auf PEAP ändern.
Sicherheit ist zunächst Client-Sache: Bei Freeradius (auf dem Server und auch auf der OPNsense) sind die default-Einstellungen aktiv. Das bedeutet alle Arten genutzt werden können, wenn der Client sie mit einem RADIUS Auth Request anfordert (das ist auch seine Aufgabe). Du kannst natürlich Authentifizierungsmodule deaktivieren; das geht aber in der OPNsense soweit ich das sehe nicht in der UI (s.o.).
1000 Dank für deine Idee. Ich möchte gleich mit der Tür ins Haus fallen:
Hast du nicht Bock diesen Teil der Doku zu übernehmen. Nicht alleine selbstredend aber ich glaube wir könnten von deinem nicht nutzlosen Spezialwissen alle profitieren. Denn deine im letzten Post geäußerten Ansichten bzgl. der Optionen teille ich auf ganzer Linie.
Wie könnte eine sinnvolle Gliederung in deinen Augen aussehen?
