KOMÁREK, L. Příprava a implementace Jump serveru pro herní scénáře v Kybernetické aréně [online]. Brno: Vysoké učení technické v Brně. Fakulta elektrotechniky a komunikačních technologií. 2023.
Student se ve své práci věnoval implementací a automatizací Jump serveru, který má poskytovat jednoduché SSH spojení pro virtuální stroje vnořené ve virtuální infrastruktuře kyberbezpečnostních her. Celou práci studenta musím rozlišovat na aktivitu v zimním a letním semestru. V zimním semestru se student věnoval teoretické části, a to postupně virtualizaci, kontejnerizaci, OpenStacku a jeho hlavním službám a na závěr srovnává virtuální stroje a kontejnery, a to v úvaze, která technologie bude vhodnější k použití Jump serveru. Během srovnávání se student rovněž manuálně seznamoval s oběma technologiemi pro jejich bližší pochopení, tuto práci však nyní nevhodně přemístil pod kapitolu 2.1 s názvem Nástroje OpenStacku, kde se však o žádné jeho nástroje nejedná. Práce v zimním semestru byla zakončena kapitolou 2.5. Shrnutím lze říct, že se studentovi nepovedlo manuální zprovoznění Jump Serveru, nebylo moc uvažováno nad možnými duplicitami a napsaný text byl na velmi nízké úrovni. V rámci letního semestru student výrazně zlepšil kvalitu předešle napsaného textu (především v gramatických, typografických a někdy i věcných chybách), avšak zbytek jeho práce je opět na velmi slabé úrovni. Student se skoro vůbec nevěnoval psaní práce a nechal to až na posledních pár dnů před odevzdáním (kapitoly 2.6 až 2.9). To se velmi podepsalo na kvalitě textu, který někdy vůbec nedává smysl a je zde velké množství gramatických a věcných chyb. Student začal konzultovat od 1.3. jednou za 1–2 týdny. Avšak musím bohužel konstatovat, že většina stráveného času nebyla efektivně využita. V rámci řešení student nepřicházel s vlastními nápady implementace a muselo mu být v tomto smyslu dopomáháno, navíc si nedělal poznámky a spousta věcí mu musela být vysvětlována opakovaně. Některé zásadní věci student vypustil úplně. Příkladem může být navedení studenta, že pro nastavování SSH tunelů se Jump server vůbec nemusí přihlašovat na cílové virtuální stroje, ale pouze na localhosta, což bylo i studentem během konzultace otestováno. Student ale namísto toho zbytečně řešil automatizaci přihlašování na cílové servery pom. jednotného uživatele a hesla / veřejného klíče. Student velmi podcenil celou automatizační část. Svůj dosavadní postup v automatizaci moc nekonzultoval, konzultace využil spíše k dotázání se k některým částem kódu nebo případně k určitému problému. Musím konstatovat, že k hlavnímu kódu, který není moc rozsáhlý (2 playbooky, 3 role, okolo max 25 operací) byl student detailně seznámen s kódem a rovněž i další ukázkovou Heat šablony, kterou mohl převzít a poupravit ke svému prospěchu. Student následně po 4 týdnech uvedl, že "zprovoznil" playbook game_shutdown, který slouží pro kompletní vymazání všech vytvořených struktur z playbooku game_start. Funkcionalita však nebyla vůbec zprovozněna a student tedy vůbec neřešil žádné čistící operace svých změn při mazání celé kybernetické hry. Je nutné vše dělat ručně. Implementace Jump serveru pomocí playbooku game_start není zcela zautomatizována a při běhu je vyžadováno potvrzení ECDSA fingerprintu. Předávání parametrů (IP+port) pro připojení na virtuální stroje přes SSH mělo být zprovozněno obdobně jako u ukládání parametrů scénáře, toho nebylo úplně docíleno, není předávána plovoucí IP Jump serveru. SSH tunely dále nejsou vytvářeny podle účelu uvedeném v konfiguračním souboru – pokud je uveden parametr „ssh_connection“ jako False, je i tak SSH tunel vytvořen, i když jiným způsobem. Vzhledem k uvedeným se nedá považovat jako hlavní cíl práce za zcela splněný. Na závěr lze ještě dodat, že nebyly úplně pochopeny zásady Ansiblu, čemuž odpovídá implementace řešení, největší výtky shrnuji v bodech: - kód obsahuje spoustu nevyužitých struktur kódu, to je zapříčiněno i kopírováním bez přemýšlení. Příkladně: výpis 2.2 – většina jen převzata z hlavního kódu student se vůbec nezamyslel proč tu používá validaci Heat šablony, nebo proč získává výpis existujících stacků (tuto hodnotu totiž dále vůbec nepoužívá); nebo import knihoven "getpass", "pwd" v python příkazu pro vytvoření hashe v roli template-jumpserver. - Zadávání absolutních cest s domovským adresářem lokálního uživatele, i když se v Ansiblu využívá relativních cest od složky s hlavními playbooky. Implementace tak nebude fungovat na serveru bez přidaného stejného uživatele. - Nevhodná pojmenování operací, příkladně operace „Check for free ports“, nekontroluje volné porty, nýbrž jen uloží náhodně zvolený port z rozsahu, může zde tedy dojít k chybě i když v minimální míře. - Není zaručena idempotence, tedy operace nejsou vhodně ošetřeny při opětovném spuštění a playbook skončí chybou. - Nadbytečné používání parametrů pro Jump server v konfiguraci her, kde takřka všechny parametry můžou být hardcodovány / zautomatizovány. - Technika generování celých struktur rolí pomocí jinja2, které jsou následně importovány a spouštěny při aktuálně běžícím Ansible playbooku se v praxi nedá používat. Role by měly být nadefinovány přímo a spouštění by mělo být vhodně ošetřeno pomocí podmínek. Rovněž se nepoužívá definování proměnných do názvů operací. Tyto techniky znemožňují hledání v kódu při debuggingu. Navíc generované role obsahují i duplicitní operace, které je třeba spustit jen jednou a ne pro každého studenta (scénář) znovu. Vzhledem ke všem uvedeným nedostatkům, hodnotím práci známkou F, 45 b.
Ladislav Komárek řešil v rámci své bakalářské práce přípravu a implementaci Jump serveru pro herní scénáře v Kybernetické aréně vyvíjené na VUT. Textová práce je rozdělena do dvou kapitol. Autor zde vychází zejména z popularizačních textů webových stránek, YouTube a dalších nepříliš odborně zaměřených zdrojů. V první kapitole se autor věnuje virtualizaci, kontejnerizaci a následně veřejně dostupnému cloudu OpenStack. Autor se zde dopouští drobných typografických prohřešků (např. OpenStack vs Openstack, rozdělení slova Docker-file, nadpisy tabulek pod tabulkami, špatné použití uvozovek, apod.), fakticky by se dalo rozporovat porovnání Dockeru a VM, kde autor uvádí, že VM má využití 5–10 GB, což pouze v případě OS image Ubuntu 20.04 se bude pohybovat minimálně na úrovni 16 GB, dále si myslím, že poměrně stěžejní otázka bezpečnosti by se při tomto srovnání mohla využít daleko detailněji než pouze zmínkou v sekci 1.4.2 a srovnání v tabulce 1.1 formou ANO, ANO. V kapitole 2 se autor věnuje své praktické části, která působí odbytým dojmem. Kupříkladu autor si sám protiřečí, hned v úvodu kapitoly uvádí: „V praktické části je popsán postup k přípravě Jump server, který je implementován jako kontejner“, nicméně po dalších sekcích věnujícím se Dockeru se uvádí, že u Jump serveru v kontejneru nelze nastavit směrování a proto bude využita VM. Dále autor uvádí v Sekci 2.1 "Nástroje OpenStacku" jako Libvirt a Docker, nicméně zde jde o naprosto nepřesnou a matoucí formulaci, protože toto nejsou implicitní funkce/nástroje OpenStacku, nýbrž doinstalované nástroje do tohoto cloudu. Celkově lze konstatovat, že textová část práce je pod průměrem standardu Fakulty elektrotechniky a komunikačních technologií VUT se značným množstvím faktických či jiných typografických nedostatků. Největším nedostatkem práce je její praktická část. Cílem studenta bylo automatizovat tvorbu jump serveru. Student realizoval konfiguraci Ansible playbooků pro automatickou tvorbu Jump serveru, nicméně tento vytvořený playbook nefunguje, respektive plně neautomatizuje tvorbu Jump serveru. Při spuštění playbooku studenta nastane chyba vyžadují ECDSA key fingerprint. Při manuální opravě této chyby (uložení nového otisku je nutné potvrdit manuálně) a opětovného spuštění dojde k další chybě. Kromě samotných komplikací se spuštěním automatického vytvoření Jump serveru, lze konstatovat, že implementace Ansible playbooků vykazuje známky nepochopení Ansiblu. Student využívá pro generování struktury operací jinja2 template, ale bohužel zde uvádí 9 operací, kde pouze 2–3 mají skutečně smysl ke spuštění. Ostatní operace se provádí opakovaně při každém použitém scénáři. Toto nepovažuji za efektivní, vzhledem k tomu, že dojde k opakovanému kopírování SSH private/public klíče. To může u her v kybernetické aréně obsahující 20–30 scénářů vyžadovat 40 a více operací, i když je potřeba pouze 1. Vzhledem k rozsahu implementační části, její slabé úrovni a nefunkčnosti plně automatické tvorby Jump serveru považuji zadání za nesplněné. Z tohoto důvodu uděluji 44 bodů se známkou F.
eVSKP id 153104