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

Анализ трафика

Один подход к обнаружению веб-ботов, или Как мы использовали машинное обучение для классификации ботов

19.08.2020 20:12:15 | Автор: admin
Объем трафика в интернете растет (особенно в последние месяцы, когда мы все оказались на удаленке и многие перевели свои активности в онлайн). Увеличивается и число автоматических средств взаимодействия с контентом на веб-сайтах и, как следствие, все большую актуальность получает фильтрация нежелательной автоматизированной активности. Сегодня до 50% интернет-активности генерится автоматически с помощью так называемых веб-ботов (или просто ботов). И в данном случае речь о любой активной в сети программе, вне зависимости от целей ее использования. Обычно такие программы выполняют повторяющиеся, простые в автоматизации действия. Например, поисковые движки Google или Yandex используют краулеры для периодического сбора контента и индексации страниц в интернете.

Итак, есть два типа веб-ботов легитимные и зловредные. К легитимным можно отнести поисковые движки, RSS-ридеры. Примеры зловредных веб-ботов сканеры уязвимостей, скрейперы, спамеры, боты для DDoS-атак, трояны для мошенничества с платежными картами. После определения типа веб-бота к нему могут быть применены различные политики. Если бот легитимный, можно уменьшить приоритет его запросов к серверу или снизить уровень доступа к определенным ресурсам. Если бот определен как зловредный, можно его заблокировать или отправить в песочницу для дальнейшего анализа. Обнаруживать, анализировать и классифицировать веб-боты важно, так как они могут нанести вред: например, вызвать утечку важных для бизнеса данных. А также это снизит нагрузку на сервер и сократит так называемый шум в трафике, ведь до 66% трафика веб-ботов это именно зловредный трафик.

Существующие подходы


Есть разные техники обнаружения веб-ботов в сетевом трафике, начиная от лимитирования частоты запросов к узлу, черных списков IP-адресов, анализа значения HTTP-заголовка User-Agent, снятия отпечатков устройства и заканчивая внедрением CAPTCHA, и поведенческим анализом сетевой активности с помощью машинного обучения.

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

Анализ поля User-Agent в первом приближении может показаться полезным, но ничто не мешает веб-боту или пользователю изменить значения этого поля на валидное, замаскировавшись под обычного пользователя и используя валидный User-Agent для браузера, или под легитимный бот. Назовем такие маскирующиеся веб-боты impersonators. Использование различных отпечатков устройства (отслеживание движения мыши или проверка возможности рендеринга HTML-страницы клиентом) позволяет выделять более сложные в обнаружении веб-боты, имитирующие поведение человека, например запрашивающие дополнительные страницы (файлы стилей, иконки и т. п.), парсящие JavaScript. Этот подход основан на внедрении кода на стороне клиента, что часто недопустимо, так как ошибка при вставке дополнительного скрипта может нарушить работу веб-приложения.

Следует отметить, что обнаруживать веб-боты можно и онлайн: оценка сессии будет производиться в режиме реального времени. Описание такой постановки задачи можно найти у Кабри и соавторов [1], а также в работах Зи Чу [2]. Другой подход анализировать только после завершения сессии. Наиболее интересен, очевидно, первый вариант, который позволяет принимать решения быстрее.

Предлагаемый подход


Для выявления и классификации веб-ботов мы использовали техники машинного обучения и стек технологий ELK (Elasticsearch Logstash Kibana). Объектами исследования стали HTTP-сессии. Сессия последовательность запросов от одного узла (уникальное значение IP-адреса и поля User-Agent в HTTP-запросе) в фиксированном временном интервале. Дерек и Гохале для определения границ сессий используют 30-минутный интервал [3]. Илиу и др. утверждают, что такой подход не гарантирует реальной уникальности сессии, но все же допустимо. В силу того, что поле User-Agent может быть изменяемым, могут появиться больше сессий, чем есть на самом деле. Поэтому Никифоракис и соавторы предлагают более тонкую настройку, основанную на том, поддерживается ли ActiveX, включен ли Flash, разрешение экрана, версия ОС.

Мы же будем считать допустимой погрешность в формировании отдельной сессии, если поле User-Agent меняется динамически. А для выявления сессий ботов построим четкую бинарную модель классификации и будем использовать:

  • автоматическую сетевую активность, созданную веб-ботом (метка bot);
  • сетевую активность, созданную человеком (метка human).

