Protocolo

SNMP

Na supervisão da infraestrutura da casa inteligente, SNMP resolve o problema de coletar métricas e alarmes de switches, UPS, roteadores, access points e gateways sem API proprietária. SNMPv1 surgiu em 1988; SNMPv3 usa o framework da RFC 3411 e pode oferecer autenticação e privacidade pelo USM da RFC 3414. A porta usual é UDP 161, com traps em 162. Para implantação segura, desabilitar comunidades `public/private`, preferir authPriv e restringir gerentes por ACL.


📖Definição aprofundada

SNMP é uma família de protocolos e modelos para gerenciamento de dispositivos IP. Um gerente ou Network Management System consulta agentes instalados em switches, roteadores, UPS, access points, servidores, controladores e gateways. Os dados são organizados como objetos com OIDs numa árvore. As definições ficam em MIBs, escritas em SMI. Um OID como `1.3.6.1.2.1.1.3.0` representa sysUpTime no MIB-II. O gerente usa GET para ler um objeto, GETNEXT para navegar, GETBULK em versões posteriores para ler tabelas eficientemente, SET para alterar quando permitido e recebe TRAP ou INFORM para notificações. O agente normalmente escuta UDP 161; traps e informs usam UDP 162 no receptor. TCP pode existir em extensões, mas UDP é o padrão comum. SNMPv1 foi definido no fim da década de 1980 e popularizou comunidades como strings de acesso. SNMPv2 trouxe melhorias, GETBULK e novos tipos; SNMPv2c manteve comunidades sem segurança criptográfica. SNMPv3, definido pelo framework das RFCs 3411–3418 em 2002, adiciona arquitetura, engine IDs, usuários, autenticação, privacidade, controle de acesso e modelo de processamento. USM, RFC 3414, oferece noAuthNoPriv, authNoPriv e authPriv. Para redes atuais, authPriv é a escolha segura, usando algoritmos suportados e atualizados. Implementações antigas usam MD5 e DES, que devem ser evitados quando SHA e AES estão disponíveis. Extensões modernas definem SHA-2 e AES. VACM controla quais OIDs cada usuário pode ler ou alterar. O engine boots/time ajuda proteção contra replay. Relógios e engine ID precisam estar corretos. Descoberta do engine ocorre. Em casa inteligente avançada, SNMP monitora temperatura da UPS, carga, bateria, potência, portas de switch, PoE, tráfego, erros, clientes de access point, estado de links e sensores ambientais. Um switch PoE pode informar consumo por porta. Um NMS como Zabbix, LibreNMS, PRTG ou Prometheus via exporter coleta a cada 30–300 s. Home Assistant possui integrações SNMP para sensores e comandos, mas polling excessivo aumenta carga. MIBs padrão fornecem IF-MIB, SNMPv2-MIB, ENTITY-MIB, UPS-MIB e LLDP-MIB. Fabricantes adicionam OIDs privados sob sua enterprise. O arquivo MIB traduz números em nomes e tipos. A presença da MIB não garante que o modelo implemente todos. O integrador consulta. Índices de tabela podem mudar após reboot. Interfaces devem ser correlacionadas por ifName/ifAlias, não apenas ifIndex quando persistência não é garantida. Contadores de 32 bits transbordam rapidamente em links rápidos; usar Counter64 em ifHCInOctets/ifHCOutOctets. Para calcular taxa, fazer diferença e dividir pelo tempo, tratando wrap e reboot. sysUpTime ajuda. Traps são não confirmados; INFORM recebe confirmação. Não depender apenas de trap para estado crítico. Polling reconcilia. SET é poderoso e arriscado. Deve ser desabilitado ou restrito. Uma automação não deve desligar porta PoE por community pública. SNMP não é discovery de usuário final. É gerenciamento. Firewalls permitem apenas do NMS para agentes. UDP 161/162 nunca fica exposto à Internet. Comunidades v2c podem aparecer em captura; usar v3. O protocolo também pode ser usado em dispositivos sem suporte a TLS. authPriv fornece segurança própria, mas a configuração é complexa. Logs e rotação de credenciais são necessários.

