Обеспечение безопасности. Практика

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

1. Перенастройте систему на другие порты

2. Откажитесь от использования 5060, 5061, 5063 портов.

3. Замените их на другие и перенастройте все подключенные устройства.

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

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

Смена стандартного порта 5060 UDP (TCP) на другой (например, 9061) позволит многократно снизить вероятность обнаружения открытого порта со стороны злоумышленников.

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

Фильтр подсетей

Фильтр SIP домена

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

Фильтр user-agent

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.

Утечки и подбор паролей

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

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

• Если получится — подытожьте, какие доступы вам понадобились для этого, и пожалуйста, свяжитесь с вендором.
• Если не получится — перечислите опробованные способы и причины по которым не удалось этого сделать.

2*. Подумайте над тем, какие еще потенциальные уязвимости появляются, если у злоумышленника есть доступ к диску сервера.

3*. Подумайте, какие данные могут оказаться подвержены утечке вместе с лог-журналами системы, отправляемыми на диагностику.

Роли пользователей

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

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

2. Создайте пользователя с ролью "liteadmin".

3. Задайте для ее учетной записи режим, при котором совсем недоступные разделы не отображаются.

• Авторизуйтесь под созданной учетной записью.
• Проверьте что раздел с пользователями не виден.
• Проверьте что раздел с SIP-учетками виден.
• Попробуйте изменить SIP-учетку. Должен быть отказ.
• Попробуйте через API получить доступ к учетным записям пользователей (/rest/v1/iam/users, /api/crud/v1/user/read)
• Попробуйте создать сценарий, получающий доступ к паролю админа.

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