Перед прочтением данной статьи настоятельно рекомендую ознакомиться с 1 частью
Введение
Данная статья является продолжением статьи про поднятие киберполигона AITU Military CTF, в этой части мы рассмотрим глобальные изменения касающиеся инфраструктуры, такие как настройка сети ESXI, создание централизованного Firewall и мониторинг. Данные изменения обоснованы тем что это было мероприятие уже республиканского уровня где участвовали люди из разных университетов страны
Я решил написать эту статью так как очень мало подобных статей на тему постройки киберполигона, в последнее время в нашей стране начали часто проводится CTF и в этой статье мы рассмотрим все тонкости настройки инфраструктуры в условиях ограниченности ресурсов.
P.S. Данная статья является лишь моим личным опытом а не инструкцией.
Оглавление
Предыстория
Ознакомление с ESXI и топологией
Неудачные попытки работы с pfSense
Mikrotik сила
OpenVPN
Firewall
IPAM и Zabbix
Какие были проблемы
Проведение киберполигона
Заключение
Предыстория
Всем привет, меня зовут Руслан aka @fafeka. Я студент первого курса факультета Кибербезопасности и по совместительству сетевой инженер, это моя первая серьезная статья поэтому прошу не критиковать меня за ошибки, я постараюсь расписать все подробно и интересно.
Для начала введу в контекст: существует так называемые игры CTF (Capture The Flag), это соревнования по кибербезопасности которые направлены на тренировку ваших способностей в различных сферах кибербезопасности таких, как Web, pwn, Forensic, Reverse, Cryptography, OSINT и многих других. Классический CTF Jeopardy представляет собой решение задач на платформе и получение флагов.
24 февраля 2024 года в университете прошел не совсем обычный CTF, в нем были добавлены элементы некого полигона, то есть помимо решения задач на платформе у участников была возможность реализовать бизнес риски. Бизнес риски решаются дольше обычных заданий и зачастую имеют несколько векторов атаки. Я участвовал в данном CTF и знал какие проблемы присутствовали у организаторов, поэтому я предложил им свою помощь.
Организацией данного полигона занималась команда из пентестеров и только одного DevSecOps, что согласитесь не очень хорошо. Поэтому меня и еще двух людей позвали участвовать в качестве сетевых инженеров, передо мной поставили четкую цель создать централизованное управление сетью и ее мониторинг. Почему я согласился? Мне хотелось сделать свой вклад в развитие ИБ в нашей стране и в университете, а также это ценный опыт в виде построения собственной инфраструктуры.
Само мероприятие проходило 5 апреля 2024 года в здании МВЦ Expo. В эти же дни проводился Kazakhstan Security Systems, на данной выставке было много различных спикеров и экспертов, в том числе и по информационной безопасности.
Ознакомление с ESXI и топологией
Что мы имеем по ресурсам?
Сервер 48 ЦПУ, 396 ГБ ОЗУ, 8 ТБ SSD. Пропускная способность канала подключенного к нашему серверу 1 Гб/с. И имеется один внешний белый IP-адрес. На сервере имеется 2 физические сетевые карты, одна служит для нашего полигона а другая для других задач.
Сам сервер подключен к межсетевому экрану Fortigate университета

До этого я только слышал словосочетание "ESXI Сервер" и никогда не работал с ним. ESXI сервер позволяет удобно запускать несколько виртуальных машин и управлять ими, это нужно для различных потребностей, в том числе и для построения киберполигона. Для того чтобы настроить простейшую сеть на сервере необходимо создать виртуальный свитч (vSwitch), привязать его к реальной сетевой карте и создать порт группы. Порт группы позволяют разделять порты на виртуальном свитче что в последствии позволяет нам сегментировать сеть.

На vSwitch можно настроить либо виртуальную сетевую карту (vmk) для ее соединения с физической сетевой картой (vmnic), либо виртуальный роутер или Firewall который также будет соединен с физическим адаптером. Когда я первый раз зашел на ESXI в vSwitch CyberPoligon был настроен vmk (виртуальный сетевой адаптер) с адресом 10.1.14.24.

