VM Setup Guide

Example CTF Configuration

This VM Setup Guide is designed to help students taking the EN.650.631 Ethical Hacking course plan their virtual machine configurations for the Capture the Flag (CTF) challenge.

This guide will not show you how to configure, test, or choose vulnerabilities for this project. You will need to do this using what you've learned during the course.

About the Challenge

At the end of this course, students will create a system of networked virtual machines configured with intentional vulnerabilities for challengers to uncover and exploit in a controlled environment. Each successful attack should uncover clues or unlock new attack vectors to allow further exploitation through the system towards a pre-determined goal.

Official Rules

Official Rules as of 2018-12-27:

   Must use:
   * At most 4 servers
   * More than one operating system type
   * Vulnerabilities (software/hardware) not discussed in class
   * At least 2 advanced topics (script writing)
   * Shell coding
   * Reverse engineering
   * Cryptology
   * At least 10 flags
   * Unique identifiers for flags
   * A storyline that is at least 4-6 hours long
   * Flags should build on each other like a story

Understanding the Playing Field

In order to effectively configure your challenge, you should be well aware of how your systems will be hosted and made accessible on the network. Failure to do so may result in your challenge being unintentionally simplified or, worse yet, impossible to complete.

The VM Host

All virtual machines provided by students will be hosted on a VMWare vSphere cluster (ESXi version 6.5 U2) hosted internally by the Information Security Institute. When creating your VMs, please ensure that they are compatible with this system. The best way to do this is to create your VMs using VMWare Workstation or VMWare Fusion. VMWare Workstation is installed on all MSSI General-Use Workstations, but students may download VMWare software for use on their own devices using the department VMAP subscription.

The Attack System

When the challenge begins, your team will be granted SSH access to a fully updated Kali Linux system with two virtual network interfaces: One (eth0) on the ISI DMZ and the other (eth1) on the virtual network of the system (or systems) you will be attacking. You will have root on this system, so you are free to configure it however you choose.

Once you gain access to the attack system, change the password immediately. You do not want other teams gaining access to your system as this may grant them an unfair advantage while solving challenges.

Accessing the Attack System

Each team will be assigned an attack system that is available on any JHU network. The hostnames, usernames, and passwords will be given to you before the competition to allow you a little bit of time to set it up. By default, the only way to access Kali is via SSH. If you need to use GUI applications on this system, you can use X11 Forwarding. If this is still not adequate for your needs, you are welcome to install and configure something like VNC to gain access to a complete desktop environment.

Changing the IP Address of the Target Interface

Kali Linux, by default, uses NetworkManager for network management and configuration. You have two options to modify the network configs: the GUI management system or the CLI.

Config via GUI

When you connect via SSH, ensure you've enabled X Forwarding. Run the following command:

student@TEAMX-ATTACK:~$ nm-connection-editor

This should allow you to easily modify the Target network.

Config via CLI

Managing NetworkManager via the CLI can be done via the nmcli command. To show the available interfaces:

student@TEAMX-ATTACK:~$ nmcli c show
NAME    UUID                                  TYPE      DEVICE
DMZ     xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  ethernet  eth0
Target  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  ethernet  eth1

To change the IP address of the Target interface to 10.200.0.20 with a netmask of 255.255.255.0 and no gateway:

student@TEAMX-ATTACK:~$ sudo nmcli con down Target
Connection 'Target' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
student@TEAMX-ATTACK:~$ sudo nmcli c mod Target ipv4.method manual ipv4.addr "10.200.0.20/24"
student@TEAMX-ATTACK:~$ sudo nmcli con up Target
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

To change the IP address of the Target interface to 10.200.0.20 with a netmask of 255.255.255.128 and a gateway of 10.200.0.1:

student@TEAMX-ATTACK:~$ sudo nmcli con down Target
Connection 'Target' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
student@TEAMX-ATTACK:~$ sudo nmcli c mod Target ipv4.method manual ipv4.addr "10.200.0.20/25 10.200.0.1"
student@TEAMX-ATTACK:~$ sudo nmcli con up Target
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

