Sicheres WLAN

zuglufttier

Well-Known Member
Ahoi,

mich plagt da ein Problem! Und zwar betreut man ja hier und da WLANs, ob man nun will oder nicht :D

Auf alle Fälle gibt's da mehrere Netze, die auch öfter mal kurzzeitig neue Clients bekommen. Bisher war die Handhabung so alles über einen WPA2-Schlüssel zu sichern was ja gut klappt und auch sicher ist, sofern der Schlüssel nicht bekannt wird. Das ist nun jedoch durchgesickert, sprich: Jemand hat's einfach ausgeplaudert.

Wie auch immer, ich habe mir nun überlegt pfSense zu nehmen und mit Static ARP und DHCP zu arbeiten, so dass alle Clients nur im Netzwerk arbeiten können, wenn MAC- und IP-Adresse übereinstimmen. Das hätte ja auch noch zur Folge, dass man endlich mal alle Clients schön übersichtlich in einer Liste hätte. Neue Clients müssen dann relativ aufwendig eingepflegt werden. Die Access Points sollen dann ohne Verschlüsselung laufen, so dass die Arbeit an den Clients entfällt. Die müssen einfach nur das neue Netz auswählen und es braucht keinen Schlüssel. Authentifizieren soll man sich dann noch per RADIUS mit Anbindung an eine Windows-Domäne. Klappt auch alles soweit!

Nur: MAC Spoofing geht mir zu einfach. Einfach mit einem AP verbinden, wireshark etc. laufen lassen und nach fünf Minuten spätestens hat man IP und MAC eines gültigen Rechners. Es geht mir jetzt hauptsächlich darum den Einsatz privater Geräte zu unterbinden, denn die entsprechenden Leute haben ja auch schließlich gültige Daten für die Authentifizierung.

Habt ihr da noch ne Idee wie man das System verbessern könnte? Den Zugriff auf die Access Points mit WPA2 zu verschlüsseln halte ich für wenig sinnvoll, da das Passwort wieder durchsickern könnte und der Aufwand wieder ansteigen würde.
 
Es hilft alles nix. Wenn du einen hast, der ausplaudert, dann ist das Netz kompromittiert. Er kann auch vpn-Schlüssel und Logindaten weitergeben.
 
wenn jemand sein vpn-zertifikat weitergibt, dann hast du ihn dran und kannst ihn sperren.

wenn jemand wirklich jemand anderes in ein netz lassen will, dann findet er immer einen weg. da hilft nur, denjenigen ebenfalls auszuschließen.
 
Es reicht ja, wenn man einige Hürden setzt, so dass 95% aller Angriffe ins Leere gehen. Dann geben die allermeisten ja auf und es wird echte kriminelle Energie benötigt. Das ist dann was anderes als eben einen bekannten Schlüssel eingeben.

Aber habt ihr auch eine Idee wie es laufen könnte, ohne dass die Clients speziell angepasst werden müssen? Die ollen Zertifikate kann man unter Windows z.B. so ohne Probleme einfach exportieren und auf ein anderes Gerät installieren.
 
Mit RADIUS hast du doch für jeden Client ne eigene Authentifizierung, oder? Damit kannst du dann rausfinden, wer Mist gebaut hat und ihn abmahnen. Bei wiederholung: aussperren. Dürfte doch reichen, oder?
 
Nicht wirklich. Mal angenommen, man nähme eine bestehende Kombination aus IP- und MAC-Adresse und übertrüge diese auf ein anderes Gerät (ist ja mehr oder weniger problemlos möglich), dann würde ich ja nicht merken welches Gerät nun läuft, die RADIUS-Authentifizierung würde klappen und lediglich der eine Client hätte keinen Netzwerkzugriff. Und wenn dieser eine Client nun gerade ein wenig benutzter Laptop ist, der sein Dasein in einem Schrank fristet, dann fiele das noch nicht mal großartig auf. Aber gut, mal angenommen, man bemerkt diesen Fehler, dann könnte man nachsehen wer sich zu dem Zeitpunkt angemeldet hat.

