Перед прочтением данной статьи настоятельно рекомендую ознакомиться с 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, я же оставлю те ресурсы которыми пользовался я:

OpenVPN - RouterOS - MikroTik Documentation

help.mikrotik.com

Настройка OpenVPN-сервера на роутерах Mikrotik в RouterOS 7

interface31.ru

Настройка OpenVPN-сервера на роутерах Mikrotik

bookflow.ru

Отмечу что до этого организаторы использовали 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, анализ доступности хостов в реальном времени, просмотр свободных адресов в подсети и многое другое. Я не буду подробно останавливаться на установке данного софта, для тех кому интересно ниже прикреплена официальная документация:

Installation

phpipam.net

Пример настройки менеджмента подсетей и 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 прошел отлично, участники яро бились за первые строчки на скорборде и реализовывали бизнес риски, я действительно рад что такие ивенты проводятся в нашей стране и что студенты уже в раннем возрасте показывают действительно отличные результаты, я благодарен всем организаторам за возможность поработать в таком приятном коллективе, это был хороший опыт и я надеюсь в будущем я смогу еще принять участие в подобных мероприятиях!

Организаторы AITU Military CTF 2024:Digital Fortress

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

AITU Military CTF 2024:Digital Fortress: Как мы инфраструктуру для полигона поднимали. Часть 2