We are building a cyber testing ground for hacker tests

[CarderPlanet]

This article was written for educational purposes only. We do not call anyone to anything, only for information purposes! The author is not responsible for your actions.

When testing security tools, as well as training personnel in attack scenarios and protecting network infrastructure, virtualization tools are indispensable. The wheel is often reinvented for this, constructing an eerie jumble of virtual machines and all kinds of software. We will take a different path: we will set up an emulation platform based on EVE-NG and create on its basis a universal scalable cyber polygon that allows networkers and security personnel to hone their skills.

The idea to try a modern emulation platform came about when I was overseeing a team of cybersecurity engineers. They often research, deploy, integrate, and test different products. There are a huge number of vendors and solutions, but a significant part of them revolve around protecting the same key systems, some standard corporate infrastructure: workstations, AD servers, file shares, mail servers, web servers, database servers. Also, in any infrastructure there is a certain standard hierarchy of user groups, network segmentation, a set of software and network equipment in the form of switches, routers, firewalls.

Integration tasks, as a rule, are also typical: set up authorization via AD / Radius, make friends with mail, roll out agents, assemble a cluster, submit mirrored traffic, send logs or flows to analysts. Practice shows that without a standardized approach, each engineer will eventually build up a similar infrastructure for himself, and each with his own blackjack. The result is a whole zoo of differently configured virtual machines, on which it is not clear what is spinning. Another team member, most likely, will not be able to simply take and quickly use such VMs.

In addition to the "personal" VMs scattered on different ESXi hosts, segmented networks are required to test firewalls, run malware and other tasks, so port groups are sometimes also found in such an infrastructure. They are necessary only for the laboratory, but in fact they go to the Internet through the production infrastructure. After the dismissal of an engineer, such virtual machines are simply killed along with all the "accumulated experience". In short, this approach seemed to me not at all effective, especially since it does not use some of the features and flexibility of VMware. I decided to standardize the process, and at the same time test the emulation platform.

SELECTING A PLATFORM​

For our needs, the EVE-NG Community Edition platform was chosen - this is a fork of the well-known UNetLab, which is no longer supported. Networkers are very fond of this solution, and there really is a reason. Just look at examples of network topologies with clusters and BGP!

BGP topology

However, it was created not only for networkers: the possibilities of its use are almost endless, they depend solely on imagination and available knowledge. To work, we needed a web interface, and competitors had it at the time of selection only in GNS3, and even then in beta. All fichah EVE-NG, including the Professional and Learning Center, which have Docker and support clustering, you can read on the official sai-te, I will talk about the key features.

• QEMU / KVM. In this bundle, QEMU acts as an iron emulator, it is flexible enough and can run code written for one processor architecture on another (ARM on x86 or PPC on ARM). KVM, in turn, allows for high performance through hardware-assisted virtualization such as Intel VT-x and AMD-V.
• IOU / IOL and Dynamips. Support for old, but quite working Cisco switches and routers.
• Optimization of UKSM memory in the kernel. With the simultaneous use of monotonous VMs, it allows deduplication of memory and thereby significantly reduce RAM consumption.
• Full HTML5 web interface.
• Multi-user mode for the simultaneous operation of various virtual laboratories.
• Interaction with the "real" network.

INSTALLATION​

We deployed Eve on bare metal. For this type of installation, the following system requirements are imposed: CPU - Intel Xeon CPU supporting Intel® VT-x with Extended Page Tables (EPT), OS - Ubuntu Server 16.04.4 LTS x64.

Everything else depends on the expected load: here the more, the better, especially for RAM. If you are confused by the old version of the OS, then don't worry, it will be supported until 2024. Note that the Community version is not updated as often as the Professional version, which requires 18.04 LTS to be installed on hardware. If you are all like that in the clouds, then keep in mind that EVE-NG officially supports GCP.

INFO​

Do you know that in GCP (Azure, Yandex), a new user can get a $ 300-Lares in the form of free credits to test the services, for example to run a VM? And what, besides that, does GCP have preemptive VMs? These are virtual machines that cost 3-4 times cheaper than usual ones, but live a maximum of 24 hours or less: if the cloud needs the resources that this VM occupies, it will crash it.

Unfortunately, Google's policy has changed and free credits cannot be spent on preempted VMs, but if you ever need 128 RAM in the cloud and cheaply, you know what to do! ?

We will now consider the option of a quick acquaintance with the platform by deploying it on a laptop with VMware Workstation. Supported only by VMware, including Player and ESXi. But in any case, it should be understood that nested virtualization (this is when a virtual machine works inside another virtual machine) can have a bad effect on performance. Also, your CPU must support hardware virtualization technologies such as Intel VT-x and AMD-V. Remember to check if they are enabled in the BIOS.

It is interesting that AMD support in the Community version is not officially reported, but in the documentation for Professional, manufacturers have already written that they support the latest processor versions. However, I deployed the Community version on an AMD Ryzen 5 4600H processor without any problems.

If you are using Windows as your host OS, there are a few things to keep in mind about the role of Hyper-V, in particular in Windows 10. Here is what the Microsoft website says about it:

