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

Мониторинг сети

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

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

Зачем внедрять EDR, если есть SIEM, Sysmon и антивирус?

23.07.2020 10:06:27 | Автор: admin
Без мониторинга конечных точек сегодня уже не получится в полной мере обеспечить безопасность и вовремя обнаруживать факты компрометации инфраструктуры. Джентельменский набор сетевой мониторинг, антивирус и стандартный аудит на конечных точках уже не позволяет противодействовать не только серьезным группировкам, но даже злоумышленникам с низким уровнем подготовки. Почему? Рассмотрим на конкретных примерах.


Кадр из мультфильма Жил-был пес

Итак, стандартных средств мониторинга становится недостаточно. Этому способствуют несколько факторов:

индикаторы компрометации (хеши, IP-адреса и доменные имена) часто бывают одноразовыми, так как их изменение не представляет труда для злоумышленника, особенно в случае с APT;

атакующие применяют в работе легитимные исполняемые файлы, штатные средства ОС и т. д.;

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

на практике часто встречается ВПО, которое не детектируется ни антивирусом, ни сетевыми сигнатурами;

с ростом инфраструктуры становится проблематично вовремя обновлять сигнатуры и лицензии.

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

Мониторинг конечных точек существенно расширяет возможности по выявлению и предотвращению атак: он позволяет перейти от детектирования хешей, IP и доменов к детектированию хостовых артефактов, инструментов и TTP (да-да, той самой пирамиды боли).

Несколько примеров техник, которые часто встречаются на практике и не детектируются без хостового мониторинга:

DLL Hijacking
Living off the land
Использование Mimikatz

Дополнительный мониторинг конечных точек можно организовать с помощью встроенных в ОС средств (расширенный аудит), бесплатных утилит (например, Sysmon) и коммерческих решений (продукты класса EDR). Рассмотрим, какие достоинства и недостатки имеют эти подходы на примерах детектирования различных вариаций упомянутых выше техник.

Расширенный аудит. Windows Event Logging


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

При грамотной настройке мы закрываем некоторые пробелы стандартного подхода и видим:

факты запуска процессов вместе с командной строкой;

запускаемые PowerShell-скрипты в декодированном виде (Script block logging);

частично работу с файлами и реестром;

активность, связанную с учетными записями (создание/удаление пользователей и так далее).

У нас появляется возможность детектировать новые техники:

некоторые варианты DLL hijacking по созданию файлов с определенными путями;

использование LOLBin и Mimikatz по паттернам в командной строке.

При этом у злоумышленника все еще есть возможность избежать обнаружения. В случае с LOLBin это может быть копирование файла в другую папку под другим именем и обфусцирование командной строки. А Mimikatz можно перекомпилировать с измененными командами и строками, что не позволит обнаруживать его использование по командной строке. Также не будут видны варианты, когда на машину помещается легитимный бинарный файл, подверженный DLL hijacking.



Код Mimikatz с измененными строками


Настроить аудит Windows можно на любой системе без предустановки стороннего ПО, но есть и существенные недостатки:

1. Неудобная и плохо масштабируемая настройка.
Пример: чтобы поставить на мониторинг определенную ветку реестра, для нее нужно отдельно настроить ACL. Сам факт того, что нужно проводить какие-то действия, на практике выливается в проблемы и задержки по времени, особенно в случае крупных инфраструктур. Если это делается для расширения мониторинга (например, для детектирования какого-нибудь способа UAC Bypass), то время не играет критической роли. Но если такая необходимость возникает во время инцидента, это затрудняет процесс реагирования.

2. Отсутствие контроля.
Если события перестанут регистрироваться или поступать в используемые системы мониторинга, вовремя понять это, скорее всего, не получится, так как нет централизации.

3. Простота противодействия.
Даже злоумышленники с низкой квалификацией знают, как скрываться от стандартного аудита. Вопрос только в том, насколько эффективно и незаметно они это сделают.

Примеры техник:

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

Приостановка потоков службы аудита с последующим выполнением вредоносных действий или удалением событий (например, с помощью инструмента github.com/QAX-A-Team/EventCleaner).

