Oagapov в 15:43, 9 декабря 2024

2024-12-09T15:43:57Z

← Предыдущая версия		Версия от 15:43, 9 декабря 2024
Строка 172:		Строка 172:
	* ''Как снизить риски постороннего вмешательства в работу системы?''		* ''Как снизить риски постороннего вмешательства в работу системы?''
	* ''Как снизить риски несанкционированного доступа?''		* ''Как снизить риски несанкционированного доступа?''
			{{СОРТИРОВКА_ПО_УМОЛЧАНИЮ: 20. Безопасность и защита от взлома}}
	[[Категория:Курс IP АТС]]		[[Категория:Курс IP АТС]]

Oagapov: Новая страница: «В комплексе мер против внешних атак есть следующие: * закрытая сеть (). нестандартный порт. * отказ от ответов неизвестным инициаторам запросов (). белый список адресов/масок/диапазонов (). черный список адресов/масок/диапазонов/юзерагентов/доменов/us...»

2024-12-09T15:39:00Z

Новая страница: «В комплексе мер против внешних атак есть следующие: * закрытая сеть (*). * нестандартный порт. * отказ от ответов неизвестным инициаторам запросов (*). * белый список адресов/масок/диапазонов (*). * черный список адресов/масок/диапазонов/юзерагентов/доменов/us...»

Новая страница

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

* закрытая сеть (*).
* нестандартный порт.
* отказ от ответов неизвестным инициаторам запросов (*).
* белый список адресов/масок/диапазонов (*).
* черный список адресов/масок/диапазонов/юзерагентов/доменов/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?''
* ''Как снизить риски постороннего вмешательства в работу системы?''
* ''Как снизить риски несанкционированного доступа?''

[[Категория:Курс IP АТС]]

20. Безопасность и защита от взлома - История изменений

Oagapov в 15:43, 9 декабря 2024