WPA2 gehackt Android und Linux besonders gefährdet

[MSfree]

Windows ist schon gepatched.

wpa_supplicant und hostapd sind für Linux auch schon gepatcht.

Wenn aber der billige Pastikrouter noch nicht gepatcht wurde, wovon man in kleinen Betrieben zu fast 100% ausgehen kann, kannst du Windows soviel patchen wie du willst, dann greife ich halt den WLAN-Router an.

Die Patientendaten sind nur gefährdet wenn man die unverschluesselt via Wlan versendet.

Die Patientendaten werden vermutlich ganz einfach mittels SMB übertragen, Verschlüsselung = Fehlanzeige.

[TRex]

Wenn man der heise-Erklärung folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

[mat6937]

... folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

Sie sind auch als WLAN-Router angreifbar, wenn sie:

Code: Alles auswählen

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

implementiert haben.

[MSfree]

Wenn man der heise-Erklärung folgt, sind Router nur angreifbar, wenn sie als Client agieren (repeater).

Nein, denn sonst hätte man für Linux den hostapd nicht gepatcht. Die größte Gefahr geht mal wieder vov ungepatchten WLAN-Routern aus. Aber ich gebe zu, daß keine einzige Erklärung, die ich im Internet gelesen habe, wirklich eindeutig sagt, was Sache ist. Es wird sensationsheischend dieser Bug verbreitet, aber nicht klar gesagt, was denn wirklich kaputt ist.

Ich gehe sogar davon aus, daß man auf die Art und Weise, wie der Angriff durchgeführt wird, auch der WPA-Key auslesbar ist, obwohl überall vehement das Gegenteil behauptet wird. Das Geeiere um die echten Auswirkungen dieses Bugs bestätigt mich eigentlich nur in meiner Annahme, daß wohl auch die Patches, die jetzt veröffentlicht wurden, nur ein notdürftiges Pflaster sein werden. Vermutlich brauchen wir WPA3, um der Lage Herr zu werden.

[guennid]

Da ich z.Z. noch andere Software-Sorgen habe, würde ich dem Verwirrspiel auch gerne verweigern, solange man nicht weiß, was Sache ist.

Ich lese hier immer "Router". Meine Router sind lediglich per Kabel, bzw. DSL ans Internet angeschlossen. Aber was ist mit Plastik-AP, über den ein paar Rechner an die Router angeschlossen sind?

Grüße, Günther

[MSfree]

Ich lese hier immer "Router".

Ein WLAN-Router ist ein Router mit integriertem WLAN Accesspoint. Wenn du also auf deinen "nur" per Kabel" angeschlossenen Router das WLAN nicht abgeschaltet hast, ist es prinzipiell verwundbar.

Aber was ist mit Plastik-AP

Der Plastik-AP ist selbstverständlich genau der verwundbare Teil, um den du dir Gedanken machen mußt.

Alles, was irgendwie über WLAN funkt (Laptops, Tabletts, APs, WLAN-Router, Smartphones, IoT-Devices, TV-Geräte, Überwachungskameras, Amazon Alexa...) ist angreifbar.

[guennid]

Wenn du also auf deinen "nur" per Kabel" angeschlossenen Router das WLAN nicht abgeschaltet hast,

Ist abgeschaltet.

Der Plastik-AP ist selbstverständlich genau der verwundbare Teil, um den du dir Gedanken machen mußt.

Dachte ich mir schon. Daher liebäugele ich mit hikarus Idee. Ob die WLAN-NIC auf einem eeepc 4g hostapd-tauglich ist, muss ich noch rausfinden.

Grüße, Günther

[hikaru]

Ob die WLAN-NIC auf einem eeepc 4g hostapd-tauglich ist, muss ich noch rausfinden.

Soweit ich weiß steckt da ein Atheros-Modul drin, mit dem es gehen sollte. Aufschluss gibt die Ausgabe von iw list, wobei das Entscheidende dann diese beiden Punkte wären:

Code: Alles auswählen

Supported interface modes:
		 * AP
		 * AP/VLAN

[scientific]

Unser IT-Dienstleister gibt für die Remote-Desktopverbindung ein Zertifikat heraus, das von einer in den Browsern bekannten CA signiert ist, heraus, das auf "*.domain.example" ausgestellt ist. Der Gateway für die RDP-Verbindung passt. Der Sessionhost endet dann auf *.LOCAL