We introduced a number of features that utilize the Windows Hypervisior. These include security enhancements like Windows Defender Credential Guard, Windows Defender Application Guard, and Virtualization Based Security as well as developer features like Windows Containers and WSL 2.

In addition to the OS itself and its features, Docker Desktop can also use this service. Because of this, up to and including version 15.5, VMware Workstation (like VirtualBox) did not work at all on a host with the Hyper-V role enabled. The collaboration between Microsoft and VMware nevertheless made it possible to integrate Workstation with WHP through the API, thanks to which a working solution appeared. But, unfortunately, in addition to being such a bunch slowly began to work, there is the main ogre-Nitsche-set, namely - Intel functions VT-x / AMD-V is not available for guest VMs. The Hyper-V service uses VT-x exclusively, restricting access to other hypervisors.

Therefore, if the Hyper-V role is enabled on your host, analyze what it is used for and disable it if possible. If this is not possible, use a different PC, server or cloud.

I recommend downloading the EVE-NG recipe book in PDF format right away. It provides comprehensive guidance for the entire project, from A to Z.

So, for quick deployment, we will download the ZIP archive with the OVF image, unpack the archive and double click on it to EVE-COMM-VM.ovf import it into Workstation.

OVF import

Let's open the properties, add memory and processors if necessary. Make sure you have a check mark Virtualize Intel VT-x/EPT or AMD-V/RVI in the settings group Virtualization engine. Without it, EVE-NG will boot itself, you can open and create laboratories, but VMs inside the laboratory will not start.

VM properties

For clarity, we will select the mode Bridgedfor the network adapter, thereby our VMs inside the laboratory will be available directly on the local network.

WORKING WITH THE PLATFORM​

Launch EVE-VM in Workstation. After a successful download, you will receive a password prompt.

Password prompt

Log in using the standard root/eve console account.

Next, we answer standard questions about setting up the OS, such as:

• New root password;
• Hostname;
• DNS domain name;
• DHCP / Static IP address;
• NTP Server;
• Proxy Server configuration.

After answering the last question, the system will automatically reboot. Upon completion of the reboot, open the web interface using the IP address specified in the VM console and log in using the account admin/eve.

Management consoles

For the most part, all work with the platform is done through the web interface. You have to connect to Eve via SSH only occasionally, for example, to prepare images. There are two options for connecting to a VM monitor: through native applications or the HTML5 console. If you select a native console, the remote access applications and Wireshark must be installed on the PC from which the web interface is open. The set of software differs depending on the OS, and some tuning of the registry is also required, so it is recommended to use the Windows / Linux / Apple Client Side Integration Pack, which contains everything you need, including scripts for configuration.

When using the HTML5 console, all control is carried out entirely through the browser. The console runs on Apache Guacamole, as in many modern vendor labs.

After logging in, we find ourselves in a certain file manager, where laboratory files are stored. First, I will show you a ready-made corporate laboratory, and then we will create our own for example. I will only note that for a better visual display, many of the connections in this diagram have been changed or completely removed.

Open laboratory

At its core, a laboratory file is a config in XML format that describes the configuration of nodes, their location on the field, connections, etc. Nodes are VM objects that can be IOL / Dynamips / QEMU images. Labs can be cloned, exported and imported directly from the web interface.

Laboratory config

Opening the lab displays a topology view that is somewhat similar to Visio. On this topology, nodes are added and connected to each other. On the left in the menu is everything you need to work, you can start all the nodes at once, or you can selectively.

Topology view

Unlike Visio, clicking the icon opens a remote connection to the node.

Windows 10 monitor

Kali Linux Monitor

Each node has its own standard VM settings, such as the image from which the boot is performed, the number of CPU, RAM, Ethernet ports, arguments for the hypervisor, and more.

Node settings

Node settings, continued

NETWORKS​

There are two main types of networks in EVE: the bridge and the control interface. Basically you will have to click on the nodes and select the source and destination ports. This is one of the reasons why networkers like Eve so much: in ESXi, for example, for "clean" point-to-point connections, you need to create a separate vSwitch and port-group, which takes a lot of time and effort ...

Connecting nodes

A bridged network acts like an unmanaged switch. It supports the transmission of tagged packets dot1q. This may be necessary when we need to connect many nodes in a flat (dot1q) network without using a network device image. The result is a completely isolated virtual network.

Bridge Mode Network
The second version of the network is called the "control network" with names Cloud0/Pnet0. This interface is configured in bridged mode with the server's first network adapter. Thanks to this, you can make the nodes available directly over the network, they will be on the same network segment as the management interface, and can interact with other external networks.

Control network

The rest of the interfaces Cloud* can be connected to a second or higher Ethernet port to connect to another network or to a device. They do not need to be configured with an IP address. They will act as a clean bridge between your external connection and the lab node.

IMAGES​

Eva is shipped without images, there is only a Virtual PC on board with basic network functionality.

Virtual pc

The list of supported images on the sci-those are not always relevant, this directly stated in the documentation. Due to licensing restrictions, the authors of the project cannot post direct links to images on their website, but in practice, any image can be found on torrents. And if you work in an integrator, then this is not a problem at all.

