Ich bin jetzt nicht genau der radius experte also bitte korrigeiren wennnich was falsch im kopf habe.
Aber, ichndachte das ist so, dass man eine eigene ca und den key braucht dass man uberhaupt client zertifikate erzeugen oder wieder zurueckziehen kann.
Wenn ich eine fremde ca verwenden moechte (LE) kann ich ja keine zertifikate erzeugen weil der key wohlbehuetet bei letsencrypt liegt. es handelt sich ja beim wlan um private netzwerke. Da sind die geraete nicht mit domainadresse im internet so auf die da letsencrypt zertifikate ausstellen wuerde.
kein Endgerät spricht direkt mit dem RADIUS-Server, daher kann man im WPA-Supplicant auch nicht direkt einen RADIUS-Server auswählen. Der Client sendet sein Authentisierungsanfrage an irgendeinen AP. Dieser AP (oder irgendein Proxy wenn man die Netzlast verringern will) spricht dann mit dem für dieses Funknetz zuständigen RADIUS-Server und fragt: Hier hab hier ein Gerät, das kommt mit den und den Daten daher, darf der rein? Der RADIUS sagt dann, jo passt, lass durch oder Nein, der darf nicht, der kommt mit einem Zertifikat daher, dessen Zertifizierungsstelle ich nicht kenne, oder ich hab die Anmeldedaten geprüft, entweder stimmt Benutzername oder Kennwort nicht.
Der RADIUS-Server ist über die Einstellungen des Funknetzes definiert. Kein Client darf den frei wählen, daher kann man das auch nicht konfigurieren. Auch über irgendein Tool nicht.
ganz Recht, der CA-Key zum Signieren liegt bei der Zertifizierungsstelle, aber wenn du z.B. über certbot ein Zertifikat bei LetsEncrypt anforderst bekommt man ein Serverzertifikat mit dazugehörigem pivatekey. Die liegen i.d.R. unter /etc/letsencrypt/ssl/live/name.der.webseite.
Die kann man mit openssl so exportieren, dass daraus ein p12-Zertifikat wird, das man auf Endgeräten als Clientzertifikate importieren kann.
Man braucht nur Zugriff auf irgendeinen Server, der sich LE-Zertifikate holt.
ich schrieb auch nicht von einer freien Wahl des RADIUS-Servers, sondern von der Überprüfung des korrekten Kommunikationspartners und dass dieser vom WLAN-Betreiber vorgegeben ist. Natürlich reichen die Endgeräte ihre Zugangsdaten nur an den AP und der leitet die Nachricht weiter, dennoch muss das Endgerät prüfen, ob am anderen Ende der korrekte Server kommuniziert.
Dort kann ich sehr wohl einstellen, dass wenn der falsche RADIUS-Server „antwortet“, weil es ein AP oder RADIUS-Server eines MITM-Angreifers ist, mein Endgerät dann keine Daten übermittelt.
(Hervorhebung von mir)
Warum sollte man so einen Unfug machen? Dann kann man ja nie einzelne Clients unterscheiden, geschweige denn durch Widerruf des Zertifikats sperren.
jetzt verstehe ich, was du meinst. Die Einstellung ist aber an sich dafür da um zu verhindern, dass der Client andere Zertifikate als die einer bestimmten Zertifizierungsstelle für diese WiFi-Verbindung verwendet werden soll, z.B. wenn ich vorher eigens eine CA importiert habe aus der mein Client-Zertifikat stammt. Also kurz: ich sage dem Client: Verwende für diese Verbindung ein Zertifikat aus dieser Zertifizierungsstelle und nicht eins, was zufällig sonst noch in deinem Zertifikatsspeicher rumtobt aber aus einer anderen CA stammt.
Damit kann man, wie du ganz richtig sagst, Clientseitig verhindern, dass Daten an einen Rogue-RADIUS abfließen.
Das war aber gar nicht das Thema. Thema ist, ich kann mit irgendeinem LE-Zertifikat mit EAP-TLS auf meinem Smartphone einem Funknetz beitreten, das serverseitig ebenfalls mit LE-Zertifikaten arbeitet, weil beide Zertifikate aus der gleichen CA stammen und deswegen RADIUS mit LE-Zertifikaten Mist in der Kategorie „ESX im Internet veröffentlichen“ ist.
und jetzt verstehe ich dein Problem besser. Ja das liegt dann im Aufgabenbereich des RADIUS-Serverbetreibers. Wenn er die Wahl trifft eine weitverbreitet genutzte Zertifizierungsstelle für seine Clientzertifikate zu nutzen, dann kann und darf er sich nicht darauf verlassen, dass irgendein Zertifikat dieser Zertifizierungsstelle ausreicht. Er muss im RADIUS-Server seine Richtlinien zur Überprüfung des Clientzertifikats dann so einstellen, dass Details des Zertifikats geprüft werden und nicht nur der Zertifizierungsstelle vertraut wird.
Hier könnte dann das Problem auftreten, dass LE keine zusätzlichen Details in Zertifikatanträgen zulässt und man sich ausschließlich auf Validierung von DNS-Einträgen beschränken kann.
Die Aussage trifft auf den kleinen Rahmen oben in meinem Screenshot zu. Der untere Rahmen/Teil im Bild bezieht sich ausschließlich auf die Validierung des Zertifikats des RADIUS-Servers.
für RADIUS mit Authentifizierungmethode EAP-TLS (Clientzertifikate) gebe ich dir vollkommen recht.
Beim Serverzertifikat kann das schon sinnvoll sein, z. B. wenn BYOD ein Thema ist und man keine administrative Hoheit über alle eingesetzten WLAN-Clients hat. Dann hat man die Wahl alle Nutzer das Serverzertifikat auf ihrem Gerät importieren zu lassen oder man hat ein Serverzertifikat, dass von einer weit verbreiteten vorinstallierten Zertifizierungsstelle signiert ist. So oder so geht man immer durch die Supporthölle, wenn man fremde Geräte im WLAN hat.
so ganz verstehe ich das alles noch nicht, leider kenne ich mich mit Radius nicht wirklich gut aus.
Was mir nicht klar ist: Wieso soll es ein Problem sein, wenn ein Serverzertifikat z. B. von LE signiert ist? Der Server wird ja deshalb nicht gleich alle Client-Zertifikate akzeptieren, die mit irgendeinem anderen LE_Zertifikat generiert wurden. Der Server sollte doch nur Client-Zertifikate akzeptieren, die er selbst generiert (bzw. signiert) hat - mit seinem Zertifikat, das nur er hat.
Und überhaupt: Ich will ja gar keine Client-Zertifikate. Ich stelle mir das so vor: Erforderlich sind zwei Schritte:
Der Server weist nach, dass er wirklich der ist, der er behauptet, damit niemand seine geheimen Zugangsdaten irgendeinem fremden AP anvertraut.
Der Client weist nach, dass er das WLAN nutzen darf.
Im ersten Schritt reicht es doch vollkommen, wenn der Server ein (LE-)Zertifikat mit der Domain der Schulhomepage vorzeigt. Dann weiß der User (wenn er die Domain der Homepage kennt), dass er mit dem richtigen Server spricht.
Im zweiten Schritt kommen Username und Passwort zum Zug.
das Problem an der Sache ist die gemeinsame CA. Der RADIUS-Server vertraut jedem Zertifikat, das aus der gleichen CA stammt und gültig ist. Es ist vollkommen unerheblich ob du Client-Zertifikate machen willst oder nicht. Irgendjemand kann sich die Zertifikate, z.B. aus seiner privaten Nextcloud mit LE-Zertifikaten, schnappen und diese als Client-Zertifikat auf sein Endgerät importieren. Dann geht er in dein Funknetz und wählt nicht PEAP sondern TLS als Methode aus und wählt das Client-Zertifikat das LE-Zert seiner privaten Nextcloud. RADIUS prüft das Zertifikat und sagt: Prima, mein Serverzertifikat und das Zertifikat des anfragenden Clients stammen aus der gleichen CA, ist zeitlich gültig und somit vertrauenswürdig → ok
Und schon könnt ihr Clients im Netz haben, von denen ihr nicht mal zu träumen wagtet.
Stichwort: Organisationsvertrauen
So praktisch LE bei Webservern sein kann. Finger weg davon bei RADIUS. RADIUS ist kein Webserver und auch nicht vergleichbar.
Viele Grüße
Thomas
PS: Den Dialog könnt ihr euch so vorstellen:
Client: Hi! Ich will rein!
Server: Hi! Guck mal! Ich hab 'nen gültigen Ausweis von LetsEncrypt!
Client: Klasse! LetsEncrpyt kenn ich! Guck mal, ich hab auch einen gültigen Ausweis von LetsEncrypt!
Server: Super! LetsEncrypt kenn ich auch! Komm rein!
und sooo schwierig ist das bei freeradius nun nicht mit den eigenen Zertifikaten.
Unter /etc/freeradius/3.2/certs liegen i.d.R cnf- Dateien, Vorlagen zum Generieren von CA, Server und Client-Zertifikaten → einmal richtig ausfüllen → make → mods-enabled/eap anpassen → fertig
Und Stichwort BYOD → da würd ich mir zweimal überlegen, ob ich solche potentiell verseuchten Geräte in ein mit WPA/2/3-Enterprise abgesichertes Netz aufnehme, wo evtl. sensible Daten liegen, oder die doch lieber in einem Gast-Netz mit CaptivePortal unterbringe
danke für Deine ganzen Erklärungen - so langsam verstehe ich das Problem: „Der RADIUS-Server vertraut jedem Zertifikat, das aus der gleichen CA stammt.“ Das ist für die Situation, dass der Server seine eigene CA ist, und sicher ganz viele Szenarien natürlich sinnvoll. Für ein WLAN mit BYOD bedeutet das aber, dass man immer die CA auf den Endgeräten bekannt machen oder ihr „irgendwie“ vertrauen muss.
Das Problem ist ja nicht, eine eigene CA zu basteln - das geht recht einfach. Das Problem ist, dass sich die User dann nicht einfach so anmelden können.
Einsatzzweck wäre ein WLAN ohne (ungesicherten) Zugriff auf Schulnetz. Dort soll man auch BYOD-Geräte verwenden können. Da wäre es schon schön, wenn das mit Radius so ginge, dass die Clients dem Radius automatisch vertrauen, weil er ein gültiges und von einer vertrauenswürdigen CA signiertes Zertifikat für eine bekannte Domäne vorzeigt. Aber wenn ich die Diskussion richtig verstehe, dann ist das bei Radius nicht vorgesehen.
vielen Dank für eure Diskussion: so langsam wird mir das alles klarer.
das Problem an der Sache ist die gemeinsame CA. Der RADIUS-Server
vertraut jedem Zertifikat, das aus der gleichen CA stammt und gültig
ist. Es ist vollkommen unerheblich ob du Client-Zertifikate machen
willst oder nicht. Irgendjemand kann sich die Zertifikate, z.B. aus
seiner privaten Nextcloud mit LE-Zertifikaten, schnappen und diese als
Client-Zertifikat auf sein Endgerät importieren. Dann geht er in dein
Funknetz und wählt nicht PEAP sondern TLS als Methode aus und wählt das
Client-Zertifikat das LE-Zert seiner privaten Nextcloud. RADIUS prüft
das Zertifikat und sagt: Prima, mein Serverzertifikat und das Zertifikat
des anfragenden Clients stammen aus der gleichen CA, ist zeitlich gültig
und somit vertrauenswürdig → ok
Und schon könnt ihr Clients im Netz haben, von denen ihr nicht mal zu
träumen wagtet.
… jetzt hab ich das auch endlich mal verstanden: also woher das "keine
öffentlichen Zertifikate im Radius kommt.
Das mit der eigenen CA ist auch echt kein Hexenwerk: steht auch hier im
Forum wie das geht (danach hab ich es auch eingerichtet).
Und jetzt wo Android die Möglichkeit hat beim ersten Kontakt der CA zu
vertrauen ist ja alles wieder gut
Und Stichwort BYOD → da würd ich mir zweimal überlegen, ob ich solche
potentiell verseuchten Geräte in ein mit WPA/2/3-Enterprise
abgesichertes Netz aufnehme, wo evtl. sensible Daten liegen, oder die
doch lieber in einem Gast-Netz mit CaptivePortal unterbringe
deswegen habe ich WPA2 enterprise im Blauen Netz und nicht in Grün.
Bei iOS-Geräten musste man das Serverzertifikat schon immer akzeptieren, unabhängig aus welcher CA es stammte. Bei Android (ich spreche von Android 13 Patchstand 6.Februar 2023) gibt es jetzt diese Möglichkeit auch, sofern der RADIUS auch das CA-Zertifikat mit ausliefert. Auch bei Windows musste man zustimmen.
Das Problem lag/liegt bei den Androids, die diese Option noch nicht haben. Hier musste man das CA-Zertifikat händisch einspielen und den Benutzern die Konfiguration für den wpa-supplicant mitteilen. Das war sehr umständlich.
ich habe nun Eure Hinweise und Anleitungen (Erstellung eines eigenen Radius-Zertifikat mit der Ca von linuxmuster.net sowie der Einbindung der Zertifikate in Freeradius) in der Doku aufgenommen (Netzwerkzugriff über Radius — linuxmuster.net 7.1 Dokumentation). Kontrolliert bitte nochmal, ob das alles so stimmt.
@nosch Welche Firewall-Einstellungen hast Du denn zusätzlich benötigt ? Erklärungen und Screenshots wären hier hilfreich.
Ich hatte für mich die komplette Einrichtung eines „blauen Netzes“ mit DHCP-Server auf der OPNSense so dokumentiert:
Ein blaues Netz für das Schüler-WLAN einrichten:
Zunächst muss für das blaue Netz ein in allen Switches ein VLAN (hier als Beispiel 10) erstellt und getaggt auf die notwendigen Ports gelegt werden.
Ziel ist es nun auf diesem VLAN ein Netzwerk zu erstellen, das von der OPNSense per DHCP verwaltet wird und von dem aus Zugriff ins Internet, aber kein Zugriff ins grüne Netz möglich ist bzw. nur die WebUI erreichbar ist.
Dazu sind zunächst, falls noch nicht geschehen ein paar Anpassungen im Proxmox, auf dem die OPNSense läuft zu machen:
Und zum Schluss noch die Firewallregeln anlegen. Dazu muss zunächst ein Alias mit den privaten Netzen angelegt werden, die nicht von blau erreichbar sein sollen:
Die Reihenfolge der Regeln ist entscheidend - siehe verlinktes Video weiter unten! Die unterste Regel erlaubt den Zugriff aus blau überall hin - die darüber liegende Regel schränkt dies aber ein und verbietet alles in die privaten Netze. Darüber kommen zwei Ausnahmen für die WebUI und DNS-Anfragen.
Mein Vorgehen zum Einrichten des blauen Netzes entspricht dieser Anleitung:
Und für die Firewall-Regeln diesem schönen Video:
Soll ich noch Bilder der einzelnen Firewall-Regeln erstellen?
Viele Grüße!
Noah
Wäre es dann nicht einfacher beide Regeln zusammenzufassen, indem man nur bei der letzten Regel die Destination auf „NICHT Alias PrivateNetze“ festlegt? Die Regel davor könnte eingespart werden, weil das dann wieder durch die unsichtbare deny-all-Regel am Ende erfasst wäre.
