Содержание статьи
Обеспечение сетевой безопасности с помощью программно-конфигурируемых сетей
Ты когда-нибудь сталкивался с задачей настройки нескольких десятков файрволов в гетерогенной сети, с согласованием конфигураций, оптимизацией? Тогда тебе известно, насколько это дорогой и трудоемкий процесс. Мы предлагаем рассмотреть новый перспективный подход к обеспечению сетевой безопасности, который активно исследуется и внедряется в мировой IT-индустрии, — технологию программно-конфигурируемых сетей.
Новый подход, который мы адаптировали к задаче разграничения доступа в сети, позволяет добиться максимальной эффективности использования коммутационного оборудования и отказаться от дорогостоящих выделенных файрволов. Предлагаем твоему вниманию один из вариантов использования нового подхода, когда мы решаем задачу перехода от сети с традиционной архитектурой к ПКС с сохранением существующей политики разграничения доступа.
Все началось с ARPANET…
Архитектура глобальной сети безнадежно устарела. Ее основы закладывались в 70-х годах, когда не было ни мобильных узлов, ни беспроводной связи. В то время никто не мог предсказать современные скорости и объемы передаваемых данных. Да и при разработке базовых протоколов не было предусмотрено разграничение доступа на уровне сети. Предполагалось, что в глобальной сети приложения могут связываться друг с другом без ограничений. Реальность довольно быстро потребовала корректировки такого идеалистического представления, и появились специализированные устройства (и программные средства в операционных системах), реализующие разграничение доступа в сети, — межсетевые экраны (далее МСЭ), впоследствии системы предотвращения вторжений (IPS), сетевые антивирусы, шлюзы уровня приложений (в том числе WAF — web application firewall).
Почему необходима технология ПКС
Нам несказанно повезло — мы оказались свидетелями кардинальных изменений в составе, структуре и распределении трафика в Сети. С точки зрения клиентских устройств интернет стал мобильным — число беспроводных устройств перевалило за миллиард, в то время как количество «фиксированных» клиентов в пять-шесть раз меньше. Общий объем трафика за последние пять лет возрос более чем в три раза. По прогнозам Cisco, трафик будет удваиваться примерно каждые девять месяцев, что приведет к увеличению нагрузки на несколько порядков в течение ближайших лет. Причем ожидается, что к 2014 году около 80% трафика будет составлять видеотрафик.
По мере изменения характера приложений и трафика меняются и требования к обеспечению информационной безопасности устройств и контента. Если раньше задача заключалась в управлении отдельными серверами, сетями и маршрутизаторами, то сейчас требуется обеспечить информационную безопасность всех корпоративных бизнес-процессов, независимо от размещения клиентских устройств, их перемещения, распределения данных по устройствам и их принадлежности (вспомним концепцию BYOD).
К сожалению, в настоящее время эффективность решений по разграничению доступа начала снижаться — требуется значительно больше дорогих устройств, чтобы обеспечить тот же уровень гранулярности сети, как пять-десять лет назад. Проблема заключается в том, что в условиях мобильности клиентских устройств конфигурация сети постоянно изменяется и информация о ней не может быть напрямую использована для разграничения доступа. Поэтому на первый план выходит задача разграничения доступа на основе информации об ожидаемом поведении (потоках) между приложениями в сети. Кроме того, сами устройства разграничения доступа уровня сети не становятся дешевле, даже наоборот — решения для 10- или 100-гигабитных каналов стоят дорого.
Те, кто интересовался этой глобальной проблемой в сфере компьютерных сетей, знают, что сегодня одна из самых перспективных технологий — это программно-конфигурируемые сети (ПКС, англ. software defined network — SDN). Напомним, что основная идея ПКС-подхода состоит в том, чтобы, не изменяя существующего оборудования, отделить управление сетевыми устройствами от управления передачей данных и перейти от управления отдельными экземплярами сетевого оборудования к управлению сетью в целом. Новая парадигма позволяет администратору четко видеть все потоки трафика, ему становится легче замечать вторжения и выявлять другие проблемы, назначать приоритеты различным типам трафика и разрабатывать правила реагирования сети при заторах и проблемах с оборудованием. А мы покажем еще одно, менее очевидное преимущество — новая концепция ПКС позволяет не только сохранить прежнюю функциональность разграничения доступа на уровне сети, но и реализовать ее оптимально.
Проблема оптимизации расположения правил фильтрации и ее решение
Для начала рассмотрим проблему контроля доступа на уровне сети на примере МСЭ и ее решение с помощью ПКС. Как известно, правила МСЭ описывают ограничения на доступ между приложениями, исходя из информации об адресах, номерах портов (то есть типах приложений) и прочих служебных полях заголовков. Использование сложных правил обусловлено прежде всего тем, что МСЭ устанавливается в одной, вполне определенной точке сети, поэтому язык правил должен позволять точно различать потоки между различными приложениями и клиентами. Из-за сложности и богатства языка определения правил усложняется логика устройств фильтрации, им надо выполнять больше операций над каждым заголовком, чтобы определить действие, выполняемое с каждым пакетом (permit или deny). Очевидно, что каждое анализируемое правило вносит определенную задержку во время передачи пакета и чем сложнее правило, тем больше время его анализа.
В то же время известно, что если бы существовала возможность выполнять фильтрацию «по источнику» максимально близко к источнику, а фильтрацию «по назначению» максимально близко к узлу или приложению назначения, то сами правила можно было бы существенно упростить, а значит, удешевить реализацию задачи разграничения доступа. Можно показать, что если существует некоторая конфигурация МСЭ, которая описывает правила доступа между приложениями, то она может быть отображена на набор таблиц потоков (Flow Tables) ПКС таким образом, что общая пропускная способность сети при сохранении всех ограничений на доступ будет строго больше, чем при использовании централизованного устройства фильтрации. Таким образом, с помощью ПКС можно не только избавиться от МСЭ в виде отдельных устройств и выполнять фильтрацию на уровне среды доступа, но и максимизировать ее пропускную способность. Звучит заманчиво, не так ли?
От классической топологии к ПКС-архитектуре
Предлагаемый подход к миграции среды передачи данных с традиционной архитектурой сети, использующей выделенные межсетевые экраны, на ПКС с переносом правил фильтрации непосредственно в среду передачи данных, представленную OpenFlow-коммутаторами и контроллером ПКС, предполагает наличие нескольких этапов.
Алгоритм перехода традиционной сети к ПКС-топологии:
- Оптимизация правил:
- поиск и удаление аномалий на каждом МСЭ в отдельности;
- поиск и удаление аномалий на МСЭ в совокупности.
- Построение единого логического (виртуального) МСЭ для каждой подсети в топологии.
- Подсчет минимального необходимо количества OF-коммутаторов и выбор топологии ПКС.
- Трансляция правил фильтрации трафика для каждого OF-коммутатора в правила потоков.
Под аномалией в политике фильтрации мы подразумеваем правила, наличие которых не влияет на конечный результат фильтрации.
В качестве примера применения описываемого метода рассмотрим топологию (рис.1), состоящую из большого количества подсетей (Free Wi-Fi, Web Server, DataBase, Management Network, Research Network, Development Network и Accounts Network), маршрутизаторов и МСЭ. Также существует отдельная область, называемая интернет. Мы определяем ее как подсеть с любым адресом, не пересекающимся с набором адресов перечисленных выше подсетей.
Хакер #173. Уязвимости Ruby on Rails
Данная топология отображает строение реальной LAN и имеет сложную структуру разграничения прав доступа на основе фильтрации трафика с использованием трех аппаратных МСЭ. Также некоторые хосты в топологии могут иметь МСЭ уровня приложений, развернутые программно, как, например, на хостах подсети Accounts Network. Вся сеть разбивается МСЭ на зоны (A, B, C и D). Передаваемый трафик внутри каждой зоны не подвергается фильтрации со стороны МСЭ.
Для перехода к топологии, в основе которой лежит технология ПКС, необходимо выбрать ее структуру. Самые распространенные: дерево, полносвязный граф, решетка, звезда, кольцо, трехмерный куб. Топология выбирается в зависимости от размера сети и требований, предъявляемых к ее надежности, отказоустойчивости и загруженности. Для рассматриваемого примера топологии мы выбрали структуру полносвязного графа, поскольку считаем, что количество хостов во входной топологии невелико, однако скорость передачи данных является критическим фактором. Как известно, в топологии полносвязного графа любой пакет может достигнуть точки назначения за три хопа.
В процессе замены топологии возникает необходимость вычисления минимального количества OF-коммутаторов, которые будут участвовать в топологии. Данная задача представляет собой разновидность задачи об упаковке в контейнеры (Bin-Packing Problem). Она заключается в распределении подсетей с различным числом хостов по коммутаторам с различным числом портов таким образом, чтобы число задействованных коммутаторов было минимальным. Результатом процесса замены для рассматриваемой LAN является ПКС топология, представленная на рис. 2.
Наши результаты на практике
Предлагаемый подход был реализован в качестве приложения для контроллера POX с использованием языка программирования Python 2.7 (поддерживаемая версия протокола OpenFlow 1.0). Приложение реализует фильтрацию трафика в двух режимах: классическом и рефлексивном. На вход приложения поступает начальная топология с определенной политикой фильтрации трафика для каждого МСЭ в формате Extended Cisco ACL. Результатом работы является множество наборов правил потоков для каждого коммутатора, входящего в новую ПКС-топологию.
В качестве тестового коммутатора использовался OpenFlow-hybrid коммутатор 48GbE NEC PF5820. Данная модель поддерживает версию протокола OpenFlow 1.0, до 96 тысяч записей потоков уровня L2 и до 750 полноценных правил потоков, состоящих из 12 полей. Коммутатор можно разбить на несколько виртуальных коммутаторов, однако все они используют единую таблицу потоков. Для проведения экспериментальных исследований коммутатор NEC разбили на шесть виртуальных коммутаторов по восемь портов в каждом. Для создания топологии полносвязного графа получившиеся виртуальные коммутаторы соединили друг с другом (рис. 3).
К виртуальным коммутаторам 1–5 подключили хосты к портам 1, 9, 17, 25, 33 соответственно. Каждому хосту в топологии был назначен IP-адрес из различных подсетей. К 6-му коммутатору подключили ноут (порт 41), на котором работало тестируемое приложение.
Сначала был воспроизведен пример топологии, описанной выше, проверена корректность установки и трансляции правил фильтрации в правила потоков. Далее провели следующие испытания:
- Измерили время установки правил потоков в зависимости от их количества. Согласно полученным результатам время установки правил линейно зависит от их количества.
- Измерили задержку при передаче нового потока, появляющегося в сети, в зависимости от расположения первого подходящего правила.
Из проведенных экспериментов можно сделать вывод, что время передачи пакета при классическом варианте реализации остается примерно постоянным (около 40 мс) вне зависимости от количества правил потоков, поскольку время, которое требуется для поиска по таблице, расположенной в троичной ассоциативной памяти (Ternary Content Addressable Memory, TCAM), является минимальным. При рефлексивном варианте реализации задержка при передаче пакета увеличивается (около 110 мс для первого пакета), однако после установки правил потока на все коммутаторы передача пакета составляла в среднем 0,1 мс, что в 1100 раз меньше.
Варианты использования и преимущества
Итак, к чему мы пришли? Согласно определенной политике (рис. 1), пакет с IP-адресом источника 7.7.7.7 и IP-адресом назначения 172.16.0.25 должен будет пройти через три аппаратных МСЭ и один программный — в итоге будет проанализировано 41 правило. Необходимо отметить, что мы рассмотрели самый критичный случай, при котором пакет каждый раз проходит по предпоследнему правилу (последнее правило deny). При переходе к ПКС количество просмотренных правил для того же случая значительно уменьшается — 7 (лучший случай) и 32 (худший случай). Все зависит от того, сколько подсетей подключено к одному OF-коммутатору. Для достижения наименьшего количества просматриваемых правил необходимо для каждой подсети выделить отдельный коммутатор.
Howto по созданию тестового стенда на коммутаторе NEC PF5820
- Создаем VLAN’ы. У каждого виртуального коммутатора должен быть отдельный VLAN
NEC(config)# vlan 1001 NEC(config-vlan)# name “Subnet1” NEC(config-vlan)# exit - Назначаем каждому порту принадлежность к определенному VLAN
NEC(config)# interface range gigabitethernet 0/1–8 NEC(config-if-range)# switchport mode access NEC(config-if-range)# switchport access vlan 1001 NEC(config-if-range)# no shutdown NEC(config-if-range)# exit - На этом порту и по этому адресу будет располагаться контроллер
NEC(config)# interface gigabitethernet 0/41 NEC(config-if)# ip address 10.0.0.1 255.255.255.0 NEC(config-if)# no shutdown NEC(config-if)# exit - Создаем виртуальный OpenFlow-коммутатор
NEC(config)# openflow openflow-id 1 virtual-switch - Приходящие пакеты на этот коммутатор будут отправляться на контроллер по указанному адресу и TCP-порту
NEC(config-of)# controller controller-name Subnet1-controller 100 10.0.0.1 port 6633 tcp - В виртуальный коммутатор будут входить порты, принадлежащие VLAN 1001
NEC(config-of)# openflow-vlan 1001 - Если несколько попыток соединиться с контроллером завершились неудачей, коммутатор должен войти в режим emergency и повторно установить TCP-соединение. В данном режиме записи таблиц потоков, кроме помеченных битом emergency, удаляются.
NEC(config-of)# emergency-mode disable - Отключаем автоматическое выучивание MAC-адресов. Данная функциональность выполняется контроллером
NEC(config-of)# mac-learning disable - Включаем настроенный виртуальный коммутатор
NEC(config-of)# enable NEC(config-of)# exit
Виртуальный коммутатор готов!
Заключение
Переход от сети традиционной архитектуры к ПКС позволяет решить сразу несколько проблем в современных (и перспективных) сетях: во-первых, мы можем избавиться от выделенных дорогостоящих устройств — традиционных межсетевых экранов и решить задачи разделения доступа средствами коммутационной среды; во-вторых, существующие на данный момент ПКС-контроллеры позволяют учитывать мобильность клиентов, и у нас появляется возможность централизованно и оперативно, по мере перемещения клиента по физической сети, изменять конфигурацию «логического» МСЭ, реализуемого коммутационной средой. Ну и самое главное — в управлении сетевой безопасностью и разделении доступа на уровне коммутационной среды мы наконец-то получаем все возможности, предоставляемые идеологией Open Source, — подавляющее большинство контроллеров OpenFlow являются открытыми проектами, и администратор сети получает возможность реализовать произвольную политику контроля доступа, без оглядки на тот набор функциональности, который реализован поставщиками оборудования.
Если тебя заинтересовала наша исследовательская работа, исходный код приложения доступен здесь
WARNING
Контроллер POX используется преимущественно для реализации прототипов приложений. Его производительность значительно ниже аналогичных решений, реализованных на C++, Java или Ruby. Для внедрения описанного подхода в существующие сети необходимо переписать приложение для другой сетевой ОС.
