Web Interface for Network Anomaly Detection System

VYSOKÉ U

Č

ENÍ TECHNICKÉ V BRN

Ě

FAKULTA INFORMA

Č

NÍCH TECHNOLOGIÍ

ÚSTAV PO

Č

ÍTA

Č

OVÝCH SYSTÉM

Ů

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

WEBOVÉ ROZHRANÍ PRO SYSTÉM DETEKCE

SÍ

Ť

OVÝCH ANOMÁLIÍ

BAKALÁ

Ř

SKÁ PRÁCE

BACHELOR‘S THESIS

AUTOR PRÁCE

PETR SLÁDEK

AUTHOR

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

FAKULTA INFORMA

Č

NÍCH TECHNOLOGIÍ

ÚSTAV PO

Č

ÍTA

Č

OVÝCH SYSTÉM

Ů

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

WEBOVÉ ROZHRANÍ PRO SYSTÉM DETEKCE

SÍŤOVÝCH ANOMÁLIÍ

WEB INTERFACE FOR NETWORK ANOMALY DETECTION SYSTEM

BAKALÁ

Ř

SKÁ PRÁCE

BACHELOR‘S THESIS

AUTOR PRÁCE

PETR SLÁDEK

AUTHOR

VEDOUCÍ PRÁCE

Ing. VÁCLAV BARTOŠ

SUPERVISOR

Abstrakt

Úkolem této bakalář_{ské práce je vytvo}ř_{it webové rozhraní pro systém detekce sí}ť_{ových anomálií}

s názvem HostStats. Jeho úkolem je umožnit uživateli efektivně _{pracovat s daty a statistikami, které}

systém poskytuje. Webové rozhraní funguje jako plugin do NfSenu i jako zcela nezávislá webová aplikace. Implementace probě_{hla v PHP s využitím Nette Frameworku, HTML5, CSS3 a JavaScriptu}

s použitím jQuery knihovny.

Abstract

The goal of this work is to create a web interface for network anomaly detection system called HostStats. Its mission is to enable users to effectively work with data and statistics provided by the system. Web interface works as a plugin to NfSen as a completely independent web applications. Implementation took place in PHP using the Nette Framework, HTML5, CSS3, and JavaScript using the jQuery library.

Klí

č

ová slova

HostStats, NfSen, NetFlow, timeslot, detekce útoků_{, sí}ť_{ové anomálie, Nette framework}

Keywords

HostStats, NfSen, NetFlow, timeslot, attack detection, network anomaly, Nette framework

Citace

Sládek Petr: Webové rozhraní pro systém detekce síť_{ových anomálií, bakalá}ř_{ská práce, Brno, FIT}

Webové rozhraní pro systém detekce sí

ť

ových anomálií

Prohlášení

Prohlašuji, že jsem tuto bakalář_{skou práci vypracoval samostatn}ě _{pod vedením Ing. Václava Bartoše.}

Uvedl jsem všechny literární prameny a publikace, ze kterých jsem č_erpal.

……… Petr Sládek 15.kvě_{tna 2013}

Pod

ě

kování

Dě_{kuji svému vedoucímu práce Ing. Václavu Bartošovi za odborné vedení a všechny podn}ě_{ty a}

podklady, které mi k vypracování práce poskytl.

© Petr Sládek, 2013

Tato práce vznikla jako školní dílo na Vysokém uč_{ení technickém v Brn}ě_{, Fakult}ě _informač_ních

technologií. Práce je chráně_{na autorským zákonem a její užití bez ud}ě_{lení oprávn}ě_{ní autorem je}

Obsah

Obsah ... 1

1 Úvod ... 3

2 Analýza ... 4

2.1 Proces získávání dat pro HostStats ... 4

2.1.1 NetFlow ... 4

2.1.2 NfSen – Netflow Senzor ... 5

2.1.3 HostStats ... 5

2.2 Architektura pluginů _{NfSen ... 6}

2.3 Komunikace Frontendu s Backendem ... 7

2.3.1 NEW_DATA (1) ... 8 2.3.2 GET_STATUS (10) ... 8 2.3.3 GET_HOST_CNT_HISTORY (11) ... 8 2.3.4 GET_FLOW_CNT_HISTORY(12) ... 9 2.3.5 GET_PROFILES(20) ... 9 2.3.6 GET_FIELD_LIST(30) ... 9 2.3.7 GET_TIMESLOT_DATA(31) ... 10 2.3.8 GET_TIMESLOT_IPMAP (32) ... 10 2.3.9 GET_HOST_HISTORY(35) ... 11 2.3.10 GET_DETECTION_LOG_LIST(40) ... 11 2.3.11 GET_DETECTION_LOG(41) ... 12

2.4 Potencionální technologie Frontendu ... 12

3 Implementace ... 13 3.1 Použité technologie ... 14 3.1.1 HTML5 ... 14 3.1.2 CSS3 ... 15 3.1.3 PHP Framework Nette ... 15 3.1.4 Konfigurace př_{es Neon ... 16}

3.1.5 JavaScriptová knihovna jQuery ... 16

3.1.6 CSS Framework Bootstrap ... 17

3.1.7 AJAX & Snippety ... 17

3.2 Objektový návrh aplikace ... 18

3.2.1 MVP struktura ... 18

3.2.2 Životní cyklus aplikace ... 20

3.2.4 Tř_{ída Timeslot ... 22} 3.2.5 Tř_{ída Timewindow ... 23} 3.2.6 Tř_{ída Nettools ... 23} 3.2.7 Zpracování chyb ... 23 3.3 Sekce Frontendu ... 24 3.3.1 Sekce Overview ... 24 3.3.2 Sekce Detail ... 25 3.3.3 Sekce IP map ... 25 3.3.4 Sekce History ... 26 3.3.5 Sekce Detectors ... 27 4 Testování ... 28 4.1 Oblasti testování ... 28

4.1.1 Testování funkč_{nosti ... 28}

4.1.2 Testování použitelnosti ... 29

4.1.3 Testování bezpeč_{nosti ... 29}

4.2 Na č_{em bylo testováno ... 29}

4.3 Výsledky testování ... 29

5 Možnosti dalšího rozšíř_{ení ... 30}

1

Úvod

Cílem této práce je popsat a zdokumentovat webové rozhraní pro systém detekce síť_{ových anomálií}

HostStats, vyvíjeného v rámci výzkumné skupiny ANT. HostStats je název systému, který využívá data v NetFlow záznamech a generuje statistiky o jednotlivých hostech na síti. V tě_{chto statistikách}

poté vyhledává anomálie, na základě _{kterých detekuje jednotlivé sí}ť_{ové útoky jako DOS, horizontální}

a vertikální skenování portů _{a další.}

Webové rozhraní (neboli také frontend) systému HostStats je prostř_{edek pro zobrazování}

statistik ve formě _{tabulek, filtr}ů _{a graf}ů _{uživateli tak, aby bylo vše p}ř_ehledně _vidě_{t a s daty se dalo bez}

problémů _{pracovat. Webové rozhraní je plugin do monitrovacího systému NfSen, který slouží pro}

práci s NetFlow záznamy. Dů_{raz je ale taktéž kladen na to aby frontend mohl fungovat samostatn}ě

jako nezávislá webová aplikace.

Tato práce se zabývá analyzováním a urč_{ením nejlepšího vhodného technologického} ř_ešení

pro implementaci webového rozhraní systému HostStats, a také popsáním implementace samotné. A to př_{edevším architekturou plugin}ů _{do monitorovacího systému NfSen, fungováním aplikace ve}

vybraném Nette Frameworku, dále pak popsáním ně_{kterých d}ů_{ležitých t}ř_{íd objektového modelu,}

popsáním MVC struktury aplikace a v neposlední ř_adě _{komunikací webového rozhraní}

s backendovou (serverovou) č_{ástí systému.}

V poslední kapitole je popsáno testování funkč_{nosti a použitelnosti webu. Vzhledem k tomu,}

že tato aplikace slouží pro administrátora č_{i správce sít}ě_{, testování prob}ě_{hlo na skupince lidí z IT}

oboru. Dále jsou uvedeny možná budoucí užiteč_{ná rozší}ř_{ení systému.}

Na př_{iloženém CD jsou kompletní zdrojové kódy webového rozhraní a elektronická verze tohoto}

2

Analýza

Tato kapitola se zabývá teoretickou stránkou funkč_{nosti systému. Dozvíte se kde a jak se berou data}

pro statistiky ze kterých HostStats vychází a na základě _{kterých odhaluje sí}ť_{ové útoky. Jsou zde}

popsány technologie, na kterých je systém detekce síť_{ových anomálií založen a ze kterých je proto}

nutné vycházet. Na závě_{r jsou zde uvedeny možné technologie a prost}ř_{edky na kterých je vhodné}

stavě_{t webové rozhraní.}

2.1

Proces získávání dat pro HostStats

Struč_ně _{funguje systém takto: HostStats zpracovává NetFlow záznamy o tocích na síti. NetFlow}

záznamy jsou ukládány do souborů_{, p}ř_ič_{emž každý soubor obsahuje záznamy z jednoho} č_asového

intervalu o délce 5 minut (tzv. timeslot). Pomocí opensource nástroje nfdump se dají data z tě_chto

souborůč_{íst. Pro lepší vizualizaci a práci s NetFlow záznamy se ovšem používá opensource nástroj}

NfSen. Jeho webový frontend zobrazuje tyto údaje uživateli ve formě _grafů _{a tabulek s r}ů_{znými filtry}

a vyhledáváním. NfSen také nabízí podporu pro pluginy. Vždy po 5 minutách, když dojde k vytvoř_ení

nového souboru s flow záznamy, pošle NfSen pomocí pluginu zprávu s názvem souboru timeslotu na HostStats a ten ho zpracuje a vytvoř_{í statistiku o jednotlivých hostech na síti.}

Základním č_{lánkem získání dat ke statistice je tedy NetFlow.}

2.1.1

NetFlow

NetFlow je protokol vytvoř_{ený, jednou z nejvíce dominujících firem na poli sí}ť_{ových prvk}ů_,

společ_{ností Cisco Systems. Tento otev}ř_{ený protokol slouží k monitorování sí}ť_{ového provozu na}

základě _{IP tok}ů _{a to v tém}ěř _reálném č_{ase. Toto monitorování je d}ů_{ležité zejména k zabezpe}č_ování

poč_ítač_{ové sít}ě_{, ale i nap}ř_{íklad pro ISP k zpoplat}ň_{ování svých služeb na základ}ě _př_{enesených dat.}

IP tok (neboli flow) je definovaný jako ukonč_{ená sekvence paket}ů _{se shodnými p}ě_{ti údaji} • Cílová IP adresa

• Zdrojová IP adresa

• Cílový port

• Zdrojový port

• Č_{íslo protokolu}

U každého toku je evidován č_{as jeho za}č_{átku, délka jeho trvání, po}č_{et p}ř_{enesených paket}ů_{, po}č_et

př_{enesených byt}ů _{a p}ř_ípadně _{další údaje. Z každého toku tedy m}ů_{žeme ur}č_{it kdo s kým kdy}

Architektura NetFlow je složena z ně_{kolika sond (tzv. exportér}ů_{) a jednoho kolektoru.}

Exportéry jsou umístě_{ny v r}ů_{zných místech sít}ě_{, na kterých chceme schra}ň_{ovat statistiky a analyzují}

procházející pakety. Ukládají informace o toku a ve chvíli kdy tok skonč_{í, odešlou ho na kolektor. A}

to buď _{po síti na které jsou p}ř_{ipojené nebo po vlastní dedikované lince, která nezat}ě_žuje

monitorovanou síť_{. [1]}

Kolektor je zař_{ízení, které schra}ň_{uje a ukládá všechny statistiky o tocích, které p}ř_{ijme od}

exportérů_{. Proto musí mít velký úložný prostor. V}ě_{tšinou na tomto za}ř_{ízení b}ě_{ží také software}

vhodný pro vizualizaci tě_{chto NetFlow záznam}ů_{. Jedním z nich je nap}ř_{íklad NfSen.}

2.1.2

NfSen – Netflow Senzor

Tento oblíbený a č_{asto používaný nástroj slouží nejen jako NetFlow kolektor, ale ve své podstat}ě

jako grafická nadstavba nástroje nfdump. Pochází také od stejného autora a je stejně _{tak vydávaný}

jako opensource. NfSen je rozdě_{len na backend a webový frontend. Backend slouží jako kolektor,}

který shromažduje NetFlow záznamy a ukládá je do RRD1 databáze. Frontend pomocí RRD grafů

vykresluje využití sítě _{(v bytech, paketech i tocích) a další statistiky. Tyto data se dají samoz}ř_ejmě

filtrovat podle portů_{, ip adres, jednotlivých senzor}ů _atp…

Jak backend, tak i frontentd mají své pluginy. Backendové jsou volané př_{i r}ů_zných

událostech, jako je např_{íklad nový timeslot, n}ě_{jaké definované upozorn}ě_{ní a podobn}ě_{. Frontendové}

pluginy slouží k vlastní vizualizaci a filtraci dat. A také k volání funkcí v backendových pluginech. [2]

Tyto pluginy jsou využity i pro HostStats. Backendový plugin posílá nová data do HostStats ke zpracování a Frontendový plugin zajištuje vykreslení HostStats frontendu v layoutu NfSenu.

2.1.3

HostStats

HostStats je název systému pro analýzu dat a detekci síť_{ových anomálií vyvíjený pod výzkumnou}

skupinou ANT, jehož základem je výpoč_{et statistik o jednotlivých hostech (IP adresách) v síti.}

Systém je vyvíjen jako plug-in pro NfSen. Každých 5 minut jsou z NetFlow dat vypoč_{ítány informace}

o provozu jednotlivých IP adres. V tě_{chto informacích pak jsou vyhledávány adresy vykazující}

podezř_{elé chování.}

Komunikace jednotlivých prvků _{systému je znázorn}ě_{na na schématu (obrázek 1).}

Backendový plugin NfSenu, napsaný v jazyce perl, posílá jednou za 5 minut př_{es socket zprávu}

s názvem nového timeslotu. HostStats server (backend) timeslot analyzuje a vypoč_{ítá statistiky pro}

1

jednotlivé hosty (IP adresy) a statistiku uloží na disk. Ze vzniklé statistiky detekuje hrozby, jejichž seznam taktéž uloží na disk k dalšímu použití, př_ípadně _{odešle informace do systému Warden} 2_.

Na všechny uložená data se opě_{t p}ř_{es socket dotazuje webový frontend. Ten je poté zobrazuje}

v uživatelsky př_{ijatelné form}ě _{uživateli. Podrobn}ě _{je komunikace HostStats backendu s frontendem}

popsána v kapitole 2.3.

Obrázek 1: Schéma datových toků _HostStats

2.2

Architektura plugin

ů

NfSen

Webové rozhraní (frontend) systému HostStats musí fungovat jako plugin do NfSenu. A to př_edevším

z toho dů_{vodu, aby byly všechny nástroje používané k analýze NetFlow p}ě_kně _{na jednom míst}ě_{. Na}

druhou stanu je ovšem vhodné aby webový frontend mohl být funkč_{ní i samostatn}ě _{bez použití}

NfSenu.

Jak už bylo ř_eč_{eno NfSen nabízí podporu pro frontendové pluginy psané v PHP , které jsou}

vidě_{t na webovém frontendu NfSenu a backendové pluginy, které se spouští jako perl skript a mohou}

komunikovat s frontendovými pomocí aplikač_{ního rozhraní.}

Z dů_{vodu pot}ř_{eby samostatnosti našeho webového rozhraní, není možné použít nabízené}

rozhraní pro frontendové pluginy. Proto je použit jen drobný mů_{stek, kterým je php soubor}

hoststats.php v adresář_{e NfSen plugin}ů_{. Ten vypne automatické obnovování stránky v nastaveném}

intervalu, vloží iframe s adresou našeho webového rozhraní a pomocí JavaScriptu ho roztáhne na celou možnou plochu uživatelova prohlížeč_e.

2

WARDEN - systém pro efektivní sdílení informací o detekovaných událostech (hrozbách). Systém je vyvíjen v rámci projektu Velká Infrastruktura CESNET, který řeší sdružení CESNET. https://csirt.cesnet.cz/Warden

Jakákoli jiná možnost velmi komplikovala využít kterékoli framework, ajaxové požadavky, vlastní CSS styly atd. NfSen rozhraní pro PHP frontendové pluginy není pro funkč_{nost HostStats}

webového rozhraní nutností, protože to komunikuje př_{es sockety p}ř_{ímo s HostStats backendem a}

nevyžaduje jakékoliv propojení s NfSenem.

Obrázek 2: Schéma architektury pluginů _{v NfSen [2]}

2.3

Komunikace Frontendu s Backendem

Frontend posílá požadavky na socket otevř_{ený backendem (standardn}ě _{localhost na portu 3333) ve}

formátu:

• první byte - kód požadavku

• ř_etě_{zec libovolné délky - parametry}

