Alguns dos meus dispositivos inteligentes estavam se esgueirando pelo meu buraco Pi e bloqueá-los foi mais fácil do que eu pensava

Quando apresentei o Pi-hole à minha rede doméstica, pensei nisso como uma coisa do tipo configure e esqueça, conforme sugerido pela maioria das discussões da comunidade. Instalei o Pi-hole em meu servidor Debian doméstico, adicionei algumas listas de bloqueio confiáveis ​​e configurei-o como o DNS padrão em meu gateway WAN duplo. E por um tempo realmente parecia que o trabalho estava feito. Os anúncios desapareceram, rastreadores óbvios foram filtrados e o painel me mostrou milhares de consultas bloqueadas.

Por curiosidade, vim verificar aleatoriamente o painel. Esse hábito deixou de ser apenas uma curiosidade quando filtrei o log de consultas pelo endereço IP local de cada dispositivo, especificamente dos meus dispositivos inteligentes. Percebi que meus dispositivos IoT falavam o dia todo, mesmo quando estavam ociosos. Comecei a investigar essas dúvidas e a investigação acabou sendo muito mais interessante do que a correção em si.

Minha lista de bloqueio mentiu para mim

O log de consulta contou uma história diferente

Quando construí meu laboratório doméstico, o DNA não fazia parte da minha pilha original. O Pi-hole começou como um bloqueador de anúncios e gradualmente evoluiu para meu DNS padrão para toda a minha rede doméstica. Mesmo quando o usava apenas como bloqueador de anúncios, verificava o log de consultas de vez em quando, não para evitar nada, mas como um hábito. Ao configurar o Pi-hole, usei as listas de bloqueio mais recomendadas: a grande lista do OISD e as listas de bloqueio de host unificadas de Steven Black. E presumi que se algum dos meus dispositivos usasse Pi-hole, as listas de bloqueio da comunidade já seriam suficientes para capturar telemetria e rastrear tráfego.

Tudo correu bem e funcionou conforme o esperado até que tentei filtrar as consultas por dispositivo usando seus endereços IP locais. Tenho vários dispositivos IoT, como um Amazon Echo Dot, dois Amazon Fire TV Sticks, vários switches inteligentes como o Tapo P110, lâmpadas inteligentes e caixas de Android TV. Filtrar por endereços IP individuais me contou uma história diferente. Escolhi especificamente três dos meus dispositivos IoT mais usados ​​– o Echo Dot, o Fire TV Stick e o Tapo P110 – e comecei a pesquisar. Juntos, eles eram responsáveis ​​por milhares de solicitações por dia, e notei vários domínios da Amazon aparecendo repetidamente ao lado dos domínios de nuvem TP-Link Tapo. A parte surpreendente foi que a maioria dos pedidos foi facilmente transferida para o Pi-hole.

Tapo contatou domínios como use1-cvm-api, aps1-device-cloudgatewaye security.iot.i.tplinknbu.com ao longo do dia. Os domínios AWS de diagnóstico Echo Dot estavam se repetindo descontroladamente, por exemplo web.diagnostic.networking.aws.dev e suas variantes regionais (ap-south-2, ap-east-2) disparando quase a cada minuto. Mas no caso do FireTV Stick, havia vários pedidos a cada minuto, mas felizmente alguns deles já estavam filtrados pelo Pi-hole, por exemplo. mobile-collector.newrelic.com e api.statsig.com. Esses eram SDKs analíticos genéricos de terceiros, portanto, as listas de bloqueio da comunidade já os cobriam. Mas ainda havia alguns que as listas de bloqueio não afetaram, como os domínios de infraestrutura da própria Amazon unagi-eu.amazon.com e misturado a2z.com domínios identificadores de dispositivos.

Depois de tudo isso, fui desafiado a descobrir quais dos domínios restantes poderiam desaparecer sem levar o dispositivo consigo. Porque um palpite errado e eu poderia inutilizar meu Echo Dot.

Nem todo domínio merece passe livre

Um palpite errado e Alexa cala a boca

Olhando os registros, meu primeiro instinto foi bloquear tudo. Mas esses eram dispositivos inteligentes que precisavam da Internet para funcionar corretamente, e bloquear tudo significava bloqueá-los do mínimo necessário para funcionar. Se eu bloquear o endpoint errado, isso poderá interromper o assistente de voz ou interromper o gerenciamento da nuvem, as atualizações de firmware ou a autenticação da conta.

Então, comecei a descobrir qual domínio faz o quê e comecei a colocá-los em dois segmentos. Telemetria limpa que era segura para eliminar, como endpoints de diagnóstico da AWS (web.diagnostic.networking.aws.dev), serviços de identificação de dispositivo (*.us-east-1.prod.service.minerva.devices.a2z.com) e relatórios de histórico (unagi-eu.amazon.com). E os domínios que o dispositivo realmente precisava para executar, como a API Alexa (api.amazonalexa.com), Gateway de nuvem TP-Link (aps1-device-cloudgateway.iot.i.tplinknbu.com) e qualquer coisa que obviamente manipule comandos, autenticação ou comunicação de dispositivo (use1-cvm-api.i.tplinknbu.com).

Mais alguns sinais me ajudaram a diferenciá-los, como a frequência com que apareciam e se as solicitações ocorriam mesmo quando o dispositivo estava ocioso. E alguns domínios apenas falaram sobre o que foi feito: security.iot.i.tplinknbu.compor exemplo, não parecia seguro bloquear com base em um palpite; parecia aquilo em que Tapo estava realmente viciado. Algumas horas de pesquisa na Internet, além de um pouco do meu instinto, e eu estava pronto para filtrá-los da minha rede.

A correção foi menor que a investigação

Eu não precisava de uma lista de bloqueio melhor. Eu precisava de seis linhas

Depois de terminar minha investigação, eu tinha uma lista de domínios que eram seguros para bloquear e outra lista de domínios necessários para o funcionamento dos dispositivos. Mas ainda havia alguns que precisavam ser verificados porque o nome contava uma história diferente. Passei por diversas discussões na comunidade e documentação oficial antes de tomar minha decisão final.

Security.iot.i.tplinknbu.com parecia importante à primeira vista, e mais tarde descobri que era. Mensagens recomendadas estava envolvido na conectividade em nuvem da Tapo e seu bloqueio poderia interromper a operação normal dos switches inteligentes. Outro foi msh.amazon.co.uk. Pareceu importante no início, mas acabou sendo menos crítico do que o esperado. Bloqueá-lo não mataria meu Fire TV Stick, mas poderia retardar a instalação de aplicativos, então decidi dar um passe grátis.

Como os domínios não especificados estão fora do meu caminho e a lista de domínios a serem bloqueados é boa, a implementação no painel Pi-hole demorou alguns minutos. Adicionei seis entradas à lista de negações do Pi-hole. Quatro deles eram domínios de correspondência exata e dois deles eram curingas.

api.statsig.com
mobile-collector.newrelic.com
firetvcaptiveportal.com
unagi-eu.amazon.com
(\.|^)prod\.service\.minerva\.devices\.a2z\.com$
(\.|^)diagnostic\.networking\.aws\.dev$

Esperei algumas horas para que tudo se resolvesse. Os resultados foram limpos. A maioria das consultas desnecessárias foram bloqueadas no Echo Dot, Fire TV Stick e Tapo P110. Os domínios de telemetria agora exibem consistentemente “Permitir” em vez de “Permitir”. E o mais importante, todos os dispositivos funcionaram conforme o esperado. No final, a correção consistiu em apenas seis linhas adicionadas à lista de negações do Pi-hole. A parte mais difícil não foi adicioná-los à lista de bloqueios, mas passar horas descobrindo a qual deles pertencia.

Configure e esqueça que foi o verdadeiro erro

Pi-buraco falhou. Já filtrou milhares de rastreadores de terceiros. Os pontos cegos eram telemetria específica do fornecedor que as listas de bloqueio da comunidade em geral não foram projetadas para capturar. Depois de toda a investigação, meu antigo instinto de configurar e esquecer mudou para ler os logs de consulta de vez em quando. Gastar apenas alguns minutos nos registros pode revelar padrões que as listas de bloqueio da comunidade muitas vezes não percebem. No meu caso, seis linhas em três dispositivos foram suficientes. O resto da minha rede pode estar escondendo alguns dos seus.