# Защита SMPP: TLS, аутентификация и белые списки IP

> Сам SMPP не зашифрован — system_id и password в bind передаются по каналу открытым текстом поверх обычного TCP. В промышленной эксплуатации его защищают запуском SMPP поверх TLS (оборачивая TCP-сессию), аутентификацией по учётным данным вместе с белыми списками IP, требованием TLS 1.2+ и ротацией учётных данных из менеджера секретов, а не их жёстким прописыванием.

- Канонический URL: https://www.broadnet.me/ru/reference/smpp-over-tls-security
- Язык: ru
- Последнее обновление: 2026-07-18
- Издатель: BroadNet (https://www.broadnet.me)

У SMPP нет собственного шифрования. Как защитить bind в промышленной эксплуатации: SMPP поверх TLS, аутентификация по учётным данным и IP, белые списки и гигиена учётных данных.

## Почему незашифрованный 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 поверх TLS*

| Аспект | Обычный 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.

## Источники

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

## См. также

- [Операции bind в SMPP](https://www.broadnet.me/ru/reference/smpp-bind-operations)
- [Лучшие практики интеграции SMPP](https://www.broadnet.me/ru/reference/smpp-integration-best-practices)
- [Чек-лист интеграции SMPP (руководство)](https://www.broadnet.me/ru/guides/smpp-integration-checklist)
- [SMSC-шлюз (операторам)](https://www.broadnet.me/ru/operators/smsc-gateway)
- [Документация для разработчиков](https://www.broadnet.me/ru/developers)