Cisco – мировой лидер в области сетевых технологий
72,42
рейтинг
9 июля 2014 в 11:05

Разработка → Обзор межсетевого экрана и системы предотвращения вторжений нового поколения SourceFire FirePower

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

Речь пойдет о продукте SourceFire Firepower, который представляет собой интегрированную систему защиты от вторжений, межсетевого экранирования нового поколения и защиты от Malware.

Компания SourceFire была приобретена компанией Cisco в октябре 2013 года и на текущий момент ее решения являются лидером по мнению рейтингового агентства Gartner в области систем предотвращения вторжений.

image

О компании 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).

image

Рис. 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 штук.

image

Рис. 2

Система управления в ее аппаратном исполнении имеет функции отказоустойчивости для моделей DC1500 и DC3500.

Доступные топологии развертывания

Для виртуального сенсора доступны конфигурации как Inline размещения (см Рис. 3) с инспекцией и фильтрацией активного трафика, так и размещение в режиме IDS на копии трафика (SPAN) (см Рис. 4).

image

Рис. 3

image

Рис. 4

В случае использования аппаратной платформы нам становятся доступны более сложные топологии, поскольку аппаратные комплексы поддерживают функции коммутации на аппаратном уровне с поддержкой Spanning Tree Protocol (STP) и имеют функции маршрутизации с использованием протоколов OSPF и RIP.

Платформа позволяет строить гибридные топологии (см. Рис. 5).

image

Рис. 5

Для правильной обработки движком IPS ассиметричного потока трафика в сети заказчика, вводится понятие Inline Set, пример такой конфигурации см. Рис. 6.

image

Рис. 6

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

Функциональный обзор

FireSight

Нельзя защищать то, чего не знаешь” – это один из слоганов компании SourceFire и с этим тяжело не согласиться. Имея огромные корпоративные сети в управлении, службе ИБ все сложнее отслеживать появление новых уязвимостей на ресурсах компании как то:

  • Новые патчи в клиентских приложениях, несущие новые уязвимости;
  • Бесконтрольная установка приложений пользователями;
  • Возможность принести свое устройство в сеть и его бесконтрольное подключение;
  • Выход и установка обновлений операционных систем, лечащие старые уязвимости и открывающие новые;
  • Появление новых сегментов сети с новыми типами операционных систем, таких как например оборудование АСУТП и т.д.;

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

  • какой сервис подвержен атаке;
  • какая версия операционной системы установлена на атакуемом хосте и версия её патча;
  • какая версия патча для атакуемого сервиса используется;
  • список известных уязвимостей для вышеперечисленных опций и т.д.;

А что если за атакуемым хостом может сидеть и сам CIO?! Зная все эти и многие другие характеристики объектов атаки или возможных объектов атаки, можно более эффективно фильтровать неопасные атаки и блокировать с необходимой эскалацией действительно опасные вторжения.

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

  • актуальных хостов/систем;
  • операционных систем с версиями и патчами на хостах;
  • клиентским ПО и его версиями;
  • пользователей, находящихся за хостами;
  • свойственными уязвимостями;
  • обмена данными между хостами в пассивном режиме;

image

Рис. 7

Сенсор анализирует активно проходящий через него трафик или трафик из SPAN сессии, заглядывает в заголовки трафика вплоть до уровня приложений и на основании собранных данных строит “карту” защищаемой сети со всеми характерными ей уязвимостями. Эта карта обновляется в режиме реального времени. Настройки позволяют комплексу активировать/деактивировать сигнатуры в активных сигнатурных наборах, отвечающие обнаруживаемым уязвимостям в сети. Тестирование NSS Labs 2014 года Datacenter IPS приводит эффективность блокирования атак 99,4%, и 100% защиты от техник обхода обнаружения атак (evasion techniques).

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

Как пример, собираемой информации, приведу профиль одного из хостов (см. Рис. 8,9,10,11).

image

Рис. 8

Список приложений на хосте:

image

Рис. 9

Список уязвимостей на хосте:

image

Рис. 10

Пример описания одной из выявленных уязвимостей c ссылками на патчи:

image

Рис. 11

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

image

Рис. 12

Next-Generation Firewall (NGFW)

