Развертывание Ibm Security Network Protection На Open Vswitch

Добрый день всем жителям Хабро! В этой статье вы узнаете, как настроить IBM Security Network Protection (XGS5100) в программно-определяемой сети (SDN) на базе Open vSwitch и защитить все ваши виртуальные активы.

Open vSwitch — это виртуальный коммутатор на базе OpenFlow, широко используемый в облачных средах.

Программно-определяемая сеть (SDN) — это технология развертывания облака, которая обеспечивает масштабируемую и гибкую среду, соответствующую динамическому характеру самого облака.

Вы узнаете, как развернуть IBM Security Network Protection (ISNP) в OpenFlow с поддержкой коммутатора SDN. Откройте vSwitch и посмотрите, насколько легко можно развернуть ISNP в среде SDN.

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

Программно-определяемые сети SDN — это новый архитектурный подход, целью которого является обеспечение гибкости сети в соответствии с динамикой современной среды.

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

Не только это Этот процесс занимает много времени у администратора и не может быть решен одним лишь бубном; это также несет в себе опасность получить кучу ошибок.

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

В традиционных сетях плоскость управления реализована в устройствах передачи данных, и эта реализация зависит от поставщика.

В SDN эти уровни разделены, управление осуществляется централизованно для всего сетевого оборудования внутри предприятия (независимо от производителя оборудования).

Эта архитектура обеспечивает простой и быстрый способ управления потоком трафика.

Облачные среды требуют динамического распределения ресурсов.

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

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

OpenFlow SDN требует взаимодействия между уровнем централизованного управления и уровнем инфраструктуры (реализованным на физических устройствах).

Протокол OpenFlow от Фонд открытых сетей — это протокол SDN, который обеспечивает такую связь.

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

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

Открыть vSwitch Open vSwitch — это виртуальный коммутатор, лицензированный под Apache 2.0. Обычно он устанавливается на сервере для управления трафиком гипервизора, обеспечивая динамическую сетевую среду.

Open vSwitch поддерживает ряд протоколов управления трафиком, включая NetFlow, sFlow, SPAN, RSPAN, CLI, 802.1ag и OpenFlow. ИСНП ISNP — продукт, сочетающий в себе функции системы предотвращения вторжений и комплексного контроля приложений.

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

В зависимости от репутации приложения ISNP может разрешить или заблокировать соединение.

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

Интегрированная с другими функциями безопасности система предотвращения вторжений обеспечивает быстрое развертывание и простоту администрирования.

Подготовка Мы будем использовать 64-разрядную версию Ubuntu 12.04 LTS с поддержкой до апреля 2017 года.

Мы установили Ubuntu на «голое железо», а не на виртуальную машину.

Использование «голого железа» для установки гипервизора KVM обеспечивает хорошую производительность виртуальной машины.

Сервер должен иметь как минимум три сетевых интерфейса: один для удаленного доступа и два для подключения к ISNP напрямую к портам безопасности (как показано на рис.

1).

Рисунок 1

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

Настройка гипервизора KVM Виртуальная машина (KVM) — это инфраструктура виртуализации ядра Linux, превращающая его в гипервизор.

Перед установкой Ubuntu активируйте набор команд ВТ-д в процессоре, в настройках биоса, Рекомендуемый дистрибутив — Ubuntu 12.04 LTS. После загрузки системы на жесткий диск вам будет предложено выбрать дополнительные компоненты Ubuntu из коробки.

В главе выбор программного обеспечения должен быть выбран Хост виртуальной машины И OpenSSH-сервер Рис.

2

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

Для меня, а также для всех, кто неожиданно ослеп, или пропустил нужную строку, или по какой-то другой причине забыл выбрать Хост виртуальной машины , можно установить необходимые компоненты KVM с помощью следующей команды: # sudo apt-get install qemu-kvm libvirt-bin. Чтобы завершить установку гипервизора KVM, выполните следующие действия:

  1. Убедитесь, что ваш системный дистрибутив обновлен: # sudo apt-get update && apt-get dist-upgrade
  2. Убедитесь, что ваш процессор поддерживает KVM: # судо квм-ок.

  3. Убедитесь, что в BIOS активирована функция VT-d и что ваш процессор не слишком старый для работы с KVM.
  4. Добавьте пользователя в группу KVM: # sudo gpasswd -a $USER kvm
  5. Добавьте пользователя в группу libvirtd: # sudo gpasswd -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: # перезапуск службы sudo libvirt-bin. При желании вы можете установить virt-manager: # sudo apt-get install virt-manager. Он утверждает, что имеет удобный интерфейс для настройки виртуальных машин.

