Текущая версия от 14:43, 30 мая 2025

Общая информация

Комплекс мер по обеспечению безопасности SIP в первую очередь служит для предотвращения несанкционированного доступа к сервисам телефонии, а также для фильтрации запросов, которые могут привести к отказу в обслуживании (DDOS).

В рамках данной статьи будут описаны основные методы обеспечения безопасности SIP в рамках платформы.

Обзор мер обеспечения безопасности

Приведенную ниже таблицу можно использовать в качестве чек-листа по проверке и настройке средств безопасности.

В данной таблице, однако, приведены только методы, которые могут быть реализованы средствами самой платформы. Следует обратить внимание на обеспечение безопасности сред, на которых платформа исполняется, так как несанкционированный доступ к среде исполнения позволяет обойти большинство ограничений и средств безопасности, описанных ниже.

Методы обеспечения безопасности
Метод	Комментарий
Смена портов SIP	Использование нестандартных портов SIP при публикации системы во внешней сети, позволяет защититься от большого числа сканеров.
Защита от перебора пароля	Автоматический фильтр-детектор, блокирующий доступ при большом количестве неудачных авторизаций SIP или TFTP
Блокировка отправки ответов	Система позволяет отключить отправку ответов неавторизованным клиентам.
Ограничение доступа к учетным записям SIP	Ограничение на использование учетной записи SIP с других IP-адресов, кроме указанного.
Ограничение использование Feature-кодов	Настройка доступа пользователей к использованию feature-кодов
Настройка правил фильтрации запросов	Настройка правил пограничного фильтра SG/ESG в мастер-домене. Позволяет делать черные и белые списки IP-адресов, а также гибко фильтровать входящие запросы.
Использование TLS для SIP	Можно использовать TLS-шифрование для протокола SIP. В данном случае обязательно использование домена, необходимо либо получить публичный сертификат, либо использовать самоподписанный и на всех SIP-устройствах подключить корневой сертификат для проверки.
Шифрование медиа-трафика*	Платформа позволяет использовать протокол SRTP для шифрования медиа-трафика. Однако, использование зашифрованного медиа-трафика в публичных сетях ограничивается законом.
Использование отдельных серверов для обслуживания внешних подключений	Рекомендуется использовать отдельный "фасадный" сервер, обслуживающий внешние подключения. В случае DDOS-атаки, нагрузка будет влиять только на данный сервер, а внутренние клиенты и другие сервисы, обслуживаемые отдельным сервером, могут продолжать работу.
Ограничение доступа к реестру учетных записей SIP	Создание отдельной административной роли, которая ограничивает доступ к учетным записям SIP, но рарешает доступ к другим разделом.

Базовые практики защиты

Публичные порты SIP

По умолчанию системой используются обещпринятые порты для работы SIP-протокола:

5060
5061
5063
5080

При публикации сервисов системы во внешней сети, рекомендуется сменить данные порты на какие-либо другие для снижения риска обнаружения системы сканерами.

Детально, порты используемые системой описаны в соответствующей статье.

Защита от перебора пароля

Платформа имеет автоматический фильтр-детекор, позволяющий отслеживать неудачные попытки авторизации и блокировать доступ на 20 минут после определенного их числа (50 запросов за 30 секунд).

Аналогичный фильтр работает на TFTP-интерфейсе для Autoprovision, при поступлении большого количества запросов с неизвестным MAC-адресом (30 пакетов в секунду), система заблокирует доступ с IP-адреса на 20 минут.

Блокировка отправки ответов

Специальный параметр в мастер-домене позволяет регулировать отправку ответов по неавторизованным запросам. По-умолчанию отправка отключена, что позволяет в некотором смысле, маскировать систему. Внешние системы злоумышленников не будут получать негативный результат авторизации и могут отменить дальнейший перебор паролей.

Этот же механизм позволяет добавлять адреса злоумышленников в динамические бан-листы.

Ограничение доступа к учетным записям SIP

Платформа позволяет в настройках абонента указать явный адрес и порт устройства, которое будет использовать данную учетную запись. Доступ к учетной записи с других устройств будет ограничен.

Дополнительно, для повышения безопасности, не рекомендуется использовать несколько пар логин-пароль для одной учетной записи. Данная настройка не вынесена в карточку редактирования УЗ, однако может быть выполнена с помощью редактирования JSON.

Кроме того, можно ограничить количество одновременных регистраций для учетной записи.

Ограничение использование Feature-кодов

В рамках настройки feature-кодов необходимо использовать правила сервисов, которые позволяют ограничить применение таких кодов для определенных внутренних номеров. Это важно при создании feature-кодов перехвата, подслушки, подмены плеча разговора и т.д.

