Розгортання IBM Security Network Protection в Open vSwitch

Всім хаброжителям доброго часу доби!

У цій статті ви зможете дізнатися, як налаштувати IBM Security Network Protection (XGS5100) в заснованої на Open vSwitch програмно-конфігурована мережі(SDN), і захистити-таки всі ваші віртуальні активи.

Open vSwitch — це віртуальний комутатор на основі OpenFlow, широко використовуваний в хмарних середовищах.

Software-defined Networking (SDN) — це технологія для розгортання хмари, що забезпечує масштабовану і гнучку середу, відповідну для динамічного характеру цього самого хмари.

Ви навчитеся розгортати IBM Security Network Protection (ISNP) у рамках OpenFlow з підтримкою SDN комутатора — Open vSwitch і побачите як легко ISNP можуть бути розгорнуті в середовищі SDN.
image


Програмно-конфігуровані мережі

SDN — новий архітектурний підхід, мета якого забезпечити мережеву гнучкість, підходящу для динаміки сучасної середовища. Існуючі мережеві технології є за своєю суттю статичними і їх важко змінити, так як невеликі мережеві зміни часто вимагають суттєвої переконфігурації всіх або більшої частини комутаторів, маршрутизаторів і міжмережевих екранів. Мало того, що
процес цей займає багато часу для адміністратора і не вирішується за допомогою одного лише бубна, він ще й несе в собі небезпеку отримати купу помилок.

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

В традиційних мережах рівень управління реалізується в пристроях передачі даних, і ця реалізація залежить від постачальника.
У SDN ці рівні розділені,
управління здійснюється централізовано для всього мережевого обладнання в рамках підприємства (незалежно від виробника обладнання). Ця архітектура забезпечує простий і швидкий спосіб для управління потоком трафіку.

Хмарні середовища вимагають динамічного розподілу ресурсів. Відкриті і приватні хмари мають віртуальні програми і сховища, так що наступний логічний крок — це віртуалізація мережі. А чому б і ні?!

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

OpenFlow

SDN вимагає взаємодії централізованого рівня управління з інфраструктурним рівнем (реалізованим у фізичних пристроях). Протокол OpenFlow від Open Networking Foundation — це протокол SDN, що забезпечує таку зв'язок. OpenFlow дозволяє детально контролювати трафік на всіх комутаторах і маршрутизаторів в мережі,
фізичних, так і віртуальних, незалежно від свого постачальника програмного
забезпечення.

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

Open vSwitch

Open vSwitch представляє з себе віртуальний комутатор під ліцензією Apache 2.0. Він, як правило, встановлюється на сервері для контролю трафіку в гипервизоре, забезпечуючи динамічне мережеву середу.

Open vSwitch підтримує ряд протоколів керування трафіком, в тому числі NetFlow, sFlow, SPAN, RSPAN, CLI, 802.1 ag і OpenFlow.

ISNP

ISNP — продукт поєднує функції системи запобігання вторгнень і складного контролю за додатками.
Він дає можливість контролю над усією активністю користувача, аналізуючи кожне з'єднання і визначаючи використовувані програми. У залежності від репутації додатки ISNP може дозволити або заблокувати з'єднання. Також ISNP може записувати інформацію додатків, що може бути корисним для уточнення політики, включаючи пропускну здатність.

Інтегрована з іншими захисними функціями система запобігання вторгнень забезпечує швидке розгортання і просте адміністрування.

Підготовка

Ми будемо використовувати 64-бітний Ubuntu 12.04 LTS з підтримкою до квітня 2017. Ми встановлювали Ubuntu на «голе залізо», а не на віртуальній машині. Використання «голого заліза» для установки KVM гіпервізора дає хорошу продуктивність для VM.

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

Рис.1
image

Налаштування KVM гіпервізора

Віртуальна машина (KVM) є інфраструктурою виртуализаци для ядра Linux, і перетворює його в гіпервізор.
Перед тим як зайнятися установкою Ubuntu, активуйте набір команд VT-d ЦПУ, в налаштуваннях BIOS,

Рекомендований дистрибутив — Ubuntu 12.04 LTS.

Після завантаження системи на жорсткий диск, вам буде запропоновано вибрати додаткові компоненти Ubuntu «з коробки».