Сокрытие событий с помощью нарушения структуры соответствующего файла .evtx (http://personeltest.ru/aways/github.com/fox-it/danderspritz-evtx).

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

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

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

Сходство Sysmon и EDR


Sysmon не является полноценным EDR-решением, так как в нем нет возможности выполнять активные действия на системе. Но механизм сбора событий точно такой же, как и в коммерческих EDR: работает он на двух технологиях обратных вызовах ядра и ETW. Подробно описывать их не будем рассмотрим только, как появляются события и кто инициатор их создания.



Обратные вызовы ядра. Например, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Где и как вызываются эти и другие обратные вызовы, можно увидеть в соответствующих функциях ядра. Пример вызова callbackов при создании процесса приведен ниже:



Цикл вызова callbackов в CreateProcessW -> NtCreateUserProcess -> PspInsertThread.
То есть вызывает эти callbackи поток родительского процесса, вызвавший CreateProcess.

Event Tracing Windows (ETW).
В части появления событий ETW работает похожим образом. Снова рассмотрим пример с созданием процесса. При вызове CreateProcessW поток родительского процесса выполняет следующие действия (упрощенная схема):

CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, переход в режим ядра)
NtCreateUserProcess (ntoskrnl.exe, далее работа в режиме ядра)
PspInsertThread (здесь вызываются и callbackи)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite

Таким образом, поток родительского процесса является прямым инициатором создания события ETW. Примерно таким же образом работает запись остальных событий, например, сетевых. Ниже приведен пример создания событий, связанных с сетевой активностью:



Функция ядра EtwpNetProvTraceNetwork


Из всего вышесказанного следует два вывода:

1) И Sysmon, и EDR использует для сбора событий только встроенные возможности Windows, что обеспечивает надежность работы.

2) Злоумышленник может использовать методы сокрытия, которые будут применимы и к Sysmon, и к EDR. Обратные вызовы ядра можно снять в памяти ядра с помощью подписанного драйвера. А зная описанный механизм регистрации событий, можно понять, почему Sysmon и некоторые EDR не могут обнаружить определенные техники инжектирования в процесс (например, с помощью APC) или PPID spoofing.

Sysmon


Использование Sysmon позволяет расширить возможности стандартного аудита. События при этом записываются в отдельный журнал. Некоторые примеры информации, которой нет в аудите Windows, но есть в Sysmon:

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

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

1) копирование LOLBin под другим именем можно выявлять по соответствию полей OriginalFileName, Image и Hashes из события создания процесса;

2) можно детектировать загрузку неподписанных библиотек, что в некоторых случаях позволяет обнаружить DLL hijacking;

3) есть потенциальная возможность выявлять Mimikatz с помощью вышеупомянутых методов или по событию ProcessAccess к процессу lsass.exe.

Настройка аудита осуществляется с помощью конфигурационного файла, что в случае с созданием файлов и событиями реестра намного удобнее настройки ACL.

При этом нужно учитывать следующие моменты:

Необходимость дополнительных инструментов. Так как события пишутся в журнал, то, как и в случае с расширенным аудитом Windows, Sysmon нужно использовать в связке с другими инструментами, например, SIEM.

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

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

Про способы обхода некоторых возможностей Sysmon можно почитать здесь, здесь и здесь.

Endpoint Detection & Response


С ростом размера и критичности инфраструктуры недостатки Sysmon становятся существенными. Качественные EDR имеют несколько преимуществ (специфические для конкретных продуктов возможности описывать не будем):

1) Расширенный набор регистрируемых событий
Здесь все зависит от конкретного продукта. Например, встречается логирование всего интерактивного ввода в командную строку, что позволяет детектировать техники, которые не видно ни с аудитом Windows, ни с Sysmon.

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

Логирование интерактивного ввода, в свою очередь, поможет детектировать такой случай, если Mimikatz не будет перекомпилирован (в нашем случае строки остались нетронутыми).

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

3) Самодостаточность
В большинстве случаев EDR это самостоятельный продукт со своим интерфейсом, который может использоваться не только в связке с другими инструментами, но и отдельно.

Может присутствовать возможность писать собственные правила детектирования. Так как набор доступных данных больше, чем у расширенного аудита или Sysmon, у аналитиков появляется больше возможностей для детектирования различных паттернов атак.