Pivoting

It is recommended that you become familiar with SSH Port Forwarding and Metasploit pivoting techniques, as this will make traversal of these VM networks far easier.

VM Access

Since the VMs will be hosted on a shared server for teams to attack, players will not have console access to these systems. Any access given to these systems will need to be network based, either directly via a network access server or indirectly via an exploit.

The most common network access servers are Remote Desktop Protocol (RDP) for Windows and Secure Shell (SSH) for linux. These tools are typically not enabled by default, so you will need to configure them yourselves. If you plan on using these services, ensure that they are configured to start automatically at boot.

While RDP and SSH are the most common, they are by no means required. How users traverse your challenge is completely up to you.

Virtual Networks

By default, your VMs will be on a single vSwitch that will only be made accessible to the Attack System (i.e. it will not be connected to the internet). This vSwitch will not contain any network services such as DHCP, DNS, or Routing, so unless you decide to configure one or more of your virtual machines to handle these services, all your VMs will need statically assigned IP addresses to be able to communicate with each other.

Configuring Static IP Addresses

How static addresses are configured will depend from system to system, but there are common configuration options that will almost always be available:

IP Address

If your network is not internet routable, any IPV4 network space will work. It is recommended, however, to use one of the IETF/IANA Reserved Ranges. The most common IP network used is 192.168.1.1/24.

On a single vSwitch, most simple configurations will require each of your systems to have a different IP address.

Please keep in mind that the Attacker VM will need an IP address assigned to it as well in order to connect to your networks. If you choose to use static addressing without having your own DHCP server, you will need to provide an IP address for the Attacker to use.

Netmask

A Network Mask (sometimes called a Subnet Mask) defines IP subnetworks or "subnets". In very basic terms, this defines how large a network space is.

In most typical installations, a subnet mask of 255.255.255.0 (CIDR /24) is used. In the IP example above, the /24 means that the network is confined within 24 bits. Without going too deep into IP addressing fundamentals, this results in an address range of 192.168.1.1 to 192.168.1.255, meaning your VMs can be anywhere within that range.

Online Tools also exist for easily calculating subnets.

Again, please keep in mind that the attacker may be needed to connect to your network as well, so be sure to have a subnet defined that is large enough to support your attacker.

Router / Gateway

Unless you decide to use one of your VMs as a virtual router or gateway, no router or gateway needs to be defined. In most typical network configurations, you can safely leave this option blank.

Custom Network Configurations

When designing your challenge, there are plenty of options available for configuring your network outside of the static, single-switch configuration. You may request additional vSwitches, configure your own virtual routers or firewalls, etc. Please keep in mind that your network configurations should work with minimal configuration and should be ready to go "out of the box."

If you would like to use an alternate network configuration, please contact support to discuss your plan further.

Example Network Configuration

The image at the top of this page demonstrates a very basic network configuration involving two vSwitches: one (VM Network 1) simulating a DMZ and the other (VM Network 2) an internal corporate network.

The Web Server and Database server are hosted on the DMZ, but the web server has a second network interface allowing it to talk to the corporate file server on the internal network. It is assumed that the attacker would use this second interface to pivot to the Employee Workstation.

For a static configuration, these systems could be set up as follows:

System	Interface	Network	Type	IP	Netmask
Student Laptop	WiFi	JHU	DHCP	Assigned via DHCP	Assigned via DHCP
Attack System	eth0	JHU	DHCP	Assigned via DHCP	Assigned via DHCP
	eth1	VM Network 1	Static	192.168.1.100	255.255.255.0
Web Server	eth0	VM Network 1	Static	192.168.1.10	255.255.255.0
	eth1	VM Network 2	Static	10.1.1.10	255.255.255.0
