По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! В этой статье мы рассмотрим Partitions и Calling Search Space (CSS) в Cisco Unified Communications Manager (CUCM) , которые являются частью механизма Class of Control и применяются при разграничении доступов.
/p>
Partitions можно рассматривать как набор маршрутов, паттернов, номеров DN, каждый из которых может принадлежать к определенным разделам. CSS же представляет собой упорядоченный список Partitions. Чтобы совершить вызов Partition вызываемой стороны должен принадлежать CSS вызывающей стороны.
При попытке выполнить вызов CUCM просматривает CSS вызывающей стороны и проверяет, принадлежит ли вызываемая сторона Partition’у в CSS. Если это так, вызов направляется в Translation Pattern. Если нет, то вызов отклоняется или Translation Pattern игнорируется. Подробнее про маршрутизацию и Translation Pattern’ы можно прочить в наших статьях.
Можно назначить разные CSS IP-телефонам, номерам DN, переадресации всех вызовов (Call Forwarding All – CFA), переадресации без ответа (Call Forwarding No Answer - CFNA), переадресации вызовов в случае занятости (Call Forwarding Busy - CFB), шлюзов и паттернам Translation Pattern.
Разделы и CSS облегчают маршрутизацию вызовов, поскольку они делят план маршрутизации на логические подмножества на основе организации, местоположения и/или типа вызова.
Чтобы лучше понять, как все это работает, рассмотрим пример.
Пример использования Partitions и CSS
Этот пример иллюстрирует, как можно разграничить маршрутизацию звонка между пользователями в пределах организации.
Допустим, у нас имеется три группы пользователей:
Стажеры (могут звонить только на внутренние номера)
Работники (могут звонить на внутренние номера и совершать междугородние звонки)
Руководство (могут звонить на внутренние номера, совершать междугородние и международные звонки)
Для каждого направления необходимо иметь Partition:
Внутренние номера –Partition_1
Междугородние звонки – Partition_2
Международные звонки – Partition_3
Эти разделы отражают все возможные направления звонков. Все телефоны (номера DN) мы поместим в раздел Partition_1 (внутренние номера).
На шлюзе сконфигурировано два паттерна Route Patterns:
Все звонки кроме международных (поместим в раздел Partition_2)
Международные звонки (поместим в раздел Partition_3)
На основании этих ограничений создаем три CSS:
CSS1 содержит разделы: Partition_1
CSS2 содержит разделы: Partition_1, Partition_2
CSS3 содержит разделы: Partition_1, Partition_2, Partition_3
Настраиваем телефоны:
На телефонах стажеров указываем CSS1
На телефонах работников указываем CSS2
На телефонах руководства указываем CSS3
Теперь совершим тестовые звонки с заданными настройками.
Тест 1: Звонок с телефона стажера
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_2 не включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 2: Звонок с телефона работника
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 3: Звонок с телефона руководства
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_3 включен в CSS)
Таким образом, получается, что вызовы совершать можно, только если раздел Partition вызываемого абонента находится в CSS вызывающего.
Настройка
Начнем с настройки Partitions. В Cisco Call Manager Administration переходим во вкладку Call Routing → Class of Control → Partition и нажимаем Add New. Здесь в поле Name указываем название для раздела и нажимаем Save.
Теперь перейдем к созданию CSS. Для этого выберем вкладку Call Routing → Class of Control → Calling Search Space. Тут указываем имя в поле Name, из поля Available Partitions перенесем в поле Selected Partitions разделы, которые должен содержать CSS. Перенос осуществляется при помощи стрелочек. После чего нажимаем кнопку Save для сохранения.
После того как мы создали CSS и Partitions на наших серверах, применим их к устройствам. Рассмотрим это на примере настройки телефона. Для этого выбираем телефон, который мы хотим настроить во вкладке Device → Phone. В его настройках выбираем желаемую линию и нажимаем на нее, например Line [1] . В открывшемся окне в строке Route Partition в выпадающем списке выбираем раздел для этой линии. После этого нажимаем Save и возвращаемся назад.
Теперь нам осталось применить к телефону CSS. Здесь, в настройках телефона в поле Device Information находим строчку Calling Search Space и в выпадающем меню выбираем созданный ранее CSS. Затем сохраняем и применяем настройки.
Аналогично мы можем настраивать Partitions и CSS на других устройствах, паттернах и номерах.
На днях к нам в офис пришел четырехпортовый FXO шлюз китайской компании Dinstar DAG100-4O. За относительно небольшие деньги, этот шлюз способен обработать до 4-х аналоговых линий. Помимо этого, имеет 4 Ethernet интерфейса – 3 по LAN и 1 под WAN подключение. Помимо обычного функционала стыка аналоговой телефонной сети и VoIP, этот аппарат умеет работать в режиме маршрутизатора в сети. Перейдем к распаковке:
Обзор шлюза
Коробка обычная, не фирменная - без символики компании.
Внутри коробки находится сам аппарат, блок питания, mini CD диск, обжатый с двух сторон патчкорд Ethernet и телефонный провод с коннектором RJ -11. Были приятно удивлены наличием соединительных шнуров, так как уже подготовились обжимать провода.
Вынимаем все оборудование из коробки.
На фронтовой панели DAG1000-4O находятся элементы индикации, а именно:
PWR – индикация наличия питания
RUN – работа шлюза
WAN – статус подключения по WAN интерфейсу
LAN – статус портов для подключения к LAN
FXO (0-4) – состояние FXO портов шлюза
Важно отметить, что индикация на FXO интерфейсах маршрутизатора является не постоянной. Порты индицируют только при входящем/исходящем вызовах. Не стоит забывать, что это все-таки аналог. Хочется отметить, что устройство немного «люфтит». Это означает, что при переносе был слышен дребезг металлического корпуса устройства.
На задней панели шлюза Dinstar располагаются порты для подключение FXO, LAN, WAN и питание.
На нижней части шлюза находится инструкция по настройке шлюза. Вот что необходимо сделать для подключения к графическому интерфейсу шлюза:
Подключить DAG1000-4O к сети через интерфейс LAN0.
Подключить телефонные линии в FXO интерфейсы.
На компьютере, подключенном в тот же сетевой сегмент сети что и шлюз, ввести IP адрес 192.168.11.199, маску подсети 255.255.255.0 и шлюз по умолчанию 192.168.11.1.
Применить изменения, открыть в интернет браузере адрес 192.168.11.1 и ввести логин и пароль admin/admin.
Конфигурация DAG1000-4O
Перейдем к непосредственной настройке шлюза. Первым делом, подключившись к WEB – интерфейсу необходимо поменять IP – адрес шлюза (мы ведь не можем каждый раз менять IP – адрес NIC своего ПК чтобы администрировать шлюз). Делается это во вкладке Network -> Local Network. Выставляем настройки и нажимаем на Save. Важно отметить, что шлюз может работать как в режиме маршрутизатора, так и в режиме моста. Ниже представлен интерфейс для настройки в режиме моста.
При настройке в режиме маршрутизатора (Route), в конфигурации прибавляется возможность настройки WAN порта шлюза.
Перейдем к настройке SIP сервера в соответствующую вкладку SIP Server и настроим коннект между шлюзом и Asterisk. Здесь необходимо указать IP – адрес, порт и интервал регистрации.
Переходим к настройка Asterisk. В нашем случае, мы пользуемся графической оболочкой FreePBX. Заходим во вкладке Connectivity -> Trunks и создаем новый транк с такими параметрами:
Производим настройку транка, в соответствие с вышеуказанными параметрами. В данном случае, 192.168.1.110 – это адрес шлюза. Жмем Submit, а затем Apply Config.
Возвращаемся на шлюз и идем во вкладку Advanced -> FXS/FXO. Указываем страну, в которой находимся. Мы указали Russia. В сегменте FXO Parameter указываем Detect CID, отмечая галочку на соответствующем поле, и выбираем Send Original CID when Call from PSTN, чтобы получить номер звонящего из публичной сети. Жмем сохранить.
Переходим во вкладку Port. Нажимаем на Add и настраиваем FXO порт №0. Вводим данные, как мы создали на Asterisk в настройках транка. Offhook Auto-Dial это в нашем случае номер, на который шлюз пробрасывает пришедший вызов. На стороне Asterisk настроен входящий маршрут на этот DID, 2253535, который уже и проводим манипуляции с вызовом. Жмем Save.
Идем во вкладке Call & Routing и выбираем Tel->IP/Tel Routing. В данной статье мы покажем как настраивать входящую из PSTN маршрутизацию вызовов. Отметим, что исходящая маршрутизация настраивается аналогично. В указанной вкладке меню жмем Add.
Здесь настроено следующее правило:
Все звонки с FXO порта №0 (Call From) с любым префиксом отправлять на SIP сервер (Calls to). Вот и все, теперь наш шлюз будет отправлять все вызовы с порта 0 на Asterisk.
Заходим во вкладку Status & Statistics -> Registration и видим, что наш порт зарегистрирован на Asterisk.
Теперь можно принимать вызовы с настроенной аналоговой линии через шлюз.
Не секрет, что на сегодняшний день Kubernetes стал одной из лучших оркестраторов контейнерных платформ. Более 80% организаций сегодня используют Kubernetes в тех или иных целях. Он просто автоматизирует конфигурирование и управление контейнерами.
Но помимо простоты, безопасность также является одной из наиболее важных частей любого контейнерного приложения. Вы должны знать, как обеспечить надежную безопасность приложений, работающих в кластере Kubernetes. Вопросы безопасности в последние несколько лет экспоненциально возрастают, поэтому каждая организация сосредотачивает внимание на этой области.
Если вы знакомы с Kubernetes, то вы знаете, что, по умолчанию, Kubernetes назначает IP-адрес каждому порту в кластере и обеспечивает безопасность на основе IP. Но он предоставляет только основные меры безопасности. Когда речь заходит о расширенном мониторинге безопасности и обеспечении соответствия нормативным требованиям, к сожалению, Kubernetes не обеспечивает нужного уровня безопасности. Но, к счастью, есть сторонние сканеры Kubernetes с открытым исходным кодом, которые могут помочь вам защитить ваши кластеры Kubernetes.
Вот несколько преимуществ использования сканеров Kubernetes:
Определение неправильных настроек и уязвимостей в кластере, контейнерах, модулях
Предоставляет решения для исправления неправильных настроек и устранения уязвимостей
Дает представление о состоянии кластера в реальном времени.
Дает больше уверенности команде DevOps в необходимости разработки и развертывания приложений в кластере Kubernetes
Помогает избежать сбоя кластера, выявляя проблему на ранней стадии.
Рассмотрим следующие инструменты, которые помогут найти уязвимость и неправильную конфигурацию системы безопасности для обеспечения безопасности контейнерных приложений.
1. Kube Hunter
Kube Hunter - это средство поиска уязвимостей от Aqua Security. Этот инструмент очень полезен для повышения уровня безопасности кластеров Kubernetes. Этот инструмент для выявления уязвимостей предлагает несколько стандартных вариантов сканирования, таких как удаленный, чересстрочный, сетевой.
Он содержит список активных и пассивных тестов, которые могут идентифицировать большинство уязвимостей, присутствующих в кластере Kubernetes.
Существует несколько различных вариантов использования этого инструмента.
Можно загрузить архив, извлечь его или использовать pip для непосредственной установки Kube Hunter на машину с сетевым доступом к кластеру Kubernetes. После установки можно начать сканирование кластера на наличие уязвимостей.
Второй способ использования Kube Hunter - в качестве контейнера Docker. Вы можете непосредственно установить Kube Hunter на машину в кластере, а затем проверить локальные сети для сканирования кластеров.
И третий способ - запустить Kube Hunter как под внутри Kubernetes кластера. Это помогает находить уязвимости в любых модулях приложений.
2. KubeBench
Kube Bench является одним из инструментов обеспечения безопасности с открытым исходным кодом, которые проверяют соответствие ваших приложений эталонному стандарту безопасности CIS (Center for Internet Security).
Он поддерживает тесты для нескольких версий Kubernetes. Кроме того, он также указывает на ошибки и помогает в их исправлении. Этот инструмент также проверяет настройки авторизации и аутентификации пользователей, а также уровень шифрования данных. Это гарантирует, что приложение соответствует требованиям CIS.
Возможности KubeBench:
Написано как приложение Go
Тест для мастеров и узлов Kubernetes
Доступно как контейнер
Тесты определены в YAML, что упрощает расширение и обновление
Поддержка выходных данных формата JSON
3. Checkov
Checkov - это средство безопасности, используемое для предотвращения неправильных настроек облака во время сборки Kubernetes, Terraform, Cloudformation, Serverless фреймворков и других сервисов типа Infrastructure-as-code-language. Он написан на языке Python и направлен на повышение эффективности внедрения безопасности и соответствия передовым практикам.
Можно выполнить сканирование с помощью Checkov для анализа сервисов типа Infrastructure-as-code-language
Функции Checkov:
Открытый и простой в использовании
Более 500 встроенных политики безопасности
Передовые практики обеспечения соответствия для AWS, Azure и Google Cloud
Поддержка нескольких форматов вывода - CLI, JUnit XML, JSON
Интеграция сканирований в конвейеры ci/cd
Выполняет сканирование входной папки, содержащей файлы Terraform & Cloudformation
4. MKIT
MKIT означает управляемый инструмент проверки Kubernetes. Этот инструмент помогает быстро выявлять ключевые угрозы безопасности кластеров Kubernetes и их ресурсов. Он имеет быстрые и простые методы для оценки неправильных настроек в кластере и рабочих нагрузках.
Инструмент поставляется с интерфейсом, который по умолчанию работает на http://localhost:8000. Инструмент дает представление о неуспешных и успешных проверках. В разделе «Затронутые ресурсы» вы получите подробные сведения о затронутых и не затронутых ресурсах.
Функции MKIT:
Создана с использованием всех библиотек и инструментов с открытым исходным кодом
Простота установки и использования
Поддержка нескольких поставщиков Kubernetes - AKS, EKS и GKE
Хранение конфиденциальных данных внутри контейнера
Предоставляет веб-интерфейс
5. Kubei
Kubei используется для оценки непосредственных рисков в кластере Kubernetes. Большая часть Kubei написана на языке программирования Go. Он охватывает все эталонные тесты CIS для Docker.
Он сканирует все образы, используемые кластером Kubernetes, прикладные и системные модули и т.д. Вы получаете несколько вариантов настройки сканирования с точки зрения уровня уязвимости, скорости сканирования, области сканирования и т.д. С помощью графического интерфейса можно просмотреть все уязвимости, обнаруженные в кластере, и способы их устранения.
Основные характеристики Kubei:
Сканер уязвимостей среды выполнения Kubernetes с открытым исходным кодом
Проверяет общедоступные образы, размещенные в реестре
Предоставляет состояние работоспособности кластера в режиме реального времени
Веб-интерфейс пользователя для визуализации сканирований
Предоставляет несколько пользовательских параметров для сканирования
6. Kube Scan
Kube Scan - это сканер контейнера, который сам поставляется как контейнер. Вы устанавливаете его в новый кластер, после чего он сканирует рабочие нагрузки, выполняющиеся в данный момент в кластере, и показывает оценку риска и сведения о рисках в удобном веб-интерфейсе. Риск оценивается от 0 до 10, 0 означает отсутствие риска, а 10 - высокий риск.
Формула и правила оценки, используемые Kube scan, основаны на KCCSS, общей системе оценки конфигурации Kubernetes, которая является фреймворком с открытым исходным кодом. Он аналогичен CVSS (Common Vulnerability Scoring System). Он использует более 30 параметров настройки безопасности, таких как политики, возможности Kubernetes, уровни привилегий и создает базовый уровень риска для оценки риска. Оценка риска также основана на простоте эксплуатации или уровне воздействия и масштабах эксплуатации.
Функции KubeScan:
Инструмент оценки рисков с открытым исходным кодом
Веб-интерфейс пользователя с оценкой рисков и подробностями оценки рисков
Выполняется как контейнер в кластере.
Регулярные сканирование кластера каждые 24 часа
7. Kubeaudit
Kubeaudit, как предполагает название, является инструментом кластерного аудита Kubernetes с открытым исходным кодом. Он находит неправильные настройки безопасности в ресурсах Kubernetes и подсказывает, как их устранить. Он написан на языке Go, что позволяет использовать его как пакет Go или средство командной строки. Его можно установить на компьютер с помощью команды brew.
Он предлагает различные решения вроде запуск приложений от имени пользователя без рут прав, предоставление доступа только для чтения к корневой файловой системе, избегание предоставления дополнительных привилегий приложениям в кластере для предотвращения общих проблем безопасности. Он содержит обширный список аудиторов, используемых для проверки проблем безопасности кластера Kubernetes, таких как SecurityContext модулей.
Особенности Kubeaudit:
Инструмент аудита Kubernetes с открытым исходным кодом
Предоставляет три различных режима - манифест, локальный, кластер, для аудита кластера
Дает результат аудита на трех уровнях серьезности - ошибка, предупреждение, информация
Использует несколько встроенных аудиторов для аудита контейнеров, модулей, пространств имен
8. Kubesec
Kubesec - это инструмент анализа рисков безопасности с открытым исходным кодом для ресурсов Kubernetes. Он проверяет конфигурацию и файлы манифестов, используемые для развертывания и операций кластера Kubernetes. Вы можете установить его в свою систему с помощью образа контейнера, двоичного пакета, контроллера допуска в Kubernetes или плагина kubectl.
Особенности Kubesec:
Инструмент анализа рисков с открытым исходным кодом
Он поставляется с объединенным HTTP-сервером, который по умолчанию работает в фоновом режиме и слушает порт 8080.
Может запускаться как Kubesec-as-a-Service через HTTPS по адресу v2.kubesec.io/scan
Может сканировать несколько документов YAML в одном входном файле.
Заключение
Указанные средства предназначены для обеспечения безопасности кластера Kubernetes и его ресурсов и затрудняют взлом хакерами приложений, работающих внутри кластера. Сканеры помогут более уверенно развертывать приложения на кластере.