4) Возможность активного реагирования
Во время реагирования на инцидент необходимость выполнить какие-либо действия на множестве систем практически всегда становится проблемой.

EDR позволяет в удобной интерактивной форме выполнять множество действий:

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

Так как класс продуктов EDR изначально создавался для обеспечения хостового мониторинга и реагирования, недостатков у таких решений в этой области существенно меньше. Здесь все зависит от возможностей конкретного продукта. Не обходится и без слепых зон, например, отсутствует возможность углубленного анализа сетевой активности (проблема, которая успешно решается продуктами NTA/NDR).

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

Автор: Аскер Джамирзе, старший инженер технического расследования отдела расследования инцидентов JSOC CERT
Подробнее..

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

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

10.02.2021 16:11:31 | Автор: admin

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

Пассивные средства безопасности

Пассивные средства сетевой безопасности применяются для мониторинга и анализа трафика в сети. Такие инструменты работают с копией трафика, полученной со SPAN-портов, ответвителей сетевого трафика (TAP) или брокеров сетевых пакетов (NPB). Пассивный мониторинг не вносит временных задержек и дополнительной служебной информации в сеть. В данное время широко используются такие пассивные средства безопасности, как IDS, Network Forensics, NBA и NTA.

Система обнаружения вторжений (IDS)

Система обнаружения вторжений (Intrusion Detection System - IDS) предназначена для мониторинга сетевого трафика на наличие вредоносных программ, эксплойтов и других киберугроз путём использования большого количества сигнатур угроз (иногда называемых правилами). Программное обеспечение IDS может быть развёрнуто на специально построенных устройствах, предоставленном пользователем оборудовании и в некоторых случаях как виртуальные устройства для VMware, Xen и других платформ виртуализации.

В настоящее время в подавляющем большинстве случаев IDS это режим работы инструментов системы предотвращения вторжений (Intrusion Prevention System IPS). Другими словами, на сегодняшний день приобрести решение, которое способно выполнять только пассивный мониторинг будет довольно проблематично. IPS относятся к более сложным и дорогим устройствам, однако, как правило, поддерживают активные IPS и пассивные IDS конфигурации в одном решении. Кроме того, компании обычно развёртывают IPS только для пассивного IDS мониторинга, особенно в ядре сети.

В пространстве IDS решений (как конфигурация пассивного мониторинга системы IPS) представлены продукты компаний Positive Technologies, Код Безопасности, Инфотекс, Smart-Soft, Info Watch, Stonesoft, Trend Micro, Fortinet, Cisco, HP, IBM, Juniper, McAfee, Sourcefire, Stonesoft, Trend Micro, Check Point.

Сетевая форензика (Network Forensics)

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

Производители решений в этом пространстве MicroOLAP, Гарда Технологии, AccessData, NIKSUN, RSA (NetWitness), Solera Networks.

Анализ поведения сети (NBA) и сетевого трафика (NTA)

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

Системы анализа поведения сети (Network Behavior Analysis - NBA) обнаруживает угрозы, с которыми сталкивается сеть изнутри, используя NetFlow и другие стандарты потока (cFlow, sFlow, jFlow и IPFIX), чтобы получить базовое значение для нормального сетевого трафика и обнаружить аномалии, такие как распространение вредоносных программ. Системы анализа сетевого трафика (Network Traffic Analysis - NTA) предназначены для перехвата и анализа трафика, а также для обнаружения сложных и целевых атак. С их помощью можно проводить ретроспективное изучение сетевых событий, обнаруживать и расследовать действия злоумышленников, реагировать на инциденты. NTA могут служить отличным источником данных для ситуационных центров информационной безопасности (SOC).

Производители в пространстве NBA и NTA решений Positive Technologies, Kaspersky, Group-IB, Гарда Технологии, Arbor Networks, Lancope, Riverbed Awake, Cisco, Darktrace, ExtraHop Networks, LogRhythm, Flowmon, RSA, TDS и другие.

Типичные проблемы развёртывания систем сетевой безопасности

ИТ-компании сталкиваются с многочисленными проблемами при развёртывании инструментов сетевой защиты, особенно в больших, сложных и географически распределённых сетях. Звучит знакомо? Ниже приведены кейсы, в которых распространённые проблемы систем мониторинга и информационной безопасности решаются с помощью внедрения брокера сетевых пакетов (NPB).

