Questão Derrubando seletivamente pacotes de descoberta do SSDP


Eu tenho vários dispositivos Alexa da Amazon (um Echo, dois pontos) e um comutador inteligente Belkin Wemo. O aplicativo Alexa permite que você faça a varredura de dispositivos domésticos inteligentes e adicionará automaticamente qualquer coisa que encontrar. Isso normalmente é tratado 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 todas as vezes.

Eu realmente quero que ele falhe, enquanto permitindo o controle remoto para o Wemo 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 ficarão conectados por mais de um minuto nessa rede. Então desisti disso e tentei fazê-lo através de regras de firewall - que estão bem fora da minha zona de conforto. Eu também não estou familiarizado com o SSDP / UPNP, mas estou recebendo a idéia rapidamente. Estou usando o DD WRT no roteador. Eu atribuí cada dispositivo Alexa, meu telefone e o Wemo a um endereço IP estático.

Dado que eu não sei os detalhes do mecanismo de descoberta do Alexa, eu suponho que preciso deixar as mensagens M-SEARCH do Echo e enviar comunicados NOTIFY do Wemo. Gostaria de manter a descoberta de dispositivos em geral funcionando na minha rede. Eu uso os controles remotos do iTunes e o Plex e posso adicionar mais dispositivos semelhantes. Eu também não tenho certeza de qual dispositivo Alexa / telefone iria iniciar a descoberta, então 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 eu suponho 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 endereços IP de quatro dispositivos:

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

As respostas devem ser unicast, então eu teria pensado que isso diminuiria a resposta para o M-SEARCH. Talvez eu esteja usando a mesa 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 separadamente TCP, ou nenhum, apenas para uma boa medida - 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 com a 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 eu tentei muitas combinações (não todas as permutações do que eu mostrei, mas muitas delas) e como regra não consegui impedi-las de se encontrarem. Heck, eu até tentei desabilitar o UPNP completamente no roteador. Mesmo isso não parecia funcionar. Eu não sei como esses dispositivos estão se comunicando! Eu cheirava pacotes, mas é wifi e eu estou no Windows, então aparentemente é difícil. Eu tive alguma sorte com regras mais gerais, por exemplo iptables -I FORWARD -d A -j logdrop mas eles são muito drásticos e, claro, quebraram a capacidade do IFTTT de se conectar, e eu tive dificuldade em descobrir quais regras estavam fazendo a mágica até então.

Então, depois de duas noites tentando por conta própria, é hora de pedir ajuda. Qual é o caminho certo para configurar as regras de firewall? Ou o que eu sou fundamentalmente mal entendido sobre SSDP ou regras de roteamento (ou teoricamente Alexa)?


2


origem




Respostas:


O primeiro problema é que esses pacotes não são encaminhado em primeiro lugar.

iptables -I FORWARD lida com pacotes encaminhados na camada IP - ou seja, quando o dispositivo atua como um roteador entre duas redes IP. No entanto, os pacotes dentro do mesmo As sub-redes nem chegam ao roteador - elas são encaminhadas na camada de enlace pelos próprios APs Wi-Fi e pelos próprios switches Ethernet.

Então você poderia ser capaz de filtrar pacotes que chegam ao software usando ebtables - por exemplo, geralmente pacotes atravessando entre o Wi-Fi AP e o builtin Ethernet switch passam por uma interface 'bridge' do Linux, e de fato existem vários sites falando sobre isso (por exemplo.).

Por exemplo, isso bloqueia todos pacotes multicast saindo via ath* (Atheros sem fio) interfaces:

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

Infelizmente, você geralmente não pode fazer o mesmo para os pacotes encaminhados em hardware - nem mesmo ebtables os vêem.

Agora, se todos os pacotes envolvidos fossem unicast regulares, eu sugeriria configurar uma segunda sub-rede e deixar o roteador rotear coisas entre as duas redes. No entanto, isso pode ser problemático quando a multidifusão está envolvida - a maioria das funções de "encaminhamento" ou "proxy" multicast parece unidirecional; roteamento multicast completo está além das habilidades do DD-WRT; Além disso, muitos pacotes de descoberta têm um TTL de 1, de modo que nenhum roteador os ultrapassará além da primeira rede.

(Como uma nota lateral, o iTunes geralmente não usa o SSDP - ele usa o DNS-SD sobre o mDNS.)


2



Isso faz muito sentido, obrigado. Eu até tive uma classe de rede sólida e provavelmente deveria ter visto isso; Ah bem. Há uma parte de mim que está feliz que eu estava completamente errado e não apenas um erro de digitação! Por que você em itálico ebtables só poderia trabalhos? Você está sugerindo que, dependendo do modelo / chipset do roteador, pode haver uma ponte que possamos configurar ou pode ser apenas hardware? - ojchase
Eu não me importaria com o TTL de 1, pois isso deixaria o pacote como desejado! Mas o segundo caminho de sub-rede é um não-inicial, dado que o Wemo não manterá a conexão. Eu suspeito de um pacote descartado, mas entre a falta de conhecimento do que está fazendo, o suporte técnico inútil da Wemo ea dificuldade de farejar pacotes, eu não acho que vou tentar isso. Obrigado pela dica embora. Provavelmente vou tentar ebtables ou chegar a uma solução completamente diferente (talvez não técnica) para o verdadeiro problema. Independentemente disso, você respondeu a pergunta, então muito obrigado! - ojchase


Eu tive um problema semelhante com os meus pontos de eco. Quando eles 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 chegou a lugar nenhum. Eu acredito que é especificamente a urna: Belkin: device: ** pacote que faz isso (não recriou-me para confirmar ainda). Minha solução foi colocar esta regra em cada um dos meus pontos (X.X.X.X é 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 eu realmente preciso fazer uma descoberta a partir de um ponto, eu corro um script para alterar os ebtables, e depois mudo de volta quando terminar. Eu ainda não encontrei uma maneira de contornar isso e permitir que o multicast passasse para outras interfaces, para que as alterações no meu emulador de hue possam ser selecionadas sem fazer alterações nos ebtables.


1



Acompanhamento: Encontrei uma maneira de filtrar seletivamente o SSDP a partir dos pontos / ecos, mas permiti-lo a outros dispositivos. Eu coloco os dispositivos que eu quero filtrar de seu SSDP em outra interface (no meu caso, uma rede de convidado) e adiciono isso a ebtables para cada ponto / echo: ebtables -I FORWARD -o wl0.1 --protocolo IPv4 --ip- origem XXXX --ip-destino 239.255.255.250 -j DROP - 5iver
Segundo acompanhamento: A causa deste problema é que os dispositivos da Amazon estão enviando pacotes SSDP malformados. Especificamente, os dispositivos da Belkin usam um alvo de pesquisa da Belkin, que deve ser um FQDN de acordo com a especificação upnp. Isso pode ser visto no Wireshark e no Intel Device Sniffer para UPNP. Eu posso recriar o problema enviando o seguinte pacote SSDP através do netcat e ter um ticket de suporte aberto com a Amazon: M-SEARCH * HTTP / 1.1 HOST: 239.255.255.250:1900 MAN: "ssdp: discover" MX: 15 ST: urn : Belkin: dispositivo: ** - 5iver