WPA2 gehackt Android und Linux besonders gefährdet

[ingo2]

Ich verfolge das hier auch mit Interesse. Zunächst nur wegen der WPA2-Geschichte, jetzt aber auch bezüglich "Brückenbau". Bin nämlich auch gerade auf meinem APU.2C die 3 Ethernet-Ports zu einer "br0" zusammengeschlossen - die laufen jetzt vorläufig als dummer Switch.

Der nächste Schritt soll dann ein minimales Routen/Firewalling auf der Bridge sein (mit iptables, ebtables und arptables muß ich mich erst noch vertraut machen).

Was mir aber schon jetzt noch völlig unklar ist - das könnte ja auch hikaru interessieren:
Was ist mit IPv6 ???

Schon in der default-Konfiguration nach der Installation von Stretch hatte ich folgende Zeile in der interfaces:

Code: Alles auswählen

# This is an autoconfigured IPv6 interface
iface enp1s0 inet6 auto

Habe das erstmal einfach kommentiert - aber dennoch funktioniert IPv6 über die Bridge, obwohl ich nur eine IPv4-Adresse statisch vergeben habe!?
Und die ganzen schönen Filter-Regeln reden nur von und konfigurieren nur IPv4. Ist das nicht irgendwo widersinnig, mit IPv6 umgeht man doch das ganze Routing-Konstrukt, oder denke ich da falsch?

Viele Grüße,
Ingo

[dufty2]

Habe das erstmal einfach kommentiert - aber dennoch funktioniert IPv6 über die Bridge, obwohl ich nur eine IPv4-Adresse statisch vergeben habe!?
Und die ganzen schönen Filter-Regeln reden nur von und konfigurieren nur IPv4. Ist das nicht irgendwo widersinnig, mit IPv6 umgeht man doch das ganze Routing-Konstrukt, oder denke ich da falsch?

Haben wir doch gelernt
Bei einer Bridge/Switch bräuchten wir gar keine IP(4/6)-Adresse,
die geht ja auf Layer-2 und so ist der übergeordnete Layer-3 (Routing) nicht von Belang.

Code: Alles auswählen

$ cat /etc/ethertype

zeigt Dir auf, dass es neben IPv4 und IPv6 'ne Menge Protokolle auf Layer-3 gibt.
Jene könnte man ggf. auch per "ebtables" blocken.

[ingo2]

Haben wir doch gelernt
Bei einer Bridge/Switch bräuchten wir gar keine IP(4/6)-Adresse,
die geht ja auf Layer-2 und so ist der übergeordnete Layer-3 (Routing) nicht von Belang.

... zeigt Dir auf, dass es neben IPv4 und IPv6 'ne Menge Protokolle auf Layer-3 gibt.
Jene könnte man ggf. auch per "ebtables" blocken.

Da fehlt mir jetzt echt das Verständnis. Wie soll dann eine Firewall auf so einer Bridge laufen, wenn eh' alle Ports wie eine "Mehrfachsteckdose" verbunden sind? Was macht dann überhaupt der Kernel noch?
Gibt's irgendwo da ein Tutorial, wo die Zusammenhänge für Anfänger auf dem gebiet erklärt sind?

Was ich mir noch vorstellen könnte, wäre eine Flußsteuerung anhand von MAC-Adressen, d.h. eth1 darf mit eth2 und eth3 kommunizieren, aber eth2 darf nicht mit eth3 kommunizieren ... usw.

Ingo

[dufty2]

Du willst doch unbedingt eine Firewall auf eine Bridge laufen lassen
Die meisten Firewall, die ich so kenne, sind eher Router als Bridges/Switche.

Aber der kernel hat schon einige Möglichkeiten, z. B. kann man ipv6 komplett abschalten.
Und was er im Fall einer bridge macht, kannst Du z. B. hier nachlesen unter "bridge processing":
https://vincent.bernat.im/en/blog/2017- ... -isolation

Recht bekannt ist auch
https://wiki.linuxfoundation.org/images ... kernel.png

