Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

It security

StealthWatch анализ и расследование инцидентов. Часть 3

13.07.2020 10:06:40 | Автор: admin


Cisco StealthWatch это аналитическое решение в области ИБ, которое обеспечивает всесторонний мониторинг угроз в распределенной сети. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств. В результате сеть становится чувствительным сенсором и позволяет администратору заглянуть туда, куда не могут добраться традиционные методы защиты сети, например, Next Generation Firewall.
В прошлых статьях я уже писал о StealthWatch: первое представление и возможности, а также развертывание и настройка. Сейчас предлагаю двигаться дальше и обсудить, как следует работать с алармами и расследовать инциденты безопасности, которые генерирует решение. Будет приведено 6 примеров, которые, я надеюсь, дадут хорошее представление о полезности продукта.

Сперва следует сказать, что в StealthWatch присутствует некоторое распределение срабатываний на алгоритмы и фиды. Первые это разного рода алармы (уведомления), при срабатывании которых, можно обнаружить подозрительные вещи в сети. Вторые это инциденты безопасности. В данной статье будут рассмотрены 4 примера срабатываний алгоритмов и 2 примера фидов.

1. Анализ самых объемных взаимодействий внутри сети


Первоначальным шагом настройки StealthWatch является определение хостов и сетей по группам. В веб-интерфейсе вкладка Configure > Host Group Management следует разнести сети, хосты, сервера по соответствующим группам. Группы можно создавать и свои. К слову, анализ взаимодействий между хостами в Cisco StealthWatch довольно удобен, так как можно не только сохранять фильтры поиска по потокам, но и сами результаты.
Для начала в веб-интерфейсе стоит зайти во вкладку Analyze > Flow Search. Затем следует установить следующие параметры:
  • Search Type Top Conversations (самые популярные взаимодействия)
  • Time Range 24 hours (промежуток времени, можно использовать другой)
  • Search Name Top Conversations Inside-Inside (любое понятное имя)
  • Subject Host Groups > Inside Hosts (источник группа внутренних узлов)
  • Connection (можно указать порты, приложения)
  • Peer Host Groups > Inside Hosts (назначение группа внутренних узлов)
  • В Advanced Options дополнительно можно указать коллектор, с которого смотрятся данные, сортировку вывода (по байтам, потокам и прочее). Я оставлю по умолчанию.




После нажатия на кнопку Search выдается список взаимодействий, которые уже отсортированы по объему переданных данных.



В моем примере хост 10.150.1.201 (сервер) в рамках только одного потока передал 1.5 Гб трафика на хост 10.150.1.200 (клиент) по протоколу mysql. Кнопка Manage Columns позволяет добавить больше столбцов в выводимые данные.
Далее на усмотрение администратора можно создать кастомное правило, которое будет срабатывать постоянно на такого рода взаимодействия и уведомлять по SNMP, email или Syslog.

2. Анализ самых медленных клиент-серверных взаимодействий внутри сети на предмет задержек


Метки SRT (Server Response Time), RTT (Round Trip Time) позволяют выяснить задержки серверов и общие задержки в сети. Данный инструмент особенно удобен, когда следует быстро найти причину жалоб пользователей на медленно работающее приложение.
Примечание: практически все Netflow экспортеры не умеют отправлять метки SRT, RTT, поэтому зачастую, чтобы видеть такие данные на FlowSensor надо настроить отправку копию трафика с сетевых устройств. FlowSensor в свою очередь отдает расширенный IPFIX на FlowCollector.
Данную аналитику удобнее проводить в java приложении StealtWatch, которая устанавливается на компьютер администратора.
Правой клавишей мыши на Inside Hosts и переходим во вкладку Flow Table.



Нажимаем на Filter и устанавливаем необходимые параметры. В качестве примера:
  • Date/Time For the last 3 days
  • Performance Average Round Trip Time >=50ms





После выведения данных следует добавить интересующие нас RTT, SRT поля. Для этого следует нажать на колонку на скриншоте и правой клавишей мыши выбрать Manage Columns. Далее прокликать RTT, SRT параметры.



После обработки запроса, я отсортировал по RTT average и увидел самые медленные взаимодействия.



Чтобы провалится в детальную информацию, следует нажать правой клавишей мыши на поток и выбрать Quick View for Flow.



Данная информация говорит о том, что хост 10.201.3.59 из группы Sales and Marketing по протоколу NFS обращается к DNS серверу на протяжении минуты и 23 секунд и имеет просто ужасную задержку. Во вкладке Interfaces можно узнать, с какого Netflow экспортера данных информация получена. Во вкладке Table изображена более подробная информация о взаимодействии.



Далее следует узнать, какие устройства шлют трафик на FlowSensor и проблема скорее всего кроется там.
Более того, StealthWatch уникален тем, что проводит дедупликацию данных (объединяет одни и те же потоки). Следовательно, можно собирать практически со всех устройств Netflow и не бояться, что будет много повторяющихся данных. Как раз-таки наоборот, в данной схеме это поможет понять, на каком именно хопе наибольшие задержки.

3. Аудит криптографических протоколов HTTPS


ETA (Encrypted Traffic Analytics) технология, разработанная Cisco, позволяющая обнаруживать зловредные подключения в зашифрованном трафике без его расшифровки. Более того, данная технология позволяет разбирать HTTPS на версии TLS и криптографические протоколы, которые используются при соединениях. Данный функционал является особенно полезным, когда нужно обнаружить сетевые узлы, которые используют слабые криптостандарты.
Примечание: предварительно следует установить network app на StealthWatch ETA Cryptographic Audit.
Переходим во вкладку Dashboards > ETA Cryptographic Audit и выбираем группу хостов, которую планируется проанализировать. Для общей картины выберем Inside Hosts.



Можно наблюдать, что выводятся версия TLS и соответствующий криптостандарт. По привычной схеме в колонке Actions переходим во View Flows и запускается поиск в новой вкладке.




Из вывода видно, что хост 198.19.20.136 на протяжении 12 часов использовал HTTPS с TLS 1.2, где алгоритм шифрования AES-256 и хэш-функция SHA-384. Таким образом, ЕТА позволяет найти слабые алгоритмы в сети.

4. Анализ аномалий в сети


Cisco StealthWatch умеет распознавать аномалии трафика в сети, используя в три инструмента: Core Events (события безопасности), Relationship Events (события взаимодействий между сегментами, узлами сети) и поведенческий анализ.
Поведенческий анализ, в свою очередь, позволяет со временем строить модель поведения для того или иного хоста или группы хостов. Чем больше трафика проходит через StealthWatch, тем более точные будут срабатывания благодаря этому анализу. Поначалу система много неверно триггерит, поэтому правила следует подкручивать руками. Рекомендую первые несколько недель не обращать внимания на такие события, так как система сама подстроится, либо же добавлять в исключения.
Ниже приведен пример предустановленного правила Anomaly, в котором говорится, что событие сработает без аларма, если хост в группе Inside Hosts взаимодействует с группой Inside Hosts и за 24 часа трафик превысит 10 мегабайт.



Для примера возьмем аларм Data Hoarding, который означает, что какой-то хост источника/назначения загрузил/скачал аномально большое количество данных с группы хостов или хоста. Нажимаем на событие и проваливаемся в таблицу, где указываются триггерящие хосты. Далее выбираем интересующий нас хост в колонке Data Hoarding.




Выводится событие, говорящее о том, что обнаружено 162к очков, а по политике разрешено 100к очков это внутренние метрики StealthWatch. В колонке Actions нажимаем View Flows.



Мы можем наблюдать, что данный хост ночью взаимодействовал с хостом 10.201.3.47 из отдела Sales & Marketing по протоколу HTTPS и скачал 1.4 Гб. Может быть данный пример является не совсем удачным, но детектирование взаимодействий и на несколько сотен гигабайт осуществляется точно таким же образом. Следовательно, дальнейшее расследование аномалий может привести к интересным результатам.



Примечание: в веб-интерфейсе SMC данные во вкладках Dashboards выводятся только за последнюю неделю и во вкладке Monitor за последние 2 недели. Чтобы проанализировать события более старой давности и для генерации отчетов нужно работать с java консолью на компьютере администратора.

5. Нахождение внутренних сканирований сети


Теперь рассмотрим несколько примеров фидов инцидентов ИБ. Этот функционал интересен больше безопасникам.
Предустановленных типов событий сканирования в StealthWatch несколько:
  • Port Scan источник сканирует множество портов узла назначения.
  • Addr tcp scan источник сканирует целую сеть по одному и тому же TCP порту, меняя при этом IP адрес назначения. При этом источник получает TCP Reset пакеты или не получает ответов вовсе.
  • Addr udp scan источник сканирует целую сеть по одному и тому же UDP порту, меняя при этом IP адрес назначения. При этом источник получает ICMP Port Unreachable пакеты или не получает ответов вовсе.
  • Ping Scan источник посылает ICMP запросы на целую сеть с целью поиска ответов.
  • Stealth Scan tсp/udp источник использовал один и тот же свой порт для подключения к множеству портов на узле назначения в одно и то же время.

Для более удобного нахождения сразу всех внутренних сканеров существует network app для StealthWatch Visibility Assessment. Перейдя во вкладку Dashboards > Visibility Assessment > Internal Network Scanners вы увидите инциденты безопасности, относящиеся к сканированию, за последние 2 недели.



Нажав на кнопку Details, будет видно начала сканирования каждой сети, тренд трафика и соответствующие алармы.



Далее можно провалиться в хост из вкладки на предыдущем скриншоте и увидеть события безопасности, а также активность за последнюю неделю для этого хоста.




В качестве примера проанализируем событие Port Scan с хоста 10.201.3.149 на 10.201.0.72, нажав на Actions > Associated Flows. Запускается поиск по потокам и выводится релевантная информация.



Как мы видим данный хост с одного своего порта 51508/TCP сканировал 3 часа назад хост назначения по портам 22, 28, 42, 41, 36, 40 (TCP). Некоторые поля не отображают информацию либо потому, что не вся поля Netflow поддерживаются на Netflow экспортере.

6. Анализ скачанных зловредов с помощью CTA


CTA (Cognitive Threat Analytics) облачная аналитика Cisco, которая прекрасно интегрируется с Cisco StealthWatch и позволяет дополнить безсигнатурный анализ сигнатурным. Тем самым становится возможным детектирование троянов, сетевых червей, вредоносов нулевого дня и других зловредов и их распространение внутри сети. Также ранее упомянутая технология ЕТА позволяет анализировать такие вредоносные коммуникации и в зашифрованном трафике.



