Brokers MQTT Expostos na Internet: Os Riscos da Porta 1883 Aberta

Brokers MQTT expostos são servidores que aceitam conexões de qualquer lugar da internet, muitas vezes na porta 1883 sem criptografia e sem autenticação. Este artigo explica o que um atacante ou um curioso pode ver e fazer em um broker assim, como verificar se algum dos seus brokers está exposto e como corrigir isso. Você termina com um checklist curto de auditoria e uma regra clara sobre onde ficam os dados de teste e os dados de produção.

Por que brokers MQTT expostos continuam aparecendo

O MQTT foi projetado para ser simples. Uma instalação padrão de broker normalmente escuta na porta TCP 1883, e algumas configurações mais antigas ou voltadas a desenvolvimento permitem conexões anônimas de fábrica. Isso é perfeito em um notebook e perigoso em uma VM na nuvem com IP público.

Pesquisadores de segurança e mecanismos de busca que indexam serviços conectados à internet já relataram diversas vezes grandes quantidades de brokers que respondem na porta 1883 e aceitam conexões sem credenciais. O padrão por trás deles costuma ser o mesmo:

• Um desenvolvedor inicia o Mosquitto ou outro broker em uma VM para fazer um protótipo funcionar.
• O firewall ou security group da nuvem é aberto para a porta 1883 "temporariamente" para que os dispositivos em campo possam alcançá-lo.
• O acesso anônimo continua ativado porque os dispositivos nunca receberam credenciais.
• O protótipo vira produção sem alarde.

Nenhuma dessas etapas parece arriscada isoladamente. Juntas, elas criam um barramento de mensagens que qualquer um pode ler e escrever.

O que um broker aberto expõe

Para entender o risco, lembre-se do que um broker MQTT faz: ele encaminha cada mensagem publicada a todos os assinantes correspondentes. Se qualquer um pode se conectar, qualquer um pode virar assinante, e o curinga multinível # corresponde a todos os topics que o broker trata.

O lado da escrita costuma ser subestimado. Se um relé inteligente se inscreve em home/garage/door/set e o broker aceita publicadores anônimos, o portão é controlado por quem encontrar o broker. Em ambientes industriais, como uma estação de tratamento de água ou uma linha de envase, o mesmo padrão afeta setpoints e comandos de máquinas. É por isso que a segurança do MQTT envolve autorização tanto quanto criptografia.

Vazamentos de informação sem nenhum ataque

Não é preciso má intenção para que o estrago aconteça. Uma árvore de topics como acme/plant2/line4/press7/fault conta a um concorrente como é o layout da sua planta. Retained messages podem incluir versões de firmware, o que ajuda quem procura dispositivos com bugs conhecidos. Topics de depuração costumam trazer stack traces, endereços IP ou dumps completos de configuração. A suposição segura é que tudo o que é publicado em um broker aberto é público.

Como verificar se o seu próprio broker está exposto

Teste apenas brokers que são seus ou que você tem autorização explícita para testar. O objetivo aqui é confirmar a sua própria configuração de fora para dentro, do mesmo jeito que um scanner da internet a veria.

Execute estas verificações a partir de uma rede fora da sua rede corporativa ou de nuvem, como um hotspot de celular:

# 1. A porta MQTT sem criptografia está acessível pela internet?
nc -vz your-broker.example.com 1883

# 2. Ele aceita uma conexão anônima? (apenas no seu próprio broker)
mosquitto_sub -h your-broker.example.com -p 1883 -i audit-anon-check -t 'audit/probe' -W 5 -v

# 3. A porta TLS apresenta um certificado válido?
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null | head -20

Interprete os resultados assim:

1. Se o nc informar a porta aberta e você não pretendia oferecer MQTT sem criptografia publicamente, feche-a no firewall.
2. Se o mosquitto_sub se conectar e ficar esperando em vez de falhar com "not authorised", o acesso anônimo está ativado. Desative-o.
3. Se o certificado for autoassinado, estiver expirado ou não corresponder ao hostname, os clientes falham ou, pior, foram configurados para pular a verificação.

Revise também a configuração do broker diretamente. No Mosquitto 2.x, por exemplo, um listener sem allow_anonymous false e sem senha ou plugin de autenticação é um sinal de alerta. Verifique todos os listeners, inclusive os listeners WebSocket em portas como 8083 e 9001, que são frequentemente esquecidos.

Como corrigir um broker MQTT exposto

Siga estes passos na ordem. Os três primeiros eliminam a maior parte do risco em uma tarde.

1. Exija autenticação em todos os listeners. Emita um usuário e senha únicos, ou um certificado de cliente, por dispositivo ou por serviço. Credenciais compartilhadas tornam a revogação impossível. O guia de autenticação MQTT com usuário e senha cobre a configuração prática.
2. Feche a porta 1883 para a internet. Mantenha o MQTT sem criptografia no localhost ou em uma rede privada e exponha apenas TLS na porta 8883 (e WebSockets seguros se navegadores precisarem de acesso).
3. Ative o TLS com um certificado de uma CA confiável. Os clientes devem verificar o certificado do servidor e o hostname. Veja configuração de TLS no MQTT para as configurações de cliente e de broker.
4. Restrinja o que cada identidade pode publicar e assinar. Em um broker auto-hospedado, use ACLs para que um sensor de temperatura não possa se inscrever em # nem publicar comandos. O guia de ACL MQTT mostra padrões comuns.
5. Remova dados sensíveis dos payloads e dos topics retidos. Limpe as retained messages de que você não precisa mais publicando uma retained message vazia no topic.
6. Aplique limites. Limite conexões, tamanho de mensagem e taxa de mensagens para que um único cliente não consiga esgotar o broker.
7. Atualize e monitore. Mantenha a versão do broker em dia e fique de olho em falhas de login repetidas.

