Curso de Open vSwitch con NFV dirigido para estudiantes de la Extecamp UNICAMP

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

3. Hands On

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?