Буквально на первой же вкладке в веб-интерфейсе есть специальный виджет Cognitive Threat Analytics. Краткая сводка говорит об обнаруженных угрозах на пользовательских хостах: троян, мошенническое ПО, назойливое рекламное ПО. Слово Encrypted как раз-таки и свидетельствует о работе ЕТА. Нажав на хост, по нему выпадает вся информация, события безопасности в том числе логи по СТА.




Наводя на каждый этап СТА, события выводится подробная информация о взаимодействии. Для полной аналитики стоит нажать View Incident Details, и вы попадете в отдельную консоль Cognitive Threat Analytics.



В правом верхнем углу фильтр позволяет отобразить события по уровню критичности. Наводя на конкретную аномалию, в нижней части экрана появляются логи с соответствующим таймлайном справа. Тем самым, специалист отдела ИБ четко понимает, какой зараженный хост после каких действий начал выполнять какие действия.
Ниже изображен еще один пример банковский троян, которым был заражен хост 198.19.30.36. Данный хост начал взаимодействовать со зловредными доменами, а в логах изображена информация по потокам этих взаимодействий.




Далее одно из лучших решений, которое может быть, закинуть хост в карантин благодаря нативной интеграции с Cisco ISE для дальнейшего лечения и анализа.

Заключение


Решение Cisco StealthWatch является одним из лидеров среди продуктов мониторинга сети как с точки зрения анализа сети, так и информационной безопасности. Благодаря ему можно обнаруживать нелегитимные взаимодействия внутри сети, задержки приложений, самых активных пользователей, аномалии, зловредов и APT. Более того, можно находить сканирования, пентестеров, проводить криптоаудит HTTPS трафика. Еще больше use cases вы можете найти по ссылке.
Если у вас появилось желание проверить, насколько у вас в сети все гладко и эффективно работает, отправьте заявку.
В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Cisco , Stealthwatch , Tssolution , It security , Мониторинг сети

StealthWatch интеграция с Cisco ISE. Часть 4

21.07.2020 10:07:42 | Автор: admin


В более ранних статьях было рассмотрено несколько обширных тем касательно решения по мониторингу Cisco StealthWatch. Напомню, что StealthWatch решение по мониторингу трафика в сети на предмет инцидентов безопасности и легитимности сетевого взаимодействия. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств.
Приведу для справки ссылки на прошлые статьи: первое представление и возможности, развертывание и настройка, а также анализ и расследование инцидентов.
Прошу заметить, мониторинг, в частности Cisco StealthWatch, это прежде всего решение по детектированию угроз и атак. Все мониторинговые решения не подразумевают в себе предотвращение угроз, однако часто это требуется. У StealthWatch есть интеграция из коробки с Cisco ISE (Identity Services Engine). Интеграция состоит в том, что StealthWatch обнаруживает инцидент безопасности, а Cisco ISE вносит в хост карантин до момента, пока администратор руками его из карантина не вынесет.
В данной статье рассматривается настройка интеграции и пример срабатывания.

Cisco ISE это


Если кратко, то Cisco ISE это Network Access Control (NAC) решение для предоставления контроля доступа пользователям к внутренней сети с учетом контекстов. Cisco ISE позволяет:
  • Быстро и просто создавать гостевой доступ
  • Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу)
  • Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec)
  • Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing)
  • Классифицировать и профилировать оконечные и сетевые устройства
  • Предоставлять видимость оконечных устройств
  • Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики
  • Делать все, что умеет ААА сервер

Про Cisco ISE писали многие коллеги по отрасли, рекомендую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE и интеграция с Cisco FirePOWER.

Как работает карантин


Workflow действий добавить/удалить из карантина ANC политики (Adaptive Network Control) в Cisco ISE изображен ниже:



  1. Предварительно пользователь логиниться в корпоративную сеть через WLC (контроллер точек доступа). Затем отправляется REST API запрос на карантин с ноды управления (Policy Administration Node).
  2. Мониторинговая нода (Monitoring Node), которая отвечает за сбор логов, отправляет специальный PrRT запрос на PSN ноду (Policy Service Node, отвечает за применение политик ISE). Также отправляется CoA запрос с целью изменить атрибуты ААА и отключить пользователя.
  3. Клиентское устройство отключается.
  4. Клиент пытается заново аутентифицироваться и переподключиться.
  5. RADIUS запрос со стороны клиента отправляется назад на мониторинговую ноду (Monitoring Node).
  6. Устройство заноситься в карантин.
  7. В карантине оно и остается, так как профиль карантина был применен и до сих пор активен.
  8. Решив инцидент безопасности, администратор выводит хост из карантина.


Настройка


1. В веб-интерфейсе Cisco ISE перейдите во вкладку Operations > Policy List и создайте новую политику, нажав на Add.



2. Назовем ее StealthWatch_Quarantine и выберем действие Карантин (Quarantine) и нажимаем Submit.



3. Следующим шагом является настройка политики. Переходим в Policy > Policy Sets и нажимаем на самую правую стрелку под колонкой View.



4. Во вкладке Authorization Policy > Global Exceptions создается новое правило (следует нажать на +). Далее в колонке Conditions нажимаете + еще раз и выбираете атрибут Session ANCPolicy. Действие в данном правиле Equals StealthWatch_Quarantine.
В колонке Profile > DenyAccess и по желанию в колонке Security Groups можно указать вашу группу безопасности (например, гости или отдел маркетинга). В конце сохраняем изменения.



5. Во вкладке Operations > Live Logs (RADIUS или TACACS) можно посмотреть по пользователю или адресу логи. Предположим, найдем пользователя wesley.



6. Переходим в StealthWatch веб интерфейс и во вкладке Monitor > Users находим данного пользователя.



7. Переходим в его хост, нажав на IP адрес.



8. В пункте ISE ANC Policy выбираем Edit > StealthWatch_Quarantine > Save. Хост помещается в карантин до дальнейшего разбирательства.



Дополнительно в ANC политике можно использовать действия port_shutdown (выключение порта сетевого устройства) и port_bounce (shutdown/no shutdown устройства). Например, если зловред успел распространиться по целому VLAN, то на коммутаторе уровня доступа логичнее и быстрее будет выключить порт, а не вносить каждый хост в карантин.

Заключение


Как Cisco StealthWatch является достойным решением по мониторингу сети на предмет обнаружения инцидентов безопасности, так и Cisco ISE является отличным решением для контроля пользовательского доступа. Интеграция этих двух решений действительно работает и позволяет минимизировать время реакции на инциденты ИБ.
В скором времени Cisco обещает добавить автоматическую реакцию на выбранные инциденты и применять к ним ANC политики, либо же вы сами можете написать скрипт. Как StealthWatch, так и ISE обладает открытым REST API. Однако данную автоматическую интеграцию следует настраивать только после длительного времени, когда StealthWatch сформировал корректные модели поведения хостов и количество ложных срабатываний минимально.
Более подробная информация о Cisco StealthWatch доступна на сайте. В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Контроль доступа , Cisco , Stealthwatch , Tssolution , It security , Мониторинг сети , Ise

Stealthwatch Cloud. Быстрое, удобное и эффективное решение для облачных и корпоративных инфраструктур

29.07.2020 10:12:50 | Автор: admin


Не так давно я писал про мониторинг Netflow/IPFIX и про Cisco StealthWatch аналитическое решение, которое позволяет детектировать такие события, как сканирования, распространение сетевых червей, шпионское ПО, нелегитимные взаимодействия и различного рода аномалии. О расследовании инцидентов с помощью StealthWatch написано в статье.
Мониторинг облачной инфраструктуры давно уже не является новой задачей, так у каждого крупного игрока, есть свои инструменты Amazon CloudWatch или Amazon S3, Google Stackdriver, Azure Monitor. Эти инструменты отлично подходят для мониторинга приложений, производительности и инфраструктуры в целом, но они не закрывают задачи по безопасности (да и сами провайдеры облаков не сильно ей обеспокоены): распространение зловредного ПО, ботнет-коммуникации, обнаружение аномалий, попытки сканирования, нелегитимный доступ (включая варианты с использованием легитимных учетных данных) и многое другое.

StealthWatch Cloud


StealthWatch Cloud (SWC) SaaS-решение, которое напоминает Stealthwatch Enterprise (не зря Cisco последнее время стирает границы между этими двумя решениями в своей архитектуре), но учитывает специфику облачных сред. Если для Stealthwatch Enterprise важным источником информации является телеметрия на базе Netflow, то Stealthwatch Cloud использует в качестве таких данных журналы облачных сред (не ограничиваясь логами, получая и другие виды телеметрии). Дальше выполняются привычные для StealthWatch действия: моделирование объектов, построение их поведенческих моделей, обнаружение отклонений, проверка соответствия политикам, обнаружение событий безопасности (как встроенных, так и заданных пользователем) и многое другое. Угрозы, аномальная и зловредная активность обнаруживаются быстрее, как следствие, ущерб от инцидента снижается или даже полностью нивелируется.
При этом у тревог Stealthwatch Cloud есть привычная для XXI века функция: заказчик может оценить полезность сгенерированной тревоги одним кликом мышки. На текущий момент 96% тревог, сгенерированных для существующих заказчиков StealthWatch Cloud, признаны полезными.
Область применения StealthWatch Cloud не ограничена облаками: решение может использоваться для мониторинга публичных облаков, частных облаков, классической корпоративной инфраструктуры, а также, безусловно, гибридной архитектуры с использованием любого сочетания этих трёх компонентов. Учтены в Stealthwatch Cloud и варианты обслуживания нескольких клиентов при оказании услуг по обеспечении безопасности.
Варианты развертывания можно представить примерно следующим образом.


Рисунок 1. Варианты использования StealthWatch Cloud

StealthWatch Cloud можно использовать при работе с публичными облаками (Amazon, Azure, Google), приватными и гибридными облаками, которые построены на инфраструктуре из Kubernetes и, разумеется, корпоративными сетями.
К слову, Mail.ru являются сертифицированным партнером Kubernetes (K8s). В StealthWatch Cloud отправляются журналы событий подов K8s и потоки трафика между этими подами. В результате приобретаются полная видимость подов K8s, сущностей приватного облака и обнаружение инцидентов безопасности, о которых сказано ранее. На рисунке 2 изображена схема взаимодействия.


