# Proteger SMPP: TLS, autenticación y listas de IP permitidas

> SMPP en sí no está cifrado: el system_id y la password del bind cruzan el cable en claro sobre TCP simple. En producción lo proteges ejecutando SMPP sobre TLS (envolviendo la sesión TCP), autenticando con credenciales más listas de IP permitidas, exigiendo TLS 1.2+ y rotando las credenciales desde un gestor de secretos en lugar de codificarlas.

- URL canónica: https://www.broadnet.me/es/reference/smpp-over-tls-security
- Idioma: es
- Última actualización: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

SMPP no tiene cifrado nativo. Cómo proteger un bind en producción: SMPP sobre TLS, autenticación por credenciales e IP, listas de permitidos e higiene de credenciales.

## Por qué el SMPP en claro es un riesgo

La especificación de SMPP no define seguridad de transporte. En un bind TCP en claro (puerto 2775), el system_id y la password de bind_transmitter/receiver/transceiver, y todo cuerpo de mensaje, viajan sin cifrar. En cualquier trayecto no confiable, eso expone las credenciales a interceptación y el tráfico a espionaje. Por tanto, la seguridad se añade en la capa de transporte, no en el protocolo.

## SMPP sobre TLS

El control estándar es ejecutar la sesión SMPP dentro de un túnel TLS: la conexión TCP completa un handshake TLS antes de enviar la PDU bind, de modo que credenciales y cargas se cifran de extremo a extremo. No hay un único puerto TLS de la IANA para SMPP, así que los proveedores exponen un puerto dedicado con TLS habilitado. Exige TLS 1.2 o superior, valida la cadena de certificados del servidor, rechaza certificados caducados o autofirmados y nunca desactives la verificación para «que funcione».

*SMPP en claro frente a TLS*

| Aspecto | SMPP sin cifrar | SMPP over TLS |
|---|---|---|
| Transporte | TCP (puerto predeterminado 2775) | TCP + TLS (puerto proporcionado por el proveedor) |
| Credenciales transmitidas por la red | Texto plano | Cifrado |
| Cuerpos de los mensajes | Texto plano | Cifrado |
| Identidad del servidor | No verificado | Validado mediante certificado |

## Autenticación y listas de IP permitidas

SMPP se autentica con el par system_id/password del bind. Eso es débil por sí solo, así que los operadores añaden encima listas de IP permitidas: solo las direcciones IP de origen registradas previamente pueden abrir un bind, en ambos extremos. Las listas de permitidos son un control estándar del operador y una forma rápida de contener una credencial filtrada: una contraseña robada es inútil desde una IP no incluida. Combínalas con TLS, no como sustituto.

## Higiene de credenciales

Trata las credenciales de SMPP como cualquier otro secreto. Guárdalas en un gestor de secretos, nunca en el código fuente ni en configuración incluida en un repositorio. Rótalas con periodicidad e inmediatamente ante cualquier sospecha de exposición. Usa credenciales distintas por entorno y por integración para que una filtración tenga un radio de impacto limitado, y vigila bind desde IP inesperadas o a horas inesperadas.

## Preguntas frecuentes

### ¿SMPP está cifrado de forma predeterminada?

No. SMPP no tiene cifrado integrado: sobre TCP simple las credenciales y los cuerpos de mensaje se envían en claro. El cifrado se añade ejecutando la sesión SMPP sobre TLS, algo que el protocolo no especifica pero que todo proveedor serio admite.

### ¿Qué puerto usa SMPP sobre TLS?

No hay un único puerto TLS estandarizado. SMPP en claro usa el puerto 2775 de la IANA; para TLS, los proveedores exponen un puerto provisionado aparte (a veces se usa el 3550). Usa el puerto TLS que asigne tu proveedor.

### ¿Basta con las listas de IP permitidas por sí solas?

No. Las listas de IP permitidas limitan quién puede conectarse y contienen credenciales filtradas, pero no cifran el tráfico. Combina las listas de permitidos con SMPP sobre TLS para proteger tanto el origen de la conexión como la confidencialidad de los datos.

### ¿Cómo debo almacenar las credenciales de SMPP?

En un gestor de secretos, nunca en el código ni en configuración incluida en el repositorio. Usa credenciales separadas por entorno e integración, rótalas con periodicidad y ante cualquier sospecha de filtración, y vigila bind desde IP inesperadas.

## Fuentes

- [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)

## Relacionado

- [Operaciones de enlace SMPP](https://www.broadnet.me/es/reference/smpp-bind-operations)
- [Mejores prácticas de integración SMPP](https://www.broadnet.me/es/reference/smpp-integration-best-practices)
- [Lista de verificación (guía) para la integración SMPP](https://www.broadnet.me/es/guides/smpp-integration-checklist)
- [Pasarela SMSC (operadores)](https://www.broadnet.me/es/operators/smsc-gateway)
- [Documentación para desarrolladores](https://www.broadnet.me/es/developers)