Projekt KYPO VG Analýza a návrh architektury

Transkript

1 Projekt KYPO VG Analýza a návrh architektury Technická zpráva 2013 Autoři Kontaktní adresa 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 Masarykova univerzita Ústav výpočetní techniky Botanická 68a Brno Příloha číslo 1 Výtisk číslo 1 Počet listů 42

2 Obsah 1 Úvod Definice kritické infrastruktury Hrozby pro kritickou informační infrastrukturu Architektura Kybernetického polygonu Konfigurace Kybernetického polygonu Řízení scénářů Vyhodnocování scénářů Fungování Kybernetického polygonu z pohledu uživatelů Simulace infrastruktury Požadavky na infrastrukturu Navržené řešení Měření a analýza provozu Měřicí infrastruktura Analýza dat Bezpečnostní scénáře Seznam hrozeb pro kritickou informační infrastrukturu Obecný scénář pro Kybernetický polygon Scénář útoku distribuovaného odepření služby Vizualizace Vymezení základních požadavků na vizualizaci Front end volba vizualizačních technologií na straně klienta Back end volba aplikačního rámce Celková architektura vizualizační aplikace Závěr 37 8 Seznam zkratek 38 9 Seznam použité literatury 40 Projekt Kybernetický polygon VG Strana 2/42

3 ... Analýza a návrh architektury Výtisk č. 1 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 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 LAN 1 Scénář Vstupní portál Správa scenáře LMN 1 Konfigurace scénáře Zpracování dat Uzel správy scénáře Routing Node LMN n LAN n LMN 2 LAN 2 Vizualizace Scénář n Uzel správy scénáře Databáze Simulace & Měření 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 VG Strana 3/42

4 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. Projekt Kybernetický polygon VG Strana 4/42

5 1.2 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í 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]. Projekt Kybernetický polygon VG Strana 5/42

6 2 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. Projekt Kybernetický polygon VG Strana 6/42

7 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ů. Projekt Kybernetický polygon VG Strana 7/42

8 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ží Projekt Kybernetický polygon VG Strana 8/42

9 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 VG Strana 9/42

10 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. Projekt Kybernetický polygon VG Strana 10/42

11 3 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 VG Strana 11/42

12 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 VG Strana 12/42

13 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. Projekt Kybernetický polygon VG Strana 13/42

14 4 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 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í: IPFIX 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í IPFIX Kolektor Analýza dat Obrázek 5: Schéma měřicí architektury Projekt Kybernetický polygon VG Strana 14/42

15 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 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í 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ů. Projekt Kybernetický polygon VG Strana 15/42

16 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 VG Strana 16/42

17 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 ( Nagios ( Cacti ( 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 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 TCP Zdrojový port Cílový port 80 Počet bytů 2568 Počet paketů 5 Začátek toku :58: Konec toku :59: 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 HTTP metoda Host URI Referer Hodnota GET /general/about muni.cz%2fgeneral%2fabout&source=web User-Agent Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1;.NET CLR ;.NET CLR ) Tabulka 2: Příklad položek pro HTTP dotaz. Položky Referer a User-Agent jsou zkráceny. Projekt Kybernetický polygon VG Strana 17/42

18 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) 768 Využití procesoru (%) 51 Obsazené místo na disku (MB) Čas :59: Tabulka 3: Příklad položek měřených na koncové stanici 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 odpo- Projekt Kybernetický polygon VG Strana 18/42

19 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ň: a t = α(y t c t m ) + (1 α)(a t 1 + b t 1 ) Lineární trend: b t = β(a t a t 1 ) + (1 β)b t 1 Sezónní trend: c t = γ(y t a t ) + (1 γ)c t m Predikce je potom ^y t+1 = a t + b t + c t+1 m kde m 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 d t = γ y t ^y t + (1 γ)d t m, z které se následně vypočítá interval spolehlivosti (^y t ± δ d t m ). 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 VG Strana 19/42

20 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ší Projekt Kybernetický polygon VG Strana 20/42

21 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: [ p k=1 K(i, j) = exp (x ki x kj ) 2 ] kde p je počet pozorovaných časových řad, i a j označují dvojici časových značek, x ki je hodnota k té časové řady v okamžiku i. Jádrová matice K(i, j) je transformována do reprezentace váženého grafu G = (V, E), kde V je množina uzlů a E 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(i, j). 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 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. σ 2 Projekt Kybernetický polygon VG Strana 21/42

22 5 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 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í [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] 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 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. Projekt Kybernetický polygon VG Strana 22/42

23 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 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í ů 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] 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 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. Projekt Kybernetický polygon VG Strana 23/42

24 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 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 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. Projekt Kybernetický polygon VG Strana 24/42

25 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 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 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. Projekt Kybernetický polygon VG Strana 25/42

26 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í 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 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 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 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 VG Strana 26/42

27 ú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í. Bot Bot www Bot #irc Vnitřníšsíť Master Vnějšíšsíť Bot Útočník #irc Běžnýšuživatel IRCšserver Běžnýšprovoz Útokššššššššššššš IRCškomunikace 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 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 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 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 ser- Projekt Kybernetický polygon VG Strana 27/42

28 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 /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 /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 n wolf -p 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= 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 Projekt Kybernetický polygon VG Strana 28/42

29 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ář. Projekt Kybernetický polygon VG Strana 29/42

30 6 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ě Projekt Kybernetický polygon VG Strana 30/42