Der Rdp-Client bemängelt zurecht ein unkorrektes Zertifikat. Der Workaround ist "Klicken sie bitte die Warnmeldung weg"
Meine Bitte nach einem korrekten Zertifikat wird "nicht einmal ignoriert"...

Dieser Dienstleister meint nun, dass vom WPA-Crack keine Gefahr ausgeht. Die Geschäftsführung glaubt den Experten und meint belustigt "DEIN Linux ust ja viel gefährdeter"...

Angenommen, ein Bösewicht nutzt den Wpa-Bug aus und lenkt die Rdp-verbindung über einen Man-in-the-middle-Rechner um und greift sich Logindaten ab. Dann meckert natürlich der RDP-Client ein fehlerhaftes Zertifikat. Die User lernten diese Warnung wegzuklicken... Und schon ist der Angreifer im Netz bei uns.
Klingt das realistisch (wenn auch unwahrscheinlich)? Könnte man dann so auch eine ssl-verschlüsselte Verbindung öffnen?

Lg scientific

[MSfree]

Soweit ich weiß steckt da ein Atheros-Modul drin

Richtig, im 70x-Modell steckt Atheros. Es kann aber nur 54MBIt/s brutto, ist also entsprechend lahm.

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen, entsprechende Firewallregeln kann man relativ einfach einrichten. Ich hatte so etwas mal vor langer Zeit, als ich noch einen AP hatte, der nur WEP konnte.

Fremde können mit so einem WLAN nichts anfangen, weil das nichts durchrouten würde außer OpenVPN-Pakete, und für OpenVPN gibt es für jeden Rechner ein eigenes Zertifikat.

[MSfree]

Angenommen, ein Bösewicht nutzt den Wpa-Bug aus und lenkt die Rdp-verbindung über einen Man-in-the-middle-Rechner um und greift sich Logindaten ab.

Angeblich ist MiM im Moment nicht möglich. Man kann nur den unverschlüsselten WLAN-Verkehr mitlesen aber nichts selbst einstreuen. Es wird auch versichert, daß man durch mitlesen (angeblich) nicht an den WPA-Key kommt.

Wer also im Moment seine Netzwerkverbindungen zusätzlich über Verschlüsselung absichert, hat erstmal kein großes Problem. Im Moment kann man dann nur evrschlüsselte Pakete mitlesen.

Aber, wie gesagt, ob man nicht doch noch an den WPA-Key kommt, kann ich nicht ausschließen.

[hikaru]

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen,

Das Konzept durcblicke ich nicht auf Anhieb. Was passiert dann mit den OpenVPN-Paketen im Plastikrouter? Ich habe mich hostseitig nie mit VPN beschäftigt.

[TomL]

Was passiert dann mit den OpenVPN-Paketen im Plastikrouter?.

Nix, weil es die da nicht gibt. Die Vpn-Verbindung befindet sich zwischen Client und wlan-AP. Zwischen AP und dem DSL-Router ist ne normale Leitung mit normalen TCP/UDP-Paketen. Das heisst, im wlan-Router kommen auf dem tun-Interface vpn-Pakete rein und gehen via eth0-Interface unverschlüsselt an den DSL-Router.

Technisch könnten sich alle Clients mit dem AP verbinden , aber via Iptables werden nur VPN-Pakete geroutet, alles andere hingegen gedropt. Damit ist der AP für Nicht-VPN-Clients quasi unbenutzbar. Und die VPN-Clients haben 'personifizierte' Zertifikate. Ich hoffe, ich habe msfree' Idee richtig verstanden

[MSfree]

Mein Ansatz wäre eher, über WLAN nur noch OpenVPN zuzulassen,

Das Konzept durcblicke ich nicht auf Anhieb.

Ich hatte, wie geasgt, mal einen WEP-only Accesspoint. Den habe ich per Ethernetkabel an einer zweiten Netzwerkschnittstelle eines Linuxrechners angeschlossen und darüber ein eigenes Subnetz aufgespannt. Der Linuxrechner hat per iptables nur UDP 1194 durchgelassen, ebenso die WLAN-Clients.

Der OpenVPN-Server lief auf dem Linuxrechner, an dem die WLAN-Kiste angeschlossen war. OpenVPN habe ich so konfiguriert, daß man die virtuelle tun/tap-Schnittstelle, mit dem lokalen LAN bridgen konnte.

Über das VPN waren dann alle WLAN-Clients auch Mitglied im lokalen LAN, so daß keine weiteren Konfigurationen auf den Clients nötig war, ausser dort OpenVPN einzurichten.