Рисунок 2. Схема интеграции StealthWatch Cloud c Kubernetes

В случае работы с частными корпоративными сетями требуется установка виртуальной машины (Virtual Sensor аналог Flow Sensor в StealthWatch Enterprise). На рисунке 3 изображено, что на сенсор отправляется Netflow, IPFIX, SPAN, а по шифрованному туннелю сенсор отправляет информацию в StealthWatch Cloud, где и производится вся аналитика. Тем самым, вычислительные мощности заказчика не задействуются от слова совсем, а внедрение и пилот проходят максимально оперативно.


Рисунок 3. Схема интеграции StealthWatch Cloud с корпоративной сетью

Также хочется отметить, что установка Virtual Sensor влечет за собой массу положительных моментов:

  • Поддерживается интеграция c Cisco ISE, AD;
  • Работает технология ETA (Encrypted Traffic Analytics), позволяющая обнаруживать зловредные подключения в зашифрованном трафике без его расшифровки. Более того, данная технология позволяет разбирать HTTPS на версии TLS и криптографические протоколы, которые используются при соединениях;
  • Доступен сигнатурный анализ вместе с безсигнатурным, который основывается на телеметрии.

Существует вариант и без установки виртуального сенсора (Virtual Sensor), но тогда StealthWatch Cloud сможет работать только с телеметрией, то есть сигнатурный анализ доступен не будет.
Еще немного плюсов StealthWatch Cloud:

  • Гибкая модель лицензирования по мега-потокам (Effective Mega Flows EMF, где 1 EMF = 1 млн. логов, которые предварительно дедуплицируются, т.е. остаются в едином экземпляре, и считаются в конце месяца);
  • Поддержка многопользовательских сред (это плюс для партнеров, предоставляющих SOC на аутсорс, из одной консоли можно мониторить всех заказчиков).

Выводы:
При работе с публичными, приватными и гибридными облаками StealthWatch Cloud позволяет обнаруживать следующие инциденты безопасности:

  • Аномальное поведение пользователей, хостов
  • Ботнет активность
  • Брутфорс
  • Попытки удаленного доступа, в том числе из необычных геолокаций
  • Распространение зловредного ПО и обращения к зловредным URL
  • Нарушение ролей взаимодействия
  • Новые устройства, потоки
  • Попытки сканирования
  • Флуд трафика, штормы
  • Система обнаружения вторжений (IDS)
  • Специфичные события для AWS, Azure, GCP

При работе с частными корпоративными сетями добавляется практически весь функционал StealthWatch Enterprise.

Интеграция с Amazon Web Services (AWS)


StealthWatch Cloud использует AWS Lambda API (сервис по автоматическому исполнению программного кода и управлению вычислительными ресурсами в AWS) и Identity and Access Management (IAM) API. Это позволяет получать информацию о политиках доступа к инстансам, изменениях исполнения программного кода, проводить аудит инстансов и другое.
Дополнительно SWC использует данные о потоках (взаимодействиях сетевого уровня) с мониторинговых сервисов Amazon CloudWatch или Amazon S3. VPC (Virtual Private Cloud) Flow logs так называются данные о потоках в терминологии AWS.
Следовательно, со стороны администратора в личном кабинете Amazon Web Services следует дать права на чтение потоков (VPC Flow logs) и журналов событий с сервисов Amazon CloudTrail, Amazon IAM, Amazon GuardDuty, AWS Lambda, Amazon Inspector и AWS Config, если вы их используете.
На рисунке 4 изображены схема работы StealthWatch Cloud и AWS.


Рисунок 4. Схема работы StealthWatch Cloud и AWS

В свою очередь, SWC проводит аналитику и выводит ее на дэшборды, позволяя оперативно ознакомиться с текущим трафиком, загрузкой инфраструктуры и даже предсказать будущую загрузку рисунок 5.


Рисунок 5. Консоль мониторинга Amazon Web Services в StealthWatch Cloud

Интеграция с Microsoft Azure


В случае работы с Azure StealthWatch Cloud обращается к API Azure для считывания журналов событий, которые содержат информацию о трафике север-юг и запад-восток внутри облачной инфраструктуры. Называются такие журналы NSG Flow logs. По своей сути похожи на потоки Netflow, так как содержат в себе заголовки пакетов.
Большим отличием от кейса с AWS является то, что Azure может отправлять копию трафика с виртуальных машин через VTAP виртуальные ответвители трафика. VTAP является технологией разработанной Microsoft, но доступна для интеграции со всеми третьими решениями. Использование VTAP эффективно, потому что:

  1. Копия трафика с нужных сегментов позволит SWC получить полную видимость и, как следствие, максимальное детектирование угроз.
  2. Нагрузка на виртуальные машины не увеличивается, так как VTAP это трафик с виртуального коммутатора, а не самой машины.
  3. Взаимодействие с SWC осуществляется по шифрованному TLS туннелю.

На рисунке 6 изображена схема взаимодействия.


Рисунок 6. Схема работы StealthWatch Cloud и Microsoft Azure

Интеграция с Google Cloud Platform


При интеграции с Google Cloud Platform (GCP) возможно только обращение к API со стороны SWC для считывания ранее упомянутых VPC Flow журналов событий (таких же, как и у Amazon) c Google Stackdriver. Google Stackdriver это сервис, который собирает логи и метрики из GCP, мониторит приложения, виртуальные машины и Google Cloud инфраструктуру в целом. Однако работа только с VPC Flow журналами событий дает немного меньшую видимость. Схема работы изображена на рисунке 7.


Рисунок 7. Схема работы StealthWatch Cloud и Google Cloud Platform

SWC vs. SWE


Хотя Stealthwatch Cloud и Stealthwatch Enterprise решают сходные задачи, области их применения и различия в основных источниках телеметрии обуславливают разные возможности. Сравнительные данные сведены в таблице ниже.
Опция сравнения SWC SWE
Скорость развертывания Максимально быстрая Средняя
Минимально требуемые мощности Не требуется; 4 GB RAM, 2 CPU, 60 GB HDD (для использования Virtual Sensor) 36 GB RAM, 6 CPU, 385 GB HDD
Интеграция с ISE Да, если установить Virtual Sensor Да
ETA/Cognitive Threat Analytics Да Да
Поддержка публичных облаков Да Нет
Поддержка приватных облаков и Kubernetes Да Нет
Используемая телеметрия Журналы событий облаков (VPC Flow, NSG Flow) через API, Netflow/IPFIX при работе с корпоративной сетью NetFlow, sFlow, jFlow, cFlow, Netstream, nvzFlow, IPFIX, Packeteer-2 и другие кастомные доработки
Поведенческий анализ Для хостов и сетевых устройств, сущностей AWS, Azure, GCP, для подов Kubernetes Для хостов, сетевых устройств
Дедупликация данных Да Да
Лицензирование По мега-потокам в месяц (EMF) По потокам в секунду (fps)
Можно заключить, что StealthWatch Enterprise является отличным вариантом, когда есть своя виртуальная инфраструктура, доступно много вычислительных ресурсов и нужен максимальный функционал по мониторингу корпоративной сети на предмет инцидентов безопасности, легитимных взаимодействий и видимости сети. К слову, можно приобрести и физическое исполнение StealthWatch.
В свою очередь, StealthWatch Cloud привлекателен быстротой развертывания (особенно для пилота), также для него не требуется развертывать и поддерживать виртуальные машины, кроме Virtual Sensor. SWC позволяет мониторить инфраструктуру в публичных, приватных облаках и поддерживает исходную интеграцию с единой платформой управления ИБ решениями Cisco SecureX.

Как протестировать?


Есть два варианта бесплатного пилотного проекта: самому или с партнером. В случае первого варианта, предлагаются обратиться к сайту. Лицензия выдается на 60 дней, гайды по настройке предоставляются на этом же сайте Cisco. В случае, если вы желаете больше погрузиться в детали и максимально качественно решить свои задачи по мониторингу, то обращайтесь к нам по ссылке.

Заключение


StealthWatch Cloud является многогранным решением, которое позволяет в максимально сжатые сроки получить полную видимость в приватном, публичном или гибридном облаке, будь-то Amazon Web Services, Microsoft Azure или Google Cloud Platform. Одновременно с этим данное решение может использоваться и для мониторинга корпоративных сетей, обладая при этом практически одинаковым функционалом в сравнении с on-premise StealthWatch Enterprise. Экономия времени, технических и человеческих ресурсов при работе c SWC вот явные преимущества.
В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Облачные технологии , Cisco , Stealthwatch , Tssolution , It security , Мониторинг сети , Облачная инфраструктура

Эшелонированная защита. Fortinet amp Flowmon Networks

18.08.2020 10:04:18 | Автор: admin


В последнее время все больше компаний дозревают до эшелонированной защиты, когда одно решение защищает периметр сети, другое оконечные станции, третье постоянно мониторит сеть, обнаруживая аномалии, четвертое сканирует сеть на предмет незакрытых уязвимостей и так далее. Одновременно с этим возрастает потребность в различных интеграциях и хорошо, когда они из коробки, то есть писать сложные скрипты не нужно.
Мы не так давно писали о новой услуге TS Solution CheckFlow. Это бесплатный аудит сетевого трафика (как внутреннего, так и внешнего). Flowmon решение по анализу телеметрии и мониторингу сети, которое дает ценную информацию как для сетевых администраторов, так и для безопасников: аномалии, сканирования, нелегитимные сервера, петли, нелегитимные взаимодействия, вторжения в сеть, атаки нулевого дня и многое другое.
Также рекомендую обратиться к статье 9 типовых проблем в сети, которые можно обнаружить с помощью анализа с Flowmon.

Интеграция Flowmon & FortiGate


Интеграция была упомянута в нашем блоге. В общем и целом она заключается в том, что Next-Generation Firewall (такой, как FortiGate) защищает периметр, а Flowmon мониторит сетевую инфраструктуру, тем самым заказчик получает полную видимость сети. Однако Flowmon позволяет лишь обнаруживать, но не предотвращать атаки и аномалии, ведь он работает на телеметрии, которая добывается с помощью Netflow/IPFIX. Для вноса в карантин подозрительного или зараженного хоста может использоваться NGFW или же NAC (Network Access Control) решение.
Так вот, вендор Flowmon выпустил shell скрипт, который в ответ на инциденты безопасности может выполнить следующие действия на FortiGate:

  • Заблокировать зараженный хост по IP адресу (IP Ban);
  • Внести в хост карантин с помощью FortiClient по MAC адресу (Quarantine with FortiClient);
  • Динамический карантин на все зараженные хосты по МАС адресам (Access Layer Quarantine);

