Hlavní navigace

Jak se staví největší české kybernetické cvičení Cyber Czech

Jakub Onderka

Kybernetická cvičení se stávají stále komplexnější a bez automatizačních nástrojů by je již nešlo vytvářet. Představíme vám nástroje, které se používají při přípravě největšího českého cvičení Cyber Czech.

Doba čtení: 8 minut

Sdílet

V květnu tohoto roku proběhlo největší cvičení kybernetické bezpečnosti v Česku – Cyber Czech. To pořádá Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) od roku 2015 a to ve spolupráci s Masarykovou univerzitou v kybernetickému polygonu (KYPO) v Brně. A protože se jednalo o poslední opakování ročníku 2018, rozhodli jsme se vám poodhalit, jak příprava takového cvičení z technického pohledu vypadá.


Jednotlivé týmy jsou během cvičení a už i během jeho přípravy rozděleny dle barev:

  • Modrý tým má za úkol zabezpečit a ubránit danou infrastrukturu.
  • Červený tým má za úkol útočit na infrastrukturu Modrých týmů.
  • Bílý tým připravuje scénář a netechnické úkoly, simuluje uživatele, policii, právní tým, vládní CERT a novináře.
  • Zelený tým připravuje infrastrukturu Modrých týmů, skórování a monitorování.

Pro Modré týmy (většinou šest týmů po čtyřech lidech) celé cvičení probíhá ve dvou dnech. První den dostanou přístup k pro ně neznámé infrastruktuře. Ta se skládá z několika desítek strojů, u kterých musí nejprve pochopit jejich funkci v infrastruktuře a následně je zabezpečit bez toho, aniž by byla narušena jejich funkce. Druhý den už jsou na ně totiž prováděny útoky ze strany Červeného týmu. Těmto dvěma dnům samotného cvičení však předchází několikaměsíční příprava ze strany Červeného, Bílého a Zeleného týmu.

Příprava cvičení z pohledu Zeleného týmu

Celé cvičení běží ve virtualizační platformě KYPO, která je postavená na systému OpenNebula a využívá virtualizaci KVM. Obsahuje více než 100 virtuálních strojů různých operačních systémů, které běží nad 200 procesorovými jádry s 600 GB paměti. Pro účely vývoje a testování se používá separátní virtualizační platforma VMware vSphere.

Při přípravě ročníku 2016 byly použity textové popisy instalace strojů uložené v Redmine Wiki. Tyto popisy obsahovaly informace o hardwarových prostředcích stroje, nainstalovaném software, nastavení operačního systému, apod. To se však brzy ukázalo jako problematické, protože celý systém byl náchylný na lidské chyby (zapomenutí spuštění příkazu, překlepy apod.) a náročná byla také správa těchto popisů. Redmine Wiki sice poskytuje verzování stránek, ale jakákoliv změna (např. přidání příkazu) vyžadovala úpravu návodu, ověření funkčnosti a informování osoby zodpovědné za nasazení.

Ansible

Pro ročník 2018 jsme se rozhodli pro výraznou změnu, a to pokusit se všechny postupy automatizovat. Primárním cílem bylo snížení počtu chyb způsobených lidmi, zrychlení a zjednodušení nasazení a možnost znovupoužít části kódu pro další ročníky cvičení. Automatizované popisy instalace strojů také částečně slouží jako dokumentace (pokud není dokumentace součástí kódu, rychle zastarává). Jako automatizační nástroj byl zvolen Ansible. Pro naše potřeby totiž:

  • Podporuje všechny platformy, které jsou ve cvičení použity (Windows, linuxové systémy, Cisco).
  • Na stroji nemusí běžet žádný agent, Ansible se na stroj připojuje pomocí SSH resp. WinRM.
  • Úkoly se zapisují v YAML formátu a jsou tak snadno čitelné.
  • Umožňuje jednoduchou tvorbu vlastních modulů (Python, PowerShell).
  • Každý úkol musí mít název (zajišťuje Ansible Lint), který slouží jako základní dokumentace.

