Cooking With Technology

Howto: Virtual Isolated Network Using VMWare

I enjoy computer security. There aren’t a lot of opportunities to study it formally within computer science, so my education in this field is entirely from what I read and practice in my own time.

Most recently, I’ve been feeling the itch to write a worm. The idea is attractive because a worm can be developed modularly with reusable components. Each individual component will increase my knowledge substantially in a different area of security, making the development a measurable goal with incremental positive feedback.

However, before development could begin, I wanted to ensure that I wouldn’t end up in court for an accidental release of one of the components gone awry. I love virtual machines as a tool to aid in the development process, so the solution was immediately obvious - create a multi-host virtual network that is isolated from the world. Further, I wanted each machine on this isolated network to occasionally be able to access the Internet to retrieve updates or tools, so the isolation needed to be complete but /controllable./ The final requirements of the virtual network ended up looking like this:

• Isolated network except when explicitly given access to the Internet
• Multiple hosts with different operating systems
• Must be able to easily add and remove hosts
• All hosts on the network must both default and fail to isolation

The way to implement this using VMWare Workstation (and I’m sure other products in their virtualization line) is to utilize teams. Teams are a ‘wrapper’ of a sort that encompass multiple VMs with additional configuration. When you start a team, each virtual machine included in the team’s configuration is also started. The team can be configured to also provide a virtual network segment for the virtual machines to use, which when paired with each VM in the team being configured with ‘host only’ network access, results in a virtual isolated network.

The team doesn’t provide DHCP though, which means the network has to be maintained with static address and modifications to each machine’s host file. This hardly met my requirement for easily adding and removing hosts from the network. Creating a host that would act as the network server fulfills this requirement, and will also facilitate network control access. As we continue on, please note that I’m using Debian Linux with a 2.6.x kernel, and all of the commands I give below and edits to configuration files *must be done as a superuser.*

Enough setup: time for implementation. To speed the process, I created two base images, one Windows XP SP2 install, and one Debian Lenny netinstall with a 2.6.x kernel. Each image was updated to include the latest patches, user accounts were created, and standard tools were installed. Once these base images were created, they were set aside to never be modified. Clones of the base images are created for each of the expendable hosts, and one clone of the Debian base image was used as the only ‘permanent’ member of the team. All members of the team share one virtual network segment, and have one interface. The only exception to this is the network server VM, which is dual-homed to be connected to both the virtual network and the Internet via NAT.

All hosts default to DHCP, so cloned images have no need for additional configuration when added. The network server is the only machine that had be set up specially. The bind9 and dhcp3-server packages were obtained (for DNS and DHCP, respectively) using Debian’s awesome package manager:

apt-get install bind9 dhcp3-server

Configuring bind is trivial, it defaults to forwarding DNS requests, so nothing is required as far as configuration unless you want to. dhcpd, provided by dhcp3-server, is a little more complicated. First, the interface connected to the isolated network must be set up to have a static address in the subnet in which you will be offering IP addresses, like 10.10.10.1 for the 10.10.10.x subnet or 192.168.30.1 for the 192.168.x.x subnet. It would be wise to modify your interface configuration to make this change survive rebooting.

/etc/network/interfaces:

auto lo eth0 ethiface lo inet loopback

iface eth0 inet static
 	address 10.10.10.1
 	netmask 255.255.255.0iface eth1 inet dhcp

The external interface is eth1, and is configured with DHCP since it is NAT routed. The internal interface is eth0, and is given an ip of 10.10.10.1 with a subnet mask of 255.255.255.0. (This means that the last quartet of the IP address is variable and available for use.) Next comes the configuration for dhcpd:

/etc/dhcp3/dhcpd.conf:

default-lease-time 600;max-lease-time 7200;
authoritative;option domain-name-servers 10.10.1.1 192.168.30.1

subnet 10.10.10.0 netmask 255.255.255.0 {
 range 10.10.10.2 10.10.10.254;
 option routers 10.10.10.1;
 option ip-forwarding off;
 option broadcast address 10.10.10.255;
 option subnet-mask 255.255.255.0;
}

Here we are saying that the subnet is 10.10.10.*, and that we will assign addresses from 10.10.10.2 - 10.10.10.254. The other options should be self-explanatory - read up on networking if you have questions. As it stands, when the interfaces are brought down and back up and dhcpd is started, addresses will be assigned to all virtual machines sharing that network segment. If this is all you want, just issue:

ifdown eth1 eth0
ifup eth1 eth0
/etc/init.d/dhcpd3-server start

And you are done! The machine now will serve DHCP to the isolated subnet, while maintaining separate access for itself to the Internet.

However, if you want to continue on to enable Internet access for other hosts on the isolated network, we still have some work to do.