Кейс 1. Оптимизация сетевой инфраструктуры информационной безопасности

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

Применяемые методы зеркалирования трафика с использованием SPAN-портов или ответвителей сетевого трафика (TAP) имеют свои ограничения и недостатки. Трафик SPAN-портов имеет низкий приоритет и, при повышении нагрузки на коммутаторе, начинает теряться, а при выставлении высокого приоритета, начинает теряться боевой трафик, что приводит к более опасным последствиям. Использование TAP позволяет иметь стопроцентную копию трафика, но здесь есть ограничение по количеству возможных точек установки TAP на сетевой инфраструктуре. При увеличении парка средств информационной безопасности, на каждое из которых нужно подавать трафик с одних и тех же сегментов сети, остро встаёт вопрос внедрения их в существующую инфраструктуру.

Задача: В компании, где внедрены системы обнаружения вторжений (IDS) и анализа поведения сети (NBA), разворачиваются системы Network Forensics и NTA. Для получения максимальной видимости трафика, съём осуществляется не через SPAN-порты, а через TAP. Трафик от TAP соответствующих сегментов сети необходимо доставить и распределить между четырьмя видами систем информационной безопасности.

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

Кейс 2. Оптимизация использования средств информационной безопасности

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

Задача: Компания имеет систему обнаружения вторжений (IDS) с четырьмя интерфейсами 10GbE. Трафик для мониторинга снимается с четырёх сегментов сети, при этом пиковая нагрузка на IDS не более 40%. Со временем инфраструктура сети увеличилась, и возникла необходимость дополнительно отслеживать два новых сегмента.

Решение: С расчётом на дальнейшее развитие сети и отказа от закупки дополнительной IDS в виду 40% загрузки существующей системы, решать эту задачу рациональнее с помощью брокера сетевых пакетов. В данном случае использование пакетного брокера продиктовано еще и уменьшением проблем, связанных с решением вопросов выделения места в стойке, обеспечения электропитания и кондиционирования. Брокеры сетевых пакетов могут агрегировать трафик из нескольких сегментов сети, а затем оптимизировать (выполняя функции фильтрации, классификации, зеркалирования, балансировки, дедупликации, модификации) этот трафик перед маршрутизацией в IDS. Брокеры сетевых пакетов, как правило, дешевле средств обеспечения безопасности, что позволяет компаниям разумно использовать денежные средства и материальные ресурсы, одновременно повышая отказоустойчивость и производительность инструментов.

Кейс 3. Использование инструментов безопасности 1G в современных сетях

Стандарт компьютерной сети 10-гигабитный Ethernet (10GbE или 10G) был впервые опубликован в 2002 году, но достиг критической массы к 2007 году. С тех пор 10G стал основой для крупных компьютерных сетевых инфраструктур и магистралей. Уже сейчас широко распространяются стандарты 40G/100G, а в недалёком будущем придут стандарты 200G/400G.

Практически каждая крупная компьютерная сеть имеет десятки, а то и сотни, инструментов мониторинга безопасности волоконной сети 1G. Эти устройства в зависимости от модели могут иметь возможность проверять более 1 Гбит/с трафика, но инструменты, оснащённые интерфейсами 1G, физически не могут подключаться к сетям 10G/40G/100G.

Задача: Компания модернизирует инфраструктуру сети для увеличения пропускной способности каналов внедрением нового сетевого оборудования и линий связи. На замену интерфейсам 1G приходят интерфейсы 10G/40G/100G. Существующая система информационной безопасности состоит из средств с интерфейсами 1G. Необходимо обеспечить функционирование существующей системы информационной безопасности на новой инфраструктуре.

Решение: Брокеры сетевых пакетов решают эту задачу путем агрегирования, балансировки нагрузки и оптимизации трафика (минимизация нецелевого трафика и дедупликация) из сетей 10G/40G/100G в существующие инструменты безопасности 1G. Это решение не только продлевает срок службы существующих инструментов 1G (что откладывает расходы на их замену), но и максимизирует их производительность и отказоустойчивость.