Настройка


1. В подробности самого скрипта я вдаваться не буду, скажу лишь, что есть две версии: одна для FortiGate выше версии 6.4.0, другая для более ранних версий. Код приведен ниже.

Код скрипта для FortiGate ниже версии 6.4.0 
#!/bin/bash# Author: Jiri Knapek# Description: This script is to quarantine IP on Fortigate Firewalls for FortiOS before 6.4.# Version: 1.3# Date: 8/3/2020# Debug 1 = yes, 0 = noDEBUG=0[ $DEBUG -ne 0 ] && echo `date` "Starting mitigation script" >> /tmp/fg-mitigation.log# Management IP/hostname of Firewall/ Core deviceIP='10.10.30.210'API_KEY='fp8114zdNpjp8Qf8zN4Hdp57dhgjjf'# Default timeout for action is# value in seconds or neverTIMEOUT='300'# FortiGate API URLBAN="http://personeltest.ru/aways/$IP/api/v2/monitor/user/banned/add_users?access_token=$API_KEY"function usage {    cat << EOF >&2usage: mitigation_script.sh <options>Optional:    --fw        IP / hostname of Fortigate firewall--timeoutTimeout in seconds--keyFortiGate API key    EOF    exit}      params="$(getopt -o f:t:k:h -l fw:,timeout:,key:,help --name "mitigation_script.sh" -- "$@")"[ $DEBUG -ne 0 ] && echo `date` "Params $params" >> /tmp/fg-mitigation.logif [ $? -ne 0 ]then    usage    [ $DEBUG -ne 0 ] && echo `date` "Got to usage." >> /tmp/fg-mitigation.logfieval set -- "$params"unset paramswhile truedo    case $1 in        -f|--fw)            IP=("${2-}")            shift 2            ;;        -k|--key)            API_KEY=("${2-}")            shift 2            ;;        -t|--timeout)            TIMEOUT=("${2-}")            shift 2            ;;        -h|--help)            usage            ;;        --)            shift            break            ;;        *)            usage            ;;    esacdone# we dont support any other args[ $# -gt 0 ] && {    usage    [ $DEBUG -ne 0 ] &&  echo `date`  "INFO: Too many arguments. Got to usage." >> /tmp/fg-mitigation.log 2>&1}cat << EOF >&2-----  My params are ------------------FW = $IPAPI KEY = $API_KEYTIMEOUT = $TIMEOUTTOKEN = $TOKEN---------------------------------------EOF[ $DEBUG -ne 0 ] && cat >> /tmp/fg-mitigation.log << EOF >&2-----  My params are ------------------FW = $IPAPI KEY = $API_KEYTIMEOUT = $TIMEOUTTOKEN = $TOKEN---------------------------------------EOFecho "Stdin read started..." >&2LINE_NUM=1array=()while read linedo    IFS=$'\t'    array=($line)    echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}"    [ $DEBUG -ne 0 ] &&  echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}" >> /tmp/fg-mitigation.log 2>&1        LINE_NUM=$((LINE_NUM+1))    # BAN the source IP of the event    if [ $DEBUG -ne 0 ]; then        /usr/bin/curl -k -X POST -H "Content-Type": "application/json" --data "{ \"ip_addresses\": [\"${array[10]}\"], \"expiry\": $TIMEOUT}" $BAN >> /tmp/fg-mitigation.log 2>&1    else        /usr/bin/curl -k -X POST -H "Content-Type": "application/json" --data "{ \"ip_addresses\": [\"${array[10]}\"], \"expiry\": $TIMEOUT}" $BAN    fidone < /dev/stdinecho "---- Everything completed ----"[ $DEBUG -ne 0 ] &&  echo `date` "---- Everything completed ----" >> /tmp/fg-mitigation.log

Код скрипта для FortiGate версии 6.4.0 и выше 
#!/bin/bash# Author: Jiri Knapek# Description: This script is to quarantine IP or MAC on Fortigate Firewalls and Security Fabric# Version: 2.0# Date: 7/8/2020# Debug 1 = yes, 0 = noDEBUG=0[ $DEBUG -ne 0 ] && echo `date` "Starting mitigation script" >> /tmp/fg-mitigation.log# Flowmon API accessUSER='admin'PASS='admin'# Management IP/hostname of Firewall/ Core deviceIP='10.10.30.210'WEBHOOK='FlowmonADS'API_KEY='fp8114zdNpjp8Qf8zN4Hdp57dhgjjf'MAC=0URL="http://personeltest.ru/aways/$IP/api/v2/monitor/system/automation-stitch/webhook/$WEBHOOK"function usage {    cat << EOF >&2usage: mitigation_script.sh <options>Optional:    --fw        IP / hostname of Fortigate firewall    --user      Username to be used for Flowmon API authentication    --pass      Password for the user--keyFortiGate API key--mac    Add this parameter to enable MAC mitigationEOF    exit}params="$(getopt -o f:u:p:k:h:m: -l fw:,key:,pass:,user:,help,mac: --name "mitigation_script.sh" -- "$@")"[ $DEBUG -ne 0 ] && echo `date` "Params $params" >> /tmp/fg-mitigation.logif [ $? -ne 0 ]then    usage    [ $DEBUG -ne 0 ] && echo `date` "Got to usage." >> /tmp/fg-mitigation.logfieval set -- "$params"unset paramswhile truedo    case $1 in        -f|--fw)            IP=("${2-}")            shift 2            ;;        -k|--key)            API_KEY=("${2-}")            shift 2            ;;        -p|--pass)            PASS=("${2-}")            shift 2            ;;        -u|--user)            USER=("${2-}")            shift 2            ;;        -m|--mac)            MAC=1            shift 2            ;;        -h|--help)            usage            ;;        --)            shift            break            ;;        *)            usage            ;;    esacdone# we dont support any other args[ $# -gt 0 ] && {    usage    [ $DEBUG -ne 0 ] &&  echo `date`  "INFO: Got to usage." >> /tmp/fg-mitigation.log 2>&1}if [ $MAC -ne 0 ];then    # authenticate to localhost    OUTPUT="$(/usr/bin/curl "https://localhost/resources/oauth/token" -k -d 'grant_type=password' -d 'client_id=invea-tech' -d "username=$USER" -d "password=$PASS")"    TOKEN=""    echo "${OUTPUT}" > /tmp/access_token.json    if [[ $OUTPUT == *"access_token"* ]]; then        [ $DEBUG -ne 0 ] && echo `date` "Successfully authenticated to Flowmon Collector!" >> /tmp/fg-mitigation.log        TOKEN="$(cat /tmp/access_token.json | jq '.access_token')"        TOKEN="${TOKEN//\"}"        TOKEN="Authorization: bearer "$TOKEN    fificat << EOF >&2-----  My params are ------------------FW = $IPAPI KEE = $API_KEYURL = $URLMAC = $MACTOKEN = $TOKEN---------------------------------------EOF[ $DEBUG -ne 0 ] && /tmp/fg-mitigation.log << EOF >&2-----  My params are ------------------FW = $IPAPI KEE = $API_KEYURL = $URLMAC = $MACTOKEN = $TOKEN---------------------------------------EOFecho "Stdin read started..." >&2LINE_NUM=1array=()while read linedo    IFS=$'\t'    array=($line)    echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}"    [ $DEBUG -ne 0 ] &&  echo "$LINE_NUM - ID ${array[0]} - type ${array[4]} - source ${array[10]}" >> /tmp/fg-mitigation.log 2>&1    # Call a webhook    if [ $MAC -ne 0 ];    then        MAC_ADDR="$(/usr/bin/curl "https://localhost/rest/ads/event/${array[0]}" -G -k -H "$TOKEN"  | jq '.macAddress')"        if [ $DEBUG -ne 0 ]; then            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\", \"mac\": $MAC_ADDR, \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL >> /tmp/fg-mitigation.log 2>&1        else            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\", \"mac\": $MAC_ADDR, \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL        fi    else        if [ $DEBUG -ne 0 ]; then            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\",  \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL >> /tmp/fg-mitigation.log 2>&1        else            /usr/bin/curl -k -X POST -H "Authorization: Bearer $API_KEY" --data "{ \"srcip\": \"${array[10]}\",  \"fctuid\": \"A8BA0B12DA694E47BA4ADF24F8358E2F\"}" $URL        fi    fi    LINE_NUM=$((LINE_NUM+1))done < /dev/stdinecho "---- Everything completed ----"[ $DEBUG -ne 0 ] &&  echo `date` "---- Everything completed ----" >> /tmp/fg-mitigation.log


2. Я использую ForiGate версии 6.4.3. В самом скрипте в 13 и 14 строке следует добавить ваши логин и пароль к Flowmon, а также добавить API ключ из п.5, IP-адрес FortiGate и имя Webhook (имя механизма автоматизации).



3. В веб-интерфейсе FortiGate следует добавить во вкладке Security Fabric > Automation > New Automation Stitch. Имя FlowmonADS, Status Enabled, Trigger Incoming Webhook, Action IP BAN, Access Layer Quarantine, Quarantine with FortiCLient (если используете).



4. Затем вы увидите окно как на скриншоте ниже с URLом FortiGate для данного Webhooka, поле для API токена админа (мы его создадим позже) и пример запроса.



5. Далее следует создать профиль администратора, который будет иметь права. Вкладка System > Admin Profiles > Create New.



6. Назначить права Security Fabric Read, Firewall Read/Write, System Read/Write, Security Profile Read/Write.



7. После во вкладке System > Administrators создаем нового администратора с профилем api_admin. Дополнительно в поле Trusted Hosts можно указать доверенные сети или IP-адрес устройства Flowmon.
Примечание: параметр Trusted Hosts позволяет жестко задать сегменты IP адресов, из которых api_admin сможет отправлять API запросы на FortiGate, тем самым это рекомендуемая настройка.



8. После этого шага генерируется API ключ, который надо добавить в первоначальный скрипт вместе с другими данными, указанными в пункте 1 и в webhook в пункте 4.