My solution for this involves iptables and masquerading. Before we do anything, we’ll need to enable IP forwarding. This can be done in multiple ways, but the most reliable for me has been the following simple command:

echo 1 > /proc/sys/net/ipv4/ip_forward

With IP forwarding enabled, we can now utilize the masquerading features of iptables, the Linux firewall. By creating rules that will take packets coming in from our internal network’s interface and sending them out on our external interface, in addition to creating a complementing rule that will accept return packets coming in from the external interface headed for the isolated host, we can accomplish this. The individual rules for my setup are:

iptables -t nat -A POSTROUTING -s  -o eth1 -j MASQUERADE
iptables -A FORWARD -d  -i eth0 -j ACCEPT

Since these are annoying to have to type in each time I want to enable access for a host, I wrote a set of scripts. The first two enable and disable access for a host or multiple hosts respectively. The third script is my emergency “oh crap” failsafe, with which a simple command I can disable all isolated hosts’s access immediately followed by bringing down the network server’s interfaces for complete assurance that whatever is going on won’t get out of the virtual network. Here they are:

enableInternet.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

if [[ -z $* ]]; then
        echo
        echo "  Usage: ./enableInternet.sh <ipaddress [ipaddress2...ipaddressN]>"
        echo
        exit 1
fi

for ip in $@; do
        # Will match an address of type 10.10.1.2, which matches our subnet
        # definition
        check=`echo $ip | grep -E "^([[:digit:]]{2}[.]){2}[[:digit:]][.][[:digit:]]+$"`
        # If it doesn't match, print a warning and skip it
        if [ -z $check ]; then
                echo "Improperly formatted address $ip, skipping..."
                continue
        fi

        # Enable Internet access for the address
        iptables -t nat -A POSTROUTING -s $ip -o eth1 -j MASQUERADE
        iptables -A FORWARD -d $ip -i eth0 -j ACCEPT
        echo "$ip's internet access enabled..."

done

echo "Done."

blockInternet.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

if [[ -z $* ]]; then
        echo
        echo "  Usage: ./blockInternet.sh <ipaddress [ipaddress2...ipaddressN]>"
        echo
        exit 1
fi

for ip in $@; do
        # Will match an address of type 10.10.1.2, which matches our subnet definition
        check=`echo $ip | grep -E "^([[:digit:]]{2}[.]){2}[[:digit:]][.][[:digit:]]+$"`
        # If it doesn't match, print a warning and skip it
        if [ -z $check ]; then
                echo "Improperly formatted address $ip, skipping..."
                continue
        fi

        # Disable Internet access for the address
        iptables -t nat -D POSTROUTING -s $ip -o eth1 -j MASQUERADE
        iptables -D FORWARD -d $ip -i eth0 -j ACCEPT
        echo "$ip's internet access disabled..."
done

echo "Done."

blockAll.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

echo "Disabling Internet access for all hosts on 10.10.1.0/255.255.255.0..."

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain
ifdown eth0 eth1

echo "Done."

I alias’d all the commands in my shell’s configuration scripts and prefixed them with sudo so they may be executed quickly and from anywhere on the system. If you’ve read this far, you should too - at least for the blockAll script. You don’t want to be fumbling around trying to remember where you put the script when you need complete isolation 30 seconds ago :)

I know this post was long, but there was a lot to cover. With this setup, hosts can now be easily added thanks to DHCP, Internet access is manually granted and defaults to none, and the environment is completely homogeneous. Perfect for worm development, malware analysis, or what have you. If you replicate this environment, let me know how it works out for you and what improvements you make. I’m always interested in making better systems!

Geek Adventures: Project Management - Implementation

Last time, I talked about the requirements and initial division of an attendance database project for Computer Science House. If you recall, we left off with the project having been split into parts that will eventually be coupled into a complete system - these parts being an iButton interface, iButton back end, user interface, and client back end.

Mark, having been on the last team’s attempt to create this database, was tasked with getting our preliminary idea of what the database should look like up and running. Additionally, since he’ll be working directly with the database, I’ve assigned him the task of creating a PHP interface for interacting with the database. This interface will be called from the user interface as a means of centralizing the database calls for easier updates and maintenance.

Dave offered his help with whatever module needed developing, so he is primarily responsible with developing the user interface. He’ll be using PHP, JavaScript, and CSS as his development tools, utilizing Ajax-ian techniques for creating an interactive interface. This is going to be the most time consuming part of the project, so while Dave is responsible for the primary design and page layout, both Mark and I will be jumping on board to implement specific features when our parts are complete.