Использование TLS и SRTP

Подробно про настройку TLS и SRTP при подключении к провайдерам можно прочитать на ресурсе Vendor.

Фильтрация SIP-запросов

Правила фильтрации запросов

Задача — минимизировать риски несанкционированного подключения к IP-АТС по протоколу IP-телефонии SIP.

Настройка фильтров осуществляется только в мастер-домене в приложении «Настройка». Меню «Маршрутизация», «Фильтр запросов». Правила фильтрации исполняются согласно приоритету от меньшего к большему. Найденное правило исполняется однажды. Все что не запрещено, то разрешено.

Защита при помощи фильтра IP-подсетей. Позволяет реализовать белый и чёрный список IP-адресов с которых разрешено или запрещено подключение.
Фильтр на SIP-домен регистрации. Позволяет не допустить подключение злоумышленника, который не знает SIP-домен регистрации SIP-устройств.
Фильтр на SIP User-agent. Позволяет отсечь все попытки подключения кроме указанного в фильтре SIP User агента.
Универсальный фильтр SIP-запросов на базе регулярных выражений
Встроенный в платформу автоматический алгоритм пресечения перебора паролей для подключения. Позволяет временно блокировать IP-адрес источника подключения.

Обязательным в данном случае является использование финального запрещающего все иные подключения фильтра с низким приоритетом. Запрещающие фильтры рекомендуется реализовывать методом drop, который, в отличие от deny, не отправляет ответ злоумышленнику. Это позволяет снизить вероятность повторной попытки подключения.

Тестирование правил

1. Добавьте правило, запрещающее все обращения по SIP.

Попробуйте зарегистрироваться. Должен быть отказ.
Скачайте лог-журнал trn с микросервиса sg. Как сервер применяет правило?
Скачайте лог-журнал trn с микросервиса esg. Как сервер применяет правило?

Если логирование trn выключено в конфигурации, то следов, разумеется, не будет.

2. Добавьте правила, запрещающие все обращения по ws, кроме локального адреса вашего клиентского устройства, где запускается браузер.

Попробуйте открыть приложение и авторизоваться с другого компьютера. Как проходит процесс?
Скачайте лог-журнал с микросервиса ws. Как выглядят следы блокировки?
Какие выводы?

Если в конфигурации логирование ws отключено, то следов, разумеется, не будет.

3. Добавьте к уже настроенному правило для SIP с большим приоритетом, разрешающее диапазон из 10 IP-адресов, среди которых адреса подключаемых телефонов.

Инициируйте или дождитесь перерегистрации.
Скачайте лог-журнал trn с микросервиса sg. Что изменилось?
Добавьте правило для SIP, разрешающее собственный адрес сервера.
Скачайте лог-журнал trn с микросервиса esg. Что изменилось?

4. Измените правило для диапазона адресов, добавив в него фильтр по User-Agent. Внесите туда целиком или по маске имя одного из устройств, которое можно обнаружить в регистрационных пакетах в соответствующем заголовке.

Инициируйте или дождитесь перерегистрации.
Скачайте лог-журнал trn с микросервиса sg. Что изменилось?

5. Добавьте правила для ws на доступные локальные подсети или их объединения с помощью масок сети.

Попробуйте открыть приложение и авторизоваться с другого компьютера.

Правила с фильтрами по IP-адресу (не содержащие других фильтров) применяются гораздо раньше, и требуют от сервера меньше ресурсов в случае игнорирования.

Правила также действуют для автопровровижена. Не каждый, кто может сгенерировать MAC адрес должен иметь возможность скачать конфигурацию для устройства, содержащую пароль учетной записи.

Ограничение допустимой нагрузки "фасадных" микросервисов

В случае, если невозможно выделить отдельный сервер для обслуживания внешних подключений, можно ограничить допустимую нагрузку на конкретные микросервисы, которые обрабатывают внешние SIP-подключения:

esg
eg
autoprovision

В конфигурации инстанса, можно настроить количество доступных ядер для конкретного микросервиса, что позволит при поступлении большого количества вредоносных запросов, снизить их влияне на другие сервисы платформы.

Также, имеет смысл использовать несколько экземпляров микросервисов, разделив между ними аплинки к провайдерам. В таком случае при перегрузке одного из них, остальные продолжат работать.

Журналы событий безопасноси

Платформа автоматически фиксирует важные события безопасности в специальный журнал для дальнейшего аудита. Журнал доступен к просмотру через приложение Администратор платформы, в разделе События.

