Строим киберполигон. Используем EVE-NG, чтобы развернуть сеть для хакерских испытаний

Идея поп­робовать сов­ремен­ную плат­форму эму­ляции воз­никла, ког­да я наб­людал за работой коман­ды инже­неров кибер­безопас­ности. Они час­то занима­ются изу­чени­ем, раз­верты­вани­ем, интегра­цией и тес­тирова­нием раз­ных про­дук­тов. Вен­доров и решений — огромное количес­тво, но зна­читель­ная их часть вра­щает­ся вок­руг защиты одних и тех же клю­чевых сис­тем, некой стан­дар­тной кор­поратив­ной инфраструк­туры: рабочих стан­ций, сер­веров AD, фай­ловых шар, поч­товых сер­веров, веб‑сер­веров, сер­веров баз дан­ных. Так­же в любой инфраструк­туре при­сутс­тву­ет некая стан­дар­тная иерар­хия групп поль­зовате­лей, сетевая сег­мента­ция, набор ПО и сетевое обо­рудо­вание в виде ком­мутато­ров, мар­шру­тиза­торов, фай­рво­лов.

За­дачи по интегра­ции, как пра­вило, тоже типич­ные: нас­тро­ить авто­риза­цию через AD/Radius, под­ружить с поч­той, рас­катать аген­тов, соб­рать клас­тер, подать зер­калиро­ван­ный тра­фик, отправ­лять ана­лити­кам логи или флоу. Прак­тика показы­вает, что без стан­дарти­зиро­ван­ного под­хода каж­дый инже­нер со вре­менем нагоро­дит себе подоб­ную инфраструк­туру, и каж­дый — со сво­им блек‑дже­ком. В резуль­тате получа­ется целый зоопарк по‑раз­ному скон­фигури­рован­ных вир­туалок, на которых кру­тит­ся непонят­но что. Прос­то взять и быс­тро заюзать такие ВМ дру­гой член коман­ды, ско­рее все­го, не смо­жет.

По­мимо раз­бро­сан­ных на раз­ных ESXi-хос­тах «лич­ных» ВМ, для тес­тирова­ния фай­рво­лов, запус­ка мал­вари и про­чих задач тре­буют­ся сег­менти­рован­ные сети, поэто­му в такой инфраструк­туре порой встре­чают­ся еще и порт‑груп­пы. Они необ­ходимы толь­ко для лабора­тории, но по фак­ту ходят в интернет через про­дак­шен‑инфраструк­туру. Пос­ле уволь­нения инже­нера подоб­ные вир­туал­ки прос­то уби­вают­ся вмес­те со всем «накоп­ленным опы­том». Короче говоря, такой под­ход казал­ся мне сов­сем не эффектив­ным, тем более в нем не исполь­зуют­ся некото­рые фичи и гиб­кость VMware. Я решил стан­дарти­зиро­вать про­цесс, а заод­но про­тес­тировать плат­форму эму­ляции.

Зачем киберполигон инженерам?

Как ты, навер­ное, уже зна­ешь, кибер­полигон — это некая вир­туаль­ная сре­да, нацелен­ная на обу­чение. В отли­чие, ска­жем, от клас­сичес­ких CTF-подоб­ных сорев­нований, на кибер­полиго­не учат­ся так­же и защит­ники. Помимо кибер­полиго­нов, которые носят сорев­нователь­ный харак­тер и дос­туп к которым бес­плат­ный, уже сущес­тву­ет целый класс недеше­вых вен­дор­ских решений с готовы­ми сце­нари­ями атак и защиты, поз­воля­ющий эффектив­но обу­чать как «синие» коман­ды, так и «крас­ные» — в обла­ке по под­писке или on-premise. В нашем слу­чае была необ­ходима плат­форма, поз­воля­ющая дос­тигать сле­дующих целей:

• эф­фектив­ное внут­реннее/внеш­нее обу­чение инже­неров;
• пол­ноцен­ный демос­тенд для заказ­чиков.

Выбор платформы

Под наши нуж­ды была выб­рана плат­форма EVE-NG Community Edition — это форк извес­тно­го UNetLab, который боль­ше не под­держи­вает­ся. Дан­ное решение очень любят сетеви­ки, и дей­стви­тель­но есть за что. Ты толь­ко пос­мотри на при­меры сетевых тополо­гий с клас­терами и BGP!

