Como proteger um dispositivo IoT com Raspberry Pi: checklist prático de blindagem

Para garantir a segurança de um dispositivo IoT com Raspberry Pi, você precisa fechar as portas fáceis que os atacantes procuram: logins por senha, portas abertas, pacotes desatualizados, serviços rodando como root e tráfego sem criptografia. Este checklist percorre cada camada com os comandos exatos para o Raspberry Pi OS Bookworm e termina com uma conexão MQTT criptografada com TLS que não exige nenhuma porta de entrada. Faça o processo uma vez e depois incorpore o resultado à sua imagem, para que cada novo dispositivo já comece blindado.

Modelo de ameaças para um Pi em campo

Um gateway Pi é um pequeno servidor Linux instalado em um lugar que você não controla totalmente: a rede de um cliente, o chão de fábrica, um armário à beira de uma rodovia. As ameaças realistas não são exóticas. Scanners automatizados testam senhas padrão e fracas via SSH. Serviços sem patch são explorados por vulnerabilidades conhecidas. Uma aplicação comprometida rodando como root assume o dispositivo inteiro. Credenciais deixadas em um script acabam em um repositório Git ou em um chamado de suporte. Tráfego MQTT sem criptografia é lido ou alterado em uma rede compartilhada. Alguém com acesso físico retira o cartão SD e lê o conteúdo.

Cada item do checklist abaixo ataca uma dessas ameaças. Nenhum deles exige hardware especial.

O checklist num relance

1. Contas

As imagens atuais do Raspberry Pi OS não vêm mais com o antigo usuário padrão pi e sua senha; você cria um usuário no Raspberry Pi Imager ou no primeiro boot. Escolha um nome de usuário pouco óbvio e uma senha longa e nunca distribua uma imagem mestre em que todos os dispositivos compartilham as mesmas credenciais. Se você cria imagens para uma frota, gere credenciais por dispositivo no momento do provisionamento.

# verifica quais contas podem fazer login
grep -vE "nologin|false" /etc/passwd
# bloqueia a senha de qualquer conta que deva usar apenas chaves
sudo passwd -l someuser

2. SSH somente com chaves

Copie sua chave pública para o Pi, confirme que consegue entrar com ela e depois desative a autenticação por senha com um arquivo drop-in, para que as atualizações de pacotes não sobrescrevam sua alteração.

# na sua estação de trabalho
ssh-keygen -t ed25519 -C "admin@workstation"
ssh-copy-id admin@gateway-01.local

# no Pi
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3
EOF
sudo sshd -t && sudo systemctl reload ssh

Mantenha a sessão atual aberta e teste um novo login em um segundo terminal antes de fechá-la. Se você não precisa de SSH nos dispositivos implantados, desative-o com sudo systemctl disable --now ssh e use um procedimento de manutenção que o habilite temporariamente.

3. Firewall

Um gateway MQTT só faz conexões de saída, então quase não precisa de regras de entrada. O ufw mantém a configuração legível:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.10.0/24 to any port 22 proto tcp   # somente a sub-rede de gestão
sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status verbose

Substitua a sub-rede pela sua rede de gestão. Em ambientes mais rigorosos, negue também o tráfego de saída e permita apenas DNS, NTP, os espelhos de pacotes e o seu broker MQTT na porta 8883. Adicione o fail2ban se o SSH precisar ser acessível a partir de redes mais amplas.

4. Atualizações

A maioria dos comprometimentos reais explora vulnerabilidades que já têm correção. Habilite as atualizações automáticas de segurança e agende upgrades completos regulares:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run --debug | tail -n 20

Inclua as dependências Python na rotina. Fixe as versões em um requirements.txt, teste as atualizações primeiro em um dispositivo e depois distribua para a frota.

5. Desabilite serviços não utilizados

Cada serviço em execução é algo a corrigir e algo a atacar. Liste o que está habilitado e desligue o que o seu gateway não precisa:

systemctl list-unit-files --state=enabled --type=service
sudo systemctl disable --now avahi-daemon cups 2>/dev/null
sudo systemctl disable --now bluetooth   # somente se você não usa BLE

Em dispositivos headless, você também pode desabilitar o Wi-Fi ou o Bluetooth no nível do hardware em config.txt, com dtoverlay=disable-wifi ou dtoverlay=disable-bt, quando o dispositivo usa apenas Ethernet.

6. Privilégio mínimo para a sua aplicação

Rode o cliente MQTT como um usuário de sistema dedicado, sem shell de login e apenas com os grupos de que ele precisa (por exemplo gpio ou dialout). Depois deixe o systemd isolá-lo em sandbox:

sudo useradd --system --home /opt/gateway --shell /usr/sbin/nologin gateway
sudo usermod -aG gpio gateway

[Service]
User=gateway
Group=gateway
EnvironmentFile=/etc/gateway/mqtt.env
ExecStart=/opt/gateway/.venv/bin/python -u /opt/gateway/gateway.py
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/gateway
ProtectKernelTunables=yes
ProtectControlGroups=yes
RestrictSUIDSGID=yes

