Введение
Всем еще раз привет!
В данной статье будет рассказано, как мой сон на университетской лекции случайно, привел к череду событий, где я стал техническим организатором двух киберполигонов в стенах моего университета. Данная часть будет затрагивать только первый 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:
Подсеть Network имела доступ в интернет и на ней находилась машина с внешним ip адресом, на котором был расположен OpenVPN Server, с помощью которого обеспечивался доступ во внутренние подсети для участников полигона.
Подсеть DMZ не имела доступа в интернет, поэтому доступ к ней можно было получить лишь через машину с OpenVPN Server-ом, которая имела отдельный сетевой интерфейс в подсети DMZ. Все машины находившиеся в DMZ были подключены с помощью OpenVPN клиент файлов конфигурации к OpenVPN Server, в которых им всем были заданы зарезервированные ip-адреса внутри туннелей.
В оставшихся подсетях находилось по 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 месяцев, а в ее состав присоединилось несколько сетевых инженеров, которые забрали часть моих обязанностей по инфраструктуре, позволив состредоточиться на подъеме мониторинга, что позволило реализовать все изначальные идеи, которые не смогли реализовать в этой части.
Увидимся в следующей части!