Dynamips / IOL images​

With images of network devices Dynamips / IOL do not need to do little more than determine the value IDLE PC and create Liezen Zee file. Unfortunately, not all of the functions of these network devices under-hold-vayut Xia. Their configs are stored in a separate place, in the menu startup-configs and in NVRAM, and not in the image file itself. NVRAM is used as writeable persistent storage for initial configuration. During the boot process, the node will always check the NVRAM for a saved configuration.

Boot configs

The loading process for such images is shown in the following diagram and is generally understood without further explanation.

Config loading order

QEMU / KVM images​

All other systems will run as QEMU images. The peculiarity of these images in Eve is that first a base image is created, and when the VM starts and runs, all changes are written to a separate file. This can be regarded as a kind of snapshots tied to individual users.

Such a mechanism is very convenient for group training, when several engineers are doing one laboratory work in parallel: changing the settings in the image for one user does not affect the others in any way. If the image has become inoperative due to incorrect settings and there is no time to find the problem, you can click the Wipe (Wipe all nodes) button, and the image in the laboratory for a particular user will return to the basic state.

Among other things, this scheme also solves the licensing problem - only one license is needed. The parameters to which licenses are bound do not change, as happens, for example, when cloning in ESXi.

Large vendors usually provide several options for their VM images: VMware, KVM, Hyper-V. But if there is no ready-made image, you can create or convert it from the existing one.

Image conversion​

To convert an image, you must use the console utility qemu-imgalready installed in Eve. Just keep in mind that qemu-img and /opt/qemu/bin/qemu-img are different versions, so use the full path as indicated in the documentation.

For example, this command converts a VMware image to a QEMU image:

$ /opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2

For the rest of the formats and arguments for conversion, see the table:

QCOW2 (KVM, Xen)
qcow2

QED (KVM)
qed

raw
raw

VDI (VirtualBox)
vdi

VHD (Hyper-V)
vpc

VMDK (VMware)
vmdk

Creating your own image​

When creating your image should be guided by the rules of naming folders and images of dis-ka, because the system is sensitive to them.

The root directory for images is /opt/unetlab/addons/qemu/. As an example, consider creating your image based on the Kali Linux distribution. To do this, download the installation imagekali-linux-2021.2-installer-netinst-amd64.iso.

1. Create a directory on Eva's server:
   

   $ mkdir /opt/unetlab/addons/qemu/linux-kali/

2. Transfer the installation image kali-linux-2021.2-installer-netinst-amd64.iso to the Eva server in a folder /opt/unetlab/addons/qemu/linux-kali/.
3. Rename the installation image to cdrom.iso:
   

   $ mv kali-linux-2021.2-installer-netinst-amd64.iso cdrom.iso

4. From the same folder, create a new HDD disk file. In the example, the size is 30 GB - you can specify any:
   

   $ /opt/qemu/bin/qemu-img create -f qcow2 virtioa.qcow2 30G

5. Create or open a laboratory via the web interface, add a new node by connecting it to the network, if you need the Internet for installation.
6. Launch the node, open it and continue the installation process as usual.
7. After the installation is complete, reboot and shutdown the node from the inside using standard OS tools, and then delete the file cdrom.iso.

If you look at the file size /opt/unetlab/addons/qemu/linux-kali/virtioa.qcow2, you will see that it has not changed and remains empty.

Base image size

This happened because all changes during the operation of the node are written to a separate file along the path /opt/unetlab/tmp/PodID/UUID/NodeID. If you made changes inside the node, installed software or uploaded files and want to make these changes to the base image, then you can do this in the way described below.

Making changes to the base image​

Turn off the node from the inside using standard OS tools, right-click on the node in the Eve web interface. You will see a number in parentheses. This is the Node ID, write it down - in our example it is 2.

Node ID

On the left in the menu, open the item Lab Detailsand write down the ID, in this example - 6393e2df-501f-405c-b602-2e9a080f72f1.

Laboratory ID

1. Close the lab and go to Management/User Management. Find your user and write down their POD value. The admin has a default value of 0.
2. Follow the path /opt/unetlab/tmp/PodID/UUID/NodeIDby substituting your values:
   

   $ cd /opt/unetlab/tmp/0/6393e2df-501f-405c-b602-2e9a080f72f1/2/

3. As you can see, the file with changes in this folder is 3.1 GB.

Temporary image size

Run the command specifying the name of the disk file:

$ /opt/qemu/bin/qemu-img commit virtioa.qcow2

If everything went well, you will receive a message Image comitted. By checking the files, you can make sure that the changes from the temporary folder have moved to the base image.

The image has moved

Now, when the linux-kali node is turned on, any of the users will load the base disk image file. This was an instruction from the official documentation, but in practice its use caused problems, which I will describe below.

Windows port scan with Kali

The port is open and detailed host information is available. We will not check the network connectivity with VPC2 and VPC3, we only need them for extras to show how you can achieve building an L2 network (in which there are more than two nodes) using an object network and emulation of network equipment.