Сам SMPP не зашифрован — system_id и password в bind передаются по каналу открытым текстом поверх обычного TCP. В промышленной эксплуатации его защищают запуском SMPP поверх TLS (оборачивая TCP-сессию), аутентификацией по учётным данным вместе с белыми списками IP, требованием TLS 1.2+ и ротацией учётных данных из менеджера секретов, а не их жёстким прописыванием.
bind_transceiverОткрыть и аутентифицировать сессиюbind_transceiver_respСессия принятаsubmit_smОтправить сообщениеsubmit_sm_respПринято, возвращен ID сообщенияdeliver_smПодтверждение доставки или входящее сообщениеdeliver_sm_respПодтвержденоenquire_linkKeepalive в режиме ожидания
Почему незашифрованный SMPP — это риск
Спецификация SMPP не определяет транспортную безопасность. При обычном bind поверх TCP (порт 2775) system_id и password в bind_transmitter/receiver/transceiver, а также тело каждого сообщения передаются без шифрования. На любом недоверенном пути это подвергает учётные данные перехвату, а трафик — прослушиванию. Поэтому безопасность добавляется на транспортном уровне, а не самим протоколом.
SMPP поверх TLS
Стандартная мера — запустить сессию SMPP внутри TLS-туннеля: TCP-соединение завершает TLS-рукопожатие до отправки PDU bind, поэтому учётные данные и полезные нагрузки шифруются из конца в конец. Единого TLS-порта IANA для SMPP нет, поэтому провайдеры выделяют специальный порт с поддержкой TLS. Требуйте TLS 1.2 или выше, проверяйте цепочку сертификата сервера, отклоняйте просроченные или самоподписанные сертификаты и никогда не отключайте проверку, «чтобы заработало».
| Аспект | Обычный SMPP | SMPP over TLS |
|---|---|---|
| Транспорт | TCP (порт по умолчанию 2775) | TCP + TLS (порт, выделяемый провайдером) |
| Учётные данные передаются по сети | Открытый текст | Зашифрованный |
| Тела сообщений | Открытый текст | Зашифрованный |
| Подлинность сервера | Непроверенный | С проверкой сертификата |
Аутентификация и белые списки IP
SMPP аутентифицируется парой system_id/password в bind. Сама по себе она слаба, поэтому операторы поверх неё добавляют белые списки IP: открыть bind могут только заранее зарегистрированные исходные IP-адреса, с обеих сторон. Белый список — это стандартная мера оператора и быстрый способ ограничить последствия утёкших учётных данных: украденный пароль бесполезен с IP не из списка. Сочетайте его с TLS, а не заменяйте им.
Гигиена учётных данных
Относитесь к учётным данным SMPP как к любому другому секрету. Храните их в менеджере секретов, никогда не в исходном коде или конфигурации, зафиксированной в репозитории. Меняйте их по расписанию и немедленно при любом подозрении на компрометацию. Используйте отдельные учётные данные для каждой среды и каждой интеграции, чтобы одна утечка имела ограниченный радиус поражения, и отслеживайте bind с неожиданных IP или в неожиданное время.
Часто задаваемые вопросы
Зашифрован ли SMPP по умолчанию?
Нет. У SMPP нет встроенного шифрования — поверх обычного TCP учётные данные и тело сообщений передаются открытым текстом. Шифрование добавляется запуском сессии SMPP поверх TLS, что протокол не описывает, но что поддерживает любой серьёзный провайдер.
Какой порт у SMPP поверх TLS?
Единого стандартизированного TLS-порта нет. Незашифрованный SMPP использует порт IANA 2775; для TLS провайдеры выделяют отдельный порт (иногда используется 3550). Используйте тот TLS-порт, который назначает ваш провайдер.
Достаточно ли одного белого списка IP?
Нет. Белый список IP ограничивает круг тех, кто может подключиться, и сдерживает утёкшие учётные данные, но он не шифрует трафик. Сочетайте белый список с SMPP поверх TLS, чтобы защитить и источник соединения, и конфиденциальность данных.
Как хранить учётные данные SMPP?
В менеджере секретов, никогда не в коде или зафиксированной конфигурации. Используйте отдельные учётные данные для каждой среды и интеграции, меняйте их по расписанию и при любом подозрении на утечку и отслеживайте bind с неожиданных IP.
Технические характеристики источника
На этой странице представлены опубликованные стандарты, на которых они основаны. (Открывается в новой вкладке)