Ich frage mich nun, bringt es mir einen entscheidenden Vorteil, wenn ich die Verbindung zwischen Client und Access Point nun noch zusätzlich verschlüssele? Oder anders gefragt, haltet ihr die Zugangsbeschränkung durch die statischen ARP-Einträge für sicher oder würdet ihr das eher als fahrlässig einstufen?

PS: Mit arpwatch lässt sich ja überprüfen, ob die Kombi aus MAC und IP geändert wurde, jedoch gilt das nur, wenn der Client sich vorher noch nicht im Netz angemeldet hat.
 
Bei RADIUS muss man doch user+pw eingeben, oder? gib einfach jedem einen eigenen user und du kannst ihm auf die finger hauen!

WLAN würde ich immer verschlüsseln. Sonst sind passworte und inhalte, die nicht durch HTTPS oder SSH geschützt sind, von jedem deppen auslesbar.
 
Richtig, die müssten Benutzernamen und Passwort eingeben.

Hmm... Ich habe ein Captive Portal in meiner Testumgebung laufen, welches sich auch über https ansprechen ließe. Das muss ich mal konfigurieren und gucken, ob dann die Verbindung ins Web komplett verschlüsselt läuft. Die gehen so oder so noch über einen transparenten Proxy.

Edit: Das Captive Portal über https bewirkt nur, dass dort der Benutzername sowie das Passwort verschlüsselt übertragen werden was aber ja auch nicht weg ist.
 
Zuletzt bearbeitet:
EAP-TTLS wäre eine Option welche du mit dem RADIUS verknüpfen kannst.
Ansonsten musst du evt. dein Konzept noch weiter ausbauen.

- zusätzliches Gäse-WLAN, unverschlüsselt, mit Firewall/Proxy beschränkt
- VPN Clients ausrollen (deutlich höherer Aufwand)
- gleichzeitige Logins einer ID unterbinden
- pro ID nur eine MAC zulassen

Wenn du davon ausgehst dass du auf den Clients keinen EAP-TTLS Supplicant haben wirst, und auch sonst nichts verändern kannst, bleibt nur noch die Option mit Proxys und Captive Portalen zu arbeiten.

Brauchst du tatsächliche Sicherheit nach bestem Wissen und Gewissen - oder brauchst du eine rechtliche Absicherung? Also eine pro forma Hürde um kriminelle Energie provozieren zu müssen
 
Ne rechtliche Absicherung wäre nicht schlecht aber letztlich nicht unbedingt notwendig. Es geht mir darum, dass das Netz sicher ist und ich "normale" Angriffe ausschließen kann.
 
Moin!

Nimm EAP-TLS. Da hast Du Zertifikate (die Du natürlich auf jedem Client installieren [lassen] musst), die du gegebenenfalls auch revoken, also sperren kannst.

So kannst Du Dir recht einfach eine eigene Zertifkat-Hierarchie aufbauen, mit der Du nur Leute reinlässt, denen du das auch gestattest. Mit hostapd und freeradius ist sowas recht einfach aufzusetzen.

Du bekommst damit skalierbare Sicherheit (man kann die Schlüsselgrößen einstellen) und ausplaudern kann dann auch keiner mehr Dein Passwort.

Eine andere Möglichkeit wäre es, regelmäßig Dein Passwort zu ändern (was Du ohnehin tun solltest bei einem PSK-gesicherten Netz). Vollkommen inakzeptabel ist ein offenes WLAN mit VPN, denn Dein WLAN bleibt immer offen für Angriffe. Davon möchte ich doch ernsthaft abraten.

HTH,
Herakles
 