Таким образом, применение брокеров сетевых пакетов решает следующие задачи:

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

Подробнее..

Аналитика в SD-WAN как она выглядит и зачем нужна?

09.04.2021 18:04:19 | Автор: admin
Привет, я работаю инженером в КРОК, где у нас есть своя SD-WAN-лаборатория. И когда заказчик приходит с вопросами вроде А вот у меня в сети сейчас всё работает так, а как это будет работать, если я захочу перейти на SD-WAN? И будет ли работать вообще? мы можем быстро собрать нужную схему, оттестировать и показать.

На днях мы добавили в наш стенд Cisco средство аналитики от компании-партнёра LiveAction, которое сейчас вовсю тестируем. Почему для SD-WAN вообще нужно какое-то особое средство аналитики? Во-первых, маршрутизация в такой сети устроена намного сложнее, чем в традиционной сети и администратору важно видеть, что происходит с трафиком с учётом всего многообразия настроек. Во-вторых, SD-WAN-сеть это про обеспечение качества работы приложений, а значит необходимо иметь средства анализа качества работы этих приложений.

Расскажу, как эти решения работают в паре и как все настроить.




Принцип работы аналитики в SD-WAN


Работа SD-WAN-сети Cisco, напомню, определяется набором компонентов управления:
vManage управляет конфигурациями и собирает данные для мониторинга сети
vSmart рассылает маршрутную информацию и политики управления трафиком
vBond связывает все компоненты решения воедино



SD-WAN-роутеры получают маршрутную информацию по проприетарному протоколу OMP. В традиционной сети маршрут всегда выглядит как сеть 192.168.4.0/24 доступна через шлюз X. В случае с OMP всё несколько непривычно, например, вот так:



По сути вывод выше означает сеть 192.168.4.0/24 доступна через маршрутизатор с идентификатором 1.1.255.21, через два вида транспорта (MPLS и Private1), а передаваемый туда трафик необходимо упаковать в IPSEC. Все эти навороты необходимы для обеспечения SD-WAN-функционала.

Вдобавок к маршрутам, есть ещё и политики, определяющие выбор вида транспорта, например, Голосовой трафик передавать через MPLS, если MPLS не выдаёт нужное качество, перейти на LTE. Вот так:



Понять, куда пойдёт трафик конкретного приложения в конкретный момент времени становится сложно. Проверить что именно мы настроили можно с помощью инструмента симуляции потоков (Simulate Flows) в vManage



Но кроме этого, хочется понять, как ходил трафик этого приложения по сети в последнюю, скажем, неделю, с учётом того, что качество каналов иногда падало, а объёмы трафика менялись. Стоило ли вообще передавать этот трафик именно по этому пути или стоит пересмотреть политику? Именно в этом и помогает такое средство аналитики как LiveAction.

LiveAction устанавливается в виде сервера или кластера серверов, интегрируется с vManage по API, получает оттуда список маршрутизаторов и данные об их конфигурации, а потом опрашивает их по SNMP и получает данные по cFlowd (аналог NetFlow).

Интеграция


Связались с vManage через API:



Получили список устройств:



Разрешили на них доступ по SNMP (Стандартный Internet OID, добавляется в SNMP-шаблон в vManage):



Настроили отправку cFlowd с помощью политики vManage:



И получаем в LiveAction информацию о сети, например, вот в таком представлении:



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



а также, при необходимости, сгенерировать кастомизируемый отчёт, например, вот такой по трафику между двумя площадками:



Заглянуть поглубже


По клику на потоке трафика на диаграмме система умеет подтягивать с vManage политики, влияющие на него, опять же через API:



Ну а для того, чтобы увидеть, что по факту происходило с трафиком того или иного приложения в конкретный момент времени есть вот такая диаграмма:



Из неё можно увидеть, что, например, трафик FTP-Data из VRF 2 передавался с меткой DSCP 0 через транспорт с названием Private1. В нижней части доступен бегунок, позволяющий определить интересующий нас промежуток времени и кнопка Play, чтобы посмотреть, как менялось поведение маршрутизатора во времени. Таким образом можно не только убедиться в том, что трафик того или иного приложения передавался так, как мы этого хотели, но и расследовать какие-то инциденты в работе сетевого приложения, имевшие место в прошлом. Например, если три дня назад с 12:00 до 12:30 у нас плохо работала видеоконференцсвязь, можно увидеть, что мы почему-то передавали её трафик не через тот канал и без нужной метки DSCP.