Wobei ich zugebe, letzteres auch nicht verstanden habe

[ingo2]

Du willst doch unbedingt eine Firewall auf eine Bridge laufen lassen

Nachdem ich deinen Link gelesen habe, nicht mehr - Danke!
Sicherheit bringt das praktisch kaum, im Gegenteil, es wird soooo kompliziert, daß Fehler unvermeidbar sind und ich mir das nicht zutraue. Also meine 2 übrigen/ungenutzten Ports werden zum Switch - fertig. Kann man ja noch als Monitoring Port für Wireshark nutzen, da die Interfaces alle im promiscuous mode laufen.
Aber gelernt habe ich trotzdem viel: eine wirklich gute Firewall gehört nicht umsonst auf eine dezidierte Hardware mit professioneller Software. Die sollte dann aber nicht nochmal NAT machen und auch IPv6-tauglich sein.
Und - was jetzt hikaru beachten sollte: so eine WLAN-Ethernet-Bridge öffnet das ganze Heimnetz über WLAN!

Recht bekannt ist auch
https://wiki.linuxfoundation.org/images ... kernel.png

Dass das alles funktioniert - wer hat da den Überblick

[BenutzerGa4gooPh]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Das weiß ich nicht, kommt wohl auf die programmierte "Implementierung der Deaktivierung" an.

Und das ist ebenfalls offen:

802.11s kann ich nicht abschätzen, da müsste man tiefer graben als hier: https://de.m.wikipedia.org/wiki/IEEE_802.11s

dufty2 hat geschrieben: Sa 21. Okt 2017, 13:50
Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt,
Danke! Die Konfiguration funktioniert.

Freut mich auch. Haben "Mitneugierige" einen Link auf eine verifizierte Gebrauchsanleitung.
Du arbeitest nun mit fixer IP und deaktiviertem

Code: Alles auswählen

service dhcpcd stop
systemctl disable dhcpcd

?

[mat6937]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein. Z. B.:

In der ".config"-Datei zwecks Kompilieren:

Code: Alles auswählen

# IEEE Std 802.11r-2008 (Fast BSS Transition)
CONFIG_IEEE80211R=y

in der wpa_supplicant.conf-Datei zwecks Konfigurieren:

Code: Alles auswählen

# key_mgmt: list of accepted authenticated key management protocols
# ,,,
# FT-PSK = Fast BSS Transition (IEEE 802.11r) with pre-shared key
# FT-EAP = Fast BSS Transition (IEEE 802.11r) with EAP authentication
# ...

[dufty2]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein.

Man darf davon ausgehen, dass ein Angreifer "mit allen Mitteln gewaschen" ist, sprich alle WLAN-modis zur Verfügung hat.
Dies nicht zu tun, wäre IMHO etwas blauäugig

Aber um auf die Frage etwas konkreter einzugehen, z. B. wird 802.11r in
http://www.arubanetworks.com/assets/ale ... _Rev-1.pdf
erwähnt und - solange nicht konfigueriert - auch nicht als Gefährdung angesehen.
So wird's bei hostapd wohl auch sein, denke ich (sprich: sicher weiß ich es auch nicht ).

Auf der "All Systems Go 2017" gab's einen netten Vortrag von Marcel Holtmann,
ist ganz schön über wpa_supplicant hergezogen
https://media.ccc.de/v/ASG2017-132-upda ... _for_linux

[mat6937]

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?

Der WLAN-Client (wpa_supplicant) müsste auch damit bzw. dafür kompiliert _und_ konfiguriert sein.

Man darf davon ausgehen, dass ein Angreifer "mit allen Mitteln gewaschen" ist, sprich alle WLAN-modis zur Verfügung hat.
Dies nicht zu tun, wäre IMHO etwas blauäugig

BTW: Im Zitat geht es aber nur um den 802.11r-FT-Angriff. In deinem 1. Link kann man z. B. Folgendes zu diesem Angriff lesen:

However, if
updating AP software is not possible immediately, an effective mitigation would be disabling 802.11r on
the Aruba infrastructure ...