Далее уже были настроены несколько порт групп с первого полигона, мы удалили их и создали 7 новых: DMZ, Organizers, Monitoring, Internet Management и 3 порт группы бизнес-рисков. В порт группе Internet Management будет находиться только шлюз.
До того как ознакомиться с реальной инфраструктурой я предлагал различные варианты начиная от аренды сервера в том помещении где будет проводиться мероприятие и заканчивая настройкой туннеля между двумя филиалами (Университет и МВЦ Expo), однако мы были ограничены в ресурсах и возможностях поэтому пришлось немного приубавить аппетит ;)
Неудачные попытки работы с pfSense
Изначально я не сразу разобрался, как все это работает и в будущем я за это поплачусь. При поднятии первого полигона организаторы хотели использовать pfSense - межсетевой экран с открытым исходным кодом основанный на OC FreeBSD. Его можно поставить как виртуальную машину и свободно использовать. До этого я никогда не слышал о pfSense и решил поработать с ним. Вместо того чтобы поставить pfSense как шлюз между реальным сетевым адаптером и остальными хостами мы подключили pfSense к vmk. Из за этих действий сеть работала не корректно и мы не понимали что делали не так, пока коллега не подсказал мне что надо удалить vmk и поставить вместо нее pfSense. В качестве WAN адреса назначить 10.1.14.24 а для виртуальных машин сделать свои подсети.
Когда эта проблема была решена мы вздохнули с облегчением, однако всплыло множество других, я хотел бы отметить несколько минусов работы с pfSense а именно:
1) Множественные баги из за которых у вас может что то отвалиться
2) Достаточно трудная настройка OpenVPN
3) pfSense нужно больше мощностей чем Mikrotik
Это лишь мое мнение и мой опыт, я считаю что все могло бы также работать и с pfSense, но лично мне это решение неудобно.
Mikrotik сила
Итоговым и отличным как оказалось решение стало установка в качестве роутера Mikrotik CHR (Cloud Hosted Router). Mikrotik - крупный вендор сетевого оборудования который производит различные сетевые устройства. До этого у меня уже был небольшой опыт работы с Mikrotik, а также я смотрел некоторые вебинары на эту тему. Mikrotik CHR часто используют как виртуальное решение, для управления и мониторинга трафика. Сначала мы столкнулись с проблемой лицензирования, в бесплатной версии доступна скорость только 1Mbit/сек что нас совсем не устраивало. Однако, если вы зарегистрируетесь на официальном сайте Mikrotik вам будет доступно 60 дней любой пробной лицензии указанной в таблице ниже. И даже после окончания лицензии ограничений по скорости не будет, у вас будут ограничения только на обновления. Более подробные мануалы по активации пробной версии вы можете найти в интернете а мы идем дальше.
License | Speed Limit | Price |
Free | 1Mbit | FREE |
P1 | 1Gbit | $45 |
P10 | 10Gbit | $95 |
P-Unlimited | Unlimited | $250 |
Как только мы скачали наш образ Mikrotik, нам необходимо создать виртуальную машину.
CHR необходимо минимум 256МБ ОЗУ и 128МБ диска. Максимально можно поставить 128ГБ ОЗУ и 16ГБ жесткого диска. Изначально я выделил 4 CPU но после нагрузочных тестов решил увеличить их до 8 CPU.
Также важный момент с выбором типа виртуальных сетевых адаптеров, мы можем выбрать один из 3 типов: E1000, E1000E и VMXNET3. Первые два представляют собой эмуляцию реальных сетевых карт Intel, третий же вариант это паравиртуализация сетевого адаптера рассчитанного на большие скорости и отличающий стабильностью и поддержкой большинства ОС. VMXNET3 поставляется в пакете VMware Tools.
Далее необходимо добавить интерфейсы на наш роутер

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