9. Далее переходим во Flowmon в модуль ADS (Anomaly Detection System) во вкладку System > System Settings > Custom Scripts > New Custom Script > Выбрать файл с расширение .sh. Далее следует задать параметры --fw (IP-адрес FortiGate), --key (API токен), --mac (ничего), --pass (пароль от REST API Flowmon), --user (пользователь REST API Flowmon). После следует нажать кнопку Save.
Примечание: --pass и --user по умолчанию admin / admin.



10. Финальным шагом является установление событий, на которые данные программный код и будет срабатывать. Во вкладке Settings > Processing > Custom Scripts > New Custom Script Action следует поменять параметр Perspective на Security Issues, установить порог срабатывания (Minimal priority to be reported) и проверить параметры из прошлого шага.



Проверка


В случае срабатывания события из категории Security Issues на Flowmon, FortiGate заблокирует данный хост. Далее в удобном виджете Quarantine можно посмотреть потенциально зараженные хосты, провалившись внутрь. Либо же через команду в CLI diagnose user quarantine list.



После ИБ администратор может приступить к расследованию инцидента с помощью Flowmon ADS, установив первоначально зараженный хост, по каким портам распространяется зловред и его поведение. С помощью же решений по защите рабочих станций, например, FortiEDR можно вылечить машину и провести расследование инцидента безопасности.
Для того, чтобы вынести хост из карантина, его следует выбрать и нажать кнопку Remove.

Заключение


Повсеместный подход к эшелонированной защите подталкивает многих вендоров на интеграцию с другими решениями из коробки. В данной статье были рассмотрены интеграция, настройка и демонстрация совместной работы Flowmon и FortiGate.
В ближайшее время у нас планируется вебинар, на котором более подробно расскажем, как Flowmon и Fortinet дополняют друг друга, их интеграцию между собой, а также ответим на интересующие вас вопросы. Регистрация доступна по ссылке.
Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!
Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Системное администрирование , Сетевое оборудование , Monitoring , Netflow , Блог компании ts solution , It security , Fortinet , Fortigate , Ts solutin , Span , Flowmon

Cisco ISE Введение, требования, установка. Часть 1

18.09.2020 10:20:14 | Автор: admin

1. Введение

У каждой компании, даже самой малой есть потребность в проведении аутентификации, авторизации и учета пользователей (семейство протоколов ААА). На начальном этапе ААА вполне себе хорошо реализуется с использованием таких протоколов, как RADIUS, TACACS+ и DIAMETER. Однако с ростом количества пользователей и компании, растет и количество задач: максимальная видимость хостов и BYOD устройств, многофакторная аутентификация, создание многоуровневой политики доступа и многое другое.

Для таких задач отлично подходит класс решений NAC (Network Access Control) - контроль сетевого доступа. В цикле статей, посвященному Cisco ISE (Identity Services Engine) - NAC решению для предоставления контроля доступа пользователям к внутренней сети с учетом контекста, мы подробно рассмотрим архитектуру, инициализацию, настройку и лицензирование решения.

Кратко напомню, что Cisco ISE позволяет:

  • Быстро и просто создавать гостевой доступ в выделенной WLAN;

  • Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу);

  • Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec);

  • Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing);

  • Классифицировать и профилировать оконечные и сетевые устройства;

  • Предоставлять видимость оконечных устройств;

  • Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики;

  • Нативно интегрироваться с Cisco StealthWatch и вносить в карантин подозрительные хосты, участвующие в инцидентах безопасности (подробнее);

  • И другие стандартные для ААА сервера фичи.

Про Cisco ISE уже писали коллеги по отрасли, поэтому в дальнейшем советую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE.

2. Архитектура

В архитектуре Identity Services Engine есть 4 сущности (ноды): нода управления (Policy Administration Node), нода распределения политик (Policy Service Node), мониторинговая нода (Monitoring Node) и PxGrid нода (PxGrid Node). Сisco ISE может быть в автономной (standalone) или распределенной (distributed) инсталляции. В Standalone варианте все сущности находятся на одной виртуальной машине или физическом сервере (Secure Network Servers - SNS), когда в Distributed - ноды распределены по разным устройствам.

Policy Administration Node (PAN) - обязательная нода, которая позволяет выполнять все административные операции на Cisco ISE. Она обрабатывает все системные конфигурации, связанные с ААА. В распределенной конфигурации (ноды можно устанавливать как отдельные виртуальные машины) у вас может быть максимум две PAN для отказоустойчивости - Active/Standby режим.

Policy Service Node (PSN) - обязательная нода, которая обеспечивает доступ к сети, состояние, гостевой доступ, предоставление услуг клиентам и профилирование. PSN оценивает политику и применяет ее. Как правило, PSN устанавливается несколько, особенно в распределенной конфигурации, для более избыточной и распределенной работы. Конечно же, эти ноды стараются устанавливать в разных сегментах, чтобы не терять возможности обеспечения аутентифицированного и авторизованного доступа ни на секунду.

Monitoring Node (MnT) - обязательная нода, которая хранит журналы событий, логи других нод и политик в сети. MnT нода предоставляет расширенные инструменты для мониторинга и устранения неполадок, собирает и сопоставляет различные данные, в также предоставляет содержательные отчеты. Cisco ISE позволяет иметь максимум две MnT ноды, тем самым формируя отказоустойчивость - Active/Standby режим. Тем не менее, логи собирают обе ноды, как активная, так и пассивная.

PxGrid Node (PXG) - нода, применяющая протокол PxGrid и обеспечивающая общение между другими устройствами, которые поддерживают PxGrid.

PxGrid - протокол, который обеспечивает интеграцию продуктов ИТ- и ИБ-инфраструктуры разных вендоров: систем мониторинга, систем обнаружения и предотвращения вторжений, платформ управления политиками безопасности и множества других решений. Cisco PxGrid позволяет обмениваться контекстом в однонаправленном или двунаправленном режиме со многими платформами без необходимости использования API, тем самым позволяя использовать технологию TrustSec (SGT метки), изменять и применять ANC (Adaptive Network Control) политику, а также осуществлять профилирование - определение модели устройства, ОС, местоположение и другое.

В конфигурации высокой доступности ноды PxGrid реплицируют информацию между нодами через PAN. В случае, если PAN отключается, нода PxGrid перестает аутентифицировать, авторизовывать и проводить учет пользователей.

Ниже схематично изображена работа разных сущностей Cisco ISE в корпоративной сети.

Рисунок 1. Архитектура Cisco ISEРисунок 1. Архитектура Cisco ISE

3. Требования

Cisco ISE может быть внедрен, как и большинство современных решений виртуально или физически как отдельный сервер.

Физические устройства с установленным ПО Cisco ISE называются SNS (Secure Network Server). Они бывают трех моделей: SNS-3615, SNS-3655 и SNS-3695 для малого, среднего и большого бизнеса. В таблице 1 приведена информация из даташита SNS.

Таблица 1. Сравнительная таблица SNS для разных масштабов

Параметр

SNS 3615 (Small)

SNS 3655 (Medium)

SNS 3695 (Large)

Количество поддерживаемых оконечных устройств в Standalone инсталляции

10000

25000

50000

Количество поддерживаемых оконечных устройств для каждой PSN

10000

25000

100000

CPU (Intel Xeon 2.10 ГГц)

8 ядер

12 ядер

12 ядер

RAM

32 Гб (2 x 16 Гб)

96 Гб (6 x 16 Гб)

256 Гб (16 x 16 Гб)

HDD

1 х 600 Гб

4 х 600 Гб

8 х 600 Гб

Hardware RAID

Нет

RAID 10, наличие RAID контроллера

RAID 10, наличие RAID контроллера

Сетевые интерфейсы

2 х 10Gbase-T

4 х 1Gbase-T

2 х 10Gbase-T

4 х 1Gbase-T

2 х 10Gbase-T

4 х 1Gbase-T

Касательно виртуальных внедрений, поддерживаются гипервизоры VMware ESXi (рекомендуется минимум VMware версия 11 для ESXi 6.0), Microsoft Hyper-V и Linux KVM (RHEL 7.0). Ресурсы должны быть примерно такие же, как и в таблице выше, либо больше. Тем не менее, минимальные требования виртуальной машины для малого бизнеса: 2 CPU с частотой 2.0 ГГц и выше, 16 Гб RAM и 200 Гб HDD.

Для уточнения остальных деталей развертывания Cisco ISE обратитесь к нам или к ресурсу 1, ресурсу 2.

4. Установка

Как и большинство других продуктов Cisco, ISE можно протестировать несколькими способами:

  • dcloud облачный сервис предустановленных лабораторных макетов (необходима учетная запись Cisco);

  • GVE request запрос с сайта Cisco определенного софта (способ для партнеров). Вы создаете кейс со следующим типичным описанием: Product type [ISE], ISE Software [ise-2.7.0.356.SPA.x8664], ISE Patch [ise-patchbundle-2.7.0.356-Patch2-20071516.SPA.x8664];

  • пилотный проект - обратитесь к любому авторизованному партнеру для проведения бесплатного пилотного проекта.

1) Создав виртуальную машину, если вы запросили ISO файл, а не OVA шаблон, у вас вылезет окно, в которой ISE требует выбрать установку. Для этого вместо логина и пароля следует написать "setup"!

Примечание: если вы развернули ISE из OVA шаблона, то данные для входа admin / MyIseYPass2 (это и многое другое указано в официальном гайде).

Рисунок 2. Установка Cisco ISEРисунок 2. Установка Cisco ISE

2) Затем следует заполнить необходимые поля, такие как IP-адрес, DNS, NTP и другие.

Рисунок 3. Инициализация Cisco ISEРисунок 3. Инициализация Cisco ISE

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

Рисунок 4. Веб-интерфейс Cisco ISEРисунок 4. Веб-интерфейс Cisco ISE

4) Во вкладке Administration > System > Deployment можно выбрать, какие ноды (сущности) включены на том или ином устройстве. Нода PxGrid включается здесь же.

Рисунок 5. Управление сущностями Cisco ISEРисунок 5. Управление сущностями Cisco ISE

5) Затем во вкладке Administration > System > Admin Access > Authentication рекомендую настроить политику паролей, метод аутентификации (сертификат или пароль), срок истечения учетной записи и другие настройки.