У розділі software selection необхідно вибрати Virtual Machine host і OpenSSH server

Рис.2
image

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

Для завершення установки KVM гіпервізора, виконайте наступні дії:

  1. Переконайтеся, що дистрибутив системи оновлено: # sudo apt-get update && apt-get dist-upgrade
  2. Переконайтеся, що ваш процесор підтримує KVM: #sudo kvm-ok.
  3. Убедитеть що в BIOS активована функція VT-d і що ваш процесор не надто «стар» для роботи з KVM.
  4. Додати користувача до kvm group: # sudo gpasswd-a $USER kvm
  5. Додати користувача в libvirtd group:# sudo gpasswd-a $USER libvirtd


Потім, введіть /etc/libvirt/qemu.conf і додайте наступні параметри:

# sudo vi /etc/libvirt/qemu.conf
user = "root"
group = "kvm"
security_driver = "ні"
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 service libvirt-bin restart.

При бажанні ви можете встановити virt-manager :# sudo apt-get install virt-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 module, за цим немає необхідності самим збирати її.
Як тільки openvswitch module буде завантажений, так відразу ваша система буде готова до використання.

Ах так, переконайтесь що ви все таки завантажили openvswitch module і вам це не приснилося:# lsmod | grep openvswitch . А якщо ви раптом захочете перевірити запущено ovsdb-server і ovs-vswitchd, то використовуйте цю команду: # sudo service openvswitch-switch status

Ви повинні побачити це:
ovsdb-server is running with pid xxxx
ovs-vswitchd is running with pid yyyy


Конфігурування Open vSwitch

Наступний крок демонструє як сконфігурувати Open vSwitch і використовувати інтерфейс eth0 як порт uplink
Після цього Віртуальні Машини підключаться до комутатора і отримають доступ до мережі.

Щоб ще раз переконатися в тому, що ви «розумниця», ваш Open vSwitch готовий до використання і ви все зробили правильно, виконайте ці команди:

  1. Переконайтеся, що ви завантажили Open vSwitch module: # lsmod | grep openvswitch.
    Ви повинні побачити щось схоже на це:# openvswitch 47849 0
  2. Перевірте статус всіх сервісів Open vSwitch: # sudo service openvswitch-switch status .


Ви повинні побачити це:
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.
Необхідно дотримуватися порядок введення команд, не то отримаєте loop. Ці 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-серверів імен 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
image

Для цієї статті ISNP використовувався як IPS. Ми використовували стояла за замовчуванням X-Force IPS, а не мережеву політику контролю користувачів і додатків. У підсумку було активовано тільки правило «any any». Інші правила, зазначені в початкових налаштуваннях поставляються разом з XGS5100(версія 5.1)

Рис.4
image

Після налаштування 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, бо якщо ні, то при під'єднанні кабелів отримаєте loop.

Створення першої віртуальної машини та підключення її до ovs-internal

Для початку вам необхідно приготувати скрипт для підключення вашої віртуальної NIC на вашій віртуальній машині до 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 server і ми не встановили X-сервер, то ми не зможемо запустити яку або програму з GUI.
Але якщо раптом ви вирішили використовувати Desktop Edition, то проблема буде вирішена і ви можете отримати доступ до virt-manager безпосередньо.

Для запуску virt-manager на вашій KVM, використовуйте X forwarding(для перегляду GUI програм на вашому локальному сервері)

Якщо ви працюєте під Linux®, то для з'єднання з віддаленим KVM необхідно запустити команду активує X forwarding. (З'єднання X forwarding з сервера по протоколу SSH):# ssh-X user@<server_ip>.>.

Замість eth0 вам необхідно отримати IP-адреса вашого сервера від ovs-internal :# ifconfig ovs-internal>.

Після входу на віддалений KVM, запустіть virt-manager:# virt-manager.
Якщо все правильно, то відобразиться GUI програми.

Рис.5
image

Тепер створюємо першу віртуальну машину.

Рис.6
image

Рис.7
image

У неї повинен бути хоча б один vNIC (Virtualized Network Interface)

Рис.8
image

