Содержание


Развертывание IBM Security Network Protection в среде Open vSwitch

Сетевая безопасность в программно-определяемых сетях

Comments

Программно определяемые сети (SDN) — это технология, предназначенная для облачных установок, которая обеспечивает масштабируемую и гибкую среду, соответствующую динамической природе облака. Из этой статьи вы узнаете, как развернуть IBM Security Network Protection (ISNP) на коммутаторе SDN с поддержкой OpenFlow – Open vSwitch, – чтобы убедиться, как легко развернуть ISNP в SDN-среде.

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

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

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

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

OpenFlow

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

Open vSwitch

Open vSwitch – это виртуальный коммутатор с открытым исходным кодом, распространяемый по лицензии Apache 2.0. Обычно он устанавливается на сервере для управления трафиком в гипервизоре, чтобы создать динамическую сетевую среду. Open vSwitch поддерживает ряд протоколов, включая NetFlow, sFlow, SPAN, RSPAN, CLI и 802.1ag. Он также поддерживает OpenFlow как метод управления потоком трафика.

ISNP

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

Функциональность предотвращения вторжений ISNP реализована в модуле анализа протокола (PAM), разработанном группой IBM X-Force R&D. Этот модуль добавляет современный протокол и механизмы эвристического анализа для обнаружения подписи. Как сказано в боковой врезке, лаборатория NSS недавно проверила эффективность механизма PAM с использованием GX7800. Общая результирующая эффективность достигает 95,7%.

Настройка среды

Операционная система, которую мы использовали, – это выпуск с долгосрочной поддержкой (LTS) 64-разрядной Ubuntu 12.04, поддержка которого гарантирована до апреля 2017 года. Мы установили Ubuntu не на виртуальную машину (ВМ), а на «голый» сервер. Использование голого сервера для установки гипервизора KVM обеспечивает достаточную производительность ВМ. Однако если нужно запускать гипервизор KVM на виртуальной машине, то для получения инструкций можно выполнить поиск в Интернете по ключевой фразе «nested KVM».

Используемый голый сервер должен иметь по крайней мере три сетевых карты (NIC): одну для удаленного доступа и две для подключения к ISNP-устройству. На рисунке 1 показана схема настроенной среды. Две сетевых карты на сервере подключаются непосредственно к портам защиты устройства ISNP. На рисунке 1 показана модель ISNP XGS5100.

Рисунок 1. Окончательная схема установки
Схема с тремя NIC
Схема с тремя NIC

Установка гипервизора KVM

Виртуальная машина на основе ядра (KVM) — это инфраструктура виртуализации ядра Linux, которая превращает его в гипервизор. Прежде чем установить Ubuntu, включите в ЦП набор инструкций VT-d в настройках BIOS (см. раздел Ресурсы). Обычно это можно сделать в разделе дополнительной настройки меню BIOS.

Рекомендуется дистрибутив Linux-Ubuntu 12.04 LTS. При установке Ubuntu 12.04 выполните стандартные инструкции. Затем при выборе программного обеспечения укажите Virtual Machine host и OpenSSH server (чтобы разрешить удаленный доступ к серверу). См. рисунок 2.

Рисунок 2. Выбор VM host и OpenSSH server
Выбор VM host и OpenSSH server
Выбор VM host и OpenSSH server

Если вы забыли выбрать Virtual Machine host во время установки, то необходимые компоненты KVM можно установить с помощью следующей команды: #sudo apt-get install qemu-kvm libvirt-bin.

После установки выполните следующие шаги, чтобы завершить установку гипервизора KVM. Во-первых, убедитесь в актуальности своей установки Ubuntu: # sudo apt-get update && apt-get dist-upgrade.

Убедитесь, что процессор поддерживает набор инструкций, необходимый для KVM: #sudo kvm-ok.

Если ответом команды kvm-ok будет не KVM acceleration can be used, то либо вы не включили в BIOS функцию VT-d, либо у вас слишком старый процессор для запуска гипервизора KVM.