Рисунок 6. Настройка типа аутентификацииРисунок 6. Настройка типа аутентификацииРисунок 7. Настройки политики паролейРисунок 7. Настройки политики паролейРисунок 8. Настройка выключения аккаунта по истечение времениРисунок 8. Настройка выключения аккаунта по истечение времениРисунок 9. Настройка блокировки учетных записейРисунок 9. Настройка блокировки учетных записей

6) Во вкладке Administration > System > Admin Access > Administrators > Admin Users > Add можно создать нового администратора.

Рисунок 10. Создание локального администратора Cisco ISEРисунок 10. Создание локального администратора Cisco ISE

7) Нового администратора можно сделать частью новой группы или уже предустановленных групп. Управления группами администраторов осуществляется в этой же панели во вкладке Admin Groups. В таблице 2 сведена информация об администраторах ISE, их правах и ролях.

Таблица 2. Группы администраторов Cisco ISE, уровни доступа, разрешения и ограничения

Название группы администраторов

Разрешения

Ограничения

Customization Admin

Настройка гостевого, спонсорского порталов, администрирование и кастомизация

Невозможность изменять политики, просматривать отчеты

Helpdesk Admin

Возможность просматривать главный дашборд, все отчеты, лармы и траблшутить потоки

Нельзя изменять, создавать и удалять отчеты, алармы и логи аутентификации

Identity Admin

Управление пользователями, привилегиями и ролями, возможность смотреть логи, отчеты и алармы

Нельзя изменять политики, выполнять задачи на уровне ОС

MnT Admin

Полный мониторинг, отчеты, алармы, логи и управление ими

Невозможность изменять никакие политики

Network Device Admin

Права на создание, изменение объектов ISE, просмотр логов, отчетов, главного дашборда

Нельзя изменять политики, выполнять задачи на уровне ОС

Policy Admin

Полное управление всеми политиками, изменение профилей, настроек, просмотр отчетности

Невозможность выполнять настройки с учетными данными, объектами ISE

RBAC Admin

Все настройки во вкладке Operations, настройка ANC политики, управление отчетностью

Нельзя изменять другие кроме ANC политики, выполнять задачи на уровне ОС

Super Admin

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

Не может изменить, удалить другого профиля из группы Super Admin

System Admin

Вс настройки во вкладке Operations, управление системными настройками, политикой ANC, просмотр отчетности

Нельзя изменять другие кроме ANC политики, выполнять задачи на уровне ОС

External RESTful Services (ERS) Admin

Полный доступ к REST API Cisco ISE

Только для авторизации, управления локальными пользователями, хостами и группами безопасности (SG)

External RESTful Services (ERS) Operator

Права на чтение REST API Cisco ISE

Только для авторизации, управления локальными пользователями, хостами и группами безопасности (SG)
Рисунок 11. Предустановленные группы администраторов Cisco ISEРисунок 11. Предустановленные группы администраторов Cisco ISE

8) Дополнительно во вкладке Authorization > Permissions > RBAC Policy можно редактировать права предустановленных администраторов.

Рисунок 12. Управление правами предустановленных профилей администраторов Cisco ISEРисунок 12. Управление правами предустановленных профилей администраторов Cisco ISE

9) Во вкладке Administration > System > Settings доступны все системные настройки (DNS, NTP, SMTP и другие). Вы можете их заполнить здесь, в случае если пропустили при первоначальной инициализации устройства.

5. Заключение

На этом первая статья подошла к концу. Мы обсудили эффективность NAC решения Cisco ISE, его архитектуру, минимальные требования и варианты развертывания, а также первичную установку.

В следующей статье мы рассмотрим создание учетных записей, интеграцию с Microsoft Active Directory, а также создание гостевого доступа.

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

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog,Яндекс.Дзен).

Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Ts solution , Контроль доступа , Cisco , It security , Ise , Cisco ise , Nac , Network access control

Cisco ISE Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

25.09.2020 10:10:53 | Автор: admin

Приветствую во второй публикации цикла статей, посвященному Cisco ISE. В первой статье были освещены преимущества и отличия Network Access Control (NAC) решений от стандартных ААА, уникальность Cisco ISE, архитектура и процесс установки продукта.

В данной статье мы углубимся в создание учетных записей, добавлению LDAP серверов и интеграцию с Microsoft Active Directory, а также в нюансы при работе с PassiveID. Перед прочтением настоятельно рекомендую ознакомиться с первой частью.

1. Немного терминологии

User Identity - учетная запись пользователя, которая содержит информацию о пользователе и формирует его учетные данные для доступа к сети. Следующие параметры, как правило, указываются в User Identity: имя пользователя, адрес электронной почты, пароль, описание учетной записи, группу пользователей и роль.

User Groups - группы пользователей - это совокупность отдельных пользователей, которые имеют общий набор привилегий, которые позволяют им получать доступ к определенному набору сервисов и функций Cisco ISE.

User Identity Groups - предустановленные группы пользователей, которые уже имеют определенную информацию и роли. Следующие User Identity Groups существуют по умолчанию, в них можно добавлять пользователей и группы пользователей: Employee (сотрудник), SponsorAllAccount, SponsorGroupAccounts, SponsorOwnAccounts (спонсорские учетки для управления гостевым порталом), Guest (гость), ActivatedGuest (активированный гость).

User Role - роль пользователя - это набор разрешений, определяющих, какие задачи может выполнять пользователь и к каким сервисам может получить доступ. Зачастую роль пользователя связана с группой пользователей.

Более того, у каждого пользователя и группы пользователей есть дополнительные атрибуты, которые позволяют выделить и более конкретно определить данного пользователя (группу пользователей). Больше информации в гайде.

2. Создание локальных пользователей

1) В Cisco ISE есть возможность создать локальных пользователей и использовать их в политике доступа или даже дать роль администрирования продуктом. Выберите Administration > Identity Management > Identities > Users > Add.

Рисунок 1. Добавление локального пользователя в Cisco ISEРисунок 1. Добавление локального пользователя в Cisco ISE

2) В появившемся окне создайте локального пользователя, задайте ему пароль и другие понятные параметры.

Рисунок 2. Создание локального пользователя в Cisco ISEРисунок 2. Создание локального пользователя в Cisco ISE

3) Пользователей также можно импортировать. В этой же вкладке Administration > Identity Management > Identities > Users выберите опцию Import и загрузите csv или txt файлик с пользователями. Для того, чтобы получить шаблон выберите Generate a Template, далее следует его заполнить информацией о пользователях в подходящем виде.

Рисунок 3. Импорт пользователей в Cisco ISEРисунок 3. Импорт пользователей в Cisco ISE

3. Добавление LDAP серверов

Напомню, что LDAP - популярный протокол прикладного уровня, позволяющий получать информацию, производить аутентификацию, искать учетные записи в каталогах LDAP серверов, работает по порту 389 или 636 (SS). Яркими примерами LDAP серверов являются Active Directory, Sun Directory, Novell eDirectory и OpenLDAP. Каждая запись в каталоге LDAP определяется DN (Distinguished Name) и для формирования политики доступа встает задача подтягивания (retrieval) учетных записей, пользовательских групп и атрибутов.

В Cisco ISE возможно настроить доступ ко многим LDAP серверам, тем самым реализуя избыточность. В случае, если первичный (primary) LDAP сервер недоступен, то ISE попробует обратиться к вторичному (secondary) и так далее. Дополнительно, если имеется 2 PAN, то то для первичной PAN можно сделать приоритетным один LDAP, а для вторичной PAN - другой LDAP.

ISE поддерживает 2 типа лукапа (lookup) при работе с LDAP серверами: User Lookup и MAC Address Lookup. User Lookup позволяет делать поиск пользователю в базе данных LDAP и получать следующую информацию без аутентификации: пользователи и их атрибуты, группы пользователей. MAC Address Lookup позволяет так же без аутентификации производить поиск по MAC адресу в каталогах LDAP и получать информацию об устройстве, группу устройств по MAC адресам и другие специфичные атрибуты.

В качестве примера интеграции добавим Active Directory в Cisco ISE в качестве LDAP сервера.

1) Зайдите во вкладку Administration > Identity Management > External Identity Sources > LDAP > Add.

Рисунок 4. Добавление LDAP сервераРисунок 4. Добавление LDAP сервера

2) В панели General укажите имя LDAP сервера и схему (в нашем случае Active Directory).

Рисунок 5. Добавление LDAP сервера со схемой Active DirectoryРисунок 5. Добавление LDAP сервера со схемой Active Directory

3) Далее перейдите в Connection вкладку и укажите Hostname/IP address AD сервера, порт (389 - LDAP, 636 - SSL LDAP), учетные данные доменного администратора (Admin DN - полный DN), остальные параметры можно оставить по умолчанию.

Примечание: используйте данные домен админа во избежание потенциальных проблем.

Рисунок 6. Ввод данных LDAP сервераРисунок 6. Ввод данных LDAP сервера

4) Во вкладке Directory Organization следует указать область каталогов через DN, откуда вытягивать пользователей и группы пользователей.

Рисунок 7. Определение каталогов, откуда подтянуться группы пользователейРисунок 7. Определение каталогов, откуда подтянуться группы пользователей

5) Перейдите в окно Groups > Add > Select Groups From Directory для выбора подтягивания групп из LDAP сервера.

Рисунок 8. Добавление групп из LDAP сервераРисунок 8. Добавление групп из LDAP сервера

6) В появившемся окне нажмите Retrieve Groups. Если группы подтянулись, значит предварительные шаги выполнены успешно. В противном случае, попробуйте другого администратора и проверьте доступность ISE c LDAP сервером по LDAP протоколу.

Рисунок 9. Перечень подтянутых групп пользователейРисунок 9. Перечень подтянутых групп пользователей

7) Во вкладке Attributes можно опционально указать, какие атрибуты из LDAP сервера следует подтянуть, а в окне Advanced Settings включить опцию Enable Password Change, которая заставит пользователей изменить пароль, если он истек или был сброшен. В любом случае нажмите Submit для продолжения.

8) LDAP сервер появился в соответствующий вкладке и в дальнейшем может использоваться для формирования политик доступа.

Рисунок 10. Перечень добавленных LDAP серверовРисунок 10. Перечень добавленных LDAP серверов

4. Интеграция с Active Directory

1) Добавив Microsoft Active Directory сервер в качестве LDAP сервера, мы получили пользователи, группы пользователей, но не логи. Далее предлагаю настроить полноценную интеграцию AD с Cisco ISE. Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > Add.