Для классификации веб-ботов по типу активности построим многоклассовую модель из таблицы ниже.
Название Описание Метка Примеры
Краулеры Веб-боты,
собирающие
веб-страницы
crawler SemrushBot,
360Spider,
Heritrix
Социальные сети Веб-боты различных
социальных сетей
social_network LinkedInBot,
WhatsApp Bot,
Facebook bot
RSS-ридеры Веб-боты,
собирающие информацию с
помощью RSS
rss Feedfetcher,
Feed Reader,
SimplePie
Поисковые движки Веб-боты
поисковых движков
search_engines Googlebot, BingBot,
YandexBot
Утилиты Веб-боты,
использующие
различные
библиотеки и
утилиты для
автоматизации
libs_tools Curl, Wget,
python-requests,
scrapy
Веб-боты Общая категория bots
Неизвестные Такие сессии, для
которых не была
известна разметка
или значение поля
User-Agent было
пустым или
отсутствовало
unknown

Также будем решать задачу онлайн-обучения модели.



Концептуальная схема предлагаемого подхода

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

Обучение и тестирование модели


С помощью модуля packetbeat осуществляется парсинг трафика. Сырые HTTP-запросы отправляются в logstash, где с помощью Ruby-скрипта формируются задачи в терминах Celery. Каждая из них оперирует идентификатором сессии, временем запроса, телом и заголовками запроса. Идентификатор сессии (ключ) значение хеш-функции от конкатенации IP-адреса и User-Agent. На этом этапе создаются два вида задач:

  1. по формированию вектора признаков для сессии,
  2. по простановке меток класса на основе текста запроса и User-Agent.

Эти задачи отправляются в очередь, где обработчики сообщений их выполняют. Так, обработчик labeler выполняет задачу простановки метки класса, используя экспертную оценку и открытые данные из сервиса browscap на основе используемых User-Agent; результат записывает в key-value storage. Session processor формирует вектор признаков (см. таблицу ниже) и записывает результат для каждого ключа в key-value storage, а также устанавливает время жизни ключа (TTL).
Признак Описание
len Количество запросов в сессии
len_pages Количество запросов в сессии в страницах
(URI заканчивается на .htm, .html, .php,
.asp, .aspx, .jsp)
len_static_request Количество запросов в сессии в
статических страницах
len_sec Время сессии в секундах
len_unique_uri Количество запросов в сессии,
содержащих уникальный URI
headers_cnt Количество заголовков в сессии
has_cookie Есть ли заголовок Сookie
has_referer Есть ли заголовок Referer
mean_time_page Среднее время на страницу в сессии
mean_time_request Среднее время на запрос в сессии
mean_headers Среднее количество заголовков в сессии

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

Предсказание


Во время парсинга трафика обновляется вектор признаков сессии в key-value storage: c появлением нового запроса в сессии пересчитываются признаки, ее описывающие. Например, признак среднее количество заголовков в сессии (mean_headers) вычисляется каждый раз, когда в сессию добавляется новый запрос. Predictor отправляет вектор признаков сессий в модель, а ответ от модели записывает в Elasticsearch для анализа.

Эксперимент


Свое решение мы проверяли на трафике портала SecurityLab.ru. Объем данных более 15 ГБ, более 130 часов. Количество сессий более 10 000. В силу того, что предлагаемая модель использует статистические признаки, сессии, содержащие менее 10 запросов, не участвовали в обучении и тестировании. В качестве метрик качества мы использовали классические метрики качества точность, полнота и F-мера для каждого класса.

Тестирование модели обнаружения веб-ботов


Построим и оценим модель бинарной классификации, то есть будем обнаруживать ботов, а потом уже классифицировать их по типу активности. По результатам пятикратной стратифицированной перекрестной проверки (именно такая требуется для рассматриваемых данных, так как присутствует сильный дисбаланс классов) можно сказать, что построенная модель довольно хорошо (точность и полнота более 98%) умеет разделять классы пользователей-людей и ботов.
Средняя точность Средняя полнота Средняя F-мера
bot 0,86 0,90 0,88
human 0,98 0,97 0,97

Результаты тестирования модели на отложенной выборке представлены в таблице ниже.
Точность Полнота F-мера Количество
примеров
bot 0,88 0,90 0,89 1816
human 0,98 0,98 0,98 9071

Значения метрик качества на отложенной выборке примерно совпадают со значениями метрик качества при валидации модели, значит модель на этих данных умеет обобщать знания, полученные при обучении.
Рассмотрим ошибки первого рода. Если экспертно разметить эти данные, то матрица ошибок существенно изменится. Это значит, что при разметке данных для модели были допущены некоторые ошибки, но модель все равно смогла распознать такие сессии корректным образом.
Точность Полнота F-мера Количество
примеров
bot 0,93 0,92 0,93 2446
human 0,98 0,98 0,98 8441

Рассмотрим пример сессии impersonators. Она содержит 12 похожих запросов. Один из запросов представлен на рисунке ниже.



Все последующие запросы в этой сессии имеют такую же структуру и отличаются только URI.



Отметим, что этот веб-бот использует валидный User-Agent, добавляет поле Referer, обычно использующееся неавтоматическими средствами, и количество заголовков в сессии невелико. Кроме того, временные характеристики запросов время сессии, среднее время на запрос позволяют говорить о том, что эта активность автоматическая и относится к классу RSS-ридеров. При этом сам бот маскируется под обычного пользователя.

Тестирование модели классификации веб-ботов


Для классификации веб-ботов по типам активности будем использовать те же данные и тот же алгоритм, что в предыдущем эксперименте. Результаты тестирования модели на отложенной выборке представлены в таблице ниже.
Точность Полнота F-мера Количество
примеров
bot 0,82 0,81 0,82 194
crawler 0,87 0,72 0,79 65
libs_tools 0,27 0,17 0,21 18
rss 0,95 0,97 0,96 1823
search engines 0,84 0,76 0,80 228
social_network 0,80 0,79 0,84 73
unknown 0,65 0,62 0,64 45

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

Согласно этим экспериментам на рассматриваемых данных, более 22% сессий (при общем объеме более 15 ГБ) созданы автоматически, и среди них 87% относятся к активности ботов общей направленности, неизвестных ботов, RSS-ридеров, веб-ботов, использующих различные библиотеки и утилиты. Таким образом, если фильтровать сетевой трафик веб-ботов по типу активности, то предлагаемый подход позволит снизить нагрузку на используемые серверные ресурсы минимум на 910%.

Тестирование модели классификации веб-ботов онлайн


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



F-мера модели во времени для каждого класса

Графики ниже иллюстрируют изменение значения метрик качества во времени для наиболее интересных классов. Размер точек на них связан с числом сессий в выборке в конкретный момент времени.



Точность, полнота, F-мера для класса search engines



Точность, полнота, F-мера для класса libs tools



Точность, полнота, F-мера для класса rss



Точность, полнота, F-мера для класса crawler



Точность, полнота, F-мера для класса human

Для ряда классов (human, rss, search_engines) на рассматриваемых данных качество работы модели является допустимым (точность и полнота более 80%). Для класса crawler с увеличением числа сессий и качественным изменением вектора признаков для этой выборки качество работы модели растет: полнота увеличилась с 33% до 80%. Для класса libs_tools невозможно сделать разумных выводов, так как количество примеров для этого класса невелико (менее 50); поэтому отрицательный результат (низкое качество) не может быть подтвержден.

Основные результаты и дальнейшее развитие


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

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

Для дальнейшего развития задачи классификации и обнаружения веб-ботов целесообразно:

  • выделять дополнительные классы ботов и повторно обучать, тестировать модель;
  • добавлять дополнительные признаки для классификации веб-ботов. Например, добавление признака robots.txt, являющегося бинарным и отвечающего за наличие или отсутствие обращения к странице robots.txt, позволяет повысить среднюю F-меру для класса веб-ботов на 3%, не ухудшая другие метрики качества для прочих классов;
  • делать более корректную разметку для целевого класса с учетом дополнительных метапризнаков и экспертной оценки.

Автор: Николай Лыфенко, ведущий специалист группы перспективных технологий, Positive Technologies

Источники
[1] Cabri A. et al. Online Web Bot Detection Using a Sequential Classification Approach. 2018 IEEE 20th International Conference on High Performance Computing and Communications.
[2] Chu Z., Gianvecchio S., Wang H. (2018) Bot or Human? A Behavior-Based Online Bot Detection System. In: Samarati P., Ray I., Ray I. (eds) From Database to Cyber Security. Lecture Notes in Computer Science, vol. 11170. Springer, Cham.
[3] Derek D., Gokhale S. An integrated method for real time and offline web robot detection. Expert Systems 33. 2016.
[4] Iliou Ch., et al. Towards a framework for detecting advanced Web bots. Proceedings of the 14th International Conference on Availability, Reliability and Security. 2019.
[5] Nikiforakis N., Kapravelos A., Joosen W., Kruegel C., Piessens F. and Vigna G. Cookieless Monster: Exploring the Ecosystem of Web-Based Device Fingerprinting. 2013 IEEE Symposium on Security and Privacy, Berkeley, CA, 2013, pp. 541555.
Подробнее..

Сайты региональных органов власти все еще печальнее, чем у федералов

06.12.2020 22:08:26 | Автор: admin
image

Вот мы и выпустили сводный доклад по итогам мониторинга сайтов высших органов власти регионов Надежность сайтов органов государственной власти субъектов Российской Федерации 2020. Оценивали их с трех сторон: а) можно ли эти сайты считать официальными с точки зрения закона, б) обеспечивают ли они надежное HTTPS-соединение, и в) что и откуда они загружают, т.е. насколько потенциально уязвимы к XSS и как щедро сливают данные о своих посетителях третьим лицам?

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

Что касается официальности сайтов: у федералов 2 из 82 исследованных сайтов органов власти оказались неофициальным. Первоначально мы посчитали неофициальным еще и сайт Росгвардии, администрируемый подведомственным ей центром информационных технологий, но та отстояла свою точку зрения: центр это войсковая часть, т.е. часть самой Росгвардии, поэтому нарушения закона тут нет, а есть наша невнимательность (но вот TLS-сертификат у них на сайте уже вне всяких сомнений второй месяц как протух).

Поэтому региональные сайты мы проверяли по уже доработанной методике, предусматривающей запрос в ЕГРЮЛ и выяснили: из 184 сайтов, названных официальными, 27 (15%) таковыми не являются, т.к. соответствующие доменные имена администрируются подведомственными госучреждениями, коммерческими и некоммерческими организациями, и даже физическими лицами, хотя закон четко устанавливает, что это разрешено только государственным органам (читай органам власти). Особенно отличились Северо-Западный и Сибирский федеральные округа, где официальных сайтов не имеют более 30% высших органов власти.

С замиранием сердца делали запрос в ЕГРЮЛ по ИНН администратора сайта Парламента Чеченской Республики, который указан в реестре регистратора как ООО Парламент ЧР. Я, конечно, заранее извиняюсь, Рамзан Ахматович, но у парламентов в России иная организационно-правовая форма, и в ФНС считают так же (они пусть сами извиняются). В общем, сенсации не случилось администратор там Аппарат Парламента Чеченской Республики, а за ООО пусть извиняется тот, кто внес такую запись в реестр доменов.

Тут внимательный читатель может перебить меня вопросом: а почему исследовались 184 сайта, когда субъектов федерации 85? Отвечаю: исследовались сайты региональных правительств, парламентов и губернаторов при их наличии (сайта, а не губернатора). Но если вы думаете, что количество губернаторских сайтов легко вычисляется по формуле 184 85 85 (= 14), то вы заблуждаетесь, все намного сложнее. Например, у Правительства Москвы нет своего сайта, есть только сайт Мэра Москвы, где правительству отведен свой угол. Зато органы власти некоторых других субъектов располагают сразу двумя сайтами, причем оба называются официальными.

Для примера, у Правительства Республики Тыва сразу два сайта, оба названы официальными (gov.tuva.ru и rtyva.ru) и оба таковыми не являются с точки зрения закона, т.к. первое доменное имя администрируется АО Тывасвязьинформ, а второе вообще анонимным физическим лицом. У Правительства Костромской области тоже два сайта (adm44.ru и kostroma.gov.ru), оба официальные, но с разным наполнением.

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

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

Интересно тут другое: наверное, все хотя бы слышали про Электронную Москву, Электронную Бурятию, Электронный Татарстан и прочие электронные программы по освоению бюджетов на информатизацию госуправления. А знаете, у кого в результате оказалась лучшая поддержка HTTPS на официальном сайте? У правительств Ульяновской и Московской областей и парламентов Владимирской области и ЯНАО.

Я вот ничего даже не слышал про Электронное ЯНАО, может такой программы и не существует, а хотя бы одного пряморукого админа в ЯНАО найти смогли (пятое место по площади среди субъектов федерации, населения как в одном районе Москвы). А в электронной Бурятии то ли с населением еще хуже (Росстат возражает), то ли денег на нормального админа не хватило, но сервера обоих органов власти законодательной и исполнительной приветливо машут любознательным исследователям букетом из CVE-2014-0160, CVE-2014-0224, CVE-2016-2107, CVE-2019-1559 и далее со всеми остановками.

Из занимательного: при попытке проверить сайт Администрации Ненецкого автономного округа, мы наткнулись на блокировку по IP ряда исследовательских инструментов. На это у администратора хватило и усердия, и знаний, и желания, а вот на закрытие CVE-2012-4929 (кто не в курсе, первая цифра год описания уязвимости, 8 лет назад, Карл!) и прочих дыр уже ни сил, ни желания не осталось, а может и знаний тоже.

Лидером по поддержке защищенного соединения является Южный федеральный округ, где 53% исследованных сайтов обеспечивают достаточно надежное HTTPS-соединение. Следом за ним идут Центральный и Уральский (47% и 40% соответственно). Отстающие Приволжский и Северо-Кавказский, в которых лишь 13% сайтов высших органов власти не имеют значимых проблем с поддержкой защищенного соединения.

Что касается XSS, т.е. мусора, которые сайты сами загружают из сторонних источников, то тут, как и у федералов зоопарк: JS-библиотеки, шрифты, счетчики, баннеры и далее со всеми остановками, но есть и свои интересные нюансы.

Например, у федералов Google Analytics на 4 месте по популярности, а у регионалов на 7; это даже в абсолютных цифрах меньше, чем у федералов. Но если собственно счетчик GA стоит лишь на 9% региональных сайтов, то гуглокод вообще на 63%, так что данные о посетителях они все равно успешно собирают. А вот на третьем месте среди счетчиков у регионалов внезапно оказался Bitrix. Это который вроде бы CMS ну и еще немного сбора статистики.

Рекордсменом по любви к аналитике стало Правительство Алтайского края, чей сайт украшен сразу 6 счетчиками, но его успех несколько меркнет по сравнению с сайтами Администрации Костромской области, парламентов Калининградской области, Удмуртской Республики и Москвы, которые украшены кодом счетчика OpenStat, уже два года не подающим признаков жизни. Это, конечно, не электронные пропуска шаманить, это ж HTML, а у ДИТ лапки загребущие.

В качестве резюме: как и в случае мониторинга федеральных сайтов, мы рассылали отдельные доклады по субъектам их героям. Федералов после этого специально не мониторили, но подвижки видны невооруженным глазом: кто-то дыры на сервере залатал, кто-то HTTPS включил, кто-то TLS-сертификат обновил, кто-то так и не почесался, но реакция заметна.

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

В общем, пока на главной странице его сайта не появится срамная картинка или хула на государя-императора, губернатор партбилетом не перекрестится. Через год проверим, так ли это планируем проводить мониторинг ежегодно.
Подробнее..

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

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. При этом, конечно, должен быть выстроен процесс эксплуатации сети с точки зрения менеджмента система заявок, расследования причин возникающих проблем, планирование развития. Если инженеры, эксплуатирующие сеть, работают по звонку и хаотично тушат пожары, не факт, что она им поможет.
Подробнее..

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

13.04.2021 20:10:28 | Автор: admin

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

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

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

Среди наиболее популярных активных средств информационной безопасности остановимся на IPS, NGFW, SWG, AMP, DLP и Anti-DDoS, а также рассмотрим способы их развёртывания на базе Bypass и брокеров сетевых пакетов для обеспечения гарантированной безопасности сети.

Системы предотвращения вторжений (IPS)

Системы предотвращения вторжений (Intrusion Prevention Systems - IPS) это программные и аппаратные средства, предназначенные для обнаружения и предотвращения попыток несанкционированного доступа к конфиденциальным данным, повышения привилегий, использования уязвимостей программного обеспечения и вывода из строя компьютерных систем. Такие попытки вторжений осуществляются главным образом через Интернет или локальную сеть, могут иметь форму атак хакеров/инсайдеров или же быть результатом действий вредоносных программ.

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

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

В России требования к системам обнаружения вторжений (под понятием СОВ подразумеваются как пассивные IDS системы, так и активные IPS системы) появились еще в 2011 году, тогда ФСТЭК России поделила СОВ на 6 классов защиты. Отличия между классами заключаются в уровне информационных систем и непосредственно информации, которая подлежит обработке (персональные данные, конфиденциальная информация, государственная тайна). Соответствие требованиям регулятора является важным фактором при выборе СОВ, в то же время это положительно сказывается на развитии отечественного рынка IPS/IDS решений.

В пространстве IPS решений представлены продукты следующих производителей: Positive Technologies, Код Безопасности, Smart-Soft, Info Watch, Инфотекс, Stonesoft, Trend Micro, Fortinet, Cisco, HP, IBM, Juniper, McAfee, Sourcefire, Stonesoft, Trend Micro, Check Point, Palo Аlto Networks.

Межсетевые экраны нового поколения (NGFW)

Межсетевые экраны нового поколения (Next-Generation Firewall - NGFW) это эволюция типовых межсетевых экранов с возможностью отслеживания состояния соединений. Поскольку всё большее число компаний сейчас используют онлайн-приложения и службы SaaS, то классический контроль портов и протоколов уже недостаточен для обеспечения эффективной сетевой безопасности. В отличие от предыдущего поколения, в новых устройствах добавлена тесная интеграция дополнительных возможностей, таких как встроенная глубокая проверка пакетов (DPI), предотвращение вторжений (IPS) и проверка трафика на уровне приложений (Web Application Firewall). Некоторые NGFW также включают проверку зашифрованного трафика TLS/SSL, фильтрацию веб-сайтов, управление пропускной способностью, QoS, антивирусную проверку и интеграцию со сторонними системами управления идентификацией (LDAP, RADIUS и Active Directory). Решения NGFW в скором времени заменят традиционные межсетевые экраны, предотвращая вторжения и контролируя приложения как по периметру, так и внутри сети.

Производители NGFW решений: UserGate, Континент, Huawei, Check Point, Сisco, Fortinet, McAfee, Palo Alto Networks и Sourcefire.

Шлюзы информационной безопасности (SWG)

Прокси-серверы с функциями информационной безопасности (Security Web Gateway SWG), также известные как веб-фильтры это программно-аппаратные комплексы (ПО + сервер), разработанные и оптимизированные для соблюдения политик веб-безопасности компании и контроля доступа пользователей к веб-сайтам. Веб-сайты, которые содержат вредоносное ПО или неприемлемый контент (например, порнографию или азартные игры), блокируются на SWG, тем самым повышая производительность труда сотрудников, ограничивая ответственность компании и защищая компьютерные устройства пользователей от вреда.

Поставщики SWG группируют веб-сайты по категориям и выпускают обновления безопасности, как правило, на ежедневной основе. Администраторы SWG могут создавать политики доступа на основе категорий веб-сайтов и относить их к отдельным пользователям и группам пользователей.

Производители SWG решений: Ростелеком-Солар, Smart-Soft, UserGate, ESET, Kaspersky, Sophos, TRENDmicro, Huawei, Blue Coat, Cisco, McAfee, Trustwave и Websense.

Advanced malware protection (AMP)

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

Для защиты от этих угроз существует категория решений сетевой безопасности - AMP (Advanced Malware Protection). Основная задача AMP проверка файла, пересылаемого через сетевое устройство и/или записываемого на конечное оборудование, на наличие вредоносного кода. Система AMP осуществляет ретроспективный анализ и обеспечивает защиту не только до момента атаки или во время атаки, но и после того, как атака прошла. Кроме того, это решение позволяет отследить все пути распространения файла и может заблокировать файл на уровне сети.

Производители AMP решений: Kaspersky, Malwarebytes, Cisco, Damballa, FireEye и Palo Alto Networks.

Системы предотвращения утечки данных (DLP)

Системы предотвращения утечки данных (Data Loss Prevention или Data Leakage Prevention - DLP) это программно-аппаратные комплексы (ПО + сервер), которые предназначены для обнаружения и предотвращения потенциальных нарушений конфиденциальности данных и личной информации (номера кредитных карт, номера телефонов, данные паспорта и т. д.) путём мониторинга данных в нескольких состояниях:

  • при использовании (Data-inUse) на рабочем месте пользователя

  • при передаче (Data-inMotion) в сети компании

  • при хранении (Data-atRest) на серверах и рабочих станциях компании

Производители DLP решений: InfoWatch, Инфосистемы Джет, SmartLine Inc, Гарда Технологии, Zecurion, Ростелеком-Солар, Falcongaze, Атом Безопастность, ESET, SearchInform, CoSoSys, Blue Coat, Check Point, Cisco (IronPort), Fidelis, McAfee, RSA, Verdasys, Symantec, Websense.

Системы предотвращения распределённого отказа в обслуживании (DDoS Protection, Anti-DDoS)

Системы предотвращения распределённого отказа в обслуживании (Distributed Denial of Service (DDoS) Protection или Anti-DDoS) это специализированные программно-аппаратные и программные средства, предназначенные для защиты веб-серверов/сайтов компании от распределённых атак типа Отказ в обслуживании.

Атака типа отказ в обслуживании (DoS) - это попытка одного компьютера сделать другой компьютер недоступным для его предполагаемых пользователей путём забивания его полосы пропускания и/или вычислительных ресурсов паразитным трафиком, часто через поток пакетов SYN или ICMP. Распределённый отказ в обслуживании (DDoS) это DoS-атака, инициируемая ботнетом (совокупностью компьютеров, называемых ботами, которые заражены зомби-агентами или троянами), обычно используется для атак на целевые веб-сайты. Все боты в данном ботнете запрограммированы на выполнение действий в точно согласованное время, как это предписано центральной системой управления и контроля (Сommand and Сontrol - С&C), управляемой преступником.

На предприятиях системы Anti-DDoS помогают выявлять и предотвращать DDoS-атаки путём использования проприетарных алгоритмов и оценки механизмов защиты.

Средства безопасности в этой области производят компании: DDOS-GUARD, СТОРМ СИСТЕМС, Variti, Гарда Технологии, Kaspersky, Inoventica Technologies, Qrator Labs, Akamai Technologies, CloudFlare, Imperva, Sucuri, F5 Networks, Arbor Networks, Cisco, Corero и VeriSign.

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

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

Кейс 1 Развёртывание нескольких копий активных средств безопасности для обработки трафика в современных высоконагруженных сетях 40G/100G

В настоящее время широко распространяются стандарты 40G/100G. Производители активных средств безопасности стараются не отставать и предлагают высокопроизводительные инструменты для обеспечения защиты сетей данных стандартов. К сожалению, далеко не все предлагаемые современные инструменты могут обработать трафик высоконагруженных сетей стандартов 40G/100G. А те немногие, которые способны, имеют высокую стоимость и делают это с ограничениями.

Задача: Сеть компании построена по стандарту 40G. Существующая система NGFW имеет интерфейсы 40G, но её производительности хватает только при нагрузке в сети до 30%. При повышении нагрузки в сети установленная NGFW уже не справляется и начинает терять трафик. Необходимо внедрить решение, которое будет обеспечивать работоспособность сети с использованием существующей активной системы NGFW и минимально возможными инвестициями.

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

Кейс 2 Безопасное развёртывание нескольких активных средств безопасности последовательно

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

Задача: В компании, в сетевой инфраструктуре которой развёрнута система межсетевого экрана, планируется внедрить активные системы IPS и Anti-DDoS. При этом необходимо обеспечить бесперебойность работы сети при выходе из строя средств ИБ.

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

Кейс 3 Поддержка отказоустойчивых сетевых конфигураций и активных систем информационной безопасности

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

Отказоустойчивые сетевые архитектуры требуют избыточных компонентов сетевой инфраструктуры и дополнительных единиц активных средств ИБ. Чтобы избыточность свести к минимуму и в то же время обеспечить максимальную отказоустойчивость, необходимо проектировать сеть с использованием брокера сетевых пакетов и Bypass.

Задача: В компании поставлена задача по организации отказоустойчивой конфигурации сети с активными средствами ИБ. Необходимо обеспечить бесперебойное функционирование системы ИБ в случае отказа группы систем и/или одного из элементов группы. Построенный сегмент активных средств ИБ не должен влиять на работоспособность общей сетевой инфраструктуры компании. Также требуется предусмотреть возможность дальнейшей масштабируемости и повышения производительности активных систем ИБ без изменения общей конфигурации сети.

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


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

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

  • Простота интеграции, надёжность и отказоустойчивость сети

  • Масштабируемость активных средств контроля трафика без усложнения топологии сети

  • Постоянный мониторинг доступности каждого активного устройства ИБ и различные сценарии реагирования на аварии

  • Один Bypass для нескольких активных средств

  • Вариативность пропускания трафика через активные системы ИБ

  • Простота внедрения новых решений в инфраструктуру

Подробнее..

Настраиваем экспорт IPFIX на VMware vSphere Distributed Switch (VDS) и последующий мониторинг трафика в Solarwinds