Кроме базовых событий, в данный журнал также могут записываться события приложений, если разработчик предусмотрел фиксацию событий безопасности для аудита.

Ограничение доступа к реестру учетных записей SIP

Механизм ролей платформы позволяет создать отдельную роль, разрешающую доступ к провайдерам для чтения и модификации, к правилам маршрутизации, но не разрешающую доступ к учетным записям пользователей, а к учетным записями SIP-устройств разрешающую доступ только для чтения.

Помимо этого, возможна привязка ролей пользователей к динамической модели данных. Там могут ограничиваться доступы к конкретным коллекциям, к конкретным операциям с коллекцией, а также в особо тонких случаях, конкретные операции с конкретными записями в коллекциях.

@@ Строка 6: / Строка 6: @@
 = Обзор мер обеспечения безопасности =
-Приведенную таблицу можно использовать в качестве чек-листа по проверке и настройке безопасности.
+Приведенную ниже таблицу можно использовать в качестве чек-листа по проверке и настройке средств безопасности.
-В данной таблице, однако, приведены только методы, которые могут быть осуществлены средствами самой платформы. Следует обратить внимание на обеспечение безопасности сред, на которых платформа исполняется, так как несанкционированный доступ к среде исполнения позволяет обойти большинство ограничений и средств безопасности, описанных ниже.
+В данной таблице, однако, приведены только методы, которые могут быть реализованы средствами самой платформы. Следует обратить внимание на обеспечение безопасности сред, на которых платформа исполняется, так как несанкционированный доступ к среде исполнения позволяет обойти большинство ограничений и средств безопасности, описанных ниже.
 {| class="wikitable"
 |+Методы обеспечения безопасности
@@ Строка 23: / Строка 23: @@
 |Система позволяет отключить отправку ответов неавторизованным клиентам.
 |-
-|Привязка SIP-учетных записей к IP-адресам
+|Ограничение доступа к учетным записям SIP
 |Ограничение на использование учетной записи SIP с других IP-адресов, кроме указанного.
 |-
@@ Строка 35: / Строка 35: @@
 |Можно использовать TLS-шифрование для протокола SIP. В данном случае обязательно использование домена, необходимо либо получить публичный сертификат, либо использовать самоподписанный и на всех SIP-устройствах подключить корневой сертификат для проверки.
 |-
-|Парольные политики
+|Шифрование медиа-трафика*
-|
+|Платформа позволяет использовать протокол SRTP для шифрования медиа-трафика. Однако, использование зашифрованного медиа-трафика в публичных сетях ограничивается законом.
+|-
+|Использование отдельных серверов для обслуживания внешних подключений
+|Рекомендуется использовать отдельный "фасадный" сервер, обслуживающий внешние подключения. В случае DDOS-атаки, нагрузка будет влиять только на данный сервер, а внутренние клиенты и другие сервисы, обслуживаемые отдельным сервером, могут продолжать работу.
+|-
+|Ограничение доступа к реестру учетных записей SIP
+|Создание отдельной административной роли, которая ограничивает доступ к учетным записям SIP, но рарешает доступ к другим разделом.
 |}
@@ Строка 67: / Строка 73: @@
 [[Файл:Ограничение УЗ SIP по адресу.png|мини|Ограничение УЗ SIP по адресу]]
-=== Привязка SIP-учетных записей к IP-адресам ===
+=== Ограничение доступа к учетным записям SIP ===
 Платформа позволяет в настройках абонента указать явный адрес и порт устройства, которое будет использовать данную учетную запись. Доступ к учетной записи с других устройств будет ограничен.
@@ Строка 81: / Строка 88: @@
 === Ограничение использование Feature-кодов ===
