NETinVM

A tool for teaching and learning about systems, networks and security

Authors:	Carlos Perez & David Perez
Date:	2016-11-03

Contents

Introduction
Description of NETinVM
Working with NETinVM
A More Detailed Description
- Storage in the UML systems
Sample Exercises
Download information

Introduction

NETinVM is a VMware virtual machine image that provides the user with a complete computer network. For this reason, NETinVM can be used for learning about operating systems, computer networks and system and network security.

In addition, since NETinVM is a VMware image, it can be used for demonstrations (i.e. in classrooms) that can be reproduced by students either in a laboratory or on their own laptop and thus, at home, at the library... For these reasons we present NETinVM as an educational tool.

Description of NETinVM

NETinVM is a VMware virtual machine image that contains, ready to run, a series of User-mode Linux (UML) virtual machines. When started, the UML virtual machines create a whole computer network; hence the name NETinVM, an acronym for NETwork in Virtual Machine. This virtual network has been called 'example.net' and has fully qualified domain names defined for the systems: 'base.example.net', 'fw.example.net', etc.

All of the virtual machines use the Linux operating system. The VMware virtual machine is called 'base' and it runs Debian 8. User-mode Linux machines also use Debian 8 and they have different names depending on their network location, because they are grouped into three different subnets: corporate, perimeter and external. The subnetworks are named 'int' (for internal network), 'dmz' (for DMZ or demilitarized zone, usually used as a synonym for perimeter network) and 'ext' (for external network).