Можно вывести список потоков трафика между двумя площадками в виде таблицы:



А потом зайти в конкретный поток и посмотреть путь его прохождения вместе, скажем, с загрузкой интерфейсов, CPU и памяти устройств, участвовавших в передаче данных:



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

И ещё глубже


Помимо веб-интерфейса у LiveAction есть инженерная консоль. Она позволяет увидеть потоки трафика даже в пределах одного устройства. Вот так, к примеру, выглядит маршрутизатор Cisco CSR1000v:



Для каждого устройства можно смотреть так называемый Historical Playback то, как менялись потоки трафика во времени:



Дашборды


Для текущего мониторинга SD-WAN-сети в LiveAction доступны преднастроенные и кастомизируемые с помощью виджетов дашборды. Доступно около 30 различных виджетов, можно создавать свои. Вот пример готового дашборда для отслеживания производительности туннелей SD-WAN:



Для любого дашборда можно сделать постоянную ссылку и вывести его в контрастном виде на плазменную панель в NOC:



Чем полезен LiveAction на этапе тестирования


Наш опыт работы с решением Cisco SD-WAN показывает, что для его успешного тестирования и внедрения особенно важно понимать, какой именно трафик гуляет по сети, какими маршрутами и в каких объёмах. Традиционные сети фокусировались на connectivity соединить площадки A, B, C с ЦОД. Максимум, что можно было сделать для обеспечения качества работы конкретных приложений это шейпинг трафика и распределение его по очередям QoS.

Задачу connectivity, кстати, SD-WAN решает быстрее и проще традиционных сетей, но главная его фишка адаптация под требования сетевых приложений. Real-Time трафик мы можем перебрасывать с одного канала на другой, измеряя задержку и джиттер. Вот как это работает. На трафик, критичный к потерям применяем коррекцию ошибок или передаем его одновременно по двум каналам, а тяжёлый и некритичный трафик сгружаем на дешёвые каналы. Система аналитики как раз позволяет увидеть какие приложения передают трафик по сети и отнести их к тому или иному классу. Причём сделать это можно не только после внедрения SD-WAN, но и до, на этапе тестирования:

  1. Поставить LiveAction и собрать первичные данные с сети
  2. Выбрать для тестирования SD-WAN площадки, паттерн трафика на которых наиболее репрезентативен для текущего состояния сети
  3. Сделать предположения о том, какие политики повысят качество передачи данных
  4. Установить SD-WAN-маршрутизаторы и настроить в тестовом SD-WAN-сегменте политики, согласно предположению
  5. С помощью LiveAction проанализировать результаты работы и скорректировать политики. Увидеть самим и продемонстрировать заинтересованным лицам повышения качества передачи данных
  6. Получить готовую к развёртыванию на всю сеть конфигурацию SD-WAN.

Резюме. Польза от аналитики на уже работающей SD-WAN-сети


Тем, кто уже внедрил у себя решение SD-WAN от Cisco, система аналитики поможет:

  • Проследить за тем, как операторы связи соблюдают SLA и какое вообще качество выдают на своих каналах связи;
  • Увидеть проблемы в работе критичных приложений до того, как их пользователи начнут жаловаться;
  • Корректно подстраивать сеть под работу новых приложений, которые внедряются;
  • Быстрее находить ошибки в настройках, допущенные специалистами по эксплуатации сети;
  • Понять, насколько лучше стала использоваться доступная пропускная способность каналов связи, а значит и оценить эффективность миграции на SD-WAN в деньгах.

LiveAction классное, продвинутое решение, которое позволит выжать максимум производительности сети и наибольшую отдачу от инвестирование в такое капитальное решение, как SD-WAN. При этом, конечно, должен быть выстроен процесс эксплуатации сети с точки зрения менеджмента система заявок, расследования причин возникающих проблем, планирование развития. Если инженеры, эксплуатирующие сеть, работают по звонку и хаотично тушат пожары, не факт, что она им поможет.
Подробнее..

Категории

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

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