Die Änderung der Passwörter auf den Clients ist mehr oder weniger die Grundlage warum die gesamte Struktur geändert werden soll. Mach das mal eben auf 50 oder 100 Rechnern. Wären es deutlich weniger, würde ich gar nicht großartig nachdenken. Es sind ebenfalls so an die 15 Access Points im Gebäude verteilt. Das hätte man von Anfang an anders konzipieren müssen. Nun ja, wenn's denn schnell gehen soll :D

Ich werde wohl die APs als Client beim Radius Server von Windows 2003 (der läuft sowieso schon) einstellen. Alle Rechner mit WLAN-Zugriff sollen dann noch ein Zertifikat bekommen. Hmm, muss ich nur eben herausfinden wie man ein Zertifikat erstellt, welches nur für einen einzelnen Computer gilt.

Zusätzlich kommt dann noch eine Kiste mit pfSense ins Netz, die mit statischen ARP-Einträgen arbeitet, so dass der Spaß am WLAN recht schnell vergangen sein sollte.

PS: Das komplett offene WLAN hat wirklich nichts, wenn man ein bisschen drüber nachdenkt.
 
Zuletzt bearbeitet:
Also ich habe hier hostapd am Laufen mit normalem WPA2. Jedes Gerät (WLAN Adapter) bekommt einen eigenen Schlüssel, der gebunden an eine MAC ist.

Da brauche ich kein Radius und jeder hat trotzdem einen anderen Schlüssel. Die Leute können sich gerne eine MAC-Adresse teilen, wenn sie wollen (hihi!) aber wenn sie anfangen Unfug im Netz zu machen, dann sehe ich ja auch WER schuld ist und kann ihn direkt ausschließen.
 
Weils gerade hier reinpasst :)
Soweit ich weiß kann man sich client-seitig via if-alias ja zu mehreren WLANs verbinden. Kann man auf die gleiche Weise server-seitig auch mehrere APs über ein physisches Interface laufen lassen oder gibt das die Hardware gar nicht her?
Hintergrund ist eigentlich die Trennung der via WPA/EAP-TLS verbundenen Systeme in Klassen (hier ebene Netze) zur besseren Kontrolle (Resourcen/Autorisierung).

Und: Kann sich via Radius eigentlich ein Benutzer mehrmals anmelden? In der Konfiguration von freeradius habe ich da nichts gefunden.

Als passende freie CA kann ich neben der etwas fummligen OpenCA die umfangreichere EJBCA empfehlen. Ja, ich weiß, Java :p
 
Hoi,

Du packst die digitalen Zertifikate des Clients oifach uf en eTokenbär. D.h. der Client User hat garkoi Möglichkeit dieses Zertifikat korrekt weiterzugeben, da Du ja auch die Seriennummer des Tokens noch hast als Kriterium. Natürlich könnte er mittels PIN den privaten Key ebenfalls exportieren; Die Seriennummer des eTokens fälschen kann er jedoch so einfach erstmal nicht. Parallel dazu verbietest Du in der Konfiguration das Anmelden des Users von mehr als einem Client gleichzeitig. Den eToken als USB z.B. kann er jedoch jederzeit an ein anderes Gerät stöpseln - ist also nicht direkt an nur eine Maschine allein gebunden. Mit Smartcards als Speicher ging das bärig natürlich ebenfalls. Voraussetzung das des sicher funktioniert ist natürlich das Du die Serial von dem eToken / der Smartcard auch kennst und auswerten kannst bei der AUTH.

Gruß Bummibär
 
Hoi,

wir benutzen die von A..... unter FreeBSD. Werbung machen is ned so gut abär ich tät mal "etoken freebsd" als Beispiel in Googlebär jagen :)

Gruß Bummibär
 
Die Änderung der Passwörter auf den Clients ist mehr oder weniger die Grundlage warum die gesamte Struktur geändert werden soll. Mach das mal eben auf 50 oder 100 Rechnern. Wären es deutlich weniger, würde ich gar nicht großartig nachdenken. Es sind ebenfalls so an die 15 Access Points im Gebäude verteilt. Das hätte man von Anfang an anders konzipieren müssen. Nun ja, wenn's denn schnell gehen soll :D