Межсетевой экран нового поколения, как теперь принято называть, контентный МСЭ уровня приложений реализован в SourceFire FirePower и использует сигнатуры определения типов приложений, предоставляемых движком системы обнаружения вторжений. NGFW призван осуществлять фильтрацию не просто на уровне портов и протоколов, как это классически реализуется в МСЭ с отслеживанием статуса соединения (statefull inspection), а на уровне протоколов уровня приложений и функций самих приложений, таким образом заглядывая вглубь транзакций и останавливая, например, такие активности как пересылка файла через Skype или доступ к функции игр в Facebook (см. Рис 13,14). Заметим, к примеру, что Facebook и Google работают через протокол 7-го уровня модели OSI – HTTP. Однако эти “порталы” предоставляют огромное количество функции в виде web-приложений, которые невозможно контролировать посредством классических МСЭ.

Политика доступа NGFW:

image

Рис. 13

Пример правила блокировки Skype File Transfer:

image

Рис. 14

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

Условия ACL могут быть следующих типов:

  • Зоны, между которыми будет производиться фильтрация, это логические зоны, к которым может принадлежать тот или иной интерфейс устройства;
  • Сети, между которыми будет фильтроваться трафик;
  • VLAN, между которыми фильтруется трафик;
  • Пользователи AD, трафик которых хотим фильтровать;
  • Приложения, доступ к которым хотим ограничить/разрешить;
  • Порты tcp/udp, обращения с/на которые будем фильтровать;
  • URL, разбитые по категориям и репутации;

Все эти условия могут одновременно фигурировать в одном правиле и будут использованы как логическое И (AND).

После каждого ACL можно видеть три иконки (см. Рис. 15), которые означают ассоциированные политики слева направо:

  • Политика предотвращения вторжений;
  • Политика файловой фильтрации и защиты от Malware;
  • Политика логирования;

image

Рис. 15

Если в Вашей сети присутствуют приложения собственной разработки и они отсутствую в базе приложений для фильтрации, Вы можете с легкостью добавить свое собственное приложение в базу приложений. Импортируйте соответствующий Pattern ASCII/HEX для поиска, либо загрузите пример сетевой активности приложения из PCAP файла.

image

Рис. 16

К каждой политике доступа, которых может быть множество, можно назначить политику фильтрации Security Intelligence (Рис. 17). Данная политика содержит постоянно обновляемые списки IP адресов спаммеров, C&C центров ботнетов, открытых proxy и т.д. Вы можете выбирать из имеющихся списков, либо загрузить свои собственные списки фильтрации из файла, либо указать системе URL, откуда эти списки забирать.

image

Рис. 17

FireAMP защита от Malware

Решения FirePower предоставляют защиту от Malware на уровне сети. Система анализирует проходящие через устройство файлы указанных в файловой политике (Рис. 18) форматах и передаваемых посредством указанных типов протоколов. Об особенностях решения по защите от Malware можно прочитать в статье Алексея Лукацкого (alukatsky).

image

Рис. 18

Принцип работы защиты от Malware следующий. С пересылаемого через устройство файла снимается хэш SHA-256 и отправляется на Defense Center, который в свою очередь производит запрос (Cloud Lookup) в облаке SourceFire, выясняя диспозицию данного файла (является ли файл чистым, либо Malware) по имеющейся в облаке базе известного Malware. Для заказчиков, которые не хотят отсылать какие-либо данные в облако, сервер с базой Malware можно развернуть непосредственно в корпоративной сети, данная конфигурация называется Private Cloud.

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

image

Рис. 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

image

Рис. 20а

image

Рис. 20б

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

На рисунке 20б можно видеть более детальную информацию о распространении и методе попадании угрозы непосредственно на хост со всеми ассоциированными I/O операциями.

image

Рис. 21

Функция Compliance Whitelist

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

Следует отметить, что FirePower предоставляет возможность создавать и назначать хостам различного типа атрибуты и выставлять атрибуты как результат действия корреляции. Можно использовать атрибуты при формировании автоматических уведомлений в том числе для повышения уровня критичности атаки и многое другое. Например, повысить уровень критичности атаки при ее обнаружении в направлении хоста со значением базового атрибута — non-compliant.

