Для начала

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

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

Архитектура заказчика

Что мы имеем? У Заказчика есть географически разнесенная IT инфраструктура, история которой уходит корнями еще в начало нулевых годов, несколько раз модернизированная, обросшая со всех сторон различными средствами защиты информации. Мы будем рассматривать четыре типовых филиала и центральный офис – администрацию, по факту же филиалов было примерно в пять раз больше.

Администрация и четыре типовых филиала

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

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

Здесь и появляется вопрос, а как сформировать полезные ACL, но при этом не нарушить бизнес-процессы заказчика?

Правильным подходом, описанным во всех Best-Practice документах, является разработка ACL на основе карты информационных потоков, но, конечно же, её нет. Более того, отсутствие карты как документа – это половина беды, а то и её треть, главная проблема этого этапа – это отсутствие у IT персонала заказчика понимания того, что, куда и зачем ходит, какие информационные системы филиалов обращаются в центр, кому из пользователей необходим доступ к центральному контроллеру домена, а кому к почтовому серверу соседнего филиала.


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

Собственно, переходим к…

Инструментарию

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

• Серверы DNS, контроллеры домена

• Пользовательские сети объекта

• Почтовые сервера

• Серверы обновлений

• Серверы служб мониторинга

• Серверы служб антивирусной защиты

• Станции администрирования

• Серверы терминальных ферм

• Серверы прокси

• Серверы сбора логов

• Транспортные сегменты

и т.д.


Анализ логов МЭ.

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

• Cisco Security Manager Event Viewer

• CheckPoint SmartView Tracker

• Fortinet Fortigate Firewall Log Analyzer

• ZyXEL ZyWALL USG Log Analyzer

а также бесплатные анализаторы логов для межсетевых экранов, построенных на основе свободных Unix-систем.


Создание и редактирование ACL.
Здесь также нужно отталкиваться от вендора межсетевого экрана. Как правило, вендор представляет наиболее удобное программное обеспечение для работы со своим оборудованием и изобретать велосипед здесь не приходится.

План работ, разделение ролей


1. Сбор исходных данных

a. Интервьюирование инженерного персонала

b. Сбор текущих конфигураций сетевого оборудования

c. Сбор существующих схем сетевых взаимодействий

d. Сбор логов межсетевых экранов (в режиме полного логирования)

2. Анализ исходных данных

a. Разработка перечня объектов и сетей, участвующих в межсетевом взаимодействии

b. Выделение типовых объектов, разработка шаблонов политик межсетевого экранирования для типовых объектов, выделение основных сервисов.

c. Разработка рекомендаций по модернизации (при наличии взаимодействий, не соответствующих логике сети Заказчика)

3. Опытное внедрение политик МЭ

a. Применение политик межсетевого экранирования на один из типовых объектов

b. Опытная эксплуатация, корректирование правил.

c. Отработка оставшихся шаблонов политик межсетевого экранирования

4. Тиражирование политик МЭ

a. Разработка политик для каждого из филиалов на основе соответствующего шаблона

b. Распространение политик межсетевого экранирования на все филиалы

c. Опытная эксплуатация, своевременное реагирование и внесение корректировок.

5. Документирование результатов



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

• Сетевой аналитик, ответственный за разработку правил, умеющий «читать» трафик.

• Сетевой инженер, постоянно находящийся на объекте внедрения в момент опытной эксплуатации политик.

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

Шаблон типового филиала

Политика межсетевого экранирования для каждого из филиалов состоит из трех блоков:

• DNS-имена и IP-адреса объектов взаимодействия

• Описание групп портов/протоколов

• Правила межсетевого взаимодействия

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

DNS-имена и IP-адреса объектов взаимодействия

Далее, на основе пунктов плана 1a, 1.d и 2.b, получаем основные сервисы взаимодействий, например, мы точно знаем, что контроллеры доменов каждого из филиалов реплицируются с центральными контроллерами. А в связи с тем, что нам известна версия операционной системы, мы можем получить список конкретных портов и протоколов, подкрепив эти знания анализом реальных логов.


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

Описание групп портов/протоколов

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

Правила межсетевого взаимодействия

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

Пример применения правил на практике, разбор заявки

После подготовки шаблона политики правил межсетевого экранирования, мы переходим к следующему, наиболее важному и ответственному этапу – опытное внедрение политик безопасности.

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

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

В итоге мы выработали простой алгоритм, позволяющий максимально быстро и без потери качества реагировать на подобные инциденты:

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

2. Сетевой инженер делает выборку трафика, исходящего из целого сегмента, в который входит АРМ заявителя и составляет список портов, по которым трафик блокируется.

3. Сетевой инженер отбирает весь трафик, источником и получателем которого является АРМ заявителя.

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

5. Корректировка согласовывается администратором Заказчика.


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

Результаты

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

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

Во-вторых, благодаря отсеиванию нецелевого трафика, мы получили падение загрузки каналов связи от 15 до 60 % на разных филиалах.

Например, для небольшого филиала «Калуга», график загрузки канала связи выглядит следующим образом:

Падение загрузки канала связи филиала "Калуга" после применения правил

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

До применения правил экранирования
После применения правил экранирования

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