Database Server	eth0	VM Network 1	Static	192.168.1.20	255.255.255.0
Corporate File Server	Ethernet 1	VM Network 2	Static	10.1.1.20	255.255.255.0
Employee Workstation	Ethernet 1	VM Network 2	Static	10.1.1.42	255.255.255.0

Hardware Interfaces

In some cases, you may wish to have some sort of interaction with physical hardware such as a WiFi Network Interface Card (NIC) or a thumb drive. This is possible via VMWare's USB Arbitration Service. Please keep in mind that if you choose to require a physical component to your CTF, you will need to have at least 2 exact copies of that hardware configured since your challenge will be duplicated for multiple teams to access at once.

If you would like to use a physical component in your CTF, please contact support to discuss your plan further.

Virtual Machine Setup Recommendations

While every VM created for this project will be different, there are a few general considerations that should be minded to ensure your VMs are as efficient as possible within the constraints of the project. While these recommendations are not required, they will help you better manage your VMs to prepare them for distribution.

Choosing an Operating System

DO NOT CREATE A VIRTUAL MACHINE UNTIL YOU KNOW WHAT YOU'RE GOING TO DO WITH IT.

The most common operating systems used for this project are Windows and Linux. There are countless versions of each of these, and choosing the right one will be extremely important to your project's success. The wrong OS version could make your planned vulnerability useless, or make your system easier to own than you planned.

Windows

The most recent version of Microsoft's Windows operating system is Windows 10 , but did you know that there are 12 different editions, all with their own unique feature sets?

When choosing a Windows operating system for one of your VMs, make sure you're aware of what specific versions and editions are capable of demonstrating the attack you plan on having your challengers implement. A vulnerability in Windows Vista may not affect a Windows 7 machine or a service in Windows 10 Enterprise might not be available in Windows 10 Home.

We can acquire any version and/or edition of Windows you need, so if a license or ISO download for the version you wish to use is not already available to you on the Shared Drive, please contact support Make sure you do your research before starting the build process, since acquiring licensing for some versions of Windows may take more time than others and you don't want to waste that time with an operating system you can't use.

Linux

Since most Linux vulnerabilities are in particular kernels, libraries, or software packages, the distribution you choose typically won't matter. Try to locate a "minimal" or "server" edition of the operating system to reduce software bloat and make the system hardening process easier.

Ubuntu, for example, has a minimal, CLI-only Server Edition that lacks common Desktop applications your challengers won't be using anyway... unless you need them to, in which case you might consider using the Ubuntu Desktop Minimal Installer and using the Xubuntu option to have a more lightweight GUI.

Minimum System Requirements

Once you have your OS picked out, you can start creating your VM. You'll want to use the least amount of resources possible to run your operating system and any software packages involved, and a good place to start is to locate the minimum system requirements.

Let's use Windows 10 as an example.

According to Microsoft's help site, Windows 10 requires the following hardware specifications to run effectively:

• Processor: 1 gigahertz (GHz) or faster processor or System on a Chip (SoC)
• RAM: 1 gigabyte (GB) for 32-bit or 2 GB for 64-bit
• Hard drive space: 16 GB for 32-bit OS or 32 GB for 64-bit OS

If I plan to do a 64-Bit installation of Windows 10 for my virtual machine, I can configure it with a single processor, 2GB of RAM, and 32GB of hard drive space to run the base operating system.

Now... Lets say I also need Microsoft Office 2019 as part of this project. The requirements from Microsoft's help site state:

• Computer and processor: 1.6 gigahertz (GHz) or faster, 2-core
• Memory: 4 GB RAM; 2 GB RAM (32-bit)
• Hard disk: 4.0 GB of available disk space

So in order to run Office effectively on top of the base operating system, we would need an additional core for the processor, 4GB of memory, and 4GB of hard drive space...

So the minimal requirements for this system would be:

• Processor: 2-Cores
• Memory: 6GB
• Disk: 36GB