Примечание: для успешной интеграции с AD ISE должен находиться в домене и иметь полную связность с DNS, NTP и AD серверами, в противном случае ничего не выйдет.

Рисунок 11. Добавление сервера Active DirectoryРисунок 11. Добавление сервера Active Directory

2) В появившемся окне введите данные администратора домена и поставьте галочку Store Credentials. Дополнительно вы можете указать OU (Organizational Unit), если ISE находится в каком-то конкретном OU. Далее придется выбрать ноды Cisco ISE, которые вы хотите соединить с доменом.

Рисунок 12. Ввод учетных данныхРисунок 12. Ввод учетных данных

3) Перед добавлением контроллеров домена убедитесь, что на PSN во вкладке Administration > System > Deployment включена опция Passive Identity Service. PassiveID - опция, которая позволяет транслировать User в IP и наоборот. PassiveID получает информацию из AD через WMI, специальных AD агентов или SPAN порт на коммутаторе (не лучший вариант).

Примечание: для проверки статуса Passive ID введите в консоли ISE show application status ise | include PassiveID.

Рисунок 13. Включение опции PassiveID Рисунок 13. Включение опции PassiveID

4) Перейдите во вкладку Administration > Identity Management > External Identity Sources > Active Directory > PassiveID и выберите опцию Add DCs. Далее выберите галочками необходимые контроллеры домена и нажмите OK.

Рисунок 14. Добавление контроллеров доменаРисунок 14. Добавление контроллеров домена

5) Выберите добавленные DC и нажмите кнопку Edit. Укажите FQDN вашего DC, доменные логин и пароль, а также опцию связи WMI или Agent. Выберите WMI и нажмите OK.

Рисунок 15. Ввод данных контроллера доменаРисунок 15. Ввод данных контроллера домена

6) Если WMI не является предпочтительным способом связи с Active Directory, то можно использовать ISE агентов. Агентский способ заключается в том, что вы можете установить на сервера специальные агенты, которые будут отдавать login события. Существует 2 варианта установки: автоматический и ручной. Для автоматической установки агента в той же вкладке PassiveID выберите пункт Add Agent > Deploy New Agent (DC должен иметь доступ в Интернет). Затем заполните обязательные поля (имя агента, FQDN сервера, логин/пароль доменного администратора) и нажмите OK.

Рисунок 16. Автоматическая установка ISE агентаРисунок 16. Автоматическая установка ISE агента

7) Для ручной установки Cisco ISE агента требуется выбрать пункт Register Existing Agent. К слову, скачать агента можно во вкладке Work Centers > PassiveID > Providers > Agents > Download Agent.

Рисунок 17. Скачивание ISE агентаРисунок 17. Скачивание ISE агента

Важно: PassiveID не читает события logoff! Параметр отвечающий за тайм-аут называется user session aging time и равняется 24 часам по умолчанию. Поэтому следует либо делать logoff самому по окончании рабочего дня, либо же писать какой-то скрипт, который будет делать автоматический logoff всем залогиненым пользователям.

Для получения информации logoff используются "Endpoint probes" - оконечные зонды. Endpoint probes в Cisco ISE существует несколько: RADIUS, SNMP Trap, SNMP Query, DHCP, DNS, HTTP, Netflow, NMAP Scan. RADIUS probe с помощью CoA (Change of Authorization) пакетов отдает информацию о смене прав пользователя (для этого требуется внедренный 802.1X), а настроенный на коммутаторах доступа SNMP, даст информацию о подключенных и отключенных устройствах.

Ниже приведен пример, актуальный для конфигурации Cisco ISE + AD без 802.1X и RADIUS: пользователь залогинен на Windows машине, не делая logoff, логиниться с другого ПК по WiFi. В этом случае сессия на первом ПК по-прежнему будет активна, пока не случится тайм-аут или не произойдет принудительный logoff. Тогда если у устройств разные права, то последнее залогиненное устройство будет применять свои права.

8) Дополнительно во вкладке Administration > Identity Management > External Identity Sources > Active Directory > Groups > Add > Select Groups From Directory вы можете выбрать группы из AD, которые хотите подтянуть на ISE (в нашем случае это было сделано в пункте 3 Добавление LDAP сервера). Выберите опцию Retrieve Groups > OK.

Рисунок 18 а). Подтягивание групп пользователей из Active DirectoryРисунок 18 а). Подтягивание групп пользователей из Active Directory

9) Во вкладке Work Centers > PassiveID > Overview > Dashboard вы можете наблюдать количество активных сессий, количество источников данных, агентов и другое.

Рисунок 19. Мониторинг активности доменных пользователейРисунок 19. Мониторинг активности доменных пользователей

10) Во вкладке Live Sessions отображаются текущие сессии. Интеграция с AD настроена.

Рисунок 20. Активные сессии доменных пользователейРисунок 20. Активные сессии доменных пользователей

5. Заключение

В данной статьей были рассмотрены темы создания локальных пользователей в Cisco ISE, добавление LDAP серверов и интеграция с Microsoft Active Directory. В следующей статье будет освещен гостевой доступ в виде избыточного гайда.

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

Следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Ts solution , Контроль доступа , Cisco , It security , Ise , Cisco ise , Nac , Network access control

Cisco ISE Настройка гостевого доступа на FortiAP. Часть 3

19.10.2020 10:13:52 | Автор: admin

Приветствую в третьей публикации цикла статей, посвященному Cisco ISE. Ссылки на все статьи в цикле приведены ниже:

  1. Cisco ISE: Введение, требования, установка. Часть 1

  2. Cisco ISE: Создание пользователей, добавление LDAP серверов, интеграция с AD. Часть 2

  3. Cisco ISE: Настройка гостевого доступа на FortiAP. Часть 3

В данной публикации вас ждет погружение в гостевой доступ, а также пошаговое руководство интеграции Cisco ISE и FortiGate для настройки FortiAP - точки доступа от Fortinet (в целом подходит любое устройство, поддерживающее RADIUS CoA - Сhange of Authorization).

Дополнительно прилагаю наши статьи Fortinet подборка полезных материалов.

Примечание: Check Point SMB устройства не поддерживают RADIUS CoA.

Замечательное руководство на английском языке описывает, как создать гостевой доступ с помощью Cisco ISE на Cisco WLC (Wireless Controller). Давайте разбираться!

1. Введение

Гостевой доступ (портал) позволяет предоставить доступ в Интернет или к внутренним ресурсам для гостей и пользователей, которых вы не хотите впускать в свою локальную сеть. Существует 3 предустановленных типа гостевого портала (Guest portal):

  1. Hotspot Guest portal - доступ в сеть гостям предоставляется без данных для входа. Как правило, пользователям требуется принять Политику использования и конфиденциальности компании, прежде чем получить доступ в сеть.

  2. Sponsored-Guest portal - доступ в сеть и данные для входы обязан выдать спонсор - пользователь, ответственный за создание гостевых учеток на Cisco ISE.

  3. Self-Registered Guest portal - в этом случае гости используют существующие данные для входа, либо сами себе создают аккаунт с данными для входа, однако требуется подтверждение спонсора для получения доступа в сеть.

На Cisco ISE можно развернуть множество порталов одновременно. По умолчанию на гостевом портале пользователь увидит логотип Cisco и стандартные общие фразы. Это все можно кастомизировать и даже установить просмотр обязательной рекламы перед получением доступа.

Настройку гостевого доступа можно разбить на 4 основных этапа: настройка FortiAP, установление связности Cisco ISE и FortiAP, создание гостевого портала и настройка политики доступа.

2. Настройка FortiAP на FortiGate

FortiGate является контроллером точек доступа и все настройки проводятся на нем. Точки доступа FortiAP поддерживают PoE, поэтому как только вы подключили ее в сеть по Ethernet, можно начинать настройку.

1) На FortiGate зайдите во вкладку WiFi & Switch Controller > Managed FortiAPs > Create New > Managed AP. Используя уникальный серийный номер точки доступа, который указан на самой точке доступа, добавьте ее как объект. Либо же она может обнаружиться сама и тогда нажмите Authorize с помощью правой клавиши мыши.

2) Настройки FortiAP могут быть по умолчанию, для примера оставьте как на скриншоте. Крайне рекомендую включать 5 ГГц режим, ибо некоторые устройства не поддерживают 2.4 ГГц.

3) Затем во вкладке WiFi & Switch Controller > FortiAP Profiles > Create New мы создаем профиль настроек для точки доступа (версия 802.11 протокола, режим SSID, частота канала и их количество).

Пример настроек FortiAP

4) Следующий шаг - создание SSID. Перейдите во вкладку WiFi & Switch Controller > SSIDs > Create New > SSID. Здесь из важного следует настроить:

  • адресное пространство для гостевого WLAN - IP/Netmask

  • RADIUS Accounting и Secure Fabric Connection в поле Administrative Access

  • Опция Device Detection

  • SSID и опция Broadcast SSID

  • Security Mode Settings > Captive Portal

  • Authentication Portal - External и вставить ссылку на созданный гостевой портал из Cisco ISE из п. 20

  • User Group - Guest Group - External - добавить RADIUS на Cisco ISE (п. 6 и далее)

Пример настройки SSID

5) Затем следует создать правила в политике доступа на FortiGate. Перейдите во вкладку Policy & Objects > Firewall Policy и создайте правило следующего вида:

3. Настройка RADIUS

6) Перейдите в веб интерфейс Cisco ISE во вкладку Policy > Policy Elements > Dictionaries > System > Radius > RADIUS Vendors > Add. В данной вкладке мы добавим в список поддерживаемых протоколов RADIUS от Fortinet, так как почти каждый вендор имеет собственные специфические атрибуты - VSA (Vendor-Specific Attributes).

Список атрибутов RADIUS Fortinet можно найти здесь. VSA отличаются по уникальному числу Vendor ID. У Fortinet этот ID = 12356. Полный список VSA был опубликован организацией IANA.

7) Задаем имя словарю, указываем Vendor ID (12356) и нажимаем Submit.

8) После переходим в Administration > Network Device Profiles > Add и создаем новый профиль устройства. В поле RADIUS Dictionaries следует выбрать ранее созданный Fortinet RADIUS словарь и выбрать методы CoA для того, чтобы использовать их потом в политике ISE. Я выбрал RFC 5176 и Port Bounce (shutdown/no shutdown сетевого интерфейса) и соответствующие VSA:

Fortinet-Access-Profile = read-write

Fortinet-Group-Name = fmg_faz_admins

9) Далее следует добавить FortiGate для связности c ISE. Для этого зайдите во вкладку Administration > Network Resources > Network Device Profiles > Add. Изменить следует поля Name, Vendor, RADIUS Dictionaries (IP Address используется FortiGate, а не FortiAP).

Пример настройки RADIUS со стороны ISE

10) После следует настроить RADIUS на стороне FortiGate. В веб интерфейсе FortiGate зайдите в User & Authentication > RADIUS Servers > Create New. Укажите имя, IP адрес и Shared secret (пароль) из прошлого пункта. Далее нажмите Test User Credentials и введите любые учетные данные, которые могут подтянуться через RADIUS (например, локальный пользователь на Cisco ISE).

11) Добавьте в группу Guest-Group (если ее нет создайте) RADIUS сервер, как и внешних источник пользователей.

12) Не забудьте добавить группу Guest-Group в SSID, который мы создали ранее в п. 4.

4. Настройка пользователей аутентификации

13) Опционально вы можете импортировать на гостевой портал ISE сертификат или создать самоподписанный сертификат во вкладке Work Centers > Guest Access > Administration > Certification > System Certificates.

14) После во вкладке Work Centers > Guest Access > Identity Groups > User Identity Groups > Add создайте новую группу пользователей для гостевого доступа, либо же используйте созданные по умолчанию.

15) Далее во вкладке Administration > Identities создайте гостевых пользователей и добавьте их в групп из прошлого пункта. Если же вы хотите использовать сторонние учетные записи, то пропустите данный шаг.

16) После переходим в настройки Work Centers > Guest Access > Identities > Identity Source Sequence > Guest Portal Sequence - это предустановленная последовательность аутентификации гостевых пользователей. И в поле Authentication Search List выберите порядок аутентификации пользователей.

17) Для уведомления гостей одноразовым паролем можно сконфигурировать SMS провайдеров или SMTP сервер для этой цели. Перейдите во вкладку Work Centers > Guest Access > Administration > SMTP Server или SMS Gateway Providers для данных настроек. В случае с SMTP сервером требуется создать учетку для ISE и указать данные в этой вкладке.

18) Для уведомлений по SMS используйте соответствующую вкладку. В ISE есть предустановленные профили популярных SMS провайдеров, однако лучше создать свой. Данные профили используйте как пример настройки SMS Email Gateway или SMS HTTP API.

Пример настройки SMTP сервера и SMS шлюза для одноразового пароля

5. Настройка гостевого портала

19)Как было упомянуто в начале, есть 3 типа предустановленных гостевых портала: Hotspot, Sponsored, Self-Registered. Предлагаю выбрать третий вариант, так как он наиболее часто встречающийся. В любом случае настройки во многом идентичны. Поэтому переходим во вкладку Work Centers > Guest Access > Portals & Components > Guest Portals > Self-Registered Guest Portal (default).

20) Далее во вкладке Portal Page Customization выберите View in Russian - Русский, чтобы портал стал отображаться на русском языке. Вы можете изменять текст любой вкладки, добавить свой логотип и многое другое. Справа в углу превью гостевого портала для более удобного представления.

Пример настройки гостевого портала с саморегистрацией

21) Нажмите на фразу Portal test URL и скопируйте URL портала в SSID на FortiGate в шаге 4. Примерный вид URL https://10.10.30.38:8433/portal/PortalSetup.action?portal=deaaa863-1df0-4198-baf1-8d5b690d4361

Чтобы отображался ваш домен, следует подгрузить сертификат на гостевой портал, смотрите шаг 13.

22) Перейдите во вкладку Work Centers > Guest Access > Policy Elements > Results > Authorization Profiles > Add для создания профиля авторизации под ранее созданный Network Device Profile.

23) Во вкладке Work Centers > Guest Access > Policy Sets отредактируйте политику доступа для WiFi пользователей.

24) Попробуем подключиться к гостевому SSID. Меня сразу перенаправляет на страницу входа. Здесь можно зайти под учеткой guest, созданной локально на ISE, либо зарегистрироваться в качестве гостевого пользователя.

25) Если вы выбрали вариант саморегистрации, то одноразовые данные для входа можно отправить на почту, через СМС или же распечатать.

26) Во вкладке RADIUS > Live Logs на Cisco ISE вы увидите соответствующие логи входа.

6. Заключение

В данной долгой статьей мы успешно настроили гостевой доступ на Cisco ISE, где в качестве контроллера точек доступа выступает FortiGate, а в качестве точки доступа FortiAP. Получилась этакая нетривиальная интеграция, что в очередной раз доказывает широкое применение ISE.

Для тестирования Cisco ISE обращайтесь по ссылке, а также следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog, Яндекс.Дзен).

Подробнее..
Категории: Информационная безопасность , Системное администрирование , Сетевые технологии , Блог компании ts solution , Ts solution , Контроль доступа , Cisco , It security , Ise , Cisco ise , Nac , Network access control

Проектирование ПО с учетом требований стандартов безопасности

27.01.2021 20:23:33 | Автор: admin

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

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS. Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют системы и решения собственной разработки, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только, большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS, не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано, а в данной статье приведены именно упомянутые стандарты, а не требования PA DSS.

Но помните, что каждый случай индивидуален, требует оценки и анализа.

Итак, давайте перейдем к детализации и описанию требований.

Общие разделы стандарта PCI DSS.

Требования PCI DSS (на основе требований PCI DSS 3.2.1)

1. Минимизировать места и сроки хранения критичных данных. В контексте данной публикации критичные данные это данные, безопасность которых регламентируется требованиями PCI DSS + GDPR (карточные и персональные данные).

Нужныли таковые данные впринципе или ихможно анонимизировать? Действительноли необходимо хранить критичные данные втаком объеме? Можноли избежать дублирования данных икак обеспечить ихминимизацию?

Кроме того, врамках проектирования архитектуры решения иеереализации требуется учесть вкаких базах данных (таблицах), местах файловой системы, архивах ипр. будут сохранены критичные данные. Каким образом эти данные могут быть удалены. Атакже перешифрованы при смене ключей шифрования. Учесть увеличение нагрузки наБД вслучае выполнение поиска позашифрованным данным. Как добиться максимальной производительности системы, при обработке минимально необходимого количества критичных данных.

2. Критичные данные в базах данных, рекомендовано хранить в зашифрованном виде.

Критичные данные должны хранится в зашифрованном виде. Достаточно шифрования средствами базы данных (или файловой системы). Но значительно более безопасно использовать дополнительное шифрование в рамках передачи данных и последующего помещения в БД данных в зашифрованном виде. В этом случае требуется определить стойкий алгоритм шифрования, предусмотреть возможность перешифрования данных при смене ключа, а также безопасный метод хранения или формирования ключа.

3. Клиентские сетевые потоки данных должны передаваться в зашифрованном виде.

Критичные данные должны передаваться по шифрованному каналу. Сетевые критичные данные должны передаваться по шифрованному каналу. Формально достаточно использование протокола безопасности TLS, но лучше обеспечить шифрование передаваемой информации на уровне ПО.

Соединение приложения с базами данных рекомендовано сделать шифрованным.

4. Если собираются фото платежных карт, они должны соответствовать требованиям безопасности.

Сбор пользовательских данных для процессов верификации, часто подразумевает сбор графических материалов с изображением платежных карт, на которых могут быть указаны карточные данные (PAN, CVV). Простое решение - это удалять такие данные из систем и просить клиента самостоятельно повторно предоставлять фото копии требуемогоформата. Следующий вариант - самостоятельно удалять критичные данные и сохранять фото без таковых. Еще более интересный вариант - это самописные или купленные сервисы распознавания и замыливания Cvv и номера карт на графических изображениях.

5. Базы данных должны размещаться в отдельной подсети от подсети приложений.

Для уменьшения рисков утечки критичных данных, БД должны размещаться отдельно от подсети, в которой размещены приложения.Учитывая повсеместную виртуализацию, рекомендуется также рассмотреть возможность дополнительного разделения БД и приложений.

6. Все тестовые параметры при переводе в эксплуатацию должны быть удалены.

Зачастую в рамках интеграции используются боевые аутентификационные данные. Что несет риски их компрометации. Рекомендуется использование тестовых данных, при переводе в среду эксплуатации, таковые данные должны быть изменены или удалены.

7. Требуется использовать защищенные технологии и стойкие алгоритмы шифрования.

Не все алгоритмы шифрования считаются стойкими.

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

8. Запрещено хранить пользовательские пароли, только хеш (результат выполнения однонаправленного преобразования над паролем).

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

9. Проверка на OWASP TOP 10.

Необходимо проверять решение на основные уязвимости безопасности перед передачей его в эксплуатацию. Сам данный пункт достоин не то что одной, а целой серии статей от процесса проверок внутри Компании до внедрения систем Bug Bounty. Для начала рекомендуется проверять хотя бы на OWASP TOP 10.

10. Использование персонифицированных учетных записей.

Будьте аккуратны и внимательны с использованием групповых учетных записей в ПО как на этапе тестирования так и при переводе системы в промышленную эксплуатацию. Это сильно затрудняет процессы расследования, мешает разделению полномочий и не ведет ни к чему хорошему.

11. Логирование действий с возможностью перенаправления во внешние системы.

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

12. Система разграничения полномочий с минимально необходимыми правами.

В системе должна функционировать система разграничения полномочий. Такая система может базироваться на ролевой или смешанной модели доступа (матричная тоже не запрещена, но слишком сложна при поддержке и значительном количестве пользователей). Разделение ролей должно быть построено на основе матрицы разделения полномочий.

13. Шифрование безопасными ключами.

Ключи должны быть заменены не реже, чем один раз в год. Передача ключа должна осуществляться безопасными каналами. Хранение ключа должно быть обеспечено таким образом, чтобы минимизировать возможность его компрометации (безопасные решения хранения ключей, разделенное хранение ключей, процессы генерации ключей на основе имеющихся данных).

14. Требования к стойкости пароля.

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

15. Пункт, который вероятно вы захотите дополнить самостоятельно

Подробнее..
Категории: Информационная безопасность , It-стандарты , Разработка приложений , Security , Разработка под e-commerce , It security , Gdpr , Pci dss , Требования

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru