Projekt KYPO VG Analýza a návrh architektury

Projekt KYPO – VG20132015103 Analýza a návrh architektury Technická zpráva 2013

Autoři Pavel Čeleda, Petr Velan, Tomáš Jirsík Jan Vykopal, Martin Drašar, Martin Vizváry Jakub Čegan, Michal Procházka, Tomáš Rebok Radek Ošlejšek, Zdenek Eichler, Dalibor Toth Kontaktní adresa Masarykova univerzita Ústav výpočetní techniky Botanická 68a 602 00 Brno Příloha číslo 1 Výtisk číslo 1 Počet listů 42

Analýza a návrh architektury

Výtisk č. 1

Obsah 1 Úvod 1.1 Definice kritické infrastruktury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Hrozby pro kritickou informační infrastrukturu . . . . . . . . . . . . . . . . . . . . .

3 3 5

2 Architektura Kybernetického polygonu 2.1 Konfigurace Kybernetického polygonu . . . . . . . . . . 2.2 Řízení scénářů . . . . . . . . . . . . . . . . . . . . . . . 2.3 Vyhodnocování scénářů . . . . . . . . . . . . . . . . . . 2.4 Fungování Kybernetického polygonu z pohledu uživatelů

. . . .

6 7 8 8 9

3 Simulace infrastruktury 3.1 Požadavky na infrastrukturu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Navržené řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11 11 12

4 Měření a analýza provozu 4.1 Měřicí infrastruktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Analýza dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 14 17

5 Bezpečnostní scénáře 5.1 Seznam hrozeb pro kritickou informační infrastrukturu . . . . . . . . . . . . . . . . . 5.2 Obecný scénář pro Kybernetický polygon . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Scénář útoku distribuovaného odepření služby . . . . . . . . . . . . . . . . . . . . .

22 22 24 26

6 Vizualizace 6.1 Vymezení základních požadavků na vizualizaci . . . . 6.2 Front end – volba vizualizačních technologií na straně 6.3 Back end – volba aplikačního rámce . . . . . . . . . 6.4 Celková architektura vizualizační aplikace . . . . . .

30 30 32 34 36

. . . .

. . . .

. . . . klienta . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

7 Závěr

37

8 Seznam zkratek

38

9 Seznam použité literatury

40

Projekt Kybernetický polygon – VG20132015103

Strana 2/42


1

Výtisk č. 1

Úvod

Projekt Kybernetického polygonu (KYPO) představuje inovativní řešení reagující na aktuální potřeby Národního bezpečnostního úřadu, rezortu Ministerstva vnitra a bezpečnostních týmů (vládní CERT a národní CSIRT) při plnění jejich úkolů vyplývajících z cílů a závazků České republiky k zajištění kybernetické bezpečnosti. Předkládaný dokument shrnuje provedenou analýzu a definici hrozeb ohrožujících bezpečnost kritických infrastruktur. Je proveden návrh architektury Kybernetického polygonu umožňující realizaci hrozeb, jejich monitorování, identifikaci a vizualizaci. Jedná se o naplnění dílčího cíle projektu stanoveného na rok 2013. Z provedených pozorování a porovnání plyne, že v současné době dostupná řešení mají závažná návrhová a infrastrukturní omezení snižující jejich použitelnost. Tato omezení pak neumožňují jejich nasazení tak, aby mohly uspokojivě řešit problematiku předloženou v požadavcích kladených na projekt Kybernetického polygonu. Navrhovaný Kybernetický polygon má za cíl vytvořit prostředí pro vývoj a výzkum metod na ochranu proti kybernetickým útokům. Tohoto cíle bude dosaženo pomocí provádění komplexních kybernetických útoků proti reálné síťové a IT infrastruktuře, která bude umístěna ve virtualizovaném prostředí cloudu. Provedené útoky pak bude možné analyzovat a vyhodnocovat v jejich průběhu i po jejich ukončení. Prostředí bude dále sloužit pro vývoj nových bezpečnostních nástrojů a pro školení členů bezpečnostních týmů. Scénář 1

Scénář .... ....

Správa scenáře

LMN 1

Konﬁgurace scénáře

Routing Node

Zpracování dat

LMN n

...

Uzel správy scénáře

Vizualizace

LMN 2

Vstupní portál

LAN 1

LAN 2 LAN n

Scénář n Uzel správy scénáře

Simulace & Měření

Databáze

Obrázek 1: Kybernetický polygon

1.1

Definice kritické infrastruktury

Pro přesné určení pojmu kritická infrastruktura je nutné nahlédnout do zákonů, norem a dalších dokumentů poskytovaných organizacemi zabírajícími se problematikou informační bezpečnosti na úrovni jednotlivých států, případně nadnárodních uskupení. Dobrými příklady vymezení tohoto pojmu mohou poskytnout tři níže uvedené dokumenty. Projekt Kybernetický polygon – VG20132015103

Strana 3/42


Výtisk č. 1

První definici uvádí připravovaný věcný záměr Zákona o kybernetické bezpečnosti [9]. Věcný záměr popisuje kritickou infrastrukturu jako prvek kritické informační infrastruktury nebo systém těchto prvků, kde narušení jeho funkce může způsobit poškození nebo ohrožení zájmu České republiky. Následně jsou v záměru přesně specifikovány pojmy kritická informační infrastruktura a zájem České republiky. „Prvkem kritické informační infrastruktury je označen informační systém, služba nebo síť elektronických komunikací se zvláštním významem pro kybernetickou bezpečnost České republiky, jejichž dlouhodobá nefunkčnost bude mít za následek ohrožení nebo poškození konkrétního zájmu České republiky zařazeného do seznamu prvků kritické informační infrastruktury.“ „Zájem České republiky pak představuje zachování její ústavnosti, svrchovanosti a územní celistvosti, zajištění vnitřního pořádku a bezpečnosti, mezinárodních závazků a obrany, ochrana ekonomiky a ochrana života nebo zdraví fyzických osob.“ Druhou definici kritické infrastruktury definuje Ministerstvo vnitřní bezpečnosti Spojených států amerických v dokumentu Blueprint for a Secure Cyber Future: The Cybersecurity Strategy for the Homeland Security Enterprise [26]. V dokumentu je nejprve následujícím způsobem podrobně popsán pojem kritická informační infrastruktura. „Any physical or virtual information system that controls, processes, transmits, receives or stores electronic information in any form including data, voice or video that is: 1) Vital to the functioning of critical infrastructure; 2) So vital to the United States that the incapacity or destruction of such systems would have a debilitating impact on national security, national economic security, or national public health or safety; or 3) Owned or operated by or on behalf of a State, local, tribal, or territorial government entity. (Adapted from the Administration’s cyber legislative proposal)“ V návaznosti na kritickou informační infrastrukturu je definován i vlastní pojem kritická infrastruktura. „Systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters. (42 U.S.C. §5195)“ Oproti těmto dvěma poměrně podrobným definicím obsažených ve věcném záměru Zákona o kybernetické bezpečnosti a v dokumentu amerického Ministerstva vnitřní bezpečnosti předkládá Evropská agentura pro informační a síťovou bezpečnost (ENISA) velmi stručnou definici popisující kritickou informační infrastrukturu [21] jako: „The systems, services, networks and infrastructures that form a vital part of a nation’s economy and society, providing essential goods and services. Their disruption or destruction would have a serious impact on vital societal functions.“ Pro další využití v rámci této technické zprávy a také celého projektu byla vybrána definice kritické infrastruktury společně se všemi souvisejícími pojmy dle věcného záměru Zákona o kybernetické bezpečnosti. Tato definice představuje na rozdíl od definice organizace ENISA velmi přesné určení pojmů a navíc je v podstatě obdobná s již používanou a také velmi dobrou definicí Ministerstva vnitřní bezpečnosti Spojených států amerických.


Strana 4/42


1.2

Výtisk č. 1

Hrozby pro kritickou informační infrastrukturu

Kritické informační infrastruktury čelí řadě bezpečnostních hrozeb. Úspěšné provedení útoku pomocí těchto hrozeb může představovat, z definice popisované oblasti, závažné škody a ohrožení organizace, státu nebo jeho obyvatel. V rámci průzkumu provedeného organizací ENISA, který byl publikován v dokumentu ENISA Threat Landscape: Responding to the Evolving Threat Environment [20], je popsáno několik typů hrozeb. Jedná se například o distribuované útoky odepřením služby, botnety, různé druhy průniků do systémů a další. Podrobněji je jim věnována kapitola 5. Mimo ně jsou v dokumentu uvedeny další faktory mající dopad na tuto oblast. Jedná se například o vznik pokročilých útočných nástrojů, rozdíly v úrovních vyspělosti a zabezpečení jednotlivých podsystémů, trend používání BYOD zařízení, politická nestabilita ohrožující funkčnost systémů a současná finanční krize vedoucí k nákupu levnějších a méně kvalitních zařízení. Tyto hrozby však nepůsobí pouze na klasickou infrastrukturu ve smyslu serverů a síťových zařízení. Stále častěji se útočníci zaměřují na průmyslové řídicí systémy jako je například SCADA. Z poslední doby lze zmínit mediálně známý útok čínské skupiny APT1 na vodárnu ve Spojených státech amerických, která se nakonec ukázala pouze pokročilou návnadou pro přilákání útočníků, takzvaným honeypotem [33]. Případ potvrzuje neutuchající zájem útočníků o napadání průmyslových řídicích systémů, který je podpořen faktem, že během 4 měsíců bylo 12 těchto systémů napadeno 74 útoky, kdy 10 z nich bylo dostatečně sofistikovaných pro ovládnutí celého systému v honeypotu [33]. Další případ známého útoku z poslední doby představuje napadení cílů na českém internetu v období 4. – 7. března 2013, který měl značný mediální dopad díky promyšlené strategii útoku. V první vlně došlo k dočasnému vyřazení stránek největších zpravodajských serverů a následně k odstavení významného vyhledávače. V druhé fázi útoku pak byly za dostatečné pozornosti médií napadeny stránky mobilních operátorů a bankovních institucí. V neposlední řadě je možné zmínit masivním útok představující napadení organizace Spamhaus a poskytovatelů jejího připojení, který hmatatelným způsobem zasáhl i peeringová centra ve světě [17].


Strana 5/42


2

Výtisk č. 1

Architektura Kybernetického polygonu

Architektura Kybernetického polygonu se sestává ze sady čtyř modulů představujících jednotlivé funkční části polygonu. Jedná se o hlavní modul správa scénářů a navázanou správu cloudu, správu měření a správu vizualizace, jejichž popis je uveden níže. Moduly samostatně řeší přidělenou oblast a komunikují spolu pomocí předávání zpráv, které představují konfigurační údaje, nebo vlastní data. Nástroj pro popis nastavení a činností v polygonu představuje takzvaný scénář. Scénář poskytuje prostor, jak pro motivaci a vlastní popis řešeného problému, tak i pro definici technických podrobností pro jednotlivé funkční části polygonu. ∙ Správa scénářů je řídicí modul Kybernetického polygonu, který vytváří a spravuje celkovou konfiguraci a její dílčí části předává dalším modulům k implementaci. Modul správy scénáře dále zpracovává příkazy uživatele ke změně konfigurace za běhu polygonu. ∙ Správa cloudu je modul, který vytváří a spravuje cloudové prostředí. Úkolem modulu je na základě konfigurace síťové topologie spouštět a zastavovat virtuální stroje a vytvářet mezi nimi síťovou infrastrukturu. Modul správy cloudu realizuje konfiguraci jednotlivých uzlů a konfiguraci síťové topologie, kterou také doplňuje. ∙ Správa měření je modul pro řízení měřicí infrastruktury, který nastavuje měřicí prvky a spouští měření. Modul správy měření čte konfiguraci síťové topologie a realizuje a doplňuje konfiguraci měřicí infrastruktury. ∙ Správa vizualizace je modul, který zajišťuje prezentaci síťové a logické topologie a vizualizaci dat získaných měřicí infrastrukturou. Modul správy vizualizací pracuje se všemi konfiguracemi, žádnou ale nedoplňuje. Detailnímu popisu modulů se věnují následující kapitoly. Správu cloudu popisuje kapitola 3, správou měření se zabývá kapitola 4 a správu vizualizace popisuje kapitola 6. Řídicím prvkem polygonu, kterým je správa scénářů, se zabývá kapitola 5. Ta mimo podrobného popisu a praktické ukázky na vzorovém scénáři obsahuje i příklady hrozeb pro kritickou informační infrastrukturu, které lze pomocí scénáře popsat. Konfigurační údaje představují pokyny pro implementaci parametrů scénáře jednotlivými moduly, které jsou mezi nimi předávány a doplňovány, až utvoří ucelený pohled na nastavení polygonu viz obrázek 2. Konfigurace je pak rozdělena do čtyřech níže popsaných částí definujících různé aspekty scénáře, od technické implementace a měření až po přiřazení rolí jednotlivým uzlům a vizualizaci průběhu scénáře pro uživatele. ∙ Konfigurace jednotlivých uzlů popisuje technické a programové vybavení a nastavení jednotlivých uzlů (virtuálních strojů). ∙ Konfigurace síťové topologie popisuje zapojení jednotlivých uzlů do sítě, síťovou infrastrukturu a směrování. Jednotlivým linkám a sítím je možné nastavit parametry jako přenosovou rychlost, ztrátovost a další. ∙ Konfigurace logické topologie popisuje role a vazby uzlů a sítí, například kdo je útočník a kdo oběť. Konfigurace dále popisuje logický průběh scénáře, tedy změny rolí a vazeb v čase či jako reakci na událost. ∙ Konfigurace měřicí infrastruktury popisuje rozmístění měřicích bodů, použité měřicí nástroje a výstupy z měření. Nástroje pro měření a zpracování dat je možné vybírat z předem definovaného seznamu měřitelných veličin a odvozených charakteristik.


Strana 6/42


Výtisk č. 1

Pro usnadnění konfigurace a tvorbu scénářů jsou dále k dispozici repozitář topologií, seznam obrazů virtuálních strojů a číselník měření. Jedná se o předpřipravené seznamy možných konfigurací, ze kterých je možné vybírat a případně seznamy rozšiřovat. Repozitář topologií obsahuje seznam výchozích síťových topologií, které mohou být použity ve více scénářích. Seznam obrazů virtuálních strojů obsahuje předpřipravené instance jednotlivých uzlů, které jsou připraveny k okamžitému použití. Číselník měření obsahuje seznam měřitelných veličin a odvozených charakteristik, ke kterým jsou v Kybernetickém polygonu připraveny nástroje pro měření, zpracování dat a vizualizaci.

2.1

Konfigurace Kybernetického polygonu

Základním prvkem konfigurace kybernetického polygonu je již dříve uvedený scénář. Na základě jeho popisu a nastavených parametrů probíhá vlastní příprava infrastruktury a realizace popsaného úkolu. Inicializace jednotlivých součástí polygonu a jejich nastavení je definována níže uvedeným seznamem kroků zahrnujících vytvoření jednotlivých dílčích konfigurací, jejich výměnu mezi moduly a přípravu realizace scénáře. Vzhledem k tomu, že se jedná o úvodní sestavení komponent polygonu dle popisu daného scénářem, není zde zachycena interakce s uživatelem ani změny konfigurace během provádění scénáře, které popisuje podkapitola věnovaná řízení scénářů. 1. Správa scénáře obdrží popis scénáře. 2. Správa scénáře na základě popisu scénáře vytvoří konfiguraci síťové topologie, konfiguraci logické topologie a konfiguraci měřicí infrastruktury. 3. Správa scénářů pošle konfiguraci síťové topologie správě cloudu. 4. Správa cloudu podle konfigurace síťové topologie vygeneruje síťovou infrastrukturu a částečně doplní konfiguraci síťové topologie (např. přidělené sítě, bránu, masku). 5. Správa cloudu pošle doplněnou konfiguraci síťové topologie správě scénářů. 6. Správa scénářů pošle doplněnou konfiguraci síťové topologie a konfiguraci měřicí infrastruktury správě měření. 7. Správa měření podle konfigurace měřicí infrastruktury nastaví měřicí infrastrukturu a doplní konfiguraci měřicí infrastruktury. 8. Správa měření pošle doplněnou konfiguraci měřicí infrastruktury správě scénářů. 9. Správa scénářů pošle konfiguraci logické topologie, doplněnou konfiguraci síťové topologie a doplněnou konfiguraci měřicí infrastruktury správě vizualizace. 10. Správa vizualizace podle konfigurace logické topologie, konfigurace síťové topologie a konfigurace měřicí infrastruktury nastaví nástroje pro vizualizaci. Po provedení výše uvedeného seznamu kroků je uživateli k dispozici připravené cloudové prostředí s nahraným scénářem. V rámci něj se může věnovat potřebným činnostem, případně provádět drobné úpravy konfigurace jednotlivých uzlů scénáře a infrastruktury. Nepředpokládá se však, že by běžný uživatel musel provádět tyto úkony, které jsou v kompetenci pokročilých uživatelů a správců.


Strana 7/42


Výtisk č. 1

Obrázek 2: Schéma konfigurace Kybernetického polygonu

2.2

Řízení scénářů

Řízení scénářů navazuje na konfiguraci Kybernetického polygonu a zabývá se řízením běhu scénáře, interakcí s uživatelem a dynamickými změnami konfigurace. Podobně jako řízení iniciální konfigurace i řízení scénářů spadá pod modul správy scénářů. Základní činností řízení scénářů je dohled nad průběhem celého scénáře. Průběh scénáře je číslovaný seznam kroků, které v obecné rovině určují, co se bude během scénáře odehrávat. Detailní popis jednotlivých kroků včetně jejich závislostí a příkazů předávaných jednotlivým uzlům se nazývá realizace scénáře. Realizace scénáře vzniká zápisem průběhu scénáře do strojově čitelné podoby, jednotlivé příkazy (kroky) jsou následně vykonávány modulem správy scénářů. Jednotlivé kroky mohou mít definované závislosti na předchozích krocích a podmínky, za kterých je vykonání kroku považováno za úspěšné. Ke každému kroku se ukládá čas jeho zahájení a dokončení pro pozdější anotaci výstupů z měření. Interakce s uživatelem probíhá formou prezentace aktuálního stavu Kybernetického polygonu a vykonávaného scénáře. Uživatel má možnost sledovat průběh scénáře v jednotlivých krocích doplněné o výstupy z měření. Uživatel může průběžně měnit konfiguraci scénáře, například přidávat a odebírat uzly a měřicí body nebo měnit parametry sítě. Dynamické změny konfigurace jsou v systému propagovány podobně jako počáteční konfigurace, provádí se však pouze požadované změny a není nutné rekonfigurovat celý systém.

2.3

Vyhodnocování scénářů

Vyhodnocování scénářů navazuje na provedení scénáře a zabývá se výstupy řízení scénáře, výstupy z měření a vizualizací získaných dat. Výstupem řízení scénáře je finální konfigurace zachycující realizaci scénáře v Kybernetickém polygonu včetně historie změn a záznamy o provedení jednotlivých kroků průběhu scénáře. Na výslednou konfiguraci polygonu a výstupy měření navazuje vizualizace dat. Podkladem pro vizualizaci je síťová topologie, výstupy měření a logická topologie. Na základě těchto vstupů je možné vytvořit podrobný obraz emulovaného prostředí tak, jak bylo realizováno. Díky záznamům o průběhu scénáře a výstupům z měření je možné zpětně sledovat, co se během scénáře odehrávalo. Řízení scénáře ukládá časy zahájení a dokončení jednotlivých kroků, které slouží


Strana 8/42


Výtisk č. 1

k anotaci naměřených dat a umožňují rychlou orientaci v průběhu scénáře.

2.4

Fungování Kybernetického polygonu z pohledu uživatelů

Obrázek 3: Přehledový diagram případů užití Kybernetického polygonu

Obrázek 3 zobrazuje celkovou funkcionalitu Kybernetického polygonu z vnějšího uživatelského pohledu. Systém se skládá z následujících případů užití: ∙ Vytvoření bezpečnostního scénáře: Uživatel nejprve nadefinuje bezpečnostní scénář, viz kapitola 5. Bezpečnostní scénáře budou zadány a uloženy v systému v podobě strukturovaného textu. K dispozici budou šablony typických scénářů. Později zle funkcionality rozšířit o další funkce zjednodušující tento iniciální krok, např. o přesné definování topologie pomocí interaktivních map síťové infrastruktury. ∙ Příprava Kybernetického polygonu: Na základě uživatelem definovaného bezpečnostního scénáře bude vytvořena kompletní konfigurace virtuálního prostředí, tj. konfigurace jednotlivých uzlů, síťové topologie, logické topologie a měřicí infrastruktury. Na základě této konfigurace bude připraveno virtuální prostředí Kybernetického polygonu. ∙ Realizace bezpečnostního scénáře: Jakmile je připraveno virtuální prostředí Kybernetického polygonu, lze spustit bezpečnostní scénář, a to buď na základě pokynu uživatele (stisknutím tlačítka v aplikaci), nebo v předem stanovený čas. Naměřená data budou přímo k dispozici a zároveň ukládána do databáze pro další analýzu. ∙ Online monitorování a vizualizace: V průběhu vykonávání bezpečnostního scénáře bude mít uživatel k dispozici přehled o aktuálním dění v polygonu. K dispozici budou aktuální údaje o síťové topologii (aktuální vytížení linek apod.), statistické údaje, data z detekčních algoritmů, ale i speciální vizualizace s ohledem na spuštěný typ bezpečnostního scénáře. Kromě aktuálních dat bude během běžícího experimentu k dispozici i uložená data. Lze se tedy přesunout na časové ose zpět. Podrobnosti viz následující případ užití. Projekt Kybernetický polygon – VG20132015103

Strana 9/42


Výtisk č. 1

∙ Offline monitorování a vizualizace: Tento případ užití slouží k přehrání dat naměřených během vykonávání bezpečnostního scénáře, a to samostatně po skončení experimentu, nebo v průběhu experimentu. K dispozici bude časová osa, která umožní nastavit požadovaný časový okamžik nebo úsek a znovu analyzovat stav Kybernetického polygonu.


Strana 10/42


3

Výtisk č. 1

Simulace infrastruktury

Pro simulaci bezpečnostních scénářů je nutné disponovat prostředím, ve kterém lze scénáře kontrolovaně spouštět, řídit a získávat z nich monitorovací data. V současné době existuje několik prostředí, které jsou přímo určeny pro simulaci bezpečnostních scénářů. Mezi nejznámější se řadí DETER [8] a TWISC [11], které využívají infrastrukturu Emulab/Netbed [39] poskytující základní funkce pro spouštění virtuálních strojů, konfiguraci sítí a emulaci síťových charakteristik. Projekt Emulab usnadňuje většinu operací spojených s realizací bezpečnostních scénářů, má však několik zásadních omezení jako je možnost využívat pouze protokol IPv4 a omezení na operační systém a samotný hardware, nad kterým Emulab běží. Existují i prostředí, která vyžadují kompletně vlastní infrastrukturu. Například ViSe [7], LVC [37] a V-NetLab [15] jsou spustitelné pouze na platformě VMware, další vyžadují pouze KVM hypervisor, apod. Tato řešení se vyznačují nižšími počátečními požadavky na nasazení, na druhou stranu jsou často finančně náročná a mají omezenou flexibilitu v rozšiřování.

3.1

Požadavky na infrastrukturu

Z předchozí kapitoly vyplynuly požadavky, které musí infrastruktura splňovat, aby bylo možné spouštět různorodé bezpečnostní scénáře a získávat z nich kompletní monitorovací data. Pro přehlednost jsme požadavky rozdělili do pěti kategorií: síťové, hostové, monitorovací, řídicí a požadavky na nasazení. Umožnit simulovat libovolnou síťovou topologii, ať už se jedná o samotný stroj nebo několik sítí propojených mezi sebou, je bezpodmínečný síťový požadavek. Infrastruktura musí uživateli umožnit mít plnou kontrolu nad třetí síťovou vrstvou (Layer 3) ISO/OSI modelu. Tato vlastnost, která není dostupná ve většině infrastruktur, které jsme měli možnost vyzkoušet, je klíčová pro simulaci libovolného protokolu třetí vrstvy, libovolného adresního schématu či přímo simulaci veřejných IP adres v řízeném a uzavřeném prostředí. Abychom přiblížili simulované prostředí co nejvíce realitě, je nutné podporovat modifikaci charakteristik sítě. Simulovat sítě typu ADSL nebo mobilní sítě znamená umět omezit datový tok, pracovat se zpožděním, ztrátovostí a chybovostí linek. Všechny bezpečnostní scénáře nebude možné simulovat čistě v uzavřeném prostředí, ale bude nutné umožnit komunikaci do reálného Internetu. Jako příklad může sloužit monitorování komunikace úmyslně napadeného počítače s řídicím serverem v Internetu. Tento druh provozu bude muset být pečlivě filtrován za použití firewallů. Infrastruktura musí být dostatečně flexibilní, aby bylo možné simulovat stroje s běžnými operačními systémy, konkrétně Linux a MS Windows jak v 32-bitové, tak v 64-bitové verzi. Samozřejmostí je poskytování monitorovacích dat o síťovém provozu mezi libovolnými dvěma uzly, které jsou spojeny virtuální sítí. Data jsou ve formátu síťových toků, případně v podobě plnohodnotných paketů. Kromě monitorování sítě by měla infrastruktura umožnit monitorování strojů, např. vytížení CPU. Monitorování musí být realizováno transparentně, aby nebylo detekovatelné a neovlivňovalo výsledná data z měření průběhu scénáře. Aby bylo možné sledovat scénáře, případně ovlivňovat jejich průběh, infrastruktura bude vybavena řídicí vrstvou, přes kterou půjdou ovládat jednotlivé komponenty infrastruktury. Rozhraní vystavené uživatelům musí být dostatečně jednoduché a obecné, aby nebyl uživatel nucen znát interní součásti infrastruktury. Stejně tak vytvoření a spuštění bezpečnostního scénáře nesmí být složité, naopak musí být intuitivní. Část rozhraní bude ovládat scénář za běhu, aby byl uživatel schopen řídit např. útok či obranu v reálném čase. Další nezbytná vlastnost opakovaného spouštění scénáře bude využívána především pro ladění a vyhodnocování konkrétních detekčních mechanismů. Infrastruktura nesmí po cloudovém prostředí vyžadovat žádnou speciální vlastnost, která je použitelná pouze v konkrétním cloudovém prostředí. Používání běžných příkazů/vlastností cloudového prostředí zajistí přenositelnost mezi různými poskytovateli cloudů. Projekt Kybernetický polygon – VG20132015103

Strana 11/42


Výtisk č. 1

Shrneme-li si požadavky na infrastrukturu spolu s vlastnostmi cloudových prostředí, dojdeme k závěru, že využití cloudů jako prostředku pro vybudování virtuální infrastruktury umožňujícího simulovat síťovou vrstvu i samotné stroje, je vhodné řešení. Infrastruktura může být poskytována jako Infrastructure as a Service (IaaS), kdy si tento typ služeb získává poslední dobou velikou popularitu. Pokud využijeme obecná cloudová programová rozhraní, lze pak KYPO nasazovat/migrovat mezi různé poskytovatele cloudových služeb podle aktuálních potřeb. Tento přístup má ale svá úskalí, kdy obecné rozhraní nemusí poskytovat dostatečnou flexibilitu pro konfiguraci síťování, my však přicházíme s novým přístupem, který tento problém řeší.

3.2

Navržené řešení

Navržené řešení je postaveno nad cloudem, který poskytuje abstraktní vrstvu skrývající problematiku správy virtuálních strojů a umožňuje dynamicky reagovat na požadavky týkající se výkonu a počtu virtuálních strojů. Každý bezpečnostní scénář je v cloudu spouštěn v uzavřené prostředí (sandboxu), kde mohou být útoky spuštěny bez obav z ovlivnění zbytku infrastruktury. Celý sandbox je spuštěn v cloudu a skládá se výhradně z virtuálních strojů. Kybernetický polygon dovoluje uživatelům vytvářet libovolný počet virtuálních prostředí pro provádění paralelních simulací. Každé vytvořené virtuální prostředí má dedikovaný řídicí uzel (Scenario Management Node), který se stará o sestavení daného prostředí. Řídicí uzel slouží jako vstupní bod do virtuálního prostředí a poskytuje doplňkové služby, jako jsou kolektory pro monitorování síťového provozu, apod. Stroje ve virtuálním prostředí jsou spojeny virtuální sítí. Budování takového virtuální sítě nad cloudem přináší jistá omezení, co se týče topologií, L3 adresování a možnosti používání L3 protokolů, se kterými jsme se museli vypořádat. Jelikož nechceme být závislí na konkrétním cloudovém prostředí, nevyužili jsme žádnou z funkcí, které nabízí vrstva, nad kterou běží cloudové prostředí. Pro budování síťových linek mezi virtuálními stroji s volitelnými vlastnostmi a s možností kompletního monitoringu jsme museli využít nástrojů, které poskytují běžně dostupné cloudy. Abychom toho dosáhli, vytvořili jsme koncept LAN Management Node (LMN), který zajišťuje abstrakci LAN sítě v KYPO. LMN uzly jsou virtuální stroje, na kterých běží standardní operační systém se softwarovým přepínačem (v našem případě se jedná o implementaci Open vSwitch [27]) a je vybaven několika síťovými rozhraními. Každé z rozhraní je spojeno s dalším virtuálním strojem nebo s tzv. routing node (viz obrázek 1). Spojení mezi virtuálním strojem a LMN je realizováno na úrovni sítě L2 (VLAN), jedná se o iluzi virtuálního kabelu mezi každým uzlem a virtuálním switchem. Každé jednotlivé spojení má vlastní VLAN identifikátor, které je unikátní přes celý polygon, tím je zabezpečena plná izolace jednotlivých linek. Díky zpracování veškerého síťového provozu na L2 síťové vrstvě, umožňujeme uživateli mít plně pod vlastní kontrolou celou síťovou vrstvu L3. Použití LMN uzlů přináší i další výhody, jelikož veškerý datový tok prochází přes LMN uzel, je zde možné provádět detailní monitorování, emulování vlastností jednotlivých linek (např. omezení datového toku, ztráty paketů). Jak je vidět na obrázku 4, LMN uzly mohou být vybaveny dalšími službami jako je DHCP server nebo firewaly. Pokud jsou v bezpečnostním scénáři nadefinovány různé sítě, které jsou spolu spojeny, je nutné nasadit směrovací uzel (Routing Node). Kromě směrování tento uzel umožňuje provádět filtrování provozu mezi sítěmi. Stejně jako LMN i směrovací uzel monitoruje datové toky mezi jednotlivými sítěmi. KYPO ke každému scénáři vytváří i tzv. řídicí síť, která je pro sítě definované ve scénáři transparentní. Řídicí síť je určena pro komunikaci s LMN, směrovacím uzlem a řídicím uzlem scénáře. Zároveň se po této sítí přenášejí monitorovací data, aby nebyl ovlivněn datový tok v rámci scénáře. V první fázi KYPO jsme se rozhodli nevybavovat každý virtuální stroj rozhraním do řídicí sítě, aby případné útoky mířící na všechny rozhraní napadeného stroje nekončily i v řídicí síti. Místo toho využijeme vlastnost cloudů, kde je poskytován vzdálený přístup ke konzoli virtuálního stroje. Abychom dostáli požadavkům na monitoring bezpečnostních scénářů, je v KYPU nasazeno Projekt Kybernetický polygon – VG20132015103

Strana 12/42

Výtisk č. 1

Open vSwitch

DHCP


Firewall Management Měření Síťová sonda Síťový provoz

WAN Naměřená data Management data

Obrázek 4: Schéma LAN Management Node

mnoho monitorovacích sond. Jedná se jednak o sondy na monitorování síťového provozu, ale i na monitoring samotných virtuálních strojů. Tyto sondy jsou nedílnou součástí každého bezpečnostního scénáře. Monitorování sítě se skládá z množiny sond, jednotek na zpracování monitorovaných dat a databáze, více o monitorování v následující kapitole. Sondy jsou umisťovány na konkrétní pozorovací místa. Abychom získali nejpřesnější informace, sondy jsou umisťovány na LMN uzlu, viz obrázek 4. Sondy jsou do sítí bezpečnostního scénáře připojeny přes zrcadlící port (SPAN) virtuálního switche. Tento způsob zapojení nám dává možnost sledovat nejen datové toky směřující ven a dovnitř sítě LAN, ale také monitorovat komunikaci uvnitř LAN sítě. Získaná data jsou exportována přes řídicí síť do jednotek na zpracování dat, které jsou umístěny v řídicím uzlu scénáře. Monitorování virtuálních strojů umožňuje získávat data o využití procesoru, paměti, počtu otevřených spojení a mnoho dalších charakteristik vztahujících se k běžícímu stroji. Část řídicí vrstvy v KYPO, která se stará o řízení cloudu poskytuje nástroje pro příkazovou řádku. Příkazy jsou navrženy, aby skryly vnitřní strukturu cloudů a uživatel se mohl věnovat simulacím bezpečnostních incidentů. Například KYPO nabízí jednoduchý příkaz pro spojení virtuálních počítačů do sítě, existence LMN, směrovacího a řídicího uzlu, řídicí sítě a nastavení monitorovacích sond je před uživatelem plně skryta. Prototypová implementace KYPO byla vyvinuta pro cloud, který je řízen softwarem OpenNebula [19] a využívá jeho nástroje pro příkazovou řádku. Tyto nástroje poskytují základní funkčnost, která je dostupná i v jiných softwarech pro řízení cloudu, proto je principiálně jednoduché přejít na jiný software pro řízení cloudů. Pilot KYPO je provozován nad cloudem poskytovaným Masarykovou universitou a sdružením CESNET (český NREN operátor). V současné době KYPO využívá několik hardwarových strojů, které umožňují simulovat prostředí s několika nezávislými LAN sítěmi, kde každá obsahuje několik uzlů. Pokud vznikne požadavek na zvýšení počtu uzlů v některé ze sítí, jednoduše se počet navýší přes rozhraní cloudu, které je na toto koncipováno.


Strana 13/42


4

Výtisk č. 1

Měření a analýza provozu

Následující text se věnuje měření dat v Kybernetickém polygonu a možnostem jejich vyhodnocení. Je popsána problematika monitorování síťových infrastruktur, definice jednotlivých částí měřicí infrastruktury a jsou vysvětleny jejich funkce. Dále je ukázána implementace monitorovací infrastruktury do Kybernetického polygonu a popsán proces sběru dat. Jsou rozebrána naměřená data, jejich informační hodnota a možnosti jejich využití pro detekci útoků a anomálií.

4.1

Měřicí infrastruktura

Základ měřicí infrastruktury tvoří nástroje, které mají za úkol získávat relevantní data z polygonu pro další zpracování. Množina všech využívaných měřicích nástrojů tvoří měřicí infrastrukturu. Je třeba rozlišovat mezi měřicí infrastrukturou sítě, která je rozmístěna na jednotlivých spojeních a měří výhradně síťový provoz, a měřicí infrastrukturou stanic, která je umístěna na jednotlivých strojích a měří výhradně provoz a stav daného stroje. V případě, že mluvíme pouze o měřicí infrastruktuře, máme na mysli jak měřicí infrastrukturu sítě, tak měřicí infrastrukturu stanic. 4.1.1

Měřicí infrastruktura sítě

Množina všech monitorovacích nástrojů, které slouží k měření síťového provozu, se nazývá měřicí infrastruktura sítě. Monitorování síťových toků je velmi rozšířená metoda pro monitorování síťového provozu. Tato metoda je založená na agregaci informací ze záhlaví jednotlivých paketů v síti. Obvykle jeden tok představuje jedno spojení mezi dvěma komunikujícími zařízeními. Díky vysoké úrovni agregace dat je metoda vhodná i pro kritické systémy, na které je kladena vysoká zátěž. Nevýhodou metody sledování síťových toků je absence informací obsažených v paketech samotných. Tyto informace je možné získávat pomocí metod hloubkové analýzy paketů. Propustnost zpracování datového toku těmito metodami závisí na množství informací, které je nutno získat. Pokud je množství zpracovávaných informací příliš vysoké, je nutno kombinovat tuto metodu se zachytáváním provozu, který je v surové podobě ukládán pro další zpracování. Zachytávání celého provozu je vhodné zejména pro forenzní analýzu, kde je nutno získat o komunikujících aplikacích co nejvíce informací. Vzhledem k vysoké zátěži, kterou zachytávání celého síťového provozu klade především na diskovou kapacitu je vhodné, aby byl ukládán pouze relevantní provoz. Terminologie monitorování síťových toků definuje popis měřicí infrastruktury [30]. Tuto terminologii můžeme upravit a použít i pro popis měřicí infrastruktury Kybernetického polygonu (viz obrázek 5). Ta se skládá z následujících částí:

IP Zdrojová a cílová IP adresa Zdrojový a cílový port Protokol Doba trvání Počet bytů Počet paketů TCP příznaky Ostatní

X

FI

IPFIX

Kolektor

Analýza dat

Obrázek 5: Schéma měřicí architektury


Strana 14/42


Výtisk č. 1

∙ Pozorovací bod (Observation Point) je místo v síti, na kterém je pozorován síťový provoz. Příkladem pozorovacího bodu je port nebo skupina portů směrovače či přepínače. Množina více pozorovacích bodů tvoří Doménu pozorování (Observation Domain). ∙ Měřicí sonda (Metering Probe) je zařízení, které je schopné monitorovat provoz v daném pozorovacím bodě. Jeho úkolem je nepřetržité měření provozu a získávání požadovaných informací. Měřicí sondy mohou být softwarové, nebo mohou využívat podpory hardwaru pro rychlejší zpracování dat. Pokud sonda generuje síťové toky, obvykle je pomocí exportního procesu posílá na kolektor. Surová data ze sítě se naopak ukládají přímo na sondě, jelikož jejich množství je příliš velké pro efektivní okamžitý přenos po síti na kolektor. Data získaná pomocí metod hloubkové analýzy paketů lze odesílat na kolektor nebo ukládat lokálně. ∙ Kolektor (Collector) je zařízení, které přijímá a dále zpracovává data odeslaná sondami. Jeden kolektor je schopen přijímat data z více sond. Hlavní funkcí kolektoru je agregace a uložení dat získaných ze sond. Nad uloženými daty potom počítají statistické a detekční metody, které slouží k vyhodnocení provozu v síti a vyhledávání možných útoků. Data jsou již na sondě označena časovými značkami, díky kterým je možné přesně určit čas a dobu trvání každé komunikace. 4.1.2

Měřicí infrastruktura stanic

Množina všech monitorovacích nástrojů, které slouží k měření stavu dané stanice, se nazývá Měřicí infrastruktura stanic. Infrastruktura sbírá informace o aktuálním stavu jednotlivých stanic. Je možné monitorovat například využití procesoru, paměti a disku. Měřicí infrastruktura stanic se skládá z následujících částí: ∙ Hlavní uzel (Master Node) je proces, který řídí podřízené uzly, získává od nich aktuální informace a stará se o jejich vyhodnocení a uložení. Současně také poskytuje rozhraní pro přístup k těmto informacím. Pokud při vyhodnocení nastane některá ze sledovaných událostí, umí na ni upozornit. Hlavní uzel je v monitorovací infrastruktuře stanic obvykle jeden. ∙ Podřízený uzel (Child Node) je proces, který běží přímo na monitorovaném zařízení. Z tohoto zařízení získává informace o jeho stavu a předává je hlavnímu uzlu k dalšímu zpracování. 4.1.3

Návrh implementace měřicí infrastruktury v Kybernetickém polygonu

Implementace měřicí infrastruktury v Kybernetickém polygonu má svá specifika. Proto byl sestaven seznam požadavků, které by měla měřicí infrastruktura polygonu splňovat: ∙ Je nutné dosáhnout flexibilní měřicí infrastruktury. V běžných případech je monitorovací infrastruktura vybudována na předem známé síti a je navržena speciálně pro danou síť. V případě polygonu jsou ovšem typ, topologie a vlastnosti monitorované sítě proměnlivé a mezi jednotlivými scénáři se liší. Proto je nutné navrhnout dostatečně dynamickou měřicí infrastrukturu, která bude schopná monitorovat různé varianty síťových topologií. ∙ V souvislosti s flexibilní měřicí infrastrukturou je nutné zajistit jednoduchou a jednoznačnou konfiguraci jednotlivých částí infrastruktury. ∙ Aby bylo možné monitorovat jakoukoliv část Kybernetického polygonu a získávat co nejvíce informací musí mít měřicí infrastruktura dostatečnou hustotu pozorovacích bodů.


Strana 15/42


Výtisk č. 1

∙ Monitorovací infrastruktura musí být schopna uložit a zpracovat požadované množství dat za čas. Na základě identifikovaných požadavků a výše popsaných obecných principů je měřicí infrastruktura v Kybernetickém polygonu implementována následujícím způsobem: Měřicí infrastruktura sítě vychází z implementace síťové infrastruktury v Kybernetickém polygonu. Pro přenos měřených dat je využita řídicí síť určená pro správu scénáře. Díky tomu je eliminován vliv měřicí infrastruktury sítě na probíhající scénář. Specifikace infrastruktury měřicí sítě musí popisovat umístění pozorovacích bodů, typ měřicích sond a kolektoru. Jednotlivé scénáře umožňují uživateli definovat, které stanice a síťové propoje mají být monitorovány. Pozorovací bod pro monitorování stanic a tedy i vnitřního provozu v síti, kde se tyto stanice nachází je umístěn na uzlu starajícím se o správu dané sítě. Tento pozorovací bod obsahuje jednu měřicí sondu, která sbírá data o provozu všech pozorovaných stanic v síti. Síťové propoje jsou monitorovány na centrálním směrovači, přes který teče všechen síťový provoz scénáře. Díky tomu je možné monitorovat každé spojení mezi sítěmi pomocí jednoho pozorovacího bodu na směrovači. Na směrovači tedy poběží tolik měřicích sond, kolik bude monitorovaných linek. Každý pozorovací bod obsahuje jednu měřicí sondu, která sbírá data o provozu všech pozorovaných stanic v dané síti a agregovaná data posílá na kolektor. Zároveň může tato sonda sbírat i surová data přímo ze sítě pro potřeby následné analýzy. Data získaná pomocí hloubkové analýzy paketů jsou doplněna do síťových toků a předána kolektoru. Kolektor je umístěn v řídicí síti a je součástí řídicí infrastruktury. Data z kolektoru jsou po vyhodnocení a předzpracování předávána do relační databáze, odkud jsou zpřístupněna pro vizualizaci. Tato data jsou opatřena časovými značkami, které umožňují přehrát průběh scénáře přímo z této databáze. Existuje celá řada měřicích sond, ať už softwarových, nebo hardwarových. Nejrozšířenějším zdrojem dat o síťových tocích jsou směrovače a přepínače společnosti Cisco. Ostatní výrobci síťových zařízení poskytují vlastní implementace měřicích sond. V projektu Kybernetického polygonu budou použity softwarové sondy, protože jsou vhodnější pro variabilní zapojení monitorovaných scénářů. To ale nebrání zapojení hardwarové sondy v případě specifických požadavků konkrétního scénáře. Proběhne výběr vhodné sondy na základě požadavků na výkon, podporované funkce a rozšiřitelnost. Zároveň ponecháváme rozhraní pro zapojení sondy dostatečně obecné, aby bylo možné v případě potřeby tuto sondu nahradit. Pro přenos dat ze sondy na kolektor je použit protokol IPFIX (IP Flow Information Export) [12], který je aktivně vyvíjen jako otevřený internetový standard. Protokol je dostatečně variabilní a umožňuje přenášet uživatelsky definované položky proměnné délky, díky čemuž ho lze použít pro export každého typu informace. Jako kolektor byl zvolen IPFIXcol, který je vyvíjen sdružením CESNET a který je zaměřen primárně na podporu protokolu IPFIX. Výhodou tohoto kolektoru je systém zásuvných modulů, které umožňují volitelně rozšiřovat způsob ukládání a zpracování dat. Konfigurace jednotlivých uzlů měřicí infrastruktury je součástí scénáře a je řízena správou scénářů. Variabilita měřených veličin je zajištěna pomocí možnosti rozšíření jak měřicí sondy tak transportního protokolu o další monitorované veličiny. Díky tomu je možné monitorovat různé vnější projevy scénářů. Měřicí infrastruktura stanic rovněž využívá řídicí síť pro přenos dat. Hlavní uzel je umístěn na kolektoru, který se stará o sběr dat z celé monitorovací infrastruktury. Prostředí Kybernetického polygonu umožňuje použití dvou typů podřízených uzlů. První typ je přímo součástí softwarového vybavení monitorované stanice. To umožňuje sledovat širokou škálu informací o daném systému, ale monitorovací proces může zasahovat do běhu stanice a tím i do průběhu scénáře. Tento problém řeší druhý typ podřízeného uzlu. Ten běží na hostitelském systému, ve kterém je virtualizována sledovaná stanice. Díky tomu monitorování přímo neovlivňuje Projekt Kybernetický polygon – VG20132015103

Strana 16/42


Výtisk č. 1

stanici. Nevýhodou tohoto přístupu je omezení vlastností, které je takto možno sledovat na množinu informací, kterou poskytuje hostitel virtuálního stroje. Existuje řada nástrojů pro sledování stanic. Mezi nejznámější patří Zabbix (www.zabbix.com), Nagios (www.nagios.org), Cacti (www.cacti.net) a Munin (munin-monitoring.org). V Kybernetickém polygonu vybereme vhodné nástroje v závislosti na platformě monitorované stanice a požadavků uživatele. Na kolektoru se data přenášejí z hlavního uzlu do databáze, ze které jsou data vizualizovná.

4.2

Analýza dat

Data získaná pomocí měřicí infrastruktury je potřeba dále zpracovat a vytěžit informace v nich obsažené. Následující text představuje základní popis a charakteristiky naměřených dat. Jsou ukázány metody, které slouží k získání informací a souvislostí v měřených datech. 4.2.1

Charakteristika dat

Data o síťovém provozu jsou sbírána pomocí protokolu IPFIX. Díky tomu je jejich struktura poměrně jednoduchá. Každý záznam obsahuje informace o jednom síťovém toku. Tok je jednoznačně identifikován komunikujícími stranami, použitým protokolem a časovými značkami začátku a konce toku. Typické informace, které sonda o jednom toku poskytuje, jsou ukázány v tabulce 1. Položka

Hodnota

Zdrojová IP adresa Cílová IP adresa IP protokol Zdrojový port Cílový port Počet bytů Počet paketů Začátek toku Konec toku

192.168.1.1 192.168.1.100 TCP 54684 80 2568 5 2013-07-19 09:58:53.799 2013-07-19 09:59:05.156

Tabulka 1: Příklad síťového toku ve formátu IPFIX. Obvykle jsou záznamy doplněné o další položky, které poskytují podrobnější informace o toku. Takto je možné přidat informace z aplikačních protokolů, například HTTP nebo DNS. Příklad položek pro HTTP dotaz uvádí tabulka 2. Protokol IPFIX umožňuje připojit k toku i část dat přenášených v paketech. To může být využito při forenzní analýze provozu. Položka

Hodnota

HTTP metoda Host URI Referer

GET www.muni.cz /general/about http://www.google.cz/url?sa=t&rct=j&q=www. muni.cz%2Fgeneral%2Fabout&source=web Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)

User-Agent

Tabulka 2: Příklad položek pro HTTP dotaz. Položky Referer a User-Agent jsou zkráceny.


Strana 17/42


Výtisk č. 1

Data z koncových stanic jsou podobného charakteru. Místo komunikace však jeden záznam zachycuje aktuální stav stanice v čase. Musí tedy obsahovat identifikátor stanice, časovou značku a seznam hodnot měřených položek. Příklad položek měřených na koncové stanici ukazuje tabulka 3. Jelikož jsou všechny položky zaznamenávány v čase, je možné sledovat vývoj jejich hodnot a podle toho vyhodnocovat chování celého systému. Položka

Hodnota

IP adresa stroje Využitá RAM paměť (MB) Využití procesoru (%) Obsazené místo na disku (MB) Čas

192.168.1.1 768 51 36845 2013-07-19 09:59:05.156

Tabulka 3: Příklad položek měřených na koncové stanici. 4.2.2

Metody analýzy dat

Síťový provoz je možné analyzovat z různých hledisek. Je možné zaměřit se například na management sítě, kvalitu síťových služeb, či bezpečnost. V rámci Kybernetického polygonu se budeme zabývat především bezpečnostní analýzou. Cílem bezpečnostní analýzy je včas detekovat útoky, či anomálie síťového provozu. Útok je množina akcí, jejichž účel je poškodit oběť. Naproti tomu anomálie je změna oproti přirozenému řádu. Útok se tedy může projevit jako anomálie, ale každá anomálie nemusí nutně znamenat útok (např. velké zálohování dat způsobí anomálii síťového provozu, ale nejedná se o útok). Při analýze dat je potřeba důrazně rozlišovat mezi detekcí útoku a detekcí anomálie. Při konkrétním útoku je systém napaden pomocí již známé množiny operací. Množinu operací je tedy třeba vyhledat v datech. Zatímco při detekci anomálie není známo, co přesně hledáme. Je potřeba najít odchylky od normálního stavu, které je potřeba dále analyzovat a zjistit jejich příčinu. Detekci anomálií je možné využít pří odhalování nových, dříve nepoužitých druhů útoků. V průběhu posledního desetiletí byla vyvinuta řada detekčních metod pro detekci anomálií nebo útoků v síťovém provozu. Vyčerpávající přehled je možné najít v [16] - Kapitola 5: Strategie analýzy: Detekce zneužití vs. detekce anomálií), další přehled detekčních metod založených na síťových tocích poskytuje [32]. Jedná se ovšem z velké části o teoretické práce ověřované na malém objemu testovacích dat (případně na simulovaných datech). Ve zprávě jsou tedy uvedeny pouze některé metody, které byly v rámci Automatických detekčních systémů nasazeny pro monitorování sítí. Budování profilů chování je hlavní detekční metodou inteligentního profilování síťových zařízení. Profily chování jsou budovány na třech úrovních z hlediska komplexnosti profilů. Na nejnižší úrovni jsou profily budovány přímo na kolektorech (vymezení dané množiny zájmu pomocí základních filtrů, např.: verze protokolu, IP adresa, port, . . . ), střední úroveň tvoří základní profily chování získané z IPFIX dat (je možné získat charakteristiky jako počet komunikačních partnerů, objem příchozího/odchozího provozu, objem příchozího/odchozího provozu, . . . ) a na nejvyšší úrovni se nalézají pokročilé profily chování, které je možné získat pokročilými technologiemi. Tyto technologie jsou schopny rozlišit servery a klienty v síti a je možné určit následující složky profilů chování. Složka počet komunikačních partnerů obsahuje například statistiky o počtu unikátních IP adres, na které byl vyslán požadavek a získána odpověď, počet unikátních IP adres, na které byl vyslán požadavek, který zůstal bez odpovědi a jiné. Další složky profilů chování, jako objemy přenesených dat, druhy provozu (dělící se dále na strukturu klientského provozu, strukturu serverového provozu a strukturu provozu bez odpoProjekt Kybernetický polygon – VG20132015103

Strana 18/42


Výtisk č. 1

Obrázek 6: Holt-Wintersova predikce časových řad (𝛼 = 0.5, 𝛽 = 0.5) vědí) jsou tvořeny podobným způsobem. Metoda budování profilů slouží k uchování základních charakteristik různých proměnných provozu za určitou časovou jednotku. Odchylky od takto získaného profilu chování jsou potom považovány jako anomálie. Profily chování je možné v běžné bezpečnostní praxi využít na odhalování serverů s nežádoucím obsahem a pro mapování sítě, které poskytne rychlý přehled o zařízeních v síti. Sledované anomálie se týkají objemu provozu (detekce útoku vedeného z předmětného počítače na běžící i neběžící služby), počtu komunikačních partnerů (možné k detekci instalace botu do PC, rozesílání nevyžádané pošty, DDoS útoky, slovníkové útoky). Profily chování pro jednotlivé IP adresy lze interpretovat jako časové řady, neboť se jedná se o posloupnost hodnot změřených v jednotlivých dnech. V rámci automatizovaného zpracování profilů chování s cílem detekovat anomálie mohou na tyto profily chování aplikovány vybrané metody analýzy časových řad klouzavý průměr nebo Holt-Wintersova metoda. Holt-Winters predikce časových řad. Jedná se v o metodu trojitého exponenciálního vyhlazování, která je schopná modelovat časové řady obsahující trend i sezónnost a v průběhu času se řadám přizpůsobovat. [10] Algoritmus se snaží rozdělit modelovanou časovou řadu na tři základní části: ∙ Úroveň: 𝑎𝑡 = 𝛼(𝑦𝑡 − 𝑐𝑡−𝑚 ) + (1 − 𝛼)(𝑎𝑡−1 + 𝑏𝑡−1 ) ∙ Lineární trend: 𝑏𝑡 = 𝛽(𝑎𝑡 − 𝑎𝑡−1 ) + (1 − 𝛽)𝑏𝑡−1 ∙ Sezónní trend: 𝑐𝑡 = 𝛾(𝑦𝑡 − 𝑎𝑡 ) + (1 − 𝛾)𝑐𝑡−𝑚 Predikce je potom 𝑦^𝑡+1 = 𝑎𝑡 + 𝑏𝑡 + 𝑐𝑡+1−𝑚 kde 𝑚 je délka sezóny. Pokud jsou hodnoty 0 < 𝛼, 𝛽, 𝛾 < 1 blízko k 0, proces vykazuje pomalou adaptaci, zatímco pokud jsou blízko k hodnotě 1, proces se adaptuje téměř okamžitě a vliv historie je velmi malý. Algoritmus odhaduje odchylku v daném čase 𝑑𝑡 = 𝛾|𝑦𝑡 − 𝑦^𝑡 | + (1 − 𝛾)𝑑𝑡−𝑚 , z které se následně vypočítá interval spolehlivosti (^ 𝑦𝑡 ± 𝛿 · 𝑑𝑡−𝑚 ). V modelu je možné nastavit délku okna a prahovou hodnotu. Je sledován počet pozorování ležící mimo interval spolehlivosti v daném okně, a pokud počet překročí prahovou hodnotu, je pozorování vyhodnoceno jako anomální. Systém je schopen upozornit na bezpečnostní rizika jako horizontální a vertikální skenování a slovníkový útok na SSH. Počty nahlášených událostí jsou přitom stále poměrně vysoké a zabývat se podrobně každou nahlášenou událostí podrobně by bylo časově náročné. Stejně jako v předchozím případě, systém pouze dává informaci, že ve sledované charakteristice došlo v daný čas k anomální události. Obsahem a vyhodnocením anomální události se však dále nezabývá. Projekt Kybernetický polygon – VG20132015103

Strana 19/42


Výtisk č. 1

Local outlier factor (LOF): Outlier je podle pozorování, které se liší od ostatních natolik, že vyvstává podezření, že byl generován odlišným mechanismem. Algoritmus LOF zachycuje na základě lokální hustoty relativní stupeň izolace daného prvku. Pro prvky uvnitř clusteru nabývá LOF hodnoty přibližně jedna, zatímco prvky ležící mimo clustery, osamoceně mají hodnoty LOF vyšší [22].

Obrázek 7: Vizualizace LOF outlierů. LOF algoritmus je následně spuštěn na IPFIX datech, u kterých jsou sledovány různé proměnné: počet toků z dané IP, počet toků směrem k danému cíli, počet toků ze stejného portu k danému cíli a počet toků z daného zdroje do stejných portů. Předpokladem pro úspěšnou detekci anomálie je, že bude v následném zobrazení ležet odděleně od normálního provozu a bude mít vysoké LOF. Honeypot je nástroj, který lze využít pro detekci útoků a anomálií. Honeypot funguje na principu síťových pastí. Jedná se o systémy, jejichž hodnota spočívá v nedovoleném nebo neoprávněném užití [29], jejich účelem je přilákání útočníka a následná analýza útoku. Z definice plyne, že jakýkoliv pokus o kontaktování honeypotu je potenciálně nebezpečný, čehož je možné využít pro detekci anomálií v síťovém provozu. Využití honeypotů jako detekčních nástrojů sebou nese malé množství falešných hlášení (false positives). Útok zachycený honeypotem je dále možné podrobně analyzovat, za tímto účelem bývají honeypoty vybaveny nástroji pro forenzní analýzu. Jako příklad dalšího výzkumu v detekci anomálního chování časových řad jsou uvedeny následující metody: Change Point Problem a Multivariate Time Series. Tyto metody by bylo možné použít pro další zpracování časových řad získaných v rámci behaviorální analýzy. Change point problem (CHPP) řeší, kdy nastal bod, kdy se změnil model generující časovou řadu. Takovýto bod je nazýván Change point(CHP). V rámci behaviorální analýzy by metoda mohla být využitá k detekci okamžiku, kdy byla oběť napadena škodlivým kódem (tzn. začala vykazovat jiné chování). Při řešení CHPP jsou rozlišovány dva přístupy: ∙ Retrospektivní (někdy také batch) – před začátkem analýzy jsou dostupná veškerá data, Change point je hledán zpětně. Tento přístup sám o sobě nemá velké využití v real-time sledování a analýze sítového toku, nicméně je používán v kombinaci s druhým přístupem (viz [25]). ∙ Sekvenční (orig: sequentional) – data přicházejí postupně, při každém novém pozorování je děláno rozhodnutí, zda nenastal Change point. Při tomto přístupu se poté odehrává obchod mezi mírou falešných poplachů a zpožděním detekce. Ideální model by měl co nejmenší


Strana 20/42


Výtisk č. 1

míru falešných poplach a co nejmenší zpoždění detekce. Existují dvě hlavní sekvenční metody detekce CHP: Page’s cumulative sum (CUSUM), která využívá metody maximální věrohodnosti, a Shiryaev-Roberts-Pollak detekční procedura, která využívá Bayesiánských metod. Tartakovsky [25] následně využil kombinaci obou postupů k detekci DOS a TCP útoků se znatelně rychlejší detekcí útoků než pomocí metod EWMA a Adaptive Threshold mechanismus při stejně velké míře falešných poplachů. Multivariate time series lze také využít pro detekci anomálií. Cílem detekce ve vícerozměrných časových řadách je odhalit časovou značku, pro kterou se naměřené hodnoty jedné nebo více proměnných výrazně liší od jejich „normálního“ chování. „Normální“ chování odpovídá očekávaným hodnotám časových řad, které vycházejí z jejich historie a současně ze vztahů s ostatními časovými řadami. Lze takto hledat jak obecné anomálie (tzn. všechny sledované časové řady mají stejný význam z hlediska detekce anomálií), tak specifické anomálie vyskytující se v dané časové řadě, která je korelována s vysvětlujícími časovými řadami. Je také možné hledat jak lokální tak globální anomálie. Základním prvkem detekčního algoritmu je měřítko podobnosti použité k určení, jak stejná jsou dvě pozorování. Je možné využít funkce: [︃ ∑︀𝑝

K(𝑖, 𝑗) = exp −

𝑘=1 (𝑥𝑘𝑖 − 𝜎2

𝑥𝑘𝑗 )2

]︃

