Hallo Forum,
wir Kollegen, und ich, diskutieren gerade wie man das WLAN gegen Angriffe sicher macht.
Wie macht Ihr das?
Beispiel:
Allen ist der Preshared Key bekannt. Damit ist es offenbar nicht schwer Passwörter zu sniffen.
Was tut man dagegen?
Gruß
Alois
Hallo Alois,
was tut man dagegen?
Kein PSK verwenden, statt dessen Radius-Authentisierung WPA2-Enterprise einsetzen.
Viele Grüße
Thomas
Hallo Alois,
was evtl. auch helfen könnte, ist AP Client Isolation /P2P Blocking.
vG Stephan
Hallo Stephan,
Das wird bei UNIFI automatisch gemacht, wenn man den Haken bei Gastrichtlinien setzt.
Gruß Alois
Hallo Thomas,
Das ist bei uns prinzipiell gemacht. Wir brauchen aber für die Ausleihe von Laptops eine Möglichkeit des Login der nach Ablauf einer Zeit automatisch endet.
In ein Leihgerät die Benutzerdaten - wie bei WPA Enterprise - eintragen ist m.E. nicht die erste Wahl, weil es schnell Mal vergessen geht die Daten wieder zu löschen.
Gruß Alois
Hallo Forum,
bei meiner Recherche habe ich das gefunden:
https://www.globalsign.com/de-de/blog/ssl-tls-fuer-interne-server/
Gruß
Alois
Hallo Alois,
da würde ich das mit Computerzertifikaten machen.
Du erstellt über eine CA z.B. auf der openSense die Clientzertifikate, schiebst die Clientzertifikate auf die dazugehörigen Rechner und lässt Radius prüfen, ob die Zertifikate gültig sind. Bei Erfolg WLAN sonst nix.
Läuft das Zertifikat ab, ebenfalls nichts mehr mit WLAN.
Du kannst ja bei Erstellung des Zertifikats festlegen, wie lange es gültig sein soll, oder im Bedarfsfall das Zertifikat zurück ziehen. Hab ich an einigen Schulen schon so gemacht.
Gruß
Thomas
geht das bei Lets encrypt?
VG, Tobias
Hallo Tobias,
mir ist nicht bekannt, das LetsEncrypt SubCAs bereitstellt. Also eine Zwischenzertifizierungsstelle, die eigene Zertifikate ausstellen kann. LetsEncrypt ist ja auch “nur” eine SubCa. Soweit mir bekannt ist, kann man über LetsEncrypt bislang nur Single-Server und Wildcards beantragen.
Ist für das Prinzip, das hier zur Anwendung kommt aber so auch nicht erforderlich. Du hast ja ohnehin die Herrschaft über die Zertifizierungsstelle. Da du das Clientzertifikat auf den Rechner pushen musst, kannst du in einem weiteren Schritt auch das Zertifikat das CA importieren. Da die Gegenstelle also der Radius, ebenfalls auf dieser (der gleichen, auch hier muss man sie importieren) CA prüft, muss jemand schon Zugriff auf deine CA haben, um mit einem anderen Zertifikat ins WLAN zu kommen. Und wenn jemand anderes auf deine CA Zugriff hat, denke ich, dass du in deinem Netzwerk ein zumindest mittelschweres Sicherheitsproblem hast.
Sagen wir es so: Das Einzige was du nicht machen müsstest, wenn dir LetsEncrypt eine SubCa bereitstellen würde: Du müsstest nicht auch noch das Zertifikat der CA importieren.
Viele Grüße
Thomas
Hallo Thomas,
danke. Hatte deinen Satz
nicht so verstanden, dass du selbst die CA haben/sein musst. Dachte es geht nur um die Erstellung der Zertifikate, was lets encrypt für SSL ja kann. Aber ich hätte es auch an dem halbsatz “im Bedarfsfall das Zertifika zurückziehen” verstehen sollen.
Jetzt verstehe ich: Ich bin die CA (mit openssl), erstelle Clientzertifikate für die PCs, zertifiziere diese mit Hilfe der CA-Zert., importiere die CA-Zert. in Radius und Client, benutze vom Client aus das Client-Zertifikat zur Authentifizierung gegenüber dem Radius. Klingt alles ziemlich logisch.
Irgendjemandem fällt sicher irgendwann ein Szenario ein, bei dem das nicht geht oder zu umständlich ist (z.B: BYOD für Lehrer, deren CA-Import ich nicht supporten will… oder ähnliches).
Herzlichen Dank für die Idee, könnte man doch automatisiert bereitstellen (feature-request an, hm, sophomorix).
LG, Tobias
Hallo Tobias,
das Verfahren eignet sich gut für den von Alois beschrieben Anwendungsfall mit den Geräten für eine Ausleihe. Also, wenn schuleigene Geräte verliehen werden.
Bei den BYOD Geräten würde ich beim Radius mit Benutzname und Kennwort bleiben.
In dem Fall könnte man z.B. zwei SSIDs machen.
Die Zertifikatsbasierte könnte man zusätzlich noch verstecken. Mit dieser können sich ja ohnehin nur Geräte verbinden, die ein entsprechendes Clientzertifikat haben.
Mit der BYOD SSID für Lehrer können sich nur Benutzer aus der AD Gruppe Lehrer verbinden usw.
So kann man schon Mal abfangen, wer und welche Geräte überhaupt WLAN nutzen können, ohne daß man einen PSK für den Zugang braucht.
Der Rest, also welches Netz dahintersteckt und wer dann wohin darf, ist dann wieder Firewall und Co. Hat aber mit dem eigentlichen Zugang aufs WLAN gar nichts mehr zu tun.
Viele Grüße
Thomas
Hallo Tobias,
noch ne Idee, vielleicht beim import_workstations gleich so ein Clientzertifikat erstellen (Evtl zusätzlicher Punkt WLAN Gerät ja/nein).
Dann kann man das Verfahren sofort für alle Schulnetzgeräte (Notebooks) nutzen. Die CA könnte man evtl über Postsync importieren oder OPSI und das WLAN Profil per GPO…
Hi Thomas,
das stimmt schon. Wie macht ihr (ich meine alle 
) es dann mit dem “tracking” von usern. Also ihr wisst, was ich meine: das nach der Schulordnung abgestimmte Verfahren, demnach ich im Bedarfsfall nachschauen kann (z.B. unter 4-Augen) wer hier den schindluder getrieben hat? ([OT] ist schindluder eigentlich ein politisch korrektes Wort? Mir kommt es jetzt so vor, als ob da im Mittelalter gewisse Berufsgruppen diskriminiert worden sind und das besser nicht mehr verwendet werden sollte…[/OT])
Ich muss jetzt entweder noch ein Portal nachschalten, oder einen Proxy für diese Geräte aktivieren, während ich für die WLAN-Radius-Geräte ja nachvollziehen kann welche IP/MAC was getrieben hat.
VG, Tobias
Tag Thomas,
Seit letztem Jahr laeuft Let’s Encrypt unter Root-CA, de bisherige Quersgnierung von IdenTrust ist also nicht mehr notwendig.
Gruss Harry
Hallo Harry,
und warum ist das so? Weil LetsEncrypt eine vertrauenswürdige SubCA von DST ist. Prüf mal die Zertifikatskette.
Spielt aber keine Rolle für die beschriebenen Anwendungsfälle.
Gruß
Thomas
Hallo Tobias,
ich such immer noch nach einer anderen Methode, aber nach wie vor ist Proxy die Wahl der Wale.
Gruß
Thomas