Selectively dropping SSDP Discovery Packets

Question

I have several Amazon Alexa devices (an Echo, two Dots) and a Belkin Wemo smart switch. The Alexa app allows you to scan for smart home devices, and it will automatically add anything it finds. This is normally handled by communication between the app, Amazon, and the device's network cloud, but apparently the Wemo in particular uses SSDP device discovery instead. Alexa finds the Wemo almost every time.

I actually want it to fail, while allowing remote control to the Wemo from IFTTT. Yes, I know that's a weird use case :) My initial attempt was to set up a secondary network and stick the Wemo on it. But for some reason the Wemo and router won't stay connected for more than about a minute on that network. So I gave up on that and tried to do it via firewall rules - which are well outside my comfort zone. I'm also unfamiliar with SSDP/UPNP, but am getting the idea quickly. I'm using DD WRT on the router. I've assigned each Alexa device, my phone, and the Wemo a static IP address.

Given that I don't know the details of Alexa's discovery mechanism, I assume I need to drop both receiving M-SEARCH messages from the Echo and sending NOTIFY announcements from the Wemo. I would like to keep device discovery generally working on my network; I use iTunes remotes and Plex and may add more similar devices. I'm also not sure which Alexa/phone device would initiate discovery, so I'm happy blocking all of them.

So what I need is some router rules that drop SSDP communication between two devices, without disabling the entire protocol or normal HTTP communication (which I assume IFTTT is using) to either device.

What I've tried, where A is the Wemo's IP local IP address and B is one of the other four device's IP addresses:

iptables -I FORWARD -s A -d B -j logdrop
iptables -I FORWARD -s B -d A -j logdrop

The responses are supposed to be unicast, so I would have thought that would drop the response to the M-SEARCH. Maybe I'm using the wrong table?

iptables -I INPUT -s A -d B -j logdrop
iptables -I INPUT -s B -d A -j logdrop
repeat for OUTPUT, PREROUTING, POSTROUTING

Nope. Tried adding UDP (and separately TCP, or neither, just for good measure - while keeping the above table variations):

iptables -I FORWARD -p udp -s A -d B logdrop
iptables -I FORWARD -p udp -s B -d A logdrop

So that still didn't work. Maybe I can try messing with the ability to multicast?

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

Nope.

So I've tried a lot of combinations (not every permutation of what I've shown, but a lot of them) and as a rule have been unable to keep them from finding each other. Heck, I even tried disabling UPNP entirely on the router. Even that didn't seem to work. I don't know how these darn devices are communicating! I'd packet sniff, but it's wifi and I'm on Windows, so apparently that's hard. I've had some luck with more general rules, e.g. iptables -I FORWARD -d A -j logdrop but they're too drastic and of course broke IFTTT's ability to connect, and I had difficulty figuring out which rules were doing the magic even then.

So after two night's of trying on my own, it's time to ask for help. What's the right way to set up the firewall rules? Or what am I fundamentally misunderstanding about SSDP or routing rules (or theoretically Alexa)?

Answer 1

The first problem is that those packets aren't routed in the first place.

iptables -I FORWARD deals with packets forwarded at the IP layer – i.e. when the device acts as a router between two IP networks. However, packets within the same subnet don't even reach the router – they're forwarded at the link layer by the Wi-Fi APs & Ethernet switches themselves.

So you might be able to filter packets which reach the software using ebtables – for example, usually packets crossing between the Wi-Fi AP and the builtin Ethernet switch go through a Linux 'bridge' interface, and there in fact are various websites talking about this (e.g.).

For example, this blocks all multicast packets exiting via ath* (Atheros wireless) interfaces:

ebtables -A FORWARD -o ath+ -d Multicast -j DROP

Unfortunately you generally cannot do the same for packets forwarded in hardware – not even ebtables sees those.

Now, if all the packets involved were regular unicast, I'd suggest setting up a second subnet and letting the router route stuff between the two networks. However this might be troublesome when multicast is involved – most multicast "forwarding" or "proxying" functions seem unidirectional; full-blown multicast routing is beyond DD-WRT's abilities; and on top of that, many discovery packets even have a TTL of 1 so no router won't pass them beyond the first network anyway.

(As a side note, iTunes generally doesn't use SSDP – it uses DNS-SD over mDNS.)

Answer 2

I had a similar issue with my Echo dots. When they do a discovery, my Sony SA-NS400 speakers disconnect from the network and usually do not come back. They are all on the same wifi interface. This can be seen in Wireshark and Intel Device Sniffer. Amazon support was helpful but it didn't go anywhere. I believe it is specifically the urn:Belkin:device:** packet that does this (haven't recreated it myself to confirm yet). My solution was to put this rule in for each of my dots (X.X.X.X is the IP of a dot):

ebtables -A FORWARD --protocol IPv4 --ip-source X.X.X.X --ip-destination 239.255.255.250 -j DROP

This blocks just the discovery from the dots and allows discovery by other devices. When I actually need to do a discovery from a dot, I run a script to change the ebtables, and then change it back when done. I have not yet found a way around this and to allow the multicast to get through to other interfaces, so that changes to my hue-emulator can be picked up without making changes to ebtables.