kde 𝑝 je počet pozorovaných časových řad, 𝑖 a 𝑗 označují dvojici časových značek, 𝑥𝑘𝑖 je hodnota 𝑘 − 𝑡é časové řady v okamžiku 𝑖. Jádrová matice K(𝑖, 𝑗) je transformována do reprezentace váženého grafu 𝐺 = (𝑉, 𝐸), kde 𝑉 je množina uzlů a 𝐸 je množina všech hran. Každý uzel reprezentuje jednu časovou známku (případně jejich posloupnost) časové řady, zatímco hrana reprezentuje měřítko podobnosti z matice K(𝑖, 𝑗). Anomální uzel bude mít měřítko podobnosti nízké oproti ostatním. Tento přístup zahrnuje podobnost mezi jednotlivými časovými značkami, ale ne vztah mezi různými časovými řadami. 4.2.3

Implementace datové analýzy v Kybernetickém polygonu

Hlavní část datové analýzy bude probíhat na kolektoru, kde budou shromažďována data získaná ze sond. Metody budou využívány na základě definice scénáře. Ve scénáři budou uvedeny jak využité metody, tak měřené proměnné a výstupy zvolených metod. Získaná data jsou následně přeposílána do databáze, kde jsou uložena pro potřeby vizualizace. V případě účasti honeypotů při sběru dat pro analýzu je možné řešit jejich implementaci v Kybernetickém polygonu více způsoby. Přímo ve scénáři je možné definovat některé uzly jako honeypoty, tedy přiřadit jim roli honeypotu a vybavit je příslušnými detekčními nástroji, podle záměru scénáře. U větších síťových topologií je možné generovat honeypoty jako součást emulovaných sítí. Pomocí nízkointeraktivních honeypotů, např. honeyd [2], je možné emulovat celé sítě na jednom stroji.


Strana 21/42


5

Výtisk č. 1

Bezpečnostní scénáře

Následující text shrnuje vysokoúrovňový pohled na hrozby pro kritickou informační infrastrukturu. Je popsán vlastní bezpečnostní scénář a jeho faktické využití v Kybernetickém polygonu. Pro ilustraci problematiky byl vytvořen modelový scénář reálného distribuovaného útoku odepřením služby.

5.1

Seznam hrozeb pro kritickou informační infrastrukturu

Seznam hrozeb pro kritickou infrastrukturu vypracovaný ve shodě s dokumentem ENISA Threat Landscape: Responding to the Evolving Threat Environment [20] představuje stručný popis jednotlivých hrozeb, které mohou ovlivnit monitorovanou kritickou informační infrastrukturu a způsobit tak závažné škody. 5.1.1

Distribuované útoky odepřením služby

Distribuované útoky odepřením služby (DDoS) jsou využívány pro napadání služeb, strojů a infrastruktur za účelem zamezení přístupu k nim pro legitimní uživatele. Jejich nebezpečnost spočívá hlavně ve skutečnosti, že jsou v podstatě nerozlišitelné od běžného provozu. Přímým dopadem této hrozby je vždy nedostupnost napadené infrastruktury nebo služby, která zpravidla sama odezní po ukončení útoku. Ovšem i takovéto zablokování může představovat u kritické informační infrastruktury rozsáhlé finanční ztráty, případně další následky. Dobře provedený útok většího rozsahu tohoto typu představuje útok na české novinové servery, internetový vyhledávač, stránky bankovních institucí a mobilních operátorů z období 4. – 7. 3. 2013 [24], které mimo webových stránek znepřístupnily také další služby jako elektronický nákup jízdenek, některé elektronické platby a platební terminály [28]. Dalším masivním útokem pak bylo napadení organizace Spamhaus a jejich poskytovatelů konektivity [17]. Pro svůj dobře viditelný dopad je tento typ útoku často používán různými skupinami pro získávání pozornosti a propagaci svých názorů. Jako příklad lze uvést napadení webových stránek organizace OSA a Vlády České republiky [36]. 5.1.2

Botnety

Botnety představují skupiny počítačů (zombie), které byly nakaženy škodlivým kódem a nyní tvoří síť řízenou kontrolním (C&C) centrem a využívanou k rozesílání spamu, krádežím citlivých informací a provádění DDoS útoků. Strojový čas botnetů stejně jako jimi získané informace jsou komoditou na černém trhu a přinášejí majitelům botnetů nemalé finanční zisky. Existence stroje zapojeného do botnetu v kritické informační infrastruktuře znamená zásadní hrozbu pro její bezpečnost z několika důvodů. Prvním je, že takovýto stroj slouží jako předsunutý bod pro zkoumání sítě a v ní zapojených strojů nejen pro vlastní šíření, ale také pro hledání případných citlivých informací. Druhým důvodem je konzumace netriviálního množství výpočetního času a kapacity linky pro nelegitimní účely. Mezi další pak může patřit například nepřímé zavlečení organizace, kde se nakažený stroj nachází do trestné činnosti. 5.1.3

Napadení a průnik do systémů

Šíření červů a trojských koní Červi a trojské koně představují skupinu škodlivého kódu mezi počítači za účelem získání nepovoleného přístupu k systému, nebo krádeže citlivých informací z napadeného stroje. Často představují první krok útoku, kdy otevírají systém pro další nástroje. Základním rozdílem je mezi těmito přístupy je fakt, že trojský kůň představuje program se skrytou funkcionalitou instalovaný uživatele a červ představuje kód schopný samostatného šíření počítačovou sítí za využívání zranitelnosti stroje oběti.


Strana 22/42


Výtisk č. 1

Exploity Exploity představují programy využívající zranitelnosti představované neodhalenými chybami v programu, nebo systému programátorem a umožňující neoprávněnou instalaci software, případně přímé ovládnutí napadeného stroje. Tyto programy jsou skládány do sad (exploit kit) a často využívají ke svému šíření techniky sociálního inženýrství anebo drive-by download. Při této technice dochází k nahrání exploitu skrze skrytou stránku v napadené webové prezentaci. Injektace kódu Injektování kódu představuje způsob nahrání škodlivého kódu do systému pomocí jeho zaslání na nedostatečně ošetřený vstup. Následkem této akce jsou tato nevalidní data, představující škodlivý kód systémem načtena a provedena. I když jsou vůči tomuto útoku typicky zranitelné webové aplikace, obětí se může teoreticky stát každý systém zpracovávající vstupy z vnějšího světa. Výskyt kteréhokoliv z výše uvedených kódů v systému má zvláště u strojů přímo zapojených do kritické informační infrastruktury velmi zásadní dopad vzhledem k výše uvedeným cílům, které plní. Dochází ke kompromitaci stojů obsahujících důležitá data a zamoření infrastruktury, které se může snadno vymknout kontrole. 5.1.4

Phishingové útoky

Phishing představuje svým primárním zacílením na uživatele dlouhodobou hrozbu pro informační bezpečnost nejen kritických informačních infrastruktur. Základní myšlenkou těchto útoků je odesílání emailů s žádostí o zaslání přihlašovacích údajů zpět útočníkovi, nebo instalaci jeho škodlivého kódu, který umožní přístup do systémů organizace. Dopady této hrozby se dramaticky liší dle času, který proběhl mezi útokem a jeho odhalením. Pokud bezpečnostní opatření zareagují dostatečně včas, pak je jediným problémem nutnost změny přihlašovacích údajů u obětí útoku. Delší dobu neřešené útoky však mohou vyústit v rozsáhlou kompromitaci infrastruktury, které si vyžádají při svém odstranění mnoho času a finančních prostředků. Příkladem takového útoku v českých podmínkách jsou phishingy na bankovní instituce [23] včetně útoku na Českou spořitelnu [38]. 5.1.5

Kompromitace utajovaných informací

Kompromitace utajovaných informací v systémech kritické infrastruktury může být dosaženo mnoha způsoby. V kontextu této zprávy a projektu jsou však za takovéto útoky považovány snahy o přímé dolování dat z databáze pomocí technik využívajících injektování SQL dotazů do nedostatečně zabezpečené databáze, případně útoky na uživatelská data zadávaná přes prohlížeč pomocí využití chyb ve skriptech webových stránek a techniky perzistentního anebo neperzistentního Cross-site scriptingu. Důsledkem úspěšné realizace útoku je přímo neautorizovaný přístup, odcizení, nebo zničení utajovaných informací nalézajících se v napadeném systému, či některých jeho subsystémech. 5.1.6

Cílené útoky (APT a spearphishing)

Cílené útoky představují specifickou skupinu hrozeb, kde se útočníci snaží proniknout do konkrétních vybraných organizací, aby zde v tichosti sbírali citlivá data a informace. Tyto hrozby jsou také někdy nazývány Advanced Persistent Threats (APT) dle jejich vysoké složitosti a náročnosti na znalosti a zdroje útočníka. Proto jsou většinou doménou organizovaných skupin s napojením na organizovaný zločin, nebo vlády různých států [31]. Jedním z příkladů útoku realizujícího tyto hrozby je například spearphishing, kde se útočník pokouší získat přihlašovací údaje uživatelů, nebo nainstalovat škodlivý kód na jejich stanice. Může se jednat o samostatný útok za účelem získání přístupu například k bankovní aplikaci, nebo snaha o průnik do informační infrastruktury organizace za účelem získání informací, jejich zničení, zanesení škodlivého kódu, případně jiné škodlivé činnosti.


Strana 23/42


Výtisk č. 1

Nejčastějším důsledkem úspěšných útoků tohoto typu je nepozorovaný únik citlivých informací k útočníkovi, který je sbírá a zpracovává pro své potřeby, případně je může dále využívat pro pokračování svého útoku. Vzhledem k rozsáhlosti problematiky APT jsou v projektu KYPO zachyceny pouze některé specifické části. Jedná se především o přístup k citlivým informacím a cílený phishing (spearphishing), který představuje úpravu klasického phishingového útoku na míru napadané organizaci. 5.1.7

Fyzické útoky

Poslední velkou oblastí ohrožující kritickou informační infrastrukturu jsou útoky proti fyzické bezpečnosti. Může se zde jedna o možnost krádeže nebo ztráty zařízení obsahujícího citlivé informace. Také se může jednat o záměrné poškození, nebo zničení zařízení potřebného pro funkčnost kritické informační infrastruktury. Tyto hrozby dále nabývají na síle s rozšiřováním mobilních zařízení jako jsou chytré telefony a tablety. Vzhledem k jejich snadné přenosnosti zde představuje zajištění fyzické bezpečnosti zásadnější problém než u serverů a obdobných zařízení. Fyzické útoky mohou způsobit dle svého provedení únik citlivých informací ohrožujících bezpečnost organizace nebo státu, nebo mohou vést k nedostupnosti kritické informační infrastruktury v případě zničení důležitého zařízení. Vzhledem k tomu, že tyto hrozby spadají do oblasti fyzické bezpečnosti a bezpečnostních politik, nebude jim v projektu dále věnována pozornost.

5.2

Obecný scénář pro Kybernetický polygon

V následující kapitole je popsána myšlenka bezpečnostního scénáře, který je určen pro standardizaci popisu akcí a komponent takovým způsobem, aby bylo možné vytvořit jasnou komunikaci a vzájemné pochopení mezi zadavatelem, osobami plánujícími scénář a jeho implementačním týmem. 5.2.1

Klíčové pojmy

Scénáře obsahují pojmy, pro jejichž jednoznačné pochopení mezi uživateli je vytvořen následující jednoduchý slovník. Scénář definuje vlastní náplň práce Kybernetického polygonu. Jedná se o popis akcí, komponent a prostředí vytvořený pro co nejvěrnější modelování části reality. Skládá se z popisné části, kde se nachází motivace a vysvětlení celého scénáře, jednotlivých variant scénáře a z technické části zachycující nezbytně nutné informace pro jeho realizaci jako jsou uzly, topologie a vlastní průběh. Pokud je scénář správně vytvořen a popsán, měl by být dostatečně srozumitelný pro různé okruhy uživatelů. Varianta scénáře popisuje možné proveditelné odchylky scénáře. Varianty sdílí hlavní cíl, motivaci a popis. Mohou se ale odlišovat například umístěním měřicích prvků v síti, počtem zainteresovaných strojů a přesným provedením útoku. Uzel představuje jeden konkrétní kus hardware definovaný ve scénáři. Tyto lze rozdělit dle typu na mobilní zařízení, PC s klasickým operačním systémem, zařízení zajišťující síť (směrovače, přepínače) nebo prvek měřicí infrastruktury (NetFlow/IPFIX sonda). Dále je možné definovat software včetně operačního systému, který běží na těchto uzlech. Topologie realizovaná schématem s doplňujícím poznámkami zobrazuje rozmístění uzlů, sítí a jejich role ve scénáři. Podrobněji je pak dělena na topologii síťovou a logickou.


Strana 24/42


Výtisk č. 1

Průběh scénáře popisuje v obecné rovině číslovaným seznamem kroků, co konkrétně se bude po dobu běhu scénáře odehrávat. Realizace scénáře určuje jednotlivé po sobě následující kroky scénáře nejdetailnějším možným způsobem včetně konkrétních volání programů a předávaných příkazů. Vnější projevy scénáře představují množinu pozorovatelných efektů vzniklých realizací scénáře. Z nich jsou pomocí měřicí infrastruktury získávána data, která jsou vstupem pro interpretaci a vizualizaci. 5.2.2

Konfigurace uzlů

Konfigurace uzlů definuje vlastnosti všech zařízení, které jsou zapojeny do scénáře. Součástí každého scénáře je seznam všech použitých uzlů, doplněný o jejich základní konfiguraci a potřebný počet instancí konkrétního uzlu. Podle konfigurace jsou vytvořeny jednotlivé uzly v prostředí infrastruktury cloudu. Konfigurace se zaměřuje na čtyři oblasti, které definují každý uzel. Logická role uzlu určuje základní funkci uzlu. Při iniciální konfiguraci je znalost role potřebná pro správné přidělení uzlu v rámci sítě polygonu. Role například definuje je-li uzel útočník, oběť nebo jde o zařízení, které simuluje běžného uživatele. Hardware popisuje vlastnosti, které jsou dostatečné pro splnění dané logické role uzlu. Je nutné uvést počet procesorů, velikost operační paměti a počet síťových rozhraní. Tyto vlastnosti jsou využity při vytvoření virtuálního uzlu v prostředí cloudu. Operační systém definuje verzi použitého operačního systému. Je možné definovat obecně použitý systém např. Windows, případně pokud to scénář vyžaduje je možné uvést konkrétní verzi. Základní verze nejrozšířenějších operačních systému jsou k dispozici v seznamu obrazů. Software definuje sadu nástrojů, které jsou použité během útoku nebo je proti nim útok veden. Software není součástí předpřipravených obrazů jednotlivých operačních systému, ale je operativně doinstalován po startu systému. 5.2.3