Ansible má i několik drobných nevýhod, jako je například nevalidování všech parametrů a hodnot před spuštěním playbooku. Validaci provádí až během vykonávání konkrétního úkolu, takže se může stát, že syntaktická chyba je odhalena až v průběhu nasazování. Navíc se občas i v setinkové aktualizaci mění chování modulů a je tak potřeba dbát na to, aby všichni používali stejnou verzi Ansible (bohužel nelze globálně specifikovat minimální verzi, lze to jen v rámci každého playbooku).

Redmine jsme nahradili vlastní instancí GitLabu a veškerý kód začali verzovat v Git repozitářích se všemi výhodami, které Git přináší.

Terraform

Stále bylo nutné ručně vytvářet virtuální stroje na virtualizační platformě podle textového popisu (typ systému, IP adresy, počet CPU, velikost disku apod.). To je zdlouhavý proces, který se navíc v rámci testování nových verzí kódu prováděl několikrát do týdne. Ačkoliv Ansible umožňuje komunikovat s VMware vSphere, vytvářet v něm virtuální stroje a snapshoty, našim požadavkům i přesto nevyhovoval (např. neposkytuje přehled o nasazené infrastruktuře).

Proto jsme zvolili open-source nástroj Terraform od společnosti HashiCorp. Ten umožňuje na základě definice a připravených šablon virtuálních strojů nasadit celou infrastrukturu cvičení, včetně nastavení síťování. Navíc při úpravě definice stroje lze některé změny (zvětšení disku, velikosti paměti, počtu procesorů, …) provést za běhu bez nutnosti vytvářet nový virtuální stroj. Tento nástroj podporuje nejen VMware vSphere, ale i další virtualizační platformy a teoreticky by tak neměl být problém cvičení nasadit i ve veřejném cloudu (například na AWS). Zápis definic (textový formát HCL) je jednoduchý a čitelný a není tedy potřeba vytvářet separátní textové popisy strojů (co je v kódu, to platí).

Packer

Posledním krokem po vytváření virtuálních strojů byla automatizace vytváření jejich šablon. Pro tento proces byl použit open-source nástroj Packer, taktéž od společnosti Hashicorp. Ten dle dané definice a dodaného instalačního obrazu (soubor ISO) provede instalaci operačního systému, doinstalování potřebných aplikací a knihoven (např. VMware Tools, novější PowerShell u starších verzí Windows) a provede základní konfiguraci (např. ve Windows povolení WinRM, na Linuxu přidání veřejného SSH klíče pro správu). Taktéž provádí aktualizaci systému, protože se jedná o zdlouhavou proceduru (především na starších verzích Windows). Jelikož se pro testování a ostrý běh používala odlišná virtualizační platforma, bylo potřeba vytvářet šablony pro obě tyto platformy.

Po vytvoření šablony ji pak pomocný skript nahrál do VMware vSphere pomocí nástroje OVF Tool.

GitLab CI

Pro automatizaci vytváření šablon pomocí nástroje Packer a nasazení strojů nástrojem Ansible bylo využito GitLab CI. Pro vytváření šablon byl vyhrazen samostatný virtuální stroj určený přímo pro tento účel s nainstalovaným VMware Workstation a QEMU (ve VMware vSphere je potřeba pro tento stroj povolit hardwarovou virtualizaci). Pro nasazení strojů přes Ansible sloužil kontejner s nainstalovanými potřebnými nástroji a knihovnami. Před samotným spouštěním Ansible se spouštěl Ansible Lint, pro ověření dodržování best practices při psaní playbooků a rolí. Následně se všechny stroje revertovaly na inicializační snapshot, který byl vytvořen hned po nasazení pomocí nástroje Terraform a poté se začaly spouštět jednotlivé playbooky.

Nevýhodou tohoto postupu je, že v jeden okamžik může běžet jen jeden build. Druhou, čistší a pomalejší možností, je pro každý build vytvořit pomocí Terraformu novou infrastrukturu, na které se Ansible bude aplikovat. To by ovšem vyžadovalo aplikaci garbage collectoru, který by postupně odstraňoval staré buildy, aby se předešlo nedostatku místa na diskovém poli.