• poslední byte - ukonč_{ení zprávy nulovým znakem ('\0’)}

Např_:

\x1Eall;201302171200;flows > 100;50;0\0

Poč_{et a význam parametr}ů _{závisí na typu požadavku, parametry jsou obvykle odd}ě_lovány

pomocí stř_edníku.

Backend odešle zpě_{t požadovaná data (formát závisí na typu požadavku) a uzav}ř_{e spojení.}

Pro každý požadavek je tedy nutné vytvoř_{it nové spojení.}

Pokud není specifikováno jinak:

• všechny č_{asy (timesloty) se posílají ve formátu: yyyymmddHHMM.}

• parametr "profil" urč_{uje profil, ze kterého se získávají data, je to bu}ď _{"all", nebo n}ě_{který z} ř_etě_zců _{získaných voláním GET_PROFILES viz dále.}

Pokud dojde k chybě_{, je místo o}č_{ekávané odpov}ě_{di odeslána chybová hláška za}č_ínající ř_etě_zcem

"ERROR". Ta je potom vyvolaná jako Exception a dále odchycená a zpracovaná v aplikaci.

Dále jsou uvedeny jednotlivé typy požadavků_{. V závorce je vždy uveden kód požadavku v desítkové}

soustavě_.

2.3.1

NEW_DATA (1)

Speciální požadavek, který nepř_{ichází z webového rozhraní, ale posílá ho NfSen backend plugin.} Ř_{íká tím, že jsou k dispozici nová data. Na tento požadavek jako jediný není odesílána žádná}

odpověď_.

Parametry:

timeslot

2.3.2

GET_STATUS (10)

Vrátí základní stavové informace o stavu backendu. Požadavek nemá žádné parametry.

Formát odpovědi

promenna=hodnota;promenna=hodnota;...;promenna=hodnota

V souč_{asnosti se vracejí tyto prom}ě_nné:

• processing - 1 pokud plugin právě _{zpracovává nová data, jinak 0} • timeslot - aktuálně _{zpracovávaný, nebo poslední zpracovaný timeslot} • flows - poč_{et na}č_{tených tok}ů _{v posledním timeslotu}

• hosts - poč_{et na}č_{tených host}ů _{v posledním timeslotu}

2.3.3

GET_HOST_CNT_HISTORY (11)

Vrací historii poč_{tu host}ů _{v minulých timeslotech}

Paramery:

profil;starttimeslot,endtimeslot

Formát odpově_di

Hodnota pro každý timeslot mezi starttimeslot a endtimeslot (vč_etně_{), ke kterému jsou data k}

dispozici.

2.3.4

GET_FLOW_CNT_HISTORY(12)

Vrací historii poč_{tu tok}ů _{v minulých timeslotech. Parametry a formát odpov}ě_{di stejné jako u}

GET_HOST_CNT_HISTORY.

2.3.5

GET_PROFILES(20)

Vrátí seznam dostupných profilů_{. Nemá žádné parametry.}

Formát odpovědi:

nazev_profilu_1;nazev_profilu_2;...;nazev_profilu_n

2.3.6

GET_FIELD_LIST(30)

Vrátí seznam položek, ze kterých se skládá záznam o hostu.

Parametry:

profile

Formát odpově_di:

polozka;polozka;...;položka

Př_íklad:

2.3.7

GET_TIMESLOT_DATA(31)

Na tento požadavek př_{ijde jako odpov}ěď _{tabulka dat z jednoho timeslotu.}

Parametry:

profile;timeslot;filter;limit;sort_by;ascending

• filter - filtrovací pravidlo, formát kontroluje backend, z hlediska frontendu jde o libovolný

ř_etě_{zec). M}ů_{že být prázdné.}

• limit - maximální poč_{et vrácených záznam}ů _(kladné č_íslo)

• sort_by - název položky, podle jejíž hodnoty budou data seř_{azena (jeden z názv}ů _získaných

voláním GET_FIELD_LIST), mů_{že být prázdné, pak data nejsou} ř_azena

• ascending - 1 pokud mají být data ř_{azena vzestupn}ě_{, jinak jsou} ř_{azena sestupn}ě _(default)

Formát odpovědi:

Tabulka, ř_{ádky odd}ě_{leny pomocí '}\n’, hodnoty na ř_{ádku pomocí '};'.

• První ř_{ádek - popisky sloupc}ů _{tabulky (názvy položek)} • Každý další ř_{ádek jeden záznam (tj. adresa a hodnoty položek)}

Př_íklad: address;in_flows;in_packets;in_bytes;out_flows;out_packets;out_bytes 10.0.0.1;2;2;120;1;4;2405 192.168.1.2;54;510;14028;27;98;841 2001:db8::1428:57ab;0,0,0;250;250;15000

2.3.8

GET_TIMESLOT_IPMAP (32)

Na tento požadavek př_{ijde jako odpov}ěď _{tabulka dat z jednoho timeslotu agregované podle /16}

prefixu IPv4 adresy. Tyto data se používají pro vykreslení IP mapy (viz kapitola 253.3.3).

Parametry:

profile;timeslot;base_address;prefix_len

• base_address – Adresa specifické podsítě • prefix_len – Délka prefixu př_{edchozí adresy}

Formát odpově_di:

2.3.9

GET_HOST_HISTORY(35)

Vrací statistiky o jednom hostu z daného č_{asového intervalu, tj. ze všech existujích soubor}ů _s č_asovou

znač_{kou mezi} starttimeslot a endtimeslot (vč_etně_).

Parametry:

profile;address;starttimeslot;endtimeslot

• address - adresa hosta, jehož statistiky jsou požadovány (IPv4 nebo IPv6 v bě_žném

textovém formátu)

• starttimeslot - zač_átek č_{asového rozsahu (první požadovaný timeslot)} • endtimeslot - konec č_{asového rozsahu (poslední požadovaný timeslot)}

Formát odpově_di:

Tabulka, ř_{ádky odd}ě_{leny pomocí '\n’, hodnoty na} ř_{ádku pomocí ';'.} • První ř_{ádek - popisky sloupc}ů _{tabulky (názvy položek)}

• Každý další ř_{ádek jeden záznam (tj. timeslot a hodnoty položek)}

• Pokud se požadovaná adresa v datech z urč_{itého timeslotu nevyskytuje, jsou všechny hodnoty}

záznamu nulové.

• Pokud ně_{jaký timeslot není v}ů_{bec k dispozici (soubor neexistuje), je} ř_{ádek s tímto timeslotem}

vynechán. Př_íklad: timeslot;in_flows;in_packets;in_bytes;out_flows;out_packets;out_bytes 201301021200;2;2;120;1;4;2405 201301021205;0;0;0;0;0;0 201301021210;212;215;4320;250;250;15000

2.3.10

GET_DETECTION_LOG_LIST(40)

Vrací seznam dnů_{, pro které je k dispozici log detekovaných událostí. Tento požadavek nemá žádné}

parametry.

Formát odpovědi:

Seznam dní ve formátu yyyymmdd oddě_{lených pomocí '}\n’

Př_íklad:

20130102 20130103 20130104

2.3.11

GET_DETECTION_LOG(41)

Vrací obsah logu detekovaných událostí pro zadaný den

Parametry:

day (den ve formátu yymmdd)

Formát odpově_di:

Tabulka, ř_{ádky odd}ě_{leny pomocí '}\n’, hodnoty na ř_{ádku pomocí '};'.

Př_íklad:

201202151115;portscan_h;6;43.99.57.181;;;;1516;horizontal SYN scan 201202151115;portscan_h;6;138.243.71.66;;;;1413;horizontal SYN scan 201202151115;dos;6;;20fd:6cfa:e321:ff:0:ffff:93fa:e3fe;;;124112;

Význam jednotlivých sloupců_:

1. Timeslot, ve kterém byla událost detekována 2. Typ události, možnosti:

o portscan (skenování portu bez bližšího urč_ení)

o portscan_h (horizontální skenování portu, tj jeden port na více adresách)

o portscan_v (vertikální skenování portu, tj rů_{zné porty na jedné adrese)} o bruteforce (hádání hesel hrubou silou)

o dos (denial od service útok)

o other (ostatní)

3. protokol, př_{es který byl útok veden (1=ICMP, 6=TCP, 17=UDP)}

4. zdroj události (IPv4 nebo IPv6 adresa) 5. cíl události (IPv4 nebo IPv6 adresa) 6. zdrojový port

7. cílový port

8. intenzita události (např_{. po}č_{et proskenovaných adres/port}ů_{, po}č_{et tok}ů _{DoS útoku apod.)}

9. poznámka – jakýkoli ř_etě_zec

Protokolů_{, adres a port}ů _mů_{že byt i vice, v tom p}ř_ípadě _{jsou jednotlivé hodnoty odd}ě_leny č_{árkou ',' .}

2.4

Potencionální technologie Frontendu

Vzhledem k zadání je nutné použít pro webové rozhraní PHP na straně _{serveru a Javascript na stran}ě

klienta. To ulehč_{uje výb}ě_{r a odpadají tím možnosti jako Ruby, ASP, Perl} č_{i Python. Ovšem používat}

v dnešní době _{PHP bez n}ě_{jakého frameworku je velmi nevhodné a} č_asově _{neekonomické. PHP}

K nejvíce používaným a nejlépe dokumentovaným patř_{í Zend Framework, Nette Framework,}

CodeIgnitier, CakePHP a Sympony. Všechny tyto Frameworky samozř_ejmě _{fungují na PHP5, které}

obsahuje vylepšenou podporou pro objektově _{orientované programování.}

Zend Framework pochází od stejné společ_{nosti jako PHP samotné, je stále vyvíjený a má}

podrobnou a udržovanou dokumentaci. Oproti tomu je ale relativně _{pomalý, obsahuje mnoho soubor}ů

a tř_{íd, které v normální aplikaci programátor v}ů_{bec nevyužije a oproti ostatním framework}ů_{m není}

moc uživatelsky př_{íjemný. Skoro vše se konfiguruje a p}ř_{edává p}ř_{es pole, místo toho aby se použil}

objektový př_ístup.

Nette Framework vyvíjí malá č_{eská komunita. Na za}č_{átku roku vyšla jeho 2 verze, která je}

stabilní a kvalitně č_{esky i anglicky zdokumentovaná. Obsahuje skv}ě_{lý šablonovací systém Latte a}

vynikající systém vytvář_{ení formulá}řů _{a komponent. Do Nette existují také r}ů_{zné pluginy, knihovny a}

rozšíř_{ení od uživatelské komunity. Tento Framework se stává velmi populární a pro své webové}

aplikace ho použili např_{íklad servery Ulozto.cz, Denik.cz nebo kancelá}ř _prezidenta Č_R.

CodeIgnitier, CakePHP a Sympony jsou menší frameworky. Podporují, stejně _{jako p}ř_edchozí

dva, základní nástroje jako MVC strukturu, formulář_{e, emaily atp. Využívají se ovšem mén}ě _{a nejdou}

úplně _{s dobou.}

Na základě _{nezávislého testu [3] a prohlédnutí dokumentace a p}ř_íkladů _{jednotlivých}

frameworků _{jsem se rozhodl použít pro Webové rozhraní HostStats framework Nette. A to p}ř_edevším

kvů_{li šablonovacímu systému a skv}ě_{lé podpo}ř_{e AJAXu.}

Pro vývoj aplikace tohoto typu se hodí taktéž CSS Framework. Ten slouží k vytvoř_ení

základního rozložení layoutu webu a také obsahuje typografii a základní styly formulář_{ových prvk}ů_,

tabulek, rů_{zných zpráv, stav}ů _apod.

Takovýchto volně _{dostupných framework}ů _{se dá najít také mnoho. N}ě_{které, jako nap}ř_íklad

360.gs, jsou jen na vykreslení tzv „mř_ížky3_{“ webu. Jiné mají i grafické styly a JavaScript pro}

záložky, vysouvací menu apod. Mezi nejznámě_{jší pat}ř_{í YUI od Yahoo, YAML CSS Framework a}

Twitter Bootstrap.

Já jsem pro implementaci zvolil ten poslední. Twitter Bootstrap má široké využití ve všech „administrač_{ních“ prost}ř_{edích, má hezký design, který se dá jednoduše p}ř_izpů_{sobit a nabízí spoustu}

užiteč_{ných prvk}ů_.

3

Implementace

Po výbě_{ru optimálních technologií a prostudování dokumentace technologií, na které je pot}ř_eba

navázat bylo množné zač_{ít implementovat. V této kapitole jsou popsány technologie, frameworky a}

knihovny použité pro implementaci.

3

Dále je uveden objektový návrh MVP struktury, životní cyklus aplikace a podrobně_{ji popsány}

dů_{ležité t}ř_{ídy aplikace.}

3.1

Použité technologie

3.1.1

HTML5

HTML neboli hypertextový znač_{kovací jazyk je jedním ze základních jazyk}ů _{webu. Tedy publikace}

dokumentů _{na internetu. Dnes je HTML spolu s JavaScriptem, stylovacím jazykem CSS a}

serverovým jazykem PHP základem pro vě_{tšinu internetových prezentací.}

Další vývoj HTML př_{ímo ovliv}ň_{uje rozvoj internetových aplikací a umož}ň_{uje vývojá}řů_m

realizovat č_{ím dál tím více nápad}ů_{. Proto se s každou novou verzí internet posune o neuv}ěř_itelný

krok kupř_{edu. Stejn}ě _{tak se stalo i v p}ř_ípadě _{vydání poslední verze HTML5.}

HTML5 se zač_{ala vyvíjet kolem roku 2007, a její kone}č_{né schválení je plánováno až na rok}

2014. Proto je verze 5 stále velmi živá a její podpora je ze strany prohlížečů _př_{ijata r}ů_zně_{. Velká} č_ást

HTML 5 je v souč_{asné dob}ě _{podporována všemi velkými prohlíže}č_{i a je tedy možné mnoho z nové}

specifikace již používat.

HTML verze 5 se od verze 4 liší novými, zkrácenými a rychlejšími zápisy znač_{ek (tag}ů_).

Autoř_{i dávají d}ů_{raz na jednoduchost a zárove}ň _úč_{innost. V HTML5 je též možné vytvo}ř_{it aplikaci,}

která funguje v prohlížeč_{i i tehdy, když uživatel nemá internetové p}ř_{ipojení, a která ukládá data do}

lokálního úložiště _{na uživatelov}ě _poč_ítač_{i. Je-li internetové p}ř_{ipojení k dispozici, m}ů_{že aplikace}

synchronizovat data se vzdáleným serverem.

Obrázek 3: Ukázka HTML5 kódu

Př_{íklad t}ě_{la dokumentu ukazuje obrázek 3. Na první pohled je z}ř_{ejmé, že je velmi}

zjednodušený DOCTYPE a také meta tagy. Vzhledem k tomu že HTML5 vychází stejně _{jako starší}

Jazyk dále obsahuje mnoho nový znač_{ek (tag}ů_{). Nap}ř_{íklad <header>, <footer>, <section> a}

<article> pro jasně_jší č_leně_{ní obsahu nebo <video>, <audio>, <source> a <track> pro p}ř_idávání

multimediálního obsahu. Za zmínku také stojí nové typy formulář_{ových prvk}ů _{jako „number“ pro} č_{íselné hodonty, „search“ pro vyhledávání, „range“ pro} č_{íselý rozsah nebo nap}ř_{íklad „date“ pro}

datum, které rozšiř_{ují práci s webovými formulá}ř_{i bez nutnosti použití externích javascriptových}

knihoven.

Dále HTML5 obsahuje novinky jako geolokaci, vykreslovací canvas pro kreslení grafů_,

schémat nebo obrázků _{a již zmi}ň_{ované filestorage pro ukládání dat na disk. HTML5 je se všemi}

tě_{mto novinkami zp}ě_tně _{kompatibilní a web v n}ě_{m psaný je} č_ásteč_ně _funkč_{ní i ve starších}

prohlížeč_{ích které „p}ě_{tku“ nepodporují. [4]}

3.1.2

CSS3

Kaskádové styly (CSS) jsou dalším základním kamenem tvorby webů_{. Hlavním smyslem CSS je}

umožnit návrhářů_{m odd}ě_{lit vzhled dokumentu od jeho struktury a obsahu. P}ů_vodně _{to m}ě_{l umožnit}

už jazyk HTML, ale v dů_{sledku nedostate}č_{ných standard}ů _{a konkuren}č_{ního boje výrobc}ů _prohlížečů

se vyvinul jinak. Starší verze HTML obsahují celou ř_{adu element}ů_{, které nepopisují obsah a strukturu}

dokumentu, ale i způ_{sob jeho zobrazení. Z hlediska zpracování dokument}ů _{a vyhledávání informací}

není takový vývoj žádoucí a proto konsorcium W3C zač_{alo pracovat na standardu CSS. Pro moji}

aplikaci jsem zvolil nejnově_{jší verzi tohoto jazyka a to CSS3.}

Kaskádové styly ve své tř_{etí verzi nabízejí mnoho novinek uleh}č_{ující kodér}ů_{m práci a}

umožň_{ujících psát} č_{istší p}ř_enositelně_{jší kód a které odstra}ň_{ují rozdíly mezi jednotlivým prohlíže}č_{i. Za}

zmínku stojí např_{íklad CSS vlastnost border-radius, díky které lze u blokových i} ř_ádkových

elementů _{nastavit zaoblení roh}ů_{. Další takovou novinkou jsou vlastnosti box-shadow a text-shadow}

pro vytvoř_{ení stínu blok}ů_{m nebo textu. Velké využití májí také tzv. transformace, ty slouží}

k jednoduchým animacím např_{íklad p}ř_{i hover efektu (najetí myší) nebo p}ř_{i focus (zaktivn}ě_ní)

ně_{jakého formulá}ř_{ového prvku. Další velkou výhodou je možnost zadávat barvy ve formátu RGBA}

podporující alfa-kanál pro prů_hlednost.

Mnohé tyto vlastnosti mě_{li prohlíže}č_{e už d}ř_{íve, ovšem každý na to m}ě_{l své vlastnosti.}

Např_{íklad Mozzila používala –moz-border-radius a chrome –webkit-border-radius. Specifikace CSS3}

tyto rozdíly eliminuje a popsuje př_{esné chování ve všech prohlíže}č_{ích podporujících CSS3. [5]}

3.1.3

PHP Framework Nette

Nette je populární nástroj pro vytvář_{ení webových aplikací v PHP 5. Tento Framework bez}

hijacking, session fixation atd. Disponuje skvě_{lými ladícími nástroji, jak pro vypisování a odhalování}

chyb, tak pro ladě_{ní SQL dotaz}ů_{, optimalizaci rychlosti apod. [6]}

Programování v Nette Framework Vás také vede k č_{istému návrhu aplikace s d}ů_{razem na}

budoucí rozšiř_{itelnost. Díky velké a aktivní komunit}ě _{nabízí velké množství dopl}ň_ků_{, jako nap}ř_íklad

rů_{zné DataGridy, formulá}ř_{ové prvky, užite}č_{né knihovny a podobn}ě_.

3.1.4

Konfigurace p

ř

es Neon

NEON je textový soubor s př_{íponou *.neon, který se používá pro definici konfigurace. Je jednoduší a}

pro č_lově_ka č_itelně_{jší než nap}ř_{. INI, JSON nebo PHP pole. NEON používá velmi podobnou syntaxi}

jako YAML4. Hlavní rozdíl je v tom, že NEON podporuje tzv. „entity“, pro odsazení používá tabulátory, syntaxe je o ně_{co jednodušší a jeho analýza je rychlejší. Syntaxe je blíže popsaná}

v dokumentaci [7].

Aplikace používá dva konfigurač_{ní soubory. První, který je uložen}

v app/config/application.neon a nastavuje prostř_{edí aplikace, framwork, php, služby a podobn}ě_{. A}

druhý (app/config/config.neon), ve kterém se nastavuje př_izpů_{sobení HostStats frontendu. Dají se zde}

změ_{nit formáty datumu, email na který chodí p}ř_{ípadné chyby v aplikaci, parametry (adresa a port) pro}

př_{ipojení k HostStats, interval obnovování p}ř_{ehledu a adresu serveru na který se mají posílat whois}

dotazy.

3.1.5

JavaScriptová knihovna jQuery

Tato velmi populární knihovna velmi usnadň_{uje práci s JavaScriptem na webu. Její filozofie je úpln}ě

oddě_{lit „chování“ od struktury HTML dokumentu, stejn}ě _{jako CSS odd}ě_{luje grafické prvky a}

formátování. jQuery také využívá podobné selektory jako CSS. Např_{íklad místo b}ě_žného

document.getElementById(‘login’) stač_{í napsat} $(‘#login’).

Jak je vidě_{t i jQuery se drží hesla „write less, do more“ (piš málo, ud}ě_{lej hodn}ě_{). Knihovna}

nabízí mnoho animací, efektů_{, událostí a nes}č_{etné množství rozší}ř_{ení a plugin}ů_{, které si psát sám by}

byla v dnešní době _{velká ztráta} č_asu.

Ve webovém rozhraní HostStats jsou použity jQuery pluginy pro generování grafů _pro

HTML5 canvas (jquery.flot.js), pro práci s cookies (jquery.cookiee.js), pro jednotný vzhled zaškrtávacích políč_{ek, p}ř_epínačů _{a dalších formulá}ř_{ových prvk}ů _{(jquery.uniform.js), pro práci}

s AJAXem a Nette (jquery.livequery.js a jquery.nette.js) a další.

4 _{YAML je formát pro serializaci strukturovaných dat. Výhodou tohoto formátu je, že je čitelný nejen strojem,}

ale i člověkem. Jednou ze zásadních věcí tohoto formátu je, že nepodporuje znaky tabulátorů. Ty musí být nahrazeny mezerami, jinak vše vyústí v chybu.

3.1.6

CSS Framework Bootstrap

Pokud se jedná o administrač_{ní rozhraní, ovládání nebo nastavování n}ě_{jakého systému je zbyte}č_né

vymýšlet ně_{jakou speciální grafiku. V}ě_{tšinou poslouží kvalitní CSS Framework, který za použití}

správných CSS tř_{íd vytvo}ř_{í celý vzhled. Jedním z takovýchto framework}ů _{je Bootstrap od tv}ů_rců

známé sociální sítě _{Twitter. Auto}ř_{i o n}ě_{m tvrdí že je elegantní, intuitivní a výkonný front-end}

framework pro rychlejší a snadně_{jší vývoj webových aplikací. [8]}

Bootstrap definuje fluidní i statické layouty. Pro frontend hoststats byl zvolen fluidní, který se př_izpů_{sobí ší}ř_{ce monitoru a tím pádem zvýhodní lidi s velkými monitory, kterým se vejde na jednu}

obrazovku více informací.

Dále jsou využity styly pro tabulky, formulář_{e, chybové informace a stavy, boxy, menu atd.}

3.1.7

AJAX & Snippety

Moderní webové aplikace dnes bě_{ží nap}ů_{l na serveru a nap}ů_{l v prohlíže}č_{i. AJAX je tím klí}č_ovým

spojovacím prvkem. AJAX umožň_{uje zm}ě_{ny na webové stránce, bez toho aniž by se musela celá}

znovu nač_{ítat. To celé provádí pomocí JavaScriptu, který na pozadí posílá b}ě_{žné HTTP požadavky na}

server. Jejich odpověď _(vě_{tšinou ve form}ě _{JSONu, XML, ale klidn}ě _{i HTML} č_{i „plain text“)}

zpracovává a vykresluje pomocí orientace v DOMu zpě_{t do webové stránky.}

Nette podporuje AJAX hned ně_{kolika zp}ů_{soby. Umí pomocí hlavi}č_{ky HTTP požadavku}

rozpoznat, zda se jedná o AJAXový požadavek nebo o „normální“. Na základě _{toho pak vykreslí bu}ď

celou šablonu, nebo pošle jen odpověď _{ve formátu JSON (tzv. payload), který zpracovává JavaScript.}

Obrázek 4: AJAXový payload v Nette

Do tohoto payloadu je možné zapsat svoje vlastní promě_{nné, jak je vid}ě_{t na p}ř_{íkladu (obrázek}

4). Daleko silně_{jší nástroj ovšem p}ř_{edstavuje vestav}ě_{ná podpora AJAXových snippet}ů_{. Díky ní lze}

udě_{lat z oby}č_{ejné aplikace AJAXovou prakticky n}ě_kolika ř_{ádky kódu. A p}ř_{itom všem aplikace pob}ě_ží

Snippety fungují tak, že př_{i prvotním (tedy neAJAXovém) požadavku se p}ř_{enese celá stránka a}

poté se př_{i každém již AJAXovém požadavku na stejnou stránku p}ř_{enáší pouze kód zm}ě_ně_ných č_ástí

ve zmíně_{ném úložišti} payload. Tím se poté pomocí JavaScriptu pouze v př_{íslušném bloku nahradí.[9]}

Na každý odkaz v HTML kódu šablony, které má tř_{ádu ajax je nav}ě_{šena akce onClick, která}

AJAXovým GET požadavkem zavolá, jeho cílovou adresu, a oč_{ekává payload v JSONu, ze kterého}

př_eč_{te obsah snippet}ů _{a t}ě_{m poté aktualizuje obsah. Obsah snippetu se do payloadu dostane tak, že je}

v šabloně _{tento blok kódu speciáln}ě _označ_{en (Latte makrem {snippet}) a kdykoliv, v}

prů_bě_{hu životního cyklu aplikace, ješt}ě _př_{ed vykreslením (viz kapitola 3.2.2) je ozna}č_{en jako}

změ_ně_ný.

V naší aplikaci se AJAXem odesílají i formulář_{e. Pomocí jQuery dopl}ň_ku

jquery.ajaxSubmit.js se z formulář_{e posbírají hodnoty a AJAXovým POST požadavkem se pošlou ke}

zpracování na presenter. Ten vrátí stejný payload jako v př_ípadě _{GETu v p}ř_{edchozím odstavci.}

3.2

Objektový návrh aplikace

3.2.1

MVP struktura

Model-View-Controller je softwarová architektura, která vznikla z potř_{eby odd}ě_{lit u aplikací}

s grafickým rozhraním kód obsluhy (controller) od kódu aplikač_{ní logiky (model) a od kódu}

zobrazujícího data (view). Tím jednak aplikaci zpř_ehledň_{uje, usnad}ň_{uje budoucí vývoj a umož}ň_uje

testování jednotlivých č_{ásti zvláš}ť_.

Model je datový a zejména funkč_{ní základ celé aplikace. Je v n}ě_{m obsažena aplika}č_{ní logika.}

Jakákoliv akce uživatele (př_{ihlášení, vložení zboží do košíku, zm}ě_{na hodnoty v databázi) p}ř_edstavuje

akci modelu. Model si spravuje svů_{j vnit}ř_{ní stav a ven nabízí pevn}ě _{dané rozhraní. Voláním funkcí}

tohoto rozhraní mů_{žeme zjiš}ť_ovat č_{i m}ě_{nit jeho stav. Model o existenci view nebo kontroleru neví.}

Pojem Model př_{edstavuje celou vrstvu, nikoliv samostatnou t}ř_ídu.

View, tedy pohled, je vrstva aplikace, která má na starost zobrazení výsledku požadavku.

Obvykle používá šablonovací systém a ví, jak se má zobrazit ta která komponenta nebo výsledek získaný z modelu.

Controller je ř_adič_{, který zpracovává požadavky uživatele a na jejich základ}ě _{pak volá}

patř_ič_{nou aplika}č_{ní logiku (tj. model) a poté požádá view o vykreslení dat. Obdobou kontroler}ů _v

Nette Framework jsou presentery.

Každý požadavek na aplikaci se dostane př_{es soubory index.php a bootstap.php do objektu}

$application. Objekt aplikace za pomocí routeru zpracuje HTTP požadavky (URL adresu a její GET parametry) a zavolá správný presenter a jeho akci kterou má vykonat. Např_{íklad uživatel chce}

zobrazit na e-shopu produkt s id=123. V aplikaci je tento požadavek v presenteru Product, akce show s parametrem id (v Nette se to bě_žně _{zapisuje Product:show id=>123). Router je ten, který na}

základě _{tohoto požadavku vygeneruje správnou url adresu (nap}ř_. www.example.com/product/show/produkt-123.html) a naopak z této adresy dokáže zpátky zjistit, že se má zavolat akce Product:show id=>123. [10]

Presenter je objekt, který vezme požadavek př_{eložený routerem a vytvo}ř_{í odpov}ěď_{. Odpov}ě_dí

mů_{že být HTML stránka, obrázek, XML dokument, soubor na disku, JSON, p}ř_esmě_{rování nebo}

cokoliv potř_{ebujete. Konkrétn}ě _{ProductPresenter požádá model o data a ty poté p}ř_{edá do šablony k}

vykreslení. Tohle se zpravidla odehraje v metodě _{renderShow, kde slovo Show odpovídá názvu akce}

a parametr požadavku id bude př_{edán jako parametr této metod}ě_:

Obrázek 5: Kód presenteru a jeho akce

Po zavolání metody render<view>(<params>) př_{ichází na} ř_{adu šablony. Šablona není nic}

jiného než samostatný php soubor, který má za úkol pouze pomocí základních php konstrukcí (foreach, for, switch, ...) vykreslovat HTML kód webu. Jak je vidě_{t na p}ř_{íkladu viz. obrázek 5,}

promě_{nné presenter šablon}ě _př_{edává p}ř_{es objekt $this->template. V tomto p}ř_ípadě _se

k promě_{nné product p}ř_{istupuje v šablon}ě _{už jen jako} $product. [11]

Nette pro šablony nabízí svů_{j LatteFilter. Latte má podobnou syntaxi znám}ě_{jšímu systému smarty}5_.

Latte se používá pro ulehč_{ení práce a správné zabezpe}č_{ení výstupu aplikace, pomocí tzv. maker.}

Např_{íklad pro vygenerování odkazu na produkt e-shopu se použije do html kódu makro {link…} viz.}

obrázek 6, kde $idProduct je promě_{nná obsahující} č_{íslo produktu.}

Obrázek 6: HTML kód s Latte makrem

Normální vykreslování promě_{nné se provádí pouze jeho zapsáním mezi složené závorky,}

takto: {$variable}. To ale neudě_{lá pouze vypsání prom}ě_{nné, ale ješt}ě _{ji escapuje,} č_{ímž samovoln}ě

chrání proti hrozbě _{Cross-site scripting (XSS). Latte filter poskytuje programátorovi spoustu}

užiteč_{ných funkcí a nástroj}ů_{, jako nap}ř_{íklad další makra, helpery (drobné užite}č_{né funkce, p}ř_{es které}

se výsledek př_{epíše), snippety apod. Více je v dokumentaci latte v [12].}

Celá naše aplikace je rozdě_{lena do 6 presenter}ů_{, pro každou sekci jeden, které d}ě_{di od}

jednoho BasePresenteru. Ten má za úkol př_{edávat do šablon i presenter}ů _{data, komponenty a metody,}

které jsou pro všechny presentery společ_{né. Všechny tyto presentery jsou uloženy ve složce}

app/presenters/.

Každý presenter má také svou defaultní šablonu v Latte souboru (pro šablonovací systém Nette frameworku) /app/templates/<Název_presenteru>.default.latte a př_ípadně _ještě _{další (místo}

default je zde potom uveden název akce presenteru).

Pro celou aplikaci vystač_{il jeden jediný model. Jeho t}ř_{ída se jmenuje stru}č_ně _{Model a je}

uložena v app/models/Model.php. Ten zajišť_{uje p}ř_{evod dat z HSConnection (knihovny pro}

komunikaci s Backendem) do správného formátu a správných objektů_{. Nap}ř_{. instancuje t}ř_ídy

Timeslot, DateTime č_{i Timewindow a stejn}ě _{tak o}č_{ekává vstupy v instancích r}ů_{zných t}ř_{íd a t}ř_ídě

HSConnection pak př_{edává jen surová data (název Timeslotu, datum ve správném formátu atp.)}

3.2.2

Životní cyklus aplikace

Jak bylo psané dř_{íve, na presenteru se volají metody render<View> (nap}ř_{. renderShow), které zp}ů_sobí

akci vykreslení šablony show s př_{edanými prom}ě_{nnými od modelu p}ř_{es presenter až do šablony.}

Render metody však nejsou zdaleka jediné které je možné na presenteru zavolat.[10]

Metoda startup(), se zavolá ihned po vytvoř_{ení presenteru. Slouží nap}ř_íklad

k inicializování promě_{nných, nebo k ov}ěř_{ení uživatelského oprávn}ě_ní.

Po ní se volá metoda action<Action> (s názvem akce, př_{edané routerem podle URL}

adresy). Je to obdoba metod s prefixem render, akorát se neoč_{ekává, že bude vykreslovat šablonu.}

Mů_{že vykonat n}ě_{jaký úkon, na}č_{íst data z databáze} č_{i ov}ěř_{it uživatelské oprávn}ě_{ní a poté bu}ď_to

př_esmě_{rovat uživatele jinam, vykreslit nap}ř_{. JSON a skon}č_{it, a nebo nic a životní cyklus pokra}č_uje

dál podle diagramu viz. obrázek 7.

Pokud nás action nikam nepř_esmě_{ruje, nebo neukon}č_{í b}ě_{h aplikace následuje vy}ř_{izování tzv.}

signálů_{. To mají za úkol metody s prefixem} handle<Signal>. Používají se př_{edevším pro ajax,} č_i

změ_{nu stavu komponenty (presenteru). Volají se z odkazu v šablon}ě _{pomocí {link signal!}

arg1,arg2…}, kde signal je název signálu. Po jejich zavolání se oč_{ekává p}ř_esmě_{rování nebo v p}ř_ípadě

ajaxu invalidace snippetů_.

Metoda beforeRender, jak už název napovídá, se volá př_{ed už n}ě_{kolikrát zmi}ň_ovanou

metodou render<View>() a mů_{že obsahovat nap}ř_{íklad nastavení šablony, p}ř_{edání prom}ě_nných

společ_{ných pro více view a podobn}ě_.

Známé render<View>() obvykle nastaví do šablony potř_{ebná data. Hned po ní se}

vyrenderuje př_{íslušná šablona.}

Jako poslední v ř_adě _je shutdown(). Ta se obvykle používá pro odpojení od vzdálených prostř_edků _{(sockety, databáze, soubor, ...) a nebo nap}ř_{íklad pro ozna}č_{ení p}ř_íspě_vků _{za p}ř_eč_{tené apod.}

V prů_bě_{hu životního cyklu se samoz}ř_ejmě _{dají využívat standartní objektové vlastnosti t}ř_ídy

Presenter. Není problém vytvoř_{it si atribut nap}ř_{íklad private $product v action do n}ě_{j na}č_{íst z}

databáze objekt, v handle na ně_{m zavolat n}ě_{jakou metodu, a v render ho p}ř_{edat šablon}ě _{k vykreslení.}

Specialitou Nette je ovšem tzv. persistentní parametr. To je bě_{žný atribut t}ř_{ídy, p}ř_{ed který}

stač_{í napsat anotaci}6 _{@persistent. Tento attribut se poté automaticky p}ř_{enáší do všech odkaz}ů

vygenerovaných př_{es Latte makro {link …}. To se dá skv}ě_{le použít nap}ř_{íklad pro stránkování} č_i ř_{azení, ale i jiné v}ě_ci.

V presenterech se ještě _{objevují metody za}č_{ínající prefixem createComponent<name>(). Ty}

vytvář_{í tzv. komponenty. Takovouto komponentou je nap}ř_{íklad každý formulá}ř_{. V této metod}ě _se

formulář _vytvoř_{í, definuje a tato metoda ho vrátí p}ř_{es return. V latte šablon}ě _{se pak jen použije makro}

{control <name>} a na komponentě _{(v našem p}ř_ípadě _formulář_{i) se zavolá metoda render(), která}

zajistí jeho vykreslení do šablony. Dalšími komponentami mů_{žou být nap}ř_{íklad r}ů_{zné DataGridy,}

stránkovač_{e, kalendá}ř_{e apod. Používání komponent velmi zvyšuje p}ř_{enositelnost kódu na další}

aplikace, což by v dnešní době _mě_{la být, p}ř_{edevším z ekonomických d}ů_vodů_{, velká priorita.}

6 _{Anotace je běžný blokový PHP komentář začínající dvěma hvězdičkami. Stejný zápis se používá například pro}

3.2.3

T

ř

ída HSConnection

Tato tř_{ída zajiš}ť_{uje komunikaci Webového rozhraní z backendem HostStats pomocí socket}ů_{. P}ř_{es její}

konstruktor se př_{edá adresa hosta a port na který se má p}ř_{ipojit a volají se na ní metody pro získávání}

dat z HostStats serveru. Výč_{et metod koresponduje s komunika}č_{ním protokolem z kapitoly 2.3. jen}

jsou jeho názvy př_{evedeny do camelCase a parametry se p}ř_{edávají jako jednotlivé parametry metody.}

Např_{íklad p}ř_{íkaz GET_TIMESLOT_DATA se zavolá metodou na objektu typu HSConnection takto:}

$obj->getTimeslotData($timeslot, $profile, $filter, $limit, $sort, $asc);

Metoda zajistí př_{ipojení k serveru p}ř_{es sockety, zaslání správného kódu typu požadavku a}

zaslání parametrů_{. Poté po}č_{ká na odpov}ěď _{od serveru a p}ř_{ijatá data vrátí v asociativním poli .}

Tato tř_{ída se dá bez jakýchkoli problém}ů _{vzít a použít v jiné aplikaci. Do frontendu HostStats}

je př_{ipojená jako služba (service) p}ř_{es konfigura}č_{ní soubor Nette. Ten jí p}ř_{ímo z configu p}ř_edá

parametry do konstruktoru (host a port) a nabídne ji pod názvem conn. Ve všech presenterech se k ní poté dá př_{istupovat p}ř_es $this->context->getService(‘conn’) nebo zkráceně $this->context->conn.

3.2.4

T

ř

ída Timeslot

Tato tř_{ída slouží k reprezentaci p}ě_{timinutových} č_{asových úsek}ů _{používaných v HostStats, tzv.}

timeslotů _{.V aplikaci pot}ř_{ebujeme pracovat jejich} č_{asovým názvem a posouvat se o timesot dozadu} č_i

dopř_{edu. Pro vyjád}ř_{ení Timeslotu ale nevysta}č_{í b}ě_{zný DateTime z PHP, takže tato t}ř_{ída od n}ě_{j d}ě_{dí, a}

nabízí další potř_{ebné metody.}

Tř_{ída má konstruktor, který zvládne vzít jakýkoliv formát} č_{asu (stejný jako DateTime) a}

navíc formát který používá HostStats (dvanáctimístného č_{íslo RRRRMMDDHHMMSS, kde R je rok,}

M je mě_{síc atp.)} Č_{as, který je do konstruktoru p}ř_{edán je také pot}ř_{eba srovnat na 5-ti minutové úseky.}

Timeslot konč_{ící nap}ř_{íklad 8 minut a 20 sekund samoz}ř_ejmě _{neexistujte, proto se zaokrohlí na 5}

minut 0 sekund.

Oproti DateTime byly také definovány nové metody. Nejdů_ležitě_{jší jsou getName(), která}

vrací název timeslotu ve formátu dvanáctimístného č_{ísla, které se používá pro komunikaci}

s HostStats. Dále pak metody getNext() a getPrev(), které posouvají timeslot na další / př_{edchozí (tzn. o 5minut dop}ř_{edu / dozadu).}

Tato tř_{ída se dá samoz}ř_ejmě _{také použít v jakékoliv jiné aplikaci pracující s timesloty.}

V př_ípadě _{že je timeslot jinak dlouhý než 5 minut, sta}č_{í zm}ě_{nit statickou konstantu LENGTH na jiný}

3.2.5

T

ř

ída Timewindow

Pro historii komunikace jednoho konkrétního hosta je potř_{eba uvád}ě_{t od kdy do kdy se mají data}

vypisovat. Tento č_{asový úsek se nazývá} č_{asové okno – timewindow. Stejnojmenné t}ř_ídě_{, která jej}

reprezentuje se v konstruktoru př_{edávají dv}ě _{instance t}ř_{ídy Timeslot (timeslot od a timeslot do), mezi}

kterými chceme definovat č_{asové okno. Z nich se automaticky dopo}č_{ítá délka} č_{asového okna, ze}

které vycházejí v podstatě _{všechny d}ů_{ležité metody.}

Metoda getTitle() zajišť_{uje slovní vyjád}ř_{ení délky okna ve stringu. Nap}ř_{íklad „1 day“, „2}

hours“, „last week“ nebo „last 2 hour“ pro minulé dvě _{hodiny do te}ď_{. Tyto informace se vypisují na}

webovém frontendu uživateli, pro lepší př_{ehled než kdyby tam bylo pouze dvakrát datum.}

Tř_{ída Timewindow op}ě_{t disponuje mimo jiné metodami getNext() a getPrev(), které}

vrací další č_{asové okno o stejné délce.}

3.2.6

T

ř

ída Nettools

V aplikaci byly zapotř_{ebí také r}ů_{zné nástroje pro práci s IP adresami a zjiš}ť_{ování informací o nich,}

Tato tř_{ída obsahuje statické metody pro zjišt}ě_{ní WHOIS záznamu, pro zjišt}ě_{ní názvu hosta podle}

adresy a také ověř_{ení validity formátu IPv4 a IPv6 adresy.}

Metoda Nettool:whois($ip, $host=null) ke zjiště_{ní WHOIS záznamu používá}

standartní unixový př_{íkaz whois s volitelným parametrem -h <host> , který slouží k ur}č_{ení whois}

serveru na kterém se má hledat. V našem př_ípadě _{se hledá na serveru whois.ripe.net (ip 193.0.6.135),}

který je nastaven v configu.

3.2.7

Zpracování chyb

Chyby jsou v celé aplikaci ošetř_{ovány za pomocí vyjímek (tzv. exceptions) a try-catch blok}ů_{. Jediné}

odchytávané výjimky v presenterech jsou potomky tř_{ídy HSCException a TimewindowException,}

jejichž zprávy jsou poté zobrazovány uživateli ve formě _{flash message ve webovém rozhraní.}

Potomky vyjímky HSCException generuje tř_ída HSConnection v př_ípadě_{, že dojde}

k chybě _př_{i komunikaci ze serverem (HSCConnectException) nebo v p}ř_ípadě _{že HostStats server}

vrátí zprávu zač_{ínající slovem „ERROR:“ (HSCBadCommandException). To se m}ů_{že stát, když}

pošleme špatný kód typu požadavku, špatné parametry požadavku nebo když server potř_{ebuje ohlásit}

ně_{jakou chybu (nap}ř_{. že nemá p}ř_{íslušná data).}

TimewindowException vyvolává tř_{ída Timewindow v p}ř_ípadě _špatně _{zadaných parametr}ů

konstruktoru.

Všechny ostatní neodchycené vyjímky jsou chyby aplikace a v př_ípadě_{, že by se n}ě_kde

3.3

Sekce Frontendu

Celý webový frontend je rozdě_{len do 5 sekcí. P}ř_{ehled, detail timeslotu, IP mapa timeslotu, historie}

hosta a detektor útoků_{. Všechny tyto sekce jsou navzájem propojené odkazy a nebo se k nim dá}

př_{istoupit z hlavního menu.}

3.3.1

Sekce Overview

Sekce „Overview“ neboli „Př_{ehled“ je hlavní stranou aplikace. Je otev}ř_{ená hned po zadání adresy,}

př_ípadně _otevř_{ení pluginu v NfSenu.}

Obrázek 8 Výř_{ez sekce Overview}

Jak je vidě_{t na obrázku 8 je zde zobrazen aktuální na}č_{tený timeslot. P}ř_ípadně _{se u n}ě_{j píše,}

jestli už je zpracovaný (zelené „Proccessed“) nebo jestli se právě _{zpracovává (modré „Processing“).}

Tzn. jestli se právě _vytvář_{í statistika. Vedle je poté po}č_{et tok}ů _{a po}č_{et host}ů _{v aktuálním timeslotu.}

Dále je ve vrchní č_{ásti ješt}ě _{informace ke kterému HostStats serveru (backendu) je frontend p}ř_ipojen č_{i se k n}ě_{mu snaží p}ř_ipojovat.

Pod tímto „ř_{ádkem“ se stavem HostStats jsou dva grafy.} Č_{erveno-oranžový uvádí historii po}č_{tu tok}ů

v jednotlivých timeslotech za posledních 12 hodin, a modrý historii poč_{tu host}ů _{v t}ě_{chto timeslotech.}

Na stránce př_{ehledu je ješt}ě _{historie detekcí útok}ů_{. Je to ta drobná tabulka vlevo dole. Uvádí}

ně_{kolik posledních dní, ve kterých byly detekovány n}ě_{jaké útoky a jejich po}č_{et. Po kliknutí na}

3.3.2

Sekce Detail

V této sekci je vidě_{t statistika kterou po}č_{ítá HostStats. Ze všech tok}ů _{v jednom timeslotu (tzn. 5ti}

minutovém č_{asovém úseku) se}č_{te p}ř_{íchozí/odchozí packety, jednotlivé typy packet}ů

(SYN,ACK,FIN..) atd. Podle tě_chto č_{ísel se poté detekují jednotlivé hrozby.}

Obrázek 9: Výř_{ez sekce Detail}

Zde, jak je vidě_{t na obrázku 9, je možné vybrat p}ř_{íslušný timeslot (po kliknutí k dispozici}

kalendář _{s výb}ě_{rem konkrétního} č_{asu). Šipkami doleva a doprava je možné se pohybovat na další} č_i

př_{edchozí timeslot (tzn o 5 minut dozadu} č_{i dop}ř_{edu) a v tabulce uvidíte vždy seznam host}ů _(IP

adres), kteř_{í v tomto} č_{asovém úseku spolu na síti komunikovali.}

Vzhledem k tomu, že takovýchto záznamů _mů_{žou být na síti desetitisíce, statisíce i víc (záleží}

na velikosti sítě_{), vypisuje se pouze N výsledku (po}č_{et se dá nastavit zm}ě_nou č_{ísla v pravém horním}

rohu tabulky). Tě_{chto N výsledk}ů _samozř_ejmě _mů_{žeme se}ř_{adit podle p}ř_{íslušného sloupce, bu}ď_{to od}

nejvě_{tšího nebo nejmenšího} č_{ísla. Dále se dají výsledky filtrovat zapsáním filtrovacího pravidla do}

kolonky „Filter“ v pravé horní č_{ásti obrazovky. Tyto filtrovací pravidla mají formát nap}ř_{. IN_ACK >}

100 && OUT_ACK = 0. Podrobně_{ji jsou popsány v dokumentaci k HostStats serveru, který má}

také za úkol je rozpoznávat a validovat. V př_ípadě _{chyby se do frontendu vrátí chybová hláška která}

je poté zobrazena uživateli.

3.3.3

Sekce IP map

Zde je vidě_{t vizualizace komunikujících host}ů _shromáždě_{ných podle prefixu IP adresy v tzv IP map}ě_.

Je to obrázek 256x256 pixelů_{, kde každý pixel odpovídá jednomu /16 prefixu (prvních 16bit}ů _{z každé}

pro odchozí a tř_{etí pro jejich rozdíl. Na té je syt}ě _modř_{e vid}ě_{t, když n}ě_{který rozsah IP adres data jen}

vysílal a sytě č_erveně _{když jen p}ř_{ijímal. Formulá}ř _{vpravo nastavuje, jestli chceme intenzitu p}ř_enosu

zobrazovat podle poč_{tu tok}ů_{, paket}ů _{nebo byt}ů_{. Dále se nastavuje rozsah zobrazení, který je vid}ě_t

zároveň _{pod mapami. Pokud je intenzita menší/v}ě_{tší než rozsah, použije se minimální/maximální}

hodnota. Pokud pixely s intenzitou mimo rozsah vů_{bec nechceme vid}ě_{t, sta}č_{í odškrtnout „View out of}

range“.

Obrázek 10: Výř_{ez sekce IP map}

V této vizualizaci mů_{žou být vid}ě_{t n}ě_{které typy útok}ů_{. Nap}ř_{íklad p}ř_{i DDOS útok}ů

s podvrženými (náhodnými) zdrojovými adresami se rozsvítí velká č_{ást bitmapy.}

Tyto mapy jsou inspirovány projektem Internet Census 20127. Stejně _{jako tam jsou zde}

prefixy IPv4 adres vykreslovány do bitmapy podle Hilbertovy kř_{ivky, takže po sob}ě _jdoucí č_ísla

(prefixy adres) se seskupují do č_{tvercových oblastí.}

3.3.4

Sekce History

Pokud potř_{ebujeme naopak v}ě_dě_{t, jak na síti komunikoval jeden host v pr}ůř_ezu č_{asu, slouží k tomu}

sekce History.

V horní č_{ásti okna je možné zadat IP adresu hosta, o kterém chceme v}ě_dě_{t informace a vedle}

toho vpravo je políč_{ko pro zadání} č_{asového okna. Pole pro výb}ě_r č_{asového okna (timewindow)}

poskytuje možnost použít př_{eddefinované hodnoty (minulá hodina, 6 hodin, 12 hodin ..) nebo zadat}

pomocí kalendář_{e p}ř_esný č_{as od kdy do kdy chceme vid}ě_{t výsledky. Dále je pak možné} č_asovým

oknem hýbat dopř_{edu a dozadu.}

Pod tě_{mito boxy na zadání „filtru“ se zobrazují samotná data v tabulce. Tabulka obsahuje,}

kromě _{prvního, stejné sloupce jako v sekci Details. V prvním sloupci se zobrazuje timeslot, ze}

kterého jsou data v tomto ř_{ádku. Timeslot je samoz}ř_ejmě _{prolinkovaný na jeho detail.}

Obrázek 11 Výř_{ez sekce History - filtr + tabulka}

Pod tabulkou následuje box s grafem. Do tohoto grafu je možné pomocí zaškrtávacích políč_ek

napravo vynést libovolné sloupce z tabulky v závislosti na č_{ase. Samoz}ř_ejmě _{má smysl porovnávat}

pouze vstupní a výstupní hodnoty stejné velič_{iny, protože jinak jsou} č_{ísla diametráln}ě _{rozdílná (nap}ř_.

poč_{et tok}ů _{a po}č_{et p}ř_{enesených byt}ů _{v nich je n}ě_{kolikanásobný).}

Obrázek 12 Výř_{ez sekce History - grafy}

Úplně _{na konci stránky se nachází výpis WHOIS}8 _{záznamu zkoumané IP adresy. Tento výpis}

se získává z unixového konzolového nástroje „whois“ a jeho syntaxe je zvýrazně_{na pomocí voln}ě

dostupné knihovny GeSHi.

3.3.5

Sekce Detectors

V této sekci se zobrazují útoky, které HostStats detekoval. V horní č_{ásti stránky je op}ě_{t možnost zadat}

datum, tentokrát celý den, ve kterém chceme zobrazit odhalené útoky. Pomocí šipek doleva a doprava se dá opě_{t pohybovat po dnech zp}ě_{t a vp}ř_ed.

Obrázek 13 Výř_{ez sekce Detectors}

Tabulka obsahuje následující sloupce:

• Timeslot – č_{asový úsek ve kterém byl útok detekov�}