}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Transakˇcn´ı a cˇ asov´a detekce odchoz´ıch DoS utok ´ u˚ ´ D IPLOMOV A´ PR ACE
Bc. Mari´an Lorenc
Brno, podzim 2015
Prohl´asˇ en´ı ˚ Prohlaˇsuji, zˇ e tato diplomov´a pr´ace je mym ım autorskym ´ puvodn´ ´ d´ılem, kter´e jsem vypracoval samostatnˇe. Vˇsechny zdroje, prameny a literaturu, kter´e jsem pˇri vypracov´an´ı pouˇz´ıval nebo z nich cˇ erpal, v pr´aci rˇ a´ dnˇe cituji s uveden´ım ´ upln´ eho odkazu na pˇr´ısluˇsny´ zdroj.
Vedouc´ı pr´ace: Mgr. V´ıt Bukaˇc, Ph.D. ii
Podˇekov´an´ı Na tomto m´ıstˇe bych r´ad podˇekoval Mgr. V´ıtu Bukaˇcovi, Ph.D., ktery´ mne v pr´aci vedl a poskytoval mi cenn´e rady a konzultace bˇehem rˇ eˇsen´ı m´e pr´ace. ˚ D´ale bych zde chtˇel podˇekovat svym kteˇr´ı mi umoˇznili studium na ´ rodiˇcum, t´eto sˇ kole a tak´e sv´e pˇr´ıtelkyni, kter´a mi byla po celou dobu oporou.
iii
Shrnut´ı C´ılem t´eto pr´ace je navrhnout symbolicky´ z´apis, kterym ´ bude moˇzno popiso´ vat s´ıt’ovou komunikaci bˇehem prob´ıhaj´ıc´ıho utoku typu odm´ıtnut´ı sluˇzby. To˚ muto n´avrhu pˇredch´azela dukladn´ a analyza ´ komunikace v r´amci jednotlivych ´ ´ ˚ Z vysledk utok u. u˚ analyzy ´ ´ byly definov´any symboly, konstanty a samotn´a synˇ ´ taxe z´apisu. Vytvoˇreny´ z´apis umoˇznuje popsat sˇ irokou sˇ k´alu DoS utok u˚ a je velmi variabiln´ı. Pˇr´ınosem t´eto pr´ace je umoˇznˇen´ı rychl´e vymˇ ´ eny cˇ itelnych ´ in´ formac´ı o struktuˇre utoku mezi vˇedci, cˇ i programy.
iv
Abstract The aim of this work is design a symbolic notation which will be possible to describe network communication during denial of service attacks. The design process was preceded by a thorough analysis of the communication during the various attacks. From the results of analyzes were defined symbols, constants and the syntax of the notation. Created notation allows you to describe a wide range of DoS attacks and is very variable. The benefit of this work is to enable the rapid exchange of readable information about the structure of attacks between scientists, or software.
v
Kl´ıcˇ ov´a slova ´ ˚ Symbolicky´ z´apis Denial Of Service, DoS, Detekce DoS utok u,
vi
Obsah 1 2
3
4
´ Uvod . . . . . . . . . . . . . . . . . . . . . . DoS utoky ´ . . . . . . . . . . . . . . . . . . . 2.1 Charakteristika s´ıt’ov´eho provozu . . . 2.1.1 IP protokol . . . . . . . . . . . . 2.1.2 HTTP protokol . . . . . . . . . ´ 2.2 Utoky typu Denial of Service . . . . . ´ 2.2.1 Historie DoS utok u˚ . . . . . . . 2.2.2 Z´aplavov´e typy (DoS flood) . . ´ 2.2.3 Utoky vyuˇz´ıvaj´ıc´ı zranitelnost´ı ´ 2.2.4 Distribuovan´e utoky . . . . . . 2.2.5 Ostatn´ı . . . . . . . . . . . . . . Existuj´ıc´ı n´astroje a zpusoby ˚ detekce . . . 3.1 N´astroje . . . . . . . . . . . . . . . . . 3.1.1 LOIC . . . . . . . . . . . . . . . 3.1.2 XOIC . . . . . . . . . . . . . . . 3.1.3 Tor’s Hammer . . . . . . . . . . 3.1.4 Switchblade . . . . . . . . . . . 3.1.5 HTTPFlooder . . . . . . . . . . 3.1.6 HOIC . . . . . . . . . . . . . . . 3.1.7 Slowloris . . . . . . . . . . . . . ˚ ´ ˚ . . 3.2 Zpusoby obrany proti DoS utok um 3.2.1 Prevence . . . . . . . . . . . . . ´ 3.2.2 Detekce DoS utok u˚ . . . . . . . ´ 3.2.3 Reakce na prob´ıhaj´ıc´ı utok . . . Definice symbolick´eho z´apisu . . . . . . . 4.1 Motivace . . . . . . . . . . . . . . . . . ´ 4.2 Analyza u˚ . . . . . . . . . . . . . . ´ utok 4.2.1 Postup analyzy . . . . . . . . . ´ 4.2.2 Vysledky analyzy ´ ´ . . . . . . . . 4.3 Symbolicky´ z´apis . . . . . . . . . . . . 4.3.1 Symboly . . . . . . . . . . . . . 4.3.2 Z´apis . . . . . . . . . . . . . . . 4.3.3 Syntaxe . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2 3 5 5 6 8 10 12 14 15 15 15 16 17 17 17 18 18 20 20 21 22 24 24 25 25 27 28 28 28 30 vii
Pˇr´ıklad vytv´arˇ en´ı z´apisu . . . . . . . ´ Definice utok u˚ . . . . . . . . . . . . . 4.5.1 TCP . . . . . . . . . . . . . . . 4.5.2 HTTP . . . . . . . . . . . . . . 4.6 N´avrh sluˇzby . . . . . . . . . . . . . 4.6.1 Change-point detection . . . 4.6.2 Signature-based detection . . 4.6.3 Machine learning . . . . . . . 4.6.4 Vyuˇzit´ı symbolick´eho z´apisu 5 Z´avˇer . . . . . . . . . . . . . . . . . . . . . A Seznam elektronickych ´ pˇr´ıloh . . . . . . 4.4 4.5
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
31 35 35 38 39 40 40 40 40 42 48
viii
Seznam obr´azku˚ 2.1 2.2 2.3
´ DDoS utoky podle druhu obˇeti (Q2 2014) [5] 6 ´ Sch´ema takzvan´eho reflektivn´ıho DoS utoku 9 Hierarchick´a struktura botnetu 13
3.1
N´astroj LOIC 16
ix
Seznam tabulek 2.1 2.2 2.3
Porovn´an´ı modelu ISO/OSI a TCP/IP [16] 3 Struktura IPv4 paketu 4 Struktura HTTP poˇzadavku / odpovˇedi 5
3.1
´ ˚ 19 Detaily n´astroju˚ pro vytv´arˇ en´ı DoS utok u.
4.1 4.2 4.3
´ cnych Tabulka rozdˇelen´ı utoˇ ´ n´astroju˚ podle protokolu˚ 26 Souhrn symbolu˚ z´apisu 29 Konstanty symbolick´eho z´apisu 32
x
Kapitola 1
´ Uvod ´ Historie Denial of Service (DoS) utok u˚ sah´a k pˇrelomu osmdes´atych a deva´ ´ cn´ıkovi pouˇz´ıt primitivn´ıch des´atych ´ let dvac´at´eho stolet´ı. V t´e dobˇe staˇcilo utoˇ ˚ Za cˇ tvrtstolet´ı techn´astroju˚ a obˇet’ zahltit souvislym ´ proudem stejnych ´ paketu. ´ cn´ıci se zaˇcali maskovat podnick´eho rozvoje se toho mnoho zmˇenilo, utoˇ ´ vrhov´an´ım IP adres, k prov´adˇen´ı utok u˚ zaˇcaly byt ´ pouˇz´ıv´any rozs´ahl´e s´ıtˇe nakaˇzenych ´ poˇc´ıtaˇcu˚ nic netuˇs´ıc´ıch uˇzivatelu˚ a mnoho dalˇs´ıho. Spousta prin˚ cipu˚ vˇsak zustala stejnych. ´ Hlavn´ım c´ılem t´eto pr´ace bylo navrhnout a definovat strukturovany´ z´apis, ´ kterym typu Denial of Service popsat a bude pouˇzitelny´ ´ bude moˇzn´e utoky ´ ˚ Pˇred samotnym pro vymˇ u. ´ enu dat pˇri detekci utok ´ n´avrhem a definic´ı bylo ˚ ehu jednotlivych ´ ˚ V r´amci t´eto nutn´e analyzovat komunikaci bˇehem prubˇ u. ´ utok ´ analyzy bylo tˇ r eba identifikovat a popsat vlastnosti, kter ymi jsou tyto utoky ´ ´ charakteristick´e a jimiˇz se odliˇsuj´ı od bˇezˇ n´eho s´ıt’ov´eho provozu. Vytvoˇren´ım symbolick´eho z´apisu vznikne prostˇredek pro vymˇ ´ enu jedno´ ıch. Symbolicky´ z´apis bude moˇzn´e znaˇcnych ´ a cˇ itelnych ´ informac´ı o DoS utoc´ pouˇz´ıt jak pro vymˇ ´ enu informac´ı mezi lidmi, tak i jako strojovˇe cˇ itelny´ form´at ˚ s informacemi o DoS utoc´ ´ ıch. pro detekˇcn´ı n´astroje, cˇ i alternativu k datasetum Pr´ace je rozdˇelena do nˇekolika logickych ´ cˇ a´ st´ı chronologicky podle toho, jak ´ byl probl´em zpracov´av´an. Uvodn´ ı pˇrehledov´a kapitola 2 je rozdˇelena na dvˇe cˇ a´ sti. V prvn´ı cˇ a´ sti je obecnˇe pops´an s´ıt’ovy´ provoz a jeho pravidla. Druh´a cˇ a´ st ´ se zabyv´ u˚ na jednotliv´e typy a popisem jejich vlastnost´ı. ´ a rozdˇelen´ım DoS utok ´ ˚ Kapitola 3 se vˇenuje n´astrojum, ˚ kter´e Struˇcnˇe je zde pops´ana historie DoS utok u. ´ cn´ıky pˇri DoS utoc´ ´ ıch a tak´e ruzn ˚ ymi ˚ jsou pouˇz´ıv´any utoˇ zpusoby obrany proti ´ ´ ˚ Samotnou analyzou ´ tˇemto utok um. jednotlivych u˚ a definic´ı symbolick´eho ´ ´ utok z´apisu se zabyv´ pr´ace. ´ a kapitola 4. Kapitola 5 shrnuje vysledky ´
1
Kapitola 2
DoS utoky ´ Tato cˇ a´ st pr´ace obsahuje informace, kter´e jsem nastudoval z dostupn´e litera´ ˚ V prvn´ı cˇ a´ sti je tury, a slouˇz´ı k pochopen´ı souvislost´ı v oblasti DoS utok u. ’ struˇcnˇe pops´an s´ıt ovy´ provoz a jeho principy vˇcetnˇe nejvyznamnˇ ejˇs´ıch proto´ ˚ N´asleduj´ıc´ı cˇ a´ st se zab´ır´a samotnymi ´ kolu. utoky typu Denial of Service, jejich ´ histori´ı a jejich dˇelen´ım.
2.1 Charakteristika s´ıt’ov´eho provozu ˚ kter´e umoˇznuj´ ˇ ı spojen´ı a vymˇ Poˇc´ıtaˇcovou s´ıt´ı se oznaˇcuje soubor n´astroju, ´ enu informac´ı mezi zaˇr´ızen´ımi na d´alku. Nejvˇetˇs´ı takovou s´ıt´ı je Internet. Do t´eto obrovsk´e celosvˇetov´e s´ıtˇe jsou pˇripojeny miliardy zaˇr´ızen´ı, a proto je komunikace na ni postavena na velmi robustn´ım z´akladˇe. Na celou s´ıt’ se lze d´ıvat z mnoha stran (smˇerov´an´ı, technologie pˇrenosu, zabezpeˇcen´ı, protokoly, atd.), z nichˇz jsou nˇekter´e v tomto dokumentu pops´any. Pro dalˇs´ı porozumˇen´ı tomuto doku˚ zit´e sezn´amit se s referenˇcn´ım ISO/OSI modelem, ktery´ popisuje mentu je duleˇ ´ jednotliv´e vrstvy komunikace, na kterych [16] ´ tak´e prob´ıhaj´ı jednotliv´e utoky. Tento model se skl´ad´a ze sedmi vrstev, z nichˇz kaˇzd´a vykon´av´a jasnˇe danou ˚ ych ´ funkci. Vrstvy na ruzn ıch spolu komunikuj´ı pomoc´ı rozhran´ı, zat´ımco ´ urovn´ ´ ˚ Jednotkomunikace na stejnych ıch prob´ıh´a prostˇrednictv´ım protokolu. ´ urovn´ liv´e vrstvy jsou pops´any v tabulce 2.1, kde jsou srovn´any s modelem TCP/IP. Jak uˇz bylo zm´ınˇeno vyˇ ´ se, s´ıt’ov´a komunikace je umoˇznˇena souˇcinnost´ı mnoha protokolu˚ na vrstv´ach OSI modelu. Datagramy jsou pˇren´asˇ eny pomoc´ı ˚ kter´e nesou jak vlastn´ı data, tak mnoho dalˇs´ıch informac´ı zajiˇst’uj´ıc´ıch paketu, samotnou komunikaci. Tyto informace jsou pˇren´asˇ eny v hlaviˇck´ach jednot˚ Souˇca´ st´ı mnoha utok ´ livych datagramu. u˚ je podvrˇzen´ı informac´ı v tˇechto ´ ´ ˚ zit´e pochopit strukturu hlaviˇck´ach. K pochopen´ı fungov´an´ı tˇechto utok u˚ je duleˇ ˚ a funkce hlaviˇcek nˇekterych ´ tˇechto protokolu. 2
´ 2. D O S UTOKY TCP/IP
ISO/OSI Aplikaˇcn´ı vrstva
Aplikaˇcn´ı vrstva
Prezenˇcn´ı vrstva Relaˇcn´ı vrstva
Transportn´ı vrstva
Transportn´ı vrstva
S´ıt’ov´a (IP) vrstva
S´ıt’ov´a vrstva
Vrstva s´ıt’ov´eho rozhran´ı
Linkov´a vrstva Fyzick´a vrstva
Tabulka 2.1: Porovn´an´ı modelu ISO/OSI a TCP/IP [16] 2.1.1 IP protokol Nejrozˇs´ırˇ enˇejˇs´ım protokolem slouˇz´ıc´ım pro pˇrenos dat na Internetu je IP protokol st´ale ve verzi 4, proto je zde pops´ana struktura jeho hlaviˇcky. Protokol funguje na s´ıt’ov´e vrstvˇe modelu ISO/OSI 2.1. [20] ´ Verze protokolu Hodnota ud´av´a verzi protokolu. Z hlediska utok u˚ nem´a zˇ a´ dny´ vyznam. Standardn´ı hodnota pro IPv4 protokol je 4. ´ ˚ IHL – D´elka hlaviˇcky Ud´av´a d´elku hlaviˇcky. Maxim´aln´ı d´elka je 60 bajtu. ˚ Typ sluˇzby Puvodnˇ e mˇelo pole slouˇzit k urˇcen´ı typu sluˇzby a t´ım k ide´aln´ımu smˇerov´an´ı datagramu. Dnes slouˇz´ı k zajiˇstˇen´ı QoS (Quality of Service). Celkov´a d´elka Celkov´a d´elka ud´avan´a v bajtech. Identifikace Jednoznaˇcny´ identifik´ator datagramu. Slouˇz´ı k identifikaci pˇri pˇr´ıpadn´em rozdˇelen´ı datagramu do v´ıce paketu˚ (tzv. fragmentace). Pˇr´ıznaky Tˇri bity, kter´e slouˇz´ı pro rˇ´ızen´ı fragmentace. Offset fragmentu Je vyuˇzit pˇri opˇetovn´em skl´ad´an´ı datagramu, ktery´ byl frag˚ Ud´av´a poˇcet osmic bytu˚ od zaˇca´ tku puvodn´ ˚ mentov´an do v´ıce paketu. ıho datagramu po zaˇca´ tek aktu´aln´ıho paketu. [20] ˚ kter´e jeˇstˇe muˇ ˚ ze paket uskuteˇcnit. Time to live (TTL) Ud´av´a poˇcet skoku“, ” ˚ S kaˇzdym smˇerovaˇcem, se dekrementuje. Pokud dos´ahne ´ pruchodem nuly, paket je zahozen. Tato technika slouˇz´ı jako ochrana pˇred zacyklen´ım. ˚ ze byt ´ cn´ıky. Pˇri nastaven´ı pˇr´ıliˇs n´ızk´e hodnoty Toto pole muˇ ´ zneuˇzito utoˇ 3
´ 2. D O S UTOKY Bit 0 32 64
0
4
8
16
Verze
IHL
Typ sluˇzby
Protokol
31
Celkov´a d´elka Pˇr´ıznaky
Identifikace TTL
19
Offset fragmentu
Kontroln´ı souˇcet hlaviˇcky
96
Zdrojov´a adresa
128
C´ılov´a adresa
160
Nepovinn´a nastaven´ı
...
Data Tabulka 2.2: Struktura IPv4 paketu
(0-1) dos´ahne TTL paketu v s´ıti obˇeti hodnoty nula a postiˇzeny´ smˇerovaˇc ´ 0, coˇz spotˇrebov´av´a jeho pot´e odes´ıl´a zpˇet zpr´avu ICMPv4 typu 11, kod ˚ ze doj´ıt aˇz k pˇret´ızˇ en´ı serstrojovy´ cˇ as. S velkym ´ poˇctem tˇechto paketu˚ muˇ ´ veru, cˇ i smˇerovaˇce. Tento typ utoku je zn´am jako TTL expiry“ [10]. ” ˇ ıslo protokolu Ud´av´a, kter´emu protokolu transportn´ı vrstvy jsou data po C´ ˇ ısla protokolum ˚ jsou pˇriˇrazov´ana organizac´ı Internet Aspˇrijet´ı pˇred´ana. C´ signed Numbers Authority (IANA). [19] Kontroln´ı souˇcet hlaviˇcky Je poˇc´ıt´an algoritmem, ktery´ je pops´an v RFC 1071 [32]. Slouˇz´ı jako kontrola poˇskozen´ı datagramu bˇehem pˇrenosu. Pokud kontroln´ı souˇcet neodpov´ıd´a uveden´e hodnotˇe, datagram je zahozen. ´ ıch typu denial Zdrojov´a adresa IPv4 adresa odesilatele. Tato adresa je pˇri utoc´ of service (DoS, cˇ esky odm´ıtnut´ı sluˇzby) velmi cˇ asto podvrˇzen´a a neprav´ ´ cn´ıci zamˇenuj´ ˇ ı zdrojov´e IP adresy, nazyv´ div´a. Utoky, pˇri nichˇz utoˇ ´ ame IP ” spoofing“. ´ ˚ ze byt C´ılov´a adresa IPv4 adresa pˇr´ıjemce. U utok u˚ typu Land muˇ ´ zdrojov´a ad˚ ze zpusobovat ˚ resa shodn´a s c´ılovou, coˇz muˇ probl´emy. [25] ˇ ıc´ı volby, kter´e mohou m´ıt ruznou ˚ Nepovinn´a nastaven´ı Doplnuj´ d´elku a hodnoty. Data Hlaviˇcky dalˇc´ıch vrstev a samotn´a data.
4
´ 2. D O S UTOKY Struktura ˇ adek poˇzadavku / odpovˇedi R´
Hlaviˇcky
Pˇr´ıklad HTTP odpovˇedi HTTP/1.1 404 Not Found Date: Sun, 18 Oct 2012 10:36:20 GMT Server: Apache/2.2.14 (Win32) Content-Length: 230 Connection: Closed Content-Type: text/html; charset=iso-8859-1
Pr´azdny´ rˇ a´ dek Tˇelo poˇzadavku / odpovˇedi
,
404 Not Found ...
Tabulka 2.3: Struktura HTTP poˇzadavku / odpovˇedi 2.1.2 HTTP protokol Bezstavovy´ protokol HTTP slouˇz´ı k pˇren´asˇ en´ı hypertextovych dokumentu˚ a ´ informac´ı [14]. Od devades´atych let byl vyuˇz´ıv´an organizac´ı W3C1 a bez nˇej ´ by dneˇsn´ı Internet tak, jak jej zn´ame, neexistoval. Informace jsou na webu ˚ ze utoˇ ´ cn´ık nˇekter´e pˇren´asˇ eny HTTP zpr´avami. Stejnˇe jako u protokolu IP muˇ ´ informace uvnitˇr zpr´avy podvrhnout a vyuˇz´ıt je k utoku. ˚ Zpr´avy se dˇel´ı na poˇzadavek (Request) a odpovˇed’ (Response) s ruznou strukturou. Poˇzadavek obsahuje rˇ a´ dek poˇzadavku, ve kter´em je specifikovan´a metoda poˇzadavku, URL a verze protokolu. Jednotliv´e poloˇzky jsou oddˇeleny ˚ ze obsahomezerami. N´asleduj´ıc´ı rˇ a´ dky slouˇz´ı k pˇrenosu hlaviˇcky, kter´a muˇ ˚ kter´e mohou byt vat mnoˇzstv´ı parametru, ´ definov´any i uˇzivatelem. N´asleduje pr´azdny´ rˇ a´ dek a samotn´e tˇelo zpr´avy. Pˇr´ıklad lze vidˇet v tabulce 2.3. ˚ zit´a pole obsahuj´ıc´ı URL a pole, kter´e Z pohledu t´eto pr´ace jsou duleˇ urˇcuje metodu poˇzadavku. Nejbˇezˇ nˇejˇs´ı jsou metody GET a POST. GET slouˇz´ı k vyˇza´ d´an´ı informac´ı, POST zˇ a´ d´a server, aby pˇrijal data pos´ılan´a klientem. ˚ kdy GET pˇred´av´a serveru parametry Dalˇs´ı rozd´ıl je v pˇred´av´an´ı parametru, jako souˇca´ st URI a POST parametry obsahuje v tˇele poˇzadavku.
´ 2.2 Utoky typu Denial of Service ´ ´ Denial of Service (DoS, cˇ esky Utoky typu odepˇren´ı sluˇzby) utoky jsou rela´ cinnym ´ ˚ Kvuli ˚ tivnˇe jednoduchym, ale velmi uˇ utok u. ´ ´ typem kybernetickych ´ ´ sv´e jednoduchosti jsou tyto utoky jedny z nejpouˇz´ıvanˇejˇs´ıch. Veˇsker´e sluˇzby 1. Odkaz na web organizace:
5
´ 2. D O S UTOKY Commerce Enterprise
29% 30% 11% Public Sector 15%
Media and Entertainment
15% High Tech
´ Obr´azek 2.1: DDoS utoky podle druhu obˇeti (Q2 2014) [5] dostupn´e na Internetu jsou poskytov´any servery, kter´e maj´ı urˇcitou konekti´ vitu a vypoˇ C´ılem DoS utok u˚ je znemoˇznit dostupnost konkr´etn´ı ´ cetn´ı vykon. ´ ´ sluˇzby, a to bud’ zahlcen´ım komunikaˇcn´ıch cest se serverem (utoky s velkym ´ datovym ´ tokem), nebo pˇret´ızˇ en´ım vypoˇ ´ cetn´ıch prostˇredku˚ serveru (CPU, pamˇet’). ´ V obou pˇr´ıpadech nen´ı bˇehem utok u˚ moˇzn´a komunikace se serverem a t´ım i se ´ sluˇzbami, kter´e poskytuje. Utoˇcn´ık v takov´em pˇr´ıpadˇe server neovl´ad´a, nezn´a ˚ administr´atorsk´a hesla, a pˇresto znemoˇzn´ı pˇr´ıstup legitimn´ım uˇzivatelum. ´ ˚ jsou ruzn´ ˚ eho typu. Nˇekter´e utoky ´ Motivace k tˇemto utok um maj´ı poli˚ ˚ tick´e duvody (kyberterorismus), jin´e se snaˇz´ı zpusobit sˇ kodu konkr´etn´ım ko˚ merˇcn´ım subjektum, jindy jde o n´aboˇzensk´e konflikty. V neposledn´ı rˇ adˇe se ´ jedn´a o vlastn´ı zviditelnˇen´ı. Nejv´ıce utok u˚ bylo ve druh´em cˇ tvrtlet´ı roku 2014 ˚ (obr´azek 2.1). uskuteˇcnˇeno proti obchodn´ım spoleˇcnostem a velkym ´ podnikum To svˇedˇc´ı o velk´em tlaku pˇri konkurenˇcn´ım boji spoleˇcnost´ı. 2.2.1 Historie DoS utok ´ u˚ ´ Prvn´ı DoS utoky se zaˇcaly objevovat koncem osmdes´atych ´ let dvac´at´eho sto´ ´ let´ı. Jedn´ım z prvn´ıch byl v roce 1989 utok typu ICMP flood (2.2.2) [23]. Utok byl velmi primitivn´ı a spoˇc´ıval v opakovan´em zas´ıl´an´ı ICMP paketu˚ Echo ” Request“ (ping) s podvrˇzenymi IP adresami (IP spoofing 2.2.5). ´ ˚ ´ cn´ıky Se vzrustaj´ ıc´ım vykonem poˇc´ıtaˇcu˚ a s´ıt’ovou konektivitou bylo pro utoˇ ´ ´ cinn´e utoky. ´ ´ ˚ byly tˇreba vykonn´ st´ale obt´ızˇ nˇejˇs´ı prov´adˇet uˇ K utok um e stroje ´ s vˇetˇs´ı konektivitou neˇz obˇet’, a proto byly cˇ asto p´ach´any prostˇrednictv´ım uni˚ ke kterym ´ verzitn´ıch poˇc´ıtaˇcu, S tˇemi se cˇ ile ´ byly ukradeny pˇr´ıstupov´e udaje. obchodovalo na cˇ ern´em trhu. 6
´ 2. D O S UTOKY V roce 1996 byla objevena slabina rodiny protokolu˚ TCP/IP a byl poprv´e ´ pouˇzit utok typu SYN flood (2.2.2), ktery´ vyt´ızˇ ´ı serverov´e prostˇredky na maxi˚ mum a zpusob´ ı jeho nedostupnost. N´asleduj´ıc´ı rok bylo vytvoˇreno mnoˇzstv´ı programu˚ vyuˇz´ıvaj´ıc´ıch chyb v nezabezpeˇcenych syst´emech. Pˇr´ıkladem mo´ hou byt ´ teardrop, boink a bonk. Ve stejn´em roce byla tak´e objevena nov´a ra´ ´ finovan´a technika utok u˚ zvan´a Smurf utok podle prvn´ıho programu, ktery´ jej ´ cn´ık k jeho proveden´ı neprov´adˇel. Jeho vyhodou bylo pˇredevˇs´ım to, zˇ e utoˇ ´ ´ ´ potˇreboval vysokou konektivitu. Utoˇcn´ıkovi staˇcilo smˇerovat utok ICMP pakety s podvrˇzenou zdrojovou adresou za adresu obˇeti na broadcastovou adresu s´ıtˇe. Vˇsechny poˇc´ıtaˇce poslouchaj´ıc´ı na broadcastov´e adrese pot´e zaˇcaly odpov´ıdat na adresu obˇeti a tak ji zahltili. Spolu s vyvojem sˇ kodlivych n´astroju˚ se vyv´ıjely i obrann´e mechanismy ´ ´ ´ ıch zneuˇz´ıv´ano. Jedinou skupinou a byly opravov´any chyby, jichˇz bylo pˇri utoc´ ´ ˚ kter´a pˇretrv´avala, byla skupina z´aplavovych ´ utok u, u˚ (2.2.2), kter´e ´ (flood) utok ´ se snaˇz´ı zahltit komunikaci se serverem. K proveden´ı utoku je tˇreba vˇetˇs´ı sˇ´ırˇ ky p´asma pˇripojen´ı, neˇz kterym ´ disponuje obˇet’. V t´eto dobˇe (1998) jiˇz neexisto˚ ´ cn´ıky st´ale valy tak velk´e rozd´ıly v konektivitˇe a z tohoto duvodu bylo pro utoˇ obt´ızˇ nˇejˇs´ı disponovat dostateˇcnˇe rychlym bylo prvn´ı ´ pˇripojen´ım. Vysledkem ´ ´ pouˇzit´ı takzvan´eho DDoS (distributed Denial of Service) utoku, ktery´ spojuje ´ v´ıce stroju˚ do jedn´e logick´e s´ıtˇe a utok je prov´adˇen spoleˇcnˇe vˇsemi stroji najednou (2.2.4). ´ ˚ DDoS utoky ´ V n´asleduj´ıc´ıch letech prob´ıhal rozvoj distribuovanych u. ´ utok jsou vˇetˇsinou prov´adˇeny ve dvou f´az´ıch. V prvn´ı prob´ıh´a vytv´arˇ en´ı botnetu ´ cn´ık se pomoc´ı cˇ ervu˚ cˇ i jin´eho malwaru snaˇz´ı z´ıskat kontrolu nad (2.2.4). Utoˇ mnoha poˇc´ıtaˇci. Tyto obˇeti (nˇekdy tak´e oznaˇcov´any jako zombies, daemons“) ” ´ jsou pot´e vyuˇz´ıv´any ke skuteˇcn´emu utoku na konkr´etn´ı c´ıl. Vyhoda takovychto ´ ´ botnetu˚ spoˇc´ıv´a v jejich znovupouˇzitelnosti, komplikovan´e obranˇe proti jejich ´ ˚ a sloˇzit´e cestˇe k odhalen´ı skuteˇcn´eho utoˇ ´ cn´ıka. utok um Roku 1999 byl rozˇs´ırˇ en jeden z nejzn´amˇejˇs´ıch programu˚ slouˇz´ıc´ıch ´ k prov´adˇen´ı DDoS utok u˚ - Trinoo. Disponoval rozs´ahlym ´ botnetem, ktery´ do˚ Spolu s n´ım bylo vytv´arˇ eno mnoˇzstv´ı sahoval velikosti nˇekolika tis´ıc d´emonu. ˚ kter´e slouˇzily ke stejn´emu uˇ ´ celu. Nˇekter´e v´ıce cˇ i m´enˇe podobnych ´ programu, z nich byly schopny aktualizace po s´ıti, cˇ i vlastn´ı reprodukce do dalˇs´ıch zaˇr´ızen´ı. ´ ´ Jedny z prvn´ıch velkych u˚ probˇehly v unoru roku 2000. Byly m´ırˇ eny ´ utok proti nejvˇetˇs´ım internetovym ´ spoleˇcnostem, jako jsou eBay, Yahoo, Amazon. ´ Utok trval nˇekolik des´ıtek hodin a nˇekter´e z webu˚ byly urˇcitou dobu nedo´ stupn´e. Za utoky byl po roce odsouzen patn´actilety´ mlad´ık pˇrezd´ıvany´ Mafia” Boy“, ktery´ pozdˇeji o incidentu napsal knihu. [7] ´ V posledn´ı dobˇe se nejzn´amˇejˇs´ımi staly DoS utoky organizovan´e hnut´ım Anonymous. Tato skupina nem´a zˇ a´ dnou pevnˇe danou hierarchii, ani jasnˇe sta7
´ 2. D O S UTOKY noveny´ c´ıl, a tak sv´e c´ıle vol´ı zcela neˇcekanˇe a nevyzpytatelnˇe [28]. Pod´ıleli se ˇ an´ım vl´adn´ıch dokumentu˚ na cˇ innosti organizace WikiLeaks, spojen´e s odtajnov´ ´ [38]. D´ale na utoku proti spoleˇcnosti Sony [42], nebo na rˇ adˇe akc´ı m´ırˇ enych ´ proti ˚ bˇehem arabsk´eho jara [35]. vl´ad´am totalitn´ıch reˇzimu, ´ ´ DDos utoky se st´avaj´ı cˇ astym ´ n´astrojem politickych ´ boju˚ napˇr´ıklad utoky ´ veden´e hnut´ım Ham´as proti Izraeli [41], cˇ i utoky spojen´e s prodemokratickymi ´ protesty v Hong Kongu [40]. S vyv´ıjej´ıc´ımi se obrannymi mechanismy a se zrychluj´ıc´ım se pˇripojen´ım ´ ´ cn´ıci vymyˇ ˚ ´ ˚ Po obˇet´ı k Internetu utoˇ utok u. ´ sleli nov´e a rafinovanˇejˇs´ı zpusoby ´ ˚ se kterymi ˚ zeme setkat. letech tak zde existuje nˇekolik typu˚ utok u, se v praxi muˇ ´ V n´asleduj´ıc´ı kapitole je velk´a vˇetˇsina z nich pops´ana. 2.2.2 Z´aplavov´e typy (DoS flood) ´ Utoky tohoto typu jsou svou podstatou ty nejjednoduˇssˇ´ı. Jejich c´ılem je vyge˚ nerovat co nejvˇetˇs´ı datovy´ tok smˇerem k obˇeti a t´ım zahltit jej´ı linku a zpusobit ˚ nedostupnost serveru, cˇ i sluˇzby pro bˇezˇ n´e uˇzivatele [12]. Z duvodu vˇetˇs´ı efektivity jsou k jejich uskuteˇcnˇen´ı cˇ asto pouˇz´ıv´any distribuovan´e poˇc´ıtaˇcov´e s´ıtˇe, takzvan´e botnety (2.2.4). ICMP Flood (ping flood) ´ Tento typ utoku vyuˇz´ıv´a ICMP pakety typu Echo Request“. Pakety jsou ” ´ cn´ık cˇ ekal na ododes´ıl´any co nejvˇetˇs´ı frekvenc´ı na adresu obˇeti, aniˇz by utoˇ povˇed’. Obˇet’ po pˇrijet´ı paketu standardnˇe odpov´ıd´a paketem Echo Reply“ ” stejn´e velikosti a t´ım svou linku zahlcuje podruh´e. Pokud objem pˇren´asˇ enych ´ datovych bloku˚ pˇrekroˇc´ı sˇ´ırˇ ku p´asma (bandwidth) dan´e linky, st´av´a se obˇet’ ´ ´ cn´ık mnohdy pos´ıl´a pakety s podvrˇzenou zdrojovou IP adnedostupnou. Utoˇ resou, viz IP spoofing“ (2.2.5). V dneˇsn´ı dobˇe jsou cˇ asto pakety tohoto typu ” filtrov´any firewally. [25] UDP Flood ´ UDP flood je dalˇs´ım typem DoS utoku, ktery´ se snaˇz´ı zahltit linku obˇeti. ´ ıch bylo cˇ asto vyuˇz´ıv´ano Vyuˇz´ıv´a transportn´ıho protokolu UDP. Pˇri tˇechto utoc´ sluˇzeb chargen [31] a echo [30] z rodiny protokolu˚ TCP/IP, kter´e pˇri spr´avn´em ´ pouˇzit´ı utoky mnohon´asobnˇe zes´ıl´ı. Sluˇzba chargen po pˇrijet´ı jak´ekoli zpr´avy odpov´ıd´a na zdrojovou adresu n´ahodnymi daty, zat´ımco sluˇzba echo na zdro´ jovou adresu pos´ıl´a stejn´a data, kter´a pˇrijala. ´ cn´ık podvrhne zdrojovou IP adresu za adresu poˇc´ıtaˇce s dobrou Pokud utoˇ konektivitou (zesilovaˇc), ktery´ poskytuje tyto sluˇzby a cˇ ´ıslo portu nastav´ı na 8
´ 2. D O S UTOKY ´ cn´ıka zpravidla hodnotu jedn´e z tˇechto sluˇzeb, zesilovaˇc zahlt´ı obˇet’ m´ısto utoˇ ´ ´ cn´ıka obdrˇzel. Utoˇcn´ık tak nepotˇrebuje k uspˇ ´ esˇ n´emu vˇetˇs´ı zpr´avou, neˇz od utoˇ ´ ´ ˚ utoku ani rychl´e pˇripojen´ı, ani vysoky´ vypoˇ c etn´ ı v ykon. Takov ymto utok um ´ ´ ´ se rˇ´ık´a reflektivn´ı [15] a jsou pouˇz´ıv´any vˇetˇsinou jako distribuovan´e (2.2.4). ´ Sch´ema reflektivn´ıho utoku je zobrazeno na obr´azku (2.2). Pro vypoˇ ´ cet ´ cinnosti utoku ´ uˇ (BAF - Bandwidth Amplification Factor) se pouˇz´ıv´a rovnice (2.1) [34]. [25] BAF =
len(UDP provoz) od zesilovaˇce k obˇeti len(UDP provoz) od utoˇ ´ cn´ıka k zesilovaˇci
Zesilovač
(2.1)
Oběť
Útočník
´ Obr´azek 2.2: Sch´ema takzvan´eho reflektivn´ıho DoS utoku TCP Flood ´ Podle pˇr´ıznaku˚ se rozliˇsuje nˇekolik typu˚ tˇechto utok u˚ (URG, ACK, PSH, ´ RST, SYN, FIN) [29]. Kromˇe utok u˚ SYN a RST Flood maj´ı vˇsechny stejnou pod´ statu jako utoky UDP a ICMP Flood. Z´aplava pakety typy SYN nen´ı klasickou z´aplavou, kter´a se snaˇz´ı pˇret´ızˇ it ´ ˚ linku obˇeti. Svou podstatou odpov´ıd´a sp´ısˇ e utok um, kter´e maj´ı za c´ıl vyˇcerpat ´ cn´ık pos´ıl´a obˇeti mnoˇzstv´ı SYN paketu, ˚ kter´e se v TCP prostˇredky obˇeti. Utoˇ komunikaci pouˇz´ıvaj´ı k nav´az´an´ı spojen´ı pomoc´ı trojcestn´eho handshakingu ´ cn´ık m´a v umyslu ´ (three-way handshake) [29]. Obˇet’ si mysl´ı, zˇ e utoˇ nav´azat spojen´ı a pokud nem´a implementov´any mechanismy pro obranu pˇred t´ımto typem 9
´ 2. D O S UTOKY ´ ˚ odeˇsle smˇerem k utoˇ ´ cn´ıkovi odpovˇed’ v podobˇe TCP paketu typu ACK utok u, a alokuje urˇcit´e zdroje pro budouc´ı spojen´ı. K tomuto spojen´ı vˇsak jiˇz nikdy nedojde a s dalˇs´ımi pˇrich´azej´ıc´ımi poˇzadavky na vytvoˇren´ı spojen´ı jsou alokov´any dalˇs´ı a dalˇs´ı dostupn´e zdroje obˇeti, dokud nedojde k jejich vyˇcerp´an´ı. Obˇet’ se pak st´av´a pro dalˇs´ı spojen´ı nedostupnou [13]. Naopak s vyuˇzit´ım RST paketu˚ ˚ ze utoˇ ´ cn´ık ukonˇcit validn´ı spojen´ı mezi dvˇema poˇc´ıtaˇci. [25] muˇ HTTP Flood ´ Utoky typu HTTP se snaˇz´ı pomoc´ı poˇzadavku˚ (nejˇcastˇeji GET, nebo POST (2.1.2)) vyˇcerpat prostˇredky dan´eho HTTP serveru. Po jejich vyˇcerp´an´ı server pˇrest´av´a byt ´ schopny´ obsluhovat dalˇs´ı poˇzadavky a st´av´a se nedostupnym. ´ ´ Tyto utoky lze vˇetˇsinou jen tˇezˇ ko odhalit od bˇezˇ n´eho provozu, a proto je obrana proti nim cˇ asto velmi obt´ızˇ n´a a existuje vˇetˇsinou ve formˇe konkr´etn´ıch pravidel ´ firewallu pro konkr´etn´ı utok. [25] Poˇzadavky jsou obvykle konstruov´any tak, aby byly co nejjednoduˇssˇ´ı a vy´ ˚ padaly jako obyˇcejny´ provoz (vˇetˇsinou ve formˇe masivn´ıch DDoS utok u), nebo naopak, aby spotˇrebov´avaly co nejv´ıce serverovych prostˇredku˚ (napˇr. ´ poˇzadavek POST ve spojen´ı s ukl´ad´an´ım dat do datab´aze). ˚ e utoky ´ ´ ´ Ruzn´ maj´ı spoleˇcn´e vlastnosti, a proto i u HTTP utok u˚ existuj´ı utoky, ´ kter´e vyuˇz´ıvaj´ı chyb, cˇ i vlastnost´ı dan´eho protokolu. Napˇr´ıklad utok, ktery´ byl proslaven n´astrojem slowloris (3.1.7), vyuˇz´ıv´a HTTP poˇzadavku˚ a snaˇz´ı se udrˇzet co nejvˇetˇs´ı poˇcet otevˇrenych ´ spojen´ı a t´ım vyˇcerpat zdroje serveru. K udrˇzen´ı spojen´ı pos´ıl´a v co nejdelˇs´ıch intervalech d´ılˇc´ı poˇzadavky. ´ HTTP slow POST utoky vyuˇz´ıvaj´ı toho, zˇ e lze pomoc´ı nich pˇren´asˇ et data. ´ Utok spoˇc´ıv´a v odesl´an´ı poˇzadavku POST, kter´emu je velikost obsahu nastavena na co nejvˇetˇs´ı velikost. Poˇzadavek je pot´e odesl´an a data jsou odes´ıl´ana co nejmenˇs´ı rychlost´ı a server je nucen udrˇzovat spojen´ı, dokud neobdrˇz´ı vˇsechna data. [8] ´ 2.2.3 Utoky vyuˇz´ıvaj´ıc´ı zranitelnost´ı ´ Skupina tˇechto utok u˚ je specifick´a t´ım, zˇ e k jejich proveden´ı nen´ı tˇreba vy´ sok´eho vykonu, cˇ i velk´e konektivity. Utoky jsou zamˇerˇ en´e na konkr´etn´ı chybu, ´ cˇ i nedostatek v implementaci protokolu, operaˇcn´ıho syst´emu, nebo programu. ´ cn´ıkovi proto staˇc´ı identifikovat tento nedostatek, cˇ i zranitelnost a spr´avnˇe Utoˇ ˚ zkonstruovanymi pakety zpusobit vyˇrazen´ı konkr´etn´ı sluˇzby z provozu. ´ Teardrop ´ Sv´eho cˇ asu (druh´a polovina 90. let) popul´arn´ı jednoduchy´ utok. Vyuˇz´ıv´a zranitelnosti nˇekterych ´ implementac´ı IP protokolu v operaˇcn´ıch syst´emech Windows 10
´ 2. D O S UTOKY i Linux. Spoˇc´ıv´a v chybn´em nastaven´ı offsetu fragmentu (2.1.1), kdy je offset ´ n´asleduj´ıc´ıho paketu umyslnˇ e nastaven na niˇzsˇ´ı hodnotu a jeho data tak zasa˚ huj´ı do sv´eho pˇredchudce. Pˇri opˇetovn´em sestavov´an´ı IP datagramu doch´az´ı ˚ k chybˇe, kter´a zpusob´ ı p´ad syst´emu. Ping of death ˚ V s´ıti Podle RFC 791 [20] je maxim´aln´ı velikost IP datagramu 65535 bajtu. ˚ ´ tak nelze vˇetˇs´ı datagram bˇezˇ nym odeslat. Podstatou tohoto utoku ´ zpusobem ´ cn´ık vˇetˇs´ı datagram fragmentuje a stejnˇe jako v pˇredchoz´ım utoku ´ je, zˇ e utoˇ chybnˇe nastav´ı offset fragmentu posledn´ıho paketu na nejvˇetˇs´ı moˇznou hodnotu. Chybnˇe nastav´ı tak´e jeho velikost tak, aby se pˇri sestavov´an´ı dostala aˇz za ˇ zminovanou hranici. Opˇetovn´e sestavov´an´ı takov´ehoto datagramu mohlo na ˚ nˇekterych chybu. Chyba je zapˇr´ıcˇ inˇena pˇreteˇcen´ım pamˇeti ´ syst´emech zpusobit ˚ ze zpusobit ˚ vyhrazen´e pro sestavovany´ datagram a muˇ aˇz p´ad syst´emu. N´azev ´ je odvozen od typu ICMP paketu, ktery´ se k utoku pouˇz´ıv´a. PDoS ´ Pojmenov´an´ı tohoto utoku poch´az´ı ze zkratky anglick´eho Permanent“, nebo ” ´ take nˇekdy Phlashing“ DoS. Tyto utoky se zamˇerˇ uj´ı na konkr´etn´ı hardware ” (napˇr´ıklad smˇerovaˇce, routery a podobnˇe). Podstatou je kompletn´ı vyˇrazen´ı ´ ˚ utoˇ ´ cn´ıka. Po z provozu dan´eho zaˇr´ızen´ı, nebo uprava jeho cˇ innosti podle vule ˚ ze z´ısk´an´ı pˇr´ıstupu k zaˇr´ızen´ı (nejˇcastˇeji chybou firmware dan´eho zaˇr´ızen´ı) muˇ ´ cn´ık libovolnˇe mˇenit obsah pamˇeti ROM, nastavovat nepovolen´e hodnoty, utoˇ ˚ vlastn´ı upraveny software. Po tomto nebo dokonce nahr´at do zaˇr´ızen´ı svuj ´ utoku je nutn´e napadeny´ hardware znovu pˇreinstalovat, nebo zcela vymˇenit. [39] Hash DoS ´ Tento pomˇernˇe novy´ utok (2011) c´ıl´ı na hashovac´ı algoritmy webovych ser´ ˚ Je nebezpeˇcny´ pˇredevˇs´ım kvuli ˚ rozˇs´ırˇ enosti hashovac´ıch algoritmu, ˚ kter´e veru. ´ jsou proti utoku zraniteln´e (napˇr´ıklad hashovac´ı funkce DJBX33A, DJBX31A ´ ˚ jednoduchosti proveden´ı utoku. ´ a DJBX33X) a kvuli Utok spoˇc´ıv´a v odesl´an´ı HTTP POST poˇzadavku, ktery´ obsahuje velk´e mnoˇzstv´ı promˇennych, kter´e ´ ´ cn´ık snaˇz´ı doc´ılit co nejvˇetˇs´ıho jsou transformov´any na stejny´ hash. T´ım se utoˇ mnoˇzstv´ı koliz´ı a dos´ahnout co nejhorˇs´ıch moˇznych u˚ pro vyhled´av´an´ı. ´ vysledk ´ Hashovac´ı funkce serveru pot´e proch´az´ı postupnˇe vˇsechny promˇenn´e na stejn´em indexu a cˇ asov´a sloˇzitost se mˇen´ı z konstantn´ı aˇz k line´arn´ı a server se st´av´a pˇret´ızˇ enym. ´ [3] 11
´ 2. D O S UTOKY 2.2.4 Distribuovan´e utoky ´ ´ Nˇekter´e typy utok u˚ (pˇredevˇs´ım z´aplavov´e) vyˇzaduj´ı ke sv´emu proveden´ı vyˇssˇ´ı ´ cn´ık potˇrebuje vypoˇ c etn´ ı v ykon, nebo konektivitu. V takov´em pˇr´ıpadˇe utoˇ ´ ´ ´ z´ıskat moc nad vˇetˇs´ım mnoˇzstv´ı poˇc´ıtaˇcu˚ a z nich pot´e v´est kontrolovany´ utok. ´ ˚ se rˇ´ık´a distribuovan´e. Obrana proti nim je velmi obt´ızˇ n´a, Takovym um ´ utok ´ cn´ık je nav´ıc ´ ˚ ych ˚ ych protoˇze utoky pˇrich´az´ı z ruzn ´ IP adres z ruzn ´ cˇ a´ st´ı svˇeta. Utoˇ ´ c´ıc´ımi poˇc´ıtaˇci a je proto tˇezˇ ko dohledatelny. kryty´ utoˇ ´ Prakticky vˇsechny DoS ´ utoky lze prov´est jako distribuovan´e.
Botnet ´ S´ıt’ poˇc´ıtaˇcu˚ slouˇz´ıc´ıch k prov´adˇen´ı utok u˚ se nazyv´ ´ a botnet. Jednotliv´e bot˚ ych nety mohou dosahovat ruzn ´ velikost´ı – od jednotek po statis´ıce, nˇekdy aˇz ˚ Botnety jsou obvykle tvoˇreny hierarchickou strukturou. Na miliony, poˇc´ıtaˇcu. ´ cn´ık, ktery´ cely´ utok ´ jej´ım vrcholu stoj´ı samotny´ utoˇ rˇ´ıd´ı. Pod n´ım se nach´az´ı ´ cn´ıkem a poˇc´ıtaˇci, poˇc´ıtaˇce (Handler), kter´e zajiˇst’uj´ı pˇrenos informac´ı mezi utoˇ ´ kter´e prov´ad´ı samotny´ utok (Agent, Bot). Struktura je zobrazena na obr´azku ´ cn´ık muˇ ˚ ze do hierarchie pˇrid´avat libovoln´e mnoˇzstv´ı urovn´ ´ 2.3. Utoˇ ı. Takov´eto ´ cn´ıka a ten je pˇres v´ıce vrstev huˇ ˚ re dohledauspoˇra´ d´an´ı zajiˇst’uje vyˇssˇ´ı kryt´ı utoˇ telny. ´ [25] ´ cn´ıkem a agenty muˇ ˚ ze prob´ıhat mnoha zpusoby. ˚ Komunikace mezi utoˇ ´ U modern´ıch utok u˚ je veˇsker´a komunikace sˇ ifrovan´a, aby nemohlo doj´ıt k od´ cn´ıci pouˇz´ıvaj´ı jak bˇezˇ n´e ´ cn´ıky. Utoˇ cizen´ı s´ıtˇe, nebo k jej´ımu ovl´ad´an´ı jinymi utoˇ ´ protokoly, tak i vlastn´ı, kter´e si sami navrhnou. Protoˇze jednotliv´e poˇc´ıtaˇce klasick´eho botnetu v sobˇe mus´ı uchov´avat informace o tom, kde se vz´ajemnˇe nal´ezaj´ı, aby spolu mohly komunikovat, je takov´e uspoˇra´ d´an´ı velmi choulostiv´e k odhalen´ı. V pˇr´ıpadˇe objeven´ı jednoho cˇ l´anku je moˇzn´e dohledat vel˚ ˚ ych kou cˇ a´ st s´ıtˇe. Z tohoto duvodu se pro komunikaci vyuˇz´ıvaj´ı sluˇzby ruzn ´ ˚ e Instant Messagery – IM). veˇrejnych ´ sluˇzeb a komunik´atoru˚ (napˇr. IRC, ruzn´ V pˇr´ıpadˇe vypadku jsou tak jednotliv´e servery jednoduˇse nahraditeln´e a infor´ mace o nov´em uspoˇra´ d´an´ı s´ıtˇe jsou jednoduˇse dostupn´e. [27] Jinym ´ typem botnetu jsou takzvan´e fast flux botnety. Tyto botnety vyuˇz´ıvaj´ı rychlych zmˇen v DNS z´aznamech (IP adresy jednotlivych z´aznamu˚ se mˇen´ı ´ ´ ˇ ı odhalen´ı struktury botnetu v rˇ a´ dech minut). Tyto praktiky velice znesnadnuj´ a jeho odstaven´ı. U tohoto typu botnetu v sobˇe nemus´ı jednotliv´e poˇc´ıtaˇce ˚ a proto ani odhalen´ı nˇekolika serveru˚ nen´ı uchov´avat adresy ostatn´ıch serveru, pro fungov´an´ı botnetu kritick´e. [6] 12
´ 2. D O S UTOKY Útočník
Handler
Handler
Agent
Agent Agent
Agent
Agent
Agent Agent
Obr´azek 2.3: Hierarchick´a struktura botnetu Vytv´arˇ en´ı botnetu ˚ ze prob´ıhat manu´alnˇe, poloautomaticky anebo nejbˇezˇ nˇeji Vytvoˇren´ı s´ıtˇe muˇ ˚ zcela automatizovanˇe. Proces lze rozdˇelit do nˇekolika kroku: •
Nalezen´ı zranitelnych ´ stroju˚
•
Prolomen´ı ochrany
•
Instalace sˇ kodliv´eho software
•
Ustanoven´ı komunikace
Hled´an´ı moˇznych obˇet´ı vˇetˇsinou spoˇc´ıv´a v hled´an´ı zraniteln´eho poˇc´ıtaˇce ´ s urˇcitym ´ operaˇcn´ım syst´emem, ktery´ poskytuje urˇcit´e sluˇzby, cˇ i jin´e vlastnosti kter´e se daj´ı zneuˇz´ıt pro ovl´adnut´ı poˇc´ıtaˇce. Toto skenov´an´ı poˇc´ıtaˇcu˚ prob´ıh´a poˇc´ıtaˇcem, ktery´ byl jiˇz napaden takzvanym ´ cˇ ervem. Ten se zcela automaticky sˇ´ırˇ´ı na vhodn´e obˇeti, podobnˇe jako chˇripka v re´aln´em svˇetˇe. Po napa´ cn´ıkem den´ı poˇc´ıtaˇce zprostˇredkuje spojen´ı mezi napadenym ´ poˇc´ıtaˇcem a utoˇ 13
´ 2. D O S UTOKY a umoˇzn´ı mu jeho kontrolu pomoc´ı takzvanych zadn´ıch vr´atek. Pot´e znovu ´ ´ cn´ık plnou kontzaˇcne hledat nov´e obˇeti a sˇ´ırˇ it se na nˇe. V tuto chv´ıli m´a utoˇ ˚ ze do ni naistalovat software pro vytvoˇren´ı botnetu. [25] rolu nad obˇet´ı a muˇ 2.2.5 Ostatn´ı IP spoofing ´ T´ımto vyrazem se oznaˇcuje odesl´an´ı paketu s umyslnˇ e zfalˇsovanou zdrojovou ´ ´ IP adresou v hlaviˇcce IP paketu (2.1.1). Pouˇz´ıv´a se u vˇetˇsiny DoS utok u˚ a slouˇz´ı ´ cn´ıka, k pˇresmˇerov´an´ı odpovˇedi na jinou adresu, nebo k zatajen´ı totoˇznosti utoˇ ´ ˚ [2] k znesnadnˇen´ı filtrov´an´ı utok u. Email bombing ´ cn´ık se snaˇz´ı obˇet’ zahltit emai´ Je to jednoduch´a, aˇz primitivn´ı forma utoku. Utoˇ ´ ˚ ´ lovymi sp´ısˇ e psychickou, neˇz penˇezˇ n´ı ujmu obˇeti. Utok ´ zpr´avami a t´ım zpusobit ´ se pro vˇetˇs´ı efektivnost pouˇz´ıv´a spoleˇcnˇe s DDoS utoky. [1] Dalˇs´ı Banana attack, XDoS
14
Kapitola 3
Existuj´ıc´ı n´astroje a zpusoby ˚ detekce V t´eto kapitole jsou pops´any jednotliv´e n´astroje, kter´e jsou n´aslednˇe podrobeny ´ ˚ kterymi analyze u, jsou cha´ sv´eho chov´an´ı. U kaˇzd´eho jsou uvedeny typy utok ´ ˚ ˚ ˚ rakteristick´e a zpusob jejich pouˇzit´ı. Dalˇs´ı cˇ a´ st t´eto kapitoly se vˇenuje zpusob um ´ ˚ detekce jednotlivych u. ´ utok
3.1 N´astroje ˚ ych ˚ ˚ at’ uˇz lepˇs´ıch, cˇ i horˇs´ıch, existuje mnoho n´astroju, ˚ kter´e lze Z ruzn u, ´ duvod ´ volnˇe vyuˇz´ıt ke generov´an´ı t´emˇerˇ jak´ehokoli typu DoS utoku. S vyuˇzit´ım tˇechto n´astroju˚ lze tak´e testovat vlastn´ı servery, jestli jsou odoln´e proti konkr´etn´ım ˚ utok ´ ˚ S t´ımto zduvodnˇ ˚ typum u. en´ım jsou vˇetˇsinou tak´e dostupn´e na bˇezˇ nych ´ serverech ke st´ahnut´ı. ˚ ymi ´ ˚ Tato cˇ a´ st obsahuje popis vybranych druhy utok u, ´ n´astroju˚ napˇr´ıcˇ ruzn ´ ˇ ı. V tabulce 3.1 jsou pˇrehlednˇe pops´any hlavn´ı vlastnosti jednotkter´e umoˇznuj´ ˚ livych ´ n´astroju. 3.1.1 LOIC LOIC (Low Orbit Ion Cannon) je jedn´ım z nejzn´amˇejˇs´ıch a nejrozˇs´ırˇ enˇejˇs´ıch programu˚ toho druhu. Podle autora s pˇrezd´ıvkou Praetox m´a slouˇzit k testov´an´ı ´ ˚ odolnosti serveru˚ proti DoS utok um, nicm´enˇe je hojnˇe vyuˇz´ıv´an pr´avˇe k jejich realizaci. Praetox po nˇejak´e dobˇe tento software vydal jako veˇrejn´e d´ılo (Pub´ u˚ vzniklo mnoˇzstv´ı n´astroju, ˚ kter´e lic domain) a se zveˇrejnˇen´ım zdrojovych ´ kod z nich vych´az´ı a vylepˇsuj´ı je, pˇr´ıpadnˇe pˇrid´avaj´ı dalˇs´ı funkcionalitu. LOIC za svou obl´ıbenost vdˇecˇ ´ı hnut´ı Anonymous, kter´e jej v roce 2008 modifikovalo ´ ˚ Anonymous je nehierarchick´e hnut´ı, a vyuˇz´ıvalo jej k prov´adˇen´ı svych u. ´ utok ˚ kter´e nem´a pevnˇe stanoven´e veden´ı, ani c´ıle. Z tohoto duvodu se i samotny´ ˚ ych ´ a Anoupraveny´ LOIC sˇ´ırˇ´ı pomoc´ı videon´avodu˚ a ruzn diskusn´ıch for ´ ” ˚ ze st´at prakticky kaˇzdy. nem“(ˇclenem Anonymous) se tak muˇ ´ Aplikace je naps´ana v jazyce C# a je dostupn´a pro vˇsechny bˇezˇ n´e desktopov´e operaˇcn´ı syst´emy (Windows, Linux, Mac OS) a dokonce i pro mobiln´ı An15
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE
Obr´azek 3.1: N´astroj LOIC droid. Za svou obl´ıbenost vdˇecˇ ´ı cˇ a´ steˇcnˇe i velmi jednoduch´emu ovl´ad´an´ı a graˇ fick´emu uˇzivatelsk´emu rozhran´ı. LOIC umoˇznuje prov´adˇet z´aplavov´e typy ´ utok u˚ promoc´ı protokolu˚ TCP, UDP a HTTP (konkr´etnˇe TCP SYN, UDP flood ´ a HTTP GET). Uskuteˇcnˇen´ı utoku je velmi jednoduch´e a rychl´e. Staˇc´ı ve for´ mul´arˇ i nastavit poloˇzky URL cˇ i IP, zvolit typ utoku, nastavit port a poˇcet vl´aken, ´ ˚ ehu utoku ´ kter´a budou utok prov´adˇet. V prubˇ je uˇzivatel informov´an ve sta˚ ehu utoku. ´ ´ esˇ nˇe a neuspˇ ´ esˇ nˇe odevov´e cˇ a´ sti o prubˇ Jsou zobrazov´any poˇcty uspˇ slanych ´ paketu˚ a dalˇs´ıch statistickych ´ hodnot. Uˇzivatelsk´e rozhran´ı programu je vidˇet na obr´azku 3.1. 3.1.2 XOIC Autorem tohoto n´astroje je program´ator s pˇrezd´ıvkou DLR (nebo tak´e david9904). Podle jeho slov na webu SourceForge.net1 , kde se nach´az´ı i zdro´ ´ cinnˇejˇs´ı neˇz vyˇ jov´e kody n´astroje, m´a byt ´ XOIC uˇ ´ se zm´ınˇeny´ n´astroj LOIC. Nepouˇz´ıv´a prostˇredky, kter´e zbyteˇcnˇe spotˇrebov´avaj´ı strojovy´ cˇ as. ˚ Opˇet umoˇznuje ˇ Napˇr´ıklad poˇc´ıtadlo odeslanych a ztracenych paketu. vy´ ´ ´ kon´avat z´aplavov´e typy utok u˚ protokoly TCP, UDP, HTTP a nav´ıc byla pˇrid´ana podpora protokolu ICMP (konkr´etnˇe TCP SYN, UDP flood, HTTP GET a ICMP flood). XOIC rovnˇezˇ poskytuje grafick´e uˇzivatelsk´e rozhran´ı, a proto je jeho 1. Zdroj:
16
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE ovl´ad´an´ı velmi snadn´e. Aplikace je dostupn´a pouze pro syst´emy Windows a to jen v novˇejˇs´ıch verz´ıch (Windows 7 a vyˇ ´ se). 3.1.3 Tor’s Hammer ´ Tento n´astroj vyuˇz´ıv´a utok u˚ typu slow POST a podle jejich autoru˚ slouˇz´ı ˚ Podle jejich popisu staˇc´ı k vyˇrazen´ı bˇezˇ ´ıc´ıho k testov´an´ı webovych serveru. ´ ´ ´ cinn´e proti nejserveru jedin´a instance programu. Utoky t´eto aplikace jsou uˇ ˚ Apache i IIS (Internet Information Services). rozˇs´ırˇ enˇejˇs´ım webovym ´ serverum ˚ Ke zpusoben´ ı jejich nedostupnosti staˇc´ı zhruba 256 vl´aken programu. Hlavn´ım rysem programu je moˇznost anonymizace jeho provozu pomoc´ı s´ıtˇe Tor, z cˇ ehoˇz vyplyv´ ´ a i jeho n´azev. Software je naprogramov´an v jazyce Python a je tedy multiplatformn´ı. N´astroj neobsahuje uˇzivatelsk´e rozhran´ı a jedn´a se tedy o konzolovou aplikaci, ´ jej´ızˇ utoky lze skriptovat. Pouˇzit´ı je vzhledem k jednoduchosti programu velmi jednoduch´e. 3.1.4 Switchblade Switchblade2 je n´astroj vytvoˇreny´ organizac´ı OWASP (Open Web Application Security Project), kter´a se zabyv´ ´ a bezpeˇcnost´ı na Internetu. M´a slouˇzit pro ´ z´atˇezˇ ov´e testov´an´ı webovych typu slowloris a slow ´ serveru˚ Apache a IIS utoky POST. Je naps´an v jazyce C++ a je dostupny´ pro operaˇcn´ı syst´emy Windows. Program m´a pˇrehledn´e uˇzivatelsk´e rozhran´ı, ve kter´em lze vybrat typ ´ pouˇzit´eho utoku, poˇcet spojen´ı, jejich frekvenci a d´elku. Lze tak´e zvolit, jestli se ´ pˇri utoku maj´ı pouˇz´ıt poˇzadavky GET, nebo POST. 3.1.5 HTTPFlooder ´ ˚ Lze s n´ım prov´adˇet jak z´aplavov´e Tento program nab´ız´ı sˇ irokou sˇ k´alu utok u. ´ ´ utoky (HTTP), tak utoky typu slowloris, slow POST, hash DoS a nˇekolik dalˇs´ıch. Poskytuje tak´e velk´e mnoˇzstv´ı nastaven´ı. Kromˇe obvyklych ´ moˇznost´ı ´ jakymi jsou nastaven´ı d´elky utoku, jejich frekvence a poˇctu vl´aken, lze zvo´ ˚ nastaven´ı jejich parametru˚ a mnoho lit uˇzivatelsk´e hlaviˇcky HTTP poˇzadavku, dalˇs´ıho. N´astroj je naps´an jako skript v jazyce Perl. Z toho vyplyv´ ´ a, zˇ e je platformnˇe ˚ ´ nez´avisly. Z tohoto d uvodu tak´ e neobsahuje z a dn´ e uˇ z ivatelsk´ e rozhran´ı. ´ ˇ 2. Zdroj:
17
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE 3.1.6 HOIC HOIC (High Orbit Iont Cannon) je jedn´ım z dalˇs´ıch n´astroju˚ vych´azej´ıc´ıch ˚ z puvodn´ ıho programu LOIC. I tento software byl cˇ asto vyuˇz´ıv´an skupinou ´ Anonymous. Na rozd´ıl od programu LOIC je zamˇerˇ en pouze na utoky typu ´ HTTP flood, poskytuje vˇsak v´ıce moˇznost´ı nastaven´ı samotn´eho utoku a jeho ˚ Jsou to jednoduch´e hlavn´ı vyhoda spoˇc´ıv´a v pouˇzit´ı takzvanych Boosteru“. ´ ´ ” ˚ ze utoˇ ´ cn´ık libovolnˇe upravovat odchoz´ı poˇzadavky, nastaskripty, kterymi muˇ ´ vit frekvenci jejich odes´ıl´an´ı a mˇenit dalˇs´ı parametry (napˇr. URL obˇeti, User agent, HTTP referer) tak, aby kaˇzdy´ poˇzadavek vypadal jako legitimn´ı a zne´ snadnil tak detekci samotn´eho utoku. Program je distribuov´an jako spustitelny´ *.exe soubor a je tedy dostupny´ pouze pro operaˇcn´ı syst´em Windows. Obsahuje grafick´e uˇzivatelsk´e rozhran´ı, kter´e je velmi podobn´e n´astroji LOIC. 3.1.7 Slowloris ´ Program ve velk´em Tento software definoval novy´ stejnojmenny´ typ utoku. mnoˇzstv´ı otev´ır´a spojen´ı se serverem obˇeti. Jejich prostˇrednictv´ım pak pos´ıl´a HTTP poˇzadavky, kter´e vˇsak nejsou kompletn´ı. Obˇet’ cˇ ek´a na dokonˇcen´ı ´ cn´ık udrˇzuje co nejdelˇs´ı cˇ asov´e poˇzadavku a udrˇzuje tak spojen´ı aktivn´ı. Utoˇ prodlevy (aby nevyprˇsel cˇ asovy´ limit a obˇet’ neukonˇcila spojen´ı) a postupnˇe pos´ıl´a dalˇs´ı cˇ a´ sti poˇzadavku. Mezi t´ım obˇet’ st´ale udrˇzuje aktivn´ı spojen´ı. Pro kaˇzd´e otevˇren´e spojen´ı si server obˇeti alokuje urˇcit´e prostˇredky. Po vyˇcerp´an´ı ˚ ze otev´ırat nov´a spojen´ı a st´av´a se nedostupnou. tˇechto prostˇredku˚ obˇet’ nemuˇ N´astroj je naprogramovany´ jako skript v jazyce Perl a je bez uˇzivatelsk´eho rozhran´ı. Neofici´alnˇe existuje i IPv6 verze programu.
18
Slow POST Slow POST, Slow eaders, SSL renegotiation Flood (HTTP) Flood (HTTP) Slow POST Slow POST
1.0
4.0.1
1.0
2.1.003
0.7
2.2
Tors hammer
SwitchBlade
HTTPflooder
Hoic
slowloris
R-U-Dead-Yet
EA092D2258E80A4A7122059E34FA6287 451C94A23536DCBBA422D7612B34B6FF A7525A7E621CA98E16B77E31756800EF 3DEA97765EA00E60062284C493E498FB 9851EC582AEE27DDFDC966FC4CE9FFD9
´ ˚ Tabulka 3.1: Detaily n´astroju˚ pro vytv´arˇ en´ı DoS utok u.
N´astroj LOIC XOIC Tors hammer SwitchBlade HTTPflooder Hoic slowloris R-U-Dead-Yet Hulk
HTTP
HTTP
HTTP
HTTP
HTTP
HTTP
TCP, UDP, ICMP
TCP, UDP, HTTP
Protokoly
MD5 E6FA3028CD03318496852718143D256F B6C4E2C4FA384212126D7DBB832460C9 6ACDB872B766F089EAC3ADA04043C444
Flood (TCP, UDP, ICMP)
1.3
XOIC
Autor Praetox Technologies DLR (david9904) OWASP Robert Hansen (RSnake) ravivr Barry Shteiman
Flood (TCP, UDP, HTTP)
1.0.8.0
LOIC
Hulk
Typy utok ´ u˚
Verze
N´astroj
Ne
Ne
Ne
Ne
Ne
Ne
Ne
Ne
Admin. pr´ava
Ne
Ne (ano)
Ano
Ne
Ano
Ne
Ano
Ano
GUI
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE
3.2 Zpusoby ˚ obrany proti DoS utok ´ um ˚ ´ Proti rostouc´ımu poˇctu a s´ıle DoS utok u˚ je tˇreba adekv´atn´ı obrana. Pˇrirozenym ´ ´ ˚ e zpusoby ˚ vyvojem se spolu s DoS utoky vyv´ıjely i ruzn´ obrany proti nim. Lo´ gicky lze tyto postupy a opatˇren´ı rozdˇelit do tˇr´ı kategori´ı, kterymi jsou: ´ •
Prevence
•
´ Detekce DoS utoku
•
´ Reakce na prob´ıhaj´ıc´ı utok
V t´eto podkapitole jsou pops´any nˇekter´e obecn´e postupy i konkr´etn´ı korpor´atn´ı rˇ eˇsen´ı, kter´a jsou poskytov´ana tˇret´ımi stranami jako placen´e sluˇzby. 3.2.1 Prevence ´ cn´ıkovi zabr´anily utok ´ ˚ Postupy prevence slouˇz´ı k tomu, aby utoˇ vubec uskuteˇcnit. I kdyˇz poskytovatel´e internetov´eho pˇripojen´ı (ISP) disponuj´ı urˇcitymi moˇznostmi a ve v´azˇ nych pˇr´ıpadech mohou proti prob´ıhaj´ıc´ım DoS ´ ´ ´ ˚ zakroˇcit [18], hlavn´ı zodpovˇednost za bezpeˇcnost v s´ıti m´a vˇzdy jej´ı utok um ˚ zit´e, aby se dostateˇcnˇe vˇenoval veˇskerym provozovatel. Je proto velmi duleˇ ´ moˇznostem preventivn´ıch opatˇren´ı. Naprosto z´akladn´ım pravidlem, kter´e plat´ı jak pro velk´e s´ıtˇe organizac´ı, tak pro mal´e dom´ac´ı s´ıtˇe, je udrˇzovat veˇsker´e syst´emy aktualizovan´e. Vˇetˇsina chyb, ´ cn´ıci mohli vyuˇz´ıt prostˇrednictv´ım utok ´ kterych u˚ vyuˇz´ıvaj´ıc´ıch zranitel´ by utoˇ nost´ı (2.2.3), je neprodlenˇe po jejich odhalen´ı opravena a jsou vyd´any aktualiˇ ı tak proveden´ı utoku. ´ zace, kter´e chybu opravuj´ı a zabranuj´ Na hraniˇcn´ıch prvc´ıch s´ıtˇe je vhodn´e zav´est konkr´etn´ı pravidla, kter´a ome˚ ˚ Konkr´etnˇe zuj´ı, nebo zcela zakazuj´ı pruchod urˇcitych ´ paketu˚ nebo celych ´ toku. ´ ıch (2.2.2). se jedn´a napˇr´ıklad o ICMP provoz, ktery´ je cˇ asto pouˇz´ıv´an pˇri utoc´ Dalˇs´ım doporuˇcen´ım je omezit pomˇer pˇr´ıchoz´ıch SYN paketu˚ ke zbytku pro´ ˚ zitou souˇca´ st´ı levozu. SYN pakety nelze uplnˇ e zak´azat, protoˇze jsou duleˇ gitimn´ıho provozu, ale jejich pomˇer k celkov´emu provozu na s´ıti by nemˇel ˚ zitym pˇrekroˇcit urˇcitou hranici [25]. Duleˇ ´ krokem je tak´e zav´est kontrolu zdrojovych adres paketu˚ (takzvany´ Reverse Path Forwarding [11]), kter´a zabr´an´ı ´ podvrˇzen´ı zdrojovych ´ adres (IP spoofing 2.2.5). V r´amci prevence je vhodn´e, aby si kaˇzd´a organizace stanovila takzvany´ Business contingency plan. Pro tento pl´an si organizace definuje opatˇren´ı a re´ akce pro pˇr´ıpad prob´ıhaj´ıc´ıho DoS utoku. C´ılem tohoto pl´anu je zachov´an´ı bezpeˇcnosti a bezprobl´emov´eho chodu vˇsech kritickych ´ syst´emu˚ v organizaci. 20
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE Pˇred vypracov´an´ım samotn´eho pl´anu by si kaˇzd´a organizace mˇela nejprve de´ finovat vˇsechna zraniteln´a m´ısta, kter´a by mohla byt postihnuta (rou´ utokem ter na perimetru, router uvnitˇr s´ıtˇe, firewall, server, nebo jen konkr´etn´ı aplikace). Dalˇs´ım krokem je stanoven´ı do jak´e m´ıry jejich vypadek ovlivn´ı chod or´ ganizace. Vysledkem by mˇel byt ´ ´ prioritnˇe seˇrazeny´ seznam zranitelnost´ı, nad ´ kterym [37] ´ lze vypracovat cely´ pl´an pro pˇr´ıpad utoku. 3.2.2 Detekce DoS utok ´ u˚ ´ ˚ ale nikdy Kvalitn´ı prevence velmi omez´ı mnoˇzstv´ı proveditelnych utok u, ´ ´ ˚ nezajist´ı naprostou ochranu pˇred vˇsemi utoky. Z tohoto duvodu je nutn´e ´ ˚ Pro detekov´an´ı utok ´ vˇenovat prostˇredky i na detekci prob´ıhaj´ıc´ıch utok u. u˚ lze ˚ Kaˇzdy´ z nich pˇristupuje k rˇ eˇsen´ı probl´emu trochu jinym vyuˇz´ıt v´ıce pˇr´ıstupu. ´ ˚ ˚ zpusobem. Nejbˇezˇ nˇejˇs´ı zpusoby detekce lze rozdˇelit do dvou skupin. Jedn´a se o signaturovy´ pˇr´ıstup (porovn´av´an´ı signatur) a detekci anom´ali´ı. [22] [36] [21] Porovn´av´an´ı signatur Tento pˇr´ıstup monitoruje s´ıt’ovy´ provoz a porovn´av´a hodnoty atributu˚ hlaviˇcek jednotlivych paketu˚ a obsah paketu˚ s datab´az´ı signatur. Datab´aze obsahuje ´ ˚ kter´e se vyskytuj´ı v paketech zn´amych ´ ˚ Spolu s tˇemito mnoˇzstv´ı rˇ etˇezcu, u. ´ utok ˚ e kombinace zdrojovych rˇ etˇezci jsou v datab´azi uchov´av´any ruzn´ ´ a c´ılovych ´ IP ˚ Pˇri porovn´av´an´ı se vyuˇz´ıvaj´ı rychl´e algoritmy jako napˇr´ıklad adres a portu. Aho-Corasick, Commentz-Walter, cˇ i varianty zaloˇzen´e na regul´arn´ıch vyrazech. ´ ˚ Nevyhodou tohoto zpusobu je vysok´a n´aroˇcnost na prostˇredky pˇri vyhled´av´an´ı ´ a s t´ım souvisej´ıc´ı zpomalov´an´ı vyhled´av´an´ı s rostouc´ı velikost´ı datab´aze. ˚ ˚ nen´ı Protoˇze tento zpusob porovn´av´a konkr´etn´ı rˇ etˇezce a kombinace atributu, ´ ˚ [22] [36] schopen rozpozn´avat nov´e typy utok u. Detekce anom´ali´ı Pˇr´ıstupy zaloˇzen´e na detekci anom´ali´ı jsou schopny uˇcen´ı, a t´ım i roz´ ˚ coˇz je jejich hlavn´ı vyhodou ˚ ˚ pozn´av´an´ı novych u, oproti zpusob um ´ typu˚ utok ´ porovn´avaj´ıc´ım signatury. Obecnˇe se tyto techniky detekce skl´adaj´ı ze dvou ˚ pˇredkl´ad´an bˇezˇ ny´ s´ıt’ovy´ provoz. T´ım je f´az´ı. V prvn´ı f´azi uˇcen´ı je algoritmum vytvoˇren urˇcity´ vzor (profil). Ve druh´e f´azi prob´ıh´a samotn´a detekce anom´ali´ı re´aln´eho provozu vzhledem k vytvoˇren´emu profilu. Za anom´alii je povaˇzov´ano to, co je detekov´ano v s´ıti a pˇritom nen´ı obsaˇzeno v modelu vytvoˇren´em ve f´azi ˚ kter´e muˇ ˚ zeme rozdˇelit podle zpusobu ˚ uˇcen´ı. Existuje mnoˇzstv´ı pˇr´ıstupu, detekce a uˇcen´ı na statistick´e, strojov´e uˇcen´ı (machine learning) a vytˇezˇ ov´an´ı dat (data mining). [21] 21
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE Statistick´a detekce anom´ali´ı Statistick´e metody detekce rozpozn´avaj´ı anom´alie na z´akladˇe mˇerˇ itelnych odchylek v provozu. Porovn´av´a se ´ ˚ napˇr´ıklad mnoˇzstv´ı pˇrenesenych dat na kaˇzdou IP adresu, poˇcet paketu, ´ ˚ Tento druh detekce je uspˇ ´ esˇ ny´ nebo urˇcit´e znaky v hlaviˇck´ach paketu. ´ hlavnˇe pˇri odhalov´an´ı z´aplavovych utok u˚ zaloˇzenych na velk´em da´ ´ ´ ˚ kter´e jsou zaloˇzeny na vyuˇzit´ı tov´em provozu. Naopak detekce utok u, ˚ ych ˚ ze cˇ init probl´emy. Statistick´e metody jsou ruzn zranitelnost´ı mu muˇ ´ velmi podobn´e metod´am porovn´avaj´ıc´ım signatury, ale dok´azˇ ´ı se uˇcit ´ a odhalovat i nezn´am´e utoky. [21] [36] ˚ Strojov´e uˇcen´ı Zpusoby detekce zaloˇzen´e na strojov´em uˇcen´ı neporovn´avaj´ı ’ s´ıt ovy´ provoz s konkr´etn´ımi hodnotami jako pˇredchoz´ı pˇr´ıstupy. Anom´alie odhaluj´ı na z´akladˇe urˇcitych pravidel a bˇehem vyhodno´ ´ esˇ nosti cov´an´ı jsou schopny neust´al´eho sebezdokonalov´an´ı podle uspˇ konkr´etn´ıch pravidel. Z´akladem velk´eho mnoˇzstv´ı metod jsou bayesovsk´e s´ıtˇe (Bayesian Networks), vyuˇz´ıvaj´ıc´ı grafick´e zn´azornˇen´ı pravdˇepodobnostn´ıch vztahu˚ mezi konkr´etn´ımi jevy. Jelikoˇz metoda vyhodnocuje s´ıt’ovy´ provoz jako komplexn´ı syst´em a zamˇerˇ uje se na vztahy ´ esˇ n´a pˇri detekci distribuovanych mezi konkr´etn´ımi jevy, je velmi uspˇ ´ DoS ´ ˚ kter´e mohou v pˇr´ıpadˇe jinych ˚ utok u, skryty. [21] [36] ´ metod zustat Vytˇezˇ ov´an´ı dat Tato velmi komplexn´ı metoda vyhled´av´a na vzorku dat s´ıt’ov´eho provozu urˇcit´e vzory a odchylky od norm´aln´ıho provozu prostˇrednictv´ım takzvan´e fuzzy logiky, kter´a na rozd´ıl od klasick´e vyrokov´ e logiky nepracuje pouze se dvˇema hodnotami, ale s m´ırou ´ pravdivosti urˇcit´eho vyroku. Pro d´ılˇc´ı cˇ innosti pˇri vyhodnocov´an´ı jsou ´ vyuˇz´ıv´any i statistick´e metody a dalˇs´ı jednoduˇssˇ´ı algoritmy, kter´e jsou souˇca´ st´ı cel´eho komplexn´ıho syst´emu vyhodnocuj´ıc´ıho s´ıt’ovy´ provoz. [21] [36] 3.2.3 Reakce na prob´ıhaj´ıc´ı utok ´ ´ cn´ıkovi V pˇr´ıpadˇe, zˇ e se i pˇres vˇsechny preventivn´ı opatˇren´ı podaˇr´ı utoˇ ´ uskuteˇcnit DoS utok, je vyˇzadov´ana rychl´a reakce na stranˇe obˇeti pro co nejvˇetˇs´ı ´ zm´ırnˇen´ı n´asledku˚ utoku. Aby reakˇcn´ı doba byla co nejkratˇs´ı, je vhodn´e m´ıt pˇripraven´e reakˇcn´ı sc´en´arˇ e a havarijn´ı tym, kde budou jasnˇe definov´any role. ´ ’ ˚ m´a jinou rozlohu, jej´ı fungov´an´ı je Kaˇzd´a s´ıt je jin´a, skl´ad´a se z jinych ´ prvku, kritick´e pro bˇeh jinych sluˇzeb, a proto nelze definovat jeden univerz´aln´ı po´ stup, jak se v takov´e situaci chovat. Existuj´ı vˇsak urˇcit´e spoleˇcn´e postupy, kter´e ´ lze aplikovat v jak´ekoli situaci. Z´akladn´ı reakce na prob´ıhaj´ıc´ı utok jsou uvedeny napˇr´ıklad ve white paperu spoleˇcnosti Cisco [9]. 22
´ ˚ 3. E XISTUJ´I C´I N ASTROJE A ZP USOBY DETEKCE ´ ´ Z´asadn´ı reakc´ı na utok by mˇelo byt Lze ´ filtrov´an´ı datov´eho provozu utoku. to uˇcinit napˇr´ıklad manu´alnˇe, kdy z logu˚ s´ıt’ov´eho provozu zjist´ıme IP adresy ´ ˚ zeme ve firewallu zak´azat. a porty, ze kterych a ty pot´e muˇ ´ je smˇerov´an utok, Dalˇs´ı moˇznost´ı je vyuˇzit´ı nˇekter´eho z IDS (Instruction Detection System ˚ ˚ Tyto syst´emy vyuˇz´ıvaj´ı pro odhalen´ı Syst´em pro odhalen´ı pruniku) syst´emu. ´ utok u˚ technik popsanych ´ v pˇredchoz´ı kapitole (3.2.2). Po odhalen´ı prob´ıhaj´ıc´ıho ´ utoku syst´em bud’to vygeneruje upozornˇen´ı, a nebo s´am zablokuje konkr´etn´ı sˇ kodliv´e aktivity v s´ıti.
23
Kapitola 4
Definice symbolick´eho z´apisu C´ılem t´eto pr´ace bylo vytvoˇren´ı a zdokumentov´an´ı symbolick´eho z´apisu, ´ kterym DoS utok. Samotn´emu vyvoji z´apisu ´ by bylo moˇzno postihnout jakykoli ´ ´ ˚ ´ pˇredch´azela dukladn´ a analyza u˚ zaznamenanych ´ utok ´ ve form´atu pcap (packet ´ ˚ ych capture). Jednotliv´e utoky byly analyzov´any v ruzn ´ proveden´ıch co se tyˇ ´ ce ˚ ´ nastaven´ı, a tak´e s ruznou dobou trv´an´ı. Tato forma analyzy u˚ mi umoˇznila ´ utok ˚ odhalit nˇekter´e souvislosti, kter´e by jinak zustaly skryt´e. ˚ Prvn´ı cˇ a´ st t´eto kapitoly rozv´ad´ı hlavn´ı duvody pro vytvoˇren´ı nov´eho ˚ ´ ˚ Ve druh´e cˇ a´ sti kapitoly je pops´an prubˇ ˚ eh analyzy, zpusobu z´apisu utok u. ´ pouˇzity´ software a z´avˇery plynouc´ı z analyzy. V n´asleduj´ıc´ı cˇ a´ sti je definov´an ´ samotny´ symbolicky´ z´apis, jeho syntaxe a s´emantika. N´asleduj´ıc´ı cˇ a´ st obsahuje ´ n´azorny´ pˇr´ıklad vytvoˇren´ı takov´eho z´apisu pro konkr´etn´ı utok. Na konci kapi´ ˚ toly jsou uvedeny uk´azky z´apisu˚ nˇekolika zkoumanych u. ´ utok
4.1 Motivace Hlavn´ı motivac´ı pro vytvoˇren´ı symbolick´eho z´apisu bylo vytvoˇren´ı mecha´ nismu, kterym vˇcetnˇe opakuj´ıc´ıch ´ by bylo moˇzno jednoznaˇcnˇe popsat utoky ´ ´ se usek u˚ komunikace, kter´e utoky produkuj´ı. Takovyto ´ z´apis by v budoucnu ´ mohl byt u˚ typu odm´ıtnut´ı ´ vyuˇzitelny´ pro jednoznaˇcnou detekci odchoz´ıch utok sluˇzby. ´ cely existuje jen minimum datasetu˚ o DoS utoc´ ´ ıch se Pro vyzkumn´ e uˇ ´ ˚ ehu utok ´ ˚ Pomoc´ı nov´eho symbolick´eho z´apisu by bylo z´aznamem prubˇ u. ´ moˇzn´e evidovat popisy mnoha utok u˚ v kompaktn´ım form´atu. Z´arovenˇ tak vznikne prostˇredek, ktery´ umoˇzn´ı jednoduˇse a rychle porovn´avat vstupn´ı ´ ˚ Novym podm´ınky experiment´aln´ıch studi´ı tykaj´ u. ´ ıc´ıch se DoS utok ´ symbolickym ´ z´apisem tak bude moˇzno popsat jednotliv´e datasety a zefektivnit cˇ innost ˚ ych vyzkumn ´ ´ tym ´ u. ˚ kter´e jsou schopny analyzovat soubory a proExistuje nˇekolik n´astroju, gramy podle urˇcitych pravidel (n´azev, bin´arn´ı obsah, hash a podobnˇe) a jsou ´ ˚ Jedn´a se tak schopny detekovat malware a dalˇs´ı typy sˇ kodlivych n´astroju. ´ 24
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU napˇr´ıklad o frameworky YARA1 a OpenIOC2 . Ani jeden ovˇsem nedisponuje ´ ˚ prostˇredky pro jednoduch´e a cˇ iteln´e pops´an´ı s´ıt’ov´eho provozu DoS utok u. Impulsem pro vyvoj zcela nov´ e ho z´ a pisu byla absence jednoznaˇ c n´eho ´ form´atu, s jehoˇz pomoc´ı by si nejen stroje, ale i lid´e byli schopni pˇred´avat infor´ ˚ Z tohoto duvodu ˚ mace o struktuˇre DoS utok u. pˇribylo k jednoznaˇcnosti dalˇs´ı krit´erium – cˇ itelnost. Novy´ symbolicky´ z´apis by proto mˇel byt ´ co nejstruˇcnˇejˇs´ı ´ a cˇ itelnˇe strukturovany. jednoznaˇcnˇe popsat a mˇel ´ Z´arovenˇ by mˇel umˇet utok by byt ´ dostateˇcnˇe obecny, ´ aby byl schopen vyj´adˇrit jakoukoli moˇznou variantu ´ utoku i v budoucnu. Strojovou cˇ itelnost z´apisu mohou vyuˇz´ıt detekˇcn´ı n´astroje, kter´e budou ´ ´ schopny odhalit prob´ıhaj´ıc´ı utok na z´akladˇe utok u˚ popsanych symbolickym ´ ´ z´apisem. Jak by mohl takovy´ detekˇcn´ı n´astroj vypadat, je nast´ınˇeno v kapitole 4.6.
4.2 Analyza ´ u˚ ´ utok ´ Analyza u˚ prob´ıhala formou detailn´ıho rozboru s´ıt’ov´e komunikace zazna´ utok ´ ´ c´ıc´ıho poˇc´ıtaˇce. K dispozici jsem menan´e bˇehem utoku na s´ıt’ov´em rozhran´ı utoˇ ´ ˚ Data v tomto form´atu obmˇel pˇres 120 z´aznamu˚ utok u˚ ve formˇe pcap souboru. ´ sahuj´ı kompletn´ı detailn´ı informace o s´ıt’ov´e komunikaci na urovni jednotlivych ´ ˚ Celkovˇe se jednalo o utoky ´ ˚ ymi paketu. generovan´e 22 ruzn programy 4.1. ´ ’ Bˇehem analyzy jsem ve zkoumanych vzorc´ıch s´ıt ov´e komunikace hledal ´ ´ jak´ekoli anom´alie, kter´e jsou odliˇsn´e od bˇezˇ n´eho provozu. Pˇri vyhled´av´an´ı ´ anom´ali´ı a vzorcu˚ chov´an´ı signifikantn´ıch pro jednotliv´e utoky jsem vyuˇz´ıval n´astroje Wireshark3 a Splunk4 . Kaˇzdy´ z tˇechto n´astroju˚ mi umoˇznil zkoumat za´ chycen´e utoky z jin´eho pohledu. Pomoc´ı Wiresharku jsem byl schopen detailnˇe analyzovat vlastnosti kaˇzd´eho paketu zvl´asˇ t’, zat´ımco Splunk mi umoˇznil uce´ leny´ pohled nad celym d´ıky jeho schopnosti rychle vyhled´avat, filtrovat ´ utokem a analyzovat velk´e mnoˇzstv´ı strojovych ´ dat. 4.2.1 Postup analyzy ´ ´ Utoky jsem rozdˇelil do dvou skupin podle typu protokolu, prostˇrednictv´ım ´ ´ kter´eho utok prob´ıhal. Jedna skupina utok u˚ ke sv´e cˇ innosti vyuˇz´ıv´a pouze pro´ tokol TCP, druh´a v r´amci utoku pouˇz´ıv´a protokol aplikaˇcn´ı vrstvy HTTP 4.1. To ´ ˚ z kaˇzd´e skupiny jsem pˇristupoval jsem zohlednil i bˇehem analyzy um ´ a k utok m´ırnˇe odliˇsnˇe. 1. 2. 3. 4.
Zdroj: Zdroj: Zdroj: Zdroj:
25
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU TCP ByteDos DoS55 JavaLoic Loic Longcat SimpleDoSTool SynFloodDos XOIC
HTTP AnonymousDoS AnonymousDoser BanglaDos FireFlood Hoic HttpDosTool HttpFlooder Hulk Janidos Loic Longcat Slowloris Torshammer UnknownDoser
´ cnych Tabulka 4.1: Tabulka rozdˇelen´ı utoˇ ´ n´astroju˚ podle protokolu˚ ˚ pˇredpoklad takovy, Se znalost´ı informac´ı z kapitoly 2.2 byl muj ´ zˇ e pro kaˇzdy´ ´ ´ utok existuje urˇcity´ vzorec chov´an´ı, ktery´ se bˇehem utoku neust´ale opakuje. ˚ ´ Z tohoto duvodu jsem se pokouˇsel utoky rozdˇelit na jednotliv´e cˇ a´ sti a u nich sledovat specifick´e vlastnosti. Na z´akladˇe tˇechto vlastnost´ı bych pot´e mohl na´ vrhnout symbolicky´ z´apis, ktery´ by byl schopen popsat tyto utoky. ´ Kaˇzdy´ soubor se z´aznamem utoku jsem nejprve pˇrevedl do csv souboru a podrobil komplexn´ı analyze n´astrojem Splunk. Soubory pcap jsem do csv ´ form´atu pˇrev´adˇel pomoc´ı programu TShark s n´asleduj´ıc´ı syntax´ı: ” t s h a r k . exe ” −r ”ZDROJ” −T f i e l d s −E header=y −E quote=d −E s e p a r a t o r =” ,” −e ”PARAMETR” > ”CIL” Pomoc´ı pˇrep´ınaˇce -e lze vloˇzit neomezeny´ poˇcet atributu˚ z pcap souboru. N´azvy atributu˚ jsou stejn´e jako v pravidlech pro filtrov´an´ı v programu Wireshark. Tento pˇr´ıkaz lze vloˇzit do cyklu a hromadnˇe pˇrev´est vˇetˇs´ı mnoˇzstv´ı sou˚ boru. Po konverzi staˇc´ı ve Splunku zadat cestu k adres´arˇ i se soubory a poˇckat, neˇz se soubory nahraj´ı. Splunk by mˇel s´am rozeznat form´at souboru a typ oddˇelovaˇce. Pokud tomu tak nen´ı, lze tyto parametry zvolit ruˇcnˇe. Pot´e staˇc´ı ´ zadat, kter´e atributy chceme sledovat. Soustˇredil jsem se na statistick´e udaje ´ ˚ typy protov r´amci cel´eho utoku. Jednalo se napˇr´ıklad o velikosti paketu, ˚ Po z´ısk´an´ı obecnych ´ kolu˚ a cˇ ´ısla portu. informac´ ı o utoku jsem pokraˇ coval sle´ dov´an´ım konkr´etn´ıch paketu˚ programem Wireshark. V r´amci vyzkumu jsem se ´ 26
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU zamˇerˇ il pˇredevˇs´ım na tyto vlastnosti: IP adresa, cˇ ´ıslo portu, TCP pˇr´ıznaky, veli´ kost paketu, fragmentace paketu, obsah datov´e cˇ a´ sti a u HTTP utok u˚ i na obsah cˇ a´ sti pro HTTP poˇzadavek. V r´amci analyzy jsem d´ a le pakety filtroval podle ´ cˇ ´ısla portu. T´ım jsem jednoduˇse z´ıskal z´aznam komunikace bˇehem konkr´etn´ıho ´ utoku. 4.2.2 Vysledky analyzy ´ ´ ´ Hned na zaˇca´ tku analyzy jsem si potvrdil svou hypot´ezu o rozdˇelen´ı utok u˚ ´ ´ na menˇs´ı st´ale se opakuj´ıc´ı cˇ a´ sti. Vˇsechny zkouman´e utoky obsahuj´ı sekvence komunikace, kter´e se napˇr´ıcˇ toky opakuj´ı. Nemus´ı se nutnˇe jednat o zcela identick´e kusy komunikace, ale jejich sch´ema byv´ ´ a stejn´a. Pro potˇrebu analyzy ´ jsem ˚ eh utoku ´ si tedy prubˇ rozdˇelil na tˇri logick´e cˇ a´ sti: •
Nav´az´an´ı spojen´ı (Vˇetˇsinou three way handshake.)
•
´ ´ Utok (Pˇrev´azˇ nˇe opakuj´ıc´ı se hlavn´ı cˇ a´ st utoku.)
•
Ukonˇcen´ı spojen´ı (RST pakety, FIN, ACK pakety. Na rozd´ıl od pˇredchoz´ı cˇ a´ sti se v r´amci toku neopakuj´ı.)
Vˇetˇsina n´astroju˚ proto otev´ır´a komunikaci na v´ıce portech najednou a komunikuje podle st´ale stejn´eho vzorce. Existuj´ı ovˇsem i vyjimky jako Anony´ mousDos, ktery´ vˇzdy komunikuje pouze na jednom portu. Zde je souhrn signi˚ kter´e jsem pozoroval u sledovanych ´ ˚ fikantn´ıch znaku, u: ´ vlastnost´ı utok ´ ´ IP adresa Ze sledovanych u˚ pouze utoky n´astroje SynFloodDos vyuˇz´ıvaj´ı ´ utok IP spoofing a kaˇzdy´ odeslany´ paket m´a jinou zdrojovou IP adresu. Ostatn´ı ´ ˚ tomu, zˇ e navazuj´ı spojen´ı), maj´ı stabiln´ı IP adresu po celou utoky (kvuli ´ dobu utoku. ˇ ısla portu, ˚ na kterych TCP port C´ ´ n´astroje komunikuj´ı se s kaˇzdym ´ novym ´ spojen´ım inkrementuj´ı. Vyjimku opˇet pˇredstavuje SynFloodDos, ktery´ cˇ ´ısla ´ portu˚ (stejnˇe jako IP adresy) n´ahodnˇe generuje. Velikost okna Dalˇs´ım sledovanym ´ parametrem byla velikost okna definovan´a v TCP segmentu paketu. V r´amci analyzy ´ jsem nalezl dva z´akladn´ı vzory ’ ´ chov´an´ı. Bud to cely´ utok prob´ıh´a s konstantn´ı velikost´ı nastavenou na ˚ nebo se velikost okna bˇehem utoku ´ maxim´aln´ı hodnotu (65536 bajtu), ´ cn´ıkem spojen´ı postupnˇe sniˇzuje a pˇri dosaˇzen´ı nulov´e hodnoty je utoˇ ´ pˇreruˇseno RST paketem. Pot´e je znovu provedeno nav´az´an´ı spojen´ı a utok prob´ıh´a od zaˇca´ tku. 27
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ˇ ym ´ Datovy´ segment Cast u˚ je zpr´ava obsaˇzen´a v datov´e cˇ a´ sti ´ znakem TCP utok ´ paketu. Tyto zpr´avy jsou do utok u˚ pˇrid´av´any jednotlivymi DoS n´astroji ´ ’ a jsou bud nastaveny uˇzivatelem, napevno pˇriˇrazeny konkr´etn´ım proˇ ezec definovany´ uˇzivatelem gramem, nebo jsou n´ahodnˇe generov´any. Retˇ ˚ ze byt muˇ ´ v r´amci datov´e cˇ a´ sti paketu opakov´an nˇekolikr´at tak, aby mˇel paket velikost poˇzadovanou programem (napˇr´ıklad nˇekter´e verze programu LOIC). HTTP segment V r´amci HTTP segmentu jsou charakteristickymi pole URL, ´ Verze a User-Agent.
4.3 Symbolicky´ z´apis Na z´akladˇe pozorovanych vlastnost´ı a chov´an´ı datov´e komunikace bˇehem ´ ´ utok u˚ jsem navrhl symbolicky´ z´apis, ktery´ je schopen tuto komunikaci popsat. Inspirac´ı pˇri vytv´arˇ en´ı z´apisu mi byly programovac´ı jazyky a regul´arn´ı vyrazy. ´ ´ Jazykem Python jsem se inspiroval pˇri grafick´e upravˇ e z´apisu. Lze tak podobnˇe odsadit logick´e celky komunikace. Z regul´arn´ıch vyraz u˚ jsem pˇrevzal jedno´ duchy´ syst´em kvantifik´atoru˚ pro z´apis opakov´an´ı prvku.
4.3.1 Symboly Protoˇze je nutn´e popisem s´ıt’ov´e komunikace pomoc´ı symbolick´eho z´apisu postihnout celou rˇ adu charakteristickych ´ vlastnost´ı, zavedl jsem nˇekolik symbolu˚ a konstant se specifickym Symboly jsou uvedeny v tabulce 4.2 (za ´ vyznamem. ´ X lze dosadit paket, promˇennou, nebo uz´avorkovanou cˇ a´ st toku) a konstanty v tabulce 4.3.
4.3.2 Z´apis ´ ´ ˚ Datov´e toky utok u˚ lze zapisovat dvˇema zpusoby. Usporn´ y form´at se hod´ı sp´ısˇ e ´ ˚ kter´e jsou na prvn´ı pohled cˇ iteln´e. Cely´ z´apis utoku ´ pro kratˇs´ı z´apisy utok u, je zobrazen na jednom rˇ a´ dku a vˇetˇs´ı strukturalizace by pouze zbyteˇcnˇe zab´ırala v´ıce m´ısta. Pro n´azornost jsou v uk´azce m´ısto skuteˇcnych ´ paketu˚ pouˇzity pojmy popsan´e v kapitole 4.2.2. Pˇr´ıklad z´apisu: ( [ navazani s p o j e n i ] [ utok ] [ ukonceni s p o j e n i ] )∗ 28
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ´ Strukturovan´y z´apis proti tomu nab´ız´ı moˇznost popsat sloˇzity´ utok tak, aby byl st´ale snadno cˇ itelny´ a na prvn´ı pohled byly patrn´e jeho z´akladn´ı vlastnosti. Pro strukturovany´ z´apis plat´ı dvˇe z´akladn´ı pravidla: •
Kaˇzdy´ paket na nov´em rˇ a´ dku.
•
´ Jednotliv´e cˇ a´ sti uzavˇren´e z´avorkami jsou o jednu urove nˇ odsazeny.
´ Ze z´apisu utoku v tomto form´atu je ihned patrn´e jeho rozdˇelen´ı na jednot˚ eh utoku, ´ liv´e cˇ a´ sti – Nav´az´an´ı spojen´ı, Prubˇ Ukonˇcen´ı spojen´ı. Pˇr´ıklad z´apisu: ( [ navazani s p o j e n i ] ( [ utok ] [ utok ] ... ∗ ) [ ukonceni s p o j e n i ] )∗ Symbol [] {} () $[]
X ∗|s , X 0−N |p , X N |s
X−1 , X−2
d V, A
Popis Ohraniˇcuje vlastnosti paketu. Parametry oddˇelen´e stˇredn´ıkem Oddˇelen´ı typu˚ paketu˚ v dan´em poˇrad´ı (tcp, http) Ohraniˇcuje cˇ a´ st toku, kde prob´ıh´a opakov´an´ı Ohraniˇcuje hodnotu uvedenou pomoc´ı regul´arn´ıho vyrazu ´ Prvn´ı cˇ a´ st horn´ıho indexu znaˇc´ı poˇcet opakov´an´ı a za svislou cˇ arou se nach´az´ı typ opakov´an´ı (s – s´eriov´e, p - paraleln´ı) Doln´ı index znaˇc´ı pˇr´ısluˇsnost hodnoty k paketu, nebo toku. Pˇr´ısluˇsnost z´avis´ı na kontextu, ve kter´em se tento symbol pouˇzije. Hodnota bez oznaˇcen´ı plat´ı pro aktu´aln´ı paket, nebo tok, s indexem -1 pro pˇredchoz´ı atd. zpoˇzdˇen´ı ´ cn´ık (Attacker) Obˇet’ (Victim), Utoˇ Tabulka 4.2: Souhrn symbolu˚ z´apisu
29
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU 4.3.3 Syntaxe Jednotliv´e pakety jsou ohraniˇceny hranatymi z´avorkami ( [“ a ]“). Pokud nen´ı ´ ” ” rˇ eˇceno jinak, jsou uvedeny parametry TCP cˇ a´ sti paketu, kter´e obsahuj´ı anoma´ lity nebo maj´ı jinou vypov´ıdaj´ıc´ı hodnotu pro identifikaci utoku. V pˇr´ıpadˇe, zˇ e je tˇreba uv´est informace i z jinych cˇ a´ st´ı paketu, jsou tyto cˇ a´ sti oddˇeleny ´ sloˇzenymi z´avorkami ( {“ a }“) a jejich typ je uveden jako horn´ı index kaˇzd´e ´ ” ” ´ cn´ıkem. z nich. Na n´asleduj´ıc´ı uk´azce je pops´an paket, ktery´ byl odesl´an utoˇ V TCP cˇ a´ sti se vyskytuj´ı pˇr´ıznaky PSH, ACK“. Z HTTP cˇ a´ sti lze vyˇc´ıst, zˇ e se ” jedn´a o GET poˇzadavek a c´ılov´a URI je uloˇzen´a v promˇenn´e $uri.
[ {A; PSH ,ACK} T CP {GET ; $request.uri=$uri} HT T P ]
Pro oznaˇcen´ı zpoˇzdˇen´ı mezi pakety lze mezi jejich z´apis vloˇzit parametr d“ ” s konkr´etn´ı, nebo pˇribliˇznou hodnotou. Parametry Jednotliv´e parametry paketu jsou oddˇeleny stˇredn´ıkem ( ;“). Na prvn´ım ” m´ıstˇe popisu TCP cˇ a´ sti paketu je vˇzdy uveden odesilatel (Attacker, Victim) a za n´ım n´asleduj´ı pˇr´ıznaky TCP segmentu (Flags) tak, jak jsou textovˇe uvedeny u paketu v programu Wireshark. V HTTP cˇ a´ sti je na zaˇca´ tku vyhrazen prostor pro ´ odpovˇedi. Pˇrehled statyp HTTP poˇzadavku (GET, POST), nebo stavovy´ kod ´ u˚ je napˇr´ıklad v RFC2616 [14]. Uk´azku takov´eho pouˇzit´ı lze vidˇet vovych ´ kod ´ v kapitole 4.5.2 u z´apisu utoku HOIC. Dalˇs´ı atributy je moˇzno do popisu libovolnˇe pˇridat za pouˇzit´ı notace programu Wireshark. Z´apis parametru je symbolem =“ rozdˇelen na dvˇe cˇ a´ sti. Prvn´ı uv´ad´ı n´azev atributu paketu dle syntaxe ” programu Wireshark a v druh´e je uvedena samotn´a hodnota. Napˇr´ıklad: $ r e q u e s t . u r i = ”/ index . htm” Promˇenn´e Pro zvyˇ ´ sen´ı variability, obecnosti a pˇrehlednosti z´apisu lze hodnoty, nebo i cel´e cˇ a´ sti z´apisu nahrazovat promˇennymi. Promˇenn´e jsou uvozeny znakem ´ americk´eho dolaru ( $“). Jejich n´azev mus´ı byt ´ v r´amci z´apisu unik´atn´ı a nesm´ı ” vyuˇz´ıvat slov rezervovanych pro konstanty. Definice promˇennych mus´ı byt ´ ´ ´ ´ uvedena se z´apisem utoku. Hodnoty lze promˇennym pˇriˇrazovat i formou regul´arn´ıho vyrazu. Re´ ´ gul´arn´ı vyrazy jsou ohraniˇceny pomoc´ı hranatych ´ ´ z´avorek uvozenych ´ znakem 30
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ˚ dolaru. Uvnitˇr regul´arn´ıho vyrazu lze vyuˇz´ıvat promˇenn´e stejnym ´ ´ zpusobem, jako jinde s vyuˇzit´ım metaznaku \“, ktery´ v regul´arn´ıch vyrazech slouˇz´ı pro ´ ” ˚ Na pˇr´ıkladu lze vidˇet pˇriˇrazen´ı hodtakzvan´e escapov´an´ı speci´aln´ıch znaku. noty do promˇenn´e $uri pomoc´ı regul´arn´ıho vyrazu ( bud’ promˇenn´a $u1, ´ ” nebo promˇenn´a $u2“). $ u r i = $ [ \ $u1 | \ $u2 ] Konstanty ˚ ych ´ Bˇehem popisu ruzn u˚ jsem zjistil, zˇ e se nˇekter´e cˇ a´ sti pravidelnˇe opa´ utok kuj´ı, nebo maj´ı charakteristick´e vlastnosti. Pro takov´e prvky jsem vytvoˇril konˇ ı a zjednoduˇsuj´ı vysledn stanty, kter´e zpˇrehlednuj´ y´ z´apis. Pˇrehled konstant je ´ uveden v tabulce 4.3.
Matadata ˇ ´ ıch uchov´avat i dalˇs´ı data, kter´a ze saSymbolicky´ z´apis umoˇznuje o utoc´ ’ motn´eho s´ıt ov´eho provozu nevyˇcteme. Jedn´a se napˇr´ıklad o typ a verzi serveru ´ obˇeti, typ utoku a jin´e informace, kter´e mohou pˇrispˇet k jednoznaˇcnosti z´apisu ´ ´ utoku. Tato metadata slouˇz´ı pˇredevˇs´ım k tomu, aby si cˇ ten´arˇ mohl utok um´ıstit ˚ ze jednat o informace o prostˇred´ı, ve kter´em do kontextu. Pˇrev´azˇ nˇe se tak muˇ ´ utok prob´ıhal. Z´apis metadat je uvozen kl´ıcˇ ovym ´ slovem $metadata“ a je uveden spoleˇcnˇe ” s promˇennymi. Samotny´ z´apis pokraˇcuje za rovn´ıtkem a rˇ´ıd´ı se pravidly JSON ´ notace. Konkr´etn´ı kl´ıcˇ ov´a slova nejsou definov´ana, a tak lze zapsat prakticky ´ jak´akoli data, kter´a budou pro utok pˇr´ıznaˇcn´a. $metadata = { ” s e r v e r ” : ”Apache HTTP S e r v e r 2 . 4 . 6 ” ” type ” : ”HTTP a t t a c k ” }
4.4 Pˇr´ıklad vytv´arˇen´ı z´apisu V t´eto kapitole je krok za krokem pops´an postup vytv´arˇ en´ı symbolick´eho ´ z´apisu utoku typu HTTP flood n´astroje LOIC. Tento postup slouˇz´ı pro ´ cely a lze podle nˇej postupovat pˇri vytv´arˇ en´ı z´akladn´ıho popisu uk´azkov´e uˇ ´ prakticky jak´ehokoli DoS utoku. 31
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU Konstanta [3WH] uMSG gMSG rMSG
MSG $random $metadata
Popis Three-way-handshake User message, uˇzivatelem zadan´a zpr´ava Generated message, generovan´a zpr´ava, v popisu by mˇela byt ´ uvedena pravidla pro generov´an´ı Repetitive message, opakuj´ıc´ı se st´ale stejn´a zpr´ava definovan´a programem (v popisu by mˇela byt ´ uvedena konkr´etn´ı hodnota) Bl´ızˇ e nespecifikovan´a zpr´ava N´ahodnˇe generovan´a hodnota. Typ z´avis´ı na typu ˇ ıslo, text, IP adresa, ...) c´ılov´e promˇenn´e. (C´ ´ Promˇenn´a slouˇz´ıc´ı pro uloˇzen´ı metadat utoku Tabulka 4.3: Konstanty symbolick´eho z´apisu
Jako zdroj informac´ı n´am poslouˇz´ı z´aznam s´ıt’ov´e komunikace bˇehem ´ prob´ıhaj´ıc´ıho utoku ve form´atu pcap. Pro jeho analyzu pouˇzijeme kombinaci ´ programu Wireshark a software pro analyzu velk´eho mnoˇzstv´ı dat (Big Data), ´ v tomto pˇr´ıpadˇe Splunk. ´ Prvn´ı cˇ a´ st analyzy utoku (body 1. – 6.) probˇehne v programu Wireshark. ´ ´ V t´eto f´azi manu´alnˇe vyhled´av´ame abnormality v komunikaci bˇehem utoku. 1.
Vyfiltrujeme si konkr´etn´ı konverzaci podle IP adresy a cˇ ´ısla portu. Vyfiltrov´an´ım konkr´etn´ı konverzace z´ısk´ame pˇrehled o posloupnosti pa˚ kter´a se zpravidla opakuje bˇehem cel´eho utoku. ´ ketu, Pˇr´ıklad filtrovac´ıho rˇ etˇezce: ( i p . addr eq 1 9 2 . 1 6 8 . 1 . 1 0 and i p . addr eq 1 9 2 . 1 6 8 . 1 . 2 0 ) and ( t c p . p o r t eq 49177 and t c p . p o r t eq 8 0 )
2.
´ V komunikaci nejprve identifikujeme z´akladn´ı prvky utoku, jako jsou ´ nav´az´an´ı spojen´ı, hlavn´ı cˇ a´ st utoku (obvykle se jedn´a o cˇ a´ st doruˇcuj´ıc´ı data k obˇeti) a ukonˇcen´ı spojen´ı.
3.
˚ kter´e Bˇehem sledov´an´ı konverzac´ı se soustˇred´ıme na hodnoty atributu, jsou uvedeny v kapitole 4.2.2 a snaˇz´ıme se nal´ezt pravidla a souvislosti, podle kterych ´ se mˇen´ı.
4.
Vytvoˇr´ıme jednoduchy´ z´apis konverzace podle definovanych pravidel ´ symbolick´eho z´apisu. V tomto pˇr´ıpadˇe: 32
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ( [ 3WH] [ {A; PSH ,ACK}{GET} ] ( [V ;ACK] ∗ [A;ACK] ∗ ) [A; RST ,ACK] ) ∗|p ´ ˚ Kaˇzdy´ tok je iniUtok se tedy skl´ad´a z velk´eho mnoˇzstv´ı datovych ´ toku. ´ cn´ık v r´amci kaˇzd´eho toku zas´ıl´a ciov´an TCP handshake. N´aslednˇe utoˇ HTTP GET request s pˇr´ıznaky PSH a ACK k obˇeti. Obˇet’ odpov´ıd´a pa´ cn´ık pos´ıl´a paket s pˇr´ıznakem ACK. Tato kety s pˇr´ıznakem ACK a utoˇ ´ cn´ık celou komunikaci ukonˇc´ı pakecˇ a´ st se opakuje do t´e doby, neˇz utoˇ tem s pˇr´ıznaky RST, ACK. 5.
Pokraˇcujeme znovu od bodu jedna a vytv´arˇ´ıme dalˇs´ı a dalˇs´ı z´apisy. Kombinace hodnot IP adres a cˇ ´ısel portu˚ nevol´ıme n´ahodnˇe, ale podle dvou pravidel: ´ (a) Je nutn´e analyzovat konverzace rovnomˇernˇe bˇehem cel´eho utoku. (b) Je nutn´e analyzovat rˇ adu po sobˇe jdouc´ıch konverzac´ı. ˇ ım v´ıce konverzac´ı takto analyzujeme, t´ım jednoduˇseji a hlavnˇe pˇresnˇeji C´ ´ jsme schopni sestavit symbolicky´ z´apis utoku. Konkr´etn´ı poˇcet analyzovanych ´ konverzac´ı z´avis´ı na jejich variabilitˇe.
6.
Po analyze ´ dostateˇcn´eho mnoˇzstv´ı konverzac´ı jsme schopni z posloupnosti vytvoˇrenych ´ z´apisu˚ odvodit pravidla, podle kterych ´ se mˇen´ı vlast˚ V z´asadˇe existuje nˇekolik nosti konverzac´ı vˇcetnˇe jednotlivych paketu. ´ moˇznost´ı, podle kterych ´ se vlastnosti mˇen´ı: ˚ avaj´ı stejn´e. (a) Zust´ (b) Mˇen´ı se n´ahodnˇe. (c)
Mˇen´ı se na z´akladˇe urˇcit´eho pravidla (inkrementace, opakov´an´ı omezen´eho mnoˇzstv´ı hodnot st´ale dokola).
Pro vyj´adˇren´ı konkr´etn´ıch pravidel lze vyuˇz´ıt symbolu˚ z´akladn´ıch matematickych ´ operac´ı (+, -, *, /), cˇ i symbolu˚ pro inkrementaci a dekrementaci (++, --). 33
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU Pokud proch´az´ıme jednotliv´e komunikace jednu po druh´e, zjist´ıme, zˇ e s kaˇzdym dalˇs´ım spojen´ım se napˇr´ıklad inkrementuje cˇ ´ıslo portu ´ ´ cn´ıka. To muˇ ˚ zeme zapsat takto: utoˇ $tcp.srcport = $tcp.srcport−1 ++ ´ ˚ zeme naˇse z´avˇery, Vzhledem k velk´emu poˇctu konverzac´ı v utoku nemuˇ kter´e jsme vyvodili pouze ze zlomku z nich, generalizovat. Z tohoto ˚ duvodu je nutn´e vysledky ovˇerˇ it pomoc´ı softwaru pro analyzu velk´eho ´ ´ mnoˇzstv´ı dat. V m´em pˇr´ıpadˇe to byl Splunk.
7.
˚ kter´e jsme uvedli v z´apisu. Jednotliv´e Ovˇerˇ´ıme veˇsker´e hodnoty atributu, formy opakov´an´ı od sebe jednoduˇse rozezn´ame:
´ Statick´e Atribut bˇehem cel´eho utoku obsahuje pouze jednu hodnotu. ˚ kter´e N´ahodn´e Poˇcet hodnot by mˇel zhruba odpov´ıdat poˇctu paketu, konkr´etn´ı atribut obsahuj´ı (lze dopoˇc´ıtat podle pomˇeru paketu˚ s atributem a celkov´eho poˇctu paketu˚ v konverzaci). Omezeny´ vyˇ ´ cet Poˇcet hodnot pomˇerem neodpov´ıd´a pˇredchoz´ı moˇznosti a je vyraznˇ e niˇzsˇ´ı (jednotky aˇz des´ıtky). ´ Inkrementace Poˇcet je stejny´ jako u druh´e moˇznosti, ale hodnoty se ˚ ze byt s kaˇzdou dalˇs´ı konverzac´ı inkrementuj´ı. Poˇcet muˇ ´ sn´ızˇ en zbytek pod´ılu poˇctu paketu˚ obsahuj´ıc´ıch atribut a rozsahu hodnot ˚ ze nabyvat atributu (napˇr´ıklad hodnota cˇ ´ısla portu muˇ maxim´alnˇe ´ 65535).
8.
´ Pokud zn´ame konkr´etn´ı poˇcty opakov´an´ı jednotlivych cyklu˚ utoku, ´ ˚ zeme si jednoduˇse vypoˇc´ıtat jaky´ je pomˇer vyskytu muˇ konkr´etn´ıho pa´ ˚ ci poˇctu ostatn´ıch paketu˚ v z´apisu jednoho utoku. ´ ketu vuˇ Podobnˇe budeme postupovat i v n´astroji Splunk a vyfiltrujeme si pakety podle ˚ ci vzorov´eho paketu. Vypoˇcteme pomˇer vyskytu tohoto typu paketu vuˇ ´ ´ celkov´emu poˇctu paketu˚ zaznamenanych bˇehem utoku. Pomˇery by si ´ ´ mˇely odpov´ıdat (s vˇetˇs´ım mnoˇzstv´ım provedenych utok u˚ se zvyˇsuje ´ pˇresnost), jinak nastala chyba pˇri definici z´apisu, nebo pˇri vypoˇ ´ ctu pomˇeru. Napˇr´ıklad: 34
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ( [ 3WH] [A; PSH ,ACK;uMSG] [A; FIN ,ACK] [V ;ACK] [ {V ; FIN , PSH ,ACK} { 4 0 0 } ] [A; RST ,ACK] ) ∗|p
´ Na pˇr´ıkladu utoku n´astroje XOIC vid´ıme pˇr´ıklad vypoˇ ´ ctu pomˇeru paketu (3WH obsahuje 3 pakety):
0, 125 =
1 3+5
(4.1)
Vysledn y´ pomˇer poˇctu vyfiltrovanych ´ ´ paketu˚ podle vlastnost´ı vzorov´eho paketu a celkov´eho poˇctu paketu˚ by se mˇel k t´eto hodnotˇe bl´ızˇ it.
4.5 Definice utok ´ u˚ Pro lepˇs´ı pˇredstavu je zde uvedeno nˇekolik uk´azek z´apisu nejrozˇs´ırˇ enˇejˇs´ıch ´ ˚ Symbolick´e z´apisy jsou doplnˇeny o slovn´ı popis kaˇzd´eho utoku ´ utok u. tak, aby byly z´apisy jasnˇe cˇ iteln´e i pro cˇ ten´arˇ e, ktery´ nezn´a syntaxi tohoto z´apisu.
4.5.1 TCP LOIC ´ Z´apis utok u˚ n´astroje LOIC m´a vcelku jednoduchou strukturu. Nav´az´an´ı spo´ jen´ı prob´ıh´a s kaˇzdym na inkrementovan´em cˇ ´ısle portu oproti ´ novym ´ utokem ´ pˇredchoz´ımu utoku. Po proveden´ı three-way handshake doch´az´ı ze strany ´ cn´ıka k odesl´an´ı paketu s pˇr´ıznaky ACK a PSH. Paket je doplnˇen o textoutoˇ ´ cn´ık zvovou informaci ve formˇe nˇekolikr´at opakovan´eho rˇ etˇezce, ktery´ si utoˇ lil. Obˇet’ potvrzuje pˇrijet´ı paketem ACK. Tato stˇr´ıdav´a komunikace se opakuje, ´ dokud obˇet’ neukonˇc´ı spojen´ı paketem RST. Utoky prob´ıhaj´ı na v´ıce portech soubˇezˇ nˇe. 35
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ( $tcp.srcport = $tcp.srcport−1 ++ [ 3WH] ( [A; PSH ,ACK;uMSG∗|s ] [ V ;ACK] ) ∗|s [V ; RST ] ) ∗|p XOIC ´ ´ ˚ LOIC. Struktura z´apisu utok u˚ n´astroje XOIC je velmi podobn´a utok um ´ ´ cn´ıka, na S kaˇzdym opˇet prob´ıh´a inkrementace cˇ ´ısla portu utoˇ ´ novym ´ utokem ´ cn´ık pos´ıl´a kter´em prob´ıh´a komunikace. Probˇehne three-way handshake, utoˇ PSH, ACK paket a vz´apˇet´ı pos´ıl´a FIN, ACK paket pro aktivn´ı ukonˇcen´ı spojen´ı. Obˇet’ na prvn´ı paket odpov´ıd´a paketem ACK a ukonˇcuje spojen´ı paketem ´ cn´ık pos´ıl´a RST paket, a t´ım ´ FIN s kodem 400 Bad Request“ v HTTP cˇ a´ sti. Utoˇ ” spojen´ı definitivnˇe ukonˇcuje. ( $tcp.srcport = $tcp.srcport−1 ++ [ 3WH] [A; PSH ,ACK;uMSG] [A; FIN ,ACK] [V ;ACK] [ {V ; FIN , PSH ,ACK} { 4 0 0 } ] [A; RST ,ACK] ) ∗|p ByteDos ´ Jak lze poznat ze symbolick´eho z´apisu, utoky n´astroje ByteDos jsou jeˇstˇe jed´ cn´ık ihned spojen´ı noduˇssˇ´ı, neˇz pˇredchoz´ı dva pˇr´ıklady. Po nav´az´an´ı spojen´ı utoˇ ukonˇcuje paketem s pˇr´ıznakem FIN. Obˇet’ odpov´ıd´a paketem RST, a t´ım cely´ ´ utok konˇc´ı. ( [ 3WH] [A; FIN ,ACK] [ V ; RST ,ACK] ) ∗|p DoS55 ´ Tento utok prob´ıh´a pouze nav´az´an´ım velk´eho poˇctu spojen´ı. Po vyprˇsen´ı cˇ asov´eho limitu na stranˇe obˇeti jej obˇet’ ukonˇcuje paketem RST. ( [ 3WH] d ˜ 1 2 6 s [V ; RST ,ACK] ) ∗|p 36
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU LongCat ´ Z´apis tohoto utoku je velmi podobny´ pˇredchoz´ımu. Po nav´az´an´ı spojen´ı pomoc´ı three-way handshake jej obˇet’ ukonˇcuje paketem RST. ( [ 3WH] d ˜ 0 . 0 2 s [V ; RST ,ACK] ) ∗|p SynFloodDos ´ ´ Tento utok je pops´an dvˇema zanoˇrenymi cykly. Samotny´ utok je tvoˇren ´ ’ ´ cn´ıka. Obˇet mu odpouze opakovanym ´ odes´ıl´an´ı SYN paketu˚ ze strany utoˇ pov´ıd´a paketem s pˇr´ıznakem SYN ACK. Po vyprˇsen´ı cˇ asov´eho limitu, kdy obˇet’ ´ cn´ıka, ukonˇcuje spojen´ı paketem RST. Tento cyklus se neobdrˇz´ı odpovˇed’ utoˇ opakuje vˇzdy pˇresnˇe 116 kr´at a v kaˇzd´em je vygenerov´ana nov´a IP adresa ´ cn´ıka. Po tomto poˇctu opakov´an´ı je vygenerov´ano nov´e cˇ ´ıslo portu a cely´ utoˇ proces se opakuje. ( $tcp.srcport = $random ( $ip.src = $random [A; SYN ] [ V ; SYN,ACK] d˜21 s [V ; RST ,ACK] 116|p ) ) ∗|p SimpleDosTool ´ SimpleDosTool vytv´arˇ´ı jednoduch´e utoky, pˇri kterych ´ ve velk´em mnoˇzstv´ı nav´azˇ e spojen´ı s obˇet´ı a po menˇs´ı prodlevˇe odeˇsle paket FIN. Obˇet’ odpov´ıd´a paketem RST a ukonˇcuje spojen´ı. ( $tcp.srcport = $tcp.srcport−1 ++ [ 3WH] d ˜ 0 . 1 s [A; FIN ,ACK] [V ; RST ,ACK] ) ∗|p JavaLOIC ´ Struktura tohoto utoku je velmi podobn´a pˇredchoz´ımu. V nˇekterych ´ pˇr´ıpadech zde doch´az´ı po nav´az´an´ı spojen´ı k urˇcit´e vz´ajemn´e komunikaci v po37
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ˚ dobˇe pˇredem neurˇcen´eho poˇctu ACK paketu. ( $tcp.srcport = $tcp.srcport−1 ++ [ 3WH] ( [A;ACK] [ V ;ACK] ) ∗ [A; FIN ,ACK] [V ; RST ,ACK] ) ∗|p 4.5.2 HTTP ´ HTTP utoky se podle symbolick´eho z´apisu mohou zd´at sloˇzitˇejˇs´ı. Ve ´ skuteˇcnosti prob´ıhaj´ı podobnˇe jednoduˇse jako TCP utoky. Sloˇzitost z´apisu je ˚ ˚ kter´e lze u tˇechto zpusobena pouze vˇetˇs´ım poˇctem promˇenlivych atributu, ´ ´ utok u˚ pozorovat.
LOIC N´astroj LOIC po nav´az´an´ı spojen´ı odes´ıl´a paket s poˇzadavkem GET s parame˚ kter´e jsou try $ua a $uri. Obˇet’ odpov´ıd´a nespecifikovanym ´ poˇctem segmentu, ´ cn´ıkem sporadicky potvrzov´any pakety s pˇr´ıznakem ACK. Tato komuniutoˇ kace se st´ale opakuje, pˇriˇcemˇz velikost aktu´aln´ıho ACK paketu je vˇzdy menˇs´ı, ´ cn´ıka paketem RST. neˇz velikost pˇredchoz´ıho. Spojen´ı je ukonˇceno ze strany utoˇ
( $ t c p . s r c p o r t = $ t c p . s r c p o r t −1 ++ [ 3WH] [ {A; PSH ,ACK}{GET ; $request.uri=$ u r i ; $ h t t p . u s e r a g e n t =$ua } ] ( [V ;ACK] ∗ [A;ACK; $s<=$s −1 ] )∗ [A; RST ,ACK] )∗ $ua = ” M o z i l l a / 4 . 0 ( compatible ; MSIE 7 . 0 ; Windows NT 6 . 0 ) ” $ u r i = $[\/ index \ . htm \ ? [A−Z ] { 6 } ] $s = t c p . window size value 38
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU HOIC ´ cn´ıkem stejnˇe jako v pˇredchoz´ım pˇr´ıkladu odesl´an Po nav´az´an´ı spojen´ı je utoˇ poˇzadavek GET s konkr´etn´ımi parametry $uri a $ua. N´asledn´a komunikace prob´ıh´a opˇet naprosto shodnˇe jako v pˇredchoz´ım pˇr´ıpadˇe. V tomto pˇr´ıpadˇe ´ ovˇsem ukonˇcen´ı komunikace iniciuje obˇet’ paketem FIN a HTTP kodem 200 ” ´ OK“. Utoˇcn´ık odpov´ıd´a paketem ACK a korektnˇe ukonˇcuje spojen´ı paketem FIN,ACK. Obˇet’ potvrzuje pˇrijet´ı posledn´ıho paketu a t´ım je komunikace uzavˇrena. ( $ t c p . s r c p o r t = $ t c p . s r c p o r t −1 ++ [ 3WH] [ {A; PSH ,ACK}{GET ; $request.uri=($uri) ; $ h t t p . u s e r a g e n t =$ua } ] ( [V ;ACK] ∗ [A;ACK; $s<=$s −1 ] ∗ ) [ {V ; FIN , PSH ,ACK} { 2 0 0 } ] [A;ACK] [A; FIN ,ACK] [V ;ACK] ∗ ) $ua = ”” $ u r i = ”/ index . htm” $s = t c p . window size value
4.6 N´avrh sluˇzby Jako jeden z pˇr´ıkladu˚ vyuˇzit´ı vytvoˇren´eho symbolick´eho z´apisu je sluˇzba, cˇ i ´ n´astroj, kter´a by byla schopna detekovat utok na z´akladˇe jeho definice symbolickym ´ z´apisem (signature-based/pattern-based IDS5 ). V re´aln´em s´ıt’ov´em provozu se samozˇrejmˇe pˇrev´azˇ nˇe vyskytuje bˇezˇ n´a komunikace, kterou bude muset detekˇcn´ı n´astroj rozeznat a ignorovat. Protoˇze nelze jednoduˇse a exaktnˇe definovat, jak vypad´a bˇezˇ ny´ a neˇskodny´ provoz, bude tˇreba vyuˇz´ıt nˇektery´ z postupu˚ z oboru umˇel´e inteligence. Vybral jsem nˇekolik moˇznych ´ metod, kter´e by mohly v takov´emto n´astroji ´ ˚ slouˇzit pro detekci utok u. 5. zkratka Intrusion Detection System
39
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU 4.6.1 Change-point detection Metoda Change-point detection (ˇcesky Detekce zmˇeny“) spoˇc´ıv´a v detekci ” zmˇeny sledovanych parametru˚ v datech um´ıstˇenych do cˇ asov´eho r´amce. ´ ´ ´ Vyhodou metody je, zˇ e pro jej´ı poˇzit´ı pˇri detekci prob´ıhaj´ıc´ıch DoS utok u˚ ´ ´ nen´ı potˇreba m´ıt utoky pˇresnˇe definovan´e. Metoda pracuje s mnoˇzstv´ım statistickych porovn´av´a aktu´aln´ı hodnoty a vysledn´ e odchylky de´ dat, se kterymi ´ ´ tekuje jako zmˇeny. [4] [24] ˚ Namˇerˇ en´a data Dalˇs´ı vyhodou tohoto pˇr´ıstupu je rychlost jeho algoritmu. ´ lze okamˇzitˇe porovnat se statistickymi hodnotami a vyhodnotit vysledek. De´ ´ ˚ ze bez probl´emu˚ prob´ıhat v re´aln´em cˇ ase, tekce touto metodou proto muˇ ´ coˇz bylo i v laboratorn´ıch podm´ınk´ach pˇri detekci utok u˚ prok´az´ano [43]. Nevyhodou metody mohou byt ´ ´ pomˇernˇe cˇ ast´e chybn´e detekce zmˇen. [17] 4.6.2 Signature-based detection Detekce metodou Signature-besed je zaloˇzena na porovn´av´an´ı zn´amych sig´ ´ esˇ ny, natur a vzoru˚ s mnoˇzinou vstupn´ıch dat. Pokud je n´alez uspˇ ´ detekce se ´ povaˇzuje za pozitivn´ı. Pˇri vyuˇzit´ı tohoto pˇr´ıstupu pro detekci DoS utok u˚ by ´ bylo nutn´e pro kaˇzdy´ utok pˇresnˇe definovat vzor, ktery´ bude porovn´av´an. Dalˇs´ı nevyhodou t´eto metody je jej´ı n´aroˇcnost na vypoˇ pˇri pouˇzit´ı na ´ ´ cetn´ı vykon ´ link´ach s velkou propustnost´ı a z toho plynouc´ı probl´emy pˇri pouˇzit´ı v re´aln´em cˇ ase. Vyhodou t´eto metody je jej´ı vysok´a pˇresnost a mal´e procento faleˇsnych ´ ´ detekc´ı. [17] Z tˇechto vlastnost´ı vyplyv´ ´ a, zˇ e metodu Signature-based detection lze ´ vhodnˇe vyuˇz´ıt pro detekci zn´amych u˚ nad z´aznamem s´ıt’ov´e komunikace. ´ utok ´ ´ esˇ n´a nebude. Metody lze ale Pˇri detekci novych u˚ tato metoda pˇr´ıliˇs uspˇ ´ utok ˚ ych i vhodnˇe kombinovat a vyuˇz´ıt kladnych ´ vlastnost´ı ruzn ´ metod. [33] 4.6.3 Machine learning Metoda strojov´eho uˇcen´ı se vyznaˇcuje schopnost´ı reagovat na zmˇeny a uˇcit se z pˇredchoz´ıch zkuˇsenost´ı. V tomto ohledu se jev´ı jako ide´aln´ı pro pouˇzit´ı v kombinaci s pˇredchoz´ımi dvˇema metodami pro jejich zastˇreˇsen´ı. Existuj´ı dva z´akladn´ı pˇr´ıstupy strojov´eho uˇcen´ı – uˇcen´ı s uˇcitelem a uˇcen´ı bez uˇcitele. Pro oba typy uˇcen´ı byly pops´any techniky, kter´e lze pouˇz´ıt pro klasifikaci s´ıt’ov´eho ´ ˚ [44] [26] provozu a detekci prob´ıhaj´ıc´ıch DoS utok u. 4.6.4 Vyuˇzit´ı symbolick´eho z´apisu ˚ Vˇsechny vyˇ z´ıskat prvotn´ı in´ se uveden´e metody potˇrebuj´ı nˇejakym ´ zpusobem formace at’ uˇz o tom, jaky´ m´a charakter bˇezˇ ny´ s´ıt’ovy´ provoz (anomaly de40
´ 4. D EFINICE SYMBOLICK E´ HO Z APISU ´ ıch samotnych tection metody), cˇ i o utoc´ (signature-based detection). Metody ´ strojov´eho uˇcen´ı s uˇcitelem zase vyˇzaduj´ı data, na jejichˇz z´akladˇe bude provedeno prvotn´ı uˇcen´ı syst´emu. Jako prostˇredek pro vymˇ ´ enu tˇechto informac´ı lze vyuˇz´ıt vytvoˇreny´ symbolicky´ z´apis. Jako nejvhodnˇejˇs´ı se pro vyuˇzit´ı symbolick´eho z´apisu jev´ı metoda strojov´eho uˇcen´ı a signature-based detekce, pro kter´e lze jednoznaˇcnˇe definovat ´ jednotliv´e utoky. Pro detekci zaloˇzenou na metodˇe change-point detection lze ´ symbolick´e z´apisy utok u˚ vyuˇz´ıt pro sn´ızˇ en´ı poˇctu poˇctu chybnych ´ detekc´ı. Ze ´ z´apisu lze vyˇc´ıst, jak´e vlastnosti se bˇehem utoku budou mˇenit a na tyto vlast˚ ze byt nosti muˇ ´ detekce prim´arnˇe zamˇerˇ ena (napˇr´ıklad sn´ızˇ en´ım prahu pro detekci zmˇeny).
41
Kapitola 5
Z´avˇer C´ılem t´eto pr´ace bylo navrhnout a definovat symbolicky´ z´apis pro popis komu´ nikace vytv´arˇ en´e prob´ıhaj´ıc´ımi utoky. Po analyze ´ a popisu charakteristickych ´ ´ vlastnost´ı DoS utok u˚ se podaˇrilo definovat symbolicky´ z´apis, ktery´ by mˇel vy´ hovovat veˇskerym v uvodu pr´ace. Samotny´ ´ krit´eri´ım pˇredem definovanych ´ z´apis by mˇel byt ´ schopen jednoznaˇcnˇe a cˇ itelnˇe popsat nejrozmanitˇejˇs´ı varianty ´ ˚ coˇz lze pozorovat na pˇr´ıkladech v kapitole 4.5. DoS utok u, ˚ zitou cˇ a´ st´ı pr´ace pˇred samotnou definic´ı symbolick´eho z´apisu bylo stuDuleˇ ´ dium vyvoje DoS utok u˚ a principu˚ jejich fungov´an´ı, kter´e je pops´ano v kapi´ tole 2. Pouh´a teorie by ovˇsem tak´e nestaˇcila a bylo tˇreba analyzovat jednotliv´e ´ n´astroje v kapitole 3 a samotn´e z´aznamy utok u˚ jimi produkovanych ´ (4.2). Teprve s tˇemito vˇedomostmi jsem byl schopen navrhnout z´apis tak, aby dok´azal ´ popsat utok se vˇsemi jeho vlastnostmi, kter´e jsme schopni vyˇc´ıst ze s´ıt’ov´e komunikace. ´ ˚ Hlavn´ı Vysledkem je pomˇernˇe robustn´ı n´astroj pro popis DoS utok u. ´ pˇrednost tohoto symbolick´eho z´apisu vid´ım v cˇ itelnosti cˇ lovˇekem a z´arovˇen ´ ıch, i poˇc´ıtaˇcem. Symbolicky´ z´apis lze pouˇz´ıt pro vymˇ ´ enu informac´ı o utoc´ ´ nebo napˇr´ıklad jako vstup pro navrˇzenou detekˇcn´ı sluˇzbu. V definici utoku po˚ coˇz je moc´ı symbolick´eho z´apisu lze zahrnout obrovsk´e mnoˇzstv´ı parametru, umoˇznˇeno pouˇzit´ım notace programu Wireshark pro promˇenn´e. Na pr´aci by bylo moˇzn´e nav´azat detailn´ım n´avrhem sluˇzby pro detekci ´ DoS utok u˚ a jej´ı n´aslednou implementac´ı. Takovyto ´ n´astroj by mohl ovˇerˇ it pouˇzitelnost symbolick´eho z´apisu v praxi. Dalˇs´ı moˇznost´ı je ovˇerˇ en´ı, pˇr´ıpadnˇe ´ ˚ kter´e nebyly v pr´aci rozˇs´ırˇ en´ı pouˇzitelnosti z´apisu o dalˇs´ı varianty DoS utok u, ´ zahrnuty (napˇr´ıklad amplifikaˇcn´ı utoky). Pr´ace bude s laskavym ´ svolen´ım vedouc´ıho pr´ace Mgr. V´ıta Bukaˇce, Ph.D. uveˇrejnˇena na webu <>, ktery´ slouˇz´ı jako ucelen´a datab´aze vzorku˚ utok u, ´ ´ utok u˚ a dalˇs´ıch dat slouˇz´ıc´ıch pro experimentov´an´ı s DoS utoky.
42
Literatura [1] Adeyinka, O.: Internet Attack Methods and Internet Security Technology. In Modeling & Simulation, 2008. AICMS 08. Second Asia International Conference on, IEEE, 2008, s. 77–82. [2] Ali, F.: IP Spoofing. The Internet Protocol Journal, roˇcn´ık 10, cˇ . 4, 2007: s. 2–9. [3] Aumasson, J.-P., Bernstein, D. J., Boslet, M.: Hash-Flooding DOS Reloaded: Attacks and defenses. In 29th Chaos Communication Congress, Hamburg, Prosinec 2012, [cit. 2015-12-23]. Dostupn´e z: [4] Basseville, M., Nikiforov, I. V.: Detection of Abrupt Changes: Theory and Application. Prentice Hall, 1993, ISBN 0-13-126780-9. [5] Belson, D.: Akamai State of the Internet Report, Q2 2014. Q2 [2014 Report], roˇcn´ık 8, cˇ . 2, 2014. [6] Caglayan, A., Toothaker, M., Drapaeau, D., Burke, D., Eaton, G.: Behavioral analysis of fast flux service networks. In Proceedings of the 5th Annual Workshop on Cyber Security and Information Intelligence Research: Cyber Security and Information Intelligence Challenges and Strategies, ACM, 2009. [7] Calce, M., Silverman, C.: Mafiaboy: How I Cracked the Internet and why It’s Still Broken. Viking, 2008, ISBN 9780670067480. [8] Chee, W. O., Brennan, T.: H.....t.....t....p....p....o....s....t. OWASP AppSec DC 2010, Listopad 2010, [Online], [cit. 2015-12-23]. Dostupn´e z: [9] Cisco: Defeating DDOS Attacks. 2004, [Online], [cit. 2015-12-23]. Dostupn´e z: 43
´ Eˇ R 5. Z AV [10] Cisco: TTL Expiry Attack Identification and Mitigation. 2009, [Online], [cit. 2015-12-23]. Dostupn´e z: [11] Cisco: Understanding Unicast Reverse Path Forwarding. 2014, [Online], [cit. 2015-12-23]. Dostupn´e z: [12] Douligeris, C., Mitrokotsa, A.: DDoS Attacks and Defense Mechanisms: Classification and State-of-the-art. Computer Networks, roˇcn´ık 44, cˇ . 5, Duben 2004: s. 643–666, ISSN 1389-1286, doi:10.1016/j.comnet.2003.10.003. [13] Eddy, W.: RFC4987, TCP SYN Flooding Attacks and Common Mitigations. 2007, [Online], [cit. 2015-12-23]. Dostupn´e z: [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.: RFC 2616, Hypertext Transfer Protocol – HTTP/1.1. 1999, [Online], [cit. 2015-12-23]. Dostupn´e z: [15] Goyal, P., Malik, S.: Detection of Distributed Reflection DoS by using Rank Correlation. International Journal of Computer Science and Mobile Computing, roˇcn´ık 3, cˇ . 8, 2014. [16] Groth, D.: Network+ study guide. Alameda, Calif: Sybex, 2005, ISBN 9780-7821-4406-2. [17] Gupta, S., Grover, D., Bhandari, A.: Detection Techniques against DDoS attacks: A Comprehensive Review. International Journal of Computer Apˇ plications, roˇcn´ık 96, cˇ . 5, Cerven 2014: s. 49–57, doi:10.5120/16794-6390. [18] Houle, K., Greene, B.: ISP Security - Real World Techniques II. NANOG26, Eugene, OR, 2002. Dostupn´e z: [19] IANA: Protocol Numbers. 2015, [Online], [cit. 2015-12-23]. Dostupn´e z: 44
´ Eˇ R 5. Z AV [20] Internet Engineering Task Force: RFC 791, Internet Protocol - DARPA Inernet Program, Protocol Specification. 1981, [Online], [cit. 2015-12-23]. Dostupn´e z: [21] Jyothsna, V., Prasad, V. R., Prasad, K. M.: A review of anomaly based intrusion detection systems. International Journal of Computer Applications, roˇcn´ık 28, cˇ . 7, 2011: s. 26–35. [22] Liao, H.-J., Lin, C.-H. R., Lin, Y.-C., Tung, K.-Y.: Intrusion detection system: A comprehensive review. Journal of Network and Computer Applications, roˇcn´ık 36, cˇ . 1, 2013: s. 16–24. [23] Liska, A.: Building an Intelligence-Led Security Program. Elsevier Science, 2014, ISBN 9780128023709. [24] Liu, S., Yamada, M., Collier, N., Sugiyama, M.: Change-point detection in time-series data by relative density-ratio estimation. Neural Networks, ˇ roˇcn´ık 43, Cervenec 2013: s. 72–83, doi:10.1016/j.neunet.2013.01.012. [25] Mirkovic, J., Dietrich, S., Dittrich, D., Reiher, P.: Internet Denial of Service: Attack and Defense Mechanisms. Upper Saddle River, NJ, USA: Prentice Hall, 2004, ISBN 0131475738. [26] Nafiseh Kahani, M. B., Saeed Shiry: Detecting Denial of Service Attacks Utilizing Machine Learning Methods. International Journal of Computing Architecture, roˇcn´ık 3, cˇ . 1, 2008. [27] Ollmann, G.: Botnet communication topologies. 2009, [cit. 2015-12-23]. Dostupn´e z: [28] Olson, P.: We are Anonymous : inside the hacker world of LulzSec, Anonymous, and the global cyber insurgency. New York: Back Bay Books, 2013, ISBN 0316213527. [29] Postel, J.: RFC793, Transmission Control Protocol. Z´arˇ´ı 1981, [Online], [cit. 2015-12-23]. Dostupn´e z: [30] Postel, J.: RFC 862, Echo Protocol. 1983, [Online], [cit. 2015-12-23]. Dostupn´e z: [31] Postel, J.: RFC 864, Character Generator Protocol. 1983, [Online], [cit. 201512-23]. Dostupn´e z: 45
´ Eˇ R 5. Z AV [32] R., B., Borman, D., Partridge, C.: RFC 1071, Computing the Internet Checksum. 1988, [Online], [cit. 2015-12-23]. Dostupn´e z: [33] Rajapandian, P., Alagarsamy, K.: Intrusion Detection in Dos Attacks. Inter´ national Journal of Computer Applications, roˇcn´ık 15, cˇ . 8, Unor 2011: s. 33–37, doi:10.5120/1967-2634. [34] Rossow, C.: Amplification Hell: Revisiting Network Protocols for DDoS Abuse. In Proceedings of the 2014 Network and Distributed System Security (NDSS) Symposium, Internet Society, 2014. [35] Ryan, Y.: Anonymous and the Arab uprisings. Kvˇeten 2011, [Online], [cit. 2015-12-23]. Dostupn´e z: [36] Sailesh, K.: Survey of Current Network Intrusion Detection Techniques. 2007, [Online], [cit. 2015-12-23]. Dostupn´e z: [37] Sian, J.: Why do organisations need a DDoS contingency plan? 2012, [Online], [cit. 2015-12-23]. Dostupn´e z: [38] Sifry, M.: Wikileaks and the Age of Transparency. O/R Books, 2011, ISBN 9781935928317. [39] Smith, R.: PhlashDance: Discovering permanent denial of service attacks against embedded systems. EUSecWest 08, London, May 2008. Dostupn´e z: [40] Soluk, K.: DDoS Activity in the Context of Hong Kong – Pro-democracy Movement. Listopad 2014, [Online], [cit. 2015-12-23]. Dostupn´e z: [41] Soluk, K.: DDoS and Geopolitics – Attack analysis in the context of the Israeli-Hamas conflict. Srpen 2014, [Online], [cit. 2015-12-23]. Dostupn´e z:
´ Eˇ R 5. Z AV ddos-and-geopolitics-attack-analysis-in-the-context-o f-the-israeli-hamas-conflict/> [42] Stone, M.: Anonymous #OpSony: DDoS attacks against PlayStation succeed. Duben 2011, [Online], [cit. 2015-12-23]. Dostupn´e z: [43] Wang, H., Zhang, D., Shin, K.: Change-point monitoring for the detection of DoS attacks. IEEE Transactions on Dependable and Secure Computing, ˇ ıjen 2004: s. 193–208, doi:10.1109/tdsc.2004.34. roˇcn´ık 1, cˇ . 4, R´ [44] Zander, S., Nguyen, T., Armitage, G.: Automated traffic classification and application identification using machine learning. In The IEEE Conference on Local Computer Networks 30th Anniversary, Institute of Electrical & Electronics Engineers (IEEE), 2005, doi:10.1109/lcn.2005.35.
47
Pˇr´ıloha A
Seznam elektronickych ´ pˇr´ıloh Na pˇriloˇzen´em DVD je um´ıstˇen archiv pcap.zip, ktery´ obsahuje pcap soubory s pouˇzitymi z´aznamy s´ıt’ov´e komunikace produkovan´e jednotlivymi ´ ´ ´ utoky. Soubory jsou pojmenov´any podle n´azvu n´astroje, jehoˇz komunikace byla zaznamen´av´ana. V n´azvu souboru je tak´e obsaˇzen n´azev protokolu, ´ prostˇrednictv´ım kter´eho utok prob´ıhal. V souboru s n´azvem DP_Lorenc.pdf je um´ıstˇena tak´e elektronick´a verze diplomov´e pr´ace ve form´atu pdf.
48