Was passiert dann mit den OpenVPN-Paketen im Plastikrouter?

Gar nichts, die Plastikbüchse sieht die Pakete nicht einmal. Das WLAN im Plastikrouter muß allerdings ausgeschaltet werden, du brauchst ein zweites Gerät oder hast sowieso noch einen alten AP oder nimmst einen USB-WLAN-Stick und steckst ihn an einen Linuxrechner, der immer läuft.

[dufty2]

Mmmh, wird mal Zeit, sich mit WLAN genauer zu beschäftigen.
Ohne irgendwas gelesen zu haben - denke ich - ist bei WLAN:
Den (4-Wege)-Handshake initiiert stets der "wlan-client" => sind also "im Netz" nur zwei WLAN-AccessPoints (AP) - sprich zwei "wlan-server" - passiert gar nichts.
Das ändert sich für den "wlan-server" dann, wenn er a) im repeater- b) mesh- c) roaming(802.11r-2008)-mode sich befindet.

Und da Debian's hostapd die Confg
CONFIG_IEEE80211R=y
hat, muss er auch gepatcht werden.

Die 3 Modi sind bei hikaru - wenn ich seinen Netzaufbau richtig interpretiere - nicht vorhanden.
Daher weiss ich nicht, ob sein Projekt einen großen Sicherheitsgewinn bringt.

Aber wie gesagt, von WLAN keine Ahnung, lasse ich mich gerne belehren

[DeletedUserReAsG]

Angenommen, ein Bösewicht nutzt den Wpa-Bug aus und lenkt die Rdp-verbindung über einen Man-in-the-middle-Rechner um und greift sich Logindaten ab. Dann meckert natürlich der RDP-Client ein fehlerhaftes Zertifikat. Die User lernten diese Warnung wegzuklicken... Und schon ist der Angreifer im Netz bei uns.
Klingt das realistisch (wenn auch unwahrscheinlich)?

Klingt nach ’nem typischen Szenario, wenn jemand gezielt in euer Netz will.

Angeblich ist MiM im Moment nicht möglich.

Das sah in diesem hübschen Proof-of-concept-Video irgendwie anders aus …

OT: kann mal jemand den Threadtitel fixen? Als Aussage stehend ist’s ja nunmal absoluter Dummsinn – wahrscheinlich wurde da das Fragezeichen vergessen.

[mat6937]

Aber ich gebe zu, daß keine einzige Erklärung, die ich im Internet gelesen habe, wirklich eindeutig sagt, was Sache ist. Es wird sensationsheischend dieser Bug verbreitet, aber nicht klar gesagt, was denn wirklich kaputt ist.

Siehe z. B.: https://www.heise.de/security/artikel/K ... 65019.html

und

https://papers.mathyvanhoef.com/ccs2017.pdf

[hikaru]

@TomL, MSfree:
Danke für die Erklärungen! So verstehe ich es.

a) im repeater- b) mesh- c) roaming(802.11r-2008)-mode
[..]
Die 3 Modi sind bei hikaru - wenn ich seinen Netzaufbau richtig interpretiere - nicht vorhanden.

Richtig.

Daher weiss ich nicht, ob sein Projekt einen großen Sicherheitsgewinn bringt.

Ich auch nicht. Die aktuelle Lücke war nur der Tropfen der das Fass namens "Plastikrouter" bei mir zum Überlaufen gebracht hat um mich doch mal ein wenig praktisch mit dem ganzen Netzwerkkram zu beschäftigen.


Ich habe jetzt übrigens ein erstes Testsetup zu laufen.
Nach der Vorlage [1] habe ich eine hostapd.conf angelegt:

Code: Alles auswählen

# WLAN-Router-Betrieb

# Schnittstelle und Treiber
interface=wlp3s0
bridge=br0
#driver=nl80211

# WLAN-Konfiguration
ssid=hikarusAP
channel=1
hw_mode=g
ieee80211n=1
ieee80211d=1
country_code=DE
wmm_enabled=1

# WLAN-Verschlüsselung
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=StrengGeheim

Und auf Basis von [2] habe ich eine Netzwerkbrücke angelegt:

Code: Alles auswählen

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

 auto enp0s25
 allow-hotplug enp0s25
 iface enp0s25 inet dhcp

