SMPP selbst ist unverschlüsselt — die Bind-system_id und das Passwort überqueren die Leitung im Klartext über einfaches TCP. Produktiv sichern Sie es, indem Sie SMPP über TLS betreiben (die TCP-Sitzung umhüllen), sich mit Zugangsdaten plus IP-Allowlisting authentifizieren, TLS 1.2+ erzwingen und Zugangsdaten aus einem Secret Manager rotieren, statt sie fest einzucodieren.
bind_transceiverSitzung öffnen und authentifizierenbind_transceiver_respSitzung akzeptiertsubmit_smNachricht sendensubmit_sm_respAkzeptiert, Nachrichten-ID zurückgegebendeliver_smZustellungsbericht oder eingehende Nachrichtdeliver_sm_respBestätigtenquire_linkKeepalive im Leerlauf
Warum Klartext-SMPP ein Risiko ist
Die SMPP-Spezifikation definiert keine Transportsicherheit. Bei einem Klartext-TCP-Bind (Port 2775) reisen die system_id und das Passwort in bind_transmitter/receiver/transceiver sowie jeder Nachrichten-Body unverschlüsselt. Auf jedem nicht vertrauenswürdigen Pfad setzt das Zugangsdaten dem Abfangen und den Verkehr dem Mithören aus. Sicherheit wird daher auf der Transportschicht ergänzt, nicht durch das Protokoll.
SMPP über TLS
Die Standardmaßnahme ist, die SMPP-Sitzung in einem TLS-Tunnel zu betreiben: Die TCP-Verbindung schließt einen TLS-Handshake ab, bevor die Bind-PDU gesendet wird, sodass Zugangsdaten und Nutzlasten Ende zu Ende verschlüsselt sind. Es gibt keinen einheitlichen IANA-TLS-Port für SMPP, daher stellen Anbieter einen dedizierten TLS-fähigen Port bereit. Erzwingen Sie TLS 1.2 oder höher, validieren Sie die Serverzertifikatskette, weisen Sie abgelaufene oder selbstsignierte Zertifikate zurück und deaktivieren Sie die Prüfung niemals, „damit es funktioniert".
| Aspekt | Klartext-SMPP | SMPP over TLS |
|---|---|---|
| Transport | TCP (Standardport 2775) | TCP + TLS (vom Anbieter bereitgestellter Port) |
| Zugangsdaten auf der Leitung | Klartext | Verschlüsselt |
| Nachrichtentexte | Klartext | Verschlüsselt |
| Serveridentität | Nicht verifiziert | Zertifikatsvalidiert |
Authentifizierung und IP-Allowlisting
SMPP authentifiziert sich mit dem Paar system_id/password im Bind. Das ist für sich genommen schwach, daher legen Betreiber IP-Allowlisting darüber: Nur vorab registrierte Quell-IP-Adressen dürfen auf beiden Seiten einen Bind öffnen. Allowlisting ist eine gängige Betreibermaßnahme und ein schneller Weg, ein geleaktes Zugangsdatum einzudämmen — ein gestohlenes Passwort ist von einer nicht gelisteten IP aus nutzlos. Kombinieren Sie es mit TLS, nicht als dessen Ersatz.
Zugangsdaten-Hygiene
Behandeln Sie SMPP-Zugangsdaten wie jedes andere Geheimnis. Speichern Sie sie in einem Secret Manager, niemals im Quellcode oder in einer ins Repository eingecheckten Konfiguration. Rotieren Sie planmäßig und sofort bei jedem Verdacht auf Offenlegung. Verwenden Sie eigene Zugangsdaten je Umgebung und je Integration, damit ein Leak einen begrenzten Wirkungsradius hat, und überwachen Sie Binds von unerwarteten IPs oder zu unerwarteten Zeiten.
Häufig gestellte Fragen
Ist SMPP standardmäßig verschlüsselt?
Nein. SMPP hat keine eingebaute Verschlüsselung — über einfaches TCP werden Zugangsdaten und Nachrichten-Bodys im Klartext gesendet. Verschlüsselung wird durch den Betrieb der SMPP-Sitzung über TLS ergänzt, was das Protokoll nicht spezifiziert, aber jeder ernstzunehmende Anbieter unterstützt.
Welchen Port hat SMPP über TLS?
Es gibt keinen einheitlich standardisierten TLS-Port. Klartext-SMPP verwendet IANA-Port 2775; für TLS stellen Anbieter einen separaten bereitgestellten Port bereit (mitunter wird 3550 verwendet). Nutzen Sie den TLS-Port, den Ihr Anbieter zuweist.
Genügt IP-Allowlisting allein?
Nein. IP-Allowlisting begrenzt, wer sich verbinden darf, und dämmt geleakte Zugangsdaten ein, verschlüsselt aber den Verkehr nicht. Kombinieren Sie Allowlisting mit SMPP über TLS, sodass sowohl Verbindungsursprung als auch Datenvertraulichkeit geschützt sind.
Wie sollte ich SMPP-Zugangsdaten speichern?
In einem Secret Manager, niemals im Code oder in eingecheckter Konfiguration. Verwenden Sie getrennte Zugangsdaten je Umgebung und Integration, rotieren Sie sie planmäßig und bei jedem Verdacht auf ein Leak und überwachen Sie Binds von unerwarteten IPs.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)