vNIC будуть отконфигурированы пізніше, а поки закрийте створену віртуальну машину і вручну змінити її XML-файл:Edit /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 скрипт не вказаний у файлі опису. Необхідно вимкнути віртуальну машину і відключити tap (Ethernet) пристрій від комутатора. Якщо цього не зробити, то повідомлення про помилку буде з'являтися і при наступних запусках віртуальної машини.

Рис.9
image

Щоб відключити 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


Ви повинні знати два атрибута з першої віртуальної машини: МАС-адресу та номер порту, через який ваша Віртуальна машина з'єднується з ovs-internal.

Подивитися МАС-адресу вашої віртуальної NIC можна тут:

/etc/libvirt/qemu/.xml:

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


Так само можна подивитися МАС-адресу, присваивающийся кожного мережного пристрою, безпосередньо на самій віртуальній машині.

Тепер вам потрібен номер порту, через який ваша Віртуальна машина з'єднується з 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) це номер порту, потім у дужках-назва підключеного до порту пристрою.

Кожне vNIC на віртуальній машині відображається як tap пристрій гіпервізора. Таким чином, ми можемо бачити, що перша віртуальна машина підключена до 4 порту на ovs-internal, eth2 до 2 порту, і eth3 до 3 порту. Всі ці значення ви побачите в правилах управління комутатором.

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

Необхідно використовувати вірний номер порту в наступних правилах управління ovs-internal, в іншому випадку мережевий трафік не буде проходити через 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
image

За допомогою цієї команди ви можете скинути всі поточні правила на ovs-internal і подивитися як багато пакетів «вбило» кожне правило: # sudo ovs-ofctl dump-flows ovs-internal.

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

NXST_FLOW reply (0x4): 
cookie=0x0 duration=4345.083 s, table=0, n_packets=4637, n_bytes=441598, 
priority=100,in_port=4 actions=output:3 
cookie=0x0 duration=4399.466 s, 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.898 s, 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.14 s, table=0, n_packets=24095, n_bytes=1916023,
priority=0 actions=NORMAL


Тепер ви можете перевірити роботу ISNP і запустити на першій віртуальній машині тести на проникнення.

В розділі«Verify that the ISNP device is protecting your virtual machines» є кілька простих тестів, для перевірки 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


Тут ми бачимо що нове tap пристрій підключено до 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
image

Впевніться що всі правила, встановлені для ovs-internal коректні: # sudo ovs-ofctl dump-flows ovs-internal.

Тут ви так само можете перевірити роботу ISNP, запустивши тестування на проникнення з однієї віртуальної машини на іншу.

ISNP-захист ваших віртуальних машин (кілька простих тестів)

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

Перед перевіркою ми маємо можливість вибрати що цікавить нас графік.

Рис.12
image

Рекомендовано використовувати"Detail by User". У цьому випадку, якщо IP-адреси ваших віртуальних машин з'являться в мережевий статистики, то графік буде схожий на те, що ми бачимо на Рис.13

Рис.13
image

2)Ви можете надіслати на ваші віртуальні машини нешкідливу атаку і подивитися блокує їх ваш ISNP.

При коректній роботі ISNP атаки будуть блоковані, а в інтерфейсі управління програми з'явиться подія безпеки.

3)Запустіть web server на вашій віртуальній машині. Якщо вона працює під Linux, використовуйте цю команду, і запустіть web server на 8000 порту: # python-m SimpleHTTPServer.

Вчасно роботи web server'mssql а, відправте на нього атаку URL_MANY_SLASHES. Так само можна відправити атаку від зовнішнього пристрою або з однієї віртуальної машини на іншу. В обох випадках ISNP буде блокувати всі атаки.

Відправити атаку URL_MANY_SLASHES легко:

  • Щоб ініціювати подія, введіть більш ніж 500 слешів у запиті HTTP
  • Відкрийте веб-браузер, увійдіть у цей URL:http://:8000///////////////.....////////////////////////

    Щоб відправити атаку URL_MANY_SLASHES так само можна використовувати команду:

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


    Після відправки атаки перевірте події безпеки в Журналі подій (Event Log view).

    Виберіть IPS Події (IPS Events) і ви зможете побачити всі заблоковані ISNP події безпеки. (Рис.14)

    Рис.14
    image.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.