Создаваемые атрибуты могут быть следующих типов:

  • INTEGER
  • TEXT
  • LIST
  • URL

По-умолчанию каждый WhiteList имеет только один атрибут, который принимает значение:

  • Compliant
  • Non-Compliant
  • Not Evaluated

Каждый хост будет иметь назначенный на него атрибут WhiteList со значением этого атрибута из вышеуказанного списка.

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

image

Рис. 22

Профили трафика

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

image

Рис. 23

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

Корреляция событий

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

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

image

Рис. 24

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

  • адресованное уязвимой платформе (Impact 1);
  • по правилам сигнатур не заблокированное;
  • направленное на платформу Anroid или IPhone с Jailbrake;
  • принадлежащему пользователю из департамента Executives (в Active Directory);

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

  • Событие безопасности (alert);
  • Событие обнаружения (discovery);
  • Событие пользовательской активности (user activity);
  • Профиль хоста изменился или добавилась уязвимость (host input) (пример событий Рис. 26);
  • Установлено соединение (connection);
  • Изменился профиль трафика (traffic profile);
  • Обнаружение вредоносного ПО (Malware event);

image

Рис. 25

image

Рис. 26

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

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

  • запуск сканирования NMAP с заданными параметрами на источник/направление атаки;
  • блокировка атакующего на маршрутизаторе Cisco (RTBH);
  • отсылка SHUN блокировки на МСЭ Cisco ASA;
  • установка необходимого атрибута на хост;
  • уведомление администратора посредством Email/SNMP/Syslog;
  • выполнение самописной программы, написанной на C/BASH/TCSH/PERL с возможностью передачи переменных из события.

image

Рис. 27

Система мониторинга и отчетности

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

Для ознакомления администратора с текущей картиной использования сервисов сети, приложений, операционных систем, анализ релевантности активностей к бизнес процессам и рискам доступен первичный экран обзора Summary Dashboard (см. Рис. 28).

image

Рис. 28

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

image

Рис. 29

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

image
image
image

Рис. 30

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

image
image
image
image
image
image
image

Рис. 31

На рисунке 31 можно видеть статистическую информацию:

  • корелляцию данных базы Security Intelligence, событий безопасности, траффика и событий Malware для оценки возможных угроз внутри сети;
  • активность конкретных пользователей и их приложений, детализация по уровню рисков приложений;
  • используемым внутри сети операционным системам и активности информационного обмена;
  • оценка событий безопасности по уровню воздействия и уровню приоритета;
  • статистику обнаружения активности malware и передачи зараженных файлов;
  • геолокационную характеристику хостов, распространяющих malware, реализующих враждебную активность и наиболее интенсивный информационный обмен;
  • статистику наиболее часто посещаемых категорий сайтов, в том числе по репутации и самых посещаемых URL;

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

image

Рис. 32

Заключение

В заключении хочется отметить, что рассмотренная в статье комплексная система защиты сети от атак, управления политиками приложений и борьбы с распространением Malware на базе продуктов приобретенной компании SourceFire органично дополняют и усиливают портфолио компании Cisco в области продуктов информационной безопасности. Мы выделяем данный класс решений как перспективные и будем их активно развивать. Компания выделяет крупные инвестиции в развитие технологической ветки решений по информационной безопасности, которая несомненно является для компании одной из стратегических. В ближайшее время мы ожидаем все более тесной интеграции технологий SourceFire с классическими архитектурными решениями Cisco и продуктовыми решениями компании. Отдельно хочется развеять опасения коллег по индустрии относительно развития бесплатных opensource продуктов от компании SourceFire, все opensource инициативы будут сохранены и их ждет дальнейшее активное развитие.
Автор: @dkazakov
Cisco
рейтинг 72,42
Cisco – мировой лидер в области сетевых технологий

