Skip to main content
All CollectionsManaging ContentManaging Labs
VM & Docker Builds in Labs - Guidelines
VM & Docker Builds in Labs - Guidelines
FifthDomain avatar
Written by FifthDomain
Updated over a week ago

1. How to Build Lab-Based Challenges

For challenges requiring a dedicated Virtual Machines, we use lab-based VMs. Examples include CTF activities like performing Active Directory penetration, Linux Boot2Root challenges, Network Pivoting, and Network Hardening challenges etc. Let's delve into the FifthDomain Lab infrastructure.

Our friendly support team will provide you with login credentials to the platform which are linked to your organisation. From there you can upload your virtual machine images into our platform and they will be available to use in labs and placed in competitions and assessments.

1.1. Lab Prototype Creation and Management

  • The lab you'll be creating is termed a "Lab Prototype."

  • Each lab you create is dedicated to a specific challenge.

  • Never assign the same lab for multiple challenges. Should be one-to-one.

  • In the CTF competition, this lab prototype will be cloned multiple times, providing each user with individual lab instances.

  • Since there's a one-to-one correlation between lab instances and users, any modifications to the Lab prototype should be approached with caution.

1.2. Types of Lab Challenges

1.2.1. VPN Enabled

In VPN-enabled labs, the lab VMs are integrated into the VPN network. This setup is ideal for challenges where direct network access to the VM is required.

1.2.2. VDI Enabled

For VDI-enabled labs, users can access the lab VM through a browser-based VDI interface. However, it's important to note that if VDI is enabled, VPN access to the lab is not possible. In simpler terms, enabling the VDI checkbox disables VPN IP assignment, and vice versa.

For Example:

  • Server-Based Challenges (e.g., NGINX, Apache): For challenges requiring only the server's IP, such as setting up and managing a server, you can disable the "Allow users to connect to this machine via VDI" option.

  • GUI-Intensive Challenges: For challenges where participants need to interact with the VM's GUI, enable the “Allow users to connect to this machine via VDI” option.

1.3. Participant Interaction with the Lab

  • During a CTF challenge, participants receive a VPN file to connect to the lab.

  • This can be done either from their workstation or via a FifthDomain jump box provided in the competition.

1.4. Keeping the Challenge Alive in the VM

  • The challenges must remain operational throughout the event.

  • This requires setting up automatic restarts or implementing cron jobs to ensure the service stays active.

  • If a challenge is designed to be interacted with via VDI, it should also be configured to restart automatically upon each startup, even in the event of a crash.

  • For guidance on setting up cron jobs across various operating systems (Windows, Linux, Docker, etc.), refer to online resources.

Further Guidance: For a step-by-step guide on creating labs at FifthDomain, visit our detailed tutorial: Creating Labs at FifthDomain.

2. VM Configuration and Management

FifthDomain uses a selection of dedicated, customised VMs for creating CTF Challenges:

VM Type

Description

Example Use in CTF Challenges

Kali Linux

Kali Linux Purple

They are primarily used for penetration testing with prebuilt tools. Serves as an attacker (jump) box in competitions, suitable for running Linux-based services.

Ideal for challenges like running network penetration challenges, vulnerability scanning using tools available in Kali Linux, vulnerable applications, etc…

Windows 10

Ideal for tasks involving Windows work, including running Windows-based services. Features 4 GB RAM, 2 CPUs, and a 30 GB SSD.

Useful for challenges that require participants to exploit Windows-specific vulnerabilities or to use Windows-based tools.

Ubuntu - Desktop

Offers a different OS environment, used for running more intensive service-based challenges.

Suitable for challenges like setting up and exploiting services on an Ubuntu system, such as a web server hosting a vulnerable application.

Tailored for hosting Docker files. Features:

  • 2GB RAM

  • 1 CPU

  • 8GB SSD

making it ideal for building container-based challenges.

Perfect for creating container-based challenges where even participants try to break the VM. No problems. Since this is only for one-to-one participants

2.1. VM Configuration and Customisation Guidelines

  • It's important to adhere to the VM configurations pre-set by FifthDomain.

  • If the VM feels slow or a bit laggy, you can increase your RAM.

