Просмотр кода страницы Обеспечение безопасности SIP


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

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

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

В данной таблице, однако, приведены только методы, которые могут быть осуществлены средствами самой платформы. Следует обратить внимание на обеспечение безопасности сред, на которых платформа исполняется, так как несанкционированный доступ к среде исполнения позволяет обойти большинство ограничений и средств безопасности, описанных ниже.
{| class="wikitable"
|+Методы обеспечения безопасности
!Метод
!Комментарий
|-
|Смена портов SIP
|Использование нестандартных портов SIP при публикации системы во внешней сети, позволяет защититься от большого числа сканеров.
|-
|Защита от перебора пароля
|Автоматический фильтр-детектор, блокирующий доступ при большом количестве неудачных авторизаций SIP или TFTP
|-
|Настройка правил фильтрации запросов
|Настройка правил пограничного фильтра SG/ESG в мастер-домене. Позволяет делать черные и белые списки IP-адресов, а также гибко фильтровать входящие запросы.
|-
|Блокировка отправки ответов
|Специальный параметр в мастер-домене позволяет регулировать отправку ответов по неавторизованным запросам. По-умолчанию отправка отключена, что позволяет в некотором смысле, маскировать систему. Внешние системы злоумышленников не будут получать негативный результат авторизации и могут отменить дальнейший перебор паролей.
Этот же механизм позволяет добавлять адреса злоумышленников в динамические бан-листы.
|-
|Использование TLS для SIP
|Можно использовать TLS-шифрование для протокола SIP. В данном случае обязательно использование домена, необходимо либо получить публичный сертификат, либо использовать самоподписанный и на всех SIP-устройствах подключить корневой сертификат для проверки.
|-
|Политки паролей
|
|-
|Защита Autoprovision
|
|}

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

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

* 5060
* 5061
* 5063
* 5080

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

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

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

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

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

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

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

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

[[Файл:Фильтр_user-agent.png|мини|Фильтр user-agent]]
[[Файл:Drop-правило.png|мини|Drop-правило]]
'''Обязательным''' в данном случае является использование финального запрещающего все иные подключения фильтра с низким приоритетом. Запрещающие фильтры рекомендуется реализовывать методом 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 адрес должен иметь возможность скачать конфигурацию для устройства, содержащую пароль учетной записи.

== Динамические фильтры ==
Система блокирует на некоторое время IP-адреса, с которых поступают SIP-запросы, перебирающие учетные данные. Это касается веб-подключений и SIP-регистраций.

В тестах пригодится оставлять незаблокированный адрес.

Рекомендация: добавьте на клиента еще один сетевой интерфейс в той же подсети, либо на сервер и на клиента еще одну подсеть.

Дальнейшие тесты проводите с нового адреса, если иное не указывается.

1. Создайте sh-скрипт с выводом в консоль:

* Опрашивающий статический файл (''например index.html'') с дополнительного адреса.
* Инициирующий с помощью CURL авторизацию (''POST /rest/v1/iam/sessions'') с дополнительного адреса.
* Запустите скрипт. Убедитесь что авторизация успешно проходит.

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

Примеры скриптов можете запросить в телеграм канале.

2. Скопируйте скрипт под новым именем, укажите неверный пароль.

* Запустите скрипт. Обратите внимание на изменения.
* Скачайте лог-журнал с микросервиса ws. ''Как выглядят следы отказа?''

3. Скопируйте последний скрипт. Скопируйте строку авторизации с помощью CURL с неверным паролем 100 раз.

* Запустите скрипт. ''Заметьте на все ли запросы приходят ответы? На сколько запросов сервер ответит?''

4. Измените последний скрипт, сделав все неверные пароли разными.

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

5. Выполните скрипт из пункта 1.

* Какие изменения наблюдаются? Почему?

6. Опросите API в мастер-домене /rest/v1/master/logicalroles/ws/bannedaddrs

* Обнаружьте заблокированный адрес.
* Удалите его.
* Снова выполните скрипт пункта 1.
* ''Какие изменения наблюдаются?''

7. Может быть у вас получится запустить множество скриптов с других машин и атаковать сервер с целью вывести его из обслуживания?

* Добавьте в конфигурацию еще один веб-сервер.
* Напишите скрипт так, чтобы он давал указанную в параметрах частоту запросов. Используйте для этого вложенные и асинхронные скрипты.
* Постепенно повышая нагрузку наблюдайте в htop за ростом загрузки процессора. Обратите внимание, как распределяется процессор между процессами. Отфильтруйте в htop список процессов, чтобы остались только ноды системы. Сравните загрузку между нодами ws.

''Какие выводы можно сделать?''

8. Проведите аналогичные тесты с регистрацией по SIP.