Я разбил сеть следующим образом:
DMZ - 10.1.14.128/27
Organizers - 10.1.14.160/27
Monitoring - 10.1.14.96/27
Business Risk 1 - 192.168.1.0/24
Business Risk 2 - 192.168.2.0/24
Business Risk 3 - 192.168.3.0/24
OpenVPN - 172.123.0.0/24
Также при построении сети, как вы наверное уже догадались, я столкнулся с проблемой двойного NAT. Дело в том что внешним адресом был 10.1.1.24 а адрес Fortigate 10.1.14.1. Однако это не принесло существенных проблем так как участники подключались по VPN. По своему незнанию я подумал что смогу разбить подсеть 10.1.14.0/24 на разные подсети с /27 масками однако это никак не помогло так что я мог использовать любые пулы серых адресов но было уже слишком поздно когда я понял это.
Для удобства необходимо подписать каждый интерфейс:
Flags: R - RUNNING Columns: NAME, TYPE, ACTUAL-MTU, MAC-ADDRESS # NAME TYPE ACTUAL-MTU MAC-ADDRESS ;;; WAN 0 R ether1 ether 1500 00:0C:29:9C:08:16 ;;; DMZ 1 R ether2 ether 1500 00:0C:29:9C:08:20 ;;; ORGANIZERS 2 R ether3 ether 1500 00:0C:29:9C:08:2A ;;; Bussiness Risk 1 3 R ether4 ether 1500 00:0C:29:9C:08:34 ;;; Bussiness Risk 2 4 R ether5 ether 1500 00:0C:29:9C:08:3E ;;; Bussiness Risk 3 5 R ether6 ether 1500 00:0C:29:9C:08:48 ;;; MONITORING 6 R ether7 ether 1500 00:0C:29:9C:08:52
И также назначить адреса и подписать их:
Flags: D - DYNAMIC Columns: ADDRESS, NETWORK, INTERFACE # ADDRESS NETWORK INTERFACE ;;; DMZ 0 10.1.14.129/27 10.1.14.128 ether2 ;;; Organizers 1 10.1.14.161/27 10.1.14.160 ether3 ;;; Bussines Risk 1 2 192.168.1.1/24 192.168.1.0 ether4 ;;; Bussines Risk 2 3 192.168.2.1/24 192.168.2.0 ether5 ;;; Bussines Risk 3 4 192.168.3.1/24 192.168.3.0 ether6 ;;; WAN 5 10.1.14.24/26 10.1.14.0 ether1 ;;; MONITORING 6 10.1.14.97/27 10.1.14.96 ether7
Ну и прописать маршрут по умолчанию в сторону Fortigate:
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY DISTANCE 0 As 0.0.0.0/0 10.1.14.1 1
На этом базовая настройка закончена и мы можем приступать к созданию OpenVPN сервера.
OpenVPN
Для начала обновим наш Mikrotik до последней стабильной версии 7.14.1. Обновление до RouterOS 7 не только исправляет уязвимости и ошибки прошлой версии но и позволяет нам более расширено настроить сервер OpenVPN. В 7 версии добавилась возможность использовать UDP и управлять маршрутами которые посылаются клиенту. Стоит также отметить что не обязательно использовать именно OpenVPN, в RouterOS 7 есть нативная поддержка Wireguard, мы использовали OpenVPN так как он был задействован в первом полигоне и он достаточно удобен для участников.
Вы можете найти большое количество инструкций на тему поднятия OpenVPN сервера на Mikrotik, я же оставлю те ресурсы которыми пользовался я:
Отмечу что до этого организаторы использовали FortiClient для подключения к инфраструктуре, я решил что будет лучше пересадить всех на OpenVPN и поэтому разделил сеть 172.123.0.0/24 на две: 172.123.0.48/28 админам и остальные адреса участникам. Уже после полигона я решил сделать два разных пула адресов для организаторов и для участников.
Начнем с создания пула IP-адресов:
Columns: NAME, RANGES # NAME RANGES 0 OpenVPN_Tunnel 172.123.0.0/24
Также необходимо создать сертификаты OpenVPN, в сертификате вам необходимо будет ук��зывать общий ключ для подключения ( например 12345678), он необходим для дополнительной безопасности, вы не сможете настроить OpenVPN сервер без этого ключа.
Flags: K - PRIVATE-KEY; L - CRL; A - AUTHORITY; R - REVOKED; T - TRUSTED Columns: NAME, COMMON-NAME # NAME COMMON-NAME 0 KLA T CTF_CA astanait.edu.kz 1 K R CTF_OpenVPN_Server astanait.edu.kz 2 K R CTF_OpenVPN_Client astanait.edu.kz
Далее мы настроим уже сам сервер:
enabled: yes port: 1194 mode: ip protocol: udp netmask: 24 mac-address: FE:2D:97:C6:3E:EB max-mtu: 1350 keepalive-timeout: 60 default-profile: OpenVPN certificate: CTF_OpenVPN_Server require-client-certificate: no tls-version: any auth: sha256 cipher: aes256-cbc reneg-sec: 3600 redirect-gateway: disabled push-routes: enable-tun-ipv6: no tun-server-ipv6: :: ipv6-prefix-len: 64
Тут мы выбираем в каком режиме, какой протокол и порт будет использовать наш VPN (ip и udp 1194), Выбираем сертификат сервера и настраиваем шифрование. Я не анонсирую маршруты пользователям центрально а напишу их в конечный файл клиента. Также выбираем redirect gateway - disabled чтобы у клиента использовался его личный маршрут по умолчанию.
Далее создаем профиль, это некий шаблон того как определенные клиенты будут подключаться к серверу:
Flags: * - default 1 name="OpenVPN" local-address=172.123.0.1 remote-address=OpenVPN_Tunnel bridge-learning=default use-ipv6=no use-mpls=default use-compression=default use-encryption=default only-one=yes change-tcp-mss=default use-upnp=default address-list="" on-up="" on-down=""
Тут мы указываем имя нашего профиля, локальный адрес (адрес Mikrotik) и какой пул адресов должен использоваться. Также ставим галочку only-one=yes, эта опция не позволяет подключиться одному пользователю с не��кольких устройств.
Далее вам необходимо будет настроить учетные записи пользователей:
Columns: NAME, SERVICE, PASSWORD, PROFILE, REMOTE-ADDRESS # NAME SERVICE PASSWORD PROFILE REMOTE-ADDRESS 15 user1 ovpn OpenVPN 172.123.0.2
В данном примере мы назначали статический IP-адрес клиенту, выбрали сервис и выбрали для него профиль.
Чтобы наши пользователи и организаторы могли заходить на сервер нам необходимо добавить разрешающее правило в Firewall:
Flags: X - disabled, I - invalid; D - dynamic 0 ;;; OPENVPN chain=forward action=accept protocol=udp in-interface=ether1 dst-port=1194 log=yes log-prefix=""
После того как вы создадите конфиг файл, пропишите туда нужные маршруты, например:
route 10.1.14.0 255.255.255.0
Firewall и доступа
Теперь необходимо определить куда, у кого и какой доступ должен быть:
Сеть DMZ должна быть изолирована чтобы из нее нельзя было получить доступ к другим подсетям, у сети DMZ не должно быть доступа в интернет.
Сети Organizers и Monitoring должны иметь доступ везде в том числе доступ в интернет.
Сети бизнес рисков также должны быть изолированы, только один определенный хост в DMZ должен связываться с определенным хостом в подсети бизнес риска.
Для начала давайте настроим NAT для того чтобы наши хосты могли скачать необходимые обновления и инструменты:
Flags: X - disabled, I - invalid; D - dynamic 0 chain=srcnat action=src-nat to-addresses=10.1.14.24 out-interface=ether1 log=no log-prefix=""
В данном правиле мы обозначали действие (src-nat), через какой адрес будут транслироваться пакеты (10.1.14.24) и выходной интерфейс.
В подсети Organizers присутствует хост "Landing" на этой виртуальной машине расположен сайт с информацией о мероприятии и т.д. Необходимо чтобы внешние пользователи могли зайти на него. Для этого на Fortigate инженеры университета настроили проброс портов, давайте настроим его также и на Mikrotik:
Flags: X - disabled, I - invalid; D - dynamic 0 ;;; Port Forward chain=dstnat action=netmap to-addresses=10.1.14.162 to-ports=443 protocol=tcp dst-address=10.1.14.24 in-interface=ether1 dst-port=443 log=yes log-prefix="" 3 ;;; FIREWALL FOR PORT FORWARD chain=forward action=accept protocol=tcp dst-address=10.1.14.162 in-interface=ether1 out-interface=ether3 dst-port=443 log=no log-prefix=""
Мы выбираем цепочку dst-nat так как хотим чтобы изменялся адрес назначения пакета, action=netmap указывает на то что необходимо будет создать статичную запись 1:1 двух IP-адресов. Указываем входящим интерфейсов наш WAN порт (ether1) и разрешаем только https трафик (443 порт). В конце настраиваем разрешающее правило для нашего форвардинга.
Настроим правило чтобы участники могли подключаться только к подсети DMZ:
22 ;;; FROM_OPENVPN_TO_DMZ chain=forward action=accept src-address-list=OPENVPN_ALL dst-address-list=DMZ in-interface=all-ppp out-interface=ether2 log=no log-prefix="" 23 ;;; FROM_DMZ_TO_OPENVPN chain=forward action=accept src-address-list=DMZ dst-address-list=OPENVPN_ALL in-interface=ether2 out-interface=all-ppp log=no log-prefix=""
Рекомендую для удобства использовать Address Lists, это списки IP-адресов которые вы можете подписать и в дальнейшем использовать, это помогает не запутаться в своих же правилах и проще для понимания другим инженерам.
Настроим правило чтобы сети Monitoring и Organizers могли "ходить" везде:
15 ;;; MONITORING_ALL chain=forward action=accept protocol=tcp src-address-list=MONITORING dst-address-list=ALL in-interface=ether7 out-interface-list=ALL dst-port=22,443,80,1514,1515,1516,10050 log=no log-prefix="" 16 ;;; MONITORING_ALL_PING chain=forward action=accept protocol=icmp src-address-list=MONITORING dst-address-list=ALL in-interface=ether7 out-interface-list=ALL log=no log-prefix="" 17 ;;; ORGANIZERS_ALL chain=forward action=accept src-address-list=ORGANIZERS dst-address-list=ALL in-interface=ether3 out-interface-list=ALL log=no log-prefix=""
Настройка правил для бизнес рисков:
26 ;;; FROM_DMZ_TO_RISK1 chain=forward action=accept src-address-list=did0s_task1 dst-address-list=did0s_task2_risk in-interface=ether2 out-interface=ether4 log=no log-prefix="" 27 ;;; FROM_RISK1_TO_DMZ chain=forward action=accept src-address-list=did0s_task2_risk dst-address-list=did0s_task1 in-interface=ether4 out-interface=ether2 log=no log-prefix="" 28 ;;; FROM_DMZ_TO_RISK2 chain=forward action=accept src-address-list=anonwx-task1 dst-address-list=anonwx-task3-risk in-interface=ether2 out-interface=ether5 log=no log-prefix="" 29 ;;; FROM_RISK2_TO_DMZ chain=forward action=accept src-address-list=anonwx-task3-risk dst-address-list=anonwx-task1 in-interface=ether5 out-interface=ether2 log=no log-prefix="" 30 ;;; FROM_DMZ_TO_RISK3 chain=forward action=accept src-address-list=yelnurx_web1 dst-address-list=yelnurx_task3_risk in-interface=ether2 out-interface=ether6 log=no log-prefix="" 31 ;;; FROM_RISK3_TO_DMZ chain=forward action=accept src-address-list=yelnurx_task3_risk dst-address-list=yelnurx_web1 in-interface=ether6 out-interface=ether2 log=no log-prefix=""
На этом основные настройки завершены, сеть работает и доступа разграничены. Я также настроил безопасность Mikrotik в связи с тем что участники могли бы попытаться взломать его :) Я пользовался данной статьей хотя вы можете использовать любые другие методы для защиты
IPAM и Zabbix
В каждой хорошей инфраструктуре должен быт быть учет IP-адресов и хостов. Моим решением для этого стал - phpipam. Это свободное и бесплатное программное обеспечение для учета IP-адресов и хостов в сетях. Я использовал данное решение так как у меня был опыт с ним и он абсолютно бесплатен. Я вежливо попросил нашего DevSecOps установить данное решение. Данный IPAM содержит в себе мощный инструментарий такой как: создание подсетей IPv4 и IPv6, анализ доступности хостов в реальном времени, просмотр свободных адресов в подсети и многое другое. Я не буду подробно останавливаться на установке данного софта, для тех кому интересно ниже прикреплена официальная документация:
Пример настройки менеджмента подсетей и IP-адресов:

В качестве мониторинга использовался Zabbix настроенный нашим DevSecOps'ом. Я принимал лишь косвенное участие в добавлении мониторинга Mikrotik. Так как мы не можем установить Zabbix агент на Mikrotik мы будем использовать SNMP.
Для начала настроим сам SNMP:
enabled: yes contact: location: engine-id-suffix: engine-id: 80003a8c04 src-address: :: trap-target: trap-community: public trap-version: 2 trap-generators: interfaces vrf: main
В данном окне мы просто включили SNMP и указали какой community использовать. Community позволяет указывать какие данные, в каком формате, как и куда должны отправляться, давайте настроим его:
Flags: * - DEFAULT Columns: NAME, ADDRESSES, SECURITY, READ-ACCESS, WRITE-ACCESS # NAME ADDRESSES SECURITY READ-ACCESS WRITE-ACCESS 0 * public 10.1.14.98/32 none yes no
Мы использовали community по умолчанию (public), указали адрес с которого разрешено подключение (Zabbix сервер) и установили права.
Какие были проблемы
Для начала хочу отметить что на самом месте мероприятия была одна точка доступа у которой было ограничение в 100мбит/сек, всего было 45 участников которые сильно нагружали сеть так как генерировали много трафика, изначально я думал что все будет достаточно плачевно однако мало кто жаловался на скорость сети, участники активно решали и лишь иногда когда я спрашивал у них есть ли какие то проблемы они говорили про скорость сети.
Также один из участников подметил что мог сканировать и потенциально атаковать других пользователей сети OpenVPN, я сильно удивился так как в Mikrotik это по умолчанию запрещено и я проверял это простыми icmp запросами (ping). Я не нашел решения этой проблеме в интернете, возможно я упустил какую то опцию при конфигурации сервера или профиля.
При первой настройке OpenVPN сервера я столкнулся с проблемой что при заходе на Mikrotik у меня была полностью пустая конфигурация, я мог свободно подключиться по WinBox или SSH но все было пусто, при подключении через FortiClient такой проблемы не было. Мне подсказали что проблема кроется в MTU, более подробно об этой проблеме можно прочитать в данной статье.
Проведение киберполигона
Если не брать в расчёт вышеописанные проблемы, CTF прошел отлично, участники яро бились за первые строчки на скорборде и реализовывали бизнес риски, я действительно рад что такие ивенты проводятся в нашей стране и что студенты уже в раннем возрасте показывают действительно отличные результаты, я благодарен всем организаторам за возможность поработать в таком приятном коллективе, это был хороший опыт и я надеюсь в будущем я смогу еще принять участие в подобных мероприятиях!


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