26.06.2020 08:09:31 | Автор: admin
Привет, Хабр! В начале июля Solarwinds анонсировал релиз новой версии платформы Orion Solarwinds 2020.2. Одно из нововведений в модуле Network Traffic Analyzer (NTA) поддержка распознавания IPFIX-трафика от VMware VDS.



Анализ трафика в среде виртуального коммутатора важен для понимания распределения нагрузки на виртуальную инфраструктуру. Анализируя трафик, можно также обнаружить миграцию виртуальных машин. В этой статье мы расскажем о настройках экспорта IPFIX на стороне виртуального коммутатора VMware и о возможностях Solarwinds по работе с ним. А в конце статьи будет ссылка на онлайн-демо Solarwinds (доступ без регистрации и это не фигура речи). Подробности под катом.

Для корректного распознавания трафика от VDS, сначала нужно настроить подключение через интерфейс vCenter, а уже потом анализ трафика и отображение точек обмена трафиком, получаемого от гипервизоров. При желании, коммутатор может быть настроен на получение всех записей IPFIX с одного IP-адреса, привязанного к VDS, но, в большинстве случаев, более информативно видеть данные, извлекаемые из трафика, полученного от каждого гипервизора. Трафик, который приходит, будет представлять соединения от или к виртуальным машинам, расположенных на гипервизорах.

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

Настройка трафика от VDS


Начнём с добавления экземпляра vCenter в Solarwinds. После этого NTA будет обладать информацией о конфигурации платформы виртуализации.

Перейдите в меню Manage Nodes, далее Settings и выберите Add Node. После этого нужно ввести IP-адрес или полное доменное имя экземпляра vCenter и выбрать VMware, Hyper-V, or Nutanix entities в качестве метода опроса.

image

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

image

В течении некоторого времени будет выполняться начальный опрос экземпляра vCenter, обычно 10-20 минут. Нужно дождаться завершения, а уже потом включить экспорт IPFIX на VDS.

После настройки мониторинга vCenter и получения инвентарных данных по конфигурации платформы виртуализации, включим на коммутаторе экспорт записей IPFIX. Самый быстрый способ сделать это через клиент vSphere. Перейдем на вкладку Networking, выберем VDS и на вкладке Configure найдём текущие настройки для NetFlow. VMware использует термин NetFlow для обозначения экспорта потока, но фактический протокол, который используется IPFIX.

image

Чтобы включить экспорт потока, выберите Settings в меню Actions вверху и перейдите к Edit NetFlow.

image

В этом диалоговом окне введите IP-адрес коллектора, который по совместительству является экземпляром Orion. По умолчанию обычно используется порт 2055. Рекомендуем оставить поле Switch IP Address пустым, что приведет к получению потоковых записей, получаемых именно от гипервизоров. Это даст гибкость при дальнейшей фильтрации потока данных от гипервизоров.

Оставьте поле Process internal flows only отключенным, что позволит видеть все коммуникации: как внутренние, так и внешние.

Как только включите экспорт потока для VDS, нужно будет включить его также и для распределенных порт-групп, от которых хотите получать данные. Самый простой способ сделать это щелкнуть правой кнопкой мыши на панели навигации VDS и выбрать Distributed Port Group, а затем Manage Distributed Port Groups.

image

image

Откроется диалоговое окно, в котором нужно установить флажок Monitoring и нажать Next.

На следующем шаге можете выбрать определённые или все группы портов.

image

На следующем шаге переключите NetFlow на Enabled.

image

Когда на VDS и распределенных порт-группах включен экспорт потока, вы увидите, что записи потоков для гипервизоров начинают поступать в экземпляр NTA.

image

Гипервизоры можно увидеть в списке источников данных потока на странице Manage Flow Sources в NTA. Переключитесь на Nodes.

image

Результаты настройки вы можете увидеть на демо-стенде. Обратите внимание на возможность провалиться на уровень узла, протокола взаимодействия и т.д.



Интеграция с другими модулями Solarwinds в одном интерфейсе, позволяет проводить расследования в различных разрезах: посмотреть какие пользователи входили на виртуальную машину, производительность сервера (посмотреть демо), и приложений на нём, посмотреть связанные сетевые устройства и много чего ещё. Например, если в вашей сетевой инфраструктуре используется протокол NBAR2, Solarwinds NTA может успешно распознавать трафик от Zoom, Teams или Webex.

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

На Хабре у нас также есть статья о бесплатных решениях Solarwinds.

Подписывайтесь на нашу группу в Фейсбуке.
Подробнее..

Категории

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

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