The story of how my dream led to the rise of a cyber range within the walls of my university. Part 1

Introduction

Hello again everyone!

This article will tell how my dream at a university lecture accidentally led to a series of events where I became the technical organizer of two cyber testing sites within the walls of my university. This part will only affect first CTF, which was conducted only among students of our university. In the second part there will be a story about raising a larger republican training ground among teams from universities and companies, in which 3 more network engineers joined me.

PS This article is not a guide to raising cyber polygons, but more of a personal experience in which many crutches were used due to short deadlines.

Table of contents

• Background

• First look at the readiness of the landfill itself

• Dreams of cooperation with network engineers from the university IT department that did not come true

• Construction of the final infrastructure topology

• Several painful weeks of reading OpenVPN documentation before this

  • Setting up OpenVPN server (Main VPN Server)

  • Setting up OpenVPN client-servers (Virtual machine in DMZ)

  • The magic command that you should not forget on Linux servers if you have UFW

  • Setting up OpenVPN clients (Polygon participants)

• Connecting the long-dead Debian 8 to OpenVPN

• Conducting a cyber training ground

• Conclusion

Background

Let's start the background with the fact that I am a graduate student at Astana IT University, Faculty of Cyber ​​Security. At that time, I found a job as a system administrator of server infrastructure in a local information security company, which I combined with my studies. Due to the greater workload, I was quite tired, so I simply fell asleep during lectures at the university.

However, on January 23, 2024, the very event occurred that deprived me of the rest of my sleep…

That day, when I was sleeping, my friend from a parallel group was sitting behind me, who for some reason was swearing at VMWare ESXi, in which I could not pick up and raise a virtual machine. This noise disturbed my sleep, so I just picked up the virtual machine he needed.

After that, of course, I was going to go back to bed, but a rather interesting dialogue suddenly began. It turned out that he was trying to raise virtual machines for the future cyber range from the military department of our university.

I listened to him and was about to go back to sleep. However, as it turned out, not everything was so smooth for him, since the organizing team did not have a single specialist who was involved in raising the infrastructure.

The event itself was held to show that quite strong information security specialists are studying at our universities who can develop information security in the country, and all further developments on the site will be transferred to the next students, so that they do not have to raise the site and search for information from scratch, like we did it.

The purpose of this event and my personal attitude towards this person made me suddenly wake up and want to help him, although of course I will not receive any material benefits from this, but should everything be done purely for the sake of money?

This is where my story about the rise of this training ground begins…

First look at the readiness of the landfill itself

After that dialogue, they added me to the Telegram chat and showed me the initial scheme for constructing the entire cyber range:

Logically, the scheme was, of course, quite good, but there were a couple of places that I changed (Later in CTF 2, everything was done much better):

• Refused the decision to give participants 15 ready-made Kali machines, since server resources were terribly limited

• I refused to upgrade monitoring because the remaining time and work commitments did not allow me to upgrade Zabbix and Wazuh

• I refused to use PfSense because, again, I didn’t have enough time and experience to fully configure it.

• Placed OpenVPN and Landing on the same web server, since it was refused to provide an additional external IP address

Here is one of the old sketches I did during the first weeks. Later I had to throw them out, because I did not have any information about how the university network works and how everything can be done accurately.

This old sketch still contains those 15 Kali Linux machines that were later abandoned. Also Landing and OpenVPN, which were originally planned on different servers.

Dreams of cooperation with network engineers from the university IT department that did not come true

Now, of course, after a bunch of crooked sketches, I needed to consult with the IT department of the university, since I was on a completely foreign corporate network, where I didn’t even know how anything was configured.

Unfortunately, based on the title, you can tell that this did not end well. First, the network topology of the university, or at least the part in which I am located, was requested. The response was that they did not have such a card. After that, they asked for at least a network engineer who would understand how everything is configured and would set up the university’s Fortinet Firewall for me the way I needed it. And of course, I was again refused again and told that I would have to build the entire site only in VLAN 14, and no one would give me a specialist to help me. In addition, as I wrote above, it was refused to give another external IP address in order to place Landing for registration and OpenVPN on different servers, which again affected the construction of the entire cyber range 1000 times.

