Tenho vários dispositivos Amazon Alexa (um Echo, dois pontos) e um switch inteligente Belkin Wemo. O aplicativo Alexa permite que você procure dispositivos domésticos inteligentes e adicionará automaticamente tudo o que encontrar. Isso normalmente é feito pela comunicação entre o aplicativo, a Amazon e a nuvem de rede do dispositivo, mas aparentemente o Wemo em particular usa a descoberta de dispositivos SSDP. Alexa encontra o Wemo quase sempre.
Na verdade, quero que falhe, ao mesmo tempo que permito o controle remoto do Wemo a partir do IFTTT. Sim, eu sei que é um caso de uso estranho :) Minha tentativa inicial foi configurar uma rede secundária e colocar o Wemo nela. Mas, por algum motivo, o Wemo e o roteador não permanecerão conectados por mais de um minuto nessa rede. Então desisti disso e tentei fazer isso por meio de regras de firewall - que estão bem fora da minha zona de conforto. Também não estou familiarizado com SSDP/UPNP, mas estou entendendo rapidamente. Estou usando DD WRT no roteador. Atribuí a cada dispositivo Alexa, meu telefone e ao Wemo um endereço IP estático.
Dado que não conheço os detalhes do mecanismo de descoberta de Alexa, presumo que preciso abandonar o recebimento de mensagens M-SEARCH do Echo e o envio de anúncios NOTIFY do Wemo. Gostaria de manter a descoberta de dispositivos funcionando normalmente na minha rede; Eu uso controles remotos do iTunes e Plex e posso adicionar mais dispositivos semelhantes. Também não tenho certeza de qual dispositivo Alexa/telefone iniciaria a descoberta, por isso estou feliz em bloquear todos eles.
Então, o que eu preciso é de algumas regras de roteador que eliminem a comunicação SSDP entre dois dispositivos, sem desabilitar todo o protocolo ou a comunicação HTTP normal (que presumo que o IFTTT esteja usando) para qualquer um dos dispositivos.
O que eu tentei, onde A é o endereço IP local do Wemo e B é um dos outros quatro endereços IP do dispositivo:
iptables -I FORWARD -s A -d B -j logdrop
iptables -I FORWARD -s B -d A -j logdrop
As respostas deveriam ser unicast, então eu teria pensado que isso descartaria a resposta para o M-SEARCH. Talvez eu esteja usando a tabela errada?
iptables -I INPUT -s A -d B -j logdrop
iptables -I INPUT -s B -d A -j logdrop
repeat for OUTPUT, PREROUTING, POSTROUTING
Não. Tentei adicionar UDP (e TCP separadamente, ou nenhum deles, apenas para garantir - mantendo as variações da tabela acima):
iptables -I FORWARD -p udp -s A -d B logdrop
iptables -I FORWARD -p udp -s B -d A logdrop
Então isso ainda não funcionou. Talvez eu possa tentar mexer na capacidade de 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
Não.
Então, tentei muitas combinações (não todas as permutações do que mostrei, mas muitas delas) e, como regra, não consegui evitar que elas se encontrassem. Caramba, eu até tentei desabilitar totalmente o UPNP no roteador. Mesmo isso não pareceu funcionar. Não sei como esses malditos dispositivos estão se comunicando! Eu farejaria pacotes, mas é wifi e estou no Windows, então aparentemente isso é difícil. Tive alguma sorte com regras mais gerais, por exemplo, iptables -I FORWARD -d A -j logdropmas elas são muito drásticas e, claro, quebraram a capacidade de conexão do IFTTT, e tive dificuldade em descobrir quais regras estavam fazendo a mágica mesmo então.
Então, depois de duas noites tentando sozinho, é hora de pedir ajuda. Qual é a maneira correta de configurar as regras de firewall? Ou o que estou entendendo mal sobre SSDP ou regras de roteamento (ou teoricamente Alexa)?
Responder1
O primeiro problema é que esses pacotes não sãoroteadoem primeiro lugar.
iptables -I FORWARDlida com pacotes encaminhados na camada IP – ou seja, quando o dispositivo atua como um roteador entre duas redes IP. No entanto, os pacotes dentro domesmoA sub-rede nem chega ao roteador – eles são encaminhados na camada de link pelos próprios APs Wi-Fi e switches Ethernet.
Então vocêpoderser capaz de filtrar pacotes que chegam ao software usando ebtables- por exemplo, normalmente os pacotes que cruzam entre o AP Wi-Fi e o switch Ethernet integrado passam por uma interface 'ponte' do Linux, e de fato existem vários sites falando sobre isso (por exemplo).
Por exemplo, isso bloqueiatodospacotes multicast saindo por meio de ath*interfaces (sem fio Atheros):
ebtables -A FORWARD -o ath+ -d Multicast -j DROP
Infelizmente você geralmente não pode fazer o mesmo com pacotes encaminhados em hardware – nem mesmo o ebtables os vê.
Agora, se todos os pacotes envolvidos fossem unicast regulares, sugiro configurar uma segunda sub-rede e deixar o roteador rotear coisas entre as duas redes. No entanto, isso pode ser problemático quando o multicast está envolvido – a maioria das funções de "encaminhamento" ou "proxy" de multicast parecem unidirecionais; o roteamento multicast completo está além das capacidades do DD-WRT; e além disso, muitos pacotes de descoberta têm até um TTL de 1, então nenhum roteador não os passará além da primeira rede.
(Como observação, o iTunes geralmente não usa SSDP – ele usa DNS-SD sobre mDNS.)
Responder2
Eu tive um problema semelhante com meus pontos de eco. Quando fazem uma descoberta, meus alto-falantes Sony SA-NS400 se desconectam da rede e geralmente não voltam. Eles estão todos na mesma interface wifi. Isso pode ser visto no Wireshark e no Intel Device Sniffer. O suporte da Amazon foi útil, mas não levou a lugar nenhum. Acredito que seja especificamente o pacote urn:Belkin:device:** que faz isso (ainda não o recriei para confirmar). Minha solução foi colocar esta regra para cada um dos meus pontos (XXXX é o IP de um ponto):
ebtables -A FORWARD --protocol IPv4 --ip-source X.X.X.X --ip-destination 239.255.255.250 -j DROP
Isso bloqueia apenas a descoberta dos pontos e permite a descoberta por outros dispositivos. Quando realmente preciso fazer uma descoberta a partir de um ponto, executo um script para alterar as ebtables e, em seguida, altero-o novamente quando terminar. Ainda não encontrei uma maneira de contornar isso e permitir que o multicast passe para outras interfaces, para que as alterações no meu emulador de matiz possam ser captadas sem fazer alterações nas ebtables.