2.2. Selecting the Right VM for Each Challenge

  • Choosing the appropriate VM is critical for the success of a challenge.

  • Ensure the VM's capabilities align with the challenge's requirements.

  • Do not over-spec or under-spec the VM.

2.3. How to open the VM

  • We use VMWare Workstation Pro to create and package the VMs.

  • Highly suggest you use VMWare Workstation Pro to import the VMs and package the challenges into that VM.

  • You can also use “Oracle VM Virtual Box” to import and make changes. Follow the “How to build and manage VMs” article link given below.

  • However, we highly recommend using VMWare WorkStation Pro.

2.4. Building Challenge on Local Virtual Machines

2.4.1. Creating Custom Virtual Machines Image Constraints

  • Images above 5GB will need to be sent to us for manual upload.

  • Images should be compatible with VMWare ESXI version 6.7, which equates to a VMX Hardware Version 15 or lower. See more VMWARE compatibility information here - VMWARE LINK.

  • Per the above VMs must be VMWARE compatible. If your VM is created in Virtualbox you will need to convert it to be VMWARE compatibility - Guide.

  • The compressed files should be at the root of this tar.gz compressed file. Either in .ova format or the relevant .VMDK disk and .VMX manifest files.

  • The image file should be compressed for upload in only tar.gz format. Please use Linux to compress. If on Windows, use Windows SubSystem for Linux.

  • Please upload the '.tar.gz' file containing:

    • '.ova' file OR

    • '.ovf' file or '.vmx’ file with its supporting files

  • Delete any manifest files ‘.mf’ and all the hidden files.

  • If you use MacOS, delete all the hidden files since MacOS messes up the VM Builder.

2.4.1.1. open-vm-tool

It is preferable to have VMWare Tools installed. Automatic customisation fails if no VM Tools are installed. However, you could manually edit the network settings in test mode if you require custom settings and cannot install VM Tools for some reason.

apt get open-vm-tools

2.4.1.2. OS Level Upwards

Our VM’s run on VMWare ESXI version 6.7 and we provide access to labs via the web browser. There is no access to the OS Level customisation at boot time such as editing the BIOS or the hypervisor level settings.

Example: An Ubuntu 20 VM requires the user to edit the grub boot files and makes the machine un-bootable. This will render the VM broken and you will not be able to recover this VM by accessing the recovery console at boot.

2.4.1.3. Kali Specific

Kali doesn't customise properly because it gets matched to the Debian < 8 deployment package code. To make it match to the >= debian 8 code the /etc/issue file must match the following regex

/Debian.*GNU.*Linux.*\s+(\d{1,2})/i

where d == 8,9,10

example Debian.GNU.Linux.Kali 10 \n \l

2.4.1.4. Networking

  • To automatically set up an internet connection please click the “enable customisation” option. For some OS’s this may fail see VMWARE.

  • If you do not click the “enable customisation” option because the lab has complex specific networking or it fails you will need to add custom IP settings as below on the primary interface for it to connect to the internet:

    • Right-click on the internet area at the top of the screen and click “Edit Connections” then enter these details in the IPV4 section:

      • Your IP: 172.16.201.2 (only available on one VM per lab)

      • Gateway: 172.16.201.1

      • DNS: 8.8.8.8,9.9.9.9

2.4.2. Building challenges in the Platform:

  • Once the lab is ready, you can enter the test mode and start to create lab challenges.

  • For copying files, you can use any file transfer service to upload your contents. But make sure you enable the Internet to the network while creating the network for the lab.

  • For more information on this look into “Creating Labs at FifthDomain.”

    • Pros: The chances are less that the lab failed on the building.

    • Cons: Uploading the files CTF Assets into the VM is a bit tricky but if you enable the VM using Online File transfer would be the simplest way.

2.4.3. Building challenges locally & then uploading them to the platform:

  • Once you download the VM files on your local machine, you can start editing them on your VMware Workstation Pro.

  • After attaching the CTF challenge, you can export the VM compress as “challenge-name.tar.gz” and upload it to the platform.

  • Please use Linux to compress. If on Windows, use Windows Sub System for Linux.

  • Delete any manifest files ‘.mf’ and all the hidden files.

  • If you use MacOS, delete all the hidden files since MacOS messes up the VM Builder.

  • Finally, you can add them to the lab.

    • Pros: You can upload the files, and test the VM and QA challenge locally with less effort.

    • Cons: Chances of breaking the files which lead to failure in uploading VMs into the platform.