Добавьте пользователя в группу kvm: # sudo gpasswd -a$USER kvm. Добавьте пользователя в группу libvirtd: # sudogpasswd -a $USER libvirtd. Затем добавьте в файл /etc/libvirt/qemu.conf следующие параметры:

# sudo vi /etc/libvirt/qemu.conf
  user = "root"
  group = "kvm"
  security_driver = "none"
     cgroup_device_acl = [ 
      "/dev/null", "/dev/full", "/dev/zero", 
      "/dev/random", "/dev/urandom", 
      "/dev/ptmx", "/dev/kvm", "/dev/kqemu", 
      "/dev/rtc", "/dev/hpet", "/dev/net/tun", 
   ] 
   clear_emulator_capabilities = 0

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

Перезапустите libvirt-bin, чтобы загрузить новые параметры qemu: # sudoservice libvirt-bin restart.

При желании установите virt-manager: # sudo apt-get installvirt-manager. Этот шаг обеспечивает удобный интерфейс для настройки виртуальных машин.

Настройка Open vSwitch

Чтобы настроить Open vSwitch, установите все компоненты, необходимые для Open vSwitch (мы использовали Open vSwitch 1.4.0):

# sudo apt-get install openvswitch-controller openvswitch-switch 
openvswitch-datapath-source openvswitch-datapath-dkms

Примечание. При установке этих пакетов поверх ядра версии 3.8 могут возникнуть некоторые проблемы. На момент написания этой статьи группа Ubuntu работала над их решением. Хорошая новость: в ядре 3.8 уже есть нативный модуль openvswitch, так что строить свой собственный не нужно. Как только модуль openvswitch загружен, система готова к работе.

Убедитесь, что модуль openvswitch загружен должным образом: # lsmod |grep openvswitch. Используйте следующую команду, чтобы узнать, имеются ли ovsdb-server и ovs-vswitchd и работают ли они: # sudo serviceopenvswitch-switch status. Ответ должен быть таким:

ovsdb-server is running with pid xxxx
ovs-vswitchd is running with pid yyyy

Настройка Open vSwitch

Следующие шаги демонстрируют, как настроить один Open vSwitch и использовать eth0 в качестве канала восходящей связи. После этого ВМ будут подключены к указанному коммутатору для доступа к сети.

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

Проверьте, загружен ли модуль Open vSwitch: # lsmod | grepopenvswitch. Ответ должен быть таким: # openvswitch 47849 0. Проверьте статус всех служб Open vSwitch: # sudo serviceopenvswitch-switch status. Ответ должен быть таким:

ovsdb-server is running with pid xxxx
ovs-vswitchd is running with pid yyyy

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

Сброс eth0:

# sudo ifconfig eth0 0

Создание нового vSwitch:

# sudo ovs-vsctl add-br ovs-internal

Добавление eth0 к ovs-internal:

# sudo ovs-vsctl add-port ovs-internal eth0

Восстановление ovs-internal:

# sudo ifconfig ovs-internal up

Задание IP-адреса ovs-internal:

Статический IP-адрес:

# sudo ifconfig ovs-internal <ip> <netmask>
# sudo route add default gw <gw_ip>

DHCP:

# sudo dhclient ovs-internal

Добавление eth1 и eth2 к ovs-internal. Введите следующие команды в указанном порядке:

# sudo ovs-vsctl add-port ovs-internal eth1
# sudo ovs-ofctl mod-port ovs-internal eth1 down
# sudo ovs-ofctl mod-port ovs-internal eth1 noflood
# sudo ovs-vsctl add-port ovs-internal eth2
# sudo ovs-ofctl mod-port ovs-internal eth2 down
# sudo ovs-ofctl mod-port ovs-internal eth2 noflood

Эти команды останавливают eth1 и eth2 и задают для них параметр noflood. Важен порядок следования команд: если его не соблюдать, сеть не будет замкнута. Включите эти два порта, когда устройство ISNP будет готово и к eth1 и eth2 будут подключены кабели.

После окончания настройки Open vSwitch можно использовать ovs-vsctl, чтобы посмотреть состояние коммутаторов:

# sudo ovs-vsctl show 
ed1f5e9a-8c2e-4a1e-9fe8-73740f57589c 
    Bridge ovs-internal 
        Port ovs-internal 
            Interface ovs-internal 
                type: internal 
        Port "eth2" 
            Interface "eth2" 
        Port "eth1" 
            Interface "eth1" 
        Port "eth0" 
            Interface "eth0" 
    ovs_version: "1.4.0+build0"

Если нужно сделать параметр Open vSwitch персистентным, то можно изменить /etc/network/interfaces, добавив параметры персистентности.

Для настройки статического IP-адреса измените параметры на что-то вроде этого:

# Сетевой интерфейс обратной связи 
auto lo 
iface lo inet loopback 

# Восходящий канал в ovs-internal
auto eth0
iface eth0 inet static 
        address 0.0.0.0 

# Интерфейс для подключения к портам защиты в ISNP
auto eth1
iface eth1 inet static 
        address 0.0.0.0 

# Интерфейс для подключения к портам защиты в ISNP
auto eth2
iface eth2 inet static 
        address 0.0.0.0 

# Настройка Open vSwitch 
auto ovs-internal
iface ovs-internal inet static 
        address 10.40.28.1 
        netmask 255.255.128.0 
        network 10.40.0.0 
        broadcast 10.40.127.255 
        gateway 10.40.0.1 
        dns-nameservers 10.40.1.1

Для настройки DHCP измените параметры на что-то вроде этого:

# Сетевой интерфейс обратной связи 
auto lo 
iface lo inet loopback 

# Восходящий канал в ovs-internal
auto eth0
iface eth0 inet static 
        address 0.0.0.0 

# Интерфейс для подключения к портам защиты в ISNP
auto eth1
iface eth1 inet static 
        address 0.0.0.0 

# Интерфейс для подключения к портам защиты в ISNP
auto eth2
iface eth2 inet static 
        address 0.0.0.0 

# Основной сетевой интерфейс
auto ovs-internal
iface ovs-internal inet dhcp

Важно сделать персистентными параметры noflood в eth1 и eth2. Однако нехорошо делать это в /etc/network/interfaces, поэтому необходимо добавить в файл /etc/rc.local следующие команды:

# sudo vi /etc/rc.local
ovs-ofctl mod-port ovs-internal eth1 noflood
ovs-ofctl mod-port ovs-internal eth2 noflood

Настройка ISNP

Установите устройство ISNP и подключите eth1 и eth2 к его портам защиты (как показано на рисунке 1). После завершения установки можно войти в локальный интерфейс управления, чтобы увидеть панель управления ISNP.

Рисунок 3. Панель управления ISNP
Панель управления ISNP
Панель управления ISNP

В этой статье мы использовали ISNP только как IPS. Мы не используем функцию Network Access Policy управления приложением в зависимости от пользователя и сведения о репутации IP; мы используем политику IPS по умолчанию X-Force. Включено только правило "any any" в конце. Остальные показанные правила – это первоначальный набор правил, поставляемый с XGS5100 версии 5.1.

Рисунок 4. Выбор только политики IPS по умолчанию X-Force
Выбор политики IPS по умолчанию X-Force
Выбор политики IPS по умолчанию X-Force

Когда ISNP настроен и кабели подключены, включите порт eth1 и порт eth2 в ovs-internal:

# sudo ovs-ofctl mod-port ovs-internal eth1 up
# sudo ovs-ofctl mod-port ovs-internal eth2 up

Не забудьте проверить и перепроверить, что параметр noflood задан правильно как для eth1, так и для eth2. В противном случае, подключив кабели, вы замкнете свою сеть напрямую.

Создание первой виртуальной машины и ее подключение к ovs-internal

Сначала необходимо подготовить сценарий для автоматического подключения виртуальный сетевой карты виртуальной машины к ovs-internal после включения питания. Скопируйте этот код в файл /etc/ovs-ifup:

# sudo vi /etc/ovs-ifup
     #!/bin/sh 
     switch='ovs-internal' 
     /sbin/ifconfig $1 0.0.0.0 up 
     ovs-vsctl add-port ${switch} $1