Arquitetura e Funcionamento
OIDs, MIBs e tabelas
A árvore OID começa em raízes ISO/identified-organization/dod/internet. `1.3.6.1.2.1` é mib-2. Empresas usam `1.3.6.1.4.1.<enterprise>`. Um objeto escalar termina em `.0`; tabelas têm índices. A MIB define nome, sintaxe, acesso, status e descrição. O agente transmite OID e valor, não o arquivo MIB. O gerente carrega para exibir. Sem MIB, ainda é possível consultar números. OID privado precisa de documentação. Tipos incluem INTEGER, OCTET STRING, OBJECT IDENTIFIER, Counter32, Gauge32, TimeTicks e Counter64. Um sensor pode usar inteiro em décimos de grau; a descrição informa. Não assumir unidade. O índice de porta pode mudar. Use IF-MIB e ENTITY-MIB. O walk com GETNEXT/GETBULK enumera. Limitar escopo para evitar respostas grandes e CPU. MIB browsers ajudam. Validar valores e enumerações.
Polling, contadores e capacidade
O NMS consulta em intervalo. 60 s é comum; 5 min para inventário; 10 s apenas quando necessário. Mil dispositivos × centenas de OIDs criam carga. GETBULK agrupa. O agente possui limite de PDU e resposta. Pacotes UDP grandes fragmentam; ajustar max-repetitions. Para tráfego, ler Counter64 em dois instantes. Taxa em bit/s = diferença de octetos × 8 / segundos. Se sysUpTime diminui, houve reboot. Contadores podem zerar. Portas de 1 Gbit/s transbordam Counter32 em cerca de 34 s no máximo; Counter64 evita. Para PoE, ler potência e estado. A MIB específica define. Polling não deve competir com CPU de switch. Distribuir horários. O NMS usa timeout e poucas retentativas. Se o agente está offline, não aumentar avalanche. Gráficos registram. Dados sensíveis de clientes Wi‑Fi precisam de acesso restrito.
Traps, informs e eventos
TRAP é enviado pelo agente sem confirmação. Pode se perder. INFORM é uma solicitação confirmada e pode ser retransmitida. Notificações incluem snmpTrapOID e varbinds. LinkDown/LinkUp, coldStart, authenticationFailure e eventos de UPS são exemplos. O receptor precisa mapear origem e engine. NAT e endereços múltiplos complicam. Configurar destino correto. Em SNMPv3, notificação pode ser autenticada e cifrada. Traps v2c possuem community. Não aceitar de qualquer origem. Firewall permite agentes conhecidos. O NMS correlaciona e depois faz polling para confirmar. Uma porta pode flapar e gerar tempestade. Rate limit e debounce. O evento precisa de timestamp; sysUpTime informa desde boot, mas o receptor adiciona hora. NTP mantém. Traps não substituem syslog; são complementares. Syslog traz texto; SNMP traz OIDs estruturados. Alertas críticos podem usar ambos.
SNMPv3 e controle de acesso
USM identifica usuário e engine. authNoPriv autentica sem cifrar; authPriv autentica e cifra. Preferir authPriv. VACM define views de OIDs e operações. Um usuário de monitoramento lê IF-MIB e UPS-MIB, sem SET. Um usuário de automação pode controlar apenas uma saída, se realmente necessário. Não usar administrador global. Engine ID precisa ser único. Senhas são localizadas por engine, dificultando uso direto em outro agente. Credenciais devem ser longas e em cofre. Algoritmos antigos MD5/DES são fracos. Usar SHA-2 e AES quando implementados. Verificar interoperabilidade porque equipamentos antigos suportam apenas SHA-1/AES-128. Atualizar. SNMPv3 é mais complexo que v2c. Testar `snmpget -v3`. A complexidade não justifica community pública. Se o equipamento não suporta v3, isolar em VLAN de gestão e ACL, usar string aleatória, somente leitura e planejar substituição.
Análise Técnica
✓ Vantagens
  • Padroniza monitoramento de equipamentos de rede e energia de múltiplos fabricantes por OIDs e MIBs comuns.
  • SNMPv3 oferece autenticação, privacidade e controle de acesso granular sem depender de TLS externo.
  • GETBULK e contadores estruturados permitem coletar muitas interfaces e métricas com overhead moderado.
  • Traps e informs fornecem eventos assíncronos, complementando polling para detectar falhas rapidamente.
  • Possui ampla integração com Zabbix, LibreNMS, PRTG, SolarWinds, Prometheus exporters e Home Assistant.
✗ Desvantagens
  • SNMPv1 e v2c transmitem community strings sem criptografia e continuam comuns, criando risco de exposição.
  • MIBs privadas, índices e escalas variam entre fabricantes; interoperabilidade exige testes e documentação.
  • Configurar SNMPv3, engine IDs, usuários, algoritmos e VACM é mais complexo e pode falhar entre implementações antigas.
  • UDP pode perder traps e respostas; polling, retry e reconciliação continuam necessários.
  • SET pode alterar equipamentos de forma perigosa; privilégios excessivos e comunidades de escrita devem ser evitados.
💡 Cenário Prático: SNMPv3 para switches PoE, UPS e infraestrutura doméstica
Uma VLAN de gestão contém switches, access points e UPS. Somente o servidor LibreNMS ou Zabbix acessa UDP 161. Equipamentos usam SNMPv3 authPriv, usuário de leitura e AES/SHA suportados. VACM limita OIDs. Community `public` é desativada. O NMS consulta IF-MIB, LLDP-MIB, PoE MIB e UPS-MIB a cada 60 s, com inventário a cada 15 min. Contadores Counter64 alimentam gráficos. Traps autenticados chegam em UDP 162 e o NMS confirma com polling. Alertas de bateria baixa, porta PoE desligada e temperatura são enviados ao Home Assistant por webhook ou MQTT. O Home Assistant não recebe credencial de escrita do switch. Uma automação pode solicitar desligamento PoE via API do NMS ou usuário restrito, com confirmação. Firewalls bloqueiam SNMP da IoT e da Internet. Credenciais ficam em cofre. Backups de configuração não são feitos por SNMP quando existe mecanismo mais seguro. MIBs oficiais do fabricante são versionadas. Após atualização de firmware, OIDs críticos são testados. O resultado é observabilidade sem transformar o protocolo em porta administrativa aberta.