Содержание


Использование системы IBM Security Network Protection в программно-определяемой сети на базе OpenFlow

Comments

В первой статье этой серии говорилось о том, как использовать устройство IBM Security Network Protection 5100, или XGS5100, с виртуальным коммутатором Open vSwitch. Мы показали, как установить Open vSwitch и гипервизор KVM на систему Ubuntu 12.4 (LTS). Затем подключили Open vSwitch к XGS5100. В Open vSwitch создали потоки, позволяющие XGS5100 проверять трафик между виртуальными машинами. В статье также было показано, как запустить очень простую атаку для демонстрации возможностей XGS5100 по предотвращению вторжений.

Как сказано в первой статье, недостаток использования Open vSwitch состоит в том, что, сложный и чреватый ошибками процесс настройки выполняется вручную. Настраивать потоки вручную нерационально, если только среда не является относительно статичной. Любые изменения в виртуальных машинах (ВM), такие как добавление или удаление ВМ, ведут к изменению потоков в Open vSwitch.

В этой статье показан следующий логический шаг – как добавить в среду SDN-контроллер и как с помощью этого контроллера управлять потоками. Главное преимущество использования SDN-контроллера заключается в том, что он предоставляет управляемый способ настройки потоков не только в одном Open vSwitch, но и во всех виртуальных коммутаторах, присутствующих в среде. В этой статье в качестве SDN-контроллера используется контроллер POX.

Программно-определяемые сети

SDN – это новый архитектурный подход к управлению сетью. Его цель – создать гибкую сеть, более подходящую для современной динамичной ИТ-среды. Существующие сетевые технологии по своей природе статичны и трудно изменяемы. Для внесения незначительных изменений часто требуется существенная реорганизация многих коммутаторов, маршрутизаторов и брандмауэров. Этот процесс отнимает у администраторов много времени и чреват ошибками.

При SDN-подходе плоскости «управления» и «данных» разделены. Плоскость управления регулирует направление трафика в сети, а плоскость данных пересылает этот трафик. В традиционных сетевых устройствах плоскости управления и данных находятся в пределах сетевого устройства, и настройкой плоскости управления занимается его производитель. В SDN плоскость управления отделена от плоскости данных и централизованно управляется с помощью контроллера SDN посредством сетевого оборудования предприятия независимо от поставщика. Это гарантирует простой и быстрый способ управления потоком трафика.

OpenFlow

SDN для взаимодействия с плоскостью данных (реализованной на физических устройствах) требуется централизованно регулируемая плоскость управления. Один из SDN-протоколов, который обеспечивает такое взаимодействие, – OpenFlow, разработанный группой Open Networking Foundation. OpenFlow обеспечивает точное управление трафиком во всем спектре коммутаторов и маршрутизаторов корпоративной среды, как физических, так и виртуальных, независимо от поставщика. Это исключает необходимость индивидуально настраивать устройство каждого поставщика посредством его собственного интерфейса.

SDN-контроллер

SDN-контроллер – это приложение, работающее в сети SDN, которое регулирует поток управления. SDN опирается на протоколы (такие как OpenFlow), с помощью которых серверы указывают коммутаторам, куда направлять пакеты. Контроллер настраивает сетевые устройства и выбирает оптимальный сетевой путь для трафика приложения.

POX – это платформа разработки ПО с открытым исходным кодом для SDN-контроллера, написанная на языке Python. POX поддерживает OpenFlow 1.0, инструктируя сетевые коммутаторы, куда направлять пакеты. Первоначально NOX был контроллером с открытым исходным кодом, написанным на C++. POX написан на языке Python и подходит для быстрого создания прототипов и экспериментирования. Исходный код POX доступен на сайте GitHub.

IBM Security Network Protection (ISNP)

Продукт IBM Security Network Protection, обычно называемый XGS, – это соединение традиционной функции системы предотвращения вторжений (Intrusion Prevention System - IPS) со сложным управлением приложениями в зависимости от действий пользователя и репутации IP-адресов. Это решение обеспечивает критически важное понимание и контроль над всей деятельностью пользователя, анализируя каждое соединение для определения используемого веб- или не веб-приложения, его репутации и выполняемых действий. Решение ISNP может разрешать или блокировать соединения в зависимости от своей оценки сети. Кроме того, ISNP может записывать сведения о соединении, включая контекст пользователя и приложения, и использовать эту информацию для локального совершенствования политики, включая управление полосой пропускания. Подход интеграции IPS с рядом других функций безопасности позволяет ускорить процесс развертывания и упростить управление по сравнению с установкой нескольких продуктов.

Установка контроллера POX

