Русский
Русский
English
Статистика
Реклама

Облачная инфраструктура

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)!
Подробнее..

Перевод Плоскость управления EVPN в сетевой облачной инфраструктуре

17.11.2020 14:16:28 | Автор: admin

Привет, хабровчане. В преддверии курса "Архитектор сетей" подготовили для вас перевод интересной статьи.


Один из моих читателей прислал мне следующий вопрос (вероятно, задумавшись над замечанием, сделанным мной на вебинаре по сетевым возможностям AWS):

Вы упомянули, что AWS не использует EVPN в качестве своей оверлейной плоскости управления, вероятно, потому что эта технология не подходит для их масштабирования. Не могли бы вы раскрыть эту тему, пожалуйста? Я сейчас делаю PoC (проверку концепции) EVPN, и мне интересно узнать об этом больше.

Можно с уверенностью предположить, что AWS использует какую-то оверлейную виртуальную сеть (как и любой другой разумный крупномасштабный облачный провайдер). Подробностей мы не знаем; AWS никогда не испытывал необходимости использовать конференции в качестве способа набора персонала, и то немногое, что они рассказали нам на re:Invent, описывает систему в основном с точки зрения клиента.

Также можно с уверенностью предположить, что у них есть по несколько сотен тысяч серверов (оверлейных эндпоинтов виртуальных сетей) в одном регионе. Реализация BGP поверх этого была бы интересной инженерной задачей, а фильтрация посторонней информации, которая не нужна хостам гипервизора (ORF на основе RT), была бы сущем весельем. Однако я уверен, что они не используют EVPN не поэтому EVPN просто не тот инструмент, который нужен для этой работы.

Хотя кажется, что EVPN и все, что используют AWS или Azure, решают одну и ту же проблему (разметку пользовательских IP- и MAC-адресов в транспортные next-hop-ы), между средами, для которых был разработан EVPN, и инфраструктурой публичного облака IaaS существует масса фундаментальных различий.

В оставшейся части этой статьи я буду использовать аббревиатуру VTEP для обозначения транспортных next-hop-ов, даже несмотря на маловероятность того, что AWS использует VXLAN - у AWS была работающая система еще до того, как была изобретена VXLAN. VTEP означает Virtual Tunnel EndPoint.

Типичная среда L2VPN имеет динамические эндпоинты. MAC- и IP-адреса обнаруживаются локально с помощью любого инструмента обнаружения (MAC learning, DHCP/ARP snooping) и должны быть распространены на все другие периферийные устройства сети. В правильно реализованной масштабируемой облачной инфраструктуре система оркестровки контролирует присвоение MAC- и IP-адресов. Нет абсолютно никакой необходимости в динамическом обнаружении эндпоинтов или динамическом распространении информации об эндпоинтах. После запуска виртуальной машины через систему оркестровки маркировка MAC-to-VTEP распространяется на все другие хосты гипервизора, участвующие в той же виртуальной сети.

Эндпоинты могут перемещаться в среде L2VPN. Хотя перемещение эндпоинтов в WAN не является обычным делом, они достаточно много перемещаются в корпоративных центрах обработки данных vMotion во всех его вариациях (включая причудливые) самая популярная вещь для виртуализации. Хуже того, при использовании таких технологий, как VMware HA или DRS, конечные точки перемещаются без участия системы оркестровки. EVPN идеально подходит для такой среды.

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

EVPN пытается справиться со всякого рода дикими сценариями, такими как эмуляция MLAG или наличие нескольких подключений в мостовой сети. Таких чудовищ никогда не наблюдалось в крупномасштабных публичных облаках возможно, потому, что у людей, которые ими управляют, слишком много важной работы, чтобы растягивать повсюду VLAN. Она также была бы кстати, если вы достаточно велики, чтобы не заботиться о избыточных соединениях с серверами, потому что вы можете позволить себе потерять все 40+ серверов, подключенных к ToR коммутатору, не моргнув глазом.

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

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

  • API на гипервизоре, который вызывается системой оркестровки всякий раз, когда ему нужно настроить параметры гипервизора (запустить виртуальную машину, создать сеть/подсеть/группу безопасности, установить маркировку MAC-to-VTEP)

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

Исходя из моего опыта со скоростью AWS и с системами оркестровки Azure, я подозреваю, что AWS использует первый подход, а Azure второй.

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

Короче говоря: EVPN это интересная технология, но, вероятно, неправильный инструмент для реализации плоскости управления облачной инфраструктуры, которая должна предоставлять виртуальные сети для клиента. Тем не менее, она используется в качестве технологии шлюза между таким облаком и физическими устройствами. Juniper Contrail был первым (о котором я знаю), который использовал его таким образом, и даже VMware отказалась от попыток подтолкнуть всех остальных усыновить странного ребенка, которого они получили с приобретением Nicira (OVSDB), и переключилась на EVPN в NSX-Т 3.0.

Дополнительная информация

Хотите узнать, как работают сети в публичных облаках?

  • Когда вы будете готовы к большему, ныряйте в вебинары по сетям AWS и Microsoft Azure.

Заинтересованы в EVPN? Мы о вас уже позаботились в блогах есть множество постов связанных с EVPN, и мы исследовали EVPN с точки зрения центра обработки данных и поставщика услуг в вебинаре EVPN Technical Deep Dive.

Наконец, я описал NSX-Vи NSX-T на вебинаре VMware NSX Technical Deep Dive и сравнил ее с Cisco ACI на вебинаре VMware NSX, Cisco ACI or Standard-Based EVPN.


Узнать подробнее о курсе и записаться на бесплатный вебинар "Overlay. Что это такое и зачем необходимо" можно здесь.

Подробнее..

Категории

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

  • Имя: Макс
    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