# Proteger o SMPP: TLS, autenticação e lista de IPs permitidos

> 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.

- URL canônico: https://www.broadnet.me/pt/reference/smpp-over-tls-security
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

O SMPP não tem cifra nativa. Como proteger um bind em produção: SMPP sobre TLS, autenticação por credenciais e por IP, listas de permissões e higiene de credenciais.

## 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'.

*SMPP em texto simples vs TLS*

| 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.

## Fontes

- [SMPP v3.4 specification](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [RFC 8446 — TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446)

## Relacionados

- [Operações de bind SMPP](https://www.broadnet.me/pt/reference/smpp-bind-operations)
- [Melhores práticas de integração SMPP](https://www.broadnet.me/pt/reference/smpp-integration-best-practices)
- [Lista de verificação (guia) para integração SMPP](https://www.broadnet.me/pt/guides/smpp-integration-checklist)
- [Gateway SMSC (operadoras)](https://www.broadnet.me/pt/operators/smsc-gateway)
- [Documentação do desenvolvedor](https://www.broadnet.me/pt/developers)