ProtectSystem=strict deixa todo o sistema de arquivos somente leitura para o serviço, exceto os caminhos listados, de modo que um script comprometido não consegue alterar arquivos do sistema nem se instalar de forma persistente. Execute systemd-analyze security gateway.service para ver quais outras opções se aplicam. A unidade completa, incluindo as políticas de reinício, está em como executar um script Python MQTT na inicialização.

7. Mantenha os segredos fora do código

Guarde as credenciais do broker em um arquivo de ambiente legível apenas pelo root (o systemd o lê antes de reduzir os privilégios):

sudo mkdir -p /etc/gateway
sudo tee /etc/gateway/mqtt.env > /dev/null <<'EOF'
MQTT_HOST=broker.connectmq.com
MQTT_PORT=8883
MQTT_USERNAME=YOUR_USERNAME
MQTT_PASSWORD=YOUR_PASSWORD
MQTT_CLIENT_ID=YOUR_CLIENT_ID
EOF
sudo chmod 600 /etc/gateway/mqtt.env

Mantenha o arquivo fora do controle de versão e de qualquer imagem que você compartilhe. Se um dispositivo for perdido ou desativado, revogue as credenciais dele no lado do broker.

8. Proteja a conexão MQTT

O MQTT simples na porta 1883 envia credenciais e dados em texto claro. Use TLS na porta 8883. Os brokers ConnectMQ apresentam um certificado Let's Encrypt, em que o Pi já confia por meio do pacote de CAs do sistema, então nenhum arquivo de certificado é necessário:

import os
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=os.environ["MQTT_CLIENT_ID"])
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set()                       # verifica o certificado e o hostname do servidor
client.connect(os.environ["MQTT_HOST"], int(os.environ["MQTT_PORT"]), keepalive=60)
client.loop_forever()

Nunca chame tls_insecure_set(True) em produção; isso desativa a verificação do hostname e anula o propósito. Garanta que o relógio esteja correto, porque a validação do certificado falha se o Pi der boot com a data errada e o NTP ainda não tiver sincronizado. Use credenciais únicas para cada dispositivo: no ConnectMQ, os client IDs ficam vinculados às credenciais emitidas, e tentativas de login com falha repetidas a partir de um endereço levam ao bloqueio do IP. O guia de MQTT com TLS em Python aprofunda as opções de certificado, e as boas práticas de segurança MQTT tratam do lado do broker. Como o dispositivo só se conecta para fora, o firewall do passo 3 continua fechado.

Lembre que o servidor MQTT público pode ser lido por qualquer pessoa. Ele serve apenas para testes; dispositivos de produção devem ficar em um broker privado.

9. Monitoramento

Um dispositivo blindado ainda precisa de alguém de olho. Revise journalctl -u ssh em busca de logins inesperados, publique eventos de saúde e de segurança (tentativas de SSH com falha, reinícios de serviço, reinicializações inesperadas) em um topic MQTT e gere alertas para anomalias. Um topic de status retained com Last Will avisa imediatamente quando um dispositivo fica offline, o que pode ser o primeiro sinal de adulteração.

10. Segurança física

Se alguém consegue remover o armazenamento, consegue ler tudo o que há nele, incluindo as credenciais. Use um gabinete com tranca, considere dar boot pelo armazenamento interno em dispositivos baseados em Compute Module, desabilite USB e HDMI não utilizados quando o seu hardware permitir e trate qualquer dispositivo que tenha ficado fora do seu controle como não confiável até ser regravado. A documentação do Raspberry Pi explica as opções de configuração relevantes.

Estes passos combinam bem com as dicas de confiabilidade para Raspberry Pi e, juntos, formam a base para qualquer gateway construído a partir do tutorial de MQTT com Raspberry Pi.

Conecte-se com segurança com o ConnectMQ

Um dispositivo blindado merece um broker feito para produção. O ConnectMQ é um broker MQTT gerenciado com TLS na porta 8883, WebSocket seguro na 8084, credenciais por dispositivo e proteção contra flood. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte seu primeiro Pi blindado via TLS em minutos.

Perguntas frequentes

Preciso abrir alguma porta para MQTT no Raspberry Pi?

Não. Um cliente MQTT se conecta para fora, até o broker, então o Pi não precisa de portas de entrada para MQTT. Permita SSH de entrada apenas a partir de redes de gestão confiáveis, se for o caso.

A porta 1883 é aceitável em algum caso?

Apenas para testes locais com dados não sensíveis. Tudo o que atravessa uma rede não confiável deve usar TLS na porta 8883, para que credenciais e payloads sejam criptografados.

Cada dispositivo deve ter suas próprias credenciais MQTT?

Sim. Credenciais únicas permitem revogar um único dispositivo perdido ou comprometido sem mexer no resto da frota, e tornam os logs significativos.

A criptografia de disco ajuda em um Raspberry Pi?

Ela protege os dados se o armazenamento for roubado, mas o dispositivo passa a precisar de uma forma de destravar no boot sem uma pessoa presente, o que é difícil de fazer com segurança em um Pi. Para a maioria dos gateways, minimizar os segredos armazenados e usar credenciais revogáveis é mais prático.