Добавьте в сценарий разрешение выполнения: # sudo chmod +x/etc/ovs-ifup.

Создание новой виртуальной машины с помощью virt-manager

Для создания новой виртуальной машины можно использовать virt-manager. Так как здесь используется сервер Ubuntu версии 12.04, на нем нельзя запустить GUI-программу, потому что у нас не установлен X-сервер. Если выбрать desktop-версию, где X-сервер установлен, то можно получить непосредственный доступ к virt-manager. Чтобы запустить virt-manager из гипервизора KVM, можно использовать X-форвардирование (см. раздел Ресурсы) для отображения графического интерфейса пользователя на локальном X-сервере.

Если для удаленного подключения к гипервизору KVM используется рабочая станция Linux®, выполните следующую команду, чтобы включить X-форвардирование при подключении к серверу с помощью Secure Shell (SSH): # ssh -Xuser@<server_ip>.

Вместо eth0, вы должны получить IP-адрес своего сервера от ovs-internal: # ifconfigovs-internal>.

Войдя в удаленный гипервизор KVM, вы сможете запустить virt-manager: # virt-manager. На экране должен появиться графический интерфейс пользователя.

Рисунок 5. Запуск virt-manager для отображения графического интерфейса пользователя
Запуск virt-manager для отображения графического интерфейса пользователя
Запуск virt-manager для отображения графического интерфейса пользователя

Теперь можно приступать к созданию первой ВМ.

Рисунок 6. Шаг 1 по созданию виртуальной машины
Создание виртуальной машины
Создание виртуальной машины
Рисунок 7. Шаг 2 по созданию виртуальной машины
Создание виртуальной машины
Создание виртуальной машины

Новая ВМ должна иметь по крайней мере одну VNIC.

Рисунок 8. Новая ВМ должна иметь одну VNIC.
VNIC на виртуальной машине
VNIC на виртуальной машине

О настройке VNIC пока беспокоиться не нужно – мы изменим ее позже вручную. После создания виртуальной машины сразу же остановите ее, чтобы можно было вручную изменить XML-файл описания новой ВМ. Отредактируйте файл /etc/libvirt/qemu/<VM NAME>.xml. Первоначальная настройка VNIC в XML-файле должна выглядеть примерно так:

# sudo vi /etc/libvirt/qemu/<VM NAME>.xml
    <interface type='bridge'> 
      <mac address='xx:xx:xx:xx:xx:xx'/> 
      <source bridge='xxxx'/>
      <model type='virtio'/> 
      <address type='pci' domain='0x0000' bus='0x00'
            slot='0x03' function='0x0'/> 
    </interface>

Измените настройки VNIC следующим образом:

<interface type='ethernet'> 
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <script path='/etc/ovs-ifup'/>
      <model type='virtio'/> 
      <address type='pci' domain='0x0000' bus='0x00'
            slot='0x03' function='0x0'/> 
</interface>

Скомандуйте гипервизору KVM загрузить это новое описание ВМ: # sudo virshdefine /etc/libvirt/qemu/<VM NAME>.xml.

Теперь можно включить новую виртуальную машину. Выполнив следующие команды, вы должны увидеть, что в ovs-internal создан новый порт.

# sudo ovs-vsctl show 
# sudo ovs-ofctl show ovs-internal

Теперь можно установить на ВМ любую ОС и попытаться получить доступ к сети. Заметьте, что когда ВМ подключена к Open vSwitch, сеть на ней находится в режиме моста, поэтому в вашей среде должен работать DHCP-сервер. Если DHCP-сервера нет, может потребоваться ручное назначение IP-адреса новой виртуальной машине.

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

Рисунок 9. Ошибка загрузки
Ошибка загрузки
Ошибка загрузки

Чтобы вручную отключить устройство подсоединения к сети от ovs-internal, используйте следующую команду: # sudo ovs-vsctl del-port ovs-internaltapN.

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

Защита ВМ от внешнего трафика