Настройка Open vSwitch Чтобы настроить Open vSwitch, вам необходимо установить все необходимые компоненты Open vSwitch (сделаем Открыть 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 и он вам не снился: # лсмод | grep openvswitch. И если вам вдруг захочется проверить, ovsdb-сервер И овс-vswitchd затем используйте эту команду: # статус sudo service openvswitch-switch Вы должны увидеть это:

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

Настройка Open vSwitch Следующий шаг демонстрирует, как настроить Open vSwitch и использовать интерфейс eth0 в качестве восходящего порта.

После этого Виртуальные машины подключатся к коммутатору и получат доступ к сети.

Чтобы еще раз убедиться, что вы смышлены, ваш Open vSwitch готов к использованию и вы все сделали правильно, выполните следующие команды:

  1. Убедитесь, что вы загрузили модуль Open vSwitch: # лсмод | grep openvswitch .

    Вы должны увидеть что-то похожее на это: # openvswitch 47849 0

  2. Проверьте статус всех сервисов Open vSwitch: # статус sudo service openvswitch-switch.
Вы должны увидеть это:

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

Убедительно просим приступать к настройке после того, как вы убедитесь, что все сервисы 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. Необходимо соблюдать порядок ввода команд, иначе получится зацикливание.

Эти 2 порта будут работать, когда устройство 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 вам необходимо изменить настройки, чтобы они выглядели следующим образом:

# The loopback network interface auto lo iface lo inet loopback # The uplink on ovs-internal auto eth0 iface eth0 inet static address 0.0.0.0 # The interface for connecting to the protection ports on ISNP auto eth1 iface eth1 inet static address 0.0.0.0 # The interface for connecting to the protection ports on ISNP auto eth2 iface eth2 inet static address 0.0.0.0 # The Open vSwitch setting 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, настройки должны быть примерно такими:

# The loopback network interface auto lo iface lo inet loopback # The uplink on ovs-internal auto eth0 iface eth0 inet static address 0.0.0.0 # The interface for connecting to the protection ports on ISNP auto eth1 iface eth1 inet static address 0.0.0.0 # The interface for connecting to the protection ports on ISNP auto eth2 iface eth2 inet static address 0.0.0.0 # The primary network interface 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

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

В этой статье в качестве IPS использовался ISNP. Мы использовали стандартную систему X-Force IPS, а не сетевую политику управления пользователями и приложениями.

В результате активировалось только правило «любой любой».

Остальные правила, указанные в первоначальных настройках, поставляются с XGS5100 (версия 5.1).

Рис.

4

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

После настройки 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. Поскольку здесь использовался сервер Ubuntu 12.04 и мы не устанавливали X-сервер, мы не сможем запустить какую-либо программу с графическим интерфейсом.

Но если вдруг вы решите использовать Desktop Edition, то проблема будет решена и вы сможете напрямую получить доступ к вирт-менеджеру.

Чтобы запустить virt-manager на вашем KVM, используйте X переадресация (для просмотра программ с графическим интерфейсом на вашем локальном сервере) Если вы используете Linux, то для подключения к удаленному KVM вам необходимо запустить команду включения пересылки X. (X перенаправляет соединение с сервером через SSH): # ssh -X пользователь@ .

> .

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

После входа в удаленный KVM запустите virt-manager: #вирт-менеджер.

Если все правильно, отобразится графический интерфейс программы.

Рис.

5

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

Теперь давайте создадим первую виртуальную машину.

Рис.

6

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

Рис.

7

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

Он должен иметь хотя бы один vNIC (виртуальный сетевой интерфейс).

Рис.

8

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

Виртуальные сетевые адаптеры будут настроены позже, а пока закройте созданную виртуальную машину и вручную отредактируйте ее XML-файл: Отредактируйте /etc/libvirt/qemu/.

xml. Изначально настройки 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>

Измените настройки файла XML, чтобы они выглядели следующим образом:

<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 для загрузки обновленного XML-файла: # sudo virsh define /etc/libvirt/qemu/.

xml. Все! Покоряйте и разделяйте в созданной вами виртуальной машине.

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

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

Попробуйте установить любую операционную систему на свою виртуальную машину и попробуйте подключиться к сети.

Когда ваша виртуальная машина подключена к Open vSwitch, на ней должна работать сеть (в режиме моста) и DHCP-сервер.

Если DHCP-сервер недоступен, то IP-адрес виртуальной машине придется назначить вручную.

Из-за ошибки в Libvirt скрипт ovs-ifdown не указан в файле описания.

Вам необходимо выключить виртуальную машину и отсоединить ответвительное устройство (Ethernet) от коммутатора.

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

Рис.

9

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

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

(Рис.

9) Защита виртуальной машины от внешнего трафика Теперь нужно «обучить» ovs-internal проверять пакеты при передаче трафика в ISNP. Используйте команду ovs-ofctl, чтобы установить для правил SDN значение ovs-internal. Структура правил при работе со свитчем определяется стандартом OpenFlow. Повторите то же самое, чтобы защитить другие виртуальные машины.

Если вы установите неправильные правила, ваша виртуальная машина не сможет использовать сеть.

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

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

Вы должны знать два атрибута первой виртуальной машины: 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 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 LOCAL(ovs-internal): addr:e4:1f:13:6c:49:52 config: 0 state: 0

Цифры (от 1 до 4) — это номер порта, за которым в скобках следует имя устройства, подключенного к порту.

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

Итак, мы видим, что первая виртуальная машина подключена к порту 4 на ovs-internal, eth2 к порту 2 и eth3 к порту 3. Все эти значения вы увидите в правилах управления коммутатором.

Обратите внимание, что номер порта на коммутаторе может измениться после перезагрузки сервера.

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

eth0 не всегда будет на первом порту.

Предположим, что 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

Правила по правилам

Rule 01: Flush every rule on ovs-internal Rule 02: If the flow is sent from the uplink (eth0 @ port #1) and the destination MAC is “52:54:00:aa:bb:cc” then forward the flow to eth1@port#2. Rule 03: After ISNP inspected the flow, it will be forwarded to eth2@port#3. Therefore, if the flow is sent from port#3 and the destination MAC is “52:54:00:aa:bb:cc” then it should be forward the port that the first VM is connected to (port#4).

Rule 04: Forward every packets sent from the first VM (port#4) to eth2 (port #3).

Rule 05: It is the default rule to handle the broadcast/multicast traffic. This rule has the lowest priority.

Синие линии на рис.

10 показывают, как коммутатор пересылает трафик от внешнего компьютера к ISNP, а затем к первой виртуальной машине.

Рис.

10

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

С помощью этой команды вы можете сбросить все текущие правила на ovs-internal и посмотреть, сколько пакетов уничтожено каждым правилом: # sudo ovs-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 через пятый порт. Предположим, что MAC-адрес второй виртуальной машины — 52:54:00:AA:CC:DD. Вы должны установить следующие правила для 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

Правила по правилам

Rule 06–08: These rules protect the second VM from the external traffic. Rule 09: Because you must take care of the inter-vm traffic now, you need to tell the switch how to forward the inter-vm traffic after ISNP inspects it. This rule says that after ISNP returns the traffic — and if the destination is to the first VM — the traffic should be forwarded to port #4. Rule 10: After ISNP inspects the traffic, it will be forwarded to port #2. This rule forwards the traffic to port #5 if the destination is the second VM.

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

Рис.

11

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

Убедитесь, что все правила, установленные для ovs-internal, верны: # sudo ovs-ofctl dump-flows ovs-internal. Здесь вы также можете проверить работу ISNP, запустив тестирование на проникновение с одной виртуальной машины на другую.

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

Перед проверкой у нас есть возможность выбрать график, который нас интересует. Рис.

12

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

Рекомендуется использовать» Подробности по пользователю ".

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

13. Рис.

13

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

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

3) Запустите веб-сервер на вашей виртуальной машине.

Если он работает в Linux, используйте эту команду и запустите веб-сервер на порту 8000: # python -m SimpleHTTPServer. Вовремя Теги: #сети #информационная безопасность #linux #ibm #информационная безопасность

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.