Hallo Lancom Entwickler,
wir betreiben als WISP ein "gebridgetes" Datenfunknetzwerk.
Bedingt durch die "Ethernet-Struktur" sind zur Zeit noch folgende Angriffe durch authentifizierte W-LAN Clients möglich:
-> Man-in-the-middle Attacks durch ARP Flooding:
Ein W-LAN Benutzer schafft es durch ARP Flooding, dass die Pakete von anderen Nutzern nicht direkt zum Default Gateway "wandern", sondern über seine MAC. Fällt zwar schnell auf, sollte aber nicht möglich sein.
-> IP Spoofing innerhalb vom Netz:
Ein W-LAN Nutzer deaktiviert den DHCP-Client und vergibt sich einfach fest eine beliebige IP Adresse aus dem Netz.
-> fake DHCP Server:
Ein W-LAN Client ist (meist ungewollt) als DHCP Server konfiguriert; "blockiert" oder "stört" damit unseren DHCP Server und schickt falsche DHCP Zuweisungen raus.
In einem großen Netzwerk mit ein paar hundert W-LAN Clients sind gerade die letzten zwei "Störfälle" nur schwer zu lokalisieren.
Besteht eine Möglichkeit diese Mißbrauchsmöglichkeiten durch entsprechende Konfiguration der APs zu verhindern?
Wäre topp, wenn der AP W-LAN Clients nur einen Netzzugriff mit der zugewiesenen DHCP IP als Source IP ermöglicht und unerwünschte ARP und DHCP Pakete von W-LAN Clients blockt.
ARP spoofing, man in the middle attacks und DHCP discovery
Moderator: Lancom-Systems Moderatoren
Moin,
Was Du beschreibst, sind größtenteils Probleme 'höherer' Protokolle und
daher nicht wirklich Aufgabe einer Bridge, als die ein LANCOM-AP sich
nun einmal grundsätzlich sieht...
untereinander verbietet - der Angreifer kann dann soviel 'flooden', wie er will, die anderen
eingebuchten Clients sehen die Pakete einfach nicht mehr.
daran gekoppelten Filterregeln geben. Man wird sehen, wieviel Rechenleistung das
auf dem AP frißt...und nein, ich kann keinen Release-Termin dafür nennen...
auf absehbare Zeit keine Möglichkeiten. DHCP-Client- von -Server-Paketen zu
unterscheiden erfordert tief in die Pakete hineinzuschauen, und das ist in der LAN-WLAN-
Bridge weder sinnvoll noch machbar.
Gruß Alfred
Was Du beschreibst, sind größtenteils Probleme 'höherer' Protokolle und
daher nicht wirklich Aufgabe einer Bridge, als die ein LANCOM-AP sich
nun einmal grundsätzlich sieht...
Das hört schon in dem Moment auf, in dem man die Kommunikation von WLAN-Clients-> Man-in-the-middle Attacks durch ARP Flooding:
Ein W-LAN Benutzer schafft es durch ARP Flooding, dass die Pakete von anderen Nutzern nicht direkt zum Default Gateway "wandern", sondern über seine MAC. Fällt zwar schnell auf, sollte aber nicht möglich sein.
untereinander verbietet - der Angreifer kann dann soviel 'flooden', wie er will, die anderen
eingebuchten Clients sehen die Pakete einfach nicht mehr.
Ab LCOS 6.10 wird es in der LAN-Bridge eine Protokollierung von DHCP-Clients mit-> IP Spoofing innerhalb vom Netz:
Ein W-LAN Nutzer deaktiviert den DHCP-Client und vergibt sich einfach fest eine beliebige IP Adresse aus dem Netz.
daran gekoppelten Filterregeln geben. Man wird sehen, wieviel Rechenleistung das
auf dem AP frißt...und nein, ich kann keinen Release-Termin dafür nennen...
Da sehe ich über das Unterbinden der Kommunikation von Clients untereinander hinaus-> fake DHCP Server:
Ein W-LAN Client ist (meist ungewollt) als DHCP Server konfiguriert; "blockiert" oder "stört" damit unseren DHCP Server und schickt falsche DHCP Zuweisungen raus.
auf absehbare Zeit keine Möglichkeiten. DHCP-Client- von -Server-Paketen zu
unterscheiden erfordert tief in die Pakete hineinzuschauen, und das ist in der LAN-WLAN-
Bridge weder sinnvoll noch machbar.
Gruß Alfred
Hallo Alfred,
vielen Dank für deine Infos:
Bislang übertragen hier die APs im VLAN für Privatkundenzugänge nur die Protokolle ARP, UDP (67), TCP und UDP (53), TCP(1723) und GRE, welche zur Kommunikation mit dem PPTP Access Server benötigt werden. Die Kommunikation zwischen den W-LAN Clients ist untersagt, da nicht benötigt.
Die oben erwähnten "Angriffsflächen" werden zum Glück selten mißbraucht; aber leider hat die Vergangenheit gezeigt, dass es immer wieder "Spezialisten" gibt, welche gewollt oder ungewollt versuchen das Netz zu stören.
Mit Leps und Radius AAA sollen sich nun zukünftig die Privatkunden mit individuellen WPA Keys direkt in die APs einbuchen können. Sobald korrekt im W-LAN assoziert, erhält der Kunde per DHCP eine offizielle IP zugewiesen und sollte dann natürlich auch über einen unbeschränkten Internetzugang verfügen.
Korrekterweise sollten dann die W-LAN Clients untereinander Daten austauschen können. Durch die Flut der Protokolle und Datenströme ist ein Debugging bei den oben erwähnten Angriffsarten dann kaum mehr sinnvoll möglich.
Daher wäre es aus unserer Sicht sehr wünschenswert, wenn man die von den W-LAN Clients versendeten IP Pakete per erweiterten Protokollfilter wie folgt beschränken könnte:
- Protokoll UDP Port 67: nur DHCP Discover und DHCP Requests übertragen
Die IP aus dem DHCP Offer / ACK sollte der AP in einer Clienttabelle hinterlegen und:
- Protokoll ARP: ARP Replys nur für eigene IP und MAC übertragen.
- generell: Protokollübertragungen nur mit der "vom LAN Interface des AP" zugewiesenen DHCP Adresse als Source-IP übertragen.
Falls es firmwaretechnisch zu komplex wird, die jeweils per DHCP zugewiesene IP Adresse der W-LAN Clients in einer Tabelle abzulegen, würde es zur Not auch eine Blacklist mit IPs tun, welche ein W-LAN Client nicht als Source-IP oder im Zusammenhang mit ARP verwenden darf.
Ciao,
Florian
vielen Dank für deine Infos:
Bislang übertragen hier die APs im VLAN für Privatkundenzugänge nur die Protokolle ARP, UDP (67), TCP und UDP (53), TCP(1723) und GRE, welche zur Kommunikation mit dem PPTP Access Server benötigt werden. Die Kommunikation zwischen den W-LAN Clients ist untersagt, da nicht benötigt.
Die oben erwähnten "Angriffsflächen" werden zum Glück selten mißbraucht; aber leider hat die Vergangenheit gezeigt, dass es immer wieder "Spezialisten" gibt, welche gewollt oder ungewollt versuchen das Netz zu stören.
Mit Leps und Radius AAA sollen sich nun zukünftig die Privatkunden mit individuellen WPA Keys direkt in die APs einbuchen können. Sobald korrekt im W-LAN assoziert, erhält der Kunde per DHCP eine offizielle IP zugewiesen und sollte dann natürlich auch über einen unbeschränkten Internetzugang verfügen.
Korrekterweise sollten dann die W-LAN Clients untereinander Daten austauschen können. Durch die Flut der Protokolle und Datenströme ist ein Debugging bei den oben erwähnten Angriffsarten dann kaum mehr sinnvoll möglich.
Daher wäre es aus unserer Sicht sehr wünschenswert, wenn man die von den W-LAN Clients versendeten IP Pakete per erweiterten Protokollfilter wie folgt beschränken könnte:
- Protokoll UDP Port 67: nur DHCP Discover und DHCP Requests übertragen
Die IP aus dem DHCP Offer / ACK sollte der AP in einer Clienttabelle hinterlegen und:
- Protokoll ARP: ARP Replys nur für eigene IP und MAC übertragen.
- generell: Protokollübertragungen nur mit der "vom LAN Interface des AP" zugewiesenen DHCP Adresse als Source-IP übertragen.
Falls es firmwaretechnisch zu komplex wird, die jeweils per DHCP zugewiesene IP Adresse der W-LAN Clients in einer Tabelle abzulegen, würde es zur Not auch eine Blacklist mit IPs tun, welche ein W-LAN Client nicht als Source-IP oder im Zusammenhang mit ARP verwenden darf.
Ciao,
Florian
Moin,
aus lassen - alleine weil's immer wieder Leute gibt, die
versehentlich Sachen freigeben und so eine Angriffsfläche
bieten.
Das wird so ähnlich laufen,allerdings ohne die Überwachung
von ARPs, das ist in die jetzige Form der
Protokollfilter nur schwer zu gießen, und DHCP in die
eine oder andere Richtung wird auch komplett eingeschaltet
werden müssen, damit's funktioniert - sorry, aber ich will
keine möglicherweise auch noch richtungsabhängige
Deep-Packet-Analysis in der Bridge haben, das
kostet zu viel Performance...
Gruß Alfred
Gibt's dafür irgendeine Anwendung bei den Kunden (bisher ja offensichtlich nicht)? Wenn nein, würde ich das erstmalKorrekterweise sollten dann die W-LAN Clients untereinander Daten austauschen können. Durch die Flut der Protokolle und Datenströme ist ein Debugging bei den oben erwähnten Angriffsarten dann kaum mehr sinnvoll möglich.
aus lassen - alleine weil's immer wieder Leute gibt, die
versehentlich Sachen freigeben und so eine Angriffsfläche
bieten.
Das wird so ähnlich laufen,allerdings ohne die Überwachung
von ARPs, das ist in die jetzige Form der
Protokollfilter nur schwer zu gießen, und DHCP in die
eine oder andere Richtung wird auch komplett eingeschaltet
werden müssen, damit's funktioniert - sorry, aber ich will
keine möglicherweise auch noch richtungsabhängige
Deep-Packet-Analysis in der Bridge haben, das
kostet zu viel Performance...
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alfred,
wir sind WISP: Unsere Kunden wollen einen unbeschränkten Internetzugang mit einer offiziellen IP haben, so wie es bei allen anderen ISP üblich ist.
Bislang nutzen wir die W-LAN Technologie nur als Transportmedium für verschlüsselte PPTP Verbindungen zwischen den Privatkunden und einem PPTP VPN Access Server, welcher AAA abwickelt.
Dabei gibt es aus Sicht des Kunden im großen und ganzen zwei Störquellen:
- Die W-LAN Verbindung läuft nicht
- Die PPTP Verbindung über das W-LAN läuft nicht
Um den Supportaufwand zu minimieren, möchten wir gerne zukünftig Stück-für-Stück zu direktem AAA auf den LANCOM APs umstellen, was ja dank Leps, Radius AAA und WPA Verschlüsselung technisch nun kein Problem mehr darstellt.
Dabei muss es uns irgendwie gelingen, die Netzinfrastruktur so abzusichern, dass trotz "unbeschränktem Zugang" einzelne Nutzer nicht die Stabilität des gesamten Netzes und damit ein paar hundert andere Kunden stören können.
Wenn sich da eine Lösung finden ließe - und die kann auch gerne irgendwo gut geschützt im "Experten Modus" versteckt sein
- wäre uns sehr geholfen. 
Ciao,
Florian
wir sind WISP: Unsere Kunden wollen einen unbeschränkten Internetzugang mit einer offiziellen IP haben, so wie es bei allen anderen ISP üblich ist.
Bislang nutzen wir die W-LAN Technologie nur als Transportmedium für verschlüsselte PPTP Verbindungen zwischen den Privatkunden und einem PPTP VPN Access Server, welcher AAA abwickelt.
Dabei gibt es aus Sicht des Kunden im großen und ganzen zwei Störquellen:
- Die W-LAN Verbindung läuft nicht
- Die PPTP Verbindung über das W-LAN läuft nicht
Um den Supportaufwand zu minimieren, möchten wir gerne zukünftig Stück-für-Stück zu direktem AAA auf den LANCOM APs umstellen, was ja dank Leps, Radius AAA und WPA Verschlüsselung technisch nun kein Problem mehr darstellt.
Dabei muss es uns irgendwie gelingen, die Netzinfrastruktur so abzusichern, dass trotz "unbeschränktem Zugang" einzelne Nutzer nicht die Stabilität des gesamten Netzes und damit ein paar hundert andere Kunden stören können.
Wenn sich da eine Lösung finden ließe - und die kann auch gerne irgendwo gut geschützt im "Experten Modus" versteckt sein
- wäre uns sehr geholfen. Ciao,
Florian
Sowas kann einem auch in Kabelnetzen passieren, daher gehört soeine Lösung eigentlich in einen MiniPC hinter den AP, wo er dessen Performance nicht beeinträchtigt._Flo_ hat geschrieben: Dabei muss es uns irgendwie gelingen, die Netzinfrastruktur so abzusichern, dass trotz "unbeschränktem Zugang" einzelne Nutzer nicht die Stabilität des gesamten Netzes und damit ein paar hundert andere Kunden stören können.
Wenn sich da eine Lösung finden ließe - und die kann auch gerne irgendwo gut geschützt im "Experten Modus" versteckt sein
Dort kann man auswerten ob noch jemand anders als der offizielle DHCP Server auf Requests antwortet und IPs verteilt und dann auf dem betreffenden AP per TFTP die Clientisolation einschalten oder den Macfilter konfigurieren.
Gleichzeitig können dort noch HTTP-Proxys usw. drauf laufen so das die ganze Sache auch noch einen Mehrwert neben der Netzsicherung hat.
Im Prinzip haben wir in einem "gebridgten" Funknetz mit ein paar hundert W-LAN Clients ja ein zieeeemlich verlängertes, kabelloses Ethernet.Sowas kann einem auch in Kabelnetzen passieren, daher gehört soeine Lösung eigentlich in einen MiniPC hinter den AP, wo er dessen Performance nicht beeinträchtigt.
Und mit jedem neuen Client (=MAC mehr im Netz) wird es leider schwieriger interne Angriffe zu erkennen
Statt nun hinter den über 100 verbauten LANCOM APs wie wild MiniPCs zu installieren (dann kann ich ja gleich auf denen auch noch die AP Software laufen lassen), baue ich lieber neue Funksektoren mit weiteren LANCOM APs in den Gebieten auf, wo es performance-technisch nötig wird.
Auf einem OpenWRT Test-System haben entsprechende iptables Regeln die System Load zumindest nicht erkennbar beeinflusst. Warum sollte das also nicht auch LANCOM hinbekommen? Ein guter ARP-spoofing und Netzwerk-Schutz würde doch ganz gut zur beworbenen "SecurITy made in Gemany" Kampagne passen
Das würde mich auch stark wundern, iptables setzt Routing voraus und sollte daher beim bridgen von Frames keinerlei Load verursachen._Flo_ hat geschrieben:Auf einem OpenWRT Test-System haben entsprechende iptables Regeln die System Load zumindest nicht erkennbar beeinflusst.
Um auf Linuxbasierten Systemen in einer Bridge zu filtern ist ebtables notwendig was unter Last dann auch entsprechend Rechenzeit schlucken sollte.
Die L-54 erreichen unter Last aber so schon bis zu 80% Load, da kann es keine Lösung sein einen Hotpath wie die Bridge noch weiter aufzupumpen.
Eine Lösung wäre vielleicht grundsätzlich alle Frames statt der Bridge durch den Router und die Firewall laufen zu lassen, das würde bestimmt richtig Leistung kosten, würde dann aber wenigstens nur die stören die bereit sind zugunsten solcher Filter auf Performance zu verzichten.
Warum nicht einfach die Möglichkeit geben, den bereits vorhandenen Protokollfilter optional aktivierbar so zu ergänzen, dass Protokolle abhängig der TX/RX Richtung und ARP und DHCP mit den paar verfügbaren Optionen genauer zu matchen sind?Eine Lösung wäre vielleicht grundsätzlich alle Frames statt der Bridge durch den Router und die Firewall laufen zu lassen, das würde bestimmt richtig Leistung kosten, würde dann aber wenigstens nur die stören die bereit sind zugunsten solcher Filter auf Performance zu verzichten.
Dann kann man mit statischen Regeln wenigstens den Default Gateway und DCHP Server vor ARP spoofing schützen und DCHP OFFER und ACK Pakete vom W-LAN Interface kommend droppen.
Falls W-LAN Clients untereinander IP-Konflikte haben, fällt das dank ARPwatch Überwachung sowieso schnell auf.
Beide Paketarten (ARP und DHCP) sind übrigens so klein, dass das Matching der entsprechenden Optionen wohl kaum Performance kosten dürfte.
Wenn diese Option irgendwo versteckt im Expterten-Modus eingebaut wird und deaktiviert keine Performance schluckt ist jeder glücklich
Die Protokollfilter schlucken Rechenleistung, und das hat nichts mit der Länge derBeide Paketarten (ARP und DHCP) sind übrigens so klein, dass das Matching der entsprechenden Optionen wohl kaum Performance kosten dürfte.
Pakete zu tun - nur mit der Anzahl der Pakete, die pro Sekunde durch die Bridge
laufen.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Wäre trotzdem für den oben genannten Einsatzzweck schön, wenn ihr das Feature optional aktivierbar und damit nur bei Bedarf "ressourcenfressend" in die nächste Firmware mit einbauen könnt.
Ciao,
Florian
Nachtrag zu:
"böser Client" -[OpenWRT Transparente Bridge]- { 10.0.0.0/20er Netz } -[Gateway 10.0.15.254]- {Internet}
Auf dem Gateway 10.0.15.254 läuft noch ein DHCP server.
Als OpenWRT Transparent Bridge diente ein Asus WL-500g:
~# cat /proc/cpuinfo
system type : Broadcom BCM947XX
processor : 0
cpu model : BCM4710 V0.0
BogoMIPS : 82.94
[...] also nix wirklich besonderes.
Folgende ebtables Regeln habe auf dem OpenWRT installiert um das { 10.0.0.0/20er Netz} vor Gateway ARP Spoofing und Fake DHCPs im Netz zu schützen:
# ebtables -L
Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-p 0x806 -o {Interface 10er Netz} --arp-ip-src 10.0.15.254 -j DROP
-p 0x800 -s ! {MAC Gateway} -i {Interface 10er Netz} --ip-proto udp --ip-sport 67 -j DROP
Systemload bei Download von 100MB File mit ~2.2MB/sec
mit aktiven ebtables: 0.39
ebtables deaktiviert: 0.36
Auf einem um einiges leistungsstärkeren L-54er AP ist der Performancebedarf einer ähnlichen LANCOM Implementierung für Outdoor W-LAN Zwecke wohl zu vernachlässigen.
Ciao,
Florian
Nachtrag zu:
Habe folgenden Testaufbau erstellt, um den Performancebedarf zu testen:Die Protokollfilter schlucken Rechenleistung, und das hat nichts mit der Länge der Pakete zu tun - nur mit der Anzahl der Pakete, die pro Sekunde durch die Bridge laufen.
"böser Client" -[OpenWRT Transparente Bridge]- { 10.0.0.0/20er Netz } -[Gateway 10.0.15.254]- {Internet}
Auf dem Gateway 10.0.15.254 läuft noch ein DHCP server.
Als OpenWRT Transparent Bridge diente ein Asus WL-500g:
~# cat /proc/cpuinfo
system type : Broadcom BCM947XX
processor : 0
cpu model : BCM4710 V0.0
BogoMIPS : 82.94
[...] also nix wirklich besonderes.
Folgende ebtables Regeln habe auf dem OpenWRT installiert um das { 10.0.0.0/20er Netz} vor Gateway ARP Spoofing und Fake DHCPs im Netz zu schützen:
# ebtables -L
Bridge chain: FORWARD, entries: 2, policy: ACCEPT
-p 0x806 -o {Interface 10er Netz} --arp-ip-src 10.0.15.254 -j DROP
-p 0x800 -s ! {MAC Gateway} -i {Interface 10er Netz} --ip-proto udp --ip-sport 67 -j DROP
Systemload bei Download von 100MB File mit ~2.2MB/sec
mit aktiven ebtables: 0.39
ebtables deaktiviert: 0.36
Auf einem um einiges leistungsstärkeren L-54er AP ist der Performancebedarf einer ähnlichen LANCOM Implementierung für Outdoor W-LAN Zwecke wohl zu vernachlässigen.