Комментарии (45)

  • +1
    А где кат?
    • 0
      а мне показалось, что кат есть, но слишком уж глубоко
      • 0
        Он есть. Сразу после Рис. 24. Посмотрел только что запись полуфинала с эпичной игрой бразильцев. Так что такому фортелю даже не удивился.
  • +1
    Быстрее прячьте все под кат :)
  • 0
    Под кат статью, только 2-3 абзаца анонса, а не половину статьи! зачем такая простыня на главной?
  • 0
    Прошу прощенья, поправку ката сделал.
  • 0
    Когда будете публиковать EOL для всей линейки ASA? У меня давно было ощущение, что эту платформу планомерно убивают. По VPN функционалу она далеко отстала от ASR1k/ISR, оставался функционал NGFW, но тут появляется явно более совершенный FirePower. Существование ASA полностью теряет смысл.
    • 0
      EOL? Не слышали)
      Это самый широко распространённый в мире межсетевой экран, основа нашего бизнеса по безопасности и передо мной детальный план развития на два года.
      А с августа *пшшш, по секрету* мы сможем запускать Sourcefire на любой ASA с приставкой Х и SSD-диском
      • 0
        Ура! ASA из убогой хреновины с не очень понятным назначением превратится во что-то приличное!

        Скажите, а в том плане говорится что-то о приведении конфигурации NAT в поддающийся хоть какому-то сопровождению вид? Или это будет сделано в рамках интеграции SF? Подразумевает ли «запускать Sourcefire» замену родной ОС, или это параллельный функционал?
        • 0
          Наверное процесс конфигурации NAT на ASA это как «фломастеры на вкус и цвет все разные», я настраивал NAT еще на 6-ке PIX и за последние лет 7 какие только сложные конфигурации натирования мне не приходилось делать. Если честно, на мой взгляд, на ASA самая гибкая система натирования и эта функция очень продвинутая. С точки зрения настроек, да, пожалуй надо привыкнуть, но как и любая профессиональная система ASA требует сноровки и внимательного чтения мана.
          • 0
            Если честно, на мой взгляд, на ASA самая гибкая система натирования и эта функция очень продвинутая.

            Тут не поспоришь — гибче некуда. Неудобнее в работе — тоже. Вероятно, каждый, кто сталкивается с функционалом NAT на асе, периодически чертыхается на строчки в логах со словом «asymmetric». То, что наворотили в 8.3+, еще более монструозно. А уж всякие прикольные вещи вроде удаления записи policy NAT, если в его ACL нечаянно добавили строчку с «permit tcp»…

            Но да, фломастеры разные. Вот только я знаю многих работающих с натом на асашках, и никому из них это не нравится.
            • 0
              До 8.3 на мой взгляд было удобнее малость, но, вероятно, мое отношение может быть связано с тем что я учился работать с классической схемой NAT на ASA начиная с версии 7.0 и порядком к ней привык (переучиваться то не всякий любит=) ). С ассиметрией я особых проблем не вижу, как только в логе видишь эту надпись, сразу знаешь где поправить.
              • 0
                С ассиметрией я особых проблем не вижу, как только в логе видишь эту надпись, сразу знаешь где поправить.

                Ситуация печальна тем, что обычно получаешь заявку, настраиваешь, говоришь «настроено», а у людей ничего не работает. Ситуация обычно не критичная, но неприятная. Но куда хуже, когда кусок NAT просто сдувает из конфигурации из-за маленькой ошибки, а потом заводят и тут же закрывают enhancement request, мол «так и надо».

                Да, я тоже помню тот ужас, который представляли собой пиксы 6-7 версий. Еще даже без поддержки кнопки Tab. У меня где-то по сети несколько 501-х машинок даже разбросаны. Годами работают в одиночестве, ssh сервис зарастает паутиной…
                • 0
                  Со сдуванием настроек ната у меня лично не было случаев, но я и не писал permit tcp, вспоминается демотиватор «процесс перевода кейса из разряда as designed, not a bug в состояние Pending». Это уже привычка вырабатывается писать permit IP, также как и логика работы route-map с acl.
                  • 0
                    Причиной может быть копипаст куска обычного ACL, когда забыли поправить TCP на IP. Лично я так не делал, но был свидетелем подобной аварии. И где-то в блогосфере было много статей с матами на эту тему. Если вводишь некорректную строчку в ACL, правильным поведением системы было бы отбросить эту строчку. А ASA применяет ее, внезапно обнаруживает некорректность всего ACL и удаляет то, к чему он привязан. Раньше было поведение «удалить весь ACL», это на каком-то этапе заменили на более мягкое «удалить конфигурацию NAT, опирающуюся на ACL». Волшебно. Логика людей из BU какая-то инопланетная.
                    • 0
                      Людей из BU порой непросто понять ;)
    • 0
      Линейка ASA очень бурно развивается, посмотрите на тот функционал что был добавлен начиная с версии 9.0 и 9.2.1, кластеризация, микшированные контексты, BGP, интеграция в архитектуру TrustSec и оочень много всего другого, я боюсь что именно VPN в виде GETVPN/DMVPN этот как раз и есть то отличие, которое на маршрутизаторах впереди. Но возьмем мобильный VPN посредством ANYCONNECT, полноценная его работа со всеми функциями и теперь уже COA (Change of Authorization) есть только на ASA. По многим функциям у ASA и конкурентов то нет, так что платформа цветет и развивается семимильными шагами.
      • –1
        Ну положим из реально сильных мест можно упомянуть только Trustsec. Anyconnect плох по сравнению с аналогичными решениями многих конкурентов (хоть того же F5), разве что есть дружба с ISE (у конкурентов свои механизмы). Кластеризация — забавная штука, но ИМХО потребность в ней следует из плохого дизайна, и у нее свои штрафы и ограничения. Контексты наконец-то начали обретать функционал, но мне не очень понятна их надобность.
        • 0
          Я к сожалению не могу сравнить с F5, не было у меня опыта с ними, зато работал с CheckPoint в частности на десктопных и мобильных платформах, «юзер экспириенс» остался весьма отрицательный. Кстати и по поводу ISE, на данный момент это практически безконкурентная система идентификации пользовательского и непользовательского доступа в сеть. Более органично вписывающейся системы идентификации с прозрачной авторизацией на транзитных узлах (МСЭ, маршрутизаторы, коммутаторы ЦОД, VPN гейтвей) я просто не знаю (поправьте если не прав). И именно благодаря TrustSec и меткам SGT.
          Контексты они крайне полезны в ЦОД, заказчики нарезают на контексты функционально разные сегменты ЦОД, разных своих внутренних заказчиков, отделяют PCI DSS сертифицируемые сегменты и так далее, фактически вы же получаете логически полностью отдельный фаервол, даже с защитой вычислительных ресурсов по классам обслуживания.
          • 0
            Да, Trustsec и SGT — вкусно. Но не когда оборудование не умеет SGT, а иных причин менять его нет.
            • 0
              Ну так специально чтобы оборудование не менять можно использовать протокол SXP, который может передавать маппинги IP <-> SGT на вышестоящие устройства, которые понимают Inline тегирование к примеру. Этот протокол как раз избавляет нас от необходимости менять все оборудование.
              Конечно надо понимать, что совсем старое оборудование уже и SXP не умеет.
              • 0
                Там свои сложности по части масштабирования. Ну и да, пограничное оборудование может и этого не уметь. Но при этом иметь прочий функционал ISE с точки зрения 802.1x.
                • 0
                  Кстати и в этом случае есть возможность использовать SGT. Например делать динамическую авторизацию с назначением VLAN, на вышестоящем уровне распределения использовать более умное оборудование (например Cat6k-SUP2T) и применять теги на нем уже с привязкой к влану.
                  • 0
                    Тогда теряется профит отвязки примененных политик от адреса устройства. С таким же успехом можно на файрволе сразу делать фильтрацию по адресам.
                    • 0
                      Ну почему же, если у нас более менее общие политики по группам пользователей, тогда например делаем 7 вланов:
                      1) Группа 1
                      2) Группа 2
                      3) Группа 3
                      4) Группа 4
                      5) Карантин
                      6) Voice Vlan
                      7) Printers

                      Назначаем по аутентификации динамически VLAN на старом оборудовании. Эти вланы приходят на Cat6k и тегируются инлайн. Дальше на фаерволе уже все рубится по меткам, ну а метки мы соответственно можем назначать какие-хотим на разные состояния, просто надо VLAN добавить и к нему метку. Есть там конечно ограничения и не удобства, но что поделать когда денег менять железо нет, а хочется «красиво».
                      • 0
                        Ну так какой смысл накручивать фичи, если на файрволе можно сразу рубить по IP адресам? Больше фич — больше глюков.

                        Красота SGT в возможности тегировать на уровне отдельных пользователей, одновременно обходясь минимальным state на сети и на енфорсерах.
                        • 0
                          Красота SGT еще в том, что можно не просто по пользователям делать разделение. По пользователям можно было разделять политики еще лет 5 назад когда появился IDFW.
                          Прелесть в том, что эта метка характеризует состояние (контекст) текущего подключенного пользователя (устройства), например:
                          — с корпоративного ноута зашел или с домашнего
                          — Есть антивирус или нет
                          — активирован DeviceLock или нет
                          — Зашел через проводную/беспроводную/VPN сеть
                          — В каком офисе/этаже/стране зашел
                          — Сколько неудачных попыток аутентификации было
                          — Зашел с мобильного устройства (копроативного/нет), есть ли он в MDM
                          — и много много другого.

                          И метка может характеризовать любую комбинацию текущих условий.

                          Еще пример, 100 филиалов, в филиале по 1 программисту и надо дать им доступ к 10 сервисам ЦОД, в типичной конфигурации фильтров по IP это было бы ACL на 1000 строк, в случае SGT всего одна строка.
                          • 0
                            Это в том числе я и подразумевал. Весь профит SGT сдувает, как только начинаем вешать теги по VLANам.
                            • 0
                              Конечно функционал становится не таким гибким с вешанием на VLAN, но это позволит:
                              a) Подготовить этапно сеть к миграции системы авторизации на SGT;
                              б) Сделать систему NAC для внутренних пользователей с проверкой состояния;
                              в) Сегментировать доступ пользователей по группам AD (к примеру), отследить их состояние (posture) и централизованно отфильтровать на ASA в ЦОД к примеру.

                              Если оборудование оконечное не Cisco и не поддерживает COA, то о веб аутентификации и гостевом удобном доступе тоже можно забыть…
    • 0
      На текущий момент Sourcefire FirePOWER позиционируется как NGIPS и NGFW — фильтр «тонкой очистки». Позволяет предотвращать вторжения, фильтровать ложные срабатывания, получать информацию об уязвимостях в сети, настраивать политики доступа по приложениям, их компонентам, группам пользователей в АД, категориям сайтов и многое, даже МНОГОЕ другое.

      Само собой, это здорово нагружает ресурсы устройства и есть смысл дополнительно задействовать фильтр грубой очистки – Cisco ASA. Да и стоимость Гбит пропускной способности наверняка покажется более привлекательной.

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

      Повторюсь — Sourcefire on ASA, совсем скоро :)
      • 0
        В роли фильтра грубой очистки целесообразнее было бы использовать ASR1k, который, в отличие от ASA, хрен просадишь по RP/ESP. Хотя вот у него заморочек по NAT столько, что волосы дыбом встают.
        • 0
          ASA по производительности просадить… ну это не так просто. Конечно каждому месту установки и цели должна соответствовать и модель ASA, поставьте 5585, раз мы сравниваем с ASR… Опять же функция кластеризации до 16 устройств дает прирост и в соединениях в секунду и в максимальном количестве соединений.
          • 0
            Есть отличная лекция BRKSEC-3021 «Maximizing Firewall Performance», где подробно рассказывается про множество способов просадить асы, а также про их внутреннюю архитектуру :) Кластеризация ведь не линейно масштабируется, и эффективность масштабирования от кучи факторов зависит. Да и поддерживается пока исключительно на 5585.

            А ASR бывают и маленькие. 1001-X довольно интересен. Весьма недорогой по сравнению с 5585-м.
            • 0
              Про внутреннюю архитектуру я в курсе и ограничения тоже конечно же есть (как и везде), но в production за все время моей работы в интеграторе на довольно длинном списке клиентов мне не довелось увидеть чтобы асашку просадили. Во время атаки DDOS один раз помню было что асашка вылетала и тутже подключалась Failover нода, вся соль была в том, что я только через часа полтора заметил, что у меня файловер скачет время от времени, ни пользователи никто не заметил, вот такой файловер Active/Standby. Один раз помню PIX очень старый был в одном кампусе университетском на 30000 пользователей! Кампус был ну очень завирусован и там только ICMP трафик 5 мегабит генерировалось, вот там пикс на 80% работал… Но этот пикс даже на треть этих пользователей не был рассчитан.
              • 0
                Тут, наверное, имеет смысл пообщаться с кем-то из TAC security team. У них много-много историй найдется.
                • 0
                  Это да, это уникальная конечно команда. Мне и десятой части тех багов, что они рассматривали не пападется/попадалось. На то TAC у нас так и ценится, экспертиза!
        • 0
          Я лично за забивание гвоздей молотком. Но пассатижами тоже иногда можно :)
          • 0
            Молотком можно назвать хардварную платформу, производительность которой не особо зависит от числа и характера фич data plane. А еще бывают микроскопы, умеющие до фига и больше, но более нежные и тонкие :)
  • 0
    … и файл будет централизованно заблокирован как на уровне сети, так и на уровне всех зараженных Endpoint систем

    Как происходит блокировка на уровне Endpoint систем? Какой-то клиентский софт? Какие системы поддерживаются?
    • 0
      Весьма закономерный вопрос, я к сожалению все моменты в статье изложить не смог, для этого книга нужна=)
      Итак, если с блокировкой файлов на уровне сети все более-менее понятно и они будут заблокированы по совпадению проходящего через аплаенс файла с подозрительным хэшем, то в случае с блокировкой на хосте нужен агент.
      Агент представляет собой ~15-ти мегабайтный инсталлятор FireAMP Connector, который не несет в себе никакой базы антивирусной, он также как и сетевой аплаенс собирает хеши файлов, их параметры окружения и отсылает на анализ. Соответственно при поступлении сигнала на блокировку — он помещает файл в карантин.
      Причем администратор может и сам задавать в централизованных политиках какие файлы блокировать по хэшу (не только malware), также можно блокировать различные приложения (например Вы видите, что заражение произошло из-за использования Adobe Acrobat версии с уязвимостью и блокируете централизованно только эту версию).

      Поддерживаются системы на данный момент Windows, MAC OSX, Android.

      Для Windows поддерживаются:
      Microsoft Windows XP with Service Pack 3 or later
      Microsoft Windows Vista with Service Pack 2 or later
      Microsoft Windows 7
      Microsoft Windows 8 and 8.1 (requires FireAMP Connector 3.1.4 or later)
      Microsoft Windows Server 2003
      Microsoft Windows Server 2008
      Microsoft Windows Server 2012 (requires FireAMP Connector 3.1.9 or later)

      Для MAC: 64-bit Macs running OS X 10.7 to 10.9

      Для Android: Android 2.1 or higher running on ARM and Intel Atom
      • 0
        Полноценный антивирус на хосте потребуется? Они там не подерутся?
        • 0
          FireAMP рассматривается как специализированное средство борьбы с файло-ориентированными угрозами, вирусами и malware, его эффективность более 99% на данном поле, когда у обычных антивирусов по последним исследованиям не более 40%. Тем не менее мы не позиционируем FifeAMP как Антивирусное средство, поскольку он работает только с файл-ориентированными угрозами. Рекомендация на текущий момент это иметь установленный корпоративный антивирус + FireAMP.
          Работать они будут нормально вместе, FireAMP систему не нагружает, поскольку локально никакого анализа не проводит сигнатурного.
          В настройках FireAMP центральной консоли надо лишь указать исключемую директорию с антивирусом, установленным на системах. Со стороны Антивируса делается такое же исключение в сторону FireAMP.

          По моему опыту, я на 4 компьютера поставил в рамках домашней лаборатории только FireAMP, эффективность его работы на мой взгляд выше чем все ранее установленные коммерческие антивирусы. (Это лишь мой опыт в лаборатории, ни коим разом под официальные данные не подвожу)
          • 0
            Ок, спасибо
  • 0
    Расскажите пожалуйста про лицензирование. Какие лицензии нужны? Какие покупаются отдельно, если таковые есть?
  • 0
    Если говорить про устройства FirePOWER, то схема лицензирования выглядит как на картинках ниже. Если говорить про Sourcefire on ASA, то чуть проще.
    Варианты Awaraness only и AMP достаточно экзотичны, так что обратить внимание стоит на столбцы NGFW и NGIPS.



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

Самое читаемое Разработка