Ich werde wohl die APs als Client beim Radius Server von Windows 2003 (der läuft sowieso schon) einstellen. Alle Rechner mit WLAN-Zugriff sollen dann noch ein Zertifikat bekommen. Hmm, muss ich nur eben herausfinden wie man ein Zertifikat erstellt, welches nur für einen einzelnen Computer gilt.

Zusätzlich kommt dann noch eine Kiste mit pfSense ins Netz, die mit statischen ARP-Einträgen arbeitet, so dass der Spaß am WLAN recht schnell vergangen sein sollte.

PS: Das komplett offene WLAN hat wirklich nichts, wenn man ein bisschen drüber nachdenkt.

EAP-TLS (ist wohl sehr sicher)
Das geht mit free radius. Ich habe mit dem Autor des Heise Artikels bereits kommuniziert.

Leider ist die Freeradius Dokumentation ein bisschen "strubbelig". Ist das ein französisches Produkt? Die Wiki und Doku passt nach meinem Tests der letzten Tage nicht richtig mit dem zusammen, was ich gerade so teste.

EAP-TSL, OK (aber anders als in der Doku)
EAP-TLS MSCHAP2 (OK, aber geht auch anders)

Aber simples authentifizieren gegen die passwd (module passwd) geht nicht.
Kein Ahnung warum. Ich will das gar nicht einsetzen, nur das Prinzip testen. Es geht einfach nicht.

Meine Plattform OpenBDS 4.8 stable (eigenes ISO) und den dazu passenden freeradius 2.1.9. Die Installation auf 1GB Flash Medien (ALIX) oder einem Virtual PC dauert ca, 10 Minuten. Prima zum testen.

Wenn Du individuelle Zertifikate erzeugen willst.
Leg für jeden user ein client.cnf an.

Editieren make client. Pass die individuellen Daten an.
cp client.cnf client.username.cnf
dann make client

Dann ca.cer und client.der auf den jeweiligen client kopiern und wie im Heise Artikel beshriebn importieren.

Ich sollte wohl mal eine WIKI dazu schreiben.

Im Windows Client dann Smart Card oder anderes Zertifikate unter WPA2-Enterprise konfigurieren.

man openssl oder die open ssl Wiki hilft bei Setup der Client Zertifikate.
Kurze Gültigkeit. Zurückrollen, usw...

Leider habe ich wenig Zeit für weitere Test und Experiment und den WIKI.

Zusätzlich ein Captive Portal mit m0n0wall oder pfsense, da muss sich der Anwender dann mit User/Pw (z.B. auch auch gegen den Radius Server) authentifizieren.
Das geht dann auch ohne Radius dafür mit VOUCHERS ;->

Gruss

F41THR :huth:

P.S: Voluntäre für ein OpenBSD basierten m0n0wall fork gesucht. Da ich kein php kann würde ich bash scripte nehmen :ugly: Und ASCII statt xml!
 
Zuletzt bearbeitet:
P.S: Voluntäre für ein OpenBSD basierten m0n0wall fork gesucht. Da ich kein php kann würde ich bash scripte nehmen :ugly: Und ASCII statt xml!

Das hört sich interessant an... Nur was haben php, bash scripte oder xml mit m0n0wall zu tun?
Erzähl mal etwas mehr über deinen geplanten fork.
 
OpenBSD 4.8 freeradius-2.1.9

Für alle die den Heise Artikel "WLAN sichern mit Radius" als Grundlage nehmen.

Unter OpenBSD 4.8 und freeradius-2.1.9 aus den ports funktioniert es nur,
wenn in /etc/raddb/users hinter User und Passwort den Authentifizierungs Typ = EAP angegeben wird.

Code:
.... rest gekürzt ...
# On no match, the user is denied access.
"test" Cleartext-Password := "password", Auth-type := EAP

F41THR :huth:
 
Zuletzt bearbeitet:
Zurück
Oben