# Netzwerkbrücke
 auto br0
 iface br0 inet static
 address 192.168.3.1
 netmask 255.255.255.0
 broadcast 192.168.3.255
 bridge_ports enp0s25
 bridge_fd 0                  # Einstellungen testen, Verzögerung (forward-delay) ggf. erhöhen
 bridge_stp no                # Einstellungen testen und ggf. auf 'yes' setzen

Auf dem Notebook läuft eine Xfce-Standardinstallation. WLAN und LAN liefen also über den Networkmanager, was aber in Verbindung mit hostapd nicht funktionierte. Daher habe ich den Networkmanager deaktiviert und den LAN-Adapter (absichtlich mit dhcp) in /etc/network/interfaces eingetragen.
Dass die Konfiguration so vermutlich noch nicht ideal ist (hostapd channel, hw_mode), ist mit klar, aber es funktioniert zumindest prinzipiell. Ich kann mich vom anderen Notebook und vom Handy über das HTPC-Notebook per WLAN verbinden, und alle drei Geräte kommen in's Internet.

Mich irritiert allerdings, dass ich mich vom HTPC weder auf den anderen beiden Geräten oder auf dem per Kabel ebenfalls am Plastikrouter hängenden Desktop-PC per SSH einloggen kann, noch sie anpingen kann (vom HTPC zum Notebook):

Code: Alles auswählen

ping t530
PING t530.lan (192.168.1.2) 56(84) bytes of data.
From t430.lan (192.168.1.4) icmp_seq=1 Destination Host Unreachable
From t430.lan (192.168.1.4) icmp_seq=2 Destination Host Unreachable
From t430.lan (192.168.1.4) icmp_seq=3 Destination Host Unreachable
From t430.lan (192.168.1.4) icmp_seq=4 Destination Host Unreachable
^C
--- t530.lan ping statistics ---
6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 5024ms

Andersrum funktioniert es auch nicht. Die beiden WLAN-Clients und der Desktop-PC können aber gegenseitig aufeinander zugreifen. Vor der Spielerei bestand das Problem nicht.
Was mache ich hier falsch?


[1] https://www.elektronik-kompendium.de/si ... 002171.htm
[2] https://wiki.ubuntuusers.de/WLAN_Router ... erkbruecke

[dufty2]

Du hast Deinem bridge-Interface eine IP aus einem ganz anderen Band (192.168.3.0/24) vergeben.
Ohne es jetzt nachgestellt zu haben, vermute ich mal, dass dadurch Deine local-Route
192.168.1.0/24
weggeflogen ist, die Default-Route über 192.168.1.1 aber noch besteht.

Da Du im Grunde nur eine "WLAN-Bridge" aber keinen "WLAN-Router" benötigst, könnten die Zeilen

Code: Alles auswählen

address 192.168.3.1
netmask 255.255.255.0
broadcast 192.168.3.255

komplett entfallen. Ob das dann noch zusammen mit dem hostapd funktioniert, muesste man dann mal testen.

[hikaru]

Da Du im Grunde nur eine "WLAN-Bridge" aber keinen "WLAN-Router" benötigst, könnten die Zeilen

Code: Alles auswählen

address 192.168.3.1
netmask 255.255.255.0
broadcast 192.168.3.255

Nach Auskommentieren dieser Zeilen funktioniert die Netzwerkkommunikation mit anderen Rechnern wieder, allerdings scheitert dann der Handshake in hostapd:

Code: Alles auswählen

Searching a PSK for 00:bd:3a:f6:d4:11 prev_psk=(nil)
WPA: 00:bd:3a:f6:d4:11 WPA_PTK entering state PTKSTART
wlp3s0: STA 00:bd:3a:f6:d4:11 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=1 kde_len=0 keyidx=0 encr=0)
WPA: Replay Counter - hexdump(len=8): 00 00 00 00 00 00 00 01
WPA: Use EAPOL-Key timeout of 100 ms (retry counter 1)
hostapd_new_assoc_sta: reschedule ap_handle_timer timeout for 00:bd:3a:f6:d4:11 (300 seconds - ap_max_inactivity)
nl80211: Event message available
nl80211: Drv Event 19 (NL80211_CMD_NEW_STATION) received for wlp3s0
nl80211: New station 00:bd:3a:f6:d4:11
wlp3s0: Event EAPOL_TX_STATUS (38) received
IEEE 802.1X: 00:bd:3a:f6:d4:11 TX status - version=2 type=3 length=95 - ack=1
WPA: EAPOL-Key TX status for STA 00:bd:3a:f6:d4:11 ack=1
WPA: Increase initial EAPOL-Key 1/4 timeout by 1000 ms because of acknowledged frame
wlp3s0: STA 00:bd:3a:f6:d4:11 WPA: EAPOL-Key timeout