After extinguishing my 5th point from the information received, I began to build the infrastructure itself…

Building a rough plan for raising infrastructure

If we go a little into the future, then after more debate and discussion, a clear topology of the entire polygon was built, which you can see below:

According to the plan, 5 subnets were created on VMWare ESXI:

1. The Network subnet had access to the Internet and there was a machine on it with an external IP address on which the OpenVPN Server was located, which provided access to internal subnets for test site participants.

2. The DMZ subnet did not have access to the Internet, so access to it could only be obtained through a machine with OpenVPN Server, which had a separate network interface in the DMZ subnet. All machines located in the DMZ were connected using the OpenVPN client configuration files to the OpenVPN Server, in which they were all given reserved IP addresses inside the tunnels.

3. The remaining subnets each contained 1 business risk, which could only be accessed by escalating privileges on certain machines located in the DMZ, which also had separate network interfaces for accessing the business risk subnets.

As you can see, there are subnets here (192.168.1.*, 192.168.2.*, 192.168.3.*, 192.168.4.*) that are not included in the 14th subnet, but for some reason they work. In this case, it worked because I didn't have access to other physical VLANs and I created completely virtual VLANs that only worked inside ESXi.

Several painful weeks of reading OpenVPN documentation before this

Setting up OpenVPN server (Main VPN Server)

First, I needed to get information on how it was even possible to set up an OpenVPN server on a Linux machine, since we later abandoned PfSense anyway, on which OpenVPN could also be deployed.

After a bunch of unsuccessful takes and rollbacks using snapshots, it was decided to simply use a ready-made script, which also made it possible to conveniently create users with passwords using the cli:

Now that I was able to figure out how easy it is to set up an OpenVPN server, I needed to start configuring the server itself, namely how to allow external users of the OpenVPN server access to virtual machines on the internal network.

After absorbing more information, a simple decision was made, connect virtual machines in the DMZ subnet using OpenVPN clients to the OpenVPN server and configure the settings so that all clients that were connected to the VPN tunnel could have access to each other. This allowed the participant to access sites and machines, since participants with servers in the DMZ were clients of the OpenVPN server.

When setting up this option, I used the materials below:

Ultimately the file /etc/openvpn/server.conf for the OpenVPN server configuration looked something like this:

На port 443
proto tcp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
# Proxy Server IP 
server 172.123.0.0 255.255.255.0
# Reserved IP addresses for OpenVPN clients
ifconfig-pool-persist ipp.txt
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_2fc7nlMyYKJLmvUf.crt
key server_2fc7nlMyYKJLmvUf.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
# Configuration of iroute for OpenVPN clients in ccd
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3
# Create route on server
push "route 192.168.1.0 255.255.255.0"
# Permit connections between OpenVPN clients
client-to-client

The important lines here are the choice of subnet for the VPN tunnel:

# Proxy Server IP 
server 172.123.0.0 255.255.255.0

Adding a file to reserve IP addresses ipp.txt for clients:

# Reserved IP addresses for OpenVPN clients
ifconfig-pool-persist ipp.txt

Adding return routes for specific OpenVPN clients in a directory ccd:

# Configuration of iroute for OpenVPN clients in ccd
client-config-dir /etc/openvpn/ccd

Sending a route to clients so that these IP addresses pass through the OpenVPN Server VPN tunnel:

# Create route on server
push "route 192.168.1.0 255.255.255.0"

Allowing connections between clients:

# Permit connections between OpenVPN clients
client-to-client

IP address reservation file ipp.txt looked like this:

имя_представителя_команды,резервируемый_ip_адрес,
название_клиент_сервера,резервируемый_ip_адрес,

Client specific settings file name_client_server.txtwhich was stored in ccd looked like this:

iroute ip_адрес_внутренней_сети_прокси 255.255.255.0

Setting up OpenVPN client-servers (Virtual machine in DMZ)

Config files for OpenVPN client-server in DMZ were generated using a script higher.

The file for the OpenVPN client-server in the DMZ looked like this:

client 
# Используемый протокол
proto tcp 
# Подключаемый прокси
remote внутренний_ip_адрес_прокси_сервера порт_прокси_сервера 
dev tun 
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
remote-cert-tls server 
verify-x509-name server_2fc7nlMyYKJLmvUf name 
auth SHA256 
auth-nocache 
cipher AES-128-GCM 
tls-client 
tls-version-min 1.2 
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 
ignore-unknown-option block-outside-dns 
#setenv opt block-outside-dns # Prevent Windows 10 DNS leak 
verb 3 
<ca> 
-----BEGIN CERTIFICATE----- 
 
-----END CERTIFICATE----- 
</ca> 
<cert> 
-----BEGIN CERTIFICATE----- 

-----END CERTIFICATE----- 
</cert> 
<key> 
-----BEGIN PRIVATE KEY----- 
 
-----END PRIVATE KEY----- 
</key> 
<tls-crypt> 
# 
# 2048 bit OpenVPN static key 
# 
-----BEGIN OpenVPN Static key V1----- 
 
-----END OpenVPN Static key V1----- 
</tls-crypt>

To start a connection to the OpenVPN Server in the background, you had to use the command:

sudo openvpn --config имя_конфига.ovpn --daemon

The magic command that you should not forget on Linux servers if you have UFW

And this command allows Forwarding on Linux, since it is disabled by default in UFW, which will not allow traffic to be forwarded from clients to virtual machines in the DMZ using our OpenVPN server:

ufw default allow FORWARD

Setting up OpenVPN clients (Polygon participants)

Everything here is very similar to creating a file for a client-server. The config is generated through the same scriptbut we already write the external IP address of the server instead of the internal one in order to connect to it:

client 
proto tcp 
# Proxy Server External IP
remote внешний_ip_адрес_прокси_сервера порт_прокси_сервера 
dev tun 
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
remote-cert-tls server 
verify-x509-name server_2fc7nlMyYKJLmvUf name 
auth SHA256 
auth-nocache 
cipher AES-128-GCM 
tls-client 
tls-version-min 1.2 
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 
ignore-unknown-option block-outside-dns 
setenv opt block-outside-dns # Prevent Windows 10 DNS leak 
verb 3 
<ca> 
-----BEGIN CERTIFICATE----- 
 
-----END CERTIFICATE----- 
</ca> 
<cert> 
-----BEGIN CERTIFICATE----- 
 
-----END CERTIFICATE----- 
</cert> 
<key> 
-----BEGIN PRIVATE KEY----- 
 
-----END PRIVATE KEY----- 
</key> 
<tls-crypt> 
# 
# 2048 bit OpenVPN static key 
# 
-----BEGIN OpenVPN Static key V1----- 
 
-----END OpenVPN Static key V1----- 
</tls-crypt>

Connecting the long-dead Debian 8 to OpenVPN

When I was connecting client-servers to the OpenVPN server, a problem occurred with one server, since it was on a long-outdated Debian 8 with archive repositories that have not been supported for a long time. The latest version of OpenVPN on Debian 8 was not compatible with the version of OpenVPN on Debian 12, so I had to manually package the new version for this dinosaur. Here instructionswhich I used to compile packages if you find yourself in a similar situation.

Conducting a cyber training ground

There was quite a lot of tension at the test site itself on February 24, since it was unknown whether the university’s network could withstand the load of 45 participants scanning the network from the inside. Also, due to the refusal to monitor, all traffic had to be monitored purely through web servers on the machines, or tcpdump, which you will agree is not the best solution at all.

Fortunately, the entire testing site went absolutely fine and there were no more problems with the university network. If cars fell, they responded immediately and corrected any problems.

Conclusion

This cyber testing ground was a rather interesting and unusual project, and although I ended up in it completely by accident, I was very glad to become a part of it. Yes, of course, there were a lot of crutches, no separate monitoring, no central firewall for setting rules, but this was the very first time we tested the idea itself.

In the second part there will be a story about the creation of a truly serious cyber training ground on a republican scale, where 3 cybersecurity companies and 12 national universities of our country participated. The team already had over 2 months of time, and several network engineers joined it, who took away some of my infrastructure responsibilities, allowing me to focus on improving monitoring, which made it possible to implement all the initial ideas that could not be implemented in this part.

See you in the next part!