Difference between revisions of "VM Setup Guide"

From ISI Support Wiki
Jump to: navigation, search
m
Line 9: Line 9:
 
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.  
 
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 Instructions ==
+
= Official Rules =
Since this challenge changes from year to year, please make sure to familiarize yourself with the rules and instructions given to you by your instructor.
+
'''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
 +
    * Wireless networking
 +
    * 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 =
 
= Understanding the Playing Field =
Line 21: Line 35:
 
When the challenge begins, your team will be granted [[SSH]] access to a fully updated [https://www.kali.org/ Kali Linux] system with two virtual network interfaces: One on the ISI DMZ and the other 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.
 
When the challenge begins, your team will be granted [[SSH]] access to a fully updated [https://www.kali.org/ Kali Linux] system with two virtual network interfaces: One on the ISI DMZ and the other 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.'''
+
'''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.
 
 
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 ===
 
=== Accessing the Attack System ===
Line 31: Line 43:
 
It is recommended that you become familiar with [[SSH#Port_Forwarding|SSH]] and [https://www.offensive-security.com/metasploit-unleashed/pivoting/ Metasploit] pivoting techniques, as this will make traversal of these VM networks far easier.  
 
It is recommended that you become familiar with [[SSH#Port_Forwarding|SSH]] and [https://www.offensive-security.com/metasploit-unleashed/pivoting/ Metasploit] pivoting techniques, as this will make traversal of these VM networks far easier.  
  
= Planning Your Challenge =
+
== 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 [https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-allow-access Remote Desktop Protocol (RDP)] for Windows and [[SSH|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 [https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-E198C88A-F82C-4FF3-96C9-E3DF0056AD0C.html vSwitch] that will only be made accessible to the [[#The Attack System|Attack System]] (i.e. it will not be connected to the internet). This vSwitch will not contain any network services such as [https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP], [https://en.wikipedia.org/wiki/Domain_Name_System DNS], or [https://en.wikipedia.org/wiki/Routing 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 [https://en.wikipedia.org/wiki/IPv4 IPV4] network space will work. It is recommended, however, to use one of the [https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4 IETF/IANA Reserved Ranges]. On a single vSwitch, most simple configurations will require each of your systems to have a different IP address.
 +
 
 +
The most common IP network used is '''192.168.1.1/24'''.
 +
 
 +
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 [https://en.wikipedia.org/wiki/Subnetwork 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" ([https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing 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.
 +
 
 +
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 [mailto:support@isi.jhu.edu support] to discuss your plan further.
 +
 
 +
==== 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 [https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-540EA00C-92A6-4562-AEE0-AEEDBAA2B02C.html 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 [mailto:support@isi.jhu.edu support] to discuss your plan further.

Revision as of 13:46, 31 December 2018

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
   * Wireless networking
   * 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 on the ISI DMZ and the other 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

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 yourself to gain access to a complete desktop environment.

Pivoting

It is recommended that you become familiar with SSH 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. On a single vSwitch, most simple configurations will require each of your systems to have a different IP address.

The most common IP network used is 192.168.1.1/24.

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.

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.

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.