Síťová topologie

Síťová topologie popisuje vlastní rozložení počítačové sítě spojující uzly ve scénáři. Jsou zde zachyceny veškeré technické podrobnosti, jako jsou IP adresy jednotlivých strojů, rozsahy sítí, jejich směrování další. V rámci topologie jsou pak definovány tři základní položky jejich kombinací lze získat počítačovou síť scénáře. Sítě poskytují vlastní prostředí pro propojování jednotlivých uzlů a realizaci většiny scénářů. Ve své podstatě odpovídají běžnému chápání počítačové sítě. Kybernetický polygon umožňuje u sítí volitelně nastavovat jejich CIDR rozsah, kvalitu sítě (rychlost, ztrátovost) a umístění monitorovací infrastruktury. Pro připojení, případně modelování Internetu je rezervován název sítě Internet. Uzly představují z pohledu síťové topologie jednotlivé stroje nastavené dle specifikace uzlů. Ze síťového pohledu je u nich možné konfigurovat jedno až několik rozhraní zabezpečujících připojení do sítí a mající parametry: kvalitu připojení do sítě (rychlost, ztrátovost), volitelně konkrétní IPv4/IPv6 adresu a volitelně MAC adresu.


Strana 25/42


Výtisk č. 1

Směrování sítí popisuje navzájem propojené dvojice sítí. Pokud je síť definována bez uzlů, pak tvoří (páteřní) linku mezi na ni se připojujícími sítěmi. V těchto sítích je možné nastavovat jejich kvalitu (rychlost, ztrátovost), firewall a fakt, zde je zde umístěno monitorovací zařízení. 5.2.4

Logická topologie

Logická topologie představuje rozřazení rolí uzlům a sítím ve scénáři a jejich změny v čase. Typicky se jedná o role jako je oběť a útočník, kde uzel může v čase zastávat maximálně jednu roli. Dále lze uzly a sítě přiřazovat najednou do několika skupin představujících organizaci (například univerzita, technologická síť, produkční síť). Je ovšem také možné, aby uzel zůstal bez přiřazené role, pokud se jedná například o síťové prvky. Naopak každý uzel musí příslušet do jedné ze skupin definovaných ve scénáři. Tato část scénáře je pak předávána správě měření a správě vizualizací k dalšímu zpracování. Položky představující uzly a síť jsou shodné s těmi v síťové topologii, kterým přidávají navíc logickou vrstvu představující výše popsané role a vazby jednotlivých uzlů a členství ve skupinách. Nově definovanou položku představuje průběh scénáře, který zachycuje změny stavu rolí a skupin jednotlivých uzlů v logickém čase. 5.2.5

Konfigurace měřicí infrastruktury

Konfigurace měřicí infrastruktury navazuje na vnější projevy scénáře a definuje měření těchto jevů, vlastní měřicí uzly, jejich typ a umístění. Měření je z pohledu měřicí infrastruktury chápáno jako určitý proces zjišťování hodnoty měřené veličiny (zadána správou scénářů) vnějšího projevu v měřicím bodě, který je určen správou scénářů pomocí identifikátoru uzlu. Ze zjištěných dat je pak možné vytvořit odvozenou charakteristiku popsanou ve scénáři. Každé měření je prováděno dle jedné z číselníkem definované detekční metody. Měřicí uzel představuje vlastní stroj, případně proces, používaný pro monitorování vnějších projevů scénáře. V rámci uzlu je pak možné zvolit jeho typ a měřicí software (sonda a flowmonexp, kolektor a IPFIX, monitor výkonu uzlu atd.). Další nastavení pak představuje IP adresa měřicího uzlu, IP adresa kolektoru pro sondy, rozhraní SPAN a WAN monitorované sondami. Měřicím uzlům je také možné dodávat doplňující informace pro sondy (granularita měření a timeout), které jsou definovány ve scénáři.

5.3

Scénář útoku distribuovaného odepření služby

Pro praktickou ukázku zapracování útoku do formy scénáře, byl zvolen reálný útok z roku 2012. Jednalo se o distribuované odepření služby webového serveru tzv. Distributed Denial of Service (DDoS). Vytvořený scénář se drží bodů uvedených v kapitole 5. V první části předkládá stručný popis události, na základě které je scénář modelován. Následuje návod pro vytvoření modelu sítě a útoku v prostředí Kybernetického polygonu. Části věnované vlastní realizaci scénáře a jeho vyhodnocení budou uvedeny ve zprávě věnované pilotnímu bezpečnostnímu scénáři. Popis scénáře Scénář je založen na útoku, který proběhl v roce 2012. Jednotlivec nebo malá skupina útočníků, disponující jednotkami útočících uzlů napadla webový server. Záplava HTTP dotazů vyčerpala v poměrně krátké době všechny dostupné zdroje serveru a ten se stal nedostupným pro jeho legitimní uživatele. Útok byl proveden pomocí veřejně dostupného nástroje Low Orbit Ion Cannon (LOIC), který je zneužíván k provádění útoků formou TCP SYN záplavy nebo zahlcení web serveru HTTP požadavky na existující nebo neexistující stránky. Dle taxonomie [18] šlo o polo-automatizovaný Projekt Kybernetický polygon – VG20132015103

Strana 26/42


Výtisk č. 1

útok hrubou silou při kterém jednotlivé útočící uzly komunikují nepřímo s využitím validních zdrojových adres. Útok byl koordinován s využitím konstantní množiny útočících uzlů. Tento typ útoku je velmi jednoduchý na provedení a nevyžaduje prakticky žádné pokročilé znalosti od uživatelů jednotlivých počítačů zapojených do útoku. Použitý nástroj proto využívala například skupina Annonymous k provádění útoků s řádově tisíci zapojenými boty. Pro scénář byla zvolena varianta Hive Mind LOIC [35], kterou je možné ovládat vzdáleně. Logická topologie Logická topologie scénáře je rozdělena na dva celky – vnitřní síť a vnější síť (viz obrázek 8). Vnitřní síť představuje síť organizace, která je připojena pomocí jednoho páteřního směrovače. V této síti se nachází oběť útoku a případně další uživatelské uzly, které vytváří na pozadí šum běžné sítě. Šum pro tento scénář představuje přehrání IPFIX záznamu, zachyceného na reálné síti, přímo na kolektoru IPFIX dat. Druhou síť nazýváme vnější síť. Jedná se o několik sítí s rozdílnou adresací. Z nich bude přicházet provoz útoku, tak aby nebylo možné určit pouze jednu podsíť, ze které útok přichází.

www

Bot

Bot

Bot

Vnitřníšsíť

#irc

Master

Bot

Vnějšíšsíť Útočník Běžnýšuživatel #irc

Běžnýšprovoz Útokššššššššššššš IRCškomunikace

IRCšserver

www

Cílšútoku Monitorování

Obrázek 8: Logická topologie DDoS scénáře

Specifikace použitých uzlů V rámci scénáře je nutné definovat jednotlivé uzly potřebné pro simulaci útoku, které jsou představovány čtyřmi typy uzlů: ∙ Cíl útoku – Jedná se o web server, na který bude prováděn útok. Byl zvolen linuxový operační systém doplněný o webový server Apache ve verzi 2.2.16. Uzel je připojen do vnitřní sítě, která je monitorovaná. IP adresa uzlu je vzhledem ke konfiguraci útočících nástrojů nastavena na statickou hodnotu 10.19.2.2. Uzel je možné nahradit vlastním nastavením bez nutnosti upravovat další části scénáře, pokud bude dodržena adresace. ∙ IRC server – Představuje server sloužící ke komunikaci jednotlivých uzlů zapojených do útoku (botů). Linuxový operační systém je doplněn o spuštěnou aplikaci IRCD-hybrid, která slouží jako IRC server. Uzel je připojen do vnější sítě (Master síť), kterou v tomto scénáři nemonitorujeme. Má staticky přidělenou IP adresu 10.19.1.2. ∙ Master – Jedná se o uzel sloužící k ovládání botů a představuje útočníka ovládajícího botnet. Uzel využívá linuxový operační systém a aplikaci irssi pro připojení k IRC serProjekt Kybernetický polygon – VG20132015103

Strana 27/42


Výtisk č. 1

veru. Uzel je připojen do vnější sítě (Master síť). K uzlu se přistupuje pomocí SSH pod uživatelským jménem root a heslem master. ∙ Bot – Je uzlem generujícím útok a ovládaným vzdáleně přes IRC. Využívá operační systém Windows 7 a aplikaci LOIC, která je ovládána pomocí příkazů zadávaných přes IRC. Z jednotlivých uzlů je vytvořen botnet, který se připojuje ve vnější síti do podsítí A, B a C. Po spuštění systému se aplikace automaticky připojí na IRC server do místnosti loic. Síťová topologie Scénář tvoří pět podsítí, kde všechny sítě mohou komunikovat mezi sebou. Výsledná topologie je tedy podobná hvězdě. Monitorovaná je však pouze komunikace, která vstupuje nebo vystupuje z vnitřní sítě. Vnitřní síť využívá adres z rozsahu 10.19.2.0/24 a je v ní připojen pouze cíl útoku. Master síť, obsahuje IRC server a Master uzel a přiděluje adresy z rozsahu 10.19.1.0/24. Útok přichází od jednotlivých uzlů zapojených do botnetu, které jsou připojeni ve vnější síti do třech podsítí – A, B a C. Adresace těchto podsítí je dynamická a může se při nové instanci scénáře změnit. Vnější projevy útoku Aplikační DDoS útok na web server je možné sledovat na třech úrovních. Na úrovni monitorování síťových toků je možné pozorovat změny v poměru počtu toků na jednu IP adresu, snížení variability provozu z pohledu velikosti toků a počtu přenesených paketů v rámci jednoho toku. Na aplikační úrovni lze například sledovat zvýšení počtu HTTP dotazů v průměru na jednu IP adresu a snížení počtu odpovědí se stavovým kódem 200 OK. Na úrovni hosta je možné pozorovat změny v počtu otevřených spojení na straně serveru, zvýšení nároků na výpočetní výkon, zvýšenou aktivitu při přístupech na disk. Tyto projevy slouží jako příklad a je možné je doplnit o další monitorování případně o komplexní detekční metody. Realizace útoku Útok je proveden pomocí nástroje Hive Mind LOIC [35] umístěného na několika uzlech v síti Internet vzdáleně ovládaných pomocí protokolu Internet Relay Chat (IRC). Po spuštění a konfiguraci všech uzlů tvořících páteř scénáře jsou spuštěny útočící uzly. Po svém spuštění se automaticky připojují na IRC server do místnosti loic. Zde je možné jim pomocí IRC klienta přistupujícího z Master uzlu nastavit jejich vlastnosti, spouštět a zastavovat vlastní útok. Řízení scénáře probíhá prostřednictvím IRC komunikace mezi Master uzlem a jednotlivými boty. Připojení Master uzlu je realizováno prostřednictvím nástroje irssi: # irssi -c 10.19.1.2 -n wolf -p 6668 -w wolf Aby bylo možné boty ovládat musí příkazy přijít od administrátora místnosti. Příkazy pro získaní práv a připojení do místnosti loic. ] /oper wolf wolf ] /join #loic Konfigurace nástroje LOIC je provedena příkazem: ] !kypo targetip=10.19.2.2 method=http port=80 timeout=80 subsite=/test/index.html threads=200 wait=false random=false speed=90 Start a zastavení útoku je proveden příkazem: ] !kypo start ] !kypo stop


Strana 28/42


Výtisk č. 1

V této podkapitole byl popsán jeden ze scénářů, který je vytvořen na základě reálně zaznamenaného útoku strukturovaného do podoby standardního popisu definovaného v podkapitole 5.2. Tento popis slouží jako podklad pro vytvoření iniciální konfigurace určené pro správu cloudu, měření a vizualizace. Realizace scénáře předáním iniciální konfigurace, vytvoření testovacího prostředí pro scénář, vizualizace a vyhodnocení scénáře je řešena v navazující technické zprávě popisující pilotní bezpečnostní scénář.


Strana 29/42


6

Výtisk č. 1

Vizualizace

Cílem vizualizačního modulu je poskytnout uživatelům nástroj, který jim umožní rychle a přehledně sledovat a vyhodnocovat bezpečnostní scénáře, případně odhalovat souvislosti, které nejsou ve velkém množství monitorovaných dat na první pohled patrné. K tomu je třeba navrhnout a vytvořit specifické vizualizace, které jdou nad rámec běžných statistických grafů či tabulkových přehledů, viz např. vizualizace DoS útoku na obrázku 9 podle [13], nebo vizualizace spamové kampaně na obrázku 10 podle [34].

Obrázek 9: Příklad vizualizace DoS útoku podle [13]

Obrázek 10: Příklad vizualizace spamové kampaně podle [34]

6.1

Vymezení základních požadavků na vizualizaci

Pro potřebu návrhu architektury vizualizační aplikace byly stanoveny následující funkční a nefunkční požadavky, které vymezují základní služby, definují technologická omezení kladená na systém a pojmenovávají možná rizika: 1. Hlavní funkcí aplikace je analýza konkrétních útoků. Cílem je srozumitelně a interaktivně zobrazit průběh bezpečnostního scénáře. Vizualizace budou navrhovány individuálně


Strana 30/42


Výtisk č. 1

s ohledem na charakteristiky konkrétních typů útoků a postupně budou integrovány do systému. 2. Systém umožní monitorování stavu infrastruktury Kybernetického polygonu. Cílem je zobrazení základních statistických údajů o síťové a softwarové infrastruktuře, např. zobrazení fyzické či logické topologie sítě, zobrazení statistických údajů virtuálního prostředí, provozních detailů síťových uzlů, atd. 3. Systém bude připraven na dodatečnou implementaci podpůrných procesů a integraci externích modulů. Architektura vizualizačního systému musí být navržena tak, aby umožňovala snadnou integraci dalších provozních služeb, které budou v první verzi systému realizovány externími nástroji nebo procesy. Jedná se např. o správu uživatelských účtů, GUI pro konfiguraci a správu infrastruktury Kybernetického polygonu, GUI pro konfiguraci a správu útoků, apod. Systém proto musí mít modulární strukturu založenou na softwarových komponentách. 4. Systém bude mít formu webové aplikace, která bude poskytovat svoji funkcionalitu odkudkoliv prostřednictvím běžných webových prohlížečů. 5. Bude kladen důraz na efektivitu, škálovatelnost, rozšiřitelnost a udržovatelnost systému. Protože se předpokládá zpracování a zobrazování velkého množství dynamických dat, je nutné dbát na to, aby v systému nevznikla úzká místa, která by degradovala celkový výkon, uživatelskou odezvu a uživatelský komfort, nebo která by vyžadovala extrémní nároky na hardwarové zdroje. 6. Vizualizace budou záviset na velkém množství provozních dat získaných v průběhu útoku. Protože je nereálné uchovávat a zpracovávat všechna provozní data z důvodu jejich množství, projdou měřená data procesem předzpracování, který odfiltruje nepotřebné informace, data agreguje a zredukuje tak jejich objem. Např. namísto všech záznamů o síťové komunikaci v podobě konkrétních paketů budou pro vizualizační potřeby k dispozici pouze počty paketů v pětiminutových intervalech, údaje o entropii apod. 7. Systém bude postaven na nekomerčních licencích. To se týká zejména použitých externích knihoven a dalších technologií. Z výše uvedených funkčních a nefunkčních požadavků vyplývá, že aplikace bude založena převážně na zobrazování dynamických statistických a topologických dat prostřednictvím webových prohlížečů. Dynamické renderování v prostředí webu se obecně skládá z několika provázaných částí či vrstev, jejichž správná kombinace velmi ovlivňuje efektivitu webové aplikace, její škálovatelnost, rozšiřitelnost a uživatelskou přívětivost. Proto byla volbě zobrazovacích technologií věnována zvýšená pozornost. Renderování grafických dat, tj. převod grafických primitiv na barvy pixelů, lze realizovat buďto na straně serveru, nebo na straně klienta (webového prohlížeče). Oba způsoby mají své výhody a nevýhody. Konkrétní volba pak velmi ovlivňuje možnou strukturu systému a použitelné technologie. Protože renderování je obecně velmi náročné na systémové zdroje, zejména CPU a GPU, byl zvolen přesun této výpočetní zátěže na klientská zařízení. Pro další stanovování architektury jsou brány v úvahu pouze technologie vhodné pro renderování na straně klienta. Tím se zamezí přetížení serveru a vzniku úzkého hrdla při zpracování většího množství dat. Nevýhodou může být to, že každé klientské zařízení má jiné hardwarové parametry a proto se rychlost a plynulost vykreslování může značně lišit klient od klienta. S tímto faktorem musí vizualizační systém počítat.


Strana 31/42


6.2

Výtisk č. 1

Front end – volba vizualizačních technologií na straně klienta

V prostředí webových aplikací existuje několik odlišných přístupů k renderování na straně klienta. Následující přehled obsahuje vlastnosti technologií, které byly při tvorbě architektury brány v úvahu: ∙ Adobe Flex. Velkou výhodou je stabilní a celkově velmi dobrý grafický výkon a plynulé animace i při velkém množství zobrazovaných dat díky optimalizaci pro různá zařízení. Nevýhodou je naopak to, že o renderování se stará zásuvný modul, který se musí nainstalovat do webového prohlížeče. Problém je rovněž s otevřeností kódu. Samotný Adobe Flex je sice poskytován zdarma i se zdrojovými kódy, většina nezbytných vývojových nástrojů je ale komerčních. ∙ Scalable Vector Graphics, SVG. Jedná se o vektorový grafický formát založený na XML a standardizovaný konsorciem W3C. O renderování se stará přímo prohlížeč. SVG je podporován všemi novějšími prohlížeči, navíc existuje mnoho knihoven a nástrojů, které s SVG pracují a jsou tedy použitelné pro projekt Kybernetického polygonu. Grafický výkon hodně závisí na webovém prohlížeči, viz např. [14] a rovněž naše testy v kapitole 6.2.2. Oproti Adobe Flex výkon výrazněji klesá přímo úměrně k množství zobrazovaných dat. ∙ WebGL. Relativně nová technologie, která se nicméně zdá být perspektivní. Jedná se o adaptaci OpenGL jazyka (využívá se např. pro tvorbu 3D počítačových her) do prostředí webu. O renderování se stará přímo prohlížeč, renderování probíhá na GPU. WebGL je podporováno všemi novějšími prohlížeči. Na rozdíl od předchozích technologií, WebGL je nízkoúrovňový jazyk určený primárně pro popis 3D scén (podobně jako samotné OpenGL). ∙ Java2D/Java3D Tyto specializované knihovny dokáží efektivně renderovat s použitím GPU, vyžadují ale podporu Javy. Hodí se tedy buďto na renderování na straně javového aplikačního serveru, nebo v rámci samostatných (standalone) klientů naprogramovaných v Javě. V případě použití ve webovém prohlížeči by byla nutná zapnutá podpora Javy v prohlížeči. SVG bylo vybráno jako optimální technologie. Jedná se o kompromis mezi dostatečným výkonem a širokou podporou napříč webovými prohlížeči, knihovnami i programovacími jazyky. Vizualizace tím sice bude omezena na 2D zobrazení, to ale nepředstavuje zásadní problém, protože v projektu KYPO by měly převažovat právě 2D vizualizace. Kromě toho, při volbě vhodného aplikačního rámce (viz dále) by mělo jít do budoucna zkombinovat SVG s WebGL do jedné aplikace a přidat tak případné 3D vizualizace. 6.2.1

Vizualizační knihovny s podporou SVG

Vizualizace bezpečnostních scénářů vyžaduje interaktivní přístup a dynamické zobrazování měnících se dat ve webovém prohlížeči. Nejběžnějším způsobem, jak takového chování dosáhnout, je použití JavaScriptu. V současné době existuje řada JavaScriptových knihoven pro práci s formátem SVG. Pro potřeby projektu jsme se zaměřili na specializované knihovny pro vizualizaci topologií a časových řad, protože tento typ dat bude v projektu dominantní. V následujícím přehledu jsou stručně popsány vlastnosti tří knihoven, které se z pohledu projektu jeví jako nejzajímavější: ∙ D3.js [1]. – Velká kolekce předdefinovaných vizualizací, velká variabilita vizualizací, viz obr. 11. – Deklarativní přístup řízený daty (data-driven approach). Poli dat a SVG elementům se přiřazují vizuální prvky, transformace apod. – Velmi kvalitní dokumentace. Projekt Kybernetický polygon – VG20132015103

Strana 32/42


Výtisk č. 1

– Uživatelské interakce jsou řešeny na úrovni běžného JavaScriptu. – Podporované formáty zdrojových dat: XMLHttpRequest, text file, HTML document fragment, XML document fragment, CSV, TSV, JSON blob. – Existence užitečných pluginů, např. fisheye. – Licence: BSD ∙ Highcharts [3]. – Na rozdíl od D3.js omezeno pouze na „klasické“ grafy (sloupcové, koláčové apod.). Hezký a propracovaný vzhled i chování, viz obrázek 12. – Podporované formáty zdrojových dat: CSV, XML, JSON. – Licence: volně pro nekomerční použití, jinak placené. V obou případech je k dispozici zdrojový kód. ∙ Raphaël [5]. – Obecná JavaScriptová knihovna pro SVG grafiku, tj. na nižší úrovni než D3.js nebo Highcharts. – Užitečné pro specifikaci vlastních speciálních grafických primitiv, pokud bude potřeba. – Licence: MIT

Obrázek 11: Možnosti vizualizací pomocí knihovny D3.js [1]

Obrázek 12: Možnosti vizualizací pomocí knihovny Highcharts [3]


Strana 33/42


6.2.2

Výtisk č. 1

Výkonnostní testy knihovny D3.js

Výběr renderovacích technologií byl založen na existujících výkonnostních testech a diskuzích. Pro ověření limitů a možností knihovny D3.js, která by měla být stěžejní součástí vizualizace na klientech, jsme navíc uskutečnili několik vlastních výkonnostních experimentů. Zátěžový test byl založen na animaci Brownova pohybu se změnou velikosti pohybujících se bodů. Test se zaměřuje na rychlost vykreslování v FPS pro různé webové prohlížeče. Testovány byly dvě varianty konfigurace. V základní variantě jsou všechny objekty (kruhy) vykreslovány černě. Zapnutím náhodného obarvování uzlů (druhá varianta experimentu) se při každém cyklu Brownova pohybu změní barva náhodného uzlu. To umožňuje simulovat interaktivitu (přebarvené uzly se musí znovu překreslit, což odpovídá interaktivní změně stavu uzlu). Některé varianty experimentu navíc obsahují více vizualizačních oken vykreslovaných současně. Pro testování byl použit notebook s operačním systémem Windows 7 64-bit, 16GB RAM, CPU Intel Core i53210M @ 2.50GHz a 128GB SSD diskem. Počet objektů na stránce 100 100 500 500 500 500 1000 1000 1000 1000 2500 2500 5000 5000 5000 5000 5000 5000 10000 10000

Počet objektů v okně 100 100 100 100 500 500 100 100 1000 1000 500 500 500 500 1000 1000 5000 5000 5000 5000

Počet oken 1 1 5 5 1 1 10 10 1 1 5 5 10 10 5 5 1 1 2 2

Obarvování objektů vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté vypnuté zapnuté

Chrome 28

Firefox 22

IE 10

60 fps 60 fps 59 fps 56 fps 57 fps 43 fps 31 fps 29 fps 29 fps 29 fps 21 fps 18 fps 14 fps 11 fps 14 fps 11 fps 11 fps 11 fps 7 fps 7 fps



Tabulka 4: Výsledky testu animace Brownova pohybu S jednorázovým vykreslením 10 000 objektů neměl problém žádný z prohlížečů. Experiment prokázal použitelnost této technologie pro vizualizace v rámci Kybernetického polygonu. Výsledky experimentu s dynamickou animací ukazuje tabulka 4. S animací si nejlépe poradil Google Chrome, naopak nejhorší výkon byl naměřen u prohlížeče Firefox. Klesající hodnoty FPS byly při testech přímo úměrné zvyšujícímu se počtu animovaných objektů. Rozdělení objektů do několika oken má naopak zanedbatelný vliv. Tento experiment ukázal limity jednotlivých prohlížečů, se kterými musí projekt počítat s ohledem na případné interaktivní a dynamické vizualizace.

6.3

Back end – volba aplikačního rámce

Úkolem webových aplikačních rámců (web application frameworks) je poskytnout prostředí pro snadný vývoj a integraci kompletních webových aplikací. Ve skutečnosti tedy nepokrývají pouze problematiku tvorby „back-endové“ části systému, ale i problematiku tvorby webových klientů. V současné době existuje nepřeberné množství rámců lišících se základním programovacím jazykem, na kterém jsou postaveny (Java, PHP, Perl, Scala, . . . ), zaměřením (content-management Projekt Kybernetický polygon – VG20132015103

Strana 34/42


Výtisk č. 1

systems, e-shops, mobile devices, . . . ), nabízenými vlastnostmi apod. Naopak společným jmenovatelem je obvykle podpora různých datových zdrojů a podpora ORM (Object-Rational Mapping), podpora Ajax, správa účtů a sezení, snadný návrh webových klientů a obecně znovupoužitelnost kódu. Pro volbu webového rámce projektu KYPO byla formulována následující základní kritéria: ∙ Snadná tvorba webových stránek. KYPO je do značné míry experimentální prostředí, které vyžaduje přizpůsobování uživatelského rozhraní vzhledem k bezpečnostním scénářům (analýza DoS útoku vyžaduje jiné informace než např. analýza chování červa), uživatelským rolím či účelu vizualizace (online vizualizace aktuálního stavu v síti vs. forenzní analýza). Proto musí být snadné přizpůsobit rozložení prvků ve webové aplikaci, vytvořit různé varianty, prototypy GUI apod. ∙ Snadné napojení na různorodé datové zdroje (relační databáze, podpora XML, JSON, atd.). Vizualizace bezpečnostních scénářů je založena na velkém množství dat získaných ze síťového prostředí. Proto je žádoucí mít možnost kombinovat zdroje dat za účelem jejich integrace, rozložení zátěže apod. ∙ Výkon a škálovatelnost. Již v úvodní analýze požadavků na vizualizační software byly detekovány výkonnostní požadavky jako jedna z nejdůležitějších vlastností a zároveň největších rizik. Vzhledem k tomu, že vykreslování bude prováděno pomocí JavaScriptových knihoven na straně klientů, neměla by mít volba webového rámce přímý vliv na výkon vykreslování. To, co může volba rámce značně ovlivnit, je rychlost zpracování dat aplikační logikou. Proto je žádoucí, aby byl vybraný webový rámec škálovatelný s možností alokovat další zdroje, rozložit běh na více hardwarových uzlů apod. ∙ Dynamická synchronizace pohledů. Vizualizace bezpečnostních scénářů vyžaduje mít několik interaktivních pohledů (okem v rámci webové stránky) reprezentujících různé pohledy na společná data. Tyto pohledy je nutné synchronizovat při každé změně dat způsobené interakcí uživatelů nebo vývojem experimentu ve virtuálním prostředí kybernetického polygonu. Aplikační rámec by měl takovouto synchronizaci podporovat a co nejvíce ulehčovat. ∙ Možnost integrace JavaScriptových vizualizačních knihoven. ∙ Otevřený zdrojový kód. Jednou z možných variant byl zvažován software NfSen [4]. Jedná se o grafickou nástavbu nástrojů NfDump, které slouží pro monitorování provozu sítě a které budou rovněž v projektu KYPO použity. NfSen umožňuje vizualizace statistik ve formě grafů generovaných pomocí knihovny RRDTools [6]. Umožňuje rovněž integraci dalších knihoven ve formě zásuvných modulů. Na první pohled se tedy použití této technologie jeví jako optimální a přirozené řešení. NfSen nicméně není aplikační rámec v pravém slova smyslu. Jedná se spíše o grafickou nástavbu bez podpory dalších obvyklých funkcí jako např. správy uživatelských účtů. Rovněž v současné době neexistuje distribuovaná architektura, která by umožňovala rozložit zátěž paralelně na více strojů a rozložit tak zátěž. Pro vytvoření komplexní vizualizační aplikace by proto nebyl NfSen příliš vhodný. Pro realizaci vizualizační aplikace v rámci projektu KYPO byla proto vybrána Javová technologie webových portálů, která je zaměřena na agregaci dat z různých zdrojů a jejich prezentaci jednotným způsobem na jednom místě. Tato technologie splňuje všechny výše popsané požadavky. Informace lze rozčlenit do adresářové struktury a zachytit tak vertikální i horizontální členění dat. Uživatelské prostředí se skládá z portletů, které zajišťují požadovanou funkcionalitu. Každý portlet tvoří komponentu, která se zaměřuje na plnění specifické kompaktní funkcionality. V případě projektu KYPO lze tedy portlety vnímat jako konkrétní vizualizační okna. Existuje velké Projekt Kybernetický polygon – VG20132015103

Strana 35/42


Výtisk č. 1

množství předpřipravených portletů, např. pro content-management systems, data-management systems, nebo online komunikaci. Vývoj nových portletů je možný buďto podle připravených šablon, nebo nezávisle např. s využitím vývojových rámců Spring, Hibernate apod. Portlety jsou obecně popsány specifikací JSR 168 (životní cyklus portletu, módy, stavy okna) a JSR 286 (komunikace mezi portlety, přímá komunikace s portletem). Při dodržení těchto specifikací mohou běžet v některém z existujících portálů, např. v komerčních systémech Jboss Portal, IBM Websphere Portal, či Microsoft Sharepoint. Pro vývoj webové aplikace v projektu KYPO byl vybrán portál Liferay, který má otevřené zdrojové kódy a který je na předních pozicích v používání. Liferay je vydáván pod licencí MIT.

6.4

Celková architektura vizualizační aplikace

Diagram nasazení na obrázku 13 zachycuje celkovou architekturu vizualizačního systému. Vizualizační aplikace je na diagramu zachycena v podobě komponenty Visualization Application běžící v prostředí Liferay Portal. K ní se připojují uživatelé prostřednictvím běžných webových prohlížečů. Data pro vizualizaci jsou získávána ze dvou zdrojů. Prvním zdrojem je virtuální síť kybernetického polygonu (uzel Cybernetic Polygon), která by měla prostřednictvím definovaného API poskytovat aktuální stav síťové infrastruktury, jako například stav síťových uzlů, vytíženost linek, apod. Druhým zdrojem jsou data naměřená z průběhu konkrétních bezpečnostních scénářů. Tato data jsou předzpracována a agregována, viz artefakt Monitoring and Preprocessing, a následně uložena v relační databázi.

Obrázek 13: Diagram nasazení vizualizační aplikace

Konfigurace na diagramu nasazení na obrázku 13 odráží iniciální plánovanou architekturu. Zvolené technologie nicméně umožňují snadnou změnu konfigurace zejména s ohledem na výkonnostní požadavky. Většina portálových systému včetně Liferay nabízí například možnost paralelního běhu aplikace na více serverech, a to transparentně. Vizualizační aplikace tak ve skutečnosti může běžet na více uzlech bez toho, aby se to nějak dotklo klientů, databázového serveru, nebo samotného virtuálního prostředí kybernetického polygonu. Webové portály rovněž podporují několik unifikovaných způsobů napojení na datové zdroje, zejména JDBC a Hibernate. To umožňuje snadno zaměnit MySQL za jinou relační databázi, nebo připojit více rozdílných datových zdrojů.


Strana 36/42


7

Výtisk č. 1

Závěr

V roce 2013 byl proveden návrh architektury Kybernetického polygonu. Na něj následně navázal vývoj základní verze polygonu. Je sestavena základní kostra infrastruktury v cloudovém prostředí a jsou zkoumány a vytvářeny aplikace pro konfiguraci, monitorování a vizualizaci dějů uvnitř polygonu. Důležitým cílem v roce 2013 je realizace pilotního scénáře, který umožní provést vlastní útok, změřit jeho vnější projevy a v omezené podobě je vizualizovat. V roce 2014 budou postupně přidávány více uživatelsky přívětivé způsoby konfigurace prostředí a bude probíhat vlastní návrh grafického uživatelského rozhraní. Na takto vylepšeném Kybernetickém polygonu budou realizovány nové scénáře z oblasti testování, forenzního auditu a především z okruhu hrozeb pro kritickou infrastrukturu. V posledním roce projektu (2015) bude prototyp Kybernetického polygonu připraven pro pilotní běh a využívaní běžnými uživateli z řad Ministerstva vnitra a Národního bezpečnostního úřadu. Prováděné činnosti budou zaměřeny na optimalizaci uživatelského rozhraní polygonu, definici uživatelských scénářů a návrh školení pro členy bezpečnostních týmů.


Strana 37/42


8

Výtisk č. 1

Seznam zkratek

ADSL

Asymmetric Digital Subscriber Line

API

Application Programming Interface

APT

Advanced Persistent Threat

BSD

Berkeley Software Distribution

BYOD

Bring Your Own Device

C&C

Command and Control

CERT

Computer Emergency Response Team

CESNET

Czech Education and Scientific Network

CHP

Change Point

CHPP

Change Point Problem

CIDR

Classless Inter-Domain Routing

CPG

Cybernetic Proving Ground

CPU

Central Processing Unit

CSIRT

Computer Security Incident Response Team

CSV

Comma-Separated Values

DDoS

Distributed Denial of Service

DHCP

Dynamic Host Configuration Protocol

DNS

Domain Name System

DoS

Denial of Service

ENISA

European Network and Information Security Agency

FPS

Frames Per Second

GPU

Graphic Processing Unit

GUI

Graphical User Interface

HTML

HyperText Markup Language

HTTP

Hyper Text Transfer Protocol

IaaS

Infrastructure as a Service

IPFIX

IP Flow Information Export

IRC

Internet Relay Chat

JDBC

Java Database Connectivity

JSON

JavaScript Object Notation

JSR

Java Specification Request


Strana 38/42


KVM

Kernel-based Virtual Machine

KYPO

Kybernetický polygon

LAN

Local Arean Network

LMN

LAN Management Node

LOF

Local Outlier Factor

LOIC

Low Orbit Ion Cannon

MAC

Media Access Control

MIT

Massachusetts Institute of Technology

NBÚ

Národní bezpečnostní úřad

NREN

National Research and Education Network

ORM

Object-Rational Mapping

RAM

Random-Access Memmory

SCADA

Supervisory Control and Data Acquisition

SPAN

Switched Port Analyzer

SSD

Solid-State Drive

SVG

Scalable Vector Graphic

TCP

Transmission Control Protocol

TSV

Tab-Separated Values

VLAN

Virtual LAN

W3C

World Wide Web Consortium

WAN

Wide Area Network

XML

Extensible Markup Language


Výtisk č. 1

Strana 39/42


9

Výtisk č. 1

Seznam použité literatury

[1] D3.js library. Dostupné z: http://www.d3js.org. [cit. 7.8.2013] [online]. [2] Developments of the honeyd virtual honeypot. Dostupné z: http://www.honeyd.org/. [cit. 7.8.2013] [online]. [3] Highcharts library. Dostupné z: http://www.highcharts.com. [cit. 7.8.2013] [online]. [4] Nfsen software. Dostupné z: http://nfsen.sourceforge.net/. [cit. 7.8.2013] [online]. [5] Raphaël library. Dostupné z: http://raphaeljs.com/. [cit. 7.8.2013] [online]. [6] Rrd tools. Dostupné z: http://oss.oetiker.ch/rrdtool/. [cit. 7.8.2013] [online]. [7] André Arnes, Paul Haas, Giovanni Vigna, Richard A. Kemmerer. Using a virtual security testbed for digital forensic reconstruction. Journal in Computer Virology, 2(4):275–289, 2007. [8] Terry Benzel, Robert Braden, Dongho Kim, Cliford Neuman. Experiences With DETER: A Testbed for Security Research. Proceedings of the 2nd IEEE Conference on Testbeds and Research Infrastructure for the Development of Networks and Communities (TridentCom), 2006. [9] Národní bezpečnostní úřad. Věcný záměr zákona o kybernetické bezpečnosti. Technical report, Praha, Česká republika. Dostupné z: http://www.govcert.cz/download/nodeid1044/. [cit. 18.7.2013] [online]. [10] Jake D. Brutlag. Aberrant Behavior Detection in Time Series for Network Monitoring. Proceedings of the 14th USENIX conference on System administration, LISA ’00, s. 139– 146, Berkeley, CA, USA, 2000. USENIX Association. Dostupné z: http://dl.acm.org/ citation.cfm?id=1045502.1045530. [11] LD Chen. Construction of the New Generation Network Security Testbed-Testbed@ TWISC: Integration and Implementation on Software Aspect, 2008. Institute of Computer & Communication, National Cheng Kung University, Tainan, Taiwan. [12] B. Claise. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. RFC 5101 (Proposed Standard), January 2008. Dostupné z: http://www.ietf.org/rfc/rfc5101.txt. [13] Fabian Fischer, Johannes Fuchs, Pierre-Antoine Vervier, Florian Mansmann, Olivier Thonnard. VisTracer: a visual analytics tool to investigate routing anomalies in traceroutes. Proceedings of the Ninth International Symposium on Visualization for Cyber Security, VizSec ’12, s. 80–87, New York, NY, USA, 2012. ACM. [14] Zdeněk Kedaj. Spektogramy webových diskusí. 2012. Diplomová práce, Masarykova univerzita. [15] Kumar Krishna, Weiqing Sun, Pratik Rana, Tianning Li, R Sekar. V-NetLab: a cost-effective platform to support course projects in computer security. Proceedings of 9th Colloquium for Information Systems Security Education, 2005. [16] Aleksandar Lazarevic, Vipin Kumar, Jaideep Srivastava. Intrusion detection: A survey, 2005.


Strana 40/42


Výtisk č. 1

[17] Prince M. The ddos that almost broke the internet, březen 2013. Dostupné z: http: //blog.cloudflare.com/the-ddos-that-almost-broke-the-internet. [cit. 18.7.2013] [online]. [18] Jelena Mirkovic, Peter Reiher. A taxonomy of DDoS attack and DDoS defense mechanisms. SIGCOMM Comput. Commun. Rev., 34(2):39–53, April 2004. ISSN 0146-4833. Dostupné z: http://doi.acm.org/10.1145/997150.997156. [19] Rafael Moreno-Vozmediano, Ruben S. Montero, Ignacio M. Llorente. IaaS Cloud Architecture: From Virtualized Datacenters to Federated Cloud Infrastructures. Computer, 45 (12):65–72, 2012. ISSN 0018-9162. [20] European Network, Information Security Agency. ENISA Threat Landscape: Responding to the Evolving Threat Environment. Technical report, Hérakleion, Řecko, září 2012. Dostupné z: http://www.enisa.europa.eu/activities/risk-management/evolving-threatenvironment/ENISA_Threat_Landscape/at_download/fullReport. [cit. 18.7.2013] [online]. [21] European Network, Information Security Agency. National Cyber Security Strategies: Practical Guide on Development and Execution. Technical report, Hérakleion, Řecko, prosinec 2012. Dostupné z: http://www.enisa.europa.eu/activities/Resilienceand-CIIP/national-cyber-security-strategies-ncsss/national-cyber-securitystrategies-an-implementation-guide/at_download/fullReport. [cit. 18.7.2013] [online]. [22] Breunig, M; Kriegel, H.P.; Ng, Raymond T., Sander, Jörg:. LOF: Idetifying Density-Based Local Outliers. Conference on Management of Data, Dalles, 2000. [23] Čepský P. Phishingový útok na raiffeisenbank: najde se ještě nějaký hlupák?, červenec 2012. Dostupné z: http://www.lupa.cz/clanky/phishingovy-utok-naraiffeisenbank-najde-se-jeste-nejaky-hlupak/. [cit. 18.7.2013] [online]. [24] Kaplický J.; Kepšta L.; Wolf P. Anatomie jednoho DDoS. Data Security Management, 17 (2):28–31, 2013. ISSN 1211-8737. [25] Tartakovsky, Alexander G.; Rozovskii, Boris L.; Blažek, Rudolf B.; Kim, Hongjoong. A Novel Approach to Detection of Intrusions in Computer Networks via Adaptive Sequential and Batch-Sequential Change-Point Detection Methods. IEEE Transactions on Signal Processing, 54(9):3372–3382, 2009. [26] Department of Homeland Security. Blueprint for a Secure Cyber Future: The Cybersecurity Strategy for the Homeland Security Enterprise. Technical report, USA, listopad 2011. Dostupné z: http://www.dhs.gov/xlibrary/assets/nppd/blueprint-for-a-secure-cyberfuture.pdf. [cit. 18.7.2013] [online]. [27] Open vSwitch. Open vSwitch: An Open Virtual Switch. Dostupné z: http://openvswitch. org/. [cit. 30.8.2013] [online]. [28] Basta P. Ddos: Lessons learned and technical aspects, květen 2012. Dostupné z: http: //www.afcea.cz/img/clanky_next/ITTE/Basta_DDOS.pdf. [cit. 18.7.2013] [online]. [29] Niels Provos. Virtual honeypots : from botnet tracking to intrusion detection. AddisonWesley, Upper Saddle River, NJ, 2008. ISBN 0321336321. [30] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. Architecture for IP Flow Information Export. RFC 5470 (Informational), March 2009. Dostupné z: http://www.ietf.org/rfc/ rfc5470.txt. Updated by RFC 6183. Projekt Kybernetický polygon – VG20132015103

Strana 41/42


Výtisk č. 1

[31] DELL SecureWorks. Advanced persistent threats: Understand the threat, 2013. Dostupné z: http://www.secureworks.com/cyber-threat-intelligence/advanced-persistentthreats/understand-threat/. [cit. 18.7.2013] [online]. [32] Anna Sperotto, Gregor Schaffrath, Ramin Sadre, Cristian Morariu, Aiko Pras, Burkhard Stiller. An Overview of IP Flow-Based Intrusion Detection. IEEE Communications Surveys & Tutorials, 12(3):343–356, 2010. Dostupné z: http://doc.utwente.nl/72752/. [33] Simonite T. Chinese hacking team caught taking over decoy water plant, srpen 2013. Dostupné z: http://www.technologyreview.com/news/517786/chinese-hackingteam-caught-taking-over-decoy-water-plant/. [cit. 27.8.2013] [online]. [34] Orestis Tsigkas, Olivier Thonnard, Dimitrios Tzovaras. Visual spam campaigns analysis using abstract graphs representation. Proceedings of the Ninth International Symposium on Visualization for Cyber Security, VizSec ’12, s. 64–71, New York, NY, USA, 2012. ACM. [35] Urijah. Hive Mind LOIC, 2013. Dostupné z: http://hivemindloic.sourceforge.net/ wiki/Main_Page. [cit. 20.8.2013] [online]. [36] Kužník J.; Nývlt V. Anonymous napadli servery OSA, web české vlády i Evropského parlamentu, leden 2012. Dostupné z: http://technet.idnes.cz/anonymous-napadliservery-osa-web-ceske-vlady-i-evropskeho-parlamentu-1mp-/sw_internet.aspx? c=A120126_134112_sw_internet_nyv. [cit. 18.7.2013] [online]. [37] B. Van Leeuwen, V. Urias, J. Eldridge, C. Villamarin, R. Olsberg. Performing cyber security analysis using a live, virtual, and constructive (LVC) testbed. Military Communications Conference 2010 - MILCOM 2010, s. 1806–1811, 2010. [38] Česká spořitelna. Česká spořitelna preventivně upozorňuje své klienty na podvodné emaily, červenec 2012. Dostupné z: http://www.csas.cz/banka/content/inet/internet/ cs/news_ie_1497.xml. [cit. 18.7.2013] [online]. [39] Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac Newbold, Mike Hibler, Chad Barb, Abhijeet Joglekar. An Integrated Experimental Environment for Distributed Systems and Networks. s. 255–270, Boston, MA, December 2002.


Strana 42/42

Projekt KYPO VG Analýza a návrh architektury

Recommend Documents