Deploying IBM Security Network Protection to Open vSwitch
Good day to all habrewers!
In this article, you can learn how to configure IBM Security Network Protection (XGS5100) in an Open vSwitch software-configured network (SDN) and protect all your virtual assets.
Open vSwitch is an OpenFlow based virtual switch widely used in cloud environments.
')
Software-defined Networking (SDN) is a cloud deployment technology that provides a scalable and flexible environment suitable for the dynamic nature of this cloud itself.
You will learn how to deploy IBM Security Network Protection (ISNP) within an OpenFlow SDN-enabled switch — Open vSwitch and see how easy ISNP can be deployed in an SDN environment.
SDN is a new architectural approach whose goal is to provide network flexibility suitable for the dynamics of a modern environment. Existing network technologies are inherently static and difficult to change, since small network changes often require substantial reconfiguration of all, or most, switches, routers, and firewalls. Not only that
This process takes a lot of time for the administrator and is not solved with the help of one tambourine, it also carries the danger of getting a lot of mistakes.
In the software-configured network architecture, there are two levels:
the infrastructure level at which the network switches and data transmission channels operate, and the management level — a set of software tools physically separated from the infrastructure level, ensuring the implementation of mechanisms for managing the infrastructure level devices.
In traditional networks, the control layer is implemented in data transfer devices, and this implementation is vendor specific.
In SDN, these levels are divided,
management is centralized for all network equipment within the enterprise (regardless of the manufacturer of the equipment). This architecture provides an easy and fast way to manage traffic flow.
Cloud environments require dynamic resource allocation. Open and private clouds have virtual applications and storage, so the next logical step is network virtualization. Why not?!
SDN provides a platform for network virtualization, which makes it possible to create a fully dynamic environment for storing data, network and applications.
SDN requires the interaction of a centralized management layer with an infrastructure layer (implemented in physical devices). The OpenFlow protocol from the Open Networking Foundation is the SDN protocol that provides this connection. OpenFlow allows detailed control of traffic on all switches and routers in a network, like
physical and virtual, regardless of software vendor
security
Thus, the OpenFlow protocol eliminates the need to configure the device of each vendor separately through its own interface.
Open vSwitch is a virtual switch under the Apache 2.0 license. It is usually installed on a server to control traffic in the hypervisor, providing a dynamic network environment.
Open vSwitch supports a variety of traffic management protocols, including NetFlow, sFlow, SPAN, RSPAN, CLI, 802.1ag, and OpenFlow.
ISNP is a product that combines the functions of an intrusion prevention system and sophisticated application control.
It allows you to control all user activity by analyzing each connection and determining the applications used. Depending on the reputation of the application, ISNP may allow or block the connection. ISNP can also record application information, which can be useful for refining policies, including bandwidth.
Integrated with other protective functions, the intrusion prevention system provides fast deployment and easy administration.
Training
We will use 64-bit Ubuntu 12.04 LTS with support until April 2017. We installed Ubuntu on bare metal, not on a virtual machine. Using bare metal to install a KVM hypervisor gives good performance for the VM.
The server must have at least three network interfaces: one for remote access, and two for connecting to
ISNP directly to the protection ports (as shown in Figure 1).
Pic1
A virtual machine (KVM) is a virtualization infrastructure for the Linux kernel, and turns it into a hypervisor.
Before you install Ubuntu, activate the VT-d command set in the CPU, in the BIOS settings,
The recommended distribution is Ubuntu 12.04 LTS.
After booting the system to your hard drive, you will be prompted to select additional components of Ubuntu out of the box.
In the software selection section, select Virtual Machine host and OpenSSH server.
Pic2
For me, as well as for all unexpectedly blinded or missing the right line, or for some reason who forgot to choose Virtual Machine host , it is possible to install the necessary KVM components using the following command: # sudo apt-get install qemu-kvm libvirt- bin.
To complete the installation of the KVM hypervisor, follow these steps:
Then, enter /etc/libvirt/qemu.conf and add the following parameters:
DO NOT FORGET TO EXPAND THE ABOVE SETTINGS (REMOVE # AT THE BEGINNING OF EACH LINE)
Restart libvirt-bin to load and install qemu settings: # sudo service libvirt-bin restart.
If you wish, you can install virt-manager: # sudo apt-get install virt-manager. It is claimed that he has a convenient interface for configuring virtual machines.
To configure Open vSwitch, you will have to install all the necessary Open vSwitch components ( Open vSwitch 1.4.0 will do ):
Note: When installing these packages on the 3.8 kernel, you may encounter some problems, but Ubuntu employees are working hard to solve them while I write the article. And now about the pleasant - in the kernel 3.8 there is already a native openvswitch module, so there is no need to build it yourself.
As soon as the openvswitch module is loaded, your system will be ready for use right away.
Oh yeah, make sure you still download the openvswitch module and you haven't had a dream about it: # lsmod | grep openvswitch. And if you suddenly want to check whether the ovsdb-server and ovs-vswitchd are running , use this command: # sudo service openvswitch-switch status
You should see this:
Configuring Open vSwitch
The next step demonstrates how to configure Open vSwitch and use the eth0 interface as the uplink port
After that, the Virtual Machines will connect to the switch and gain access to the network.
To make sure once again that you are “smart,” your Open vSwitch is ready for use and you did everything correctly, run these commands:
You should see this:
We kindly ask you to do the configuration after you make sure that all the Open vSwitch services work correctly.
Reset eth0 settings:
Create a new vSwitch:
Add eth0 to ovs-internal:
Raise ovs-internal:
Set the IP address for ovs-internal:
Static IP:
DHCP:
Add eth1 and eth2 to ovs-internal. Enter commands in the following order:
After the introduction of these commands, the eth1 and eth2 network interfaces are deactivated and the noflood options installed on them.
You must follow the order of entering commands, or you will get a loop. These 2 ports will work when the ISNP device is ready and the cables are plugged into eth1 and eth2.
After the installation of Open vSwitch is complete, you can use ovs-vsctl and see the status of your switches.
If you do not want to configure Open vSwitch every time, go to / etc / network / interfaces and add "permanent" settings
For static IP configuration, you need to change the settings so that it looks like this:
And in order to configure DHCP, the settings should be similar to this:
It is important to install noflood on eth1 and eth2. This is not desirable in / etc / network / interfaces, so you will need to enter the following commands in /etc/rc.local:
Configure your ISNP and connect eth1 and eth2 to the device ports (as shown in Figure 1).
When the installation is complete, you can enter the interface and see the ISNP control panel.
Pic.3
For this article, ISNP was used as IPS. We used the default X-Force IPS, not the user and application control network policy. As a result, only the “any any” rule was activated. The remaining rules specified in the initial settings are shipped with the XGS5100 (version 5.1)
Pic.4
After configuring ISNP, connect the cables and bring up the eth1 and eth2 ports on the ovs-internal:
Recheck if you installed noflood on eth1 and eth2 correctly, because if not, you will get a loop when connecting cables.
First, you need to prepare a script for connecting your virtual NIC in your virtual machine to ovs-internal.
Copy this code into / etc / ovs-ifup:
Add permission to execute the script: # sudo chmod + x / etc / ovs-ifup.
To create a virtual machine, use virt-manager. Since Ubuntu 12.04 server was used here and we did not install the X server, we will not be able to run any program with the GUI.
But if suddenly you decide to use the Desktop Edition, the problem will be solved and you can access the virt-manager directly.
To run virt-manager on your KVM, use X forwarding (to view GUI programs on your local server)
If you are working under Linux, then in order to connect to a remote KVM, you must run an X forwarding command. (X forwarding connection to the server using the SSH protocol): # ssh -X user @ <server_ip>.> .
Instead of eth0, you need to get the IP address of your server from ovs-internal: # ifconfig ovs-internal> .
After logging in to the remote KVM, run virt-manager: # virt-manager.
If everything is correct, the GUI of the program will be displayed.
Pic.5
Now we create the first virtual machine.
Pic.6
Fig.7
It must have at least one vNIC (Virtualized Network Interface)
Fig.8
The vNICs will be configured later, for now close the created virtual machine and manually edit its XML file: Edit /etc/libvirt/qemu/.xml.
Initially, the settings of the XML file should look like this:
Modify the XML file settings so that it looks like this:
Give the KVM command to upload the updated XML file: # sudo virsh define /etc/libvirt/qemu/.xml.
Everything! “Conquer and share” on the virtual machine you created.
Having executed the following commands you should see the created port on ovs-internal.
Try installing any operating system on your virtual machine and try to connect to the network.
When your virtual machine is connected to Open vSwitch, the network (in bridge mode) and the DHCP server should work on it. If a DHCP server is not available, then you will have to manually assign an IP address to the virtual machine.
Due to an error in libvirt, the ovs-ifdown script is not specified in the description file. You must shut down the virtual machine and disconnect the tap (Ethernet) device from the switch. If this is not done, an error message will appear on subsequent launches of the virtual machine.
Fig.9
To disconnect a tap device from ovs-internal, enter this command: # sudo ovs-vsctl del-port ovs-internal tapN.
from the error message we can find out which device is disconnected from the switch. (Fig.9)
Now you need to "train" ovs-internal packet inspection, when sending traffic to ISNP. Use the ovs-ofctl command to set SDN rules on ovs-internal. The structure of the rules when working with the switch is determined by the OpenFlow standard. Repeat the same to protect other virtual machines.
If you set the wrong rules, your virtual machine will not be able to use the network. To restore the network connection, you must reset the switch using the following commands:
You need to know two attributes from the first virtual machine: the MAC address and the port number through which your Virtual Machine connects to ovs-internal.
You can see the MAC address of your virtual NIC here:
/etc/libvirt/qemu/.xml:
You can also see the MAC address assigned to each network device directly on the virtual machine itself.
Now you need the port number through which your Virtual Machine connects to ovs-internal. To get the status of the port on ovs-internal, you must run the following command: # sudo ovs-ofctl show ovs-internal.
The output of the command should look like this:
The numbers (from 1 to 4) are the port number, followed by the name in the brackets of the device connected to the port.
Each vNIC on the virtual machine is displayed as a hypervisor tap device. Thus, we can see that the first virtual machine is connected to port 4 on ovs-internal, eth2 to port 2, and eth3 to port 3. You will see all these values ​​in the switch management rules.
Note that the port number on the switch can be changed after the server is rebooted.
You must use the correct port number in subsequent ovs-internal management rules, otherwise network traffic will not pass through the ISNP device ...
Note: eth0 will not always be on the first port.
Suppose the MAC address of the first Virtual Machine is 52: 54: 00: AA: BB: CC.
Set new rules for ovs-internal.
Rules by rules
Blue lines in fig. 10 demonstrate how the switch forwards traffic from an external computer to an ISNP and then to the first virtual machine.
Pic.10
With this command you can dump all current rules on ovs-internal and see how many packets have killed each rule: # sudo ovs-ofctl dump-flows ovs-internal.
The output should look something like this:
Now you can test ISNP and run penetration tests on the first virtual machine.
In the section, “Verify that your virtual machines are protecting your virtual machines” there are a few simple tests to check your virtual machine’s ISNP protection.
You can create a second virtual machine by cloning the first one using virt-manager, or manually, as you did earlier
Do not forget to change the XML file so that the virtual machine automatically connects to ovs-internal
To get the port number used by the second Virtual Machine, run the ovs-ofctl command again: # sudo ovs-ofctl show ovs-internal.
The result will look something like this:
Here we see that the new tap device is connected to ovs-internal through the fifth port.
Suppose the MAC address of the second Virtual Machine is 52: 54: 00: AA: CC: DD. You must set the following rules for ovs-internal to protect it from external traffic and from traffic between Virtual Machines.
Rules by rules
The red lines in Figure 11 show the new rules set for the switch (protecting the traffic between two virtual machines).
Figure 11
Make sure that all the rules set for ovs-internal are correct: # sudo ovs-ofctl dump-flows ovs-internal.
Here you can also test ISNP performance by running penetration testing from one virtual machine to another.
1) The easiest way to make sure that network traffic went through ISNP is to use Network Graphs in the ISNP management interface. Before Network Graphs starts checking you need to send some traffic to virtual machines.
Before checking, we have the opportunity to choose the schedule that interests us.
Fig.12
It is recommended to use " Detail by User ". In this case, if the IP addresses of your virtual machines appear in the network statistics, the graph will be similar to what we see in Figure 13.
Fig.13
2) You can send a harmless attack to your virtual machines and see if your ISNP is blocking them.
If ISNP works correctly, the attacks will be blocked, and a security event will appear in the program’s control interface.
3) Run the web server on your virtual machine. If it works under Linux, use this command, and start the web server on port 8000: # python -m SimpleHTTPServer.
While the web server is running, send the URL_MANY_SLASHES attack to it . You can also send an attack from an external device or from one virtual machine to another. In both cases, ISNP will block all attacks.
Send URL_MANY_SLASHES attack easily:
In this article, you can learn how to configure IBM Security Network Protection (XGS5100) in an Open vSwitch software-configured network (SDN) and protect all your virtual assets.
Open vSwitch is an OpenFlow based virtual switch widely used in cloud environments.
')
Software-defined Networking (SDN) is a cloud deployment technology that provides a scalable and flexible environment suitable for the dynamic nature of this cloud itself.
You will learn how to deploy IBM Security Network Protection (ISNP) within an OpenFlow SDN-enabled switch — Open vSwitch and see how easy ISNP can be deployed in an SDN environment.
Software configurable networks
SDN is a new architectural approach whose goal is to provide network flexibility suitable for the dynamics of a modern environment. Existing network technologies are inherently static and difficult to change, since small network changes often require substantial reconfiguration of all, or most, switches, routers, and firewalls. Not only that
This process takes a lot of time for the administrator and is not solved with the help of one tambourine, it also carries the danger of getting a lot of mistakes.
In the software-configured network architecture, there are two levels:
the infrastructure level at which the network switches and data transmission channels operate, and the management level — a set of software tools physically separated from the infrastructure level, ensuring the implementation of mechanisms for managing the infrastructure level devices.
In traditional networks, the control layer is implemented in data transfer devices, and this implementation is vendor specific.
In SDN, these levels are divided,
management is centralized for all network equipment within the enterprise (regardless of the manufacturer of the equipment). This architecture provides an easy and fast way to manage traffic flow.
Cloud environments require dynamic resource allocation. Open and private clouds have virtual applications and storage, so the next logical step is network virtualization. Why not?!
SDN provides a platform for network virtualization, which makes it possible to create a fully dynamic environment for storing data, network and applications.
Openflow
SDN requires the interaction of a centralized management layer with an infrastructure layer (implemented in physical devices). The OpenFlow protocol from the Open Networking Foundation is the SDN protocol that provides this connection. OpenFlow allows detailed control of traffic on all switches and routers in a network, like
physical and virtual, regardless of software vendor
security
Thus, the OpenFlow protocol eliminates the need to configure the device of each vendor separately through its own interface.
Open vSwitch
Open vSwitch is a virtual switch under the Apache 2.0 license. It is usually installed on a server to control traffic in the hypervisor, providing a dynamic network environment.
Open vSwitch supports a variety of traffic management protocols, including NetFlow, sFlow, SPAN, RSPAN, CLI, 802.1ag, and OpenFlow.
ISNP
ISNP is a product that combines the functions of an intrusion prevention system and sophisticated application control.
It allows you to control all user activity by analyzing each connection and determining the applications used. Depending on the reputation of the application, ISNP may allow or block the connection. ISNP can also record application information, which can be useful for refining policies, including bandwidth.
Integrated with other protective functions, the intrusion prevention system provides fast deployment and easy administration.
Training
We will use 64-bit Ubuntu 12.04 LTS with support until April 2017. We installed Ubuntu on bare metal, not on a virtual machine. Using bare metal to install a KVM hypervisor gives good performance for the VM.
The server must have at least three network interfaces: one for remote access, and two for connecting to
ISNP directly to the protection ports (as shown in Figure 1).
Pic1
Configuring KVM Hypervisor
A virtual machine (KVM) is a virtualization infrastructure for the Linux kernel, and turns it into a hypervisor.
Before you install Ubuntu, activate the VT-d command set in the CPU, in the BIOS settings,
The recommended distribution is Ubuntu 12.04 LTS.
After booting the system to your hard drive, you will be prompted to select additional components of Ubuntu out of the box.
In the software selection section, select Virtual Machine host and OpenSSH server.
Pic2
For me, as well as for all unexpectedly blinded or missing the right line, or for some reason who forgot to choose Virtual Machine host , it is possible to install the necessary KVM components using the following command: # sudo apt-get install qemu-kvm libvirt- bin.
To complete the installation of the KVM hypervisor, follow these steps:
- Make sure the system distribution is updated: # sudo apt-get update && apt-get dist-upgrade
- Make sure your processor supports KVM: # sudo kvm-ok.
- Ensure that the VT-d function is activated in the BIOS and that your processor is not too “old” to work with KVM.
- Add a user to the kvm group: # sudo gpasswd -a $ USER kvm
- Add a user to the libvirtd group: # sudo gpasswd -a $ USER libvirtd
Then, enter /etc/libvirt/qemu.conf and add the following parameters:
# 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 DO NOT FORGET TO EXPAND THE ABOVE SETTINGS (REMOVE # AT THE BEGINNING OF EACH LINE)
Restart libvirt-bin to load and install qemu settings: # sudo service libvirt-bin restart.
If you wish, you can install virt-manager: # sudo apt-get install virt-manager. It is claimed that he has a convenient interface for configuring virtual machines.
Configuring Open vSwitch
To configure Open vSwitch, you will have to install all the necessary Open vSwitch components ( Open vSwitch 1.4.0 will do ):
# sudo apt-get install openvswitch-controller openvswitch-switch openvswitch-datapath-source openvswitch-datapath-dkms Note: When installing these packages on the 3.8 kernel, you may encounter some problems, but Ubuntu employees are working hard to solve them while I write the article. And now about the pleasant - in the kernel 3.8 there is already a native openvswitch module, so there is no need to build it yourself.
As soon as the openvswitch module is loaded, your system will be ready for use right away.
Oh yeah, make sure you still download the openvswitch module and you haven't had a dream about it: # lsmod | grep openvswitch. And if you suddenly want to check whether the ovsdb-server and ovs-vswitchd are running , use this command: # sudo service openvswitch-switch status
You should see this:
ovsdb-server is running with pid xxxx ovs-vswitchd is running with pid yyyy Configuring Open vSwitch
The next step demonstrates how to configure Open vSwitch and use the eth0 interface as the uplink port
After that, the Virtual Machines will connect to the switch and gain access to the network.
To make sure once again that you are “smart,” your Open vSwitch is ready for use and you did everything correctly, run these commands:
- Make sure you download the Open vSwitch module: # lsmod | grep openvswitch .
You should see something like this: # openvswitch 47849 0 - Check the status of all Open vSwitch services: # sudo service openvswitch-switch status.
You should see this:
ovsdb-server is running with pid xxxx ovs-vswitchd is running with pid yyyy We kindly ask you to do the configuration after you make sure that all the Open vSwitch services work correctly.
Reset eth0 settings:
# sudo ifconfig eth0 0 Create a new vSwitch:
# sudo ovs-vsctl add-br ovs-internal Add eth0 to ovs-internal:
# sudo ovs-vsctl add-port ovs-internal eth0 Raise ovs-internal:
# sudo ifconfig ovs-internal up Set the IP address for ovs-internal:
Static IP:
# sudo ifconfig ovs-internal <ip> <netmask> # sudo route add default gw <gw_ip> DHCP:
# sudo dhclient ovs-internal Add eth1 and eth2 to ovs-internal. Enter commands in the following order:
# 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 After the introduction of these commands, the eth1 and eth2 network interfaces are deactivated and the noflood options installed on them.
You must follow the order of entering commands, or you will get a loop. These 2 ports will work when the ISNP device is ready and the cables are plugged into eth1 and eth2.
After the installation of Open vSwitch is complete, you can use ovs-vsctl and see the status of your switches.
# 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" If you do not want to configure Open vSwitch every time, go to / etc / network / interfaces and add "permanent" settings
For static IP configuration, you need to change the settings so that it looks like this:
# 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 And in order to configure DHCP, the settings should be similar to this:
# 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 It is important to install noflood on eth1 and eth2. This is not desirable in / etc / network / interfaces, so you will need to enter the following commands in /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 Setup
Configure your ISNP and connect eth1 and eth2 to the device ports (as shown in Figure 1).
When the installation is complete, you can enter the interface and see the ISNP control panel.
Pic.3
For this article, ISNP was used as IPS. We used the default X-Force IPS, not the user and application control network policy. As a result, only the “any any” rule was activated. The remaining rules specified in the initial settings are shipped with the XGS5100 (version 5.1)
Pic.4
After configuring ISNP, connect the cables and bring up the eth1 and eth2 ports on the ovs-internal:
# sudo ovs-ofctl mod-port ovs-internal eth1 up # sudo ovs-ofctl mod-port ovs-internal eth2 up Recheck if you installed noflood on eth1 and eth2 correctly, because if not, you will get a loop when connecting cables.
Creating the first virtual machine and connecting it to ovs-internal
First, you need to prepare a script for connecting your virtual NIC in your virtual machine to ovs-internal.
Copy this code into / 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 Add permission to execute the script: # sudo chmod + x / etc / ovs-ifup.
Creating a new virtual machine
To create a virtual machine, use virt-manager. Since Ubuntu 12.04 server was used here and we did not install the X server, we will not be able to run any program with the GUI.
But if suddenly you decide to use the Desktop Edition, the problem will be solved and you can access the virt-manager directly.
To run virt-manager on your KVM, use X forwarding (to view GUI programs on your local server)
If you are working under Linux, then in order to connect to a remote KVM, you must run an X forwarding command. (X forwarding connection to the server using the SSH protocol): # ssh -X user @ <server_ip>.> .
Instead of eth0, you need to get the IP address of your server from ovs-internal: # ifconfig ovs-internal> .
After logging in to the remote KVM, run virt-manager: # virt-manager.
If everything is correct, the GUI of the program will be displayed.
Pic.5
Now we create the first virtual machine.
Pic.6
Fig.7
It must have at least one vNIC (Virtualized Network Interface)
Fig.8
The vNICs will be configured later, for now close the created virtual machine and manually edit its XML file: Edit /etc/libvirt/qemu/.xml.
Initially, the settings of the XML file should look like this:
# 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> Modify the XML file settings so that it looks like this:
<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> Give the KVM command to upload the updated XML file: # sudo virsh define /etc/libvirt/qemu/.xml.
Everything! “Conquer and share” on the virtual machine you created.
Having executed the following commands you should see the created port on ovs-internal.
# sudo ovs-vsctl show # sudo ovs-ofctl show ovs-internal Try installing any operating system on your virtual machine and try to connect to the network.
When your virtual machine is connected to Open vSwitch, the network (in bridge mode) and the DHCP server should work on it. If a DHCP server is not available, then you will have to manually assign an IP address to the virtual machine.
Due to an error in libvirt, the ovs-ifdown script is not specified in the description file. You must shut down the virtual machine and disconnect the tap (Ethernet) device from the switch. If this is not done, an error message will appear on subsequent launches of the virtual machine.
Fig.9
To disconnect a tap device from ovs-internal, enter this command: # sudo ovs-vsctl del-port ovs-internal tapN.
from the error message we can find out which device is disconnected from the switch. (Fig.9)
Protecting the virtual machine from external traffic
Now you need to "train" ovs-internal packet inspection, when sending traffic to ISNP. Use the ovs-ofctl command to set SDN rules on ovs-internal. The structure of the rules when working with the switch is determined by the OpenFlow standard. Repeat the same to protect other virtual machines.
If you set the wrong rules, your virtual machine will not be able to use the network. To restore the network connection, you must reset the switch using the following commands:
# sudo ovs-ofctl del-flows ovs-internal # sudo ovs-ofctl add-flow ovs-internal action=normal You need to know two attributes from the first virtual machine: the MAC address and the port number through which your Virtual Machine connects to ovs-internal.
You can see the MAC address of your virtual NIC here:
/etc/libvirt/qemu/.xml:
#sudo vi /etc/libvirt/qemu/<VM NAME>.xml <interface type='ethernet'> ... <mac address='xx:xx:xx:xx:xx:xx'/> ... </interface> You can also see the MAC address assigned to each network device directly on the virtual machine itself.
Now you need the port number through which your Virtual Machine connects to ovs-internal. To get the status of the port on ovs-internal, you must run the following command: # sudo ovs-ofctl show ovs-internal.
The output of the command should look like this:
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 The numbers (from 1 to 4) are the port number, followed by the name in the brackets of the device connected to the port.
Each vNIC on the virtual machine is displayed as a hypervisor tap device. Thus, we can see that the first virtual machine is connected to port 4 on ovs-internal, eth2 to port 2, and eth3 to port 3. You will see all these values ​​in the switch management rules.
Note that the port number on the switch can be changed after the server is rebooted.
You must use the correct port number in subsequent ovs-internal management rules, otherwise network traffic will not pass through the ISNP device ...
Note: eth0 will not always be on the first port.
Suppose the MAC address of the first Virtual Machine is 52: 54: 00: AA: BB: CC.
Set new rules for 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 Rules by rules
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. Blue lines in fig. 10 demonstrate how the switch forwards traffic from an external computer to an ISNP and then to the first virtual machine.
Pic.10
With this command you can dump all current rules on ovs-internal and see how many packets have killed each rule: # sudo ovs-ofctl dump-flows ovs-internal.
The output should look something like this:
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 Now you can test ISNP and run penetration tests on the first virtual machine.
In the section, “Verify that your virtual machines are protecting your virtual machines” there are a few simple tests to check your virtual machine’s ISNP protection.
Creating a second virtual machine and connecting it to Open vSwitch
You can create a second virtual machine by cloning the first one using virt-manager, or manually, as you did earlier
Do not forget to change the XML file so that the virtual machine automatically connects to ovs-internal
Protection of the Virtual Machine from internal traffic
To get the port number used by the second Virtual Machine, run the ovs-ofctl command again: # sudo ovs-ofctl show ovs-internal.
The result will look something like this:
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 Here we see that the new tap device is connected to ovs-internal through the fifth port.
Suppose the MAC address of the second Virtual Machine is 52: 54: 00: AA: CC: DD. You must set the following rules for ovs-internal to protect it from external traffic and from traffic between Virtual Machines.
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 Rules by rules
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. The red lines in Figure 11 show the new rules set for the switch (protecting the traffic between two virtual machines).
Figure 11
Make sure that all the rules set for ovs-internal are correct: # sudo ovs-ofctl dump-flows ovs-internal.
Here you can also test ISNP performance by running penetration testing from one virtual machine to another.
ISNP protection for your virtual machines (some simple tests)
1) The easiest way to make sure that network traffic went through ISNP is to use Network Graphs in the ISNP management interface. Before Network Graphs starts checking you need to send some traffic to virtual machines.
Before checking, we have the opportunity to choose the schedule that interests us.
Fig.12
It is recommended to use " Detail by User ". In this case, if the IP addresses of your virtual machines appear in the network statistics, the graph will be similar to what we see in Figure 13.
Fig.13
2) You can send a harmless attack to your virtual machines and see if your ISNP is blocking them.
If ISNP works correctly, the attacks will be blocked, and a security event will appear in the program’s control interface.
3) Run the web server on your virtual machine. If it works under Linux, use this command, and start the web server on port 8000: # python -m SimpleHTTPServer.
While the web server is running, send the URL_MANY_SLASHES attack to it . You can also send an attack from an external device or from one virtual machine to another. In both cases, ISNP will block all attacks.
Send URL_MANY_SLASHES attack easily:
- To trigger an event, enter more than 500 slashes in the HTTP request.
- Open a web browser, and enter this URL: http: //: 8000 /////////////...../////////// ///////////
To send the URL_MANY_SLASHES attack, you can also use the command:# wget http://10.40.25.10:8000/`python -c "print '/'*500"`
After sending the attack, check the security events in the Event Log view.
Select IPS Events (IPS Events) and you can see all ISNP blocked security events. (Fig.14)
Fig.14
.
Source: https://habr.com/ru/post/243885/
All Articles