You can choose any method but make sure you are following what the instruction guide tells you. There are more chances to make the VMs corrupt if you build the challenge locally. Also please make sure to use Linux to compress using tar and gunzip. And there should not be any hidden files in the compressed tar.gz file.

3. Testing Lab

3.1. Testing the VM Locally

3.1.1. Post-Challenge Attachment Testing:

  • After integrating the challenge into the VM, test it using your attacker VM. Ensure both are on the same network for accurate testing.

  • Once the Quality Assurance (QA) test is successfully passed, the VM can then be uploaded onto the platform, attached to the lab and assigned to a challenge.

3.2. Testing on the Platform

3.2.1. Lab and Challenge Integration:

  • After building the lab and assigning it to the respective challenge, you can initiate a test by entering the edit mode of the challenge, where the 'Test Lab' button should appear.

  • Then, the lab can be tested at the challenge level without tampering with the parent prototype.

3.3. Support for Content Creators

  • FifthDomain highly encourages Content Creators to thoroughly build and test their challenges.

  • If any issues arise during the challenge-building process, FifthDomain is ready to provide support.

4. How to Build Docker (Container) Based Challenges

The process of creating Docker-on-VM is very similar to how you create a Lab. All you need to do is load the challenge Image/Repository and run the docker in the lab.

  • The only constraint is you are allowed only to use “Container VM (Ubuntu Minimum)” to build the container-based challenges.

  • Although you can create challenges on any VMs, the main reason is to reduce costs on VMs and that’s what FifthDomain highly recommended you do.

VM Type

Description

Example Use in CTF Challenges

Container VM (Ubuntu Minimum)

Tailored for hosting Docker files. Features:

  • 2GB RAM

  • 1 CPU

  • 8GB SSD

making it ideal for building container-based challenges.

Perfect for creating container-based challenges where even participants try to break the VM. No problems. Since this is only for one-to-one participants.

4.1. VM Configuration and Customisation Guidelines for Docker

  • It's important to adhere to the VM configurations pre-set by FifthDomain.

  • If the VM you feel slow or a bit laggy, needs extra space, or CPU or RAM, feel free to increase it. Ensure you communicate this to the FifthDomain support team.

4.2. Note on Building Containers on VM

  • This container-based challenge should always be as a VPN Enabled.

  • In the Container VM (Ubuntu Minimum) you can find the Docker Container template. You can use that as a template.

  • After the challenge is built and successfully QA passed on your side, save the container image as challenge-name.tar.gz with this command

docker save CHALLENGE-NAME > CHALLENGE-NAME.tar

  • Requires files to be uploaded on the Virtual machine are:

    • Container Image (challenge.tar)

    • Docker Compose (docker-compose.yml)

  • After uploading those 2 files into the VM, you can run the docker-compose on detached

docker compose up --detach

  • Container should not exceed the size of more than 5 GB.

  • Do not upload the challenge assets into the Virtual Machine. Upload only docker files. We never want participants to get access to the source code of the challenge.

  • Cannot include a docker that runs in privileged mode, But the challenge required- https://learn.snyk.io/lessons/container-runs-in-privileged-mode/kubernetes/

  • Never forget to add “restart policy” and “Health Checks” to the docker-compose file.

Example Docker-compose file:

version: '3.8'

services:

<CHALLENGE_NAME>:

build: . # Build the container file which is on CHALLENGE-NAME.tar

image: <CHALLENGE-IMAGE-NAME>:latest # Container image name

ports:

- "<PORT-NUMBER>:<PORT-NUMBER>"

restart: unless-stopped # Policy keeps Docker running all time but won't restart when docker stopped manually.

healthcheck: # Regularly checks if the application is running correctly.

test: ["CMD", "curl", "-f", "http://localhost"] # depends on the challenge of how you build.

interval: 1m30s

timeout: 10s

retries: 3

start_period: 40s

logging: # Prevents log files from growing indefinitely, which could eventually consume all available disk space.

options:

max-size: "10m"

max-file: "3"

Did this answer your question?