Од­нако она соз­дана не толь­ко для сетеви­ков: воз­можнос­ти ее исполь­зования прак­тичес­ки без­гра­нич­ны, они зависят исклю­читель­но от фан­тазии и име­ющих­ся зна­ний. Для работы нам тре­бовал­ся веб‑интерфейс, а у кон­курен­тов он при­сутс­тво­вал на момент выбора толь­ко в GNS3, да и то в бете. Обо всех фичах EVE-NG, вклю­чая вер­сию Professional и Learning Center, в которых есть Docker и под­дер­жка клас­териза­ции, ты можешь про­читать на офи­циаль­ном сай­те, я же рас­ска­жу о клю­чевых воз­можнос­тях.

• QEMU/KVM. В дан­ной связ­ке QEMU выс­тупа­ет в роли эму­лято­ра железа, он дос­таточ­но гибок и может запус­кать код, написан­ный для одной архи­тек­туры про­цес­сора, на дру­гой (ARM на x86 или PPC на ARM). KVM же, в свою оче­редь, поз­воля­ет дос­тигать высокой про­изво­дитель­нос­ти бла­года­ря вир­туали­зации с аппа­рат­ной под­дер­жкой, такой как Intel VT-x и AMD-V.
• IOU/IOL и Dynamips. Под­дер­жка ста­рень­ких, но впол­не рабочих ком­мутато­ров и мар­шру­тиза­торов Cisco.
• Оп­тимиза­ция памяти UKSM в ядре. При одновре­мен­ном исполь­зовании одно­образных ВМ поз­воля­ет дедуп­лициро­вать память и тем самым сущес­твен­но сни­зить рас­ход RAM.
• Пол­ноцен­ный веб‑интерфейс на HTML5.
• Мно­гополь­зователь­ский режим для одновре­мен­ной работы раз­личных вир­туаль­ных лабора­торий.
• Вза­имо­дей­ствие с «нас­тоящей» сетью.

Установка

Мы раз­верну­ли «Еву» на железе (bare metal). Для такого типа уста­нов­ки предъ­явля­ются сле­дующие сис­темные тре­бова­ния: ЦПУ — Intel Xeon CPU supporting Intel® VT-x with Extended Page Tables (EPT), ОС — Ubuntu Server 16.04.4 LTS x64.

Все осталь­ное зависит от пред­полага­емой наг­рузки: тут чем боль­ше, тем луч­ше, осо­бен­но это каса­ется ОЗУ. Если тебя сму­тила ста­рая вер­сия ОС, то не пережи­вай, она будет под­держи­вать­ся до 2024 года. Замечу, что Community-вер­сия обновля­ется не так час­то, как Professional, в которой для уста­нов­ки на железо тре­бует­ся уже 18.04 LTS. Если же ты весь такой в обла­ках, то имей в виду, что EVE-NG офи­циаль­но под­держи­вает GCP.

Мы же сей­час с тобой рас­смот­рим вари­ант быс­тро­го зна­комс­тва с плат­формой, раз­вернув ее на ноут­буке с VMware Workstation. Под­держи­вает­ся толь­ко VMware, вклю­чая Player и ESXi. Но в любом слу­чае сле­дует понимать, что вло­жен­ная (nested) вир­туали­зация (это ког­да вир­туал­ка работа­ет внут­ри дру­гой вир­туал­ки) может пло­хо вли­ять на про­изво­дитель­ность. Так­же твой ЦПУ дол­жен под­держи­вать тех­нологии аппа­рат­ной вир­туали­зации, такие как Intel VT-x и AMD-V. Не забудь про­верить, вклю­чены ли они в BIOS.

Ин­терес­но, что про под­дер­жку AMD в Community-вер­сии офи­циаль­но не сооб­щает­ся, а вот в докумен­тации к Professional про­изво­дите­ли уже написа­ли, что под­держи­вают пос­ледние вер­сии про­цес­соров. Как бы то ни было, я раз­вернул Community-вер­сию на про­цес­соре AMD Ryzen 5 4600H без каких‑либо проб­лем.

Ес­ли ты исполь­зуешь в качес­тве хос­товой ОС Windows, тебе сле­дует пом­нить кое‑что о роли Hyper-V, в час­тнос­ти в Windows 10. Вот что об этом написа­но на сай­те Microsoft:

We introduced a number of features that utilize the Windows Hypervisior. These include security enhancements like Windows Defender Credential Guard, Windows Defender Application Guard, and Virtualization Based Security as well as developer features like Windows Containers and WSL 2.

По­мимо самой ОС и ее фич, эту служ­бу может исполь­зовать еще и Docker Desktop. Из‑за это­го до вер­сии 15.5 вклю­читель­но VMware Workstation (как и VirtualBox) вооб­ще не работа­ла на хос­те с вклю­чен­ной ролью Hyper-V. Кол­лабора­ция Microsoft и VMware поз­волила все же сде­лать интегра­цию Workstation с WHP через API, бла­года­ря чему появи­лось ра­бочее решение. Но, к сожале­нию, помимо того, что такая связ­ка ста­ла мед­ленней работать, име­ется глав­ное огра­ниче­ние, а имен­но — фун­кции Intel VT-x / AMD-V недос­тупны для гос­тевых ВМ. Служ­ба Hyper-V экс­клю­зив­но исполь­зует VT-x, огра­ничи­вая к нему дос­туп дру­гим гипер­визорам.

По­это­му, если на тво­ем хос­те вклю­чена роль Hyper-V, про­ана­лизи­руй, для чего она исполь­зует­ся, и при воз­можнос­ти отклю­чи ее. Если это невоз­можно, исполь­зуй дру­гой ПК, сер­вер или обла­ко.

Я рекомен­дую кач­нуть сра­зу кни­гу рецеп­тов EVE-NG в фор­мате PDF. В ней содер­жится исчерпы­вающее руководс­тво по все­му про­екту, от А до Я.

Итак, для быс­тро­го раз­верты­вания мы ска­чаем ZIP-архив с OVF-обра­зом, рас­паку­ем архив и двой­ным щел­чком мыши по EVE-COMM-VM.ovf импорти­руем его в Workstation.

От­кро­ем свой­ства, добавим при необ­ходимос­ти памяти и про­цес­соров. Убе­дись, что у тебя сто­ит галоч­ка Virtualize Intel VT-x/EPT or AMD-V/RVI в груп­пе нас­тро­ек Virtualization engine. Без нее EVE-NG будет заг­ружать­ся сама, мож­но откры­вать и соз­давать лабора­тории, но ВМ внут­ри лабора­тории запус­кать­ся не будут.

Для наг­ляднос­ти мы выберем режим Bridged у сетево­го адап­тера, тем самым наши ВМ внут­ри лабора­тории ста­нут дос­тупны нап­рямую в локаль­ной сети.

Работа с платформой

За­пус­каем EVE-VM в Workstation. Пос­ле успешной заг­рузки ты получишь приг­лашение на ввод пароля.

Ло­гиним­ся, исполь­зуя стан­дар­тную учет­ку root/eve для кон­соли.

Да­лее отве­чаем на стан­дар­тные воп­росы по нас­трой­ке ОС, такие как:

• New root password;
• Hostname;
• DNS domain name;
• DHCP/Static IP address;
• NTP Server;
• Proxy Server configuration.

Пос­ле отве­та на пос­ледний воп­рос сис­тема авто­мати­чес­ки перезаг­рузит­ся. По завер­шении перезаг­рузки откры­ваем веб‑интерфейс по IP-адре­су, ука­зан­ному в кон­соли ВМ, и логиним­ся, исполь­зуя учет­ку admin/eve.

По боль­шей час­ти вся работа с плат­формой выпол­няет­ся через веб‑интерфейс. По SSH под­клю­чать­ся к «Еве» при­ходит­ся лишь изредка, нап­ример для под­готов­ки обра­зов. Сущес­тву­ет два вари­анта под­клю­чения к монито­ру ВМ: через натив­ные при­ложе­ния или кон­соль HTML5. При выборе натив­ной кон­соли на ПК, с которо­го открыт веб‑интерфейс, дол­жны быть уста­нов­лены при­ложе­ния для уда­лен­ного дос­тупа и Wireshark. Набор соф­та раз­нится в зависи­мос­ти от ОС, а так­же тре­бует­ся некото­рый тюнинг реес­тра, поэто­му рекомен­дует­ся исполь­зовать Windows/Linux/Apple Client Side Integration Pack, содер­жащий все необ­ходимое, вклю­чая скрип­ты для кон­фигура­ции.

При исполь­зовании же кон­соли HTML5 все управле­ние ведет­ся пол­ностью через бра­узер. Кон­соль работа­ет на Apache Guacamole, как во мно­гих сов­ремен­ных вен­дорных лабора­тори­ях.

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

По сво­ей сути файл лабора­тории — это кон­фиг в фор­мате XML, опи­сыва­ющий кон­фигура­цию нод, их рас­положе­ние на поле, соеди­нения и про­чее. Ноды — это объ­екты ВМ, которые могут быть обра­зами IOL/Dynamips/QEMU. Лабы мож­но кло­ниро­вать, экспор­тировать и импорти­ровать пря­мо через веб‑интерфейс.

При откры­тии лабора­тории демонс­три­рует­ся вид тополо­гии, чем‑то похожий на Visio. На этой тополо­гии добав­ляют­ся и соеди­няют­ся меж­ду собой ноды. Сле­ва в меню находит­ся все, что необ­ходимо для работы, ноды мож­но запус­кать сра­зу все, а мож­но выбороч­но.

В отли­чие от Visio, при щел­чке по знач­ку откры­вает­ся уда­лен­ное под­клю­чение к ноде.

Каж­дая нода име­ет свои стан­дар­тные нас­трой­ки ВМ, такие как образ, с которо­го выпол­няет­ся заг­рузка, количес­тво CPU, RAM, Ethernet-пор­тов, аргу­мен­ты для гипер­визора и дру­гое.

Сети

В «Еве» два глав­ных вида сетей: мост и интерфейс управле­ния. В основном тебе при­дет­ся щел­кать мышью на нодах и выбирать пор­ты источни­ка и наз­начения. Это как раз одна из при­чин, по которым сетеви­кам так нра­вит­ся «Ева»: в ESXi, нап­ример, для «чис­тых» соеди­нений point-to-point тре­бует­ся соз­давать отдель­ный vSwitch и порт‑груп­пу, что отни­мает кучу вре­мени и сил.

Сеть в режиме мос­та дей­ству­ет как неуп­равля­емый ком­мутатор. Она под­держи­вает переда­чу помечен­ных пакетов dot1q. Это может быть необ­ходимо, ког­да нам нуж­но соеди­нить мно­жес­тво узлов в плос­кую (dot1q) сеть без исполь­зования обра­за сетево­го устрой­ства. Получит­ся пол­ностью изо­лиро­ван­ная вир­туаль­ная сеть.

Вто­рой вари­ант сети называ­ется «сеть управле­ния» с име­нами Cloud0/Pnet0. Этот интерфейс нас­тро­ен в режиме мос­та с пер­вым сетевым адап­тером сер­вера. Бла­года­ря это­му ты можешь сде­лать ноды дос­тупны­ми нап­рямую по сети, они будут находить­ся в том же сетевом сег­менте, что и интерфейс управле­ния, и могут вза­имо­дей­ство­вать с дру­гими внеш­ними сетями.

Ос­таль­ные интерфей­сы Cloud* мож­но свя­зать со вто­рым и выше пор­том Ethernet для под­клю­чения к дру­гой сети или к устрой­ству. Нас­тра­ивать на них IP-адрес не тре­бует­ся. Они будут дей­ство­вать как чис­тый мост меж­ду тво­им внеш­ним соеди­нени­ем и лабора­тор­ной нодой.

Образы

«Ева» пос­тавля­ется без обра­зов, на бор­ту име­ется толь­ко Virtual PC с базовой сетевой фун­кци­ональ­ностью.

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

Образы Dynamips/IOL

С обра­зами сетевых устрой­ств Dynamips/IOL поч­ти ничего делать не нуж­но, кро­ме вы­ясне­ния зна­чения IDLE PC и соз­дания фай­ла лицен­зии. К сожале­нию, не все фун­кции этих сетевых устрой­ств под­держи­вают­ся. Их кон­фиги хра­нят­ся в отдель­ном мес­те, в меню startup-configs и в NVRAM, а не в самом фай­ле обра­за. NVRAM исполь­зует­ся как пос­тоян­ное хра­нили­ще с воз­можностью записи для началь­ной кон­фигура­ции. В про­цес­се заг­рузки нода всег­да будет про­верять NVRAM на наличие сох­ранен­ной кон­фигура­ции.

Про­цесс заг­рузки таких обра­зов изоб­ражен на сле­дующей схе­ме и в целом понятен без допол­нитель­ных пояс­нений.

Образы QEMU/KVM

Все осталь­ные сис­темы будут работать в виде QEMU-обра­зов. Осо­бен­ность работы этих обра­зов в «Еве» зак­люча­ется в том, что сна­чала соз­дает­ся некий базовый образ, а при запус­ке и работе ВМ все изме­нения пишут­ся в отдель­ный файл. Это мож­но рас­ценивать как сво­его рода снап­шоты, при­вязан­ные к отдель­ным поль­зовате­лям.