Контроллер POX можно установить на любую машину, IP-адрес которой доступен для гипервизора KVM, или на ту же машину, на которой работает гипервизор. На рисунке 1 показан подход «все в одном», когда POX устанавливается на первоначальную машину Ubuntu Linux®, описанную в первой статье.

Рисунок 1. Подход «все в одном»
Подход «все в одном»
Подход «все в одном»

Для работы контроллера POX можно использовать и другую Linux-машину, как показано на рисунке 2.

Рисунок 2. Подход с отдельной машиной POX
Подход с отдельной машиной POX
Подход с отдельной машиной POX

В этом руководстве для упрощения конфигурации используется подход «все в одном», как описано ниже.

Установите git на свою машину Ubuntu Linux:

# sudo apt-get install git

Создайте новую папку для контроллера POX:

# mkdir ~/controller; cd ~/controller;

Клонируйте проект POX из github:

# git clone http://github.com/noxrepo/pox

Установка контроллера POX

В этом разделе описано, как запустить контроллер POX для управления Open vSwitch на гипервизоре.

Запуск контроллера POX как обучающего коммутатора L2

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

Перейдите в папку контроллера POX:

# cd ~/controller/pox/

Запустите контроллер POX

# ./pox.py --verbose forwarding.l2_learning samples.pretty_log

Модуль forwarding.l2_learning позволяет создавать управляемые коммутаторы, действующие как обычные коммутаторы. Модуль sample.pretty_log выводит на экран красочную картину.

Настройка Open vSwitch, чтобы контроллер POX мог управлять им

При подходе «все в одном» контроллер POX и Open vSwitch работают на одной и той же машине. Поэтому IP-адрес для подключения к контроллеру POX — 127.0.0.1. Если контроллер POX выполняется на другой машине, для настройки Open vSwitch необходимо использовать соответствующий IP-адрес.

Подключите ovs-internal к контроллеру POX:

# sudo ovs-vsctl set-controller ovs-internal
               tcp:127.0.0.1:6633

Когда ovs-internal успешно подключится к контроллеру POX, вы увидите на консоли контроллера POX сообщения, подобные тем, что показаны на рисунке 3.

Рисунок 3. Успешное подключение ovs-internal
Успешное подключение ovs-internal
Успешное подключение ovs-internal

Ovs-internal можно в любое время отключить от контроллера POX, выполнив следующую команду:

# sudo ovs-vsctl del-controller ovs-internal

Когда контроллер POX больше не управляет ovs-internal, тот действует как обычный коммутатор.

Проверка прохождения трафика

Чтобы убедиться, что трафик может проходить через Open vSwitch, инициируйте запрос ping из одной виртуальной машины к другой и убедитесь, что трафик проходит. Если ВМ успешно отправляет и принимает запросы, значит контроллер POX уже установил некоторые правила управления потоком в ovs-internal. Чтобы получить список всех правил управления потоком, установленных в ovs-internal, можно выполнить следующую команду:

# sudo ovs-ofctl dump-flows ovs-internal

Создание нового приложения в POX для защиты виртуальных машин на хосте

Чтобы автоматически переносить правила управления потоком в ovs-internal для защиты виртуальных машин, необходимо создать свое собственное приложение, работающее на контроллере POX, которое будет выполнять анализ в режиме реального времени и реагировать соответствующим образом. Это новое приложение основано на готовом обучающем модуле L2 с добавлением логики безопасности.

Описание обучающего модуля L2

Прежде чем изменять существующий обучающий модуль L2, нужно понять, как он работает, чтобы вставить свою логику безопасности в нужное место. Файл с исходным кодом обучающего модуля L2 называется l2_learning.py и находится в /pox/pox/forwarding/. Комментарии в этом файле – хорошее руководство по деталям кода, но для его понимания будет полезно более общее описание модуля.

Обучающий коммутатор L2 работает просто. Он узнает, в какой порт отправить пакет, проверяя MAC-адрес назначения. Следовательно для хранения этой информации должна присутствовать таблица соответствия MAC-адресов и портов. В исходном коде эта информация хранится в таблице self.macToPort. Алгоритм обучения L2 из исходного кода приведен в листинге 1.

Листинг 1. Исходный код отображения MAC-адресов на порты
1 if packet.dst.is_multicast: 
2   flood() # 3a 
3 else:                                     
4   if packet.dst not in self.macToPort: # 4 
5     flood("Port for %s unknown -- flooding" % (packet.dst,)) # 4a
6   else: 
7     port = self.macToPort[packet.dst]

