Введение

Всем еще раз привет!

В данной статье будет рассказано, как мой сон на университетской лекции случайно, привел к череду событий, где я стал техническим организатором двух киберполигонов в стенах моего университета. Данная часть будет затрагивать только первый CTF, который проводился лишь среди студентов нашего университета. Во второй части уже будет рассказ о поднятии более крупного республиканского полигона среди сборных команд от универов и компаний, в котором ко мне присоединились еще 3 сетевых инженера.

Киберполигон - инфраструктура с заготовленными "дырками", которая специально создается для проверки навыков киберспециалистов. Участникам подобных соревнований дается доступ в какую-либо внутреннюю инфраструктуру, где находятся сервера, которые они должны будут взломать и повысить свои привилегии. В дальнейшем им также придется использовать уже взломанные машины для опрокидывания своего трафика, чтоб получить доступ к последующим заданиям и много чего другого. Побеждает тот, кто сможет решить большее количество заданий.

P.S. Данная статья не является руководством по подъему киберполигонов, а больше личным опытом, в котором применялось много костылей из-за мелких сроков.

Оглавление

• Предыстория

• Первый взгляд на готовность самого полигона

• Мечты о сотрудничестве с сетевыми инженерами IT-департамента университета, которые не сбылись

• Построение конечной топологии инфраструктуры

• Несколько мучительных недель с чтением документации OpenVPN до этого
  

  • Настройка OpenVPN сервера (Основной VPN Сервер)

  • Настройка OpenVPN клиент-серверов (Виртуальная машина в DMZ)

  • Волшебная команда, которую надо не забывать на Linux серверах, если у тебя стоит UFW

  • Настройка OpenVPN клиентов (Участники полигона)

• Подключение давно покойного Debian 8 к OpenVPN

• Проведение киберполигона

• Заключение

Предыстория

Начнем предысторию с того, что я студент выпускного курса Astana IT University факультета Кибербезопасности. На тот момент, я нашел работу системным администратором серверной инфраструктуры в местной ИБ компании, которую совмещал с учебой. Из-за большей нагрузки я довольно сильно уставал, поэтому просто засыпал на лекциях в университете.

Однако, 23 января 2024 года произошло то самое событие, которое лишило меня оставшегося сна...

В тот день, когда я спал, сзади меня сидел мой друг с параллельной группы, который по какой-то причине ругался на VMWare ESXi, в котором никак не мог взять и поднять виртуальную машину. Этот шум мешал моему сну, поэтому я просто взял и поднял ему нужную виртуальную машину.

После этого я конечно же собирался дальше лечь спать, но резко завязался довольно интересный диалог. Оказалось, что он пытался поднять виртуальные машины для будущего киберполигона от военной кафедры нашего университета.

Я выслушал его и собирался обратно заснуть. Однако, как оказалось, у него было не все так гладко, поскольку в команде организаторов не было ни одного специалиста, который занимался подъемом инфраструктуры.

Само мероприятие же проводилось, чтоб показать, что в нашем университеты учатся довольно сильные ИБ специалисты, которые могут развивать ИБ в стране, а все дальнейшие наработки по полигону будут переданы следующим студентам, чтоб они не занимались подъемом полигона и поиском информации с самого нуля, как делали это мы.

Цель данного мероприятия и мое личное отношение к данному человеку заставило меня резко проснуться и захотеть ему помочь, хотя конечно же никаких материальных благ я с этого не получу, но разве все должно делаться чисто ради денег?

Здесь и начинается моя история о подъеме данного полигона...

Первый взгляд на готовность самого полигона

После того диалога меня добавили в Telegram-чат и показали изначальную схему построения всего киберполигона:

Логически схема была конечно довольно хорошая, однако было пару мест, которые я поменял (Позже во 2 CTF-е все уже сделано было намного лучше):

• Отказался от решения выдавать участникам 15 готовых Kali-машин, поскольку ресурсы сервера были ужасно ограничены

• Отказался от подъема мониторинга, поскольку остававшееся время и завал по работе не позволял поднять Zabbix и Wazuh

• Отказался от подъема PfSense, потому что опять же не хватало времени и опыта, чтоб полностью его настроить

