По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В одной из предыдущих статей мы рассматривали межсетевой экран ASA и порядок его первоначальной настройки. Но ничего не стоит на месте и в какой-то момент Cisco купила компанию Sourcefire за баснословные миллиарды "Даларов". Зачем? Ну, во-первых, у Sourcefire был один из лучших в то время на рынке IPS-ов и еще был ряд интересных продуктов, которые Cisco успешно забрала себе в портфолио, например – Advanced Malware Protection, который по сути своей является End Point Detection & Response решением. Зачем? А чтобы можно было вовремя реагировать на угрозы и проводить расследования. Ну да ладно, мы таки FirePower настраивать собрались. Первоначально Firepower выступал в качестве дополнительного модуля (виртуального в случае 5506-5555 и физического в случае 5585) к ASA. Что есть этот модуль? Этот модуль – отдельный и самобытный кусок ПО, доставшийся от Sourcefire. Отсюда следует забавный вывод: для управления этим модулем требовалась отдельная консоль управления (в идеале). А еще, логика обработки пакетов была довольной необычной, но так как экран работал с относительно небольшими скоростями, было принято решение о выносе модуля FirePower в качестве отдельного, уже не относящегося к межсетевому экрану ASA и назвали это чудо FirePower Threat Defense – где в базе используется ASA, а сверху прилеплен NGFW функционал. Новые FirePower-ы имеют огромную производительность – подробнее смотрите в даташитах. Кратко о наших баранах или общие рекомендации Вариации настройки платформы Firepower Threat Defense всего два (а если рассматривать ASA + FirePower сервисы, то аж три, или даже четыре – такой вот коленкор): FirePower Management Center (FMC) – централизованное управления политиками, устройствами и событиями. Обладает автоматизацией, что упрощает настройку. FirePower Device Manager (FDM) – является простым автономным решением для стандартных настроек правил обеспечения безопасности. Мы же рассмотрим самую медленную, но самую богатую (по функционалу) вариацию – средство централизованного управления FMC. Она обладает многопользовательской настройкой, более продвинутым реагированием на угрозы, такой прям мини-SIEM. Также предусмотрено наследование политик (централизованный пуш конфигурации на устройства), что упрощает настройку. Перейдем непосредственно к первоначальной настройке FMC. Настройки будем рассматривать для IPS/IDS (комплексы средств для предотвращения и обнаружения угроз в локальную сеть). Чтобы максимально эффективно использовать IDS/IPS, нужно придерживаться следующих рекомендаций: Систему необходимо разворачивать на входе защищаемой сети или подсети и обычно за межсетевым экраном (нет смысла контролировать трафик, который будет блокирован) — так мы снизим нагрузку. В некоторых случаях датчики устанавливают и внутри сегмента. Перед активацией функции IPS следует некоторое время погонять систему в режиме, не блокирующем (IDS). В дальнейшем потребуется периодически тюнинговать правила. Большинство настроек IPS установлены с расчетом на типичные сети. В определённых случаях они могут оказаться неэффективными, поэтому необходимо обязательно указать IP внутренних подсетей и используемые приложения (порты). Это поможет железке лучше понять, с чем она имеет дело. Но тут есть такая штука как NGIPS – система снимает профиль трафика и может сама под него подстраиваться, включая нужные правила и отключая ненужные. Если IPS-система устанавливается «в разрыв», необходимо контролировать ее работоспособность, иначе выход устройства из строя может запросто парализовать всю сеть. Настройте вы его уже наконец – часть 1 Итак, приступим к настройке платформы Сisco FirePower: Устанавливаем Необходимое ПО: Его можно найти в вашем комплекте поставки, либо можете скачать с официального сайта cisco.com (при наличии у вас сервисного контракта). ПО понадобится следующее: FirePower Management Center (поддерживает ESXi и KVM) и образ для вашей железяки или же образ виртуального Firepower-а, который американцы прозвали NGFWv. Подключаем кабели (согласно указанной ниже схеме и что неприменимо к виртуалке). Console port – консольный порт Management port – для подключения и настройки сети Logical Device Management – для настройки логических устройств (можно настраивать как 1, так и все интерфейсы сразу) Поместите FMC в сеть управления логическими устройствами. Для обновлений FTD и FMC требуется подключение к интернету. Если оборудование не новое (было кем-то использовано), необходимо стереть текущую конфигурацию следующими командами (выделены «жирным»): Firepower-chass Firepower-chassis # connect local-mgmt Firepower-chassis(local-mgmt)# erase configuration Подключитесь к последовательному консольному порту, используя эмулятор терминала. Firepower 9300 включает последовательный консольный кабель RS-232 – RJ-45. Вам может понадобиться использовать кабель последовательного интерфейса USB от стороннего производителя для подключения. Используйте следующие серийные параметры: 9600 baud 8 data bits No parity 1 stop bit При появлении запроса войдите в систему с именем пользователя admin и паролем cisco123. Вводим только то, что выделено «жирным». Когда появится запрос о подтверждении конфигурации, подтверждаете – просто наберите yes. Настройте вы его уже наконец – часть 2 Далее нам необходимо произвести настройки, используя браузер. Обращаю внимание, что не каждый браузер подойдет! Настраивать можно только с управляющего компьютера, IP-адрес которого попадаем в диапазон, который указывали в конфигурации. Заходим в браузер и в поисковую строку (строку ввода URL) вводим следующее: https://адрес_железки Вводим имя пользователя admin и новый пароль для входа в дальнейшем. Осуществляем процедуру входа в систему. Настраиваем NTP соединение. Оно нужно нам для синхронизации времени на всех устройствах. От этого зависит как стабильность, так и сама работа в принципе. Заходим непосредственно в настройки и выбираем параметр использования NTP-сервера. В правом нижнем углу выберите «Add» NTP Server (обязательное поле для заполнения) должен включать IP-адрес или имя host-сервера, Authentication Key – идентификатор от NTP-сервера. Если не знаете этот ключ, можете найти его поискав через поисковик (ntp.keys). Также можно получить его (при условии, что файла ntp.keys нет), прописав команду в консоли управления ntp-keygen -M, затем поискав тот же самый файл, вы найдете его в директории. Нажимаем «Add» и добавляем наш NTP-сервер. Сохраняем изменения. Заходим во вкладку «Current Time», затем «Time Zone» и выбираем свой часовой пояс из списка и после сохраняем настройки. Настройте вы его уже наконец – часть 3. Настройка базового функционала. Настроим интерфейсы. Для этого переходим в саму вкладку «Interfaces», расположенную у рамки окна в черной полосе. Нажимаем «Edit» для интерфейса, который собираемся настроить. Открываем порт для работы галочкой напротив «Enable». В строке «Type» выбираем назначение интерфейса (мы будем передавать данные, поэтому выбираем пункт «data-sharing». Остальные данные заполнять не обязательно. Скажу, что там настраивается Скорость передачи, авто согласование и режим дуплекса соответственно. Лучше оставить данные параметры не настроенными, система сама перестроится для работы. Перейдем непосредственно к настройке IPS (политика обнаружения вторжений). Выбираем пункт Policies > Access Control > Intrusion Далее жмем Сreate Policy (справа кнопка) И в появившемся окне заполняем имя (Name) (обязательный параметр). Если вы не обладаете достаточными знаниями для детальной настройки IPS, воспользуйтесь рекомендуемыми фильтрами. Пункт Base Policy, в нем выбираем Maximum Detection (максимальная защита). Создаем и применяем изменения с помощью кнопки Create and Edit Policy. IPS тут умен, гораздо умнее автора этой статьи. В ходе эксплуатации вы это заметите. А именно, что при использовании максимальной степени защиты (Maximum Detection) программное обеспечение предложит вам исключить правила, которые не нужны и просто на «холостую» тратят ресурсы вашего устройства защиты. Такие рекомендации она делает по результатам статистики. Она хранится в Policies > Access Control > Intrusion > Firepower Recommendations > Generate Recommendations Таким образом, система адаптируется индивидуально для вашей сети. Настроим обнаружение вирусов и зараженных файлов. Но для более адекватной работы сети, рекомендуется создать DNS «ловушку» (следующий пункт), которая покажет, на какое именно устройство пришел вредоносный файл. Если «ловушку» не создавать, то информация о зараженном файле появится в общем хранилище и определить, какое из устройств получило этот вредоносный файл (код), не представится возможным. Переходим по пути: Policies > Access Control > Malware & File. Создаем новую политику, даем ей название. Затем добавляем правило (Add Rule). Заполнить рекомендуется так, как указано на изображении. Это общепринятое правило с максимальной степенью защиты. Нажимаем Save. Теперь настроим DNS «ловушку». Objects > Object Management. Отыскиваем в левой колонке Sinkhole. Далее нажимаем Add Sinkhole Заполняем таблицу. При заполнении обратите внимание на то, что данные, указанные в IPv4/6 не должны быть в вашей сети. После настройки нажимаем Save. Далее переходим в настройку DNS политики (Policies > Access Control > DNS). Выбираем Add DNS Policy, добавляем название и сохраняем. Нас автоматически переводит в это правило. Мы видим, 2 раздела (белый и черный листы. Нам необходимо создать и настроить своё правило. Для этого нажимаем Add DNS Rule и появляется новое окно. Заполняем его как на изображении. В нем мы добавляем все возможные правила, рекомендуемые компанией Cisco. Выбираем все файлы и нажимаем Add to Rule. И непосредственно здесь мы можем применить свою DNS «ловушку». Для этого в пункте Action выбираем Sinkhole. Напротив откроется новый пункт, в котором мы выбираем наш DNS «ловушку». Теперь мы сможем видеть, на какое устройства пришел вредоносный файл (код). На этом первоначальные настройки произведены. Далее производится более детальная настройка исходя из ваших потребностей.
img
Использование REST API является полезной функцией для реализации ваших сценариев. Вы можете получить доступ к новым функциям, а также расширить возможности создания новых, более продвинутых сценариев. Опыт многих пользователей показывает, что, когда начинаешь использовать REST API в скриптах, то чувствуешь себя довольно неуклюже и непривычно. В этой заметке мы обсудим: Что такое REST API Как читать документацию Как использовать API REST с PowerShell Некоторые советы и подсказки, как облегчить и улучшить практику Что такое "REST"? REST, или RESTful API, это API, который использует HTTP запросы для получения, добавления, удаления или манипулирования данными в различных сервисах. Как правило, то, что нужно сделать с данными, решается тем, какой HTTP-метод вы используете. Вот краткий список методов HTTP и их применение в REST API: GET-Read POST-Create PATCH-Partial update/modify PUT-Update/replace DELETE-Remove Данные, которые возвращает API REST, обычно представляются в формате JSON. Теперь давайте начнём с нашего первого API запроса! Что такое API Работа с документацией Для использования различных API REST необходимо научиться читать и интерпретировать документацию. К счастью, если вы знаете, как читать один тип документации, вы сможете быстро научиться читать другие. В этой статье мы используем petstore.swagger.io, так как он использует популярный фреймворк Swagger, который довольно часто используется в разработке. На предыдущем рисунке показана наиболее важная информация о конечных точках REST API: HTTP-метод-GET/POST/DELETE и т.д. URL-адрес, связанный с конечной точкой REST API (Базовый URL, как правило, представлен в верхней части страницы документации) Краткое описание Подробности Первая страница документации просто замечательная, и, как правило, с помощью этой информации можно выполнить большинство запросов, требующих использования метода HTTP GET. Но такие методы, как POST и SET, обычно требуют, чтобы вы щелкнули и развернули строку, чтобы получить больше информации. Если вы нажмете на одну из строк, то получите информацию, которая выглядит так: Здесь мы представили конечную точку REST, которая может создать новый объект pet. Здесь указывается, как должен выглядеть JSON, предоставленный в теле POST, и какой тип контента он принимает. Другие конечные точки REST указывают, что это за параметры, каким типом данных они должны быть и т.д. Это основы для чтения документации. Теперь, когда общие принцип более-менее ясны, пора начать использовать REST API с PowerShell. Получение первых данных (GET) Используя REST API с PowerShell обычно довольно просто, используется встроенные командлеты, таким образом, нет необходимости в дополнительных модулях. Мы собираемся извлечь данные с помощью метода GET в конечной точке /pet/{ petId}. Если развернуть конечную точку /pet/{ petId} в документации, можно увидеть, что {petId} на самом деле является параметром, который принимает целое число. Это делает URL-адрес для выборки объекта pet с идентификатором 1: https://petstore.swagger.io/v2/pet/1 В документации SWAGGER REST API обычно отображается базовый URL-адрес в верхней части страницы. Теперь начнем с PowerShell. Откройте окно терминала и введите: PS51 > Invoke-RestMethod -Method GET -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1" id : 1 category : @{id=0; name=string} name : doggie photoUrls : {string} tags : {@{id=0; name=string}} status : available Поскольку в ответе от сервера возвращается тип содержимого "application/json" используется метод Invoke-RestMethod, который автоматически преобразует возвращаемый JSON в объект. Ошибка 404 Not found, как правило, означает, что объект не найден или URL-адрес введен неправильно. Итак, мы выполнили первый вызов REST API. Но возможности метода GET для получения данных довольно ограничены, так что давайте создадим что-нибудь с помощью метода POST. Создание объекта методом POST Метод POST чаще всего используется для создания, например, пользователей или записей и т.д. Запрос POST отправляет BODY, содержащий информацию, конечной точке REST, обычно в формате JSON, но он также может быть в виде формы с кодировкой URL. Вы узнаете, как создать объект JSON, который можно отправить в конечную точку/pet. Можно увидеть, как должен выглядеть JSON, если развернуть строку POST/pet в документации. Начнем с создания хэштаблицы, который можно преобразовать в объект JSON. Raw JSON следует избегать в скриптах PowerShell, поскольку он ограничивает его возможности. $Body = @{ id = 19 category = @{ id = 45 name = "Whatever" } name = "Dawg" photoUrls = @( "string" ) tags = @( @{ id = 0 name = "string" } ) status = "available" } Если вам трудно создать хештаблицу, который преобразуется в нужный JSON, установите модуль PsdKit и используйте команду $ JsonString | ThreadTo-Psd Теперь имеется хэш-таблица, которую можно преобразовать в строку JSON и POST в конечную точку/pet: $JsonBody = $Body | ConvertTo-Json $Uri = "https://petstore.swagger.io/v2/pet" Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method Post -Body $JsonBody id : 19 category : @{id=45; name=Whatever} name : Dawg photoUrls : {string} tags : {@{id=0; name=string}} status : available При создании объекта он обычно получает созданный для подтверждения объект. Использование DELETE. Метод DELETE используется для удаления данных, а применение очень схоже с методом GET. PS51 > Invoke-RestMethod -Method DELETE -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1" Только убедитесь, что не удалите ничего важного Использование PUT Метод PUT используется для обновления данных. Это делается аналогично методу POST путем представления полного или частичного объекта JSON: PS51> $Body = [PSCustomObject]@{ id = 19 name = "Dawg with a new name" } PS51> $JsonBody = $Body | ConvertTo-Json PS51> $Uri = "https://petstore.swagger.io/v2/pet" PS51> Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method PUT -Body $JsonBody id name photoUrls tags -- ---- --------- ---- 19 Dawg with a new name {} {} Обычно API REST возвращает объект JSON с использованными и/или обновленными данными. Можно увидеть, что объект был обновлен с помощью метода GET: PS 51> Invoke-RestMethod -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/19" id : 19 category : @{id=45; name=Whatever} name : Dawg with a new name photoUrls : {string} tags : {@{id=0; name=string}} status : available Создание функций Писать эти команды каждый раз вручную может стать довольно утомительным и на самом деле не масштабируемым. Если мы вызываем конечную точку несколько раз, то лучше создать для нее функцию. Это довольно просто и нужно написать всего несколько строк: Function Get-PetstorePet { [cmdletbinding()] param( # Id of the pet [Parameter(Mandatory,ValueFromPipeline)] [int]$Id ) Begin{} Process{ $RestMethodParams = @{ Uri = "https://petstore.swagger.io/v2/pet/$Id" ContentType = "application/json" Method = "GET" } Invoke-RestMethod @RestMethodParams } End{} } После создания функции ее можно вызвать в сценарии: PS51> Get-PetstorePet -Id 1 id name photoUrls tags -- ---- --------- ---- 1 Doggie {http://picture.url} {} Это можно сделать и для метода POST для создания нового объекта pet в Petstore: Function Add-PetstorePet { [cmdletbinding()] param( # Id of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [int]$Id, # Name of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$Name, # Status of the pet (available, sold etc) [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$Status, # Id of the pet category [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [int]$CategoryId, # Name of the pet category [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string]$CategoryName, # URLs to photos of the pet [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [string[]]$PhotoUrls, # Tags of the pets as hashtable array: @{Id=1;Name="Dog"} [Parameter(Mandatory,ValueFromPipelineByPropertyName)] [Hashtable[]]$Tags ) Begin{} Process{ $Body = @{ id = $Id category = @{ id = $CategoryId name = $CategoryName } name = $Name photoUrls = $PhotoUrls tags = $Tags status = $Status } $BodyJson = $Body | ConvertTo-Json $RestMethodParams = @{ Uri = "https://petstore.swagger.io/v2/pet/" ContentType = "application/json" Method = "Post" Body = $BodyJson } Invoke-RestMethod @RestMethodParams } End{} } И вызов этой функции PowerShell намного упрощает задачу: PS51> $AddPetStorePetsParams = @{ Id = 44 Name = "Birdie" Status = "available" CategoryId = 50 CategoryName = "Hawks" PhotoUrls = "https://images.contoso.com/hawk.jpg" Tags = @( @{ Id=10 Name="Not eagles" } ) } PS51> Add-PetStorePet @AddPetStorePetsParams id : 44 category : @{id=50; name=Hawks} name : Birdie photoUrls : {https://images.domain.com/hawk.jpg} tags : {@{id=0}} status : available Возможно, что многие модули, которые вы ежедневно используете, состоят из функций, который за кулисами используют REST API. Заключение Обучение работы с REST API, главным образом основано на чтении документации. Мы использовали документацию на основе SWAGGER в этом посте, так как она представляет, как могут выглядеть другие стили документации. Кроме того, преобразование вызовов API в функцию может сэкономить много времени, упростить работу и очистить сценарии.
img
Расскажем о том, как настроить активную запись разговоров на Cisco UCM (CUCM). Если быть кратким, активная запись это гораздо более удобный, гибкий, масштабируемый и производительный способ выполнить запись разговоров на аппаратах Cisco (с поддержкой BiB). Вы спросите гораздо более удобный по сравнению с чем? С пассивным - ответим мы. Пассивный метод записи осуществляется с помощью зеркалирования трафика, с помощью SPAN/RSPAN/ERSPAN. Работает это примерно так: сервер записи забирает метаданные звонка через специальный API (JTAPI в CUCM, это часть CTI), а RTP поток уходит напрямую с телефона через BiB (Built-in Bridge). Активную запись поддерживают такие вендоры как Nice, ZOOM, Verint, ЦРТ и другие. Приступаем к настройке. Почитать подробнее о том, как работает система записи телефонных переговоров можно по ссылке. Настройка Application User на CUCM Логинимся на интерфейс IP PBX. Далее, выбираем User Management → Application User. Нажимаем Add New. Появляется дисплей: Вводим User ID; Вводим пароль пользователя в поле "Password". Введем тот же пароль в поле "Confirm Password"; Выбираем доступные устройства и добавляем в поле Controlled Devices. Так же, нажимаем Add to User Group, чтобы добавить пользователю роли. Данный пользователь должен иметь возможность контролировать пользователей, ТА которых подлежат записи. Назначим следующие роли: Standard CTI Allow Park Monitoring. Standard CTI Allow Call Recording Standard CTI Allow Control of Phones supporting Connected Xfer and conf Standard CTI Allow Control of Phones supporting Rollover Mode Standard CTI Enabled. Нажать Add Selected: Нажать Save (сохранить).На этом, конфигурация пользователя завершена. Перейдем к настройке SIP транка. Настройка SIP транка на CUCM В деталях про настройку SIP транка на CUCM можно читать по ссылке. В появившемся окне нажать Add New. Выбираем Trunk Type = SIP trunk, Device Protocol = SIP Даем имя транку в поле Device Name, пишем описание в поле Description, выбираем Device Pool (набор общих параметров), SIP Trunk Security Profile выбираем Non Secure SIP Trunk Profile, SIP Profile выбираем Standard SIP Profile. Далее, необходимо настроить Route Pattern (маршрут в транк) Настройка Route pattern на CUCM Выбираем незанятый в диалплане номер. Например 1111. В поле Gateway/Route List выбираем сконфигурированный нами транк. Recording Profile Перейдите в Select Device → Device Setting → Recording Profile. Нажмите Add New: Дайте имя профилю; Задайте номер, как в настройке Route Pattern. 1111 в нашем примере; Осталось только настроить запись на линии телефона (включив BiB), назначить Recording Profile на телефон, включить опцию Allow Control of Device from CTI и в опции Recording Option выставьте Automatic Call Recording Enabled.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59