20 October 2013

Creating virtual laboratories with Netkit (II)

In my previous article about Netkit, we saw a simple example of its ability to simulate a network with multiple devices. The possibilities are almost endless, but we do need some kind of automation if we want to simulate complex topologies, with many nodes and especially if we pass these topologies to other researchers to experiment with them. Netkit provides this level of automation by laboratories, directory structures containing files to configure each of the nodes automatically. The good thing is that we can compress this directory tree and pass it to other researchers who can boot the lab and have all nodes configured and running with just a single command. In addition, this compressed file is really little since the configuration files on each node are text only.

We are going to prepare an example of a laboratory to simulate a scenario in which Alice is connected to the Internet from the switched network in your organization. What she doesn't know is that an intruder has gained access to the network and intends to launch a arp-spoofing attack against Alice to find out which internet pages she visits.

First of all we set Netkit to work properly in our operating system in  laboratory mode. First step is setting global variables used by Netkit. In the previous article we configured those variables correctly, problem is that when you start a laboratory in which one of the computers is to be connected to the Internet you have to use sudo which, for security, ignores most of the global variables, including those that we configured and used as normal users. A workaround is to configure sudo to not ignore Netkit variables by editing /etc/sudoers. In the "Default" of this file we must write:

Defaults:dante env_keep+="NETKIT_HOME", env_keep+="MANPATH"

Of course, instead of dante your own username must be used. You should set PATH and common sense says that you should be able to configure the sudoers as the other two ... the problem is that  sudo does not work that way and continues to ignore the user's PATH although we we configure in sudoers that way. It is something that is already reported in the Ubuntu launchpad as a bug long dragged. The solution is to create an alias that includes the user PATH every time we use sudo. To do this edit the file .bash_aliases in our home directory and write:


alias sudo="sudo env PATH=$PATH"

With that Netkit has all the necessary variables, whether we use sudo as if we run it as a normal user.

Besides, version 2.6 has a bug that prevents the virtual machine that acts as a gateway to Internet to run properly, the solution is a patch that one of the authors of the application wrote on the mailing list:

diff -Naur netkit-old/bin/script_utils netkit-new/bin/script_utils
--- netkit-old/bin/script_utils 2007-12-19 10:55:58.000000000 +0100
+++ netkit-new/bin/script_utils 2008-02-02 12:48:46.000000000 +0100
@@ -317,8 +317,8 @@
# This function starts all the hubs inside a given list
runHubs() {
- HUB_NAME="$1"
while [ $# -gt 0 ]; do
+ HUB_NAME="$1"
BASE_HUB_NAME="`varReplace HUB_NAME \".*_\" \"\"`"
"$BASE_HUB_NAME" ]; then
# This is an Internet connected hub
@@ -328,7 +328,7 @@
# This is a normal hub
- startHub "$1"
+ startHub "$HUB_NAME"
One way to apply this patch is to create a text file in $ NETKIT_HOME /bin/ called patch2_6_bug patch with the patch text and immediately do: 
dante@Hades:/usr/share/netkit/bin$ sudo patch script_utils patch2_6_bug patching file script_utils dante@Hades:/usr/share/netkit/bin$

This ends the worst part: Netkit preconfiguration . The good thing is that you just have to do it only once, from now on you will only have to worry about creating good laboratories .

To begin with ours, we have to create a folder to contain the directory tree and the configuration files. In that folder you create the main configuration file of the laboratory: lab.conf. We can store in that file all those parameters we would use with vstart to define a single machine . We can define how many interfaces have every node and to which collision domain would belong each one ( we must remember that, unlike hubs , switches define a different collision domain for each of its ports ). Another element that can be defined is the RAM used by every machine. You can also include information to identify the laboratory for its author, a , version, etc.. In our example, lab.conf file is as follows:

dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat lab.conf LAB_DESCRIPTION="Laboratorio para simular un ataque de ARP-Spoofing" LAB_VERSION="0.1" LAB_AUTHOR="Dante" LAB_EMAIL="dante.signal31@gmail.com" LAB_WEB="http://danteslab.blogspot.com/" PC-Alice[mem]=100 PC-Sniffer[mem]=100 Router[mem]=100 Switch[mem]=100 PC-Alice[0]=CD-A Switch[1]=CD-A PC-Sniffer[0]=CD-C Switch[2]=CD-C Router[1]=CD-B Switch[0]=CD-B Router[0]=tap,

The last line sets the eth0 interface of the router as tap. That is equivalent to establish a point to point line between the virtual machine Router ( and our real PC ( through which your router can go to the Internet using your PC as a gateway. In fact, when we start the lab if we do a ifconfig on your PC you will see that it has created an interface called nk_tap_root with IP As the default route is concerned, Netkit puts a static route on Router pointing to This allows Router go to Internet normally but if we also want to let the rest of the virtual network PCs go to Internet (using Router and real PC as gateways) we add a path in our real PC to the virtual network:

dante@Hades:~$ sudo route add -net netmask gw

Now, inside the lab folder of the lab we are going to create a subdirectory for each virtual machine to be used.
dante@Hades:~/netkit_labs$ mkdir lab_sniffing_sw dante@Hades:~/netkit_labs$ cd lab_sniffing_sw/ dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir Routerdante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir Switch dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir PC-Alice dante@Hades:~/netkit_labs/lab_sniffing_sw$ mkdir PC-Snifferdante@Hades:~/netkit_labs/lab_sniffing_sw$ ls PC-Alice PC-Sniffer Router dante@Hades:~/netkit_labs/lab_sniffing_sw$

The subdirectories of the virtual machines can stay empty or be used to deposit files to make then appear in the virtual machine. For example if we wanted to Alice PC-X to have the script in /usr/bin, we would create the folder "/netkit_labs/lab_sniffing_sw/PC-Alice/usr/bin" and we wold leave there a copy of the script. In our case what we qould put in the /etc/ from each team the necessary files for configuration of network resources properly.

For the case of Alice, be as follows:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat ./PC-Alice/etc/network/interfaces auto lo eth0 iface lo inet loopback address netmask iface eth0 inet static address netmask gateway

The PC-Sniffer will have the following network configuration:
dante@Hades:~/netkit_labs/lab_sniffing_sw $ cat ./PC-Sniffer/etc/network/interfaces auto lo eth0 iface lo inet loopback address netmask iface eth0 inet static address netmask gateway
The router will have the following network configuration:
dante@Hades:~/netkit_labs/lab_sniffing_sw $cat ./Router/etc/network/interfaces auto lo eth1 iface lo inet loopback address netmask iface eth1 inet static address netmask

Also, if we want our virtual machines perform DNS resolutions (essential if we install packages with apt or browse using lynx), we have to include a file /etc/resolv.conf on each of the virtual machines like hicimo s with /etc/network/interfaces. A copy of the contents of the file /etc/resolv.conf of our real PC will be enough.

The final step is to configure the switch and decide which services are to be started on each virtual machine. For that, Netkit lets define which commands are run during startup and shutdown of virtual machines using the startup and shutdown scripts respectively. For our lab we will create the following scripts:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat Switch.startup ifconfig eth0 up ifconfig eth1 up ifconfig eth2 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 brctl addif br0 eth2 brctl stp br0 on ifconfig br0 up

This script configures a bridge after Switch machine boot by incorporating the bridge ports eth0, eth1 and eth2 and also activating the spanning-tree (unnecessary in this case because there is only one switch but it is a habit we should have) .

Startup commands of the rest of the machines are easier because all they do is start the network service:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat Router.startup /etc/init.d/networking start dante@Hades:~/netkit_labs/lab_sniffing_sw$ cat PC-Alice.startup /etc/init.d/networking start dante@Hades:~/netkit_labs/lab_sniffing_sw $ cat PC-Sniffer.startup /etc/init.d/networking start

This example is very simple, but thanks to these scripts we can do that a laboratory configures itself without the end user having to do anything. In fact, the best is to configure the IP addresses of the interfaces and routes through these scripts instead of copying the configuration files in the /etc of each machine, but taking that detour gave me the opportunity to explain how to input files in the directory tree of virtual machines.

Now, finally, it's time to start our laboratory. The laboratories are started with the order lstart and stopped with lhalt. Let's see what happens in our case:
dante@Hades:~/netkit_labs/lab_sniffing_sw$ sudo lstart [sudo] password for dante: 033[1m======================== Starting lab ===========================033[0m Lab directory: /home/dante/netkit_labs/lab_sn iffing_sw Version: 0.1 Author: Dante Email: dante.signal31@gmail.com Web: http://danteslab.blogspot.com/ Description: Laboratorio para simular un ataque de ARP-Spoofing 033[1m=================================================================033[0m 033[1mStarting "PC-Alice" with options "-q --mem=100 --eth0 CD-A --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/ho me/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "PC-Sniffer" with options "-q --mem=100 --eth0 CD-C --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/hom e/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "Router" with options "-q --mem=100 --eth1 CD-B --eth0 tap,, --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/home/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mStarting "Switch" with options "-q --mem=100 --eth1 CD-A --eth2 CD-C --eth0 CD-B --hostlab=/home/dante/netkit_labs/lab_sniffing_sw --hostwd=/home/dante/netkit_labs/lab_sniffing_sw"... 033[0m 033[1mThe lab has been started.033[0m 033[1m===================== ============================================033[0m dante@Hades:~/netkit_labs/lab_sniffing_sw$

To check that the resulting network works we can try surfing the Internet with lynx from PC-Alice:

Now that we have checked that our network works we can give our laboratory an use performing the experiment mentioned at the beginning of the article: An ARP -Spoofing attack against Alice from PC - Sniffer .

As you can see in the photo above, PC - Sniffer has activated a tcpdump , but only see the traffic spanning tree (STP) issued by the switch. Unlike previous article network in which I simulated a hub, this switch does not replicate traffic on all ports but only on the port that connects the destination of the data.

To spy traffic between Router and PC- Alice we will have to place ourselves between them making them believe they talk each other when actually they do with PC- Sniffer .

We will use Ettercap tool, which is installed by default in Debian that brings Netkit (if not, you could install it with a simple " #aptitude install ettercap" , as we would in our real PC) . Ettercap allows interception on switched networks . It really is a little wonder that deserves an article to itself . Here we will use Ettercap from PC-sniffer to spy Alice web traffic . To activate an ARP -Spoofing attack (also called ARP- Poisoning) with Ettercap the order would be:

PC-Sniffer# ettercap -M arp:remote -T / /

Immediately PC-Sniffer screen start draining the contents of the data exchanged between PC-Alice and her gateway, Router, while browsing the Internet:

To stop the lab you just have to do "sudo lhalt " from the root directory of the lab (where we formerly launched  lstart ) . If we wanted to relaunch the laboratory we must take into account the need to put back the path to the virtual network which disappeared when lhalt disabled the tap interface. On the other hand, lstart created .disk files in the lab folder to not to lose the programs you have installed on virtual machines or any other changes we have made. That means that the folders where we placed configuration files are no longer read so if you want to put new files there first you have to delete the .disk files and do a Netkit lstart to re-read those folders. There is another useful option to transfer files to and from virtual machines using the /hosthome folder that there is in all virtual machines which mounts the user's home that launched the Netkit .

In another article I will explain how Ettercap works and other interception techniques . This article  served to demonstrate the utility of Netkit to simulate the complex networks that make computer security experiments possible with a considerable saving in both effort and money and space. It is also an invaluable aid for those who intend to teach the art of computer security, allowing us to offer our readers preconfigured laboratories to let student focus exclusively on the techniques explained without having to waste time setting up a test network on their own. Thats why, my further articles will include links to Netkit laboratories especially designed to train in a way fast and simple what is explained in them.