Ich habe mehrere Amazon Alexa-Geräte (ein Echo, zwei Dots) und einen Belkin Wemo Smart Switch. Mit der Alexa-App können Sie nach Smart-Home-Geräten suchen und sie fügt automatisch alle gefundenen Geräte hinzu. Normalerweise geschieht dies durch die Kommunikation zwischen der App, Amazon und der Netzwerk-Cloud des Geräts, aber anscheinend verwendet insbesondere das Wemo stattdessen die SSDP-Geräteerkennung. Alexa findet das Wemo fast immer.
Eigentlich möchte ich, dass es fehlschlägt, während ich die Fernsteuerung des Wemo über IFTTT erlaube. Ja, ich weiß, das ist ein seltsamer Anwendungsfall :) Mein erster Versuch war, ein sekundäres Netzwerk einzurichten und das Wemo daran anzuschließen. Aber aus irgendeinem Grund bleiben das Wemo und der Router in diesem Netzwerk nicht länger als etwa eine Minute verbunden. Also habe ich es aufgegeben und versucht, es über Firewall-Regeln zu machen – was weit außerhalb meiner Komfortzone liegt. Ich bin auch nicht mit SSDP/UPNP vertraut, aber ich verstehe die Idee schnell. Ich verwende DD WRT auf dem Router. Ich habe jedem Alexa-Gerät, meinem Telefon und dem Wemo eine statische IP-Adresse zugewiesen.
Da ich die Details des Erkennungsmechanismus von Alexa nicht kenne, gehe ich davon aus, dass ich sowohl den Empfang von M-SEARCH-Nachrichten vom Echo als auch das Senden von NOTIFY-Benachrichtigungen vom Wemo einstellen muss. Ich möchte die Geräteerkennung in meinem Netzwerk grundsätzlich weiter funktionieren lassen; ich verwende iTunes-Fernbedienungen und Plex und werde möglicherweise weitere ähnliche Geräte hinzufügen. Ich bin mir auch nicht sicher, welches Alexa-/Telefongerät die Erkennung einleiten würde, also bin ich zufrieden damit, sie alle zu blockieren.
Was ich also brauche, sind einige Routerregeln, die die SSDP-Kommunikation zwischen zwei Geräten unterbrechen, ohne das gesamte Protokoll oder die normale HTTP-Kommunikation (die, wie ich annehme, von IFTTT verwendet wird) zu einem der Geräte zu deaktivieren.
Was ich versucht habe, wobei A die lokale IP-Adresse des Wemo und B die IP-Adresse eines der anderen vier Geräte ist:
iptables -I FORWARD -s A -d B -j logdrop
iptables -I FORWARD -s B -d A -j logdrop
Die Antworten sollen Unicast sein, daher hätte ich gedacht, dass die Antwort an M-SEARCH verloren geht. Vielleicht verwende ich die falsche Tabelle?
iptables -I INPUT -s A -d B -j logdrop
iptables -I INPUT -s B -d A -j logdrop
repeat for OUTPUT, PREROUTING, POSTROUTING
Nö. Habe versucht, UDP hinzuzufügen (und separat TCP oder keines von beiden, nur zur Sicherheit – unter Beibehaltung der obigen Tabellenvariationen):
iptables -I FORWARD -p udp -s A -d B logdrop
iptables -I FORWARD -p udp -s B -d A logdrop
Das hat also immer noch nicht funktioniert. Vielleicht kann ich versuchen, die Multicast-Fähigkeit zu manipulieren?
iptables -I FORWARD -p udp -s A -d 239.255.255.250 -j logdrop
iptables -I FORWARD -p udp -s 239.255.255.250 -d A -j logdrop
iptables -I FORWARD -p udp -s B -d 239.255.255.250 -j logdrop
iptables -I FORWARD -p udp -s 239.255.255.250 -d B -j logdrop
also the INPUT/OUTPUT/PRE/POSTROUTING tables
Nein.
Ich habe also viele Kombinationen ausprobiert (nicht jede Permutation dessen, was ich gezeigt habe, aber viele davon) und konnte in der Regel nicht verhindern, dass sie sich gegenseitig finden. Ich habe sogar versucht, UPNP auf dem Router vollständig zu deaktivieren. Selbst das schien nicht zu funktionieren. Ich weiß nicht, wie diese verdammten Geräte kommunizieren! Ich würde Packet Sniffing durchführen, aber es ist WLAN und ich verwende Windows, also ist das anscheinend schwierig. Ich hatte etwas Glück mit allgemeineren Regeln, z. B., iptables -I FORWARD -d A -j logdropaber sie sind zu drastisch und haben natürlich die Verbindungsfähigkeit von IFTTT beeinträchtigt, und ich hatte selbst dann Schwierigkeiten herauszufinden, welche Regeln den Zauber bewirkten.
Nachdem ich also zwei Nächte lang auf eigene Faust herumprobiert habe, ist es an der Zeit, um Hilfe zu bitten. Wie richte ich die Firewall-Regeln richtig ein? Oder was verstehe ich grundsätzlich falsch, wenn es um SSDP oder Routing-Regeln (oder theoretisch Alexa) geht?
Antwort1
Das erste Problem ist, dass diese Pakete nichtweitergeleitetan erster Stelle.
iptables -I FORWARDbefasst sich mit Paketen, die auf der IP-Ebene weitergeleitet werden – also wenn das Gerät als Router zwischen zwei IP-Netzwerken fungiert. Pakete innerhalb derDasselbeSubnetz erreichen nicht einmal den Router – sie werden auf der Verbindungsebene von den Wi-Fi-APs und Ethernet-Switches selbst weitergeleitet.
Also dukönntePakete filtern können, die die Software erreichen ebtables– zum Beispiel passieren Pakete, die zwischen dem Wi-Fi-AP und dem eingebauten Ethernet-Switch hin- und hergehen, normalerweise eine Linux-Bridge-Schnittstelle, und es gibt tatsächlich mehrere Websites, die sich mit diesem Thema befassen (z.B).
Dies blockiert beispielsweisealleath*Über (drahtlose Atheros-)Schnittstellen ausgehende Multicast-Pakete :
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
Leider können Sie das Gleiche für in der Hardware weitergeleitete Pakete im Allgemeinen nicht tun – nicht einmal ebtables sieht diese.
Wenn es sich bei allen beteiligten Paketen um reguläre Unicast-Pakete handeln würde, würde ich vorschlagen, ein zweites Subnetz einzurichten und den Router die Pakete zwischen den beiden Netzwerken routen zu lassen. Dies könnte jedoch problematisch sein, wenn Multicast beteiligt ist – die meisten Multicast-Weiterleitungs- oder Proxy-Funktionen scheinen unidirektional zu sein; vollständiges Multicast-Routing übersteigt die Fähigkeiten von DD-WRT; und außerdem haben viele Discovery-Pakete sogar eine TTL von 1, sodass kein Router sie ohnehin über das erste Netzwerk hinaus weiterleiten würde.
(Nebenbemerkung: iTunes verwendet im Allgemeinen kein SSDP, sondern DNS-SD über mDNS.)
Antwort2
Ich hatte ein ähnliches Problem mit meinen Echo Dots. Wenn sie eine Erkennung durchführen, trennen sich meine Sony SA-NS400-Lautsprecher vom Netzwerk und kommen normalerweise nicht zurück. Sie sind alle auf derselben WLAN-Schnittstelle. Dies kann in Wireshark und Intel Device Sniffer angezeigt werden. Der Amazon-Support war hilfreich, hat aber nichts bewirkt. Ich glaube, es ist speziell das Paket urn:Belkin:device:**, das dies verursacht (habe es noch nicht selbst neu erstellt, um dies zu bestätigen). Meine Lösung bestand darin, diese Regel für jeden meiner Dots einzugeben (XXXX ist die IP eines Dots):
ebtables -A FORWARD --protocol IPv4 --ip-source X.X.X.X --ip-destination 239.255.255.250 -j DROP
Dies blockiert nur die Erkennung von den Punkten und ermöglicht die Erkennung durch andere Geräte. Wenn ich tatsächlich eine Erkennung von einem Punkt aus durchführen muss, führe ich ein Skript aus, um die ebtables zu ändern, und ändere es dann wieder zurück, wenn ich fertig bin. Ich habe noch keinen Weg gefunden, dies zu umgehen und dem Multicast zu erlauben, zu anderen Schnittstellen durchzukommen, sodass Änderungen an meinem Hue-Emulator übernommen werden können, ohne Änderungen an ebtables vorzunehmen.