===================================================== |netinvm|_ ===================================================== -------------------------------------------------------------------------------- A tool for teaching and learning about systems, networks and security -------------------------------------------------------------------------------- .. |today| date:: :Authors: Carlos Perez & David Perez :Date: |today| .. contents:: .. |netinvm| replace:: NETinVM .. _netinvm: index.html .. |vmware| replace:: VMware .. _vmware: http://www.vmware.com .. |virtualbox| replace:: VirtualBox .. _virtualbox: https://www.virtualbox.org .. |UML| replace:: User-mode Linux .. _UML: http://user-mode-linux.sourceforge.net/ .. _openSUSE: http://opensuse.org .. _Debian: http://debian.org 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 |UML|_ (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. |UML| 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`` UMLs connected to the internal network. ```` can take values from 'a' to 'f', both inclusive. These machines only offer SSH service by default. ``dmz`` 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`` 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. .. figure:: img/netinvm_general.png General view of |netinvm| in VMware. The document example-net.pdf_ offers a detailed view. .. _example-net.pdf: example-net.pdf 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.., where is either 0 ('ext'), 1 ('dmz') or 2 ('int'), and 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:0, where is either 0, 1 or 2 (following the same domain rule as IP addressing) and 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' and 'dmz') 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'), 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: .. figure:: img/UML_desktop_folder.jpeg 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. .. figure:: img/netinvm_exta_60.jpeg :target: img/netinvm_exta.jpeg 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: .. figure:: img/netinvm_lista_ventanas.jpeg 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') .. figure:: img/netinvm_wireshark_interfaces_60.jpeg :target: img/netinvm_wireshark_interfaces.jpeg #. 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) .. figure:: img/netinvm_wireshark_captura_60.jpeg :target: img/netinvm_wireshark_captura.jpeg 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//cow' on 'base', where 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//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" . .. __: ex-nmap.html Download information ==================== |netinvm|_ can be downloaded directly from its main page: index.html__ .. __: index.html#download