20. Безопасность и защита от взлома

В комплексе мер против внешних атак есть следующие:

• закрытая сеть (*).
• нестандартный порт.
• отказ от ответов неизвестным инициаторам запросов (*).
• белый список адресов/масок/диапазонов (*).
• черный список адресов/масок/диапазонов/юзерагентов/доменов/username.
• автоматический список блокировки адресов, перебирающих логины/пароли.

В части черных списков в перспективе, либо проектным образом с помощью ETL, можно локальный черный список синхронизировать с каким-то глобальным.

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

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

• стандартный порт 5060 отдан экземпляру SG, ответственному за обработку внутренних подключений и игнорирующего всё остальное;
• белый и черный списки не настроены;
• настроен отказ от ответам неизвестным инициаторам запросов;
• всегда включен динамический фильтр IP-адресов, перебирающих учетные записи и/или пароли.

Не стоит забывать, что взлом системы возможен и по другим направлениям, в том числе из внутренней сети. Следует рассматривать угрозы максимально широко, и производить соответствующие настройки в том числе серверов и операционной системы, баз данных, не открывать доступы в тех направлениях, где они не используются. Политика паролей, политика доступов к админке, политика доступов к серверу по ssh, политика доступа к серверам баз данных — всё должно быть заблаговременно продумано и настроено.

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

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

Задание 20.1. Публичные порты SIP

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

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

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

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

Задание 20.2. Тестируем правила

Тестируем правила

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 адрес должен иметь возможность скачать конфигурацию для устройства, содержащую пароль учетной записи.

Задание 20.3. Динамические фильтры

Динамические фильтры

Система блокирует на некоторое время 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.

Задание 20.4. Утечки и подбор паролей

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

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

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

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

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

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

Задание 20.5. Роли пользователей

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

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

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

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

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

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

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

Задание 20.6. Атаки снаружи

Атаки снаружи

Предложите варианты:

• Как защититься от DDoS?
• Как снизить риски постороннего вмешательства в работу системы?
• Как снизить риски несанкционированного доступа?