O próprio SMPP não é cifrado — o system_id e a password do bind atravessam a rede em claro sobre TCP simples. Em produção protege-se correndo o SMPP sobre TLS (envolvendo a sessão TCP), autenticando com credenciais mais uma lista de IPs permitidos, impondo TLS 1.2+ e rodando as credenciais a partir de um gestor de segredos em vez de as codificar no código.
bind_transceiverAbrir e autenticar a sessãobind_transceiver_respSessão aceitasubmit_smEnviar uma mensagemsubmit_sm_respAceito, ID da mensagem devolvidadeliver_smRelatório de entrega ou mensagem recebidadeliver_sm_respConfirmadoenquire_linkKeepalive em modo ocioso
Porque é que o SMPP em texto simples é um risco
A especificação SMPP não define qualquer segurança de transporte. Num bind TCP simples (porta 2775), o system_id e a password em bind_transmitter/receiver/transceiver, e cada corpo de mensagem, viajam sem cifra. Em qualquer caminho não confiável isso expõe as credenciais à interceção e o tráfego à escuta. A segurança é, por isso, acrescentada na camada de transporte, não pelo protocolo.
SMPP sobre TLS
O controlo padrão é correr a sessão SMPP dentro de um túnel TLS: a ligação TCP completa um handshake TLS antes de o PDU de bind ser enviado, pelo que as credenciais e os conteúdos são cifrados de ponta a ponta. Não há uma única porta TLS da IANA para o SMPP, por isso os fornecedores expõem uma porta dedicada com TLS. Imponha TLS 1.2 ou superior, valide a cadeia de certificado do servidor, rejeite certificados expirados ou autoassinados e nunca desative a verificação para 'fazer funcionar'.
| Aspeto | SMPP simples | SMPP over TLS |
|---|---|---|
| Transporte | TCP (porta padrão 2775) | TCP + TLS (porta fornecida pelo fornecedor) |
| Credenciais trafegando na rede | Texto simples | Encriptado |
| Corpos de mensagens | Texto simples | Encriptado |
| Identidade do servidor | Não verificado | Validado por certificado |
Autenticação e lista de IPs permitidos
O SMPP autentica-se com o par system_id/password no bind. Isso é fraco por si só, pelo que os operadores acrescentam por cima uma lista de IPs permitidos: só endereços IP de origem pré-registados podem abrir um bind, em ambos os lados. A lista de permissões é um controlo padrão de operador e uma forma rápida de conter uma credencial fugida — uma password roubada é inútil a partir de um IP não listado. Combine-a com TLS, não como substituto dele.
Higiene de credenciais
Trate as credenciais SMPP como qualquer outro segredo. Guarde-as num gestor de segredos, nunca no código-fonte ou em configuração submetida a um repositório. Rode-as num calendário e imediatamente perante qualquer suspeita de exposição. Use credenciais distintas por ambiente e por integração para que uma fuga tenha um raio de impacto limitado, e monitorize binds de IPs inesperados ou em horas inesperadas.
Perguntas frequentes
O SMPP é cifrado por omissão?
Não. O SMPP não tem cifra incorporada — sobre TCP simples as credenciais e os corpos de mensagem são enviados em claro. A cifra é acrescentada correndo a sessão SMPP sobre TLS, o que o protocolo não especifica mas todos os fornecedores sérios suportam.
Que porta é o SMPP sobre TLS?
Não há uma única porta TLS normalizada. O SMPP em texto simples usa a porta 2775 da IANA; para TLS, os fornecedores expõem uma porta aprovisionada separada (por vezes usa-se a 3550). Use a porta TLS que o seu fornecedor atribuir.
A lista de IPs permitidos basta por si só?
Não. A lista de IPs permitidos limita quem se pode ligar e contém credenciais fugidas, mas não cifra o tráfego. Combine a lista de permissões com SMPP sobre TLS para que tanto a origem da ligação como a confidencialidade dos dados fiquem protegidas.
Como devo guardar as credenciais SMPP?
Num gestor de segredos, nunca em código ou configuração submetida. Use credenciais separadas por ambiente e integração, rode-as num calendário e perante qualquer suspeita de fuga, e monitorize binds de IPs inesperados.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.