As for myself, being the only one with the iButton hardware for now, I am implementing the iButton interface and back end. The technologies I am using are Java, JavaScript, and LiveConnect. Java allows for the development of both the iButton communication application (the iButton interface) and the applet (iButton back end), the first of which was necessary to use the iButton Java SDK, and the second of which allows us to use LiveConnect to make the iButton IDs available to our web user interface invisibly.

The division of the project into smaller parts allows each member of our team to develop in parallel. With an emphasis placed on clean, self-explanatory interfaces existing at the points in which the modules come together, core development should proceed smoothly. As a bonus, each member is granted the freedom to develop in their own style at their own speed, with the only required communication occurring when it is time for members to link up their pieces.

For now, we code. See you when it comes time to integrate!

Geek Adventures: Project Management - Requirements

In my short career as a software developer, I’ve gained experience in multiple programming languages, development styles, and team roles. One role I have yet to play however is project manager. Transforming an idea into an end product using several stages of development with multiple people using many necessarily distinct technologies has always intrigued me (and here is my first public announcement-) an ideal job. Since there is no room for me to gain experience in this arena at my current job, I’ve decided to take on a small project and recruit two others to help me mature the concept and realization of a meeting attendance database for Computer Science House (CSH).

The basic idea of the attendance database falls in CSH’s need to record when members attend committe and general house meetings so we may conduct evaluations of our members. It is a simple idea until the requirements are analyzed. They are as listed:

1. The system must be able to store and retrieve which members were present at a specific meeting.
2. The database will be on a central server, but the client must be multi-platform and portable.
3. The system must be able to able to verify on some level that a member was physically present at a meeting.
4. Corrections to the database shall only be made by the executive board member presiding over the meeting.

And once these basic requirements are met, features will include:

1. The system must be accessible in the absence of an Internet connection.
2. The system will make the job of the executive board members easier by not requiring their involvement in recording a member’s presence at the meeting.
3. The system will include functionality for the evaluations director and chairman to generate reports of meeting attendance for all members to aid in quarterly evaluations.

Once equipped with the requirements and feature requests, I set out to find a couple of intelligent members that could aid in designing and development of the project. They are David Brenner (chairman, spring quarter ‘07) and Mark Schillaci (evaluations director, ‘07-’08). Dave learns as naturally and relentlessly as his heart beats and is capable of grasping abstract concepts easily. This makes him great for picking something up and applying it quickly. Mark is less experienced than Dave or I, but is also sharp. The reason I asked him to be a part of this project has two factors. First, he was on the last attempt to create the attendance database, and second, because he isn’t afraid to dream. This second factor paired with his lack of fear of being wrong yields great ideas that, when grounded and refined, become solid and actionable contributions.

With a team assembled, analysis of the requirements and how to move them into implementable items began. The first step was a separation of the system into components: the database and the client. Following this, an analysis of the components was made in order to fit the requirements. The database being hosted centrally is a given, so it really doesn’t need further discussion. The client requirements state that it must be portable and multi-platform, and obviously must be able to communicate with a database remotely. Additionally, it should be able to verify the physical presence of a member. This one is more interesting.

When developing for multiple platforms, the most efficient way to proceed is to create something that has a single interface for all platforms and a codebase that requires little or no modification to make available to other platforms. This results in creating a single user experience regardless of their operating system, and most importantly as a developer, an easy to maintain system. These objectives are most easily achieved with a web application, where any user with access to a graphical web browser that supports javascript will be able to use our application.

 The issue of verification on the client required more thought, and came to me while I was working on another project. The first method proposed by the developers of a previous attempt at creating the attendance database was to have the executive board member or house secretary log in, then manually type in or check off the names of people who were present. This system is flawed - it relies on the individual entering the information to see each member, which in a crowded room with members sitting behind couches can be unreliable. It also leaves the members not knowing if the person taking attendance noticed them, resulting in their asking “did you get me?” Immediate feedback to the member is necessary to prevent this. My solution to this problem is to use iButtons.

iButtons are a technology that in their most simple form are capable of carrying a guaranteed unique 64 bit ID. We already use them on CSH in our Drink projects Big Drink and Little Drink, as well as in prototype implementations of our iButton doorlocks, so the technology is not foreign to our members as an identifying token. In our case, a USB iButton reader would be connected to the laptop from which the attendance database client was running, and members upon entering the meeting place would click their iButton into the reader which would then record their attendance at the meeting. This solves the requirement of ensuring a member is physically present at the meeting and easily addresses the feature requesting that little involvement from the executive board member be had in recording attendance.

 The final subdivison of the client ends up looking like this with the above taken into consideration: the user interface (graphical interface), client backend (database communications,) iButton interface (physical reader and accompanying software), and iButton backend (local communications with client). In the next part of this series, we’ll discuss the technologies involved, the solutions decided upon, and the initial roadmap of development.