Теперь научите ovs-internal, как перенаправлять трафик на устройство ISNP для проверки пакетов. Команда ovs-ofctl применяется для установки правил SDN вручную на ovs-internal. Здесь начинается использование OpenFlow на виртуальном коммутаторе. Структура правил, передаваемых коммутатору, определяется в стандарте OpenFlow. Выполните те же шаги для защиты других виртуальных машин на своем сервере.

Если передать коммутатору неправильные правила, то ВМ не сможет использовать сеть. Чтобы восстановить подключение к сети, сбросьте коммутатор с помощью следующих команд:

# sudo ovs-ofctl del-flows ovs-internal
# sudo ovs-ofctl add-flow ovs-internal action=normal

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

Из первой ВМ нужно взять два атрибута: MAC-адрес первой ВМ и номер порта ovs-internal, к которому она подключена. MAC-адрес, назначенный виртуальной сетевого карте, можно найти в файле /etc/libvirt/qemu/<ИМЯ ВМ>.xml:

#sudo vi /etc/libvirt/qemu/<VM NAME>.xml
   <interface type='ethernet'>
      ... 
      <mac address='xx:xx:xx:xx:xx:xx'/> 
      ... 
   </interface>

Кроме того, можно просто войти в свою виртуальную машину и получить MAC-адрес, присвоенный сетевому устройству.

Второе, что вам нужно, – это номер порта ovs-internal, к которому подключена ВМ. Выполните следующую команду, чтобы получить состояние порта ovs-internal: # sudo ovs-ofctl showovs-internal.

Результат должен выглядеть следующим образом:

OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000e41f136c4952 
n_tables:255, n_buffers:256 
features: capabilities:0xc7, actions:0xfff 
 1(eth0): addr:e4:1f:13:6c:49:52 
     config:     0 
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 2(eth1): addr:e4:1f:13:6c:aa:56
     config:     NO_FLOOD
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 3(eth2): addr:e4:1f:13:6c:ab:57
     config:     NO_FLOOD
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 4(tap0): addr:be:cc:7b:8b:c0:04 
     config:     0 
     state:      0 
     current:    10MB-FD COPPER 
 LOCAL(ovs-internal): addr:e4:1f:13:6c:49:52 
     config:     0 
     state:      0

Цифры, выделенные жирным шрифтом, – это номер порта, а строки, выделенные курсивом, – имена устройств, подключенных к этому порту. Каждая VNIC виртуальной машины соответствует определенному соединительному устройству гипервизора. Таким образом, как видите, первая ВМ подключена к порту 4 ovs-internal. Кроме того, eth2 подключена к порту 2, а eth3 – к порту 3. Вы увидите эти цифры в правилах, передаваемых коммутатору.

Обратите внимание, что после перезагрузки сервера номер порта коммутатора может измениться. В следующих правилах, передаваемых в ovs-internal, необходимо использовать правильный номер порта. Иногда eth0 подключается не к порту 1. Не используйте в правилах неправильный номер порта восходящего канала, иначе сетевой трафик не будет проходить через устройство ISNP.

Предположим, что MAC-адрес первой виртуальной машины – 52:54:00:aa:bb:cc. Передайте в ovs-internal следующие правила:

Rule 01: # sudo ovs-ofctl del-flows ovs-internal
Rule 02: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=1,dl_dst=52:54:00:ac:bb:cc,idle_timeout=0,action=output:2
Rule 03: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=3,dl_dst=52:54:00:ac:bb:cc,idle_timeout=0,action=output:4
Rule 04: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=4,idle_timeout=0,action=output:3
Rule 05: # sudo ovs-ofctl add-flow ovs-internal 
priority=0,action=normal

Вот объяснение каждого правила:

Правило 01: Передать каждое правило в ovs-internal
Правило 02: Если поток направляется из uplink (eth0 @ порт #1) и MAC-адрес назначения
         
«52:54:00:aa:bb:cc», то передать поток в eth1@port#2.Правило 03: после того как ISNP проверит поток, он направляется в eth2@port#3. Таким образом, 
         если поток передан из порта #3 и целевой MAC-адрес «52:54:00:aa:bb:cc»,  
         то он должен передаваться в порт, к которому подключена первая виртуальная машина (порт #4).
Правило 04: передать все пакеты, поступающие от первой ВМ (порт #4), в eth2 (порт #3).
Правило 05: это правило по умолчанию для обработки широковещательного/многоадресного трафика. Оно имеет самый низкий приоритет.

Синие линии на рисунке 10 показывают, как коммутатор направляет трафик, поступающий от внешней машины, в ISNP, а затем в первую ВМ.

Рисунок 10. Перенаправление трафика
Перенаправление трафика
Перенаправление трафика

Можно распечатать все текущие правила на ovs-internal – и посмотреть, сколько пакетов удовлетворяют каждому правилу, – выполнив следующую команду: # sudoovs-ofctl dump-flows ovs-internal.

Результат должен выглядеть примерно так:

NXST_FLOW reply (0x4): 
   cookie=0x0, duration=4345.083s, table=0, n_packets=4637, n_bytes=441598, 
priority=100,in_port=4 actions=output:3 
   cookie=0x0, duration=4399.466s, table=0, n_packets=4618, n_bytes=449256,
priority=100,in_port=1,dl_dst=52:54:00:aa:bb:cc actions=output:2 
   cookie=0x0, duration=4363.898s, table=0, n_packets=4618, n_bytes=449256,
priority=100,in_port=3,dl_dst=52:54:00:aa:bb:cc actions=output:4 
   cookie=0x0, duration=4324.14s, table=0, n_packets=24095, n_bytes=1916023,
priority=0 actions=NORMAL

Теперь можно запустить тестирование первой виртуальной машины, чтобы увидеть, как ISNP защищает ее. В разделе «Проверка того, что устройство ISNP обеспечивает защиту ВМ» приведены некоторые простые тесты, которые проверяют, что ISNP действительно защищает ваши ВМ.

Создание и подключение к Open vSwitch второй ВМ

Вторую ВМ можно создать, клонировав первую с помощью virt-manager или путем создания новой ВМ вручную. Не забудьте изменить XML-файл, чтобы ВМ могла автоматически подключаться к ovs-internal.

Защита ВМ от внутреннего трафика

Чтобы получить номер порта, используемый второй ВМ, снова выполните команду ovs-ofctl: # sudo ovs-ofctl show ovs-internal.

Результат будет выглядеть примерно так:

OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000e41f136c4952 
n_tables:255, n_buffers:256 
features: capabilities:0xc7, actions:0xfff 
 1(eth0): addr:e4:1f:13:6c:49:52 
     config:     0 
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 2(eth1): addr:e4:1f:13:6c:aa:56
     config:     NO_FLOOD
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 3(eth2): addr:e4:1f:13:6c:ab:57
     config:     NO_FLOOD
     state:      0 
     current:    1GB-FD COPPER AUTO_NEG 
     advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG 
     supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG 
 4(tap0): addr:be:cc:7b:8b:c0:04 
     config:     0 
     state:      0 
     current:    10MB-FD COPPER 
 5(tap1): addr:be:cc:7b:8b:c0:05
     config:     0 
     state:      0 
     current:    10MB-FD COPPER 
 LOCAL(ovs-internal): addr:e4:1f:13:6c:49:52 
     config:     0 
     state:      0

Как видите, новое соединительное устройство подключено к ovs-internal через порт 5, к которому подключена вторая ВM.

Предположим, что MAC-адрес второй ВМ 52:54:00:aa:bb:cc. Нужно передать в ovs-internal следующие правила для ее защиты как от внешнего трафика, так и от трафика между ВМ.

Rule 06: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=1,dl_dst=52:54:00:ac:cc:dd,idle_timeout=0,action=output:2
Rule 07: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=3,dl_dst=52:54:00:ac:cc:dd,idle_timeout=0,action=output:5
Rule 08: # sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=5,idle_timeout=0,action=output:3
Rule 09: sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=2,dl_dst=52:54:00:ac:bb:cc,idle_timeout=0,action=output:4
Rule 10: sudo ovs-ofctl add-flow ovs-internal
priority=100,in_port=2,dl_dst=52:54:00:ac:cc:dd,idle_timeout=0,action=output:5

Вот объяснение каждого правила:

Правила 06–08: эти правила защищают вторую ВM от внешнего трафика.
Правило 09: Так как теперь нужно заботиться о трафике между ВМ, необходимо указать коммутатору, как пересылать трафик между ВМ после того, как ISNP проверит его. Это правило означает, что после того как ISNP возвратит трафик — и если он предназначен для первой ВM, — трафик необходимо направить в порт #4.
Правило 10: После того как ISNP проверит трафик, он направляется в порт #2. Если трафик предназначен для второй ВM, то это правило направляет его в порт #5.

Красные линии на рисунке 11 показывают новые правила, которые мы передали в коммутатор для защиты виртуальных машин от трафика между ВМ.

Рисунок 11. Новые правила защищают ВМ от трафика между ВМ
Новые правила защиты виртуальных машин
Новые правила защиты виртуальных машин

Для проверки того, что все правила правильно переданы в ovs-internal, можно использовать ovs-ofctl: # sudo ovs-ofctl dump-flowsovs-internal.

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

Проверка того, что устройство ISNP обеспечивает защиту ВМ

Самый простой способ проверить, что сетевой трафик пошел через устройство ISNP, — использовать Network Graphs в локальном интерфейсе местного управления ISNP. Перед проверкой сетевых графиков не забудьте предварительно направить в ВМ какой-нибудь трафик. На рисунке 12 видно, что можно выбрать одно из многих типов представлений.

Рисунок 12. Использование представления Traffic Detail by User
IP-адрес виртуальной машины
IP-адрес виртуальной машины

Мы рекомендуем использовать представление Traffic Detail by User, чтобы увидеть, появляются ли IP-адреса виртуальных машин в статистике сети, как показано на рисунке 13.

Рисунок 13. Статистика сети с IP-адресами виртуальных машин
Статистика сети
Статистика сети

Вы можете направить безвредную атаку на все свои ВМ, чтобы увидеть, действительно ли ISNP защищает их. ISNP заблокирует атаки, а Local Management Interface покажет событие безопасности.

Запустите в своей виртуальной машине веб-сервер. Если ВМ работает на Linux, можно использовать следующую команду для запуска веб-сервера через порт 8000: # python -mSimpleHTTPServer.

Когда веб-сервер работает, направьте на него атаку URL_MANY_SLASHES (см. раздел Ресурсы). Атаку можно отправить из одной виртуальной машины в другую или из внешнего компьютера. В обоих случаях ISNP заблокирует все атаки.

Отправить атаку URL_MANY_SLASHES очень легко. Просто используйте более 500 знаков косой черты в HTTP-запросе, чтобы запустить событие. Откройте веб-браузер и введите следующий URL-адрес:

http://<IP-адрес веб-сервера>:8000///////////////.....////////////////////////

Не забудьте ввести в URL-адрес не менее 500 знаков косой черты.

Для отправки атаки URL_MANY_SLASHES также можно использовать следующую команду:

# wget http://10.40.25.10:8000/`python -c "print '/'*500"`

После отправки атаки проверьте события безопасности в представлении Event Log. Выберите IPS Events, чтобы увидеть все события безопасности, заблокированные ISNP, как показано на рисунке 14.

Рисунок 14. События безопасности, заблокированные ISNP
События безопасности, заблокированные ISNP
События безопасности, заблокированные ISNP

Если в интерфейсе Local Management Interface события безопасности есть, то все в порядке.

Заключение

В этой статье описан процесс ручной настройки устройства ISNP (XGS5100) в программно-определяемой сети на базе Open vSwitch. Виртуальные коммутаторы этого типа обычно применяются в облачных средах. Процесс ручной настройки входящих потоков виртуального коммутатора сложен; он рассматривается в следующей статье этой серии, которая посвящена использованию OpenFlow–контроллера для управления потоками.


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


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1006119
ArticleTitle=Развертывание IBM Security Network Protection в среде Open vSwitch
publish-date=05152015