One of the UML machines, 'fw', interconnects the three networks ('int, 'dmz' and 'ext'), allowing for communication and packet filtering. The rest of the UML machines have only one network interface, connected to the network they are named after:

int<X>

UMLs connected to the internal network. <X> can take values from 'a' to 'f', both inclusive. These machines only offer SSH service by default.

dmz<X>

UMLs connected to the perimeter network (DMZ). They are supposed to be bastion nodes. Two preconfigured bastion nodes are provided, each one with its appropriate alias:

'dmza' is aliased as 'www.example.net' and it offers HTTP and HTTPS services.
'dmzb' is aliased as 'ftp.example.net' and it offers FTP.

ext<X>

UMLs connected to the external network (ie: Internet).

Because a picture paints a thousand words, or so they say, the following figure shows NETinVM with all of the virtual machines running inside.

General view of NETinVM in VMware. The document example-net.pdf offers a detailed view.

All of the elements referenced before are shown in the image with their IP and ethernet addresses. The following rules have been used for assigning addresses:

IP addresses are of the form 10.5.<NET>.<MACHINE>, where <NET> is either 0 ('ext'), 1 ('dmz') or 2 ('int'), and <MACHINE> is either 10 for 'exta', 'dmza' or 'inta', 11 for 'b' and so on up to 15 for 'f'.
Network masks are 24 bits (255.255.255.0).
Ethernet addresses are CA:FE:00:00:0<NET>:0<MACHINE>, where <NET> is either 0, 1 or 2 (following the same domain rule as IP addressing) and <MACHINE> is either a, b, c, d, e or f.
The interfaces of 'fw' use 254 for IP and FE for ethernet.
The interfaces of 'base' use 1 for IP and 01 for ethernet.

In addition to the computers and networks already described, the figure also shows the real computer where NETinVM runs ('REAL COMPUTER') and VMware Player's typical network interface ('vmnet8'), which optionally interconnects NETinVM's networks with the external word.

When they boot, all UML virtual machines get their network configuration from 'base', which provides DHCP and DNS services to the three NETinVM networks through its interfaces 'tap0', 'tap1' and 'tap2'.

Routing works as follows:

The default gateway for the internal and perimeter networks (machines 'int<X>' and 'dmz<X>') is 'fw' (more specifically, the IP address of 'fw' in the corresponding internal or perimeter subnet).
The default gateway for 'fw' is 'base' (its external network address).
'base' (its external network address) is also the default gateway for machines in the external network ('ext<X>'), but they are configured to use 'fw' (external network address) as the gateway for accessing machines in the perimeter and internal networks.
'fw' applies NAT (SNAT, Masquerading) to all network traffic coming into it from the internal and perimeter networks and going out through its interface in the external network. So, these packets get to the external network with a source IP address of 10.5.0.254 (fw's IP address in the external network)

Thus, IP traffic exchanged among the three networks goes through 'fw', while traffic going out from NETinVM to the external world goes through 'fw' if (and only if) it comes from the internal or perimeter networks. All traffic going to the real world (outside NETinVM) exits through 'base' which, as 'fw' does, applies IP forwarding and NAT to this outgoing traffic.

Communication between 'base' and any UML machine, in both directions, is direct, without going through 'fw'. (When the communication is started from a UML machine, the IP address of the interface of 'base' in the corresponding network must be used.) This configuration permits access from 'base' to all UML machines using SSH independently of the packet filtering configuration at 'fw'.

As an additional consideration, please note that the SNAT configuration in 'fw' described above is necessary for responses to outgoing connections to the Internet originating from the internal or perimeter networks to come back through 'fw'. Otherwise they would be routed directly from 'base' to the UML machine through 'tap1' or 'tap2' without traversing 'fw'.

Working with NETinVM

Initial start-up

To start NETinVM you need to download the VMware image, uncompress it and run it with the VMware Player program, which can be downloaded free of charge from VMware. (Alternatively, you can also use the VirtualBox image and run it with VirtualBox).

Once the VMware has been started, base.example.net is running, offering a standard KDE desktop for the unprivileged user user1 Its password is "You should change this passphrase". The same password is valid for root, also. (The same users and passwords are also valid for UML machines).

The idea is for base to be a desktop in which to work while doing exercises and that's why it includes LibreOffice and other similar tools. It is also designed to be the best place to monitor the traffic in the internal networks (through tap0, tap1 and tap2) and that is why it also includes wireshark and tcpdump. Other tools can, of course, be added by the user.

Graphical interface

Starting in 2010, NETinVM includes a "Folder View" component labelled "UML machines" with graphical links to applications:

Links to applications to perfom most usual tasks with UML machines.

When clicked on them, the links perform the following actions:

"Run all": Brings to life NETinVM (see Full startup process).
"Shutdown all": Shuts down all UML machines.
"Backup UML machines": Creates a backup of the whole NETinVM network. (All machines must be shut down before backing up.) The backup is stored in a "tar.gz" file whose name can be set during the process. By default, backups are stored in "~user1/uml/backups" and are named "uml_machines_yyyy-mm-dd_hh-mm.tgz", where "yyyy-mm-dd_hh-mm" stands for date (year, month, day of month) and time (hours, minutes).
"Restore UML machines": Deletes current UML machine's state and restores a previous one. The backup file can be selected during the process. (All machines must be shut down before restoring a backup.)
"NETinVM Documentacion": Launches a browser which shows a local copy of this documentation.
"Configure my UMLs": Launches an editor to tune the script used by "Run my UMLs".
"Run my UMLs": Brings to life the subset of UMLs specified with "Configure my UMLs".
"Kill all": Kills all UML processes and performs some additional cleanup. Only to be used when "Shutdown all" leaves UML processes running.

Full startup process

The command uml_run_all.sh is the magic word that brings to life almost everything in NETinVM. Specifically, it launches the following elements:

the virtual hubs that make up the external (ext), internal (int) and screened (dmz) networks
the UML virtual machines: fw, exta, inta, dmza and dmzb.

Although NETinVM is ready to run up to six UML virtual machines per network ('a' through 'f'), with just the four mentioned above it is possible to develop a wide range of activities although in practice the less UML virtual systems running the faster the entire system will run.

Each UML virtual machine starts up on a different KDE virtual desktop:

exta on desktop 2
fw on desktop 4
dmza on desktop 5
dmzb on desktop 6
inta on desktop 8

On each desktop the following elements, all shown in the figure below, can be identified:

A terminal window that appears at the very end of the booting process and allows the user to log into the UML virtual sytem. It is the equivalent of a serial terminal hardwired to the UML virtual system.
Two more terminal windows which also work as terminals of the UML virtual system, but start minimized.
A minimized xterm window that works as the console of the UML virtual system, displaying system messages right from the start.

View of desktop 2 after booting exta.

Once all UML virtual systems have been started it is easy to locate their corresponding windows by using the list of windows from KDE, which can be accessed by clicking on the "Window list" icon in the panel or pressing 'Meta-w'. The result should be similar to the following figure:

List of windows after all UML virtual systems have been started.

All UML virtual systems have an unprivileged user user1. The default password for both user1 an root in all UML machines is (as with "base") "You should change this passphrase".

Usage example: capturing an HTTP connection

As an example of how NETinVM can be used for teaching and learning, this section will show how the network traffic of an HTTP connection could be generated, captured and analyzed within NETinVM.

Once all virtual systems have been started within NETinVM by executing the 'uml_run_all.sh' shell script, the procedure to follow is just as simple as if all systems were real. We will establish an HTTP connection from 'exta' to 'www.example.net' and we will capture and analyze that traffic using 'wireshark' running on 'base'.

Note

Note that 'base' has access both to the external network ('ext') and the screened subnet ('dmz') through its 'tap0' and 'tap1' network interfaces, respectively. Thus, we could capture the traffic on either network (or on both at the same time using two instances of 'wireshark') since packets will travel from 'exta' to 'fw' through the external network and then from 'fw' to 'www.example.net' ('dmza') through the 'dmz' network, and back. For this exercise, we will assume that we are interested only in the traffic in the 'dmz' network.

First, start 'wireshark' on 'base' and set it to listen on the 'dmz' network (interface 'tap1')
Then, log into 'exta' using one of its terminal windows on desktop 2 and request the home page of the web server running on 'www.example.net' by executing the following command:
```
$ wget www.example.net
```
Finally, go back to 'wireshark', stop the capture and analyze the traffic at your leisure. The session captured in 'wireshark' will look similar to the following figure, which shows the HTTP session that was established between 'exta' (10.5.0.10) and 'www.example.net' (dmza, 10.5.1.10)

A More Detailed Description

Storage in the UML systems

To save drive space all UML machines (including 'fw') use the same image for their root file system, contained in the file '/home/user1/uml/data/uml_root_fs' of 'base'. This file system includes a complete installation of a Debian 8 distribution and it takes up about 1.1 GiB of space:

user1@base:~> ls -lsh /home/user1/uml/data/uml_root_fs
1.1G -r--r--r-- 1 user1 user1 4.0G Sep 28 14:24 /home/user1/uml/data/uml_root_fs
user1@base:~>

The maximum size of this file system is 4 GB, which leaves enough room for the UML systems to store programs and temporary data (2.6 GiB, available on /dev/ubda):

exta:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       3.9G  1.1G  2.6G  29% /
devtmpfs        245M     0  245M   0% /dev
tmpfs           245M     0  245M   0% /dev/shm
tmpfs           245M  5.5M  239M   3% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           245M     0  245M   0% /sys/fs/cgroup
none             19G  5.5G   13G  31% /mnt/tmp
exta:~#

Also, the UML systems can use up to an additional 13 GiB on 'base', accessible through the network (e.g. scp) or through the '/mnt/tmp' folder that is mounted automatically in every UML system and which corresponds to the folder '/home/user1/uml/mntdirs/tmp' on 'base'.

The changes that each UML system makes on its root file system is stored, using UML's copy-on-write mechanism, in a separate file, '/home/user1/uml/machines/<machine>/cow' on 'base', where <machine> is the hostname of each UML system. Obviously, the size of these files will depend on the amount of changes that happen on each system, but if these are limited to the normal booting process and minor configuration changes then they tend to take up very little space:

user1@base:~> ls -lsh /home/user1/uml/machines/exta/cow
2.0M -rw-r--r-- 1 user1 user1 4.1G Nov  2 16:25 /home/user1/uml/machines/exta/cow
user1@base:~>

Note that the size really occupied in the hard drive is just 2,0 MiB and not 4.1 GiB, since it is a so called sparse file.

Finally, each UML system uses a further 512 MiB for swap space, on a file named '/home/user1/uml/machines/<machine>/swap' on 'base'. The space occupied by this file in the hard drive is, however, much smaller, unless the systems need to start paging memory to disk:

user1@base:~> ls -lsh /home/user1/uml/machines/exta/swap
4.0K -rw-r--r-- 1 user1 user1 512M Nov  2 16:24 /home/user1/uml/machines/exta/swap
user1@base:~>

Again, please note that the size really occupied by the file is just 4.0 KiB and not 512 MiB, since this is another sparse file.

Sample Exercises

The following documents describe some sample exercises that can be carried out using NETinVM.

Port Scanning with Nmap: Perform a full port scan against "www.example.net" from "exta.example.net" .

Download information

NETinVM can be downloaded directly from its main page: index.html