Aplikace všech rolí na stroje zpočátku trvala několik hodin, protože se jednotlivé role aplikovaly postupně. Proto byly playbooky rozděleny dle jednotlivých strojů, aby šlo jejich spouštění paralelizovat. Po revertu všech strojů se nejprve aplikují společné role na všechny Windows a Linux stroje, následně se instaluje doménový kontrolér, ale poté se všechny ostatní stroje nasazují naráz paralelně.

I při použití rychlé linky je nejrychlejší vždy provoz, který nemusí opustit síť virtualizace. Proto se linuxové balíky stahují z kešovacího proxy serveru Apt-Cacher NG, který navzdory názvu podporuje také RPM repozitáře. Jedná se o jednoduchý nástroj, jediná potřebná úprava spočívala v povolení HTTPS provozu, který ale není kešován.

Nakonec se jako největší problém ukázalo stahování souborů z internetu (zdrojové kódy, aplikace a utility). Stahování souborů z internetu nám přinášelo následující potíže:

  • Webové stránky se souborem byly dočasně nedostupné.
  • Měnilo se URL k souboru.
  • Stahovaná aplikace byla nahrazena jinou verzí na stejné URL, která kvůli chybě v instalátoru nešla nainstalovat.
  • Webový server zablokoval provoz z naší IP adresy kvůli nadměrnému provozu.
  • Soubor byl ze serveru odstraněn.

Všechny body kromě posledního by nebyly samy o sobě tak problematické, ale problematické se stanou v případě zavedení CI a neustálého spouštění buildů, kdy kvůli jednomu nedostupnému souboru nedojde k dokončení celé instalace. Obzvláště nepříjemné je, když se tyto problémy objeví den před deadlinem.

Proto jsme se rozhodli přesunout všechny soubory stahované z internetu (i o velikosti několika stovek MB) do repozitáře, jelikož jsme chtěli používat jednotné prostředí pro ukládání všech dat souvisejících se cvičením. Git samozřejmě není vhodný pro ukládání velkých binárních souborů, protože při klonování repozitáře se stahuje celá historie. Existuje však Git Large File Storage, rozšíření pro Git od GitHubu, které řeší ukládání velkých souborů – při klonování stahuje jen poslední verzi binárních souborů. Git LFS je podporováno v GitLabu, stačí jej jen aktivovat pro konkrétní repozitář v nastavení. Nevýhodou LFS je, že práce s ním je neintuitivní a ne vždy funguje spolehlivě.

Problematické se také ukázalo používání jednoho společného repozitáře jak pro Ansible, tak pro velké binární soubory a to kvůli CI – jak bylo uvedeno výše, Ansible nasazujeme na stroje paralelně a to tak, že pro každý stroj běží samostatný job. GitLab CI však repozitář naklonoval pro každý job a na CI serveru tak brzy došlo místo na disku. Řešení spočívalo v rozdělení repozitáře na dva, jeden s Ansible kódem a druhý s binárními soubory. Binární soubory jsou před započetím buildu nahrány na separátní stroj, na kterém běží jednoduchý HTTP server. Ten poskytuje soubory a ostatní stroje si je z něj stahují během buildu.

Po všech optimalizacích bylo možné celou infrastrukturu cvičení nasadit za méně než jednu hodinu.


Schéma použitých nástrojů

Plány do budoucna

V současné době běží příprava na další ročník cvičení. Z pohledu Zeleného týmu bude hlavním cílem sjednocení testovací a produkční virtualizační platformy. Dojde tak ke zjednodušení celého procesu vývoje a testování. Také chceme poskytnout Modrým týmům větší kontrolu nad jimi spravovaným prostředím. Dalším velkým cílem jsou integrační testy prostředí pro ověření funkcionality nových změn a to včetně útoků Červeného týmu. Více se chceme zaměřit na použití kontejnerizačních technologií alespoň pro systémy podporující běh cvičení (skórování, monitorování, apod.).

Máte zájem se mimo jiné podílet na přípravě dalšího ročníku cvičení? Na webu NUKIB.CZ se můžete informovat o placených stážích nebo volných pozicích.