Hallo, ich muss bald ein paar WLAN-Accesspoints an Stellen montieren, die nicht wirklich gesichert sind. Also sowohl die Accesspoints, als auch die Kabel dahin, liegen im quasi öffentlichen Bereich und könnten damit manipuliert werden. Das WLAN ist auf der Funkstrecke mit WPA2-EAP gesichert, das sollte also passen. Ich möchte nicht, daß die Daten auf den ungesicherten Accesspoints entschlüsselt werden, denn dort könnten sie nach einer Manipulation des Accesspoints abgehört oder verändert werden. Daher würde ich gerne die für die Funkstrecke verschlüsselten Daten so wie sie sind in IP-Pakete packen/tunneln und sie dann zu einem ordentlich gesicherten Server schicken, auf dem dann die WPA2 Ver- und Entschlüsselung stattfindet. Kennt jemand eine Lösung die sowas kann?
Gerd E. schrieb: > Kennt jemand eine Lösung die sowas kann? einfach IPsec auf den Accesspoint machen.
Mit einer Fortigate als AP Controller. Die Accesspoints erstellen einen SSL (oder war es IPSec) Tunnel zum Controller.
Wäre WPA2-Enterprise (mit Radius-Server) eine Alternative? So etwas verwenden wir mit den Unifi-APs von UBNT. Wenn der AP wegkommen sollte, kein Problem für die Sicherheit.
Franz Mayer schrieb: > Wäre WPA2-Enterprise (mit Radius-Server) eine Alternative? > > So etwas verwenden wir mit den Unifi-APs von UBNT. Wenn der AP wegkommen > sollte, kein Problem für die Sicherheit. meines wissen übernimmt der AP aber immer noch die Entschlüsselung. Damit ist es auf der Leitung wieder unverschlüsselt.
Peter II schrieb: > einfach IPsec auf den Accesspoint machen. Diese Lösung würde mir helfen, wenn der Accesspoint gesichert wäre und nur die Kabel dorthin nicht. Leider sind die für die WLAN-Abdeckung nötigen Positionen nicht so leicht sicherbar. Der Angreifer manipuliert den Accesspoints, z.B. per JTAG. Dann kann er ein Programm als root auf dem AP laufen lassen welches alle Daten vor dem IPSec abgreift oder verändert. Das hilft mir also leider nichts.
Franz Mayer schrieb: > Wäre WPA2-Enterprise (mit Radius-Server) eine Alternative? Das wird schon eingesetzt. Doch damit ist nur die Authentifizierung am Anfang der Verbindung geschützt, der Angreifer kann also nicht die Passwörter der User klauen. Die eigentliche Verbindung wird aber weiterhin auf dem Accesspoint entschlüsselt und kann dort abgegriffen/manipuliert werden.
Hi, wieso lässt du dann nicht einfach alle Clients per VPN durch das Wlan zu einem zentralem Server verbinden. Dann ist die Verbindung immer gesichert, egal wer was auf dem AP macht, und du hast einen "definierten" Austrittspunkt, wo der Datenverkehr herkommt. Alle "normalen" Anfragen kannst du ja dann im Netzwerkrouting einfach verwerfen, damit niemand ohne den passenden VPN-Tunnel irgendwo hin kommt.
Guest schrieb: > Mit einer Fortigate als AP Controller. Die Accesspoints erstellen einen > SSL (oder war es IPSec) Tunnel zum Controller. Danke für den Hinweis. Ich hab mich mal eben ein wenig bei Fortinet umgeschaut, aber leider keinen Hinweis dazu gefunden, daß die Daten tatsächlich erst auf dem zentralen Server entschlüsselt werden. Die haben ein zentrales Management-System und die Verbindung damit ist verschlüsselt. Aber ich habe nirgends sehen können, daß die Daten auf dem AP gar nicht entschlüsselt werden. Hast Du da vielleicht noch mehr Infos zu, z.B. ein Whitepaper oder sowas von denen?
Marcus P. schrieb: > wieso lässt du dann nicht einfach alle Clients per VPN durch das Wlan zu > einem zentralem Server verbinden. Daran hatte ich auch schon gedacht. Leider macht das die Sache nicht einfacher, da so einige, vor allem Embedded-, Geräte kein VPN können. Schon WPA2-Enterprise schränkt die Auswahl an Geräten merklich ein und das führt zu einigem Gemecker von den Usern. Wenn ich jetzt noch VPN fordere, fürchte ich daß ich das nicht durchkriege weil dann zu viele Geräte weggeworfen werden müssen.
Gerd E. schrieb: >> wieso lässt du dann nicht einfach alle Clients per VPN durch das Wlan zu >> einem zentralem Server verbinden. > > Daran hatte ich auch schon gedacht. Leider macht das die Sache nicht > einfacher, da so einige, vor allem Embedded-, Geräte kein VPN können. > > Schon WPA2-Enterprise schränkt die Auswahl an Geräten merklich ein und > das führt zu einigem Gemecker von den Usern. Wenn ich jetzt noch VPN > fordere, fürchte ich daß ich das nicht durchkriege weil dann zu viele > Geräte weggeworfen werden müssen. und nur VPN? also WPA komplett weglassen und einwahl per VPN. Eigentlich sollte das die meisten Geräte können. (Android, Apple)
Peter II schrieb: > und nur VPN? also WPA komplett weglassen und einwahl per VPN. Eigentlich > sollte das die meisten Geräte können. (Android, Apple) Wenn es nur um Smartphones ginge wäre das ja alles kein Thema. Selbst Windows Phone hat es jetzt ja nach einigen Anläufen auch geschafft WPA2-Enterprise anzubieten. Doch es geht auch um mobile Messgeräte, Kameras, Barcodescanner, Datenerfassungsgeräte,... Und da ist die Auswahl an Anbietern und Modellen nicht so breit, meist gibt es nur ein oder 2 die von den restlichen Daten her passen.
:
Bearbeitet durch User
https://www.lancom-systems.de/fileadmin/pdfs/Manuals/LANCOM-WLC-MANUAL-DE.pdf Seite 5: Remote-MAC: Hier werden alle WLAN-Funktionen vom Access Point an den WLAN-Controller übertragen. Die Access Points dienen hier nur als "verlängerte Antennen" ohne eigene Intelligenz wo jetzt die Entschlüsselung stattfindet, konnte ich auf die schnell nicht finden.
Peter II schrieb: > https://www.lancom-systems.de/fileadmin/pdfs/Manuals/LANCOM-WLC-MANUAL-DE.pdf Leider wieder nix: > Local-MAC: Die dritte Möglichkeit sieht eine vollständige Verwaltung und > Überwachung des WLAN-Datenverkehrs direkt in den Access Points vor. > Zwischen dem Access Point und dem WLAN-Controller werden lediglich > Nachrichten zur Sicherung einer einheitlichen Konfiguration der Access > Points und zum Management des Netzwerks ausgetauscht. > Die Smart-Controller-Technologie von LANCOM Systems setzt das Local- > MAC-Verfahren ein. Aber dennoch hilft mir Dein Tip weiter: bisher kannte ich bei CAPWAP nur diese Local-MAC-Variante. Daß es im CAPWAP-Standard auch das Remote-MAC gibt ist mir neu. Da werde ich also mit diesen Stichworten mal weiter forschen. Vielen Dank.
Wow, vor genau 2 Wochen wurde ein RFC veröffentlicht, welches genau mein Problem behandelt und beschreibt wie man herstellerübergreifend die Verschlüsselung zentral im Accesspoint Controller (AC) macht: https://tools.ietf.org/html/rfc7494 Ich fürchte da wird es mit real funktionierenden Implementationen noch nicht weit sein. Vielleicht gibt es aber ja schon irgendwo was proprietäres, mal schauen.
Die Anforderung ist tatsächlich etwas kompliziert. Mit hoher Warscheinlichkeit musst du eine properitäre Technik vom Hersteller übernehmen. Bis die RF7494 umgesetzt ist, gehen sicher locker noch 6-7 Monate den Bach runter. Aruba kann sowas zum Beispiel: http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/Remote_AP.php Mit den drei genannten Deployment-Szenarien solle das wohl deinen Fall abdecken. Aber ich will dich gewarnt haben: Aruba ist nich gerade billig, aber bietet dafür eine nahezu jedes erdenkliche Feature an.
Ich bin mir gar nicht sicher ob das mit der Remote-MAC am ende ordentlich funktioniert. Der MAC-Teil kümmert sich auch um die Funk-Verteilung (wer wann senden darf). Wenn dieser Teil entfernt sitzt, dann kommen unweigerlich latenzen hinzu. Damit dürfte die Maximale Geschwindigkeit recht stark abfallen. Der Vorteil ist natürlich, das der AP recht dumm sein darf und man den Rest einfach in Software laufen laufenlassen kann. Es gab mal vor eine Weile die Idee Antennen direkt mit Glasfaser anzusteuern, also auf dem Glas das Analog-Modellierte Signal zu haben, eventuell gibt es da ja etwas brauchbares.
abcd schrieb: > Aruba kann sowas zum Beispiel: > http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/Remote_AP.php > > Mit den drei genannten Deployment-Szenarien solle das wohl deinen Fall > abdecken. Danke. Bei diesen Deployment-Szenarien scheint es aber auch eher um die Sicherung der Verbindung zwischen AP und Controller zu gehen, z.B. per IPSec. Aber ich hab jetzt mal bei denen angefragt ob die das können. > Aber ich will dich gewarnt haben: Aruba ist nich gerade billig, aber > bietet dafür eine nahezu jedes erdenkliche Feature an. Naja, besser eine teure Lösung die funktioniert als gar keine oder eine die ständig Ärger macht.
Peter II schrieb: > Ich bin mir gar nicht sicher ob das mit der Remote-MAC am ende > ordentlich funktioniert. Der MAC-Teil kümmert sich auch um die > Funk-Verteilung (wer wann senden darf). Wenn dieser Teil entfernt sitzt, > dann kommen unweigerlich latenzen hinzu. Damit dürfte die Maximale > Geschwindigkeit recht stark abfallen. Ja, da hast Du recht. Soweit ich bisher rausgefunden habe wird das Remote-MAC daher in der Praxis auch kaum verwendet. Bei Split-MAC werden dagegen die zeitkritischen Funktionen (wie z.B. ACKs versenden, Aufteilung der Bandbreite etc.) lokal auf dem AP gemacht. An den zentralen Controller werden dagegen nicht so zeitkritische Dinge übergeben. Und dort kann man auch die Verschlüsselung machen. Die oben verlinkte RFC beschreibt das schön. Daher ist denke ich das Split-MAC die richtige Variante für mein Problem.
Wo passiert bei WPA/WPA2 eigentlich die Verschlüsselung? Soweit ich auf die Schnelle herausgooglen konnte, ist Hardwaresupport nicht unbedingt notwendig. Angenommen, ma würde WLAN-USB-Sticks über USB2LAN Adapter abgesetzt betreiben, würde das deinen Anwendungsfall abdecken? ;) (Bitte nicht wirklich ernst nehmen, ich weiß, dass so ein Konstrukt im professionellen Umfeld nichts zu suchen hat, aber evtl gibt es dadurch weitere Denkanstöße) Wie schützenswert sind die Daten tatsächlich, so dass sich der Aufand lohnt? Deine Bedenken bzgl. JTAG kann ich verstehen, da ich sowas ähnliches als Machbarkeitsstudie schon mal gemacht habe. Das Teil wurde dabei aber resetted. Evtl könnte man einen IDS Alarm auslösen, wenn die LAN-Verbindung gekappt wird. (es wäre aber dann immer noch denkbar, dass im laufenden Betrieb per JTAG o.ä. das OS des APs manipuliert wird) Vermutlich ist es einfacher, die WPA-Verschlüsselung direkt anzugreifen. Gruß Roland
Roland Praml schrieb: > Wo passiert bei WPA/WPA2 eigentlich die Verschlüsselung? früher in der Hardware des WLAN-ICs. Heute macht das normal der Treiber des Betriebssytems. > Angenommen, ma würde WLAN-USB-Sticks über USB2LAN Adapter abgesetzt > betreiben, würde das deinen Anwendungsfall abdecken? ;) ja, wenn man das Timing hinkriegt könnte das wohl gehen. Wenn man das wirklich machen will, müsste man wohl den Treiber umstricken daß er die verschlüsselten Pakete rausgibt und die dann an eine spezielle Software weitergeben. Aber ohne ein Standardprotokoll um das weiterzugeben und zu verarbeiten etc. ist man da halt allein auf weiter Flur. > Wie schützenswert sind die Daten tatsächlich, so dass sich der Aufand > lohnt? Unentdeckte Manipulation von Daten auf die per WLAN zugegriffen wird, oder eine hartnäckige, aktive Störung des Netzbetriebs könnte schon sehr deutliche Auswirkungen auf die Firmenfinanzen haben. > Evtl könnte man einen IDS Alarm > auslösen, wenn die LAN-Verbindung gekappt wird. (es wäre aber dann immer > noch denkbar, dass im laufenden Betrieb per JTAG o.ä. das OS des APs > manipuliert wird) Die bisherigen APs werden schon per SNMP überwacht. Wenn sie nicht erreichbar sind oder die Uptime zurückgesetzt wurde bekomme ich eine Warnung. Gibt aber oft Fehlalarm weil irgendwelche Handwerker unterwegs sind oder irgendwo ne Sicherung rausgeflogen ist. > Vermutlich ist es einfacher, die WPA-Verschlüsselung direkt anzugreifen. Mein Stand ist daß das gar nicht so einfach ist, vor allem bei WPA2-Enterprise. Denn da werden ja mit jedem Einloggen wirklich neue Session-Keys (nenn ich jetzt mal so, hab den genauen Fachbegriff nicht im Kopf) erzeugt. Beim WPA2-PSK bleiben die dagegen konstant (erzeugt aus PSK und SSID) und können evtl. mit viel mitgeschnittenem Traffic und bei schlechtem PSK und gängiger SSID geknackt werden.
Gerd E. schrieb: > Mein Stand ist daß das gar nicht so einfach ist, vor allem bei > WPA2-Enterprise. Denn da werden ja mit jedem Einloggen wirklich neue > Session-Keys (nenn ich jetzt mal so, hab den genauen Fachbegriff nicht > im Kopf) erzeugt. und wie sicher sind überhaupt die Endgeräte? Wenn ich dort per jtag die Zugangsdaten auslesen kann, hilft auch der sichererste AP nicht.
Peter II schrieb: > und wie sicher sind überhaupt die Endgeräte? Wenn ich dort per jtag die > Zugangsdaten auslesen kann, hilft auch der sichererste AP nicht. Die Endgeräte sind nur in den Händen von einigermaßen vertrauenswürdigen eigenen Mitarbeitern. Da könnte natürlich auch ein böswilliger darunter sein, das ist aber viel unwahrscheinlicher als bei den ganzen anderen Leuten von Sub-Sub-Sub-Sub-Subunternehmern aus Sonstewo die auf dem Gelände sonst noch rumspringen. Die Endgeräte haben außerdem alle ihre eigenen Passwörter. Wenn die sich eingeloggt haben, bekommen die ne eindeutige IP und ich kann dann auf der Firewall genau regeln wo welches Gerät reindarf und wo nicht.
Gerd E. schrieb: > Die Endgeräte haben außerdem alle ihre eigenen Passwörter. Wenn die sich > eingeloggt haben, bekommen die ne eindeutige IP und ich kann dann auf > der Firewall genau regeln wo welches Gerät reindarf und wo nicht. dabei muss man aber noch sicherstellen, das ein gerät auch seine zugewiesene IP verwendet und nicht eine die etwas mehr darf.
Peter II schrieb: > dabei muss man aber noch sicherstellen, das ein gerät auch seine > zugewiesene IP verwendet und nicht eine die etwas mehr darf. das ist kein Problem: bei der EAP-Authentifizierung prüft der Radius-Server die MAC des Geräts, die muss zum Passwort passen. Die Authentifizierung gilt nur für diese eine MAC, das ist im WPA-Protokoll sichergestellt und wird vom AP automatisch überprüft. Die Firewall ist direkt an das WLAN-Backbone angeschlossen und bekommt damit die Pakete direkt mit der MAC der WLAN-Clients zu sehen. Die Firewall prüft dann, ob diese MAC und IP zusammenpassen. Da sollte es eigentlich keine Möglichkeit geben sich an der Firewall mit den Daten von jemandem anderen vorbeizuschmuggeln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.