Почти все ЦОД в тех технических решениях, с которыми мы встречались, имеют одну общую черту – периметр, образованный из средств защиты информации (как правило, это FW, IPS, AV, WAF, и, возможно, Sandbox). По аналогии с драже M&M’s такой ЦОД снаружи «твердый», а внутри периметра «мягкий». Чем это оборачивается для предприятия? На практике оказывается, что периметр не такой и «твердый», и злоумышленник всегда находит лазейку, чтобы его пройти. И когда злоумышленник оказывается внутри периметра ЦОД, шансы предприятия обнаружить или хоть как-то сдержать атаку близки к нулю. О некоторых подходах к решению этой проблемы пойдет речь ниже.
Думаю, что после вступления логичным был бы вопрос: «Почему вы предполагаете, что периметр не отразил атаку?» Я не стану приводить все причины для такого предположения, воспользуюсь лишь самым, на мой взгляд, сильным доводом. Периметр способен отразить только известные данному периметру (конкретным СЗИ) атаки, все остальные атаки пройдут. Поясню: средства защиты на периметре опираются по большей части на сигнатуры, что справедливо не только для IPS, AV и WAF, но и для устройств Sandbox, которые опираются на сигнатуры поведения.
Итак, злоумышленник внутри периметра (см. рисунок ниже). Какие шаги предпримет злоумышленник дальше?
Дальнейшие действия злоумышленника проще всего описать диаграммой.
Для того чтобы понять насколько просто или сложно злоумышленнику продвигаться в ЦОД, предположите, что какой-то из серверов в ЦОД находится под контролем злоумышленника, после чего ответьте на вопросы:
- Какие сервисы доступны для атак злоумышленника? В том случае, если внутри сегмента нет «перегородок», любой из сервисов и серверов может быть атакован.
- На всех ли серверах сегмента строгая парольная политика и как выполнение этой политики контролируется? Те серверы сегмента, на которых используется нестойкий пароль, злоумышленник с легкостью поставит под свой контроль.
- Какие учетные записи оказались скомпрометированы вместе с сервером? Без дополнительных ухищрений злоумышленник сможет обращаться к AAA-серверу, просматривать содержимое сетевых дисков, представляясь скомпрометированным пользователем.
В том случае, когда в ЦОД нет никаких средств контроля над потоками, устанавливаемыми с сервера на сервер (внутри сегмента), ничто не препятствует атаке распространяться внутри периметра ЦОД и впоследствии достигнуть своей цели.
Что если изменить подход? Сегмент будет соответствовать VM, а «вход» и «выход» в этот сегмент будут контролироваться средствами FW. Таким образом, одно скомпрометированное приложение не сможет стать плацдармом для атак на другие приложения (другими словами, любая атака будет зажата рамками одного приложения). Как следствие, атака могла бы быть замедлена, что предоставило бы предприятию время для обнаружения атаки.
Концепция понятна, но какие подходы к реализации? Сразу приходит на ум идея использовать FW, который стоит на периметре ЦОД. Однако на практике такой подход оборачивается несколькими неприятными последствиями:
— Требуется создать сегменты (как правило, это VLAN) в количестве серверов приложений, «протянуть» VLAN от VM к FW ЦОД, создать на FW виртуальные интерфейсы, что на практике означает конфигурирование виртуальных коммутаторов, физических коммутаторов, FW при каждом добавлении или уничтожении сервера приложения.
- Поскольку все потоки в ЦОД теперь проходят через межсетевой экран, пропускная способность FW периметра ЦОД может создать узкое место. Производительность даже самых производительных СЗИ в режиме с включенными функциями защиты IPS, AV выглядит крайне несбалансированно по отношению к производительности фабрики ЦОД.
- Миграция VM требует переноса сетевого окружения (VLAN ID, IP адреса VM и шлюза по умолчанию) в другой ЦОД, что означает изменение конфигурации сетевых устройств вручную или средствами системы автоматизации в момент миграции (подход с «растягиванием» VLAN между площадками не рассматривается в силу неприятных последствий, о которых читайте, например, в нашей библиотеке).
Как становится понятно, FW периметра ЦОД не может решить задачу сегментации, не создав при этом других проблем. Какими могут быть альтернативные подходы?
— — —
Общая концепция альтернативных подходов состоит вот в чем:
— Приблизить сервис FW как можно ближе к VM и фактически организовать для каждого приложения персональный сервис FW.
— В силу того, что серверы источников и назначения запросов находятся в ЦОД и заранее известны, реализовать политики контроля над потоками данных по принципу whitelist (блокировать все, что явно не разрешено).
Для контроля над FW (или теперь уже distributed FW, или d-FW) и представления администратору множества устройств d-FW как единую систему применяется система управления. Данная идея получила название – микросегментация.
Для реализации идеи микросегментации я рассмотрю 3 подхода (если вам известны другие подходы, поделитесь, пожалуйста, в комментариях):
- FW-as-a-VM
- Гипервизор
- Программные агенты
Подход №1. FW-as-a-VM
Подход заключается в том, что роль сервисного d-FW выполняет виртуальная машина. Для того чтобы выделить сегменты и отправить трафик для проверки на d-FW выполняется подстройка виртуальной сетевой топологии (см. рисунок ниже). Задача подстройки виртуальной топологии ложится на систему управления d-FW.
Возможности d-FW в части применяемых функций безопасности, как правило, не ограничиваются фильтрацией потоков данных средствами межсетевого экрана и включают применение функций IPS, AV и AppCtrl.
Поскольку сервисная виртуальная машина размещается на том же гипервизоре, что и виртуальные машины приложений, часть ресурсов среды виртуализации потребуется выделить для сервисной d-FW (требования одной из реализаций, с которой мы встречались: 2 vCPU, 4 GB RAM).
Одной из важных, с моей точки зрения, возможностей системы управления d-FW является считывание информации о VM, которой владеет среда виртуализации. Почему?
Давайте отвлечемся от рассматриваемого подхода FW-as-a-VM и обсудим то, как мы привыкли писать правила на межсетевых экранах. Привычным является подход, при котором идентификация VM выполняется по её адресу IP. Не удивительно, что при изменении адреса IP, при создании или удалении VM мы вынуждены вносить изменения в настройки FW. А теперь давайте рассмотрим альтернативный способ написания правил, в котором VM идентифицируются по имени или по присвоенному администратором тегу. Используя данный способ, администратор FW может один раз задать правило, указав атрибуты VM, и в дальнейшем данное правило не будет нуждаться в корректировке!
Вернемся к обсуждению подхода FW-as-a-VM. Информация, которую считывает система управления d-FW, включает имена VM, теги, данные о виртуальных сетевых интерфейсах – фактически все те данные, которыми обладает среда управления виртуализацией.
Подводным камнем подхода FW-as-a-VM является нюанс, связанный с поддержкой миграции виртуальных машин. Для миграции виртуальной машины требуется, чтобы в гипервизоре, на который переносится виртуальная машина, была выстроена топология для отправки трафика на d-FW. Если топология в момент миграции не будет подстроена, связность с виртуальной машиной приложения будет потеряна. Необходимость подстройки виртуальной топологии означает, по крайней мере, 2 вещи:
1) система управления d-FW должна быть «подписана» на получение сообщений о событиях миграции, которые генерирует система управления виртуальной средой,
2) система управления виртуальной средой должна быть online в момент миграции (именно через интерфейс API системы управления виртуальной средой выполняется подстройка топологии).
Резюме подхода:
— Выполнение функции фильтрации потоков (FW), а также IPS, AV, AppCtrl.
— Управление правилами d-FW выполняется с учетом информации о VM, которой владеет система управления средой виртуализации.
— Подход требует взаимодействия системы управления d-FW и системы управления средой виртуализации для направления трафика на сервисную виртуальную машину d-FW.
Подход №2. Гипервизор
Идея подхода состоит в том, что сервис d-FW реализуется гипервизором виртуальной среды, а именно как kernel-модуль виртуального коммутатора. Особенностью подхода является то, что система управления d-FW взаимодействует непосредственно с компонентами гипервизора (виртуальными коммутаторами), минуя систему управления виртуализацией.
Возможности d-FW в части применяемых функций безопасности, как правило, ограничены фильтрацией потоков данных средствами межсетевого экрана. Для подключения функции IPS, AV, AppCtrl может использоваться отправка потоков на сервисную виртуальную машину как в подходе FW-as-a-VM с тем лишь отличием, что перенаправление потоков выполняется не подстройкой топологии, а механизмами виртуальных коммутаторов.
Для того чтобы отказаться от использования адресов IP при задании правил, система управления d-FW связывается с системой управления виртуальной средой в части получения информации о VM (получаемая информация аналогична той, которая приводилась в описании подхода FW-as-a-VM).
Для обеспечения доступности VM после миграции система управления d-FW устанавливает правила фильтрации одновременно на всех гипервизорах, на которых потенциально может оказаться виртуальная машина. Состояние d-FW (connection table) мигрирует вместе с виртуальной машиной средствами среды виртуализации точно так же как, к примеру, состояние оперативной памяти.
Резюме подхода:
- Выполнение функции фильтрации потоков (FW). Функции IPS, AV, AppCtrl – средствами дополнительных сервисных VM.
- Управление правилами d-FW выполняется с учетом информации о VM, которой владеет система управления средой виртуализации.
Подход №3. Программные агенты
Подход основан на том, что на виртуальные машины приложений устанавливается программное обеспечение, которое для выполнения функций фильтрации управляет механизмами, всторенными в операционную систему. Поскольку агент не участвует в непосредственной обработке пакетов, функций безопасности d-FW ограничены теми механизмами, которые заложены в операционных системах. В продуктах, с которыми мы встречались, и для Windows, и для Linux была реализована функция межсетевого экрана, но не IPS, AV или AppCtrl (возможно, кто-либо встречался с другими реализациями?).
Для распространения агентов может применяться или включение ПО агента в шаблон (template) виртуальной машины, или установка ПО агента за счет систем автоматизации, например, Ansible (предприятие также может использовать собственный подход распространения ПО).
Агент, установленный на сервер приложения, сообщает системе управления d-FW данные контекста приложения, а именно: информацию о сервере (например, имя, описание, теги), запущенные процессы приложений, открытые TCP/UDP-порты. Информация, изученная агентом, может быть в дальнейшем использована для написания правил, контролирующих информационные потоки.
Преимуществом подхода является тот факт, что организовывать взаимодействие со средой виртуализации не требуется, и подход может одинаково успешно применяться и для различных гипервизоров и систем управления средой виртуализации. Кстати, если на предприятии виртуализация не охватывает 100% серверов (часть серверов bare-metal), подход может применяться и в этом случае.
Другим преимуществом подхода можно назвать то, что при использовании агентов можно не обращать внимания на вопрос миграции VM, потому что перенос сервиса d-FW, в том числе правил межсетевого экрана и состояния (connection table) происходит вместе с виртуальной машиной.
Резюме подхода:
— Выполнение функции фильтрации потоков (FW).
- Управление правилами d-FW выполняется с учетом информации приложении, которую предоставляет агент.
- Подход не ограничивает выбор среды виртуализации (может применяться и для серверов bare-metal).
— — —
Любой из рассмотренных подходов позволяет затруднить распространение атаки, вместе с тем увеличивая издержки злоумышленника и как максимум вынуждая злоумышленника отказаться от продолжения атаки. Даже если злоумышленник не оставит свои попытки, атаку злоумышленника или её следы можно попытаться обнаружить. Как обнаружить атаку, которая прошла периметр? Это отдельная история для новой статьи.
Источник: www.solidex.by