(This is part of TOOGAM's “Making a virtual machine” Tutorial on Cyber Pillar.)
Requirements for the “Making A Virtual Machine” Tutorial
(Much of the text in this section also applies to the section of requirements for making a network of multiple virtual machines. Some items in this list may not be related to making a single virtual machine, and should/will be moved to the tutorial about making a network consisting of multiple virtual machines.)
This list may seem like a fairly long list of requirements; it is fairly long at least in part due to the amount of material this guide covers. Hopefully many, or even all, of these requirements are fulfilled. So, hopefully reading through the entire list will be non-impacting. However, if any of these are not fulfilled, substantial time might be saved by having these addressed early on. Thus, this guide recommends starting by making sure that requirements are fulfilled, so that showstoppers don't cause a screeching halt shortly down the road.
If any of these requirements are not met, the recommendation is not to abandon this tutorial and look for a different tutorial with fewer requirements. Instead, the recommendation is to make whatever changes are needed to be able to fulfill the requirements. This guide will likely contain information and/or references that will effectively remedy most problems that are likely to occur, while many other tutorials do not.
- A machine capable of running several virtual machines. It is recommended that this machine have multiple NICs so that it may effectively firewall traffic.
- [#docedos]: Documentation
Using an operating system that this documentation sufficiently covers:
- For now, this host machine should be using some sort of Unix-like platform.
The most recommended course of action is for the host machine to use an operating system that this document is meant to be used with. Otherwise, there may be some differences between the documentation and what is expected.
For now, the list of operating systems that are likely covered fairly well by this operating system consists of the following operating systems:
- OpenBSD: The “Free, Functional & Secure” operating system that ships “Secure By Default”
(At the time of this writing, the guide has been focused on having things work well with that one operating system. Supporting other operating systems is a task to be performed in the future, after the site has been publicly launched.)
- Knowledge about how to install an operating system, including handling disk partitions. Related information is currently available in the MBR partition information in the Techn's area, and the section describing the topic of how data is laid out on disks. Further details about creating partition layout is expected (perhaps in the future) to become available at the Tutorials page (possibly from the guide to installing an operating system).
(This may not yet be true, but is expected to be true in the future, after this guide is updated.) Some of the steps in this guide will benefit from having IPv6 support. If the only public Internet access available is IPv4-only Internet access, this guide does provide some detail for setting up the IPv6 support. However, IPv6 access is hereby being listed as a requirement, because some steps in the guide may not be available until IPv6 Internet is somehow available. (It does not matter whether the IPv6 access is direct, or through the tunnel brokers. Note: the choices of worldwide tunnel brokers has not regularly been changing dramatically, so being banned from such a tunnel broker may prevent some of this guide from being completed. So, uh, don't get banned from such providers.)
(A guide to using IPv6 may be helpful.)
Virtual machine software:
An early step which is briefly mentioned is to have virtual machine software installed. Much of the rest of this guide may operate under the assumption that virtual machine software is already installed. (The guide does not require that such software is pre-configured, but simply having such software being initially installed can be helpful.)
Instructions for installing this in some operating systems may be elaborated upon by this tutorial, but for now here's some starting information:
- [#vmhstdoc]: List of virtualization software options that are supported by this guide
There are multiple virtual machine software options available. However, this guide may not (fully/sufficiently) cover each one of them.
For now, if the intent is to closely follow this guide, the virtual machine software being used should be one of the following:Qemu (as noted by the overview of the “Qemu” software) - although networking may present problems for people trying to run Qemu from within Microsoft Windows.
(Additional virtual machine software packages may be covered in more detail in the future. Currently, at the time of this writing, the plan is to definitely add information about more virtual machine software solutions, including KVM. (Some other solutions might be added at a later time, after IPv6 information is further elaborated upon, and when/after additional operating systems are supported by this guide.))
- Networking notes
- Qemu in Microsoft Windows
- Note on Qemu within Win9x
- Using Qemu under an operating system using the Win9x code base may not be sufficient for much of this guide, simply because the Qemu release for Win9x may not sufficiently support networking.
- Qemu in other versions of Microsoft Windows
- Trying to use networking in Qemu in Windows is not necessarily the easiest task, even if using Windows 2000 or Windows XP or newer. Until that situation is known to have improved, an easier approach may be to use some other virtualization software.
- Other options
- Many of these techniques might be able to be implemented using some other available options of virtual machine software (mentioned on the virtualization page). However, do not expect that this guide will fully walk a user through all of the steps if that software isn't in the list of virtualization software options which are supported by this guide.
- Installation instructions
- (Instructions for installing this in some operating systems might someday be elaborated upon by this tutorial, but for now, some starting information (particularly for modern operating systems other than Microsoft Windows) might be available at general software installation instructions.)
- Clearly, at least one network interface will be needed for this machine to interact with other networks (such as the Internet).
- The machine can effectively serve as a firewall. For that to happen relatively easily, this physical machine should have at least two NIC connectors. One of these will go out to the Internet, and the other will be protected machines. Working around this may be possible with some additional work (which may or may not be well documented on this site) and may result in less ideal network protection (because the firewall might be fairly easy to circumvent, simply by using traffic routing that does not send the traffic through the firewall).
- Optionally: A third network connector, such as an antenna for WiFi, and a forth connector to go to some other trusted service (such as shared files), can certainly be benficial. It is the plan to have details for this, though they may not be up yet.
implementation of virtual NIC compatability. For networking to function in a desirable way, one of the following should probably be used:
virtual network interfaces that use TAP/TUN technology.
For further information, see the section on
a TUN/TAP device.
This guide involves using three TAP devices (which are virtual,
IPv4 only, one may get by using two TAP
devices and then Qemu may use a
-net socket” type of connection. However, since Qemu notes on documentation suggest this uses slirp like usermode, perhaps this
socket-type method is specific to supporting only TCP/IPv4 and UDP/IPv4. That would prohibit the ICMP protocol commonly used by
- (For IPv4 only, one may get by using two TAP devices and then Qemu may use a “
There may be some alternatives. The guide to Using a standard-looking virtual NIC on the host machine to communicate with the virtual machine's NIC is likely to list any such details. For example: Using Virtual Distributed Ethernet and Dnsmasq with Qemu. This has not been fully tested by the author/maintainer of this guide. Early speculation suggests this might be a less compatable solution than TUN/TAP. So, if you just want things to work, and if TUN/TAP isn't providing any roadblocks, it may be easiest to start by trying that more-established/older method (at least for now...)
- [#reqtapdv]: virtual network interfaces that use TAP/TUN technology. For further information, see the section on having/creating a TUN/TAP device. This guide involves using three TAP devices (which are virtual, software “objects”).
An understanding of networking. Some specific knowledge that may be helpful include:
- Understanding when traffic goes to a default gateway
- Understanding the concepts of VLSM/CIDR notation (a.k.a. IPv4 prefix length) and subnet masks. (Wildcard masks are also good to know about, but probably won't be getting used here.) A tutorial on this may be made available later, but isn't yet (such a tutorial, with heavy RFC references, is probably already made, but hasn't been integrated with these instructions yet). So, for now, just find such a tutorial on a search engine. (Search for learning about subnet masks and how AND logic is used.)
- Understanding the notation of IPv6 addresses and address ranges is expected for one to, easily, fully understand what is said. Details are officially documented at RFC 4291: “IPv6 Addressing Architecture”, Section 2.2: “Text Representation of Addresses”, forms #1 and #2.
Some other knowledge will make completion of the tutorial easier. However, if this knowledge is lacking, the tutorial may still be rather possible to complete. Completion may take a bit longer. As a bonus, though, some of this knowledge may be effectively gained by completing the tutorial for making a single virtual machine.
- Understanding of the purposes of common protocols (e.g. for automatic addressing and name resolution) may help: detailed knowledge of how they are implemented in IPv6 is not a requirement, and this tutorial will help people familiar with how that works in IPv4 to gain familiarity and experience with how these things work in IPv6.
- Having an understanding of the different layers of networking. However, lacking these details might still be sufficient enough to make one's way through the tutorial.
- These instructions may assume an active IPv4-based Internet connection. (It is hoped that this will change so the assumed connection may be support IPv4-based and/or IPv6 communications. For now, though, this guide might somehow assume IPv4-based Internet.)
Some way to usefully view the state of a virtual machine. Some quick
notes about how that may be accomplished:
A working X Windows session will work
If using Qemu and not using
VNC, simply leave off the
portion of the command line that says
-”. Note that using VNC (via an SSH tunnel) is generally preferred over trying to use X forwarding.
- If using Qemu and not using VNC, simply leave off the portion of the command line that says “
- Instructions on how to perform the viewing of the virtual machine are provided (and referenced in later instructions). However, there could be some difficulties if trying to use a text-mode interface to control a virtual machine running a graphical user interface. Even such an unlikely thing is being mentioned because, if such a scenario happened, it would be an issue that could be a showstopper (or at least a showslower).
- A working X Windows session will work
- We'll also need some IP addresses. Because these may come from ranges of addresses reserved for private use, there should be plenty of addresses available at no financial cost. (However, if working with another network that also uses such IP addresses, make sure the IP addresses chosen don't conflict.)
We'll need some port numbers. Lots of port numbers...
Several port numbers will need to be used. Fortunately, there is generally a surplus of port numbers that may be used. However, it will be even nicer is to have a nice range of port numbers which are fully unused (instead of trying to use a bunch of non-sequential port numbers).
- Usability of dynamic/private/ephemeral ports
IANA's list of TCP and UDP port numbers says “The Dynamic and/or Private Ports are those from 49152 through 65535”.
However, although private port numbers may be used from this range, a lot of software will use these as the range of dynamic ports. Dynamic ports were also referred to as ephemeral ports by old BSD versions, and that name is also rather comomnly used for these sort of ports. In addition to being used by outgoing connections, these port numbers may be used by some other software. For instance, OpenBSD's man page for FTP: section on “Port Allocation” shows that OpenBSD's ftp program “will listen to a random high TCP port.” This is an example of how TCP ports on that operating system may be used from within the range of the sysctl called net.inet.ip.porthifirst (defaulting to 49152) through the sysctl net.inet.ip.prothilast (defaulting to 65535). (There are additional sysctl values which are just as existant: sysctl's net.inet.ip.portfirst (which defaults to 1024) through the sysctl net.inet.ip.portlast (which defaults to 49151). However, rather than using those lower numbers, the software does default to using the traditional ephemeral port range.)
(This section is simply informative, and the information may not be essential for the following steps to work. That doesn't mean that an academic program wouldn't be allowed to use it in a test.)
- Usability of port numbers from the “Registered Ports”
There may be some desire to use the ports which are less likely to be used, within the range of what IANA's list of port numbers calls “Registered Ports”. Such behavior violates IANA's note on that page which says “UNASSIGNED PORT NUMBER SHOULD NOT BE USED.” Despite the fact that such usage may be violating IANA's guidelines, using these ports may still be desirable because these ports are unlikely to already be in use. After all, as just shown (in the “Usability of dynamic/private/ephemeral ports” section), those higher port numbers may not always be entirely available for private use.
The reality is that using a port number for private use is likely to work, and is unlikely to cause problems, unless another application attempts to use that port (either by trying to actually use the port or, more sanely, checking that the port is available before trying to use it). An application can feasibly require a specific port number, and can do so without violating some of the most important networking standards, if the program is trying to support a protocol that specifies a port number that is assigned by IANA. Such a requirement may be considered to be valid behavior. However, since requiring a specific port can cause some problems (or may at least cause some inconvenience which is caused by inflexibilty), most programs are configurable to be able to avoid such problems by using a customizable port number.
The restriction about not using unassigned port numbers may not even be meant to be universally followed: Software developers may be expected to test software in controlled environments (where problems would not affect any systems except for those of the developer). IANA may not assign a port until after successful implementations exist. (An example of implementations being required for a port assignment is shown by the “final note” in OpenBSD 3.5 commmentary about petitioning IANA for a port number for CARP. Not having multiple actual implementations may not have been the only issue: Wikipedia's documentation on CARP not having an official port number describes a lack of some documentation being an issue. Still, this may be an example of how there was a general expectation that an unassigned port was being used while the port still was not assigned yet.) Clearly ports are likely to be getting used during software development (including testing) before the possible existance of recognized successful implementations.
- Some port numbers that may be available
Looking for some large ranges of numbers that do not have ports assigned by IANA?
The following paragraph was true at the time of being initially written (but may not still be true). Some ports that are still unassigned by IANA (as determined by IANA's list of TCP and UDP port assignments) may be around port numbers 4610 or 5370 or 5510 or 6720. For VNC, there are several ports from 5900 to 5998 available, although not all the numbers in that range are unassigned by IANA, so the best practice would be to check before using them. Ports 47809 and higher provide 191 unassigned ports. 8475 represents a range of 25 unassigned followed closely by a range of over 50 unassigned ports. (Above that range, the author of this text stopped scanning the list quite so closely for trying to find blocks of about 30 or much larger.) Port 32500 is in a range over a hundred unassigned ports. So is port 34400. 43442-44320 is a range of 879 addresses. 44323-44552 is 230 addresses, including 44400 which may be nice to count up from.) There is a block of over 500 unassigned ports at 47002-47556 and another block of over 500 unassigned ports from 48620-59150. In between those ranges (from 47557 to 48632), there are just over a dozen assigned ports, and multiple blocks of hundreds of unassigned ports.
All of those just-mentioned numeric ranges, with many sequential unused port numbers, are subject to change: IANA may simply add a number to the list of used port numbers. So, before trusting any numbers of that list, do check IANA's list of TCP and UDP port assignments for the latest information. (That list of numbers is not authoritive and may be out of date, but may still be useful because the list may provide some ideas of where to start looking.)
- Knowledge requirements
This tutorial may assume a fairly high amount of basic computer knowledge, including basic network terminology and setups and the ability to install an operating system (including disk partitioning (to set up a desired disk layout)).
Hopefully most/all additional knowledge required (other than what was just referred to) is either listed in this “requirements section” or, better yet, is documented on this website and is hyperlinked to by this tutorial. For some of the topics in the “Requirements” section, hopefully those details will be added to the site (and hyperlinked to from this guide) at a later time.
Some concepts, which are considered to be fairly basic, may be assumed. Examples may include: running a program from a command line (with one or more command line parameters) (details may be available at user interface basics), and editing text files. (This guide may provide details about how to accomplish some of those tasks, like editing a text file, in a specific operating system. Even still, having the general concepts understood may be helpful.) If some of that knowledge is lacking, this guide may be a bit on the advanced side. The guide may still be useful, and perhaps more useful than some other resources, but do anticipate there may be some troubles and/or other challenging aspects.
That completes this “requirements” section.