-В рамках настройки feature-кодов необходимо использовать правила сервисов, которые позволяют ограничить применение таких кодов для определенных внутренних номеров. Это важно при создании feature-кодов перехвата, подслушки, подмены плеча разговора и т.д.<br />
+В рамках настройки feature-кодов необходимо использовать правила сервисов, которые позволяют ограничить применение таких кодов для определенных внутренних номеров. Это важно при создании feature-кодов перехвата, подслушки, подмены плеча разговора и т.д.
+=== Использование TLS и SRTP ===
+Подробно про настройку TLS и SRTP при подключении к провайдерам можно прочитать на [https://vendor.era-platform.ru/docs/era/latest/articles/providers.html#tls ресурсе Vendor].<br />
 = Фильтрация SIP-запросов =
@@ Строка 139: / Строка 149: @@
 Правила также действуют для автопровровижена. Не каждый, кто может сгенерировать MAC адрес должен иметь возможность скачать конфигурацию для устройства, содержащую пароль учетной записи.
-== Динамические фильтры ==
+= Ограничение допустимой нагрузки "фасадных" микросервисов =
-Система блокирует на некоторое время IP-адреса, с которых поступают SIP-запросы, перебирающие учетные данные. Это касается веб-подключений и SIP-регистраций.
+[[Файл:Ограничение количество ядер микросервиса.png|мини|Ограничение количество ядер микросервиса]]
+В случае, если невозможно выделить отдельный сервер для обслуживания внешних подключений, можно ограничить допустимую нагрузку на конкретные микросервисы, которые обрабатывают внешние SIP-подключения:
-В тестах пригодится оставлять незаблокированный адрес.
-Рекомендация: добавьте на клиента еще один сетевой интерфейс в той же подсети, либо на сервер и на клиента еще одну подсеть.
-Дальнейшие тесты проводите с нового адреса, если иное не указывается.
-. Создайте sh-скрипт с выводом в консоль:
-* Опрашивающий статический файл (''например index.html'') с дополнительного адреса.
-* Инициирующий с помощью CURL авторизацию (''POST /rest/v1/iam/sessions'') с дополнительного адреса.
-* Запустите скрипт. Убедитесь что авторизация успешно проходит.
-Такие сценарии можно использовать для осуществления нагрузочного тестирования, инициируя исходящие вызовы с помощью API.
-Примеры скриптов можете запросить в телеграм канале.
-. Скопируйте скрипт под новым именем, укажите неверный пароль.
-* Запустите скрипт. Обратите внимание на изменения.
-* Скачайте лог-журнал с микросервиса ws. ''Как выглядят следы отказа?''
-. Скопируйте последний скрипт. Скопируйте строку авторизации с помощью CURL с неверным паролем 100 раз.
-* Запустите скрипт. ''Заметьте на все ли запросы приходят ответы? На сколько запросов сервер ответит?''
-. Измените последний скрипт, сделав все неверные пароли разными.
-* Запустите скрипт. ''Заметьте на сколько запросов сервер ответит?''
-* Скачайте лог-журнал с микросервиса ws. ''Как выглядят следы отказа и блокировки?''
-. Выполните скрипт из пункта 1.
-* Какие изменения наблюдаются? Почему?
+* esg
+* eg
+* autoprovision
-. Опросите API в мастер-домене /rest/v1/master/logicalroles/ws/bannedaddrs
+В конфигурации инстанса, можно настроить количество доступных ядер для конкретного микросервиса, что позволит при поступлении большого количества вредоносных запросов, снизить их влияне на другие сервисы платформы.
-* Обнаружьте заблокированный адрес.
+Также, имеет смысл использовать несколько экземпляров микросервисов, разделив между ними аплинки к провайдерам. В таком случае при перегрузке одного из них, остальные продолжат работать.
-* Удалите его.
-* Снова выполните скрипт пункта 1.
-* ''Какие изменения наблюдаются?''
-. Может быть у вас получится запустить множество скриптов с других машин и атаковать сервер с целью вывести его из обслуживания?
+= Журналы событий безопасноси =
+[[Файл:Журнал событий безопасности.png|мини|Журнал событий безопасности]]
+Платформа автоматически фиксирует важные события безопасности в специальный журнал для дальнейшего аудита. Журнал доступен к просмотру через приложение Администратор платформы, в разделе События.
-* Добавьте в конфигурацию еще один веб-сервер.
+Кроме базовых событий, в данный журнал также могут записываться события приложений, если разработчик предусмотрел фиксацию событий безопасности для аудита.
-* Напишите скрипт так, чтобы он давал указанную в параметрах частоту запросов. Используйте для этого вложенные и асинхронные скрипты.
-* Постепенно повышая нагрузку наблюдайте в htop за ростом загрузки процессора. Обратите внимание, как распределяется процессор между процессами. Отфильтруйте в htop список процессов, чтобы остались только ноды системы. Сравните загрузку между нодами ws.
-''Какие выводы можно сделать?''
+= Ограничение доступа к реестру учетных записей SIP =
+Механизм ролей платформы позволяет создать отдельную роль, разрешающую доступ к провайдерам для чтения и модификации, к правилам маршрутизации, но не разрешающую доступ к учетным записям пользователей, а к учетным записями SIP-устройств разрешающую доступ только для чтения.
-. Проведите аналогичные тесты с регистрацией по SIP.
+Помимо этого, возможна привязка ролей пользователей к динамической модели данных. Там могут ограничиваться доступы к конкретным коллекциям, к конкретным операциям с коллекцией, а также в особо тонких случаях, конкретные операции с конкретными записями в коллекциях.