Das Entscheidende scheint das Zuweisen einer Netzwerkadresse an die Bridge in /etc/network/interfaces überhaupt zu sein. netmask und broadcast haben offenbar keinen Einfluss. Aber wenn ich eine address-Zeile zuweise (auch 192.168.1.10, was im selben Subnetz wie mein restliches Netzwerk liegt), dann funktioniert hostapd, aber nicht das restliche Netzwerk und wenn ich sie nicht zuweise, dann ist es genau andersrum. Dabei ist es für die Funktionstüchtigkeit des Netzwerks egal, ob hostapd schon läuft oder noch nicht.

[mat6937]

... habe ich eine hostapd.conf ...

Evtl. für zusätzliche Sicherheit, den hostapd mit z. B.:

Code: Alles auswählen

CFLAGS += -DDEFAULT_WPA_DISABLE_EAPOL_KEY_RETRIES=1

patchen/kompilieren/konfigurieren.

Quelle: https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

[BenutzerGa4gooPh]

Das Entscheidende scheint das Zuweisen einer Netzwerkadresse an die Bridge in /etc/network/interfaces überhaupt zu sein. netmask und broadcast haben offenbar keinen Einfluss. Aber wenn ich eine address-Zeile zuweise (auch 192.168.1.10, was im selben Subnetz wie mein restliches Netzwerk liegt), dann funktioniert hostapd, aber nicht das restliche Netzwerk und wenn ich sie nicht zuweise, dann ist es genau andersrum. Dabei ist es für die Funktionstüchtigkeit des Netzwerks egal, ob hostapd schon läuft oder noch nicht.

Die Bridge ist auch nur ein Host im entsprechenden Netzsegment:
Router - LAN-Subnet - Ethernetport der Bridge- Bridge (IP) - WLAN-Port der Bridge - WLAN (= LAN-Subnet). Also Bridge-IP ausschließlich aus LAN-Subnet und ausserhalb DHCP-Pool des Routers! Die Bridge-IP ist eigentlich die gleiche, wie die normale IP des Rechners. DHCP-Dienste müssen gar nicht laufen (werden durchgereicht), DNS-Forwarder nur um auf dem Rechner arbeiten zu können. Auch für Host im WLAN ist der DNS des Routers zuständig. Schaue mal nach sich "kannibalisiernden" Netzwerkdiensten (network-manager, dnsmasq, systemd?). Und für Bridge gleiche IP-Konfiguration wie für Hosts im WLAN und vorgeschalteten LAN-Segment. Da fixe IP ausserhalb DHCP-Pool.

[BenutzerGa4gooPh]

"Krack" hat seinen "Weg" zu Wikipedia gefunden.

Die Sicherheitslücke betrifft die clientseitige Implementation von IEEE 802.11s und die Accesspoints bei der IEEE 802.11r beim „MESH-Roaming“ und nicht nur einzelne Implementierungen.[4]

https://de.m.wikipedia.org/wiki/WPA2#Ke ... on_Attacks
Mit Wissen um die betroffenen Standards kann man Risikoabschaetzungen für den Weiterbetrieb von WLAN-Komponenten vornehmen, die absehbar nicht (mehr) oder nicht "zeitnah" gepatcht werden.

802.11r betrifft Roaming in WLAN-Netzen mit mehreren Accesspoints. Implementierung für AP und Client notwendig.
Datenblatt suchen: Ist das in meinem Accesspoint/Router überhaupt implementiert? In meinem WLAN-Client, meinem Repeater?
In alten Android-Smartphones 802.11r eher nicht, "Roaming" durch Reaktivieren WLAN, AP mit höherem Pegel bei gleicher SSID/PSK wird gewählt. KISS.
https://en.m.wikipedia.org/wiki/IEEE_802.11r-2008

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

Jedenfalls wollen momentan nicht alle Hersteller von Accesspoints unverzüglich patchen. Z. B. keine Aussage von Devolo gefunden ausser diesem (unverbindlichen) Beitrag: https://www.heise.de/forum/heise-Securi ... 1501/show/
Keine neue Software auf Downloadseiten für "Bussiness"-WLAN.
https://www.devolo.de/business-solution ... 0-wifi-ac/
Eine offizielle Stellungnahme eines "Platzhirschen" wäre angebracht.