Se essa lista parece um trabalho contínuo em vez de uma correção pontual, é porque é. Esse é um dos principais motivos pelos quais as equipes migram para um broker MQTT gerenciado em vez de operar elas mesmas um servidor exposto à internet.

Brokers públicos de teste versus brokers privados

Existe uma distinção importante entre um broker exposto por acidente e um broker deliberadamente público. Um servidor MQTT público foi projetado para ser aberto: qualquer um pode se conectar, qualquer um pode se inscrever, e todos entendem que os dados ficam visíveis. É uma ferramenta para aprendizado e experimentos rápidos.

O ConnectMQ mantém um servidor MQTT público gratuito em broker.connectmq.com. Ele aceita clientes anônimos com qualquer client ID único e não vazio e aplica limites conservadores por cliente, como 64 KB por mensagem, 10 mensagens por segundo e 10 assinaturas. Isso o torna ideal para testar código:

mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-7f3a -t 'connectmq/demo/7f3a/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-7f3a -t 'connectmq/demo/7f3a/hello' -m 'test message'

A regra é simples: o servidor MQTT público é apenas para dados de teste. Nunca publique dados reais de clientes, credenciais, localizações ou comandos de controle de equipamentos reais em qualquer broker público. Use um prefixo de topic único, como connectmq/demo/<random-id>/, para que os seus experimentos não colidam com os de outras pessoas.

Quando o seu projeto vai além dos experimentos, ele precisa de um broker privado com autenticação e TLS. No ConnectMQ, criar um broker gera credenciais para você, e os client IDs ficam vinculados a essas credenciais, então um client ID vazado sozinho não basta para se conectar.

O que muda com um broker MQTT gerenciado

Migrar para um broker MQTT gerenciado não deixa você seguro automaticamente, mas elimina as causas mais comuns de exposição. Em um broker privado do ConnectMQ:

• As conexões exigem o usuário e a senha gerados no portal.
• O TLS está disponível na porta 8883 e WebSockets seguros na 8084, com certificado Let's Encrypt, para que os clientes verifiquem o servidor sem arquivos de CA personalizados.
• Os tenants são isolados entre si no cluster multi-tenant.
• Cotas por plano, proteção contra flood e bloqueio de IP após repetidas falhas de login limitam abusos.

A sua parte continua sendo sua: proteja as credenciais nos dispositivos, use TLS em produção e projete os topics para que não vazem informações. Para uma visão completa das opções, o guia de broker MQTT na nuvem compara modelos de implantação, e o artigo de boas práticas de segurança MQTT aprofunda o lado do cliente.

Checklist rápido de auditoria

Use esta lista para cada broker que você opera:

1. Nenhum listener aceita conexões anônimas, a menos que seja intencionalmente público.
2. A porta 1883 não está acessível pela internet; o TLS é obrigatório nos endpoints públicos.
3. Cada dispositivo ou serviço tem as próprias credenciais, e você sabe como revogá-las.
4. Os clientes verificam o certificado do servidor e o hostname.
5. Nenhum segredo, dado pessoal ou topic de controle é publicado em brokers públicos de teste.
6. As retained messages não contêm nada que você não gostaria que um estranho lesse.
7. Limites de conexão, tamanho e taxa estão configurados.
8. As falhas de login ficam visíveis e falhas repetidas são bloqueadas.

Comece com um broker privado do ConnectMQ

Se o seu protótipo roda hoje em um broker aberto, a correção mais rápida é migrá-lo para um broker privado. Crie um broker no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, copie as credenciais geradas e troque seus clientes para mqtts:// na porta 8883. O seu código de teste continua funcionando no servidor MQTT público broker.connectmq.com enquanto os dados de produção ficam privados.

Perguntas frequentes

A porta 1883 é sempre insegura?

A porta 1883 transporta MQTT sem criptografia, então credenciais e payloads trafegam em texto claro. Ela é aceitável no localhost ou em uma rede isolada, mas endpoints expostos à internet devem usar TLS na porta 8883.

Como sei se estranhos estão lendo o meu broker?

Sem autenticação, não há como saber com segurança, porque qualquer cliente pode se inscrever em # silenciosamente. Trate um broker anônimo exposto à internet como já comprometido e faça a rotação de qualquer segredo que tenha passado por ele.

É seguro usar o broker.connectmq.com no meu projeto?

É seguro para aprendizado e testes com dados não sensíveis. Como ele é público por design, tudo o que é publicado ali pode ser lido por outras pessoas, então sistemas de produção devem usar um broker privado com credenciais.

Desativar o acesso anônimo impede todos os ataques?

Não, mas elimina o mais fácil. Combine autenticação com TLS, autorização por cliente, limites e atualizações para ter proteção real.