Доброго дня дорогие читатели. В данной статье я бы хотел ознакомить Вас с флагманским решением в области информационной безопасности от компании Cisco.
Речь пойдет о продукте SourceFire Firepower, который представляет собой интегрированную систему защиты от вторжений, межсетевого экранирования нового поколения и защиты от Malware.
Компания SourceFire была приобретена компанией Cisco в октябре 2013 года и на текущий момент ее решения являются лидером по мнению рейтингового агентства Gartner в области систем предотвращения вторжений.
О компании SourceFire
Несколько слов о компании SourceFire. Компания была основана в январе 2001 года в штате Колумбия Мартином Роэшем (Martin Roesch) создателем всемирно известной opensource системы предотвращения вторжений Snort IPS, которая на текущий момент является наиболее широко используемой IPS системой в мире (более 4-х миллионов копий загружено на текущий момент). Кроме Snort компания занимается разработкой таких хорошо известных opensource сообществу продуктов как ClamAV и Razorback. Помимо очень успешных opensource проектов, которыми компания очень гордится, развивается и коммерческий продукт компании под торговой маркой SourceFire, заслуживший свое место лидера в области систем обнаружения и предотвращения вторжений на рынке ИБ по результатам рейтингового агентства Gartner (неизменный лидер последние 6 лет!), независимой лабораторией тестирования NSS Labs и других. За разработку правил обнаружения атак а также их своевременное обновление отвечает отдельная группа экспертов — команда VRT (Vulnerability Research Team). Коммерческая линейка SourceFire представлена двумя продуктами:
SourceFire FirePower – система предотвращения вторжений нового поколения с интегрированными средствами межсетевого экранирования уровня приложений, контентной фильтрацией и защитой от Malware на сетевом уровне.
SourceFire FireAmp – система защиты от Malware угроз на уровне хоста, находящегося под управлением ОС Windows/MAC OSX, Android. Может интегрироваться с системой защиты от Malware на уровне сети – SourceFire FirePower.
Обзор платформ FirePower
Продукт представлен в двух вариантах развертывания: в виде 64-х битного виртуального (VMWare гипервизор) и аппаратных комплексов. Функционал виртуальной платформы не поддерживает функции маршрутизации, коммутации и отказоустойчивости. При этом виртуальный appliance отлично работает в виде Inline бриджа или IDS системы на SPAN порту.
Выпускается большое количество аппаратных моделей с разной производительностью, модульными интерфейсными картами, функциями стекирования и кластеризации. Производительность моделей начинается с младших линеек — 50 Мб/сек, заканчивая решениями класса крупных ЦОД — 60 Гбит/сек (Рис. 1).
Рис. 1
Производительность виртуальной модели составляет 100-150 Мбит/сек на ядро.
Модели серии 7000/7100 имеют фиксированные на борту порты типа RJ45/SFP, в зависимости от конкретной модели.
Модели серии 8100 имеют модульные интерфейсные карты с поддерживаемыми типами интерфейсов 1 Гбит/сек медь/оптика и 10 Гбит/сек оптика MM-SR и SM-LR. Модели 8200 и 8300 серии вдобавок поддерживают оптические интерфейсы 40 Гбит/сек MM-SR. Большинство интерфейсных модулей имеют возможность настройки hardware байпаса (в том числе оптического) на случай возникновения отказа в работе устройства.
Старший модельный ряд комплексов FirePower 8200/8300 поддерживают функцию гибкого наращивания производительности по средствам стекирования. Например Вы можете приобрести сенсор 8350 с производительностью IPS 15 Гбит/сек (производительность платформы 30 Гбит/сек) и в момент, когда нужно будет поднять производительность системы, просто докупить еще один 8350, стекировать их и получить производительность 30 Гбит/сек IPS и таким образом можно соединить в стек до 4-х устройств с производительностью IPS до 60 Гбит/сек.
Функции отказоустойчивости реализованы посредством кластеризации комплексов в связку Active/Standby с синхронизацией статусов сессий.
Аппаратные решения FirePower построены на RISC архитектуре, оптимизированный код и мощная вычислительная платформа со специализированными сетевыми процессорами делает возможным достижение и превышение производительности, заявленной производителем. Заявленные характеристики производительности — это реальные цифры производительности, которые получит заказчик при тяжелых нагрузочных испытаниях при полностью включенном функционале. Данный факт подтверждается ежегодными тестированиями NSS Labs.
Система управления Defense Center
FirePower построена с использованием централизованной системы управления – Defense Center. Локально на самих комплексах FirePower доступны только первоначальные настройки, которые позволяют подключить устройство в сеть и настроить связь с центром управления. Все дальнейшие настройки, репортинг и мониторинг производятся централизованно в консоли администратора Defense Center.
Defense Center представлен как в виде аппаратных платформ (см Рис. 2) с максимальным количеством подключаемых сенсоров – 150 штук, так и в виде виртуальной машины под гипервизор VMWare с максимальным количеством сенсоров – 25 штук.
Рис. 2
Система управления в ее аппаратном исполнении имеет функции отказоустойчивости для моделей DC1500 и DC3500.
Доступные топологии развертывания
Для виртуального сенсора доступны конфигурации как Inline размещения (см Рис. 3) с инспекцией и фильтрацией активного трафика, так и размещение в режиме IDS на копии трафика (SPAN) (см Рис. 4).
Рис. 3
Рис. 4
В случае использования аппаратной платформы нам становятся доступны более сложные топологии, поскольку аппаратные комплексы поддерживают функции коммутации на аппаратном уровне с поддержкой Spanning Tree Protocol (STP) и имеют функции маршрутизации с использованием протоколов OSPF и RIP.
Платформа позволяет строить гибридные топологии (см. Рис. 5).
Рис. 5
Для правильной обработки движком IPS ассиметричного потока трафика в сети заказчика, вводится понятие Inline Set, пример такой конфигурации см. Рис. 6.
Рис. 6
Не будем забывать о том, что многие интерфейсные карты дают возможность настраивать bypass в случае перезагрузки или сбоя на платформе, таким образом, позволяя избежать прерывания работы сервисов в сети.
Функциональный обзор
FireSight
“Нельзя защищать то, чего не знаешь” – это один из слоганов компании SourceFire и с этим тяжело не согласиться. Имея огромные корпоративные сети в управлении, службе ИБ все сложнее отслеживать появление новых уязвимостей на ресурсах компании как то:
- Новые патчи в клиентских приложениях, несущие новые уязвимости;
- Бесконтрольная установка приложений пользователями;
- Возможность принести свое устройство в сеть и его бесконтрольное подключение;
- Выход и установка обновлений операционных систем, лечащие старые уязвимости и открывающие новые;
- Появление новых сегментов сети с новыми типами операционных систем, таких как например оборудование АСУТП и т.д.;
За всеми этими и другими изменениями с ростом сети становится все сложнее следить и с каждым днем процесс отслеживания инцидентов и реакция на них занимает все больше времени, а эффективность борьбы с реальными угрозами снижается. Хорошо если проводится периодическое активное сканирование на уязвимости командой ИБ, но ведь помимо проведения сканирования нужно блокировать возможность использования обнаруженных уязвимостей на стороне системы предотвращения вторжений. К сожалению практика показывает, что подавляющее большинство администраторов не имеет возможности производить тюнинг сигнатурного набора IPS настолько часто как этого требует изменяющаяся сеть. Ведь оценить уровень возможной реализации атаки на цель можно лишь понимая уязвима ли цель к данной атаке, а для этого надо знать:
- какой сервис подвержен атаке;
- какая версия операционной системы установлена на атакуемом хосте и версия её патча;
- какая версия патча для атакуемого сервиса используется;
- список известных уязвимостей для вышеперечисленных опций и т.д.;
А что если за атакуемым хостом может сидеть и сам CIO?! Зная все эти и многие другие характеристики объектов атаки или возможных объектов атаки, можно более эффективно фильтровать неопасные атаки и блокировать с необходимой эскалацией действительно опасные вторжения.
SourceFire принципиально отличается от конкурирующих решений в том числе и подходом к анализу характерных уязвимостей в защищаемой сети с возможностью автоматической подстройки сигнатурного набора! Технология под брендовым названием FireSight позволяет визуализировать сеть и получить видимость (см Рис. 7):
- актуальных хостов/систем;
- операционных систем с версиями и патчами на хостах;
- клиентским ПО и его версиями;
- пользователей, находящихся за хостами;
- свойственными уязвимостями;
- обмена данными между хостами в пассивном режиме;
Рис. 7
Сенсор анализирует активно проходящий через него трафик или трафик из SPAN сессии, заглядывает в заголовки трафика вплоть до уровня приложений и на основании собранных данных строит “карту” защищаемой сети со всеми характерными ей уязвимостями. Эта карта обновляется в режиме реального времени. Настройки позволяют комплексу активировать/деактивировать сигнатуры в активных сигнатурных наборах, отвечающие обнаруживаемым уязвимостям в сети. Тестирование NSS Labs 2014 года Datacenter IPS приводит эффективность блокирования атак 99,4%, и 100% защиты от техник обхода обнаружения атак (evasion techniques).
Помимо пассивно анализируемого трафика, решение поддерживает выгрузку в него результатов активного сканирования например из Nessus.
Как пример, собираемой информации, приведу профиль одного из хостов (см. Рис. 8,9,10,11).
Рис. 8
Список приложений на хосте:
Рис. 9
Список уязвимостей на хосте:
Рис. 10
Пример описания одной из выявленных уязвимостей c ссылками на патчи:
Рис. 11
Пример рекомендуемых изменений к сигнатурному набору по результатам аналитики уязвимостей и систем во внутренней сети изображен на Рисунке 12.
Рис. 12
Next-Generation Firewall (NGFW)
Межсетевой экран нового поколения, как теперь принято называть, контентный МСЭ уровня приложений реализован в SourceFire FirePower и использует сигнатуры определения типов приложений, предоставляемых движком системы обнаружения вторжений. NGFW призван осуществлять фильтрацию не просто на уровне портов и протоколов, как это классически реализуется в МСЭ с отслеживанием статуса соединения (statefull inspection), а на уровне протоколов уровня приложений и функций самих приложений, таким образом заглядывая вглубь транзакций и останавливая, например, такие активности как пересылка файла через Skype или доступ к функции игр в Facebook (см. Рис 13,14). Заметим, к примеру, что Facebook и Google работают через протокол 7-го уровня модели OSI – HTTP. Однако эти “порталы” предоставляют огромное количество функции в виде web-приложений, которые невозможно контролировать посредством классических МСЭ.
Политика доступа NGFW:
Рис. 13
Пример правила блокировки Skype File Transfer:
Рис. 14
Как видно из рисунка 13, мы формируем нашу политику фильтрации приложений и политику обнаружения вторжений в политике доступа. Каждая строка политики доступа работает как запись списка доступа (Access Control List), регламентирующая правило доступа с соответствующими условиями.
Условия ACL могут быть следующих типов:
- Зоны, между которыми будет производиться фильтрация, это логические зоны, к которым может принадлежать тот или иной интерфейс устройства;
- Сети, между которыми будет фильтроваться трафик;
- VLAN, между которыми фильтруется трафик;
- Пользователи AD, трафик которых хотим фильтровать;
- Приложения, доступ к которым хотим ограничить/разрешить;
- Порты tcp/udp, обращения с/на которые будем фильтровать;
- URL, разбитые по категориям и репутации;
Все эти условия могут одновременно фигурировать в одном правиле и будут использованы как логическое И (AND).
После каждого ACL можно видеть три иконки (см. Рис. 15), которые означают ассоциированные политики слева направо:
- Политика предотвращения вторжений;
- Политика файловой фильтрации и защиты от Malware;
- Политика логирования;
Рис. 15
Если в Вашей сети присутствуют приложения собственной разработки и они отсутствую в базе приложений для фильтрации, Вы можете с легкостью добавить свое собственное приложение в базу приложений. Импортируйте соответствующий Pattern ASCII/HEX для поиска, либо загрузите пример сетевой активности приложения из PCAP файла.
Рис. 16
К каждой политике доступа, которых может быть множество, можно назначить политику фильтрации Security Intelligence (Рис. 17). Данная политика содержит постоянно обновляемые списки IP адресов спаммеров, C&C центров ботнетов, открытых proxy и т.д. Вы можете выбирать из имеющихся списков, либо загрузить свои собственные списки фильтрации из файла, либо указать системе URL, откуда эти списки забирать.
Рис. 17
FireAMP защита от Malware
Решения FirePower предоставляют защиту от Malware на уровне сети. Система анализирует проходящие через устройство файлы указанных в файловой политике (Рис. 18) форматах и передаваемых посредством указанных типов протоколов. Об особенностях решения по защите от Malware можно прочитать в статье Алексея Лукацкого (alukatsky).
Рис. 18
Принцип работы защиты от Malware следующий. С пересылаемого через устройство файла снимается хэш SHA-256 и отправляется на Defense Center, который в свою очередь производит запрос (Cloud Lookup) в облаке SourceFire, выясняя диспозицию данного файла (является ли файл чистым, либо Malware) по имеющейся в облаке базе известного Malware. Для заказчиков, которые не хотят отсылать какие-либо данные в облако, сервер с базой Malware можно развернуть непосредственно в корпоративной сети, данная конфигурация называется Private Cloud.
В случае, если по результатам снятия хэша и запроса в базу не удается установить диспозицию файла, файл может быть отправлен устройством в облачную “песочницу”, где будет проанализировано поведение файла, его выживаемость после перезагрузки, генерируемый сетевой трафик, тестирование на запуск в виртуальной среде, создаваемые процессы, файлы, записи реестра и техники скрытия процессов, попытки самовоспроизведения и так далее. По результатам этого тестирования подсчитываются индексы вредоносного поведения, небольшой отрывок отчета изображен на рисунке 19.
Рис. 19
В случае, если файл является исполняемым (executable), FirePower снимает более 400 переменных c файла (ссылки на подключаемые библиотеки, имена библиотек, используемые иконки, переменные окружения, настройки компилятора и т.д.) для анализа движком Spero по алгоритму нечетких отпечатков (Fuzzy fingerprinting). Алгоритм, обращаясь к логическим самообучающимся деревьям признаков и поведения различного рода Malware, расположенным в облаке SourceFire, получает решение о диспозиции файла.
Очень важное отличие от классических систем антивирусной защиты состоит в том, что классические системы работают в определенной точке времени. Например к файлу происходит обращение на исполнение (execution), он проверяется по сигнатурной базе и/или песочнице и о нем забывают после заключения о его чистоте/зараженности. Однако не стоит забывать, что ежедневно в современном мире появляется более 65000 (статистика SourceFire) экземпляров нового Malware, для которых еще нет сигнатур. Malware может использовать техники задержки запуска во избежание обнаружения в “песочницах”. Ввиду вышеизложенных доводов, Malware может пройти мимо сетевого антивируса и осесть на оконечных узлах, где по прошествии времени начнется распространение и работа Malware. Со стороны антивируса при этом не останется никаких записей о прошедшем файле, времени его появления и источнике. По статистике до 30% неизвестного Malware несут с собой и загружают до 70% известного Malware и наоборот.
Система FireAMP предоставляет новый подход с ретроспективным анализом, при котором запоминаются все пути распространения файлов и их атрибуты. В случае решения FireAMP хостового базирования запоминаются все связанные активности процессов, сетевые активности, все I/O операции на локальном хосте. И когда через, допустим, 4 дня окажется, что загруженный файл являлся ранее неизвестным Malware, из облака SourceFire будет получено уведомление и файл будет централизованно заблокирован как на уровне сети, так и на уровне всех зараженных Endpoint систем. Более того, система покажет путь распространения файла как по сети, так и в системе хоста, все загруженные файлом дополнительные компоненты и Malware программы, обращения к процессам и родительский процесс, который дал возможность заразиться и дать начало распространению угрозы.
Пример обнаружения Malware на уровне сети, рисунок 20a, 21
Рис. 20а
Рис. 20б
В частности, на рисунке 21 можно увидеть путь попадания и дальнейшего распространения файла по сети, пораженные хосты, момент заражения, использованные порты и протоколы.
На рисунке 20б можно видеть более детальную информацию о распространении и методе попадании угрозы непосредственно на хост со всеми ассоциированными I/O операциями.
Рис. 21
Функция Compliance Whitelist
Отдельно хочется отметить полезную функцию белого списка систем в сети. Поскольку FirePower в режиме реального времени пассивно может видеть активность пользователей и приложений в сети, система дает возможность выстраивать профили Compliant систем. Таким образом, можно указать какие операционные системы с какими патчами, клиентскими программами и приложениями в них мы хотим видеть в нашей сети. В случае отклонения от шаблона можно уведомить администратора и использовать методы корреляции (смотри следующую главу), включая исполнение своих собственных скриптов и команд, проводить действия по карантину/исправлению проблем.
Следует отметить, что FirePower предоставляет возможность создавать и назначать хостам различного типа атрибуты и выставлять атрибуты как результат действия корреляции. Можно использовать атрибуты при формировании автоматических уведомлений в том числе для повышения уровня критичности атаки и многое другое. Например, повысить уровень критичности атаки при ее обнаружении в направлении хоста со значением базового атрибута — non-compliant.
Создаваемые атрибуты могут быть следующих типов:
- INTEGER
- TEXT
- LIST
- URL
По-умолчанию каждый WhiteList имеет только один атрибут, который принимает значение:
- Compliant
- Non-Compliant
- Not Evaluated
Каждый хост будет иметь назначенный на него атрибут WhiteList со значением этого атрибута из вышеуказанного списка.
Пример создания WhiteList можно посмотреть на рисунке 22. Вы выбираете разрешенные типы и версии операционных систем, в каждой операционной системе выбираете разрешенные клиентские приложения, веб-приложения и разрешенные протоколы транспортного и сетевого уровней.
Рис. 22
Профили трафика
Как Вы можете помнить, технология FireSight отслеживает и параметры соединений, устанавливаемых хостами в сети. На основании собираемых статистических данных, а собирается по меньшей мере 29 параметров соединения, выстраивается так называемый базовый профиль соединений для каждого хоста. В конфигурации можно устанавливать какие конкретно типы соединений или трафик приложений будет профилироваться и на какой срок выстраивать базовый профиль (Пример Рис. 23).
Рис. 23
Пример на рисунке 23 показывает, что можно как базово строить профили на основании всего передаваемого трафика, так и более тонко выделять необходимые потоки.
Корреляция событий
Очень мощная функция по отслеживанию, эскалации и реагированию на события заложена в систему – это функция корреляции. Особенно эта функция понравится энтузиастам и профессионалам ИБ.
Фактически данная функция предоставляет возможность по событию выставлять наборы условий с логическими их связками для генерации реактивного воздействия (пример корреляционного условия смотри на рисунке 24).
Рис. 24
В результате применения вышеуказанного условия корреляции будет событие вторжения:
- адресованное уязвимой платформе (Impact 1);
- по правилам сигнатур не заблокированное;
- направленное на платформу Anroid или IPhone с Jailbrake;
- принадлежащему пользователю из департамента Executives (в Active Directory);
В виде небольшого примера, условия корреляции можно создавать на следующие типы событий (см Рис. 25, 26):
- Событие безопасности (alert);
- Событие обнаружения (discovery);
- Событие пользовательской активности (user activity);
- Профиль хоста изменился или добавилась уязвимость (host input) (пример событий Рис. 26);
- Установлено соединение (connection);
- Изменился профиль трафика (traffic profile);
- Обнаружение вредоносного ПО (Malware event);
Рис. 25
Рис. 26
Мы рассмотрели возможность задания корреляционных условий, а теперь посмотрим как мы можем реагировать на выполнение этих условий.
Результатом выполнения правила корреляции может быть одно или несколько действий, такие как:
- запуск сканирования NMAP с заданными параметрами на источник/направление атаки;
- блокировка атакующего на маршрутизаторе Cisco (RTBH);
- отсылка SHUN блокировки на МСЭ Cisco ASA;
- установка необходимого атрибута на хост;
- уведомление администратора посредством Email/SNMP/Syslog;
- выполнение самописной программы, написанной на C/BASH/TCSH/PERL с возможностью передачи переменных из события.
Рис. 27
Система мониторинга и отчетности
Система управления Defense Center дает очень наглядную статистическую информацию по системе в целом, так и возможность углубиться в детали обнаруживаемых активностей из любого графика.
Для ознакомления администратора с текущей картиной использования сервисов сети, приложений, операционных систем, анализ релевантности активностей к бизнес процессам и рискам доступен первичный экран обзора Summary Dashboard (см. Рис. 28).
Рис. 28
Для начала анализа проходивших инцидентов информационной безопасности можно перейти на вкладку Intrusion Events и увидеть агрегированную информацию по обнаруженным и заблокированным атакам, статистике и перейти к детальному рассмотрению каждого интересующего события в отдельности (см Рис. 29).
Рис. 29
Каждый инцидент можно детально изучить, включая содержимое пакета, который вызвал срабатывание сигнатуры см. Рис. 30. Из информационного окна о событии можно видеть текст сработавшей сигнатуры, сигнатуры атак написаны на языке SNORT, который де-факто уже стал для многих администраторов ИБ стандартом написания правил IPS. В этом же окне можно произвести тюнинг сигнатуры, настроить фильтрацию и суммаризацию событий, изменить действие, сопряженное с обнаружением данной активности.
Рис. 30
Помимо информации об атаках, Вы можете анализировать и фильтровать интересующую информацию, получаемую системой о сети в целом. Для получения общей информации о сети, либо при необходимости о конкретных ее сегментах существует интерфейс Context Explorer (см. Рис. 31).
Рис. 31
На рисунке 31 можно видеть статистическую информацию:
- корелляцию данных базы Security Intelligence, событий безопасности, траффика и событий Malware для оценки возможных угроз внутри сети;
- активность конкретных пользователей и их приложений, детализация по уровню рисков приложений;
- используемым внутри сети операционным системам и активности информационного обмена;
- оценка событий безопасности по уровню воздействия и уровню приоритета;
- статистику обнаружения активности malware и передачи зараженных файлов;
- геолокационную характеристику хостов, распространяющих malware, реализующих враждебную активность и наиболее интенсивный информационный обмен;
- статистику наиболее часто посещаемых категорий сайтов, в том числе по репутации и самых посещаемых URL;
Система предоставляет возможность формировать свои собственные отчеты как по заранее сформированным шаблонам, так и создавать шаблоны самостоятельно. Для изготовления собственных шаблонов отчетов имеется целый Wizard (см Рис. 32), который позволяет включать различные типы графических объектов статистики, табличные данные и непосредственно содержимое пакетов с подозрительной активностью. С целью более гибкого формирования отчетов есть возможность задавать собственные переменные для подстановки их в шаблон при генерации отчета. Отчеты могут формироваться по расписанию и рассылаться ответственным лицам.
Рис. 32
Заключение
В заключении хочется отметить, что рассмотренная в статье комплексная система защиты сети от атак, управления политиками приложений и борьбы с распространением Malware на базе продуктов приобретенной компании SourceFire органично дополняют и усиливают портфолио компании Cisco в области продуктов информационной безопасности. Мы выделяем данный класс решений как перспективные и будем их активно развивать. Компания выделяет крупные инвестиции в развитие технологической ветки решений по информационной безопасности, которая несомненно является для компании одной из стратегических. В ближайшее время мы ожидаем все более тесной интеграции технологий SourceFire с классическими архитектурными решениями Cisco и продуктовыми решениями компании. Отдельно хочется развеять опасения коллег по индустрии относительно развития бесплатных opensource продуктов от компании SourceFire, все opensource инициативы будут сохранены и их ждет дальнейшее активное развитие.
Автор: dkazakov