• Расположил OpenVPN и Landing на одном веб-сервере, поскольку было отказано дать дополнительный внешний ip-адрес

Вот один из старых набросков, которые я делал в течении первых недель. Позже мне пришлось их повыкидывать, поскольку у меня не было никакой информации о том, как устроена сеть универа и как можно все сделать точно.

На этом старом наброске все еще находятся те 15 Kali Linux машин, от которых потом было принято отказаться. Также Landing и OpenVPN, которые изначально планировались на разных серверах.

Мечты о сотрудничестве с сетевыми инженерами IT-департамента университета, которые не сбылись

Теперь конечно же после кучи кривых набросков мне нужно было посоветоваться с IT-департаментом универа, поскольку я был в абсолютно чужой корпоративной сети, где даже не знаю, как что было настроено.

К сожалению, исходя из названия можно понять, что это не кончилось чем-то хорошим. Сначала была запрошена топология сети универа или хотя бы части, в которой я нахожусь. В ответ было получено, что такой карты у них нет. После этого, попросили выдать хотя бы сетевого инженера, который разбирается, как все настроено и настроил бы мне Fortinet Firewall универа так, как мне будет нужно. И конечно же опять мне было повторно отказано и сказано, что я должен буду строить весь полигон лишь в VLAN 14, а специалиста для помощи мне никто не даст. Кроме того, как писал выше, было отказано дать еще один внешний IP-адрес, чтоб расположить Landing для регистрации и OpenVPN на разных серверах, что опять же 1000 и 1 раз повлияло на построение всего киберполигона.

После тушения своей 5 точки от полученной информации, я принялся строить саму инфраструктуру...

Построение примерного плана по поднятию инфраструктуры

Если зайдем немного в будущее, то после большего количество споров и обсуждений была построена четкая топология всего полигона, которую вы можете увидеть ниже:

По плану было создано 5 подсетей на VMWare ESXI:

1. Подсеть Network имела доступ в интернет и на ней находилась машина с внешним ip адресом, на котором был расположен OpenVPN Server, с помощью которого обеспечивался доступ во внутренние подсети для участников полигона.

2. Подсеть DMZ не имела доступа в интернет, поэтому доступ к ней можно было получить лишь через машину с OpenVPN Server-ом, которая имела отдельный сетевой интерфейс в подсети DMZ. Все машины находившиеся в DMZ были подключены с помощью OpenVPN клиент файлов конфигурации к OpenVPN Server, в которых им всем были заданы зарезервированные ip-адреса внутри туннелей.

3. В оставшихся подсетях находилось по 1 бизнес-риску, к которым можно было получить доступ лишь с помощью повышение привелегий на определенных машинах, находившихся в DMZ, которые также имели отдельные сетевые интерфейс для доступа в подсети бизнес-рисков.

Как можете увидеть, то тут есть такие подсети (192.168.1.*, 192.168.2.*, 192.168.3.*, 192.168.4.*), которые не входят в 14 подсеть, но почему-то работают. В данном случае это работало, потому что у меня не было доступа в другие физические VLAN-ы и я создал полностью виртуальные VLAN-ы, работавшие только внутри ESXi.

Несколько мучительных недель с чтением документации OpenVPN до этого

Настройка OpenVPN сервера (Основной VPN Сервер)

Сначала мне нужно было достать информацию, как вообще можно было поднять OpenVPN сервер на Linux машине, поскольку от PfSense в дальнейшем мы все равно отказались, на котором тоже можно было развернуть OpenVPN.

После кучи неудачных дублей и откатов с помощью snapshot-ов, было принято просто воспользоваться готовым скриптом, который еще позволял удобно через cli создавать пользователей с паролями:

Теперь, когда я смог разобраться, как просто поднять OpenVPN сервер, нужно было заняться конфигурацией самого сервера, а именно как разрешить доступ внешним пользователям OpenVPN сервера в виртуальные машины во внутренней сети.