[dufty2]

Da Du im Grunde nur eine "WLAN-Bridge" aber keinen "WLAN-Router" benötigst, könnten die Zeilen

Code: Alles auswählen

address 192.168.3.1
netmask 255.255.255.0
broadcast 192.168.3.255

Nach Auskommentieren dieser Zeilen funktioniert die Netzwerkkommunikation mit anderen Rechnern wieder, allerdings scheitert dann der Handshake in hostapd:

Das kann gut sein, denn wenn ich mich dunkel erinnere, war die bridge "wlan-ethernet" etwas komplizierter als die bridge "ethernet-ethernet".
Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt, die ich so auch von "ethernet-ethernet"-bridges kenne:
Die IP/NM/default-gw bekommt das bridge-interface ("virtueller IP"), die unter der bridge gehängten physikalischen Interfaces bekommen selbst keine IP mehr zugewiesen.
Kannst ja nochmals so testen.

[hikaru]

Evtl. für zusätzliche Sicherheit, den hostapd mit z. B.:

Code: Alles auswählen

CFLAGS += -DDEFAULT_WPA_DISABLE_EAPOL_KEY_RETRIES=1

patchen/kompilieren/konfigurieren.

Quelle: https://w1.fi/cgit/hostap/commit/?id=6f ... 45ed8e52d3

Danke für den Hinweis!

Die Bridge ist auch nur ein Host im entsprechenden Netzsegment:
Router - LAN-Subnet - Ethernetport der Bridge- Bridge (IP) - WLAN-Port der Bridge - WLAN (= LAN-Subnet). Also Bridge-IP ausschließlich aus LAN-Subnet und ausserhalb DHCP-Pool des Routers!

Ich denke, der Teil ist mir klar.

Die Bridge-IP ist eigentlich die gleiche, wie die normale IP des Rechners.

Das ändert hier nichts. Ich habe gerade mal dem LAN-Interface und der Bridge statisch die selbe IP zugewiesen, aber auch dann lässt sich der Rechner nicht anpingen, während eine WLAN-Verbindung per hostapd funktioniert. Wenn ich die IP-Adresse der Bridge gar nicht definiere, dann habe ich wieder den umgekehrten Fall, dass zwar der Rechner selbst im LAN ereichbar ist, aber per hostapd keine WLAN-Verbindungen mehr gehen.

DHCP-Dienste müssen gar nicht laufen (werden durchgereicht), DNS-Forwarder nur um auf dem Rechner arbeiten zu können.

Keines von beiden läuft momentan auf dem Rechner.

Schaue mal nach sich "kannibalisiernden" Netzwerkdiensten (network-manager, dnsmasq, systemd?).

network--manager habe ich abgeschaltet. Das war nötig um hostapd überhaupt starten zu können.
dnsmasq ist nicht installiert, dnsmarq-base war als Abhängigkeit von network-manager vorhanden, das dnsmasq-Binary läuft aber nicht.
Bei systemd weiß ich nicht wonach ich schauen soll.

Und für Bridge gleiche IP-Konfiguration wie für Hosts im WLAN und vorgeschalteten LAN-Segment. Da fixe IP ausserhalb DHCP-Pool.

Das scheint sich mit dem Plastikrouter zu beißen. Jedenfalls kann ich dann trotz stehender Verbindung weder in's LAN noch in's Internet pingen.

802.11r betrifft Roaming in WLAN-Netzen mit mehreren Accesspoints. Implementierung für AP und Client notwendig.
Datenblatt suchen: Ist das in meinem Accesspoint/Router überhaupt implementiert? In meinem WLAN-Client, meinem Repeater?

Angenommen das sei in meinem AP implementiert, reicht das schon für Verwundbarkeit oder muss das Feature auch aktiviert sein?
Mein Bauch sagt "nein", aber wie die Zurschaustellung meiner Netzwerkkompetenz in diesem Thread zeigt, sollte ich mich darauf nicht verlassen.

Unter
https://www.elektronik-kompendium.de/si ... 002161.htm
ist auch eine bridge-Konfiguration benannt,

Danke! Die Konfiguration funktioniert.
Entscheidender Punkt könnte sein, dass da beide Enden der Bridge definiert sind (was mir logisch erscheint). Im Ubuntuusers-Wiki steht hingegen, das hostapd die Anbindung des WLAN-Interfaces an die Bridge übernimmt.