Если пакет многоадресный (строка #1), он направляется во все порты vswitch (строка #2). Если пакет не многоадресный (строка #3), модуль проверяет по таблице macToPort, в какой порт нужно направить этот пакет (строка #4). Если соответствующая запись в таблице не найдена, пакет направляется в каждый порт (строка #5). Если информация о порте в таблице есть, то модуль узнает, в какой порт направить пакет (строка #7). Затем модуль создает в vswitch новое правило управления потоком по пересылке пакетов. Код задания правил управления потоком в коммутаторе приведен в листинге 2.

Листинг 2. Установка правил управления потоком в коммутаторе
1        msg = of.ofp_flow_mod() 
2        msg.match = of.ofp_match.from_packet(packet, event.port)
3        msg.idle_timeout = 10 
4        msg.hard_timeout = 30 
5        msg.actions.append(of.ofp_action_output(port = port)) 
6        msg.data = event.ofp # 6a 
7        self.connection.send(msg)

Строка #1 создает пустой объект правила, а строка #2 составляет условия совпадения с помощью атрибута из текущего пакета. Наиболее важная часть правила – это его действие. Строка #5 создает действие для вывода пакета через порт, найденный модулем в таблице macToPort. После создания правила строка #7 передает новое правило в коммутатор, управляемый контроллером POX.

Изменение обучающего модуля L2 с добавлением логики безопасности

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

Необходимый патч можно загрузить в разделе Загрузки. Извлеките файл ISS.patch из ZIP-файла и примените его к оригинальному обучающему модулю L2.

Перейдите в папку с файлом l2_learning.py:

# cd ~/controller/pox/pox/forwarding

Примените патч:

# patch  < ISS.patch

Описание файла ISS.patch

Запись портов, к которым подключается устройство ISNP

В первом разделе файла ISS.patch определены две глобальные переменные, куда записываются порты, к которым подключен ISNP, как показано в листинге 3.

Листинг 3. Первый раздел ISS.patch
@@ -32,6 +32,10 @@ 
 # Можно переопределить в командной строке. 
 _flood_delay = 0 

+# Глобальная переменная для записи порта ввода-вывода, к которому подключен ISNP 
+_ISNP_ingress_port = -1 
+_ISNP_egress_port =  -1 
+

Следующий раздел ISS.patch инициализирует глобальные переменные при запуске модуля, как показано в листинге 4.

Листинг 4. Вторая часть ISS.patch
-def launch (transparent=False, hold_down=_flood_delay): 
+def launch (ISNP_ingress_port=-1, ISNP_egress_port=-1, transparent=False, hold_down=_flood_delay): 
   """ 
   Starts an L2 learning switch. 
   """ 
@@ -195,7 +226,15 @@ 
     global _flood_delay 
     _flood_delay = int(str(hold_down), 10) 
     assert _flood_delay >= 0 
+    global _ISNP_ingress_port 
+    _ISNP_ingress_port = int(str(ISNP_ingress_port),10) 
+    assert _ISNP_ingress_port > 0 
+    global _ISNP_egress_port 
+    _ISNP_egress_port = int(str(ISNP_egress_port),10) 
+    assert _ISNP_egress_port > 0 
   except: 
     raise RuntimeError("Expected hold-down to be a number") 

   core.registerNew(l2_learning, str_to_bool(transparent)) 
+  print "ISNP_ingress_port=%d, ISNP_egress_port=%d"%(_ISNP_ingress_port, _ISNP_egress_port) 
+  print "Secured l2 learning switch starting..."

Определение нового потока

В следующем разделе ISS.patch определяет изменения кода, как показано в листинге 5.

Листинг 5. Определение нового потока
@@ -163,16 +167,44 @@ 
1        drop(10) 
2        return 
3      # 6
4  -   log.debug("installing flow for %s.%i -> %s.%i" % 
5  -             (packet.src, event.port, packet.dst, port)) 
6  +   # Сюда мы вставляем код безопасности
8  +   in_port = event.port # which port sent the packet 
9  +   out_port = port # which port should we send the packet to 
10 + 
11 +   # Если пакет отправлен из порта ввода-вывода ISNP, то никаких правил передавать не нужно  
12 +  if port==_ISNP_ingress_port or port==_ISNP_egress_port or event.port==_ISNP_ingress_port or event.port==_ISNP_egress_port: 
13 +       return 
14 +       
15 +   log.info("Controller received flow [%s->%s] sent from port %i to port %i" % 
16 +           (packet.src, packet.dst, in_port, port)) 
17 +

Строка #3 позволяет правильно определить новый поток, переданный из ovs-internal в контроллер POX. На данном этапе обучающий модуль L2 построил таблицу соответствия MAC-адресов и портов, так что известно, какой порт получил поток и в какой порт направлять пакет в строках #8 и #9. Строка #12 гарантирует отсутствие замкнутой петли в ovs-internal, предотвращая создание правил для портов ISNP.

Построение правил для переадресации трафика в устройство ISNP

Обнаружив новый поток в ovs-internal, необходимо перенаправить его в устройство ISNP. Для каждого нового потока нужно передать в ovs-internal два правила управления потоком. Одно правило направляет поток во входной порт ISNP, а другое – из выходного порта ISNP в порт назначения. Эти правила выполняются с помощью изменений в коде, показанных в листинге 6.

Листинг 6. Правила для нового потока в ovs-internal
1  +        log.info("\tRedirecting flow [%s->%s] sent from port %i to port %i" % 
2  +                  (packet.src, packet.dst, in_port, _ISNP_ingress_port)) 
3  + 
4          msg = of.ofp_flow_mod() 
5  -       msg.match = of.ofp_match.from_packet(packet, event.port) 
6  -       msg.idle_timeout = 10 
7  +       msg.match.in_port = in_port 
8  +       msg.match.dl_src = packet.src 
9  +       msg.match.dl_dst = packet.dst 
10 +       msg.hard_timeout = 30 
11 +       msg.actions.append(of.ofp_action_output(port = _ISNP_ingress_port)) 
12 +       self.connection.send(msg) 
13 + 
14 +       log.info("\tRedirecting flow [%s->%s] sent from port %i to port %i" % 
15 +                 (packet.src, packet.dst, _ISNP_egress_port, port)) 
16 + 
17 +       msg = of.ofp_flow_mod() 
18 +       msg.match.in_port = _ISNP_egress_port 
19 +       msg.match.dl_src = packet.src 
20 +       msg.match.dl_dst = packet.dst 
21         msg.hard_timeout = 30 
22         msg.actions.append(of.ofp_action_output(port = port)) 
23 -       msg.data = event.ofp # 6a 
24 -       self.connection.send(msg) 
25 +       self.connection.send(msg) 
26 +
27 +       msg = of.ofp_packet_out() 
28 +       msg.actions.append(of.ofp_action_output(port = _ISNP_ingress_port)) 
29 +       msg.data = event.ofp 
30 +       msg.in_port = event.port 
31 +       self.connection.send(msg)

Модуль создает первое правило и перемещает его из строки #1 строку #12. В строке #11 выходной порт перенаправляется во входной порт ISNP. Создается второе правило и перемещается из строки #14 в строку #25. В строке 18 входной порт – это выходной порт ISNP, который перенаправляется в первоначальный порт назначения в строке #22.

Первый пакет, не соответствующий ни одному правилу ovs-internal, направляется в контроллер POX. Поэтому его необходимо вернуть для сохранения правильного потока. В строках #27-#31 создается новое сообщение, первый пакет в сообщении обращается, и оно возвращается в коммутатор.

Запуск нового модуля в контроллере POX

Прежде чем запустить исправленный модуль, нужно найти номер порта vs-internal, к которому подключен ISNP.

Получите сведения о портах ovs-internal:

# sudo ovs-ofctl show ovs-internal

Если предыдущая команда показывает, что ISNP подключен к портам 2 и 3, используйте следующую команду, чтобы запустить новый обучающий модуль L2 в контроллере POX.

# ./pox.py --verbose forwarding.ISS --XGS_ingress_port=2
               --XGS_egress_port=3 samples.pretty_log

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

Рисунок 4. Трафик между виртуальными машинами
Трафик между виртуальными машинами
Трафик между виртуальными машинами

Проверка защиты виртуальных машин устройством ISNP

В первом руководстве было показано, как проверить, защищает ли устройство ISNP сетевой трафик. Чтобы убедиться, что новый модуль в контроллере POX работает правильно, нужно запустить те же сценарии для его проверки. Новый модуль не заботится о том, из какого источника поступает трафик – внешнего или из другой виртуальной машины. Он только обнаруживает сетевые потоки и перенаправляет их в устройство ISNP. Поэтому нет необходимости контролировать жизненный цикл ВМ и настраивать правила. Когда ВM отправляет первый пакет, контроллер POX узнает об этом и вводит соответствующие правила регулирования потока в виртуальный коммутатор для защиты виртуальной машины. Все ВМ, подключенные к ovs-internal, получают защиту автоматически.

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1006125
ArticleTitle=Использование системы IBM Security Network Protection в программно-определяемой сети на базе OpenFlow
publish-date=05152015