После большего количества поглощенной информации было принято простое решение, подключить виртуальные машины в подсети DMZ с помощью OpenVPN клиентов к OpenVPN серверу и прописать настройки так, чтоб все клиенты, которые были подключены к VPN-туннелю могли иметь доступ к друг другу. Это позволяло участником получить доступ к сайтам и машинам, так как участники с серверами в DMZ были клиентами относительно OpenVPN-сервера.

Во время настройки данного варианта пользовался материалами ниже:

В конечном итоге файл /etc/openvpn/server.conf для конфигурации OpenVPN сервера выглядел примерно так:

На 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

Важные строчки здесь это выбор подсети для VPN-туннеля:

# Proxy Server IP 
server 172.123.0.0 255.255.255.0

Добавление файла для резервации айпи-адресов ipp.txt для клиентов:

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

Добавление обратных маршрутов для определенных OpenVPN клиентов в директории ccd:

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

Отправка маршрута на клиентов, чтоб данные ip-адреса проходили именно через VPN-туннель OpenVPN Server-а:

# Create route on server
push "route 192.168.1.0 255.255.255.0"

Разрешение соединения между клиентами:

# Permit connections between OpenVPN clients
client-to-client

Файл для резервации айпи-адресов ipp.txt выглядел так:

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

Файл для настроек определенного клиента название_клиент_сервера.txt, который хранился в ccd выглядел так:

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

Настройка OpenVPN клиент-серверов (Виртуальная машина в DMZ)

Конфиг-файлы для OpenVPN клиент-сервера в DMZ генерировались с помощью скрипта выше.

Файл для OpenVPN клиент-сервера в DMZ выглядел вот так:

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>

Для запуска подключения к OpenVPN Server-у на фоне нужно было использовать команду:

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

Волшебная команда, которую надо не забывать на Linux серверах, если у тебя стоит UFW

И эта команда разрешает Forwarding на Linux, поскольку он запрещен по умолчанию в UFW, что не позволит перенаправлять трафик с клиентов на виртуальные машины в DMZ, используя наш OpenVPN-сервер:

ufw default allow FORWARD

Настройка OpenVPN клиентов (Участники полигона)

Здесь все очень похоже на создание файла для клиент-сервера. Конфиг генерируется через тот же скрипт, но мы уже пишем внешний ip-адрес сервера вместо внутреннего, чтоб к нему подключиться:

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>

Подключение давно покойного Debian 8 к OpenVPN

Когда я занимался подключением клиент-серверов к OpenVPN-серверу произошла проблема с одним сервером, поскольку он был на давно устаревшем Debian 8 с архивными репозиториями, которые давно не поддерживаются. Последняя версия OpenVPN на Debian 8 не была совместима с версией OpenVPN на Debian 12, поэтому пришлось вручную собирать пакет с новой версией на этого динозавра. Вот инструкция, которую я использовал, чтоб скомпилировать пакеты, если попадете в похожую ситуацию.

Проведение киберполигона

На самом полигоне 24 февраля было достаточно напряжения, поскольку было неизвестно выдержит ли сеть универа нагрузку от 45 участников, которые сканируют сеть изнутри. Также из-за отказа от мониторинга весь трафик приходилось мониторить чисто через веб-сервера на машинах, либо tcpdump, что согласитесь вообще не самое лучшее решение.

К счастью, весь полигон прошел абсолютно нормально и не было большего количества проблем с сетью универа. Если машины падали, то моментально реагировали и исправляли любые проблемы.

Заключение

Данный киберполигон был довольно интересным и необычным проектом, и хоть я оказался в нем совершенно случайно, но я был очень рад стать его частью. Да конечно, было очень много костылей, отсутствие отдельного мониторинга, никакого центрального firewall-а для установки правил, но это был самый первый раз, когда мы тестировали саму идею.

Во второй части будет уже рассказ о поднятии действительного серьезного киберполигона республиканского масштаба, где участвовали 3 ИБ компании и 12 сборных ВУЗ-ов нашей страны. Времени у команды было уже свыше 2 месяцев, а в ее состав присоединилось несколько сетевых инженеров, которые забрали часть моих обязанностей по инфраструктуре, позволив состредоточиться на подъеме мониторинга, что позволило реализовать все изначальные идеи, которые не смогли реализовать в этой части.

Увидимся в следующей части!