SlideShare a Scribd company logo

OVS-NFV Tutorial

Open Networking Perú (Opennetsoft), profile picture
Open Networking Perú (Opennetsoft)

1) The document provides an agenda and instructions for a hands-on tutorial on OVS/NFV basics using Open vSwitch, Linux containers, Docker, and virtual private networks. 2) It describes how to access two provided virtual machines and configure port mirroring with Open vSwitch to monitor network traffic between VMs. 3) Instructions are given for installing Linux containers on the VMs, configuring network interfaces and scripts, and testing connectivity between containers using GRE tunnels. 4) The tutorial also covers installing and configuring Docker containers on the VMs, creating virtual networks between them using GRE tunnels, and deploying example containers from Docker Hub.

Technology
1 of 53
Downloaded 83 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
OVS/NFV Tutorial Basics and Hands On nov/2016 Prof. Christian Rothenberg (FEEC/UNICAMP) PhD candidate Javier Quinto (UNICAMP & INICTEL-UNI)
Agenda ● Open vSwitch Mirror ● Linux Containers (LXC) ● Docker ● IPSec & BroIDS VNF
Hands On
Accessing to the Virtual Machines # We are sharing two virtual machine Ubuntu 16.04 in OVA format, each one has a static IP address. # To start the VMs, open a terminal for each VM and type: $ vboxmanage startvm Tutorial-SDN1 $ vboxmanage startvm Tutorial-SDN2 # Access to each one of the VMs recently started: $ ssh tutorial@192.168.56.101 (password = tutorial) $ ssh tutorial@192.168.56.102 (password = tutorial) VM1 192.168.56.101 VM2 192.168.56.102
Agenda 1. Port Mirroring with OVS 1.1 – Creating an mirror interface with OVS
Mirror with Open vSwitch (OVS) Question: What is Port Mirroring with OVS ? This exercise describes how to configure a mirror port on an Open vSwitch. The goal is to install a new guest to act as IDS/IPS system. The guest is configured with 2 virtual network interfaces. The first interface will have an IP address and will be used to manage the guest. The other interfaces will be connected to the mirror port on Open vSwitch.
Mirror with Open vSwitch (OVS) 1.1 Create an Interface mirror with OVS (1/2) # Create three network namespaces "LNS-1”, “LNS-2” and “LNS-3” $ sudo ip netns add LNS-1 LNS-2 LNS-3 # Create a new internal interface “port3” $ sudo ovs-vsctl add-port br1 port3 -- set Interface port3 type=internal # Bind the internal interface to the corresponding LNS $ sudo ip link set port3 netns LNS-3 $ sudo ip netns exec LNS-3 ip link set dev port3 up $ sudo ip netns exec LNS-3 ip addr add 11.0.0.3/24 dev port3 $ sudo ip netns exec LNS-3 ping 11.0.0.1 -c 2 port1 port2 br1 Internal ports OVSLNS-1 LNS-2 port3 LNS-3 port1 port2
Mirror with Open vSwitch (OVS) 1.1 Create an Interface mirror with OVS (2/2) port1 port2 br1 Internal ports OVSLNS-1 LNS-2 port3 LNS-3 port1 port2 # Create a mirror interface $ sudo ovs-vsctl -- set bridge br1 mirrors=@m -- --id=@port2 get port port2 -- --id=@port1 get port port1 -- --id=@port3 get port port3 -- --id=@m create mirror name=test-mirror select-dst-port=@port1,@port2 select-src-port=@port1,@port2 output-port=@port3 # Capture packets at interface “LNS-3” $ sudo ip netns exec LNS-3 tshark -i port3 # Remove the mirror interface br1 ovs-vsct clear Bridge br1 mirror
Agenda 2. Linux Containers (LXC) 2.1 – LXC Introduction 2.2 – Configuration LXC 2.3 – GRE with LXC
2.1 LXC Introduction LXC is a userspace interface for the Linux kernel containment features. Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers. Features: Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) LXC containers are often considered as something in the middle between a chroot and a full fledged virtual machine. The goal of LXC is to create an environment as close as possible to a standard Linux installation but without the need for a separate kernel.
2.1 LXC Introduction Architecture of Linux Containers
2.2 Configure LXC (1/5) 1.1 Accesing to the virtual machines # To start the VMs, open a terminal for each VM and type: From term1: $ vboxmanage startvm Tutorial-SDN1 From term2: $ vboxmanage startvm Tutorial-SDN2 # Access to each one of the VMs recently started: From term1: $ ssh tutorial@192.168.56.101 (password = tutorial) From term2: $ ssh tutorial@192.168.56.102 (password = tutorial) 192.168.56.1 192.168.56.101 192.168.56.102 VM1 VM2
2.2 Configure LXC (2/5) 1.1 Installing of containers LXC # Create a LXC container for each VM using ubuntu 14.04 template. We call “LXC1” to the container of VM1 and “LXC2” to th container of VM2 VM1: $ sudo lxc-create -t download -n LXC1 -- -d ubuntu -r trusty -a amd64 VM2: $ sudo lxc-create -t download -n LXC2 -- -d ubuntu -r trusty -a amd64 # List the containers recently created VM1: $ sudo lxc-ls VM2: $ sudo lxc-ls 192.168.56.101 192.168.56.102 VM1 Container LXC1 Container LXC2 br0 br0 VM2 192.168.56.1
2.2 Configure LXC (3/5) Connecting LXC to the bridge br0 for VM1 Add the required lines of the LXC config file which are highlighted below and comment the line that start with “ lxc.network.link” $ sudo vim /var/lib/lxc/LXC1/config ... # Container specific configuration lxc.rootfs = /var/lib/lxc/test-ubuntu1/rootfs lxc.utsname = LXC1 # Network configuration lxc.network.type = veth lxc.network.veth.pair = host1 lxc.network.script.up = /etc/lxc/ovsup lxc.network.script.down = /etc/lxc/ovsdown lxc.network.flags = up lxc.network.ipv4 = 11.1.1.11/24 lxc.network.ipv4.gateway = 11.1.1.1 #lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:fb:cb:db 192.168.56.101 192.168.56.102 VM1 Container LXC1 Container LXC2 br0 br0 VM2 192.168.56.1
2.2 Configure LXC (4/5) Connecting LXC to the bridge br0 for VM2 Add the required lines of the LXC config file which are highlighted below and comment the line that start with “ lxc.network.link” $ sudo vim /var/lib/lxc/LXC2/config ... # Container specific configuration lxc.rootfs = /var/lib/lxc/test-ubuntu1/rootfs lxc.utsname = LXC2 # Network configuration lxc.network.type = veth lxc.network.veth.pair = host2 lxc.network.script.up = /etc/lxc/ovsup lxc.network.script.down = /etc/lxc/ovsdown lxc.network.flags = up lxc.network.ipv4 = 11.1.1.12/24 lxc.network.ipv4.gateway = 11.1.1.1 #lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:fb:cb:dc 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
2.2 Configure LXC (5/5) Script for the Container-1 and Container-2 Create/delete interfaces of containers There is a script named “ovsup” that allows to create interfaces inside br0 $ sudo vim /etc/lxc/ovsup #!/bin/bash BRIDGE="br0" ovs-vsctl --may-exist add-br $BRIDGE ovs-vsctl --may-exist add-port $BRIDGE $5 There is another script named “ovsdown” that allows to delete interfaces created by OVS when the Linux Containers was up $ sudo vim /etc/lxc/ovsdown #!/bin/bash BRIDGE="br0" ovs-vsctl del-port $BRIDGE host1 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM2VM1
2.3 Tunnel GRE with LXC (1/3) # Create the interface bridge br0 for each KVM VM1: sudo ovs-vsctl add-br br0 VM2: sudo ovs-vsctl add-br br0 # Configure the IP address for the interface br0 in each KVM VM1: sudo ifconfig br0 11.1.1.1 netmask 255.255.255.0 VM2: sudo ifconfig br0 11.1.1.2 netmask 255.255.255.0 # Create a GRE tunnel between the bridges br0 VM1: sudo ovs-vsctl add-port br0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.56.102 VM2: sudo ovs-vsctl add-port br0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.56.101 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
2.3 Tunnel GRE with LXC (2/3) # Start each container from different console VM1: sudo lxc-start -n LXC1 VM2: sudo lxc-start -n LXC2 # Access to each VM using the parameter “lxc-attach” VM1: sudo lxc-attach -n LXC1 VM2: sudo lxc-attack -n LXC2 # Testing the connectivity between the containers - From the container LXC1 (IP=11.1.1.11) $ ping 11.1.1.12 64 bytes from 11.1.1.12: icmp_seq=90 ttl=64 time=5.55 ms - From the container LXC2 (IP=11.1.1.12) $ ping 11.1.1.11 64 bytes from 11.1.1.11: icmp_seq=90 ttl=64 time=5.55 ms 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
2.3 Tunnel GRE with LXC (3/3) # Use “iperf” in each virtual machine VM1, VM2. However, as it is not installed, you may copy the binary “iperf” from VM1 to Container LXC1 and from VM2 to LXC2 respectively VM1: sudo cp /usr/bin/iperf /var/lib/lxc/LXC1/rootfs/usr/bin/ VM2: sudo cp /usr/bin/iperf /var/lib/lxc/LXC2/rootfs/usr/bin/ # Verify the RTT using IPERF UDP # From the Container LXC2 (11.1.1.12), launch Iperf Server listening on TCP port 5001 $ sudo iperf -s -u -b [#bandwith] # From the another Container LXC1 (11.1.1.11), launch Iperf Client connecting to 11.1.1.12, TCP port 5001 $ sudo iperf -c 11.1.1.12 -u Question: What is the maximum value for Bandwith and Transfer? 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2 Tunel GRE
Agenda 3. Dockers 3.1 – Introduction 3.2 - Installation and Configuration 3.2 – Docker with GRE Tunnel 3.3 – Docker with Open Vswitch and GRE Tunnel
3.1 INTRODUCTION Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments
3.2 Docker Installation (done!) 4.1 – Installation Guide (1/2) # Install and configure docker (v1.01) from the oficial repository Ubuntu sudo apt-get update && apt-get install docker.io sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker sudo sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io # Install the latest version of docker (v1.2) Add the key public in where is found Docker $ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys > 36A1D7869245C8950F966E92D8576A8BA88D21E9 Copy the docker’s site in the Ubuntu repository’s source $ sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list" Update the Kernel $ sudo apt-get update Install the latest version of docker $ sudo apt-get install lxc-docker
3.2 Docker Installation (done!) 4.1 – Installation Guide (2/2) # What do you observe when you give below command: $ docker -h ? # Allowing non-root access $ sudo gpasswd -a <user-actual> docker $ logout # Access again to the virtual machine and give the below command again: $ docker -h # Enabling the memory and swap accounting $ sudo vim /etc/default/grub GRUB_CMDLINE_LINUX="" Replace by: GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1" # Update the grub and restart the machine $ sudo update-grub2 && reboot # Installing LXC and bridge-utils $ sudo apt-get install lxc bridge-utils
3.2 Docker # For this exercise we will continue using the same VMs (VM1, VM2), (see slide 23) # Check if the docker is up $ sudo ps aux |grep docker # If docker is not up then give the below command: $ sudo service docker start # In each VM, search and pull the pre-configured container from docker hub VM1: $ sudo docker search intrig/tutorial VM2: $ sudo docker search intrig/tutorial VM1: $ sudo docker pull intrig/tutorial:v1 VM2: $ sudo docker pull intrig/tutorial:v1 # Check if docker was correctly downloaded VM1: $ docker images VM2: $ docker images
3.3 Docker with GRE Tunnel Create GRE Tunnel in Docker (1/2) # Virtual Machine 1 (VM1) Configuring the virtual network “net1” from VM1 $ sudo docker network create --subnet=10.1.1.0/24 --gateway=10.1.1.17 --ip-range=10.1.1.16/28 -o “com.docker.network.bridge.name”=”docker-net1” net1 $ sudo ovs-vsctl add-br br0 $ sudo ip link set dev br0 up $ sudo ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.102 $ sudo brctl addif docker-net1 br0 Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 Gre Tunnel
3.3 Docker with GRE Tunnel Create GRE Tunnel in Docker (2/2) # Virtual Machine 2 (VM2) Configuring the virtual network “net1” from VM2 $ sudo docker network create --subnet=10.1.1.0/24 --gateway=10.1.1.33 --ip-range=10.1.1.32/28 -o “com.docker.network.bridge.name”=”docker-net1” net1 $ sudo ovs-vsctl add-br br0 $ sudo ip link set dev br0 up $ sudo ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.101 $ sudo brctl addif docker-net1 br0 Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel
3.3 Docker with GRE Tunnel Docker Network Configuration in VM1 (2/2) # Virtual Machine 1 (VM1) # Activate docker for the container 1 $ sudo docker run --net=net1 -it --privileged --name=container1 --hostname=container1 --publish 127.0.0.1:2222:22 intrig/tutorial:v1 /bin/bash Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
3.3 Docker with GRE Tunnel Docker Network Configuration in VM1 (2/2) # Virtual Machine 2 (VM2) # Activate docker for the container 2 $ sudo docker run --net=net1 -it --privileged --name=container2 --hostname=container2 --publish 127.0.0.1:2222:22 intrig/tutorial:v1 /bin/bash Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
3.3 Docker with GRE Tunnel # Testing the connectivity between dockers From Container1 ping 10.1.1.32 From Container2 ping 10.1.1.16 # Copy the binary “iperf” from KVM to each Container. VM1: sudo cp /usr/bin/iperf /var/lib/docker/aufs/diff/<ID-docker1>/bin/ VM2: sudo cp /usr/bin/iperf /var/lib/docker/aufs/diff/<ID-docker2>/bin/ How do you know the value of <ID-dockerX> from containerX?
3.3 Docker with GRE Tunnel # Verify the RTT using IPERF UDP # From the Container1, executes Iperf Server listening on TCP port 5001 $ sudo iperf -s -u # From the another container2, executes Iperf Client connecting to Container1 (10.1.1.16), TCP port 5001 $ sudo iperf -c 10.1.1.16 -u -b <#bandwith> What can you say of the “Bandwith” ? What is the maximum value for Bandwith and Transfer? Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
3.4 Docker with OVS an GRE Tunnel Docker 1.12.3 Docker 1.12.3 OVS 2.5.0 OVS 2.5.0 enp0s8 enp0s8 192.168.56.101 192.168.56.102 ihost0 ihost1 gre0 ihost0 ihost1 gre0 br2 br2 C1 C2 C3 C4 eth0 eth0 eth0 eth0 VLAN20 VLAN10 tep0 tep0 br0 br0
3.4 Docker with OVS an GRE # Virtual Machine 1 (VM1) $ sudo ovs-vsctl del-br br0 $ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl add-br br2 $ sudo ovs-vsctl add-port br0 tep0 -- set interface tep0 type=internal $ sudo ifconfig tep0 192.168.200.21 netmask 255.255.255.0 $ sudo ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.102 # Virtual Machine 2 (VM2) $ sudo ovs-vsctl del-br br0 $ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl add-br br2 $ sudo ovs-vsctl add-port br0 tep0 -- set interface tep0 type=internal $ sudo ifconfig tep0 192.168.200.22 netmask 255.255.255.0 $ sudo ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.101
3.4 Docker with OVS an GRE Starting Containers # Virtual Machine 1 (VM1) # Delete the container docker created in the last exercise $ docker stop container1 $ docker rm container1 # Create two containers docker and set the network mode to none $ C1=$(docker run -d --net=none -t -i --name=container1 intrig/tutorial:v1 /bin/bash) $ C2=$(docker run -d --net=none -t -i --name=container2 intrig/tutorial:v1 /bin/bash) # Virtual Machine 2 (VM2) # Delete the container docker created in the last exercise $ docker stop container2 $ docker rm container2 # Create two containers docker and set the network mode to none $ C3=$(docker run -d --net=none -t -i --name=container3 intrig/tutorial:v1 /bin/bash) $ C4=$(docker run -d --net=none -t -i --name=container4 intrig/tutorial:v1 /bin/bash)
3.4 Docker with OVS an GRE Binding docker with Open Vswitch Interface (1/2) # Bind dockers with Open vSwitch interface Pipework syntax: ./pipework <bridge-name> -i <docker-interface> -l <ovs-interface> $<variable> <IP>/<mask>@<GW> @<vlan-number> For VM1: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C1 1.0.0.1/24@1.0.0.254 @10 $ sudo ./pipework br2 -i eth0 -l ihost1 $C2 1.0.0.2/24@1.0.0.254 @20 For VM2: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C3 1.0.0.3/24@1.0.0.254 @10 $ sudo ./pipework br2 -i eth0 -l ihost1 $C4 1.0.0.4/24@1.0.0.254 @20
3.4 Docker with OVS an GRE # Using different terminals, start the containers VM1 From terminal 1: $ docker start -a -i container1 VM1 From terminal 2: $ docker start -a -i container2 VM3 From terminal 1: $ docker start -a -i container3 VM4 From terminal 2: $ docker start -a -i container4 # From the Container1 (Terminal 1) Container1$ ping 1.0.0.3 -c 2 Container1$ ping 1.0.0.4 -c 2 # From the Container3 (Terminal 3) Container3$ ping 1.0.0.1 -c 2 Container3$ ping 1.0.0.2 -c 2 What ping is successful? And why?
3.4 Docker with OVS an GRE Testing GRE Tunnel # Verify the RTT using IPERF # From the Container #1 1.0.0.3 launch Iperf Server listening on TCP port 5001 $ sudo iperf -s -u # From the another Container #3, launch Iperf Client connecting to 1.0.0.1, TCP port 5001 $ sudo iperf -c 1.0.0.1 -u What can you say of the “Bandwith” ? What about IPerf TCP? # Virtual Machine 1 (KVM-1) $ sudo ovs-vsctl show $ sudo ovs-ofctl show br2 $ sudo ovs-ofctl dump-flows br2 # Virtual Machine 2 (KVM-2) $ sudo ovs-vsctl show $ sudo ovs-ofctl show br2 $ sudo ovs-ofctl dump-flows br2
Agenda 4. IPSec & BroIDS 4.1 – Bro IDS Introduction 4.2 – Docker with IPsec Tunnel and Bro IDS 4.3 – IPSec Configuration on OVS 4.4 - Docker Configuration 4.5 - Configuration IPSec Gateway 4.6 - Bro Minimal Configuration 4.7 - Exercises
4.1 Bro Introduction Bro is a passive, open-source network traffic analyzer. It is primarily a security monitor that inspects all traffic on a link in depth for signs of suspicious activity. More generally, however, Bro supports a wide range of traffic analysis tasks even outside of the security domain, including performance measurements and helping with troubleshooting. Some interesting features are: - Deployment - Analysis - Scripting Language - Interfacing
4.1 Bro Architecture Bro is composed in two components. Its event engine (or core) reduces the incoming packet stream into a series of higher-level events. These events reflect network activity in policy-neutral terms, i.e., they describe what has been seen, but not why, or whether it is significant. For example, every HTTP request on the wire turns into a corresponding http_request event that carries with it the involved IP addresses and ports, the URI being requested, and the HTTP version in use. The event however does not convey any further interpretation, e.g., of whether that URI corresponds to a known malware site. The script interpreter, which executes a set of event handlers written in Bro’s custom scripting language. These scripts can express a site’s security policy, i.e., what actions to take when the monitor detects different types of activity. More generally they can derive any desired properties and statistics from the input traffic. Bro’s language comes with extensive domain-specific types and support functionality; and, crucially, allows scripts to maintain state over time, enabling them to track and correlate the evolution of what they observe across connection and host boundaries. Bro scripts can generate real-time alerts and also execute arbitrary external programs on demand, e.g., to trigger an active response to an attack.
Docker with IPSec Tunnel and Bro IDS IPSec Host1 Attacker Host2 Host3 Host4 SSH Server Parameters of Configuration: Host1: 10.1.1.2/24 Host2: 10.1.1.3/24 Host3: 10.1.1.4/24 Host4: 10.1.1.5/24 VM1: emp0s8=192.168.56.101 VM2: emp0s8=192.168.56.102 enp0s8 enp0s8 Internet GW: 10.0.2.15/10.1.1.1 VM-1 VM-2
4.3 IPSec Configuration on OVS # Virtual Machine 1 (VM1) $ sudo docker network rm net1 $ sudo ovs-vsctl add-br br2 $ sudo ip link set dev br2 up # Create the ipsec interface “ipsec1” within br2 bridge $ sudo ovs-vsctl add-port br2 ipsec1 -- set interface ipsec1 type=ipsec_gre options:remote_ip=192.168.56.102 options:psk=<enter-password> # Virtual Machine 2 (VM2) $ docker network rm net1 $ sudo ovs-vsctl add-br br2 $ sudo ip link set dev br2 up # Create the ipsec interface “ipsec1” within br2 bridge $ sudo ovs-vsctl add-port br2 ipsec1 -- set interface ipsec1 type=ipsec_gre options:remote_ip=192.168.56.101 options:psk=<enter-password>
4.4 Docker Configuration (1/2) Starting Containers # Virtual Machine 1 (VM1) # Delete the container docker created in the last exercise # Create two containers docker and set the network mode to none $ C1=$(docker run -d --net=none -t -i --name=container1 --hostname=container1 richardqa/ubuntu16.04:v6 /bin/bash) $ C2=$(docker run -d --net=none -t -i --name=container2 --hostname=container2 richardqa/ubuntu16.04:v6 /bin/bash) # Virtual Machine 2 (VM2) # Delete the container docker created in the last exercise # Create two containers docker and set the network mode to none $ C3=$(docker run -d --net=none -t -i --name=container3 --hostname=container3 richardqa/ubuntu16.04:v6 /bin/bash) $ C4=$(docker run -d --net=none -t -i --name=container4 --hostname=container4 richardqa/ubuntu16.04:v6 /bin/bash)
4.4 Docker Configuration (2/2) # Bind dockers with Open vSwitch interfaces For VM1: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C1 10.1.1.2/24@10.1.1.1 $ sudo ./pipework br2 -i eth0 -l ihost1 $C2 10.1.1.3/24@10.1.1.1 For VM2: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C3 10.1.1.4/24@10.1.1.1 $ sudo ./pipework br2 -i eth0 -l ihost1 $C4 10.1.1.5/24@10.1.1.1
Note that each VM has one interface “enp0s3” to connect to the Internet with IP: 10.0.2.15. How to create one route for each container reaching the Internet? Steps: 1- Configure IP address for br2 in VM1 (br2=10.1.1.1/24) 2- Configure a rule in IPTABLES that allows each container using the IPSec channel to reach the Internet. (Use -A POSTROUTING and -j MASQUERADE) Q1: Write the IPTABLES rule 3- Check the connection of each Containers to the Internet 4.4 Configuring IPSec Gateway
4.5 Mirror configuration to IPsec channel a) Create a mirror interface to forward each packet within IPsec channel to the br2 local interface from VM2. ovs-vsctl -- set bridge br2 mirrors=@m -- --id= … ? Q2: Write the complete command to mirror packets b) Check if the “br2” interface is receiving packets from the IPSEC tunnel In VM1, docker exec container1 ping -c 2 10.1.1.4 In VM2, sudo tshark -i br2 Q3: Do you see any packets?
4.6 Bro: Minimal Starting Configuration (1/3) These are the basic configuration changes for a minimal BroControl installation that will manage a single Bro instance on the localhost: 1. In $PREFIX/etc/node.cfg, set the interface to monitor. 2. In $PREFIX/etc/networks.cfg, comment out the default settings and add the networks that Bro will consider local to the monitored environment. 3. In $PREFIX/etc/broctl.cfg, change the MailTo email address to a desired recipient and the LogRotationInterval to a desired log archival frequency.
4.6 Bro: Minimal Starting Configuration (2/3) Now start the BroControl shell like: broctl Since this is the first-time use of the shell, perform an initial installation of the BroControl configuration: [BroControl] > install Then start up a Bro instance: [BroControl] > start Check if Bro is running [BroControl] > status * If there are errors while trying to start the Bro instance, you can can view the details with the diag command. If started successfully, the Bro instance will begin analyzing traffic according to a default policy and output the results in $PREFIX/logs.
4.6 Bro: Minimal Starting Configuration (3/3) a) Create a new folder “test-bro” and run bro within this folder indicating the interface to be monitored. VM2$ mkdir ~/test-bro/ VM2$ sudo -s # password: tutorial VM2# bro -i br2 local b) Simple test to alert a possible threat from a external host VM1$ docker start -ai container1 Container1: $ nmap 10.1.1.4 # against container4 VM2$ ls -ls ~/test-bro/ VM2$ conn.log loaded_scripts.log notice.log packet_filter.log stats.log c) Check “notice.log” and Q4: explain the fields shown in that file.
4.7 Bro: Detecting Brute-force attacks Bro has a script to detect Brute-Force attacks. Check the file: $PREFIX/share/bro/policy/protocols/ssh/detect-bruteforcing.bro module SSH; export { redef enum Notice::Type += { Password_Guessing, Login_By_Password_Guesser, }; redef enum Intel::Where += { SSH::SUCCESSFUL_LOGIN, }; const password_guesses_limit: double = 30 &redef; const guessing_timeout = 30 mins &redef; const ignore_guessers: table[subnet] of subnet &redef; } event bro_init() { local r1: SumStats::Reducer = [$stream="ssh.login.failure", $apply=set(SumStats::SUM, SumStats::SAMPLE), $num_samples=5]; SumStats::create([$name="detect-ssh-bruteforcing", $epoch=guessing_timeout,
4.7 Bro: Detecting Brute-force attacks $reducers=set(r1), $threshold_val(key: SumStats::Key, result: SumStats::Result) = { return result["ssh.login.failure"]$sum; }, $threshold=password_guesses_limit, $threshold_crossed(key: SumStats::Key, result: SumStats::Result) = { local r = result["ssh.login.failure"]; local sub_msg = fmt("Sampled servers: "); local samples = r$samples; for ( i in samples ) { if ( samples[i]?$str ) sub_msg = fmt("%s%s %s", sub_msg, i==0 ? "":",", samples[i]$str); } # Generate the notice. NOTICE([$note=Password_Guessing, $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num), $sub=sub_msg, $src=key$host, $identifier=cat(key$host)]); }]); }
4.7 Bro: Detecting Brute-force attacks event ssh_auth_successful(c: connection, auth_method_none: bool) { local id = c$id; Intel::seen([$host=id$orig_h, $conn=c, $where=SSH::SUCCESSFUL_LOGIN]); } event ssh_auth_failed(c: connection) { local id = c$id; # Add data to the FAILED_LOGIN metric unless this connection should # be ignored. if ( ! (id$orig_h in ignore_guessers && id$resp_h in ignore_guessers[id$orig_h]) ) SumStats::observe("ssh.login.failure", [$host=id$orig_h], [$str=cat(id$resp_h)]); }
4.8 Configuring alerts in Bro We show an example of an alert against Brute-force attacks, configured in Bro IDS. Create the file brute-force.bro and write below the following: @load protocols/ssh/detect-bruteforcing redef Site::local_nets = { 10.1.1.0/24, }; redef ignore_checksums = T; redef Notice::mail_dest = "<user@domain.com>"; redef Notice::emailed_types += { SSH::Password_Guessing, }; redef SSH::password_guesses_limit=10; hook Notice::policy(n: Notice::Info) { if ( n$note == SSH::Password_Guessing && /10.1.1.5/ in n$sub ) add n$actions[Notice::ACTION_EMAIL]; }
4.9 Simulating an attack of Brute-force Now execute again the Bro program from the directory ~/test-bro in VM2. Remember execute bro from Super User VM2~/test-bro# bro -i br2 <script>.bro From container1, execute the program “hydra” to generate massive tries to authenticate against a SSH server located in the container4 Before executing Hydra, create two files, “users.txt” and “pass.txt”, they should contain a list of possible users and passwords to be used by Hydra program. container1$ hydra -L users.txt -P pass.txt 10.1.1.5 ssh After few seconds, Bro IDS should be able to detect such attack. Check the directory “~/test-bro” and take a look the file “notice.log” Q5: What can you say about the contents of notice.log? Take a look the file $PREFIX/share/bro/policy/protocols/ssh/detect-bruteforcing.bro Q6: Which parameters can you change to modify the behavior of the alerts against brute-force attacks?

More Related Content

PPTX
OpenvSwitch Deep Dive
rajdeep
 
PPTX
Vxlan deep dive session rev0.5 final
KwonSun Bae
 
PDF
VXLAN Design and Deployment.pdf
NelAlv1
 
PPTX
Kubernetes Networking 101
Weaveworks
 
PPTX
Enable DPDK and SR-IOV for containerized virtual network functions with zun
heut2008
 
PDF
Building DataCenter networks with VXLAN BGP-EVPN
Cisco Canada
 
PDF
VXLAN BGP EVPN: Technology Building Blocks
APNIC
 
PDF
netfilter and iptables
Kernel TLV
 
OpenvSwitch Deep Dive
rajdeep
 
Vxlan deep dive session rev0.5 final
KwonSun Bae
 
VXLAN Design and Deployment.pdf
NelAlv1
 
Kubernetes Networking 101
Weaveworks
 
Enable DPDK and SR-IOV for containerized virtual network functions with zun
heut2008
 
Building DataCenter networks with VXLAN BGP-EVPN
Cisco Canada
 
VXLAN BGP EVPN: Technology Building Blocks
APNIC
 
netfilter and iptables
Kernel TLV
 

What's hot (20)

PDF
Linux Networking Explained
Thomas Graf
 
PDF
Xdp and ebpf_maps
lcplcp1
 
PPTX
Introduction to Diameter Protocol - Part1
Basim Aly (JNCIP-SP, JNCIP-ENT)
 
ODP
Lisa 2015-gluster fs-introduction
Gluster.org
 
PDF
VLANs in the Linux Kernel
Kernel TLV
 
PDF
Faster packet processing in Linux: XDP
Daniel T. Lee
 
PDF
Virtualized network with openvswitch
Sim Janghoon
 
PDF
IOS Cisco - Cheat sheets
Alejandro Marin
 
PDF
Building Embedded Linux Full Tutorial for ARM
Sherif Mousa
 
PDF
Open vSwitch 패킷 처리 구조
Seung-Hoon Baek
 
PDF
EVPN Introduction
Bangladesh Network Operators Group
 
PDF
IPv4/IPv6 移行・共存技術の動向
Yuya Rin
 
PPTX
OVN - Basics and deep dive
Trinath Somanchi
 
PPTX
Openconfigを用いたネットワーク機器操作
Hirofumi Ichihara
 
PDF
OpenWrt From Top to Bottom
Kernel TLV
 
PPTX
NFV +SDN (Network Function Virtualization)
Hamidreza Bolhasani
 
PPTX
Free5 gc installation
Chia-An Lee
 
PDF
Implementing SDN Testbed(ONOS & OpenVirteX)
sangyun han
 
PDF
Userspace networking
Stephen Hemminger
 
PDF
Open vSwitch Introduction
HungWei Chiu
 
Linux Networking Explained
Thomas Graf
 
Xdp and ebpf_maps
lcplcp1
 
Introduction to Diameter Protocol - Part1
Basim Aly (JNCIP-SP, JNCIP-ENT)
 
Lisa 2015-gluster fs-introduction
Gluster.org
 
VLANs in the Linux Kernel
Kernel TLV
 
Faster packet processing in Linux: XDP
Daniel T. Lee
 
Virtualized network with openvswitch
Sim Janghoon
 
IOS Cisco - Cheat sheets
Alejandro Marin
 
Building Embedded Linux Full Tutorial for ARM
Sherif Mousa
 
Open vSwitch 패킷 처리 구조
Seung-Hoon Baek
 
EVPN Introduction
Bangladesh Network Operators Group
 
IPv4/IPv6 移行・共存技術の動向
Yuya Rin
 
OVN - Basics and deep dive
Trinath Somanchi
 
Openconfigを用いたネットワーク機器操作
Hirofumi Ichihara
 
OpenWrt From Top to Bottom
Kernel TLV
 
NFV +SDN (Network Function Virtualization)
Hamidreza Bolhasani
 
Free5 gc installation
Chia-An Lee
 
Implementing SDN Testbed(ONOS & OpenVirteX)
sangyun han
 
Userspace networking
Stephen Hemminger
 
Open vSwitch Introduction
HungWei Chiu
 
Ad

Similar to OVS-NFV Tutorial (20)

PDF
New Virtualization Technologies
Open Networking Perú (Opennetsoft)
 
PPTX
Openstack openswitch basics
nshah061
 
PPT
Docker Multi Host Networking, Rachit Arora, IBM
Neependra Khare
 
PPTX
The Basic Introduction of Open vSwitch
Te-Yen Liu
 
PDF
LF_OVS_17_LXC Linux Containers over Open vSwitch
LF_OpenvSwitch
 
PPTX
Thebasicintroductionofopenvswitch
Ramses Ramirez
 
PDF
Docker-OVS
snrism
 
PPTX
Deep Dive in Docker Overlay Networks
Laurent Bernaille
 
PPTX
Docker networking Tutorial 101
LorisPack Project
 
PPTX
Networking in Docker Containers
Attila Kanto
 
PPTX
Meetup docker using software defined networks
OCTO Technology
 
PDF
Docker and friends at Linux Days 2014 in Prague
tomasbart
 
PPTX
Docker networking basics & coupling with Software Defined Networks
Adrien Blind
 
PPTX
Deep dive in Docker Overlay Networks
Laurent Bernaille
 
PPTX
Docker SDN (software-defined-networking) JUG
Piotr Kieszczyński
 
PPTX
LXC
Wu Fan-Cheng
 
PPTX
Docker containers introduction and its usage
saurabh22062
 
PDF
Docker Networking Meetup - Intro to Docker Networking
Dhananjay Sampath
 
PPTX
Lxc – next gen virtualization for cloud intro (cloudexpo)
Boden Russell
 
PDF
Octo talk : docker multi-host networking
Hervé Leclerc
 
New Virtualization Technologies
Open Networking Perú (Opennetsoft)
 
Openstack openswitch basics
nshah061
 
Docker Multi Host Networking, Rachit Arora, IBM
Neependra Khare
 
The Basic Introduction of Open vSwitch
Te-Yen Liu
 
LF_OVS_17_LXC Linux Containers over Open vSwitch
LF_OpenvSwitch
 
Thebasicintroductionofopenvswitch
Ramses Ramirez
 
Docker-OVS
snrism
 
Deep Dive in Docker Overlay Networks
Laurent Bernaille
 
Docker networking Tutorial 101
LorisPack Project
 
Networking in Docker Containers
Attila Kanto
 
Meetup docker using software defined networks
OCTO Technology
 
Docker and friends at Linux Days 2014 in Prague
tomasbart
 
Docker networking basics & coupling with Software Defined Networks
Adrien Blind
 
Deep dive in Docker Overlay Networks
Laurent Bernaille
 
Docker SDN (software-defined-networking) JUG
Piotr Kieszczyński
 
LXC
Wu Fan-Cheng
 
Docker containers introduction and its usage
saurabh22062
 
Docker Networking Meetup - Intro to Docker Networking
Dhananjay Sampath
 
Lxc – next gen virtualization for cloud intro (cloudexpo)
Boden Russell
 
Octo talk : docker multi-host networking
Hervé Leclerc
 
Ad

More from Open Networking Perú (Opennetsoft) (9)

PDF
Primera capacitación en sdn para el proyecto Bella-T
Open Networking Perú (Opennetsoft)
 
PDF
Capacitación de SDN para COMSOC UNI
Open Networking Perú (Opennetsoft)
 
PDF
Open Dayligth usando SDN-NFV
Open Networking Perú (Opennetsoft)
 
PDF
Afiche Oficial del COOPEBRAS-2017 - I Jornada Peruana-Internacional de Invest...
Open Networking Perú (Opennetsoft)
 
PDF
Programa Oficial del COOPEBRAS 2017
Open Networking Perú (Opennetsoft)
 
PDF
Tutorial GPG
Open Networking Perú (Opennetsoft)
 
PDF
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
Open Networking Perú (Opennetsoft)
 
PDF
Docker 2014
Open Networking Perú (Opennetsoft)
 
PDF
Qualifying exam-2015-final
Open Networking Perú (Opennetsoft)
 
Primera capacitación en sdn para el proyecto Bella-T
Open Networking Perú (Opennetsoft)
 
Capacitación de SDN para COMSOC UNI
Open Networking Perú (Opennetsoft)
 
Open Dayligth usando SDN-NFV
Open Networking Perú (Opennetsoft)
 
Afiche Oficial del COOPEBRAS-2017 - I Jornada Peruana-Internacional de Invest...
Open Networking Perú (Opennetsoft)
 
Programa Oficial del COOPEBRAS 2017
Open Networking Perú (Opennetsoft)
 
Tutorial GPG
Open Networking Perú (Opennetsoft)
 
IntelFlow: Toward adding Cyber Threat Intelligence to Software Defined Networ...
Open Networking Perú (Opennetsoft)
 
Docker 2014
Open Networking Perú (Opennetsoft)
 
Qualifying exam-2015-final
Open Networking Perú (Opennetsoft)
 

Recently uploaded (20)

PDF
The Rise and Fall of 3GPP – Time for a Sabbatical?
3G4G
 
PPTX
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
PDF
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 
PDF
Per capita expenditure prediction using model stacking based on satellite ima...
IAESIJAI
 
PDF
Agricultural_Statistics_at_a_Glance_2022_0.pdf
SandeepSingh286037
 
PPT
Teaching material agriculture food technology
LiaRayya
 
PDF
Assigned Numbers - 2025 - Bluetooth® Document
Bloombase
 
PPTX
Machine Learning_overview_presentation.pptx
kondavamsidharreddy2
 
PDF
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
PPTX
MYSQL Presentation for SQL database connectivity
Swati270511
 
PDF
NewMind AI Weekly Chronicles - August'25-Week II
NewMind AI
 
PDF
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
PDF
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
SOFTTECHHUB
 
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
flufftailshop
 
PDF
MIND Revenue Release Quarter 2 2025 Press Release
MIND CTI
 
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
PPTX
Spectroscopy.pptx food analysis technology
nawahassan45
 
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
PDF
Electronic commerce courselecture one. Pdf
OmerMohamed64
 
The Rise and Fall of 3GPP – Time for a Sabbatical?
3G4G
 
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
Network Security Unit 5.pdf for BCA BBA.
Serpent6
 
Per capita expenditure prediction using model stacking based on satellite ima...
IAESIJAI
 
Agricultural_Statistics_at_a_Glance_2022_0.pdf
SandeepSingh286037
 
Teaching material agriculture food technology
LiaRayya
 
Assigned Numbers - 2025 - Bluetooth® Document
Bloombase
 
Machine Learning_overview_presentation.pptx
kondavamsidharreddy2
 
Spectral efficient network and resource selection model in 5G networks
IAESIJAI
 
MYSQL Presentation for SQL database connectivity
Swati270511
 
NewMind AI Weekly Chronicles - August'25-Week II
NewMind AI
 
Blue Purple Modern Animated Computer Science Presentation.pdf.pdf
Akar16
 
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
SOFTTECHHUB
 
Mobile App Security Testing_ A Comprehensive Guide.pdf
flufftailshop
 
MIND Revenue Release Quarter 2 2025 Press Release
MIND CTI
 
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
Spectroscopy.pptx food analysis technology
nawahassan45
 
Advanced methodologies resolving dimensionality complications for autism neur...
IAESIJAI
 
Electronic commerce courselecture one. Pdf
OmerMohamed64
 

OVS-NFV Tutorial

  • 1. OVS/NFV Tutorial Basics and Hands On nov/2016 Prof. Christian Rothenberg (FEEC/UNICAMP) PhD candidate Javier Quinto (UNICAMP & INICTEL-UNI)
  • 2. Agenda ● Open vSwitch Mirror ● Linux Containers (LXC) ● Docker ● IPSec & BroIDS VNF
  • 4. Accessing to the Virtual Machines # We are sharing two virtual machine Ubuntu 16.04 in OVA format, each one has a static IP address. # To start the VMs, open a terminal for each VM and type: $ vboxmanage startvm Tutorial-SDN1 $ vboxmanage startvm Tutorial-SDN2 # Access to each one of the VMs recently started: $ ssh tutorial@192.168.56.101 (password = tutorial) $ ssh tutorial@192.168.56.102 (password = tutorial) VM1 192.168.56.101 VM2 192.168.56.102
  • 5. Agenda 1. Port Mirroring with OVS 1.1 – Creating an mirror interface with OVS
  • 6. Mirror with Open vSwitch (OVS) Question: What is Port Mirroring with OVS ? This exercise describes how to configure a mirror port on an Open vSwitch. The goal is to install a new guest to act as IDS/IPS system. The guest is configured with 2 virtual network interfaces. The first interface will have an IP address and will be used to manage the guest. The other interfaces will be connected to the mirror port on Open vSwitch.
  • 7. Mirror with Open vSwitch (OVS) 1.1 Create an Interface mirror with OVS (1/2) # Create three network namespaces "LNS-1”, “LNS-2” and “LNS-3” $ sudo ip netns add LNS-1 LNS-2 LNS-3 # Create a new internal interface “port3” $ sudo ovs-vsctl add-port br1 port3 -- set Interface port3 type=internal # Bind the internal interface to the corresponding LNS $ sudo ip link set port3 netns LNS-3 $ sudo ip netns exec LNS-3 ip link set dev port3 up $ sudo ip netns exec LNS-3 ip addr add 11.0.0.3/24 dev port3 $ sudo ip netns exec LNS-3 ping 11.0.0.1 -c 2 port1 port2 br1 Internal ports OVSLNS-1 LNS-2 port3 LNS-3 port1 port2
  • 8. Mirror with Open vSwitch (OVS) 1.1 Create an Interface mirror with OVS (2/2) port1 port2 br1 Internal ports OVSLNS-1 LNS-2 port3 LNS-3 port1 port2 # Create a mirror interface $ sudo ovs-vsctl -- set bridge br1 mirrors=@m -- --id=@port2 get port port2 -- --id=@port1 get port port1 -- --id=@port3 get port port3 -- --id=@m create mirror name=test-mirror select-dst-port=@port1,@port2 select-src-port=@port1,@port2 output-port=@port3 # Capture packets at interface “LNS-3” $ sudo ip netns exec LNS-3 tshark -i port3 # Remove the mirror interface br1 ovs-vsct clear Bridge br1 mirror
  • 9. Agenda 2. Linux Containers (LXC) 2.1 – LXC Introduction 2.2 – Configuration LXC 2.3 – GRE with LXC
  • 10. 2.1 LXC Introduction LXC is a userspace interface for the Linux kernel containment features. Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers. Features: Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) LXC containers are often considered as something in the middle between a chroot and a full fledged virtual machine. The goal of LXC is to create an environment as close as possible to a standard Linux installation but without the need for a separate kernel.
  • 11. 2.1 LXC Introduction Architecture of Linux Containers
  • 12. 2.2 Configure LXC (1/5) 1.1 Accesing to the virtual machines # To start the VMs, open a terminal for each VM and type: From term1: $ vboxmanage startvm Tutorial-SDN1 From term2: $ vboxmanage startvm Tutorial-SDN2 # Access to each one of the VMs recently started: From term1: $ ssh tutorial@192.168.56.101 (password = tutorial) From term2: $ ssh tutorial@192.168.56.102 (password = tutorial) 192.168.56.1 192.168.56.101 192.168.56.102 VM1 VM2
  • 13. 2.2 Configure LXC (2/5) 1.1 Installing of containers LXC # Create a LXC container for each VM using ubuntu 14.04 template. We call “LXC1” to the container of VM1 and “LXC2” to th container of VM2 VM1: $ sudo lxc-create -t download -n LXC1 -- -d ubuntu -r trusty -a amd64 VM2: $ sudo lxc-create -t download -n LXC2 -- -d ubuntu -r trusty -a amd64 # List the containers recently created VM1: $ sudo lxc-ls VM2: $ sudo lxc-ls 192.168.56.101 192.168.56.102 VM1 Container LXC1 Container LXC2 br0 br0 VM2 192.168.56.1
  • 14. 2.2 Configure LXC (3/5) Connecting LXC to the bridge br0 for VM1 Add the required lines of the LXC config file which are highlighted below and comment the line that start with “ lxc.network.link” $ sudo vim /var/lib/lxc/LXC1/config ... # Container specific configuration lxc.rootfs = /var/lib/lxc/test-ubuntu1/rootfs lxc.utsname = LXC1 # Network configuration lxc.network.type = veth lxc.network.veth.pair = host1 lxc.network.script.up = /etc/lxc/ovsup lxc.network.script.down = /etc/lxc/ovsdown lxc.network.flags = up lxc.network.ipv4 = 11.1.1.11/24 lxc.network.ipv4.gateway = 11.1.1.1 #lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:fb:cb:db 192.168.56.101 192.168.56.102 VM1 Container LXC1 Container LXC2 br0 br0 VM2 192.168.56.1
  • 15. 2.2 Configure LXC (4/5) Connecting LXC to the bridge br0 for VM2 Add the required lines of the LXC config file which are highlighted below and comment the line that start with “ lxc.network.link” $ sudo vim /var/lib/lxc/LXC2/config ... # Container specific configuration lxc.rootfs = /var/lib/lxc/test-ubuntu1/rootfs lxc.utsname = LXC2 # Network configuration lxc.network.type = veth lxc.network.veth.pair = host2 lxc.network.script.up = /etc/lxc/ovsup lxc.network.script.down = /etc/lxc/ovsdown lxc.network.flags = up lxc.network.ipv4 = 11.1.1.12/24 lxc.network.ipv4.gateway = 11.1.1.1 #lxc.network.link = lxcbr0 lxc.network.hwaddr = 00:16:3e:fb:cb:dc 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
  • 16. 2.2 Configure LXC (5/5) Script for the Container-1 and Container-2 Create/delete interfaces of containers There is a script named “ovsup” that allows to create interfaces inside br0 $ sudo vim /etc/lxc/ovsup #!/bin/bash BRIDGE="br0" ovs-vsctl --may-exist add-br $BRIDGE ovs-vsctl --may-exist add-port $BRIDGE $5 There is another script named “ovsdown” that allows to delete interfaces created by OVS when the Linux Containers was up $ sudo vim /etc/lxc/ovsdown #!/bin/bash BRIDGE="br0" ovs-vsctl del-port $BRIDGE host1 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM2VM1
  • 17. 2.3 Tunnel GRE with LXC (1/3) # Create the interface bridge br0 for each KVM VM1: sudo ovs-vsctl add-br br0 VM2: sudo ovs-vsctl add-br br0 # Configure the IP address for the interface br0 in each KVM VM1: sudo ifconfig br0 11.1.1.1 netmask 255.255.255.0 VM2: sudo ifconfig br0 11.1.1.2 netmask 255.255.255.0 # Create a GRE tunnel between the bridges br0 VM1: sudo ovs-vsctl add-port br0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.56.102 VM2: sudo ovs-vsctl add-port br0 gre1 -- set Interface gre1 type=gre options:remote_ip=192.168.56.101 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
  • 18. 2.3 Tunnel GRE with LXC (2/3) # Start each container from different console VM1: sudo lxc-start -n LXC1 VM2: sudo lxc-start -n LXC2 # Access to each VM using the parameter “lxc-attach” VM1: sudo lxc-attach -n LXC1 VM2: sudo lxc-attack -n LXC2 # Testing the connectivity between the containers - From the container LXC1 (IP=11.1.1.11) $ ping 11.1.1.12 64 bytes from 11.1.1.12: icmp_seq=90 ttl=64 time=5.55 ms - From the container LXC2 (IP=11.1.1.12) $ ping 11.1.1.11 64 bytes from 11.1.1.11: icmp_seq=90 ttl=64 time=5.55 ms 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2
  • 19. 2.3 Tunnel GRE with LXC (3/3) # Use “iperf” in each virtual machine VM1, VM2. However, as it is not installed, you may copy the binary “iperf” from VM1 to Container LXC1 and from VM2 to LXC2 respectively VM1: sudo cp /usr/bin/iperf /var/lib/lxc/LXC1/rootfs/usr/bin/ VM2: sudo cp /usr/bin/iperf /var/lib/lxc/LXC2/rootfs/usr/bin/ # Verify the RTT using IPERF UDP # From the Container LXC2 (11.1.1.12), launch Iperf Server listening on TCP port 5001 $ sudo iperf -s -u -b [#bandwith] # From the another Container LXC1 (11.1.1.11), launch Iperf Client connecting to 11.1.1.12, TCP port 5001 $ sudo iperf -c 11.1.1.12 -u Question: What is the maximum value for Bandwith and Transfer? 192.168.56.101 192.168.56.102 Container LXC1 Container LXC2 br0 br0 192.168.56.1 VM1 VM2 Tunel GRE
  • 20. Agenda 3. Dockers 3.1 – Introduction 3.2 - Installation and Configuration 3.2 – Docker with GRE Tunnel 3.3 – Docker with Open Vswitch and GRE Tunnel
  • 21. 3.1 INTRODUCTION Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments
  • 22. 3.2 Docker Installation (done!) 4.1 – Installation Guide (1/2) # Install and configure docker (v1.01) from the oficial repository Ubuntu sudo apt-get update && apt-get install docker.io sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker sudo sed -i '$acomplete -F _docker docker' /etc/bash_completion.d/docker.io # Install the latest version of docker (v1.2) Add the key public in where is found Docker $ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys > 36A1D7869245C8950F966E92D8576A8BA88D21E9 Copy the docker’s site in the Ubuntu repository’s source $ sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list" Update the Kernel $ sudo apt-get update Install the latest version of docker $ sudo apt-get install lxc-docker
  • 23. 3.2 Docker Installation (done!) 4.1 – Installation Guide (2/2) # What do you observe when you give below command: $ docker -h ? # Allowing non-root access $ sudo gpasswd -a <user-actual> docker $ logout # Access again to the virtual machine and give the below command again: $ docker -h # Enabling the memory and swap accounting $ sudo vim /etc/default/grub GRUB_CMDLINE_LINUX="" Replace by: GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1" # Update the grub and restart the machine $ sudo update-grub2 && reboot # Installing LXC and bridge-utils $ sudo apt-get install lxc bridge-utils
  • 24. 3.2 Docker # For this exercise we will continue using the same VMs (VM1, VM2), (see slide 23) # Check if the docker is up $ sudo ps aux |grep docker # If docker is not up then give the below command: $ sudo service docker start # In each VM, search and pull the pre-configured container from docker hub VM1: $ sudo docker search intrig/tutorial VM2: $ sudo docker search intrig/tutorial VM1: $ sudo docker pull intrig/tutorial:v1 VM2: $ sudo docker pull intrig/tutorial:v1 # Check if docker was correctly downloaded VM1: $ docker images VM2: $ docker images
  • 25. 3.3 Docker with GRE Tunnel Create GRE Tunnel in Docker (1/2) # Virtual Machine 1 (VM1) Configuring the virtual network “net1” from VM1 $ sudo docker network create --subnet=10.1.1.0/24 --gateway=10.1.1.17 --ip-range=10.1.1.16/28 -o “com.docker.network.bridge.name”=”docker-net1” net1 $ sudo ovs-vsctl add-br br0 $ sudo ip link set dev br0 up $ sudo ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.102 $ sudo brctl addif docker-net1 br0 Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 Gre Tunnel
  • 26. 3.3 Docker with GRE Tunnel Create GRE Tunnel in Docker (2/2) # Virtual Machine 2 (VM2) Configuring the virtual network “net1” from VM2 $ sudo docker network create --subnet=10.1.1.0/24 --gateway=10.1.1.33 --ip-range=10.1.1.32/28 -o “com.docker.network.bridge.name”=”docker-net1” net1 $ sudo ovs-vsctl add-br br0 $ sudo ip link set dev br0 up $ sudo ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.101 $ sudo brctl addif docker-net1 br0 Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel
  • 27. 3.3 Docker with GRE Tunnel Docker Network Configuration in VM1 (2/2) # Virtual Machine 1 (VM1) # Activate docker for the container 1 $ sudo docker run --net=net1 -it --privileged --name=container1 --hostname=container1 --publish 127.0.0.1:2222:22 intrig/tutorial:v1 /bin/bash Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
  • 28. 3.3 Docker with GRE Tunnel Docker Network Configuration in VM1 (2/2) # Virtual Machine 2 (VM2) # Activate docker for the container 2 $ sudo docker run --net=net1 -it --privileged --name=container2 --hostname=container2 --publish 127.0.0.1:2222:22 intrig/tutorial:v1 /bin/bash Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
  • 29. 3.3 Docker with GRE Tunnel # Testing the connectivity between dockers From Container1 ping 10.1.1.32 From Container2 ping 10.1.1.16 # Copy the binary “iperf” from KVM to each Container. VM1: sudo cp /usr/bin/iperf /var/lib/docker/aufs/diff/<ID-docker1>/bin/ VM2: sudo cp /usr/bin/iperf /var/lib/docker/aufs/diff/<ID-docker2>/bin/ How do you know the value of <ID-dockerX> from containerX?
  • 30. 3.3 Docker with GRE Tunnel # Verify the RTT using IPERF UDP # From the Container1, executes Iperf Server listening on TCP port 5001 $ sudo iperf -s -u # From the another container2, executes Iperf Client connecting to Container1 (10.1.1.16), TCP port 5001 $ sudo iperf -c 10.1.1.16 -u -b <#bandwith> What can you say of the “Bandwith” ? What is the maximum value for Bandwith and Transfer? Master VirtualBox OVS net1 10.1.1.32/28 192.168.56.102 br0 Gre Tunnel Master VirtualBox OVS net1 10.1.1.16/28 192.168.56.101 br0 C1 C2
  • 31. 3.4 Docker with OVS an GRE Tunnel Docker 1.12.3 Docker 1.12.3 OVS 2.5.0 OVS 2.5.0 enp0s8 enp0s8 192.168.56.101 192.168.56.102 ihost0 ihost1 gre0 ihost0 ihost1 gre0 br2 br2 C1 C2 C3 C4 eth0 eth0 eth0 eth0 VLAN20 VLAN10 tep0 tep0 br0 br0
  • 32. 3.4 Docker with OVS an GRE # Virtual Machine 1 (VM1) $ sudo ovs-vsctl del-br br0 $ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl add-br br2 $ sudo ovs-vsctl add-port br0 tep0 -- set interface tep0 type=internal $ sudo ifconfig tep0 192.168.200.21 netmask 255.255.255.0 $ sudo ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.102 # Virtual Machine 2 (VM2) $ sudo ovs-vsctl del-br br0 $ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl add-br br2 $ sudo ovs-vsctl add-port br0 tep0 -- set interface tep0 type=internal $ sudo ifconfig tep0 192.168.200.22 netmask 255.255.255.0 $ sudo ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre options:remote_ip=192.168.56.101
  • 33. 3.4 Docker with OVS an GRE Starting Containers # Virtual Machine 1 (VM1) # Delete the container docker created in the last exercise $ docker stop container1 $ docker rm container1 # Create two containers docker and set the network mode to none $ C1=$(docker run -d --net=none -t -i --name=container1 intrig/tutorial:v1 /bin/bash) $ C2=$(docker run -d --net=none -t -i --name=container2 intrig/tutorial:v1 /bin/bash) # Virtual Machine 2 (VM2) # Delete the container docker created in the last exercise $ docker stop container2 $ docker rm container2 # Create two containers docker and set the network mode to none $ C3=$(docker run -d --net=none -t -i --name=container3 intrig/tutorial:v1 /bin/bash) $ C4=$(docker run -d --net=none -t -i --name=container4 intrig/tutorial:v1 /bin/bash)
  • 34. 3.4 Docker with OVS an GRE Binding docker with Open Vswitch Interface (1/2) # Bind dockers with Open vSwitch interface Pipework syntax: ./pipework <bridge-name> -i <docker-interface> -l <ovs-interface> $<variable> <IP>/<mask>@<GW> @<vlan-number> For VM1: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C1 1.0.0.1/24@1.0.0.254 @10 $ sudo ./pipework br2 -i eth0 -l ihost1 $C2 1.0.0.2/24@1.0.0.254 @20 For VM2: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C3 1.0.0.3/24@1.0.0.254 @10 $ sudo ./pipework br2 -i eth0 -l ihost1 $C4 1.0.0.4/24@1.0.0.254 @20
  • 35. 3.4 Docker with OVS an GRE # Using different terminals, start the containers VM1 From terminal 1: $ docker start -a -i container1 VM1 From terminal 2: $ docker start -a -i container2 VM3 From terminal 1: $ docker start -a -i container3 VM4 From terminal 2: $ docker start -a -i container4 # From the Container1 (Terminal 1) Container1$ ping 1.0.0.3 -c 2 Container1$ ping 1.0.0.4 -c 2 # From the Container3 (Terminal 3) Container3$ ping 1.0.0.1 -c 2 Container3$ ping 1.0.0.2 -c 2 What ping is successful? And why?
  • 36. 3.4 Docker with OVS an GRE Testing GRE Tunnel # Verify the RTT using IPERF # From the Container #1 1.0.0.3 launch Iperf Server listening on TCP port 5001 $ sudo iperf -s -u # From the another Container #3, launch Iperf Client connecting to 1.0.0.1, TCP port 5001 $ sudo iperf -c 1.0.0.1 -u What can you say of the “Bandwith” ? What about IPerf TCP? # Virtual Machine 1 (KVM-1) $ sudo ovs-vsctl show $ sudo ovs-ofctl show br2 $ sudo ovs-ofctl dump-flows br2 # Virtual Machine 2 (KVM-2) $ sudo ovs-vsctl show $ sudo ovs-ofctl show br2 $ sudo ovs-ofctl dump-flows br2
  • 37. Agenda 4. IPSec & BroIDS 4.1 – Bro IDS Introduction 4.2 – Docker with IPsec Tunnel and Bro IDS 4.3 – IPSec Configuration on OVS 4.4 - Docker Configuration 4.5 - Configuration IPSec Gateway 4.6 - Bro Minimal Configuration 4.7 - Exercises
  • 38. 4.1 Bro Introduction Bro is a passive, open-source network traffic analyzer. It is primarily a security monitor that inspects all traffic on a link in depth for signs of suspicious activity. More generally, however, Bro supports a wide range of traffic analysis tasks even outside of the security domain, including performance measurements and helping with troubleshooting. Some interesting features are: - Deployment - Analysis - Scripting Language - Interfacing
  • 39. 4.1 Bro Architecture Bro is composed in two components. Its event engine (or core) reduces the incoming packet stream into a series of higher-level events. These events reflect network activity in policy-neutral terms, i.e., they describe what has been seen, but not why, or whether it is significant. For example, every HTTP request on the wire turns into a corresponding http_request event that carries with it the involved IP addresses and ports, the URI being requested, and the HTTP version in use. The event however does not convey any further interpretation, e.g., of whether that URI corresponds to a known malware site. The script interpreter, which executes a set of event handlers written in Bro’s custom scripting language. These scripts can express a site’s security policy, i.e., what actions to take when the monitor detects different types of activity. More generally they can derive any desired properties and statistics from the input traffic. Bro’s language comes with extensive domain-specific types and support functionality; and, crucially, allows scripts to maintain state over time, enabling them to track and correlate the evolution of what they observe across connection and host boundaries. Bro scripts can generate real-time alerts and also execute arbitrary external programs on demand, e.g., to trigger an active response to an attack.
  • 40. Docker with IPSec Tunnel and Bro IDS IPSec Host1 Attacker Host2 Host3 Host4 SSH Server Parameters of Configuration: Host1: 10.1.1.2/24 Host2: 10.1.1.3/24 Host3: 10.1.1.4/24 Host4: 10.1.1.5/24 VM1: emp0s8=192.168.56.101 VM2: emp0s8=192.168.56.102 enp0s8 enp0s8 Internet GW: 10.0.2.15/10.1.1.1 VM-1 VM-2
  • 41. 4.3 IPSec Configuration on OVS # Virtual Machine 1 (VM1) $ sudo docker network rm net1 $ sudo ovs-vsctl add-br br2 $ sudo ip link set dev br2 up # Create the ipsec interface “ipsec1” within br2 bridge $ sudo ovs-vsctl add-port br2 ipsec1 -- set interface ipsec1 type=ipsec_gre options:remote_ip=192.168.56.102 options:psk=<enter-password> # Virtual Machine 2 (VM2) $ docker network rm net1 $ sudo ovs-vsctl add-br br2 $ sudo ip link set dev br2 up # Create the ipsec interface “ipsec1” within br2 bridge $ sudo ovs-vsctl add-port br2 ipsec1 -- set interface ipsec1 type=ipsec_gre options:remote_ip=192.168.56.101 options:psk=<enter-password>
  • 42. 4.4 Docker Configuration (1/2) Starting Containers # Virtual Machine 1 (VM1) # Delete the container docker created in the last exercise # Create two containers docker and set the network mode to none $ C1=$(docker run -d --net=none -t -i --name=container1 --hostname=container1 richardqa/ubuntu16.04:v6 /bin/bash) $ C2=$(docker run -d --net=none -t -i --name=container2 --hostname=container2 richardqa/ubuntu16.04:v6 /bin/bash) # Virtual Machine 2 (VM2) # Delete the container docker created in the last exercise # Create two containers docker and set the network mode to none $ C3=$(docker run -d --net=none -t -i --name=container3 --hostname=container3 richardqa/ubuntu16.04:v6 /bin/bash) $ C4=$(docker run -d --net=none -t -i --name=container4 --hostname=container4 richardqa/ubuntu16.04:v6 /bin/bash)
  • 43. 4.4 Docker Configuration (2/2) # Bind dockers with Open vSwitch interfaces For VM1: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C1 10.1.1.2/24@10.1.1.1 $ sudo ./pipework br2 -i eth0 -l ihost1 $C2 10.1.1.3/24@10.1.1.1 For VM2: $ cd /home/tutorial/pipework/ $ sudo ./pipework br2 -i eth0 -l ihost0 $C3 10.1.1.4/24@10.1.1.1 $ sudo ./pipework br2 -i eth0 -l ihost1 $C4 10.1.1.5/24@10.1.1.1
  • 44. Note that each VM has one interface “enp0s3” to connect to the Internet with IP: 10.0.2.15. How to create one route for each container reaching the Internet? Steps: 1- Configure IP address for br2 in VM1 (br2=10.1.1.1/24) 2- Configure a rule in IPTABLES that allows each container using the IPSec channel to reach the Internet. (Use -A POSTROUTING and -j MASQUERADE) Q1: Write the IPTABLES rule 3- Check the connection of each Containers to the Internet 4.4 Configuring IPSec Gateway
  • 45. 4.5 Mirror configuration to IPsec channel a) Create a mirror interface to forward each packet within IPsec channel to the br2 local interface from VM2. ovs-vsctl -- set bridge br2 mirrors=@m -- --id= … ? Q2: Write the complete command to mirror packets b) Check if the “br2” interface is receiving packets from the IPSEC tunnel In VM1, docker exec container1 ping -c 2 10.1.1.4 In VM2, sudo tshark -i br2 Q3: Do you see any packets?
  • 46. 4.6 Bro: Minimal Starting Configuration (1/3) These are the basic configuration changes for a minimal BroControl installation that will manage a single Bro instance on the localhost: 1. In $PREFIX/etc/node.cfg, set the interface to monitor. 2. In $PREFIX/etc/networks.cfg, comment out the default settings and add the networks that Bro will consider local to the monitored environment. 3. In $PREFIX/etc/broctl.cfg, change the MailTo email address to a desired recipient and the LogRotationInterval to a desired log archival frequency.
  • 47. 4.6 Bro: Minimal Starting Configuration (2/3) Now start the BroControl shell like: broctl Since this is the first-time use of the shell, perform an initial installation of the BroControl configuration: [BroControl] > install Then start up a Bro instance: [BroControl] > start Check if Bro is running [BroControl] > status * If there are errors while trying to start the Bro instance, you can can view the details with the diag command. If started successfully, the Bro instance will begin analyzing traffic according to a default policy and output the results in $PREFIX/logs.
  • 48. 4.6 Bro: Minimal Starting Configuration (3/3) a) Create a new folder “test-bro” and run bro within this folder indicating the interface to be monitored. VM2$ mkdir ~/test-bro/ VM2$ sudo -s # password: tutorial VM2# bro -i br2 local b) Simple test to alert a possible threat from a external host VM1$ docker start -ai container1 Container1: $ nmap 10.1.1.4 # against container4 VM2$ ls -ls ~/test-bro/ VM2$ conn.log loaded_scripts.log notice.log packet_filter.log stats.log c) Check “notice.log” and Q4: explain the fields shown in that file.
  • 49. 4.7 Bro: Detecting Brute-force attacks Bro has a script to detect Brute-Force attacks. Check the file: $PREFIX/share/bro/policy/protocols/ssh/detect-bruteforcing.bro module SSH; export { redef enum Notice::Type += { Password_Guessing, Login_By_Password_Guesser, }; redef enum Intel::Where += { SSH::SUCCESSFUL_LOGIN, }; const password_guesses_limit: double = 30 &redef; const guessing_timeout = 30 mins &redef; const ignore_guessers: table[subnet] of subnet &redef; } event bro_init() { local r1: SumStats::Reducer = [$stream="ssh.login.failure", $apply=set(SumStats::SUM, SumStats::SAMPLE), $num_samples=5]; SumStats::create([$name="detect-ssh-bruteforcing", $epoch=guessing_timeout,
  • 50. 4.7 Bro: Detecting Brute-force attacks $reducers=set(r1), $threshold_val(key: SumStats::Key, result: SumStats::Result) = { return result["ssh.login.failure"]$sum; }, $threshold=password_guesses_limit, $threshold_crossed(key: SumStats::Key, result: SumStats::Result) = { local r = result["ssh.login.failure"]; local sub_msg = fmt("Sampled servers: "); local samples = r$samples; for ( i in samples ) { if ( samples[i]?$str ) sub_msg = fmt("%s%s %s", sub_msg, i==0 ? "":",", samples[i]$str); } # Generate the notice. NOTICE([$note=Password_Guessing, $msg=fmt("%s appears to be guessing SSH passwords (seen in %d connections).", key$host, r$num), $sub=sub_msg, $src=key$host, $identifier=cat(key$host)]); }]); }
  • 51. 4.7 Bro: Detecting Brute-force attacks event ssh_auth_successful(c: connection, auth_method_none: bool) { local id = c$id; Intel::seen([$host=id$orig_h, $conn=c, $where=SSH::SUCCESSFUL_LOGIN]); } event ssh_auth_failed(c: connection) { local id = c$id; # Add data to the FAILED_LOGIN metric unless this connection should # be ignored. if ( ! (id$orig_h in ignore_guessers && id$resp_h in ignore_guessers[id$orig_h]) ) SumStats::observe("ssh.login.failure", [$host=id$orig_h], [$str=cat(id$resp_h)]); }
  • 52. 4.8 Configuring alerts in Bro We show an example of an alert against Brute-force attacks, configured in Bro IDS. Create the file brute-force.bro and write below the following: @load protocols/ssh/detect-bruteforcing redef Site::local_nets = { 10.1.1.0/24, }; redef ignore_checksums = T; redef Notice::mail_dest = "<user@domain.com>"; redef Notice::emailed_types += { SSH::Password_Guessing, }; redef SSH::password_guesses_limit=10; hook Notice::policy(n: Notice::Info) { if ( n$note == SSH::Password_Guessing && /10.1.1.5/ in n$sub ) add n$actions[Notice::ACTION_EMAIL]; }
  • 53. 4.9 Simulating an attack of Brute-force Now execute again the Bro program from the directory ~/test-bro in VM2. Remember execute bro from Super User VM2~/test-bro# bro -i br2 <script>.bro From container1, execute the program “hydra” to generate massive tries to authenticate against a SSH server located in the container4 Before executing Hydra, create two files, “users.txt” and “pass.txt”, they should contain a list of possible users and passwords to be used by Hydra program. container1$ hydra -L users.txt -P pass.txt 10.1.1.5 ssh After few seconds, Bro IDS should be able to detect such attack. Check the directory “~/test-bro” and take a look the file “notice.log” Q5: What can you say about the contents of notice.log? Take a look the file $PREFIX/share/bro/policy/protocols/ssh/detect-bruteforcing.bro Q6: Which parameters can you change to modify the behavior of the alerts against brute-force attacks?