Rozlišení člověk/robot na úrovni HTTP použitelné pro omezení DDOS útoků

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Rozlišení člověk/robot na úrovni HTTP použitelné pro omezení DDOS útoků Bc. Marek Aufart Vedoucí práce: Ing. Alexandru Moucha Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 14. května 2012

2 iv

3 v Poděkování Chtěl bych poděkovat vedoucímu za připomínky zejména k formální podobě práce a oponentovi za připomínky týkající se technických aspektů této práce. Také bych chtěl poděkovat své rodině a přítelkyni za podporu se studijními i jinými záležitostmi a zejména rodičům za to, že mě nechali vystudovat. Děkuji.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract The work deals with finding a way to filter HTTP requests based on whether they are created by human or by robot. The main task is to choose the parameters in HTTP requests that are applicable to this resolution. The aim of requests filtering is to increase resistance against (D)DOS attacks. To verify requests resolution, a module containing the developed algorithm was implemented for the nginx server. Within this module are implemented measurements to verify the ability to filter requests. Abstrakt Práce se zabývá hledáním způsobu, jak filtrovat HTTP požadavky podle toho, jestli pochází od člověka nebo robota. Hlavním úkolem je vybrat parametry v HTTP požadavcích, které jsou pro toto rozlišení použitelné. Cílem filtrování požadavků má být vyšší odolnost proti (D)DOS útokům. Pro ověření rozlišení požadavků je napsán modul serveru nginx, který vytvořený algoritmus implementuje. Pomocí tohoto modulu jsou realizována měření k ověření schopnosti rozlišovat požadavky. ix

8 x

9 Obsah 1 Úvod do problematiky Obecně o (D)DOS útocích Úvod do řešení problému (D)DOS útoků Druhy (D)DOS útoků Provedení (D)DOS útoku Technické následky způsobené (D)DOS útokem Smysl této práce Cíle Způsob řešení Struktura práce Prostředí řešení problému HTTP Útoky mimo HTTP Struktura www stránky Vzorové webové stránky pro provádění měření Požadavky na vzorové webové stránky Výběr vzorových webových stránek Rozbor obsahu vybrané webové stránky Roboti a útoky na HTTP Vyhledávací roboti SPAM roboti HTTP DOS HTTP DDOS Nástroje na provádění útoků LOIC HOIC Získávání dat pro rozlišení HTTP požadavků Konfigurace Log webserveru Log reverzní proxy Vlastní info log filtrovacího modulu Dočasný soubor s vnitřním stavem filtrovacího modulu xi

10 xii OBSAH 4.6 Informace přímo z prohlížeče klienta Portál httparchive.org Analýza parametrů pro rozlišování HTTP požadavků Parametry HTTP kód odpovědi xx xx xx xx xx Poměr zastoupení kódů odpovědí Content-type odpovědi Text/html CSS, Javascript, obrázky Částečná načtení stránky (AJAX) Obsah stahovaný z CDN HTTP referer Poměr zastoupení Content-type Doba zpracování požadavku Dynamický obsah Statický obsah Nezměněný obsah Rozlišování časů požadavků Posloupnost URL požadavků Formát uchovávání Počet uchovávaných požadavků Vyhodnocování posloupnosti požadavků Další HTTP hlavičky Cookie Accept Identifikace klienta IP adresa HTTP hlavička user-agent Kontrola čekání klienta na odpověď Počty spojení Vynucení přes cookie nginx Server nginx Vnitřní skruktura Datové typy Reprezentace konfigurace Zdrojový kód Vytváření modulu nginx module API

11 OBSAH xiii Struktura modulu Kód modulu Instalace modulu Nastavení nginx OS Diskuse k jiným webserverům Apache HTTPD Vlastní algoritmus Princip algoritmu Uchovávání dat Získání adresy do hashtabulky Velikost hashtabulky Globální stav Obsluha požadavků Při přijetí požadavku Před odesláním odpovědi Počítání skore parametrů Postup výpočtu skore Postup výpočtu prahu Naučení vzoru běžného provozu Ruční nastavení Průchozí provoz Deformace vzoru Limitní počty požadavků Zamítání požadavků Podle globálního stavu Podle podezřelého chování - skore Implementace Datové struktury Zpracování záznamu klienta Zpracování záznamu globálního stavu Velikost v paměti Přetékání, zaokrouhlování Měření a testování Testovací prostředí Legitimní klient Útočník Server Měření při sběru dat Shrnutí měření při sběru dat Měření schopnosti rozlišovat požadavky (laboratorní) Při použití nástroje LOIC Při použití nástroje HOIC

12 xiv OBSAH Chyby rozlišení z důvodu lokální cache prohlížeče Shrnutí měření rozlišování požadavků Měření schopnosti rozlišovat požadavky (ostré) Rozsah naměřených dat Vyhodnocení naměřených dat Shrnutí a porovnání s laboratorním měření Přehled jiných řešení Roboo Srovnání s touto prací Test-cookie nginx module Srovnání s touto prací Apache HTTPD mod_evasive, dosevasive Srovnání s touto prací Vestavěná nastavení v serverech Propojení s aplikační logikou nebo cloud Závěr 57 Literatura 59 A Záznamy z github repozitáře 61 B Obsah přiloženého CD 65

13 Seznam obrázků 2.1 Přehled požadavků na server v prohlížeči Přehled požadavků na CDN v prohlížeči Okno nástroje LOIC (Windows 7) Okno nástroje HOIC (Windows 7) Přidání proxy mezi webserver a klienta Základní postup zpracování požadavku legitimního (vlevo) a zablokokovaného (vpravo) klienta Základní princip rozhodnutí o zpracování požadavku Základní princip zpracování vyřízeného požadavku Graf počtu bodů klientů včetně jedné instance nástroje LOIC (Klient 3), práh Graf počtu bodů klientů při použití nástroje HOIC, práh Graf počtu bodů legitimních klientů při rozdílném cachování prohlížečů Graf s chybami v rozlišení klientů jako robotů Graf poměru správně a špatně vyhodnocených klientů xv

14 xvi SEZNAM OBRÁZKŮ

15 Seznam tabulek 8.1 Statistiky content type požadavků získané při sběru dat Statistiky not-modified požadavků získané při sběru dat Statistiky průměrných časů zpracování požadavků Statistiky skore klientů při měření s nástrojem LOIC Statistiky skore klientů při měření s nástrojem HOIC Statistiky skore klientů při měření k problému s lokální cache Množství dat získané při ostrém měření Vyhodnocení označení klienta jako robota Vyhodnocení označení klienta jako robota v procentech xvii

16 xviii SEZNAM TABULEK

17 Kapitola 1 Úvod do problematiky V této práci se zabývám (D)DOS 1 útoky na webové servery. Pojmy, které se této problematiky týkají jsou vysvětleny v kapitole Prostředí řešení problému. Zde na úvod představuji problematiku samotnou, dále vysvětluji, proč jsem si toto téma vybral a čeho chci dosáhnout. 1.1 Obecně o (D)DOS útocích (D)DOS útok je činnost, kdy se útočník snaží o přetížení infrastruktury a tím dosáhnout vyřazení cíle z provozu [4]. Blíže jsou popsány v následující kapitole. Tyto útoky jsou prováděny zejména za účelem odstavení určité služby. Známé jsou od případu se serverem Wikileaks [6], kdy byly takové útoky použity jako odplata proti karetním asociacím nebo vydavatelským společnostem. Nedostupnost služeb způsobená DDOS útoky může mít pro online portály a jiné online služby nepříjemné finanční následky a také problém ve snížení důvěryhodnosti před uživateli služby. Vzhledem k tomu, že principem (D)DOS je přetížení infrastruktury, nabízí se posílení infrastruktury tak, aby i při útoku byla schopná obsluhovat všechny požadavky. I velké naddimenzování infrastruktury ale může být proti obrovskému množství útočníků neúčinné. DDOS útoky také už přestávají být doménou pouze velkých projektů a tak je třeba je řešit i u méně exponovaných webových stránek. 1.2 Úvod do řešení problému (D)DOS útoků Techniky (D)DOS spočívají v zahlcení infrastruktury tak, aby nebylo možné obsluhovat legitimní klienty. K tomu, abychom dokázali takovému útoku zamezit, je nutné umět takovou situaci detekovat a následně útočníky rozpoznat a zablokovat. 1 (D)DOS - (distributed) denialy of service - útoky cílící na přetížení cíle 1

18 2 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Detekovat takový útok je nejjednodušeji možné přes aktuální zatížení serveru, případně množství požadavků, které zpracovává. Otázkou ovšem zůstává, jak odlišit vysokou zátěž způsobenou náhlým zvýšením návštěvnosti a (D)DOS útok. Rozlišení útočníků může být komplikovanější, ale za předpokladu, že mají požadavky útočníků něco společného, musíme tento společný rys najít a na jeho základě útočníky od legitimních požadavků odlišit. Při rozlišování požadavků je vhodné postupovat na základě statistických informací získaných z požadavků. Zablokování útoku je vhodné provádět co nejblíže útočníkům, protože může docházet k zahlcení infrastruktury po cestě. 1.3 Druhy (D)DOS útoků DDOS útoky mohou cílit na různé vrstvy komunikace. Nejčastěji se jedná o útoky na protokolech TCP/UDP nebo vyšším HTTP. Útoky na TCP typicky spočívají v zaplavení cíle TCP SYN požadavky, tedy navázání spojení. K odstavení cíle dojde buď přetížením linky do internetu nebo přetížením síťového rozhraní serveru. Na úrovni HTTP můžeme pozorovat útoky spočívající v zahlcení serveru HTTP požadavky, které jsou většinou stejné. Útočníci typicky nezpracovávají odpověď, pouze posílají požadavky a tím zatěžují server. Útoky také dosahují různé intenzity. Tu je možné měřit v datovém toku požadavků útočníků. Obecně lze říci, že větší útoky, tedy řádově stovek Mbit/s až jednotek Gbit/s, je nutné řešit odpojením linky, kterou útočníci využívají, nebo výkonným firewallem [1]. 1.4 Provedení (D)DOS útoku Provedení útoku není drahá ani náročná záležitost, záleží pouze na zvoleném rozsahu útoku. K provedení (D)DOS útoku se používají nástroje vytvářející požadavky, které zahlcují cílový server. Pro běžné uživatele je nejznámější nástroj LOIC blíže popsaný v následujících kapitolách. Útoky mohou provádět lidé pomocí těchto nástrojů nebo pomocí takzvaných botnetů 2. Výhodou botnetů je jejich decentralizovanost a schopnost synchronizace a efektivního řízení. (D)DOS útok typicky nezatěžuje jen cílový server, ale také linky, kterými je útok prováděn. Provedení útoku tedy většinou zaznamená také poskytovatel internetového připojení. 1.5 Technické následky způsobené (D)DOS útokem V případě, že útočníci disponují rychlostí připojení k internetu, která výrazně převyšuje připojení cíle, na který útočí, nemusí se útok dostat až přímo k cíli, ale zastaví na se v úzkém hrdle sítě cestou. Tímto je ohrožena síťová infrastruktura, ale cíl může být stále dostupný pro klienty, kteří využívají spojení jinou cestou. 2 botnet - řízená skupina robotů použivající se k softwarovým útokům

19 1.6. SMYSL TÉTO PRÁCE 3 Přetížení síťového rozhraní serveru může nastat v případě velkého množství přijímaných paketů, dojde tedy k ochromení síťové komunikace se serverem. Při útocích spočívajících v množství TCP spojení může dojít k vyčerpání dostupných portů (kterých je ). V případě nevhodně nastaveného softwaru nebo přetížení může velké množství požadavků vyvolat větší potřebu paměti nebo výkonu procesoru, než server má. V takovém případě se reakce serveru zpomalují, až se server a na něm provozované služby stanou nepoužitelnými. 1.6 Smysl této práce V této práci se soustředím na omezení (D)DOS útoku na úrovni HTTP. Snažím se tedy na základě pozorování procházejících požadavků rozhodnout, zda se jedná o útočníky nebo o legitimní klienty. Způsob rozlišování požadavků, který v této práci navrhnu, by měl být do budoucna použitelný jako základ jednoduchého, pro HTTP požadavky transpanentního filtru, který dokáže omezit (D)DOS útoky vedené na server takovou intenzitou, že server bude takové požadavky stíhat přijímat. Útoky se šířkou pásma v řádu Gbit/s není reálné odfiltrovat na serveru, soustředím se tedy na útoky s menší intenzitou. 1.7 Cíle Cílem práce je tedy navrhnout algoritmus, který ze statistických dat získaných při přenosu HTTP požadavku, bude schopen rozhodnout, jestli požadavek pochází od legitimního klienta nebo útočníka. Dále chci napsat filtr implementující takový algoritmus, který bude zahazovat požadavky od útočníků a vyřizovat požadavky od skutečných klientů. V případném ostrém provozu chceme díky zahazování dosáhnout zvýšení počtu vyřízených správných požadavků. Při řešení se snažím omezit způsoby filtrování, které mohou být rychleji prováděny na nižších vrstvách. Rovněž napojení na vyšší vrstvy se pokusím alespoň ze začátku vyhnout. 1.8 Způsob řešení K rozlišení, zda požadavky pochází od legitimního klienta nebo útočníka, použiji statistické metody. Pomocí nich budu sledovat odlišnosti v parametrech získaných z HTTP spojení. Parametry, které použiji k získání informací, jsou součástí HTTP provozu. Soustředím se zejména na HTTP kódy odpovědí na požadavky, obsah hlavičky content-type z HTTP odpovědí a mimo HTTP také na čas, který serveru vyřízení požadavku zabralo. Pokud se budou parametry konkrétního klienta dostatečně lišit od parametrů obvyklých pro normální provoz, dojde k jeho zablokování. Implementovat tuto práci budu jako modul do reverzního proxy serveru, který bude předávat HTTP požadavky mezi klienty a webovým serverem.

20 4 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.9 Struktura práce V úvodu této práce se zaměřuji na představení prostředí, ve kterém se problém řešený v této práci, vyskytuje a jaké jsou základní možnosti jeho řešení. Dále popisuji požadavky na výsledek této práce. Pro vytvoření představy, co vlastně je (D)DOS útok a jak může být proveden, popisuji základní druhy útoků a nástrojů, které je mohou provádět. V kapitole Získávání dat je popsáno několik způsobů, jakými lze získávat data. Ta jsou potřebná pro získání představy, jaké parametry volit a jak se liší v případě legitimního provozu a útoku. Z dat získaných v této kapitole jsou vybrány parametry, které popisuji v kapitolách následujících. Podrobně se zaměřuji na popis parametrů, na základě kterých je možné provádět rozlišování legitimních klientů a útočníků. Všechny parametry jsou dostupné na úrovni HTTP, jsou tedy součástí požadavků nebo odpovědí na požadavky. Pro demonstraci a ověření schopnosti rozlišovat požadavky je vytvořen modul do serveru nginx. V kapitole nginx je shrnuta tvorba obecného modulu pro nginx a jeho vhodné nastavení. V kapitole vlastní algoritmus jsou popsány základní pricipy, jak algoritmus požadavky vyhodnocuje a vybrané parametry na základě kterých funguje. Při měření jsem se zaměřil na ověření schopnosti filtru rozlišit legitimní klienty od případných útočníků. Jsou rovněž uvedeny a vysvětleny situace, kdy může dojít ke špatnému vyhodnocování klientů. Přehled jiných řešení jsem si nechal na konec práce, protože se v této práci nesnažím vylepšit již existující řešení, ale vyzkoušet, jestli je možné jít jinou cestou. U každého řešení je krátce popsáno, jak se liší od této práce.

21 Kapitola 2 Prostředí řešení problému Problém, který řeším, začal být aktuální díky rozšíření a používanosti internetu a zejména WWW 1, který funguje na HTTP 2. Tuto kapitolu zakončí představení HTTP a toho, co běžné webové stránky obsahují a dále se zaměřím na útoky na HTTP. 2.1 HTTP Protokol, na kterém je prohlížení WWW stránkek založeno. Definován je v RFC 2616 [21], je bezstavový a pracuje na principu požadavek - odpověď. GET / HTTP/1.1 Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:windows-1250,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:cs-CZ,cs;q=0.8 Connection:keep-alive Cookie:wp-settings-time-2= ; utma= ; utmz= utmcsr=(direct) utmccn=(direct) utmcmd=(none); PHPSESSID=kbudv6s2u4stqo95hh2cdho796 Host:glyphicons.com User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Výše je uveden příklad HTTP požadavku, zajímavé jsou řádky GET / HTTP/1.1 a Host: glyphicons.com, které určují, co po serveru požaduji. 1 WWW - World wide web 2 HTTP - Hypertext transfer protocol, protokol používající se k přenosu webových stránek 5

22 6 KAPITOLA 2. PROSTŘEDÍ ŘEŠENÍ PROBLÉMU 2.2 Útoky mimo HTTP V této práci se soustředím na validní HTTP požadavky. Techniky zahlcení serveru na nižších vrstvách v této práci neřeším, ale je vhodné je přinejmenším zmínit. Tato práce se primárně zabývá HTTP útoky, ale časté jsou útoky na nižších síťových vrstvách, které vedou k přetížení cílového serveru nebo infrastruktury, která k němu vede. TCP SYN flood - zahlcení síťového rozhraní cíle požadavky na otevření nového TCP spojení, dá se omezit nastavením firewallu. ICMP flood - zahlcení síťové infrastruktury ICMP požadavky, dá se omezit nastavením firewallu. 2.3 Struktura www stránky Samotná www stránka je typicky HTML 3 dokument obsahující nějaký text. To znamená, že další obsah, jako obrázky, CSS soubory a podobně, obvykle bývají v dalších objektech, na které stránka odkazuje. Pro každý takový objekt se na server posílá požadavek. Zobrazení jedné stránky klientovi tedy zahrnuje i desítky požadavků. 2.4 Vzorové webové stránky pro provádění měření Pro konečné srovnání a testování je třeba vybrat website, na které budeme provádět měření Požadavky na vzorové webové stránky Vzorové webové stránky by měly splňovat následující požadavky přístup mezi klienta a server (tedy běžet na mém serveru) zaindexovaná na httparchive.org "obvyklá"struktura dostatečná návštěvnost Projekt httparchive.org sbírá statistiky o webovém obsahu, blíže je popsán v kapitole Získávání dat. Pokud se jedná o jím sledovanou stránku, jsou k dispozici srovnání s jinými webovými stránkami. Pro většinu měření je nutné být mezi klientem a webserverem. Provozuji webhosting, takže je nejvhodnější vybrat některý z hostovaných webů. Obvyklou strukturou mám na mysli to, že stránka obsahuje text, obrázky a podobně. Vhodně také může běžet na jednom z více rozšířených CMS 4. Celkově se tedy podobá jiným webovým stránkám, což můžeme ověřit na HTTP archive. Pro sběr dat potřebuji co nejpestřejší uživatele. Nejlépe tedy ne českou stránku s návštěvností nejméně stovky uživatelů denně. 3 HTML - Hypertext markup language, jazyk používaný pro vytváření www stránek 4 CMS - Content management system, systém pro správu obsahu

23 2.4. VZOROVÉ WEBOVÉ STRÁNKY PRO PROVÁDĚNÍ MĚŘENÍ Výběr vzorových webových stránek Na základě uvedených požadavků a mých možností jsou nejlepší webové stránky Běží na CMS Wordpress a má návštěvnost v řádu jednotek tisíc návštěvníků denně. Má jen několik HTML stránek, ale dostatek dalšího obsahu. CMS Wordpress je poměrně rozšířený redakční systém napsaný v jazyce PHP. Jako webový server je použit Apache HTTPD řady Rozbor obsahu vybrané webové stránky Pro získání orientačního seznamu prvků ve stránce jsem použil Inspector v prohlížeči Google Chrome. Na obrázku níže jsou vypsány požadavky od začátku, tak jak byly posílány. První byla stažena HTML stránka a až po jejím zpracováním prohlížečem se mohly začít posílat další požadavky. Další požadavky vedou na prvky stránky potřebné pro její správné zobrazení. Jedná se především o obrázky, soubory se styly (CSS) a javascript. Obrázek 2.1: Přehled požadavků na server v prohlížeči Většina moderních webových stránek obsahuje také obsah, který se načítá odjinud, než ze serveru, na kterém je web provozován. Typickým příkladem jsou služby měřící návštěvnost, tlačítka pro sdílení na sociální sítě nebo některé rozšířené javascriptové knihovny (jquery). Požadavky na takový obsah na serveru se samotým webem nezaznamenáme, protože směřují na CDN 5. V logu webserveru potom požadavky vypadají takto: [04/May/2012:12:05: ] "GET / HTTP/1.1" "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/535.19" [04/May/2012:12:05: ] "GET /wp-content/themes/glyphicons /style.css HTTP/1.1" " "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/535.19"...

24 8 KAPITOLA 2. PROSTŘEDÍ ŘEŠENÍ PROBLÉMU Obrázek 2.2: Přehled požadavků na CDN v prohlížeči Content type říká, jaký typ obsahu je požadavku vrácen (mimetype, například text/html, image/gif, atd.). Vědět, co požadavek vrací přímo na úrovni HTTP pro nás může být užitečné. Podrobněji v kapitole Parametry použitelné pro rozlišení útočníků. Ve výše uvedeném obrázku také vidíme, že HTTP status požadavků je 200 OK nebo 304 Not Modified. Status HTTP 304 znamená, že některé prvky nebyly staženy znovu, ale že server pouze odpověděl, že se nezměnily. Na přesnější popis, k čemu to potřebujeme rozlišovat, dojde v dalších kapitolách této práce. Další zajímavou informaci najdeme na posledním řádku a tou je, že celkem bylo posláno 52 požadavků. Z nich bylo 34 na náš server a 18 na CDN. Web glyphicons.com je zaindexován na HTTParchive.org pod následujícím odkazem Některé výše uvedené postřehy tím můžeme ověřit. Tímto rozborem obsahu jsme získali představu o tom, jak se chová běžný klient. V dalších kapitolách toho využijeme při rozlišování legitimních klientů a útočníků. 5 CDN - Content distribution network

25 Kapitola 3 Roboti a útoky na HTTP Roboty, kteří navštěvují webové strány můžeme rozdělit na několik skupin, určitý přehled můžeme najít ve zdroji [23]. Z útoků na HTTP se zabývám útoky usilujícími o přetížení serveru, tedy (D)DOS. Útoky zaměřujícími se na bezpečnostní díry použitého softwaru nebo na jiné vrstvy se v této práci nezohledňuji. Na konci této kapitoly zmiňuji nejčastější nástroje, kterými jsou útoky prováděny. Například nástroj LOIC. 3.1 Vyhledávací roboti Nejméně problémoví roboti. Sbírají obsah ze stránek načítáním typicky jen HTML nebo textových souborů. Google robot spouští javascript, ale jinak to obvyklé není. Většinou mívají správně nastavenou hlavičku user-agent. 3.2 SPAM roboti Více nepříjemní roboti procházejí stránky za účelem vložení nějakého svého obsahu nebo hledání bezpečnostní díry. Hlavičkami, které posílají se snaží vypadat, jako skutečný návštěvník. Na user-agent hlavičku se tedy nedá spolehnout. Roboti jsou obvykle závislí na použitém softwaru a postihují obvyklé CMS nebo fóra a podobně. Častou ochranou proti nim je captcha, tedy technika, kdy má uživatel udělat něco, co je pro něj lehké a pro stroj náročné (přepsání textu z obrázku a podobně). Nezabraňuje však procházení webu robotem, ale pouze prováděním činností jako přidávání komentářů a podobně. Vyhledáváním softwaru s bezpečnostími chybami a následným využitím bezpečnostních děr mohou provozovatelům webových stránek způsobovat nepříjemnosti. Nicméně pro běh serveru samotného nejsou příliš velkým rizikem. 9

26 10 KAPITOLA 3. ROBOTI A ÚTOKY NA HTTP 3.3 HTTP DOS Útoky pod názem DOS (denialy of service) spočívají ve snaze přetížit cíl množstvím nebo náročností požadavků a tím dosáhnout zastavení obsluhy běžného provozu [24]. Na úrovni HTTP se jedná o posílání velkého množství požadavků. Typicky útočník nečeká na odpovědi nebo je zahazuje. Typicky posílá požadavky na stále stejnou URL. Známým nástrojem, které je umožňuje, je nástroj LOIC popsaný dále. Od následující skupiny se liší tím, že požadavky pochází z jednoho zdroje (IP adresy). Na postiženém serveru se dá použít limit na počet požadavků z jedné IP adresy, který dokáže útok omezit. Tato možnost už je ve webových serverech běžně implementována a není problém ji nastavit. 3.4 HTTP DDOS DDOS (distributed denialy of service) je distribuovanou obdobou DOS. Provoz tedy přichází z více míst najednou [24]. Problémem pro jeho omezení je právě to, že provoz pochází z více míst, která se mohou v čase měnit a je tedy problém danou IP adresu zablokovat. Provoz jednoho útočníka už nemusí tolik vyčnívat nad ostatní, takže nastavení maximálního počtu požadavků z jedné IP adresy může omezovat i skutečné uživatele, kteří používají NAT. Dále zmíněný nástroj LOIC umí synchronizovat útočníky a je tedy použitejný i pro DDOS útoky. 3.5 Nástroje na provádění útoků Nejrozšířenější nástroj pro provádění DDOS útoků má název LOIC, novější generaci zastupuje nástroj HOIC. Dále je představím blíže LOIC Zkratka LOIC (Low orbit ion cannon) označuje poslední dobou velmi známý nástroj na provádění (D)DOS útoků. Umožňuje zasílat požadavky na úrovni TCP/UDP nebo HTTP požadavky. Požadavky, které generuje, jsou typicky všechny stejné a není příliš náročné je odhalit. Na obrázku 3.1je příklad okna nástroje LOIC nastaveným pro útok na stroj IP a portem HOIC Jedná se o chytřejší verzi LOIC, která pracuje čistě na HTTP. Nemusí posílat stejné požadavky a umožňuje manipulovat s hlavičkami tak, aby bylo složitější jeho požadavky na serveru odfiltrovat. Na obrázku 3.2 je příklad okna nástroje HOIC s nastavenými cíly před spuštěním útoku.

27 3.5. NÁSTROJE NA PROVÁDĚNÍ ÚTOKŮ 11 Obrázek 3.1: Okno nástroje LOIC (Windows 7) Jeho výhodou jsou konfigurační soubory, pomoci kterých lze nastavit útok tak, aby byly v požadavcích různé hlavičky nebo Cookies. Níže uvedený příklad je ze souboru GenericBoost.hoic, který je součástí balíku s nástrojem samotným. Hlavička user-agent může být libovolně měněna. useragents.append "Googlebot/2.1 ( " useragents.append "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-us) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/534.14" useragents.append "Mozilla/5.0 (Windows NT 5.1; U; Firefox/5.0; en; rv: ) Gecko/ Firefox/3.5.6 Opera 10.53" Nastavení refereru, tedy adresy, odkud klient přišel se dá nastavit například na vyhledávání google nebo přímo na cílovou URL. Požadavek potom vypadá, že směřuje na prvek, který je součástí nějaké webové stránky (obrázek a podobně). // populate referer list referers.append " referers.append URL // Add random headers randheaders.append "Cache-Control: no-cache" randheaders.append "If-Modified-Since: Sat, 29 Oct :59:59 GMT" randheaders.append "If-Modified-Since: Tue, 18 Aug :54:49 GMT"... Nastavování hlaviček se také může dít automaticky pomocí následujících řádků.

28 12 KAPITOLA 3. ROBOTI A ÚTOKY NA HTTP Obrázek 3.2: Okno nástroje HOIC (Windows 7) // generate random referer Headers.Append "Referer: " + referers(rndnumber(0, referers.ubound)) // generate random user agent (DO NOT MODIFY THIS LINE) Headers.Append "User-Agent: " + useragents(rndnumber(0, useragents.ubound)) // Generate random headers Headers.Append randheaders(rndnumber(0, randheaders.ubound)) Nástroj HOIC je napsán ve Visual Basicu a během testování mi několikrát spadl (OutOfBounds Exception), nicméně jeho funkcemi je třeba se zabývat. Výsledkem přehledu možností nástrojů na (D)DOS útoky je, že nelze důvěřovat hlavičkám ani jiným parametrům, které klient může svévolně měnit.

29 Kapitola 4 Získávání dat pro rozlišení HTTP požadavků Pro filtrování obsahu je třeba nejprve nadefinovat a získat data, na základě kterých budeme filtrování provádět. Obecně můžeme data získávat na serveru, klientovi nebo po cestě. Pro získání představy o provozu při vývoji můžeme využít i klienta, nicméně při ostrém provozu je třeba být na serveru nebo na proxy serveru před aplikačním serverem. Případné zablokování klienta je vhodné provést co nejblíže k němu. Tedy pokud možno ne na serveru samotném. Je vhodné předřadit aplikačnímu serveru reverzní proxy server. V této kapitole popisuji jaké způsoby získávání dat jsem využil (od logu webserveru po data z hashtabulky filtru HTTP požadavků). 4.1 Konfigurace Obrázek 4.1: Přidání proxy mezi webserver a klienta 13

30 14 KAPITOLA 4. ZÍSKÁVÁNÍ DAT PRO ROZLIŠENÍ HTTP POŽADAVKŮ Typicky se klient připojuje přímo k webovému serveru. Pro monitorování provozu a blokování případného útoku je vhodné použít reverzní proxy server. 4.2 Log webserveru Webové servery typicky vytváří logy provozu už ve výchozím nastavení. První data mám z Apache HTTPD, ale formát dat je obvykle stejný i u jiných serverů [04/May/2012:12:05: ] "GET /wp-content/themes/glyphicons /style.css HTTP/1.1" " "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/535.19" Z takového záznamu můžeme získat identifikaci klienta (IP, případně user-agent) základní informace o požadavku HTTP kód odpovědi HTTP referer Z informací, které bychom potřebovali dále jsou to například content-type odpovědi nebo čas, který zabralo vyřízení požadavku. 4.3 Log reverzní proxy Toto řešení bylo třeba, abych získal časy obsluhy požadavků. Apache HTTPD v aktuální verzi (řady 2.2) neumí přesnější měření než na celé sekundy. To je nedostatečné, tak mu bylo nutné předřadil reverzní proxy server nginx, který od verze měří délku obsluhy požadavku s přesností v milisekundy. Zbytek zachytávaných dat zůstal stejný. Pouze byl pro lepší zpracování ukládán do formátu CSV. Nastavení logování v nginx se dá provést v konfiguračním souboru a to definováním vlastního formátu logu. log_format cas "$time_local","$remote_addr","$status","$request_length", "$body_bytes_sent","$request_time","$connection","$pipe","$host", "$request","$http_referer","$http_user_agent" ; access_log /var/log/nginx/proxy.log.csv cas; Záznamy potom vypadají, jak je uvedeno níže. Oproti předchozímu případu obsahují navíc čas zpracování obsahu (v tomto případě 0.485s). Jedná o skutečný čas mezi přijetím požadavku a momentem, kdy se začne odesílat odpověď. Doba, kterou klient odpověď stahuje, zde není započítána.

31 4.4. VLASTNÍ INFO LOG FILTROVACÍHO MODULU 15 "27/Sep/2011:23:19: "," ","404","788","1281","0.485","1310",".", "dev.aurem.cz","post /source/ajax/postcomment.php HTTP/1.1","dev.aurem.cz", "Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: ) Gecko/ Firefox/4" 4.4 Vlastní info log filtrovacího modulu Od této chvíle máme k dispozici vývojovou verzi modulu pro filtrování obsahu, který jako součást této práce píšu, takže je možné jej použít na zachytávání dat. Vlastní modul může generovat zápisy do logu s úrovní info nebo notice, pro uživatele jsou tyto úrovně ve výchozí konfiguraci vypnuté, ale v případě potřeby se dají ukládat. V prvních fázích vývoje modulu byly tyto logy používány pro odhalování chyb modulu (později přestaly být potřeba a vzhledem k množství informací a řádků začaly být nepřehledné). Informace se dají ukládat příkazem, který je na příkladu níže. Za zmínku stojí, že pro zápis do logu musím uvést požadavek, kterého se zápis týká (v příkladu reprezentován proměnnou r). ngx_log_error(ngx_log_info, r->connection->log, 0, "ANDDOS client[%d]: request_count: %d; http200_count: %d, key: %d, avg_time: %d, pass_seq: %s", i, ngx_http_anddos_clients[i].request_count, ngx_http_anddos_clients[i].http2_count, ngx_http_anddos_clients[i].key, ngx_http_anddos_clients[i].avg_time, (char *) ngx_http_anddos_clients[i].pass_seq); Pomocí výše uvedených příkazů byly generovány záznamy níže. První příklad se týká stavu konkrétního klienta, jehož index v hashtabulce byl /04/15 15:55:15 [info] 9563#0: *206 ANDDOS client[7047]: request_count: 68; http200_count: 36, key: 0, avg_time: 1, pass_seq:!%ry]! X!,Y"]z6+lO,^4"n/c* =ib} while reading response header from upstream, client: , server: localhost, request: "GET /glyphicons/wp-content/themes/glyphicons/images/ico-cc.png HTTP/1.1", upstream: " ico-cc.png", host: "localhost:8080", referrer: " Druhý příklad ukazuje globální stav serveru, tedy zjednodušeně průměr přes všechny aktivní klienty a některé další informace. Informace uvedené v tomto příkladě pochází z vývoje, nezahrnuje tedy všechny uchovávané informace o klientech a stavu serveru. 2012/04/15 15:55:15 [info] 9563#0: *206 ANDDOS state[]: request_count: 68; http200_count: 36, client_count: 1, avg_time: 1 while reading response header from upstream, client: , server: localhost, request: "GET /glyphicons/ wp-content/themes/glyphicons/images/ico-cc.png HTTP/1.1", upstream: " host: "localhost:8080", referrer: "

32 16 KAPITOLA 4. ZÍSKÁVÁNÍ DAT PRO ROZLIŠENÍ HTTP POŽADAVKŮ 4.5 Dočasný soubor s vnitřním stavem filtrovacího modulu Sekvenční čtení logu přestávalo při více událostech být přehledné. Protože v modul udržuje v paměti hashtabulku s daty o klientech, není problém jí vypisovat do souboru. Zde jsou jak statistické informace o klientech, tak jejich hodnocení (skore). Význam jednotlivých paramterů je blíže popsán v kapitole Vlastní algoritmus. Parametr ip_ua, který slouží jako zdroj pro hash funkci, kterou se získá adresa do hashtabulky, je ukládán pouze pro testovací a ladící účely. V reálném nasazení by byl z důvodu úspory paměti vypnut. ANDDOS state level: 0; clients: 1; reqs: 69; 304cnt: 33; http1cnt: 0; http2cnt: 36; http3cnt: 33; http4cnt: 0; http5cnt: 0; avgtime: 1; htmlavgtime: 163; html: 3; css: 2; javascript: 5; image: 26; other: 0 ANDDOS clients set: 1; index: 7047; httpscore: 0; mimescore: 0; timescore: 0; seqscore: 0; reqs: 69; 304_cnt: 33; http1cnt: 0; http2cnt: 36; http3cnt: 33; http4cnt: 0; http5cnt: 0; avgtime: 1; htmlavgtime: 163; html: 3; css: 2; javascript: 5; image: 5/26; other: 0 pass_seq:!%ry]! X!,Y"]z6+lO,^4"n/c* =ib} ip_ua: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Informace přímo z prohlížeče klienta Pro vývojové účely může být zajímavé porovnání informací z logu serveru s informacemi přímo z developer tool, případně webové konzole, prohlížeče. Takový příklad jsem uvedl v kapitole Prostředí řešení problému 2.1. Při vývoji bylo zjištěno, že prohlížeče se liší v pořadí požadavků poslaných na objekty uvnitř HTML stránky. 4.7 Portál httparchive.org Poměrně nový projekt, který shromažďuje statistiky o obsahu na webu. Sleduje například jaké další prvky obsahují www stránky, používané hlavičky pro cachování obsahu a podobně. Podle zdroje httparchive má k zanalyzováno URL. Umožňuje nám tedy ověřit některá místní měření srovnáním a také potvrdit, jak vypadá obvyklá webová stránka.

33 Kapitola 5 Analýza parametrů pro rozlišování HTTP požadavků Pro rozpoznávání legitimních požadavků od robotů musí být definovány parametry, které u požadavků měříme. Vzhledem k tomu, že se tato práce zabývá rozlišováním na úrovni HTTP, lze takové parametry najít pouze v HTTP požadavcích nebo odpovědích na ně. V této kapitole popisuji a vysvětluji význam všech parametrů, které jsem sběrem dat získal. 5.1 Parametry Algoritmus může brát informace pouze z HTTP požadavků. Obecně nelze věřit parametrům z požadavků od klientů, protože mohou být podvržené. Snažím se vycházet z reakcí serveru na požadavky klientů. Postupnými experimenty byly vybrány a vyzkoušeny následující parametry: HTTP kód odpovědi Content-type odpovědi Doba zpracování požadavku Posloupnost URL požadavků Zbylé HTTP hlavičky 5.2 HTTP kód odpovědi Jak bylo zmíněno v úvodu do problematiky, HTTP rozlišuje 5 kategorií odpovědí. Jsou to 1xx, 2xx, 3xx, 4xx, 5xx, přesně definovány jsou v RFC 2616 [21]. Jedná se o kódy HTTP odpovědí. Tedy něco, co generuje náš server a tedy tomu můžeme věřit. Avšak nemáme je k dispozici před vyřízením požadavku. 17

34 18 KAPITOLA 5. ANALÝZA PARAMETRŮ PRO ROZLIŠOVÁNÍ HTTP POŽADAVKŮ xx Stav pro informační zprávy protokolu HTTP, používá se například pro informaci klienta, že se na zpracování jeho požadavku stále pracuje. V běžném provozu není příliš obvyklý xx Při načtení stránky je obvyklý kód odpovědi z kategorie 2xx. Což znamená, že je požadavek vyřízen a v odpovědi se budou posílat data. Takto zakončený požadavek znamená pouze to, že jej server úspěšně obsloužil (a tedy, že je funkční nebo není příliš přetížen) xx Kódy 3xx se používají zejména ke dvěma účelům. Jsou to přesměrování a informace, že obsah nebyl změněn. Přesměrování může být součástí architektury aplikace (redirect-after-post) nebo trvalé přesměrování znamenající, že požadovaný obsah je jinde. Ani jedno není pro rozlišení robota od legitimního klienta směrodatné. Zvláštní je kód 304 Not-Modified, který klientovi místo obsahu vrátí pouze informaci, že se daný obsah nezměnil. K jeho vysvětlení je nutné se podívat do požadavku, který server takovou odpovědí obsloužil. Mezi HTTP hlavička požadavku můhou být podmínky, které mají serveru pomoci rozhodnout, jestli klient skutečně požaduje poslání obsahu nebo jen potvrzení, že se nezměnil. Hlavička může vypadat jako na příkladu níže. If-Modified-Since: Mon, 08 Aug :25:23 GMT If-None-Match:"2862fa-cf8-4a9f959a85ec0" Pokud nemá server novější verzi požadovaného souboru, než je uvedeno v If-Modified- Since, pošle klientovi pouze informaci, že se soubor nezměnil a to právě kódem 304 Not- Modified. Druhý řádek obsahuje hodnotu takzvaného ETagu. Což je identifikátor verze souboru. Narozdíl od času změny souboru dává smysl i u dynamicky generovaného obsahu. Tento klient již v odpovědi na některý z předchozích požadavků na tento soubor obržel následující informaci a při dalších požadavcích ji může poslat serveru. Date:Sun, 22 Apr :10:21 GMT ETag:"2862fa-cf8-4a9f959a85ec0" Kód 304 tedy může prokazovat, že klient má cache, kde uchovává stažené soubory, což je typické pro webový prohlížeč a tedy legitimního uživatele. Zvláštním případem by byl stav, kdy by útočník nastavoval hlavičku If-Modified-Since na čas, který je právě aktuální nebo dokonce v budoucnosti.

35 5.3. CONTENT-TYPE ODPOVĚDI xx Odpovědi s takovým kódem znamenají chybu obsahu. Nejznámější kód je snad kód 404 Not-Found a také 403 Not-Autorized. Při rozlišení legtimního klienta a útočníka je tedy vhodné sledovat četnost takových odpovědí xx Tyto kódy znamenají chybu serveru. Mohou znamenat chybu při zpracování nějakého skriptu (například PHP), ale může být vracena při přetížení webového serveru a to zejména kód 503 Service Unavailable. Pomocí tohoto kódu můžeme detekovat přetížení serveru a tím i případný útok Poměr zastoupení kódů odpovědí Z výše uvedených kódů jsou samostatně zajímavé 304 Not-Modified, který "zvyšuje"důvěryhodnost klienta a 503 Service Unavailable, znamenající chybu nebo přetížení serveru. Kromě těchto zvláštních kódů odpovědí, je zajímavým parametrem poměrné rozdělení počtu obsloužených požadavků podle jejich kategorií. Předpokládám, že poměr kódů odpovědí typický pro běžný provoz se bude od případného útoku lišit. 5.3 Content-type odpovědi Webová stránka typicky obsahuje další objekty, které jsou načítány jako zvláštní požadavky. Nejčastěji to jsou kaskádové styly, obrázky a soubory s javascriptem. Všechny tytou soubory jsou třeba až k vykreslení stránky v okně prohlížeče. Takové objekty, které stránka obsahuje, jsou stahovány až po načtení a zpracování vlastního HTML dokumentu. Typ obsahu odpovědi je nastaven webovým serverem před jejím posláním klientovi. Server pro zjištění druhu obsahu obvykle používá magic tabulku. Content-type jde také nastavit přímo v obsahu, který se posílá (v HTML hlavičkách nebo skriptech). Vzhledem k tomu, že je hlavička Content-type nastavována serverem, můžeme ji považovat za důvěryhodnou Text/html Samotné HTML dokumenty ("kostry"stránek) jsou text a většinou mají i správně nastaven typ, že se jedná o HTML. U požadavků na takové dokumenty očekáváme, že budou první a další se na ně budou odkazovat.

36 20 KAPITOLA 5. ANALÝZA PARAMETRŮ PRO ROZLIŠOVÁNÍ HTTP POŽADAVKŮ CSS, Javascript, obrázky Kaskádové styly a javascript prvky jsou textové soubory. K jejich načtení dochází až po zpracování vlastní kostry stránky v prohlížeči klienta. Na obrázky bývá odkazováno primárně ze dvou míst. Přímo v HTML dokumentu, kde vystupují jako fotky, loga a podobně. Množstevně více obrázků potom může být v souboru se stylem, kde jde o doplnění grafiky nebo ikonek. Typicky takové obrázky bývají velikostí jednotek až desítek kb, ale pokud není použita technologie CSS sprite, může být požadavků na obrázky větší množství Částečná načtení stránky (AJAX) Kromě zkreslení požadavků ukládáním dat do lokání cache prohlížeče mohou být části stránky načítány i samostatně a to zejména požadavky, které vrací přímo HTML kód nebo JSON, který je zpracován až na straně klienta. Pokud jsou v těchto částečných odpovědích obsaženy další prvky, dojde k jejich načtení. Množství prvků, které jsou takto požadovány je však nižší, takže pro server působí chování klienta odlišně Obsah stahovaný z CDN Je nutné počítat se stavem, kdy je část obsahu, který webové stránka obsahuje, umístěna na cizích serverech a tedy nemám možnost ověřovat, zda klient požaduje všechen obsah nebo ne. Zastoupení prvků ve webech je asi 20% (viz Vzorový web a [10]) HTTP referer Při načítání prvků do HTML dokumentu prohlížeč nastavuje hlavičku požadavku HTTP referer, ve které je uložena URL odkud klient přišel. Klient ji tedy může podvrhnout, takže není vhodné jí důvěřovat. Pokud bychom ji ale za důvěryhodnou považovali, je možné podle ní vytvářet propojení mezi požadavky. Referer může mít pro poznání chování klienta dva významy objekt stránky (obrázek apod.) odkazuje na stránku, do které patří požadavek na stránku má nastaveno, na jaké URL byl předtím Poměr zastoupení Content-type Jako u HTTP kódů odpovědí i zde existuje pro danou webovou stránku typický poměr v jakém jsou zastoupeny jednotlivé typy obsahu odpovědí. Vzhledem k tomu, že útočníci obvykle nezpracovávají odpovědi, ale jen posílají velké množství požadavků, dá se předpokládat, že se budou v zastoupení Content-type odpovědí znatelně lišit. Otázkou může být stav, kdy mají útočníci připraveny i požadavky na všechny objekty, které webová stránka obsahuje.

37 5.4. DOBA ZPRACOVÁNÍ POŽADAVKU Doba zpracování požadavku Protože se snažím zaměřit na přístup, kdy se soutředím na reakci serveru na požadavky více, než na samotné klienty, může být čas zpracování požadavků důležitý Dynamický obsah Požadavky na soubory, které jsou generovány nějakým skriptem, případně ještě s dotazem do databáze, mohou zabrat různě dlouhou dobu v závislosti na aktuálním vytížení serveru i na "náročnosti"konkrétního požadavku. Je tak možné sledovat "pomalé"požadavky Statický obsah Statický obsah není serverem nijak zvlášť zpracováván, ale přečten z disku (nebo jiného paměťového média) a odeslán klientovi. Čas jeho vyřízení nezávisí tolik na vytížení CPU serveru, ale více na reakci paměťového média serveru Nezměněný obsah Jak bylo zmíněno dříve, požadavky mohou být vyřízeny HTTP stavem 304, tedy Not- Modified. V tomto případě sice dojde ke čtení z disku (nebo paměti), ale pouze za účelem zjištění, zda se soubor nezměnil. Ke čtení celého obsahu souboru nedochází. Odpovědi na tyto požadavky jsou vyřízeny řádově rychleji, než v případě poslání celého obsahu odpovědi Rozlišování časů požadavků Vzhledem k tomu, že odpovědi s kódem 304 mají výrazně kratší dobu vyřízení, než ty se skutečně poslaným obsahem, není vhodné je při zpracování dávat dohromady. Časy vyřízení požadavků jsou tedy sledovány pro každého klienta. A to jak čas zpracování HTML stránek, tak ostatního obsahu, který může být pouze čten z disku. 5.5 Posloupnost URL požadavků Dosud uvedené parametry nebraly ohled na pořadí požadavků v jakém je server zpracovává. Jako další parametr mi připadalo vhodné sledovat posloupnost URL požadavků pro každého klienta. URL požadavku je řetězec skládající se zejména z názvu stroje (host) a cesty na daném stroji (path).

38 22 KAPITOLA 5. ANALÝZA PARAMETRŮ PRO ROZLIŠOVÁNÍ HTTP POŽADAVKŮ Formát uchovávání Pro jejich uchování a vyhodnocování je nutné je předzpracovat, nejlépe hashovat. Předpokládám, že množství URL, které vedou na různé prvky konkrétního webu je v řádku stovek, přinejmenším desítek. Kolize vzhledem ke stálosti hashovací funkce příliš nevadí, ale je poměrně velký tlak na velikost zabrané paměti. Takže je vhodnější zvolit úspornější reprezentaci posloupnosti URL Počet uchovávaných požadavků Pro jejich uložení tedy můžu využít pole 1-2 Bytových hodnot. Délka pole, tedy maximální počet URL, který bude u klienta uložen je otázka. Pro základní rozlišení by měl stačit počet požadavků, stačící k načtení několika stránek. Paměť na URL by měla být dostatečná. Při překročení kapacity můžeme pokračovat podle několika strategií zapisovat jako do kruhového registru smazat uložené URL a začít znovu přestat URL zapisovat úplně Vzhledem k omezeným možnostem, jak rychle vyhodnocovat posloupnost URL klienta v závilosti na všech ostatních klientech, je dostatečné zvolit ukládání URL požadavků pouze do prvního naplnění pole s posloupností URL Vyhodnocování posloupnosti požadavků Posloupnost URL požadavků od podezřelých klientů může mít několik poznávacích znamení stále stejná URL malá různorodost URL opakující se část posloupnosti URL Stále stejná URL je typická pro útoky nástrojem LOIC, kdy je na jednu URL odesláno velké množství požadavků. Různorodá posloupnost URL svědčí o tom, že klient stahuje kromě samotné stránky i další prvky (obrázky a podobně). Nicméně také může požadovat různé HTML stránky. V případě, že by útočník posílal posloupnost požadavků, která by měla simulovat skutečné prohlížení stránky, můžeme očekávat, že se posloupnost začne opakovat. Je zde ale problém s maximálním počtem URL, které chceme uchovávat, a vyhledáváním opakování v nich. Dalším rizikem je i to, že někteří klienti mohou na posílat požadavky ve stejném pořadí. Při vyhodnocování posloupností URL požadavků je třeba přihlížet k ostatním parametrům hodnocení klienta. Blokování jen na základě posloupnosti URL by bylo velmi rizikové.

39 5.6. DALŠÍ HTTP HLAVIČKY Další HTTP hlavičky HTTP požadavek může obsahovat větší množství hlaviček. Nicméně nejsou povinné a všechny pochází od klienta, takže je na zvážení, zda se jimi vůbec zabývat Cookie Cookie se používá pro udržení stavu nad HTTP, který samotný stavový není. Mohou zde být informace nastavené aplikační logikou webové stránky, které se požadavek týká. Například u webových stránek běžících na PHP, je obvyklá cookie PHPSESSID. Vzhledem k různorodosti a nedůvěryhodnosti těchto hlaviček je prozatím do algoritmu zahrnovat nebudu. Smysl by měly při propojení s aplikační logikou, které je nastavuje Accept Používá se pro informování serveru, že klient rozumí kompresi, danému kódování a podobně. Tyto hlavičky by se daly použít pro bližší rozlišení klienta, nicméně jim opět nemohu plně důvěřovat. Níže uvedené Accept hlavičky posílá prohlížeč Google Chrome (verze 18). Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:windows-1250,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:cs-CZ,cs;q= Identifikace klienta Jak už bylo zmíněno, klient pro načtení jedné stránky posílá na server i desítky požadavků. Požadavky pochází z jedné IP adresy, nabízí se tedy rozlišování klientů podle IP IP adresa IP adresa, ze které přišel požadavek je na úrovni HTTP již jistá identifikace klienta. Pro přijetí HTTP požadavku je nutné navázané TCP spojení, které vyžaduje oboustranou komunikaci a tak je jisté, že na druhé straně spojení někdo skutečně je. V praxi je častá situace, kdy je za jednou IP adresou více klientů - NAT (network address translation). Za předpokladu, že je NATem několik legitimních klientů a jeden útočník, došlo by k zablokování všech. To z pohledu správce serveru není zásadní problém, ale stojí za zvážení, jestli nevyužít nějaké další možnosti HTTP hlavička user-agent V HTTP hlavičkách se nachází hlavička s názvem user-agent, ve které typicky bývá identifikace prohlížeče a operačního systému. Například:

40 24 KAPITOLA 5. ANALÝZA PARAMETRŮ PRO ROZLIŠOVÁNÍ HTTP POŽADAVKŮ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Hlavička user-agent se nachází v požadavku (nikoliv v odpovědi) a tak ji klient může libovolně nastavovat. Tato hlavička tedy není směrodatná pro identifikaci klienta. U požadavků od legitimních klientů bychom jí věřit mohli, ale od robotů bude s největší pravděpodobností podvržená. Otázka je, jestli má cenu se jí vůbec zabývat. V úvahu přichází řešení, kdy je pro jednu IP adresu možné rozlišovat více klientů podle jejich user-agent. V každém případě ale musí být omezen jejich počet. V případě, kdy bychom chtěli považovat za klienta unikátní kombinaci IP a user-agent HTTP hlavičky, použili bychom jako vstup hashfunkce pro získání adresy záznamu hashtabulky, následující řetězec Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Kontrola čekání klienta na odpověď Některé druhy útoků spočívají v zahlcení sereru požadavky, kdy útočníci nečekají na odpověď nebo ji rovnou zahazují. Při těchto útocích nemusí být čas vyhodnocovat požadavky nějakou chytřejší logikou (na základě parametrů popsaných v odstavcích výše). Stojí tedy za zvážení blokovat tyto klienty na základně nějakého absolutního parametru Počty spojení Webové i jiné servery typicky obsahují direktivu určující, kolik nejvíce souběžných spojení mohou obsluhovat. Spojení nad tento počet jsou odmítnuta. Tuto direktivu je třeba mít nastavenou tak, aby server stíhal rozhodovat o blokování klientů. Více o nastavení v následující kapitole nginx Vynucení přes cookie Pro ověření, zda klient skutečné odpověď na jeho požadavek zpracuje, je možné poslat mu určitou cookie a kontrolovat, její nastavení v dalších požadavcích. Tento přístup má ale několik úskalí: V případě, že jsou klienti za NAT 1 em a mají stejný prohlížeč (nebo podle aktuální konfigurace stejná IP nebo jiný stav, kdy více klientů považujeme za jednoho), můžeme poslat Cookie všem a jeden z klientů by nám ji vrátil a pokud by mezi nimi byl útočník se stejně nastavenými hlavičkami pro určení identity, došlo by ke zmatení. K tomuto zmatení může dojít i v jiných případech, ale je nutné mu předcházet. Během vývoje se objevil modul do serveru nginx s názvem test-cookie, který kontrolu přes obsah cookie řeší. Od vlastní logiky pro kontrolu cookie, v rámci modulu vytvořeného k této práci, jsem tedy upustil. 1 NAT - network address translation, překlad adres, více počítačů za jednou IP adresou

41 Kapitola 6 nginx Protože v této práci plánuji vytvořit modul serveru nginx, představuji server samotný. Zabývám se také ukázkou, jak vytvořit modul serveru nginx včetně ukázky nejdůležitějších kusů zdrojového kódu a také uvádím ukázky konfigurace. Na konci kapitoly zmiňuji důvody, proč jsem vybral právě nginx a ne například Apache HTTPD. 6.1 Server nginx Jedná se o lehký server, který vytvořil Igor Sysoev a je šířen pod obdobou BSD licence. Podle Netcraft statistik obsluhuje 10,09% nejnavštěvovanějších webů [16]. Napsán je v jazyce C, při běhu používá jeden master proces a jeden nebo více worker procesů. Ty obsluhují požadavky klientů a z bezpečnostních důvodů nemají práva superuživatele. Jeden proces zpracovává větší množství klientů a nevytváří pro každý požadavek nové vlákno, při běhu tedy nezabírá tolik paměti jako Apache HTTPD. Oproti zmíněnému Apache HTTPD má méně vlastností, méně modulů, méně dokumentace, ale je rychlejší. 6.2 Vnitřní skruktura Server se i vnitřně skládá z jádra a modulů. Jádro obsahuje funkce například pro načtení konfigurace a ty, které jsou využívány více moduly (například hash). Ostatní funkčnosti, jako obsluha požadavků nebo logování, jsou realizovány pomocí modulů Datové typy Nginx využívá téměř na vše své vlastní datové typy a vlastní základní funkce, které s nimi pracují. Při vytváření modulu na ně není možné nenarazit, proto představím několik nejzákladnějších. ngx_str_t je kontejner pro řetězec, je to struktura obsahující pole znaků (unsigned char) a jeho délku. 25

42 26 KAPITOLA 6. NGINX Při procházení seznamů nebo konfigurace se používá hash_t a elt_t, tedy hashtabulka a její element. Struktura ngx_http_request_t reprezentuje samotný HTTP požadavek, obsahuje jak žádost (požadavek), tak odpověď a množství hlaviček. Dále servisní informace serveru. Například ke kterému logu patří a podobně Reprezentace konfigurace Konfigurace načtená z konfiguračních souborů je vnitřně reprezentována hashtabulkami a RB stromy. Tyto datové struktury jsou vytvořeny při startu serveru a za běhu se již nemění. Optimalizovány jsou na co nejrychlejší hledání/čtení. Vzhledem k tomu, že některé konfigurační direktivy mohou být na různých úrovních (pro server, adresář a podobně), provede se při staru serveru skládání konfigurace. Po dobu běhu serveru je pak konfigurace pouze ke čtení Zdrojový kód Soubory se zdrojovým kódem jsou rozděleny do následujících adresářů core - obsahuje soubory se základními funkcemi jako hash a vnitřní paměťové struktury event - funkce pro řízení procesů serveru http - všechny funkce serveru týkající se HTTP mail - funkce pro použití nginx jako mail proxy serveru misc - testovací funkce os - funkce nginx specifické pro OS (Linux, FreeBSD, Darwin,...) Funkce související s obsluhou HTTP požadavků jsou ve složce http, kde se nachází soubory se základní funkčnostmi a podložka modules pro rozšíření. 6.3 Vytváření modulu Psaní pluginu do webserveru nginx pro mě nebylo zrovna triviální záležitostí. Z části je to jazykem C, ale větší podíl na tom má vnitřní struktura nginxu a nedostatek aktuální dokumentace jinde, než přímo ve zdrojovém kódu serveru. Výhodou je, že téměř vše uvnitř je modul a tak se dá dobře inspirovat existujícími moduly (nejlépe přímo od autorů serveru, moduly třetích stran nebývají tak dobře komentované).

43 6.3. VYTVÁŘENÍ MODULU nginx module API Moduly mohou být více druhů, podle rozhraní, které využívají. handler - generování odpovědí na požadavky filter - zpracování již vygenerovaných odpovědí load balancer - výběr, kam požadavek k vyřízení předat Handler typicky pracuje s požadavky, které byly přijaty od klientů, ještě před vyřízením. K dispozici má tedy samotný požadavek. Jeho hlavní rolí v této práci je rozhodování, jestli daný požadavek vyřídí nebo zahodí. Vnitřním omezením serveru nginx je, že požadavek je obsluhován právě jedním handlerem. Typickým handlerem je proxy nebo fast_cgi modul. Zvláštním případem handleru je upstream handler, který poskytuje několik callback funkcí pro právě obsluhovaný požadavek. Tyto funkce jsou určeny bližší kontrole, kde a jak je požadavek zpracováván. Filter je volán po poskládání dat, která se mají poslat klientovi. V této chvíli tedy už známe, co server odpověděl (HTTP kód, hlavičky, vlastní tělo odpovědi) a umíme dopočítat, kolik času požadavek aplikačnímu serveru zabral. V mé práci je modul využívající filtr použit na ukládání statistických informací o požadavku. Informace, které se ukládají jsou vybrány, aby umožnili s co nejlepší přesností rozlišovat klienty podle chování na lidi a roboty. Load balancer rozhoduje, kam budou požadavky poslány k vyřízení. V této práci jej nepoužívám Struktura modulu Samotný modul pro server nginx se skládá typicky ze 3 souborů config - nastavení pro zakompilování modulu do serveru module.conf - nastavení modulu pro běh ngx_http_module.c - vlastní zdrojový kód modulu Soubor config předává název a data potřebná pro zakompilování do serveru samotného #cat config ngx_addon_name=ngx_http_anddos_module HTTP_AUX_FILTER_MODULES="$HTTP_AUX_FILTER_MODULES ngx_http_anddos_module" NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_anddos_module.c" Vlastní zdrojový kód se nachází v souboru, který je konvencí pojmenovat podle následujícího vzoru (přenastavením v souboru config lze upravit). ngx_<http nebo mail>_<název>_module.c

44 28 KAPITOLA 6. NGINX Kód modulu Samotný zdrojový kód modulu se skládá z následujících částí Include potřebných souborů serveru #include <ngx_config.h> #include <ngx_core.h> #include <ngx_http.h> Pro zaregistrování funkcí modulu do příslušných API serveru je třeba nastavit struktury, které server nginx od modulu čeká. V případě, že je v konfiguračním souboru direktiva "anddos", zpracovává požadavky handler modulu funkcí ngx_http_anddos, které je předána jako parametr struktura ngx_http_request_t reprezentující pořadavek. static ngx_command_t ngx_http_anddos_commands[] = { { ngx_string("anddos"), NGX_HTTP_LOC_CONF NGX_CONF_NOARGS, ngx_http_anddos, 0, 0, NULL}, }; ngx_null_command Funkci, ktera bude zpracovávat statistické informace o požadavcích, je třeba přidat do fronty funkcí, které požadavky zpracovávají, už při startu serveru zavoláním funkce ngx_http_anddos_filter_init. static ngx_http_module_t ngx_http_anddos_module_ctx = { NULL, /* preconfiguration */ ngx_http_anddos_filter_init, /* postconfiguration */ NULL, /* create main configuration */ NULL, /* init main configuration */ NULL, /* create server configuration */ NULL, /* merge server configuration */ NULL, /* create location configuration */ NULL /* merge location configuration */ }; Místem, kde se dá dohromady nastavení modulu, je proměnná datového typu ngx_module_t. Je do ní přiřazen jak filtr, tak handler. Funkce pro události jako je inicializace modulu, serveru atd., jsme v tomto případě nepoužili. ngx_module_t ngx_http_anddos_module = { NGX_MODULE_V1,

45 6.3. VYTVÁŘENÍ MODULU 29 }; &ngx_http_anddos_module_ctx, /* module context */ ngx_http_anddos_commands, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ NULL, /* init process */ NULL, /* init thread */ NULL, /* exit thread */ NULL, /* exit process */ NULL, /* exit master */ NGX_MODULE_V1_PADDING Přiřazení handleru z modulu (funkce ngx_http_anddos_request_handler) k požadavku. static char * ngx_http_anddos(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ngx_http_core_loc_conf_t *clcf; clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module); clcf->handler = ngx_http_anddos_request_handler; } return NGX_OK; Zavedení funkce ngx_http_anddos_learn_filter static ngx_int_t ngx_http_anddos_filter_init(ngx_conf_t *cf) { ngx_http_next_header_filter = ngx_http_top_header_filter; ngx_http_top_header_filter = ngx_http_anddos_learn_filter; } return NGX_OK; Instalace modulu Server nginx samotný se skládá pouze z jedné binárky, moduly se do něj tedy musí dostat už při kompilaci. Pro instalaci jsou třeba zdrojové kódy nginx a zvlášť zdrojový kód požadovaného modulu../configure --add-module=../anddos/anddos #next params configuring additional modules adding module in../anddos/anddos + ngx_http_anddos_module was configured

46 30 KAPITOLA 6. NGINX Dále jde o standardní kompilaci a instalaci make make install 6.4 Nastavení Server nginx je pro použití daného modulu potřeba nastavit. Podíváme se na nastavení nginx jako proxy serveru a uvedu některá doporučená nastavení na úrovni operačního systému nginx Hlavní konfigurační soubor se typicky nazývá nginx.conf a obsahuje několik úrovní, ve kterých lze konfiguraci provádět. / - direktivy pro celý server, například nastavení procesů nebo práv, pod kterými nginx běží http - direktivy pro všechny HTTP servery, typicky formát logů a podobně server - direktivy pro jednu instanci serveru (virtualhost) location - direktivy pro danou složku Níže uvádím příklad nastavení nginx jako reverzního proxy serveru. Požadavky, které přijdou na localhost port 8080 budou předány k vyřízení webovému serveru poslouchajícímu na localhost portu 1080 a odpověď bude přeposlána klientovi. server { listen 8080; server_name localhost; location / { anddos; proxy_pass proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_max_temp_file_size 0; } }

47 6.5. DISKUSE K JINÝM WEBSERVERŮM OS Na hostitelském stroji se typicky nastavuje firewall a případně limit TCP/IP spojení. Pro příklad uvádím GNU/Linux. Firewall využívá funkcí jádra přes nástroj IP Tables. Níže uvádím příklady práce s iptables. #povoleni prichoziho provozu iptables -A INPUT -p tcp --dport 80 -j ACCEPT #pripadne zablokovani dane IP iptables -I INPUT -s <ip_adresa_nebo_rozsah> -j DROP Nastavení limitu TCP spojení, případně další nízkoúrovňová nastavení se provádí v jádře přes virtuální adresář /proc. Podrobnější popis jednotlivých parametrů, které se zde dají nastavit jsou uvedeny ve zdroji [11]. Pro ochranu před útoky na úrovni HTTP není většinou nutné tyto parametry nastavovat, ale při útocích na nižších vrstvách (TCP/UDP) může být vhodné nastavení důležité pro odolnost serveru. Níže uvedený příklad upravuje čas, po kterém jsou TCP spojení automaticky ukončena. echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout 6.5 Diskuse k jiným webserverům Nginx není nejpoužívanější webserver, ale je jeden z nejrychlejších. Častěji používaný je Apache HTTPD, který má lepší dokumentaci a více již existujících modulů. Další opensource serverem je například lighttpd, který je přístupem podobný serveru nginx, ale je ještě méně rozšířený. Komerční řešení MS IIS v tomto srovnání vynechávám, protože není možné pracovat s jeho zdrojovými kódy a je závislý na jednom operačním systému Apache HTTPD Jak bylo řečeno, jedná se o nejrozšířenější webový server [16]. Využívá vlastní framework pod názvem APR (Apache portable runtime), který je dokumentován v [2]. Apache HTTPD jsem nevybral zejména proto, že má při vyšší zátěži velké paměťové nároky. Princip, na jakém Apache HTTPD zpracovává požadavky spočívá v tom, že každý požadavek má vlastní vlákno, které ho obsluhuje. Tato vlákna mohou být z důvodu optimalizace určitým způsobem předpřipravená, jak je uvedeno v dokumentaci [3]. Nicméně stále se jedná o větší výkonový problém, než u nginx, který obsluhuje požadavky sekvenčně jedním procesem, případně jeho vlákny. Při vyšším počtu současných spojení, dochází u něj rovněž k prodloužení doby zpracování požadavku výrazně více, než v případě serveru nginx, více ve zdrojích [20] [8].

48 32 KAPITOLA 6. NGINX Osobně se mi také několikrát stalo, že Apache HTTPD při velkém množství požadavků vyčerpal paměť a server se stal dočasně nepoužitelný. Tyto problémy se dají omezit správnou konfigurací, ale připadá mi vhodnější použít server, který díky své architektuře takové problémy nemá.

49 Kapitola 7 Vlastní algoritmus V této kapitole se zaměřuji na popis algoritmu, kterým požadavky klientů zpracovávám a případně blokuji. V popisu algoritmu popisuji, jak jsou uchovávána data, která algoritmus používá, dále jakým způsobem zpracovává požadavky a jak je rozhodnuto o zamítnutí požadavku. Pro lepší vysvětlení principu algoritmu uvádím diagram 7.2. Poslední částí této kapitoly je implementace, kde zdůvodňuji datové struktury, které používám, a jiné implementační detaily. 7.1 Princip algoritmu Každý požadavek je přijat, vyřízen a je zaznamenán ke klientovi, který ho poslal. Pro každého klienta mám záznam, který obsahuje informace o jeho požadavcích. Všichni klienti jsou nejprve povolení. Při každém požadavku je přepočítáno skore daného klienta a v případě, že je skore vyšší než aktuální práh, je klient zablokován. Přesněji jsou zablokovány všechny jeho další požadavky. Na diagramu 7.1 je zjednodušeně naznačeno, jak probíhá obsluha požadavku, který pochází od povoleného nebo zablokovaného klienta. 7.2 Uchovávání dat V paměti uchovávám informace pro jednotlivé klienty. Klient je identifikován podle IP adresy, případně user-agent HTTP hlavičky, jak je popsáno v kapitole Parametry algoritmu - identifikace klienta. Záznamy jsou uspořádány v hashtabulce v paměti. Záznam klienta v tabulce obsahuje následující parametry statistiky o požadavcích posloupnost URL požadavků položky skore 33

50 34 KAPITOLA 7. VLASTNÍ ALGORITMUS Obrázek 7.1: Základní postup zpracování požadavku legitimního (vlevo) a zablokokovaného (vpravo) klienta Získání adresy do hashtabulky Adresa je získána výpočtem hash funkce nad textovou podobou IP adresy, případně useragent hlavičky klienta a provedením modulo velikostí hashtabulky. Jako hash funkci používám vnitřní hash funkci webserveru nginx, která pro každý znak provádí kód z následujícího makra. #define ngx_hash(key, c) ((ngx_uint_t) key * 31 + c) Při zápisu klientů do hashtabulky může docházet ke kolizím, tedy situaci, kdy jsou různí klienti (rozdílné řetězce IP, případně user-agent hlavička) přiřazeni jednomu záznamu hashtabulky. Vzhledem k hashovací funkci může ke kolizím zřídka docházet při přetékání ngx u int t, ale častěji u operace výsledek hash funkce modulo velikost hashtabulky. Otázkou je, jak moc kolize vadí. Proti dvojitému hashování, případně dalším technikám pro odstranění kolizí, stojí zvýšení výpočetní náročnosti. Pokud by u menšiny klientů docházelo ke kolizím, není to kromě zvýšené nepřesnosti hodnocení klienta, závažný problém. K případnému zablokování by došlo pro všechny klienty, jejichž hash ukazoval na zablokovaný záznam v hashtabulce. Při velikosti hashtabulky vhodně zvolené k předpokládanému množství klientů nepředpokládám problémy.

51 7.3. OBSLUHA POŽADAVKŮ Velikost hashtabulky Velikost hahtabulky musí být únosná pro její uložení v paměti a zároveň dostatečná pro zajištění minimálního množství kolizí. Při testování pro jednotky až desítky klientů používám záznamů. Pro případné ostré nasazení doporučuji nastavení v závislosti na počtu unikátních návštěv. Pro tisíce návštěvníků denně bych volil záznamů. Pro větší návštěvnost proporčně více. Při implementaci budeme postupovat tak, aby byla spotřeba paměti nejvýše jednotky MB na návštěvníků / záznamů v tabulce. Což je desítky MB na záznamů a stovky MB na milion návštěvníků. Věřím, že taková paměťová náročnost nebude dělat při nasazení problémy Globální stav Kromě statistik pro jednotlivé klienty je v paměti udržován stav všech klientů dohromady. Tento stav využíváme pro rychlejší rozhodování o chování konkrétního klienta. Narozdíl od záznamu klienta neobsahuje skore atributy a posloupnosti URL požadavků. Navíc však obsahuje informace o aktuálním stavu serveru a prahu skore, při kterém jsou klienti považováni za roboty. 7.3 Obsluha požadavků V normálním stavu je požadavek od každého klienta vyřízen a vytvoří se pro něj záznam v tabulce klientů. Další požadavky klienta jsou připočítávány do jeho záznamu. Obsluba požadavku probíhá ve dvou fázích a to při přijetí požadavku (pro případné zamítnutí požadavku) a před odesláním odpovědi (pro uložení statistických informací) Při přijetí požadavku Při přijetí požadavku je vyhledáním v hashtabulce zjištěno, jestli je stav klienta, od kterého požadavek pochází, nastaven jako zablokovaný. Pokud ano, je zamítnut. V ostatních případech je požadavek postoupen k vyřízení. Tuto funkčnost zajišťuje část modulu s názvem handler. Princip funkce je na diagramu Před odesláním odpovědi Právě po vytvoření odpovědi na požadavek, ale ještě před jeho odesláním klientovi dochází k aktualizaci statistického hodnocení klienta. Na základě jeho statistik je vypočítáno skore a v případě, že je skore větší, než práh, nastaví se u klienta stav na zablokován. Toto zpracování provádí část modulu s názvem filter. Základní princip je znázorněn na diagramu 7.3.

52 36 KAPITOLA 7. VLASTNÍ ALGORITMUS Obrázek 7.2: Základní princip rozhodnutí o zpracování požadavku 7.4 Počítání skore parametrů Při každém požadavku od klienta dojde k přidání informace o požadavku do jeho záznamu v hashtabulce. Postup výpočtu skore je uveden v následující podkapitole. K případnému zamítnutí může dojít po nejméně n požadavcích. Důvodem je mimo jiné to, že se webová stránka skládá z většího množství prvků, které se ze serveru stahují zvlášť a tak je třeba dát klientovi šanci, aby načetl kompletní stránku, případně více stránek. Skore se v případě skutečného nasazení může počítat pouze u části požadavků (například každý desátý). Důvodem je zejména úspora výkonu, protože se při výpočtu skore přistupuje také ke globálního stavu serveru. Při testování se zpracování provádí při každém požadavku. Skore klienta v hashtabulce je aktuální k jeho poslednímu výpočtu, tedy k jeho poslednímu požadavku. Pokud se od té doby změnil globální stav, klient by znovu dostal jiné skore. Nejde o problém, protože při zaslání nového požadavku by došlo k přepočtu skore z aktuálních hodnot. Jedním z atributů klienta v hashtabulce je informace o jeho stavu. V tomto případě rozeznávám stavy zatím neznámý (0) - při přijetí požadavku je vytvořen záznam v hashtabulce aktivní (1) - při přijetí požadavku je aktualizován záznam v hashtabulce zablokovaný (2) - při přijetí požadavku dojde k jeho zamítnutí a ukončení komunikace

53 7.4. POČÍTÁNÍ SKORE PARAMETRŮ 37 Obrázek 7.3: Základní princip zpracování vyřízeného požadavku Postup výpočtu skore Skore každého parametru je získáno relativním rozdílem hodnoty daného parametru klienta a hodnoty parametru v globálního stavu. Tento relativní rozdíl je reprezentován jednotkami procent. Při rozdílu nezáleží, jestli se liší na jednu nebo druhou stranu, ale čistě na absolutní hodnotě rozdílu parametrů. Postup výpočtu skore se liší podle toho, kterému parametru skore patří. Ukázka výpočtu skore je uvedena na následujícím příkladu. Celkové skore klienta je potom získáno prostým součtem jednotlivých hodnot dílčích skore klienta. global = globální hodnota parametru X atrx = parametr X klienta A skore... skore parametru X klienta A skore = 100 abs(global atrx) global = 100 abs( ) 200 = = Postup výpočtu prahu Práh, při kterém jsou klienti považováni za útočníky, se počítá z průměrného skore všech klientů. Funkce pro výpočet jsem několikrát měnil. Čistě relativní přístup (násobky/podíly) hodnot nepřinesl správné výsledky. V aktuální verzi je práh (threshold) počítán podle následujícího vzorce (avg_score je průměrné skore všech klientů, min_score je nejmenší skore ze všech klientů).

54 38 KAPITOLA 7. VLASTNÍ ALGORITMUS threshold = avg_score Tento vztah byl získán experimentováním s výsledky skore, které dostaly legitimní klienti a útočníci. Předchozí vzorce výpočtu vypadaly následovně (v chronologickém pořadí) threshold = 1000 threshold = 2 * avg_score threshold = avg_score + (avg_score - min_score) threshold = avg_score + (avg_score - min_score) threshold = avg_score 7.5 Naučení vzoru běžného provozu Jak už bylo řečeno, požadavky na jeden konkrétní web mají některé společné rysy. Podíváme se, jakým způsobem tyto parametry získat a využít Ruční nastavení V případě, že chceme chránit jeden konkrétní web, je možné obvyklé chování definovat staticky přímo do filtru. Potřebujeme předtím provést měření a to například spuštěním modulu v režimu monitor a tím zjistit, jaké parametry jsou v konkrétním případě běžné. Výhodou je nemožnost degradace parametrů při chytřejším útoku, protože jsou hodnoty zadány ručně. Nevýhodou může být nedostatečně reprezentativní výsledek ručního měření a také nepřizpůsobení případným změnám webu Průchozí provoz Algoritmus neustále udržuje globální stav, takže je aktuální stav stále k dispozici. Pochybnosti však může vyvolat otázka, jestli je aktuální stav ten obvyklý nebo je ovlivněn útokem a jinými anomáliemi. Jednou možností je brát aktuální vzor vážně až při nějakém minimálním počtu požadavků nebo klientů, které zpracuje. Tento přístup je velmi vhodný pro případy, kdy útok přiliš neočekáváme a je pravděpodobné, že před útokem projde filtrem dostatečné množství požadavků pro jeho správné naučení. Rizikem získávání dat z průchozího provozu je fakt, že i požadavky pocházející od útočníků jsou napřed vyřízeny a až poté případně zablokovány. Takové požadavky jsou tedy také započítány do globálního stavu. Při dostatečné převaze legitimních klientů není globální stav ovlivněn natolik, aby omezil schopnost útočníky rozeznat.

55 7.6. ZAMÍTÁNÍ POŽADAVKŮ Deformace vzoru Při útoku na server, který zatím nemá dostatečné množství dat z běžného provozu, může být vzor deformován natolik, že bude běžné klienty považovat za útočníky. Do tohoto stavu, kterému musíme předejít, se můžeme dostat ze dvou základních situací: útok na nenaučený server méně intenzivní, ale déle trvající útok Útoku na čerstvě spuštěný server bez dostatku legitimních požadavků se musíme vyhnout ručně. V případě klientů, kteří jsou zablokováni až po větším množství vyřízených požadavcích, vyvstává otázka, jestli neprovádět při jejich zablokování nějakou kompenzaci globálního stavu. Při zablokování klienta by se tedy provedly inverzní operace jeho parametrů na globální stav Limitní počty požadavků Při testování jsou použity limity nejméně 5 klientů a zároveň nejméně 37 požadavků. Pro skutečné nasazení jsou vhodné hodnoty o řád výš. Tedy desítky klientů a stovky požadavků. Při nižším množství požadavků není globální stav serveru dostatečně reprezentativní. Při masivním útoku je riziko přetečení proměnných, které používám jako čítače. Více v odstavci s implementací. 7.6 Zamítání požadavků Zamítat požadavky je možné buď přímo v modulu při přijetí požadavku nebo lépe exportovat blokované IP adresy do firewallu, který zablokování vyřeší. Klient může být zablokován podle jeho skore, případně podle globálního stavu serveru Podle globálního stavu Politika nepřijímat neznámé klienty při přetížení může být nasazena při detekovaném útoku. Všchni klienti, kteří zatím nemají záznam v hashtabulce klientů, jsou odmítnuti. Toto je nouzové řešení a v testovacím prostředí není implementováno Podle podezřelého chování - skore Podezřelé chování je reprezentováno právě díky skore každého klienta a globálnímu prahu (threshold). V případě, že je skore klienta vyšší, než je aktuální práh, dojde k jeho zablokování.

56 40 KAPITOLA 7. VLASTNÍ ALGORITMUS 7.7 Implementace Implementaci provádím v jazyce C jako modul serveru nginx Datové struktury Jak bylo zmíněno v odstavci o uchovávání dat, obsahují záznamy zejména počty různých vlastností požadavků. Globální stav obsahuje navíc hodnotu prahu pro zahazování požadavků, která je průběžně aktualizována. Níže je uveden přehled atributů společně s jejich významem. Globální stav serveru threshold - aktuální práh skore, klienti s vyšším skore jsou považováni za útočníky client_count - počet aktivních klientů request_count - počet všech požadavků klientů notmod_count - počet všech požadavků klientů, na které byla odpověď s kódem 304 Not-Modified http1_count - počet všech požadavků klientů s odpovědí HTTP 1xx http2_count - počet všech požadavků klientů s odpovědí HTTP 2xx (OK) http3_count - počet všech požadavků klientů s odpovědí HTTP 3xx http4_count - počet všech požadavků klientů s odpovědí HTTP 4xx (chyba) http5_count - počet všech požadavků klientů s odpovědí HTTP 5xx (chyba serveru) avg_time - průměrný čas všech požadavků klientů html_avg_time - průměrný čas všech požadavků klientů na HTML obsah html_count - počet požadavků klientů na které byl vrácen HTML dokument css_count - počet požadavků klientů na které byl vrácen CSS soubor javascript_count - počet požadavků klientů na které byl vrácen soubor s javascriptem image_count - počet požadavků klientů na které byl vrácen obrázek other_count - počet požadavků klientů na které nebyl vrácen žádný z předchozích typů obsahu Časy jsou ukládány v celočíslených datových typech, ale protože vyjadřují milisekundy a běžný čas vyřízení požadavku je v řádu desítek až stovek ms, nepovažuji zaokrouhlování za závažný problém. Záznamy klientů, které jsou uspořádány v hashtabulce. Proměnné key a ua jsou určeny pro účely ladění a vývoje (key je číslo řádku v hashtabulce a ua je řetězec, ze kterého bylo číslo řádku vypočítáno). Mimo to pro každého klienta obsahují následující atributy. Záznam reprezentujicí klienta

57 7.7. IMPLEMENTACE 41 set - stav klienta (neznámý, aktivní, zablokovaný) request_count - počet všech požadavků klienta notmod_count - počet požadavků klienta, na které byla odpověď s kódem 304 Not- Modified http1_count - počet požadavků klienta s odpovědí HTTP 1xx http2_count - počet požadavků klienta s odpovědí HTTP 2xx (OK) http3_count - počet požadavků klienta s odpovědí HTTP 3xx http4_count - počet požadavků klienta s odpovědí HTTP 4xx (chyba) http5_count - počet požadavků klienta s odpovědí HTTP 5xx (chyba serveru) avg_time - průměrný čas všech požadavků klienta html_avg_time - průměrný čas požadavků klienta na HTML obsah html_count - počet požadavků klienta na které byl vrácen HTML dokument css_count - počet požadavků klienta na které byl vrácen CSS soubor javascript_count - počet požadavků klienta na které byl vrácen soubor s javascriptem image_count - počet požadavků klienta na které byl vrácen obrázek other_count - počet požadavků klienta na které nebyl vrácen žádný z předchozích typů obsahu httpcode_score - skore klienta na základě odlišnosti jeho a globálního rozložení HTTP kódů odpovědí mimetype_score - skore klienta na základě odlišnosti jeho a globálního rozložení typu obsahu odpovědí time_score - skore klienta na základě odlišnosti jeho a globálního časů zpracování požadavků passseq_score - skore klienta na základě jeho posloupnosti URL požadavků (pro skore nepoužito) pass_seq[seqsize] - posloupnost hashů URL požadavků klienta, SEQSIZE je délka posloupnosti ua - klíč podle kterého se vypočítává klientům index v hashtabulce Pořadí URL požadavků (pass_seq) je prozatím pole jednobytových hodnot, pro rozsáhlé weby je vhodné posunout na 2 Bytové hodnoty, tedy místo 256 možností.

58 42 KAPITOLA 7. VLASTNÍ ALGORITMUS Zpracování záznamu klienta Všechny atributy klienta kromě těch končících "_skore"reprezentují příslušný atribut požadavků daného klienta. HTTP skore klienta je vypočítáno z atributů http1_count až http5_count na základě rozdílu od těchto atributů na globální úrovni. Mimetype skore je stejným způsobem počítáno z atributů html_count, css_count, javascript_count, image_count a other_count. Time skore je dáno rozdílem atributů avg_time a html_avg_time příslušného klienta a globálního stavu Zpracování záznamu globálního stavu Globální atributy jsou nastavovány z příslušných atributů všech klientů. Je to tedy součet či průměr všech klientů. Globální stav se udržuje, aby s ním bylo možné srovnávat jednotlivé klienty a v případě, že se budou příliš lišit je zablokovat Velikost v paměti Pro globální stav, který je v paměti jenom jednou, není velikost kritická. Velikost záznamu pro klienta je však poměrně zásadní. Při očekávané velikosti hashtabulky je záznamů bude přidání dalšího parametru znát, proto byly datové typy voleny co nejúsporněji. příznak stavu klienta, znak: char, 1 Byte, všechny čítače požadavků: unsigned int, 4 Byte, Přetékání, zaokrouhlování Přetékání proměnných může mít za následek výrazné zkreslení informace, proto je nutné se mu vyhnout nebo ho vhodně zpracovat. K přetékání datových typů, ve kterých držíme počty požadavků, může po delší době používání docházet. Během testování a vývoje tento problém nenastal. Při dlouhodobějším nasazení bych tuto situaci řešil normalizací hodnot proměnných, tedy jejich nastavení na určitou hodnotu a dopočítání ostatních proměnných, aby byl přibližně zachován jejich poměr. Zaokrouhlování není vzhledem k velikosti hodnot v průběhu výpočtu problém. Například před převodem typu float na int je ve výpočtu použito násobení 100 z důvodu reprezentace procent.

59 Kapitola 8 Měření a testování Měření bylo prováděno ze dvou hlavních důvodů. Prvním bylo vybrání a ověření správnosti volby parametrů, které používám pro rozlišování požadavků. Druhým důvodem, na který se soustředí tato kapitola, je ověření celkové schopnosti rozlišovat požadavky pocházející od legitimních klientů a útočníků. 8.1 Testovací prostředí Testy musí být prováděny v definovaném prostředí, aby byla zajištěna relevance výsledků. Naměřená data použitá v těchto měřeních jsou výtahem z tabulky vnitřního stavu filtrovacího modulu. Ukázka dat je uvedena v kapitole 4.5, kompletní data jsou, vzhledem k jejich rozsáhlosti, na přiloženém CD Legitimní klient Za legitimního klienta považujeme takového klienta, který k prohlížení webu používá běžný prohlížeč (Firefox, Google Chrome,...) ve výchozím nastavení. Prozatím nebylo řečeno nic o tom, kdo bude prohlížeč ovládat. Pro účely testování je možné kromě ručního ovládání použít nástroj Selenium/webdriver2, který umí simulovat chování uživatele v internetovém prohlížeči Útočník Za útočníka považujeme nástroj, který posílá požadavky na server, ale nezobrazuje je uživateli. Útočník může být simulován jedním z následujících nástrojů ab (Apache Benchmark) LOIC HOIC Pro navození distribuovaného útoku bude použito více instancí (které budou identifikovány jako různí klienti) nástroje simulujícího útok. 43

60 44 KAPITOLA 8. MĚŘENÍ A TESTOVÁNÍ Server Požadavky od klientů bude přijímat server nginx a to v režimu, kdy nginx tvoří reverzní proxy server pro Apache HTTPD. Server nginx používám ve verzi , která vyšla 6. února Apache HTTPD je ze řady 2.2. Na serveru jsou vždy provozovány pouze jedny webové stránky. Vytvořený modul v této testovací verzi uchovává všechny požadavky a klienty pohromadě. 8.2 Měření při sběru dat Měřeno v březnu 2012 na vzorku 112 klientů vzorových webových stránek s cílem získat informace o tom, jaký obsah klienti stahují a jestli zvolené parametry nabývají očekávaných hodnot. Na tabulce 8.1 jsou uvedeny četnosti jednotlivých druhů obsahu. Nejčastější cíl požadavků byly HTML stránky. Následovaly je obrázky, kterých vzorové webové stránky obsahují více než HTML stránek, ale internetové prohlížeče si je uchovávají v paměti, takže je typicky opakovaně nestahují. Další obsah je zastoupen méně. Počet požadavků HTML CSS Javascript Images Other Tabulka 8.1: Statistiky content type požadavků získané při sběru dat Protože bylo v přehledu parametrů uvedeno, že HTTP stav 304 Not-Modified znamená, že má klient lokální mezipaměť a tedy se jedná nejspíše o skutečný prohlížeč, sledoval jsem poměr odpovědí HTTP 304 k celkovému počtu všech odpovědí. Vsýledek je uveden v tabulce 8.2. Poměrně nízké číslo 270 takových požadavků je způsobeno tím, že klienti často navštívili pouze úvodní stránku a lokální cache tedy nemusel využít. Počet požadavků Počet 304 Not-modified Tabulka 8.2: Statistiky not-modified požadavků získané při sběru dat Čas, který zabere serveru načtení obsahu předtím, než jej pošle klientovi v odpovědi, by se měl lišit pro statický obsah, který je pouze přečten z disku a pro dynamický obsah, který musí být načten z databáze a typicky interpretován jazykem jako PHP. Rozdíl je dobře vidět na tabulce 8.3. Čas statického obsahu [ms] Čas dynamického obsahu [ms] Tabulka 8.3: Statistiky průměrných časů zpracování požadavků

61 8.3. MĚŘENÍ SCHOPNOSTI ROZLIŠOVAT POŽADAVKY (LABORATORNÍ) Shrnutí měření při sběru dat Vybrané parametry nabývaly očekávaných hodnot a ukázaly se jako použitelné pro provádění hodnocení klientů. 8.3 Měření schopnosti rozlišovat požadavky (laboratorní) Rozlišování požadavků patřících legitimním klientům nebo útočníkům je hlavním cílem této práce. Funkční modul serveru nginx implementující vytvořený algoritmus byl postaven jako součást reverzní proxy a zpracovával všechny průchozí požadavky. Cílem těchto měření je ověření, zda funguje rozlišování požadavků a nalezení případných problémů. V následujících měřeních je velikost prahu vždy uvedena pro klienta, který poslal poslední požadavek. Po větším množství zpracovaných požadavků by se hodnota prahu příliš neměnila, tak můžeme poslední hodnotu skore považovat za tu nejpřesnější. V tabulkách a grafech se také vyskytuje klient s nulovým skore. To znamená, že se jedná o prvního klienta, který nemohl být srovnáván s průměrem ostatních. V případě, že by poslal požadavek i v době, kdy už hashtabulka obsahovala i jiné klienty, došlo by k přepočítání jeho skore Při použití nástroje LOIC Skore klientů je znázorněno na grafu 8.1. Jedná se o nejjednodušší situaci, kdy máme několik klientů a jednoho útočníka. Jako útočník byl použit nástroj LOIC (HTTP požadavky s čekáním na odpověď). Klient Skore celkem [-] Skore HTTP kód [-] Skore typ obsahu [-] Skore čas [-] Klient Klient Klient Klient Klient Tabulka 8.4: Statistiky skore klientů při měření s nástrojem LOIC Z grafu je na první pohled vidět podezřelý Klient 3, skutečně se jedná o útočníka. Z tabulky 8.4 vyplývá, že Klient 3 dostal nejvíce bodů za druh obsahu stahovaných souborů, kdy se od legitimních klientů lišil tím, že nestahoval objekty, které webová stránka obsahuje (obrázky apod.), ale pouze samotné stránky. Stahování samotných stránek se také projevilo na času zpracování požadavků, které se projevilo na přidělení vyššího skore za čas. Práh pro rozlišení legitimního klienta a útočníka byl v tomto případě 390 bodů. Útočník byl tedy spolehlivě rozpoznán.

62 46 KAPITOLA 8. MĚŘENÍ A TESTOVÁNÍ Obrázek 8.1: Graf počtu bodů klientů včetně jedné instance nástroje LOIC (Klient 3), práh Při použití nástroje HOIC Stav je znázorněn na grafu 8.2. Legitimních klientů je v tomto případě pouze 5, zbývajících 6 jsou útočníci. Klienti 3, 4, 8 a 9 jsou jako legitimní vyhodnoceni správně. Klient číslo dva je sice těsně pod prahem a je tedy také vyhodnocen správně. Nicméně je třeba zabývat se důvodem, proč dostal tak vysoké skore. Po rozboru detailů se ukázalo, že na rozdíl od ostatních legitimních klientů má Klient 2 cachované objekty, které webová stránka obsahuje. Nestahuje je znovu a má tedy vyšší skore za typ obsahu, který ze serveru stahuje. Hodnota prahu byla 960 bodů. Rozlišení bylo méně výrazné, než v případě s LOIC, ale vzhledem k mírné přesile útočníků nad legitimními klienty, stále dobře fungující Chyby rozlišení z důvodu lokální cache prohlížeče V předchozím měřením jsme narazili na zajímavý problém s vysokým skore, provedl jsem tedy další měření k objasnění problému. Stav bodů je znázorněn na grafu 8.3, všichni klienti jsou v tomto případě legitimní, tedy otevřené internetové prohlížeče. Prohlížeč Google Chrome (verze 18) při načtení stránky nestahuje narozdíl od ostatních klientů všechny objekty, které webové stránky obsahují, protože je má uloženy v lokální cache z některé z předchozích návštěv. Při měření bylo také zjištěno, že uvedená prohlížeč validnost objektů uložených v lokální cache, na serveru neověřuje při každém načtení stránky, ale pouze méně často. Tímto se liší od ostatních klientů a tedy i jeho zvýšené skore za typ stahovaného obsahu zvyšuje jeho celkové skore.

63 8.3. MĚŘENÍ SCHOPNOSTI ROZLIŠOVAT POŽADAVKY (LABORATORNÍ) 47 Obrázek 8.2: Graf počtu bodů klientů při použití nástroje HOIC, práh 960 Při delším provozu by všichni klienti museli všechen obsah stáhnout znovu (z důvodu první návštěny nebo vypršení platnosti uloženého obsahu), takže by problémy tohoto typu neměly nastat. Obrázek 8.3: Graf počtu bodů legitimních klientů při rozdílném cachování prohlížečů Shrnutí měření rozlišování požadavků Pro tuto práci pracuje rozlišování požadavků na velmi dobré úrovni. Princip, jakým jsou požadavky rozlišovány, tím považuji za správný.

64 48 KAPITOLA 8. MĚŘENÍ A TESTOVÁNÍ Klient Skore celkem [-] Skore HTTP kód [-] Skore typ obsahu [-] Skore čas [-] Klient Klient Klient Klient Klient Klient Klient Klient Klient Klient Klient Tabulka 8.5: Statistiky skore klientů při měření s nástrojem HOIC Klient Skore celkem [-] Skore HTTP kód [-] Skore typ obsahu [-] Skore čas [-] Klient Klient Klient Klient Klient Tabulka 8.6: Statistiky skore klientů při měření k problému s lokální cache Před případným ostrým nasazením by bylo vhodné kombinovat toto filtrování nějakou další metodou pro vyloučení chybných rozhodnutí. 8.4 Měření schopnosti rozlišovat požadavky (ostré) Pro konečné ověření schnopnosti rozlišování požadavků od robotů a legitimních klientů bylo provedeno měření na skutečném provozu vzorových webových stránek glyphicons.com. Z důvodu většího počtu klientů se v tomto měření již nezaměřuji na jednotlivé klienty, ale pouze na jejich počty Rozsah naměřených dat Bylo nutné zajistit dostatečné množství dat pro vyhodnocení funkce rozlišování požadavků. Pro ověření správnosti je nutná ruční kontrola vyhodnocení každého klienta, takže půjde nejvýše o stovky klientů. Klienti jsou v tomto případě identifikování již pouze na základě IP adresy. Počet rozlišených klientů je v tabulce 8.7 uveden z důvodu, že značná část klientů poslala za dobu měření na server pouze méně, než 5 požadavků a modul zajišťující rozlišení je z

65 8.4. MĚŘENÍ SCHOPNOSTI ROZLIŠOVAT POŽADAVKY (OSTRÉ) 49 důvodu omezení nepřesností zatím nezpracoval. Při bližším pohledu bylo zjištěno, že jde o čtečky novinek na webových stránkách a podobně. Pro rozbor rozlišování mám tedy k dispozici 117 klientů. Počet klientů Počet rozlišených klientů Celkový počet požadavků Tabulka 8.7: Množství dat získané při ostrém měření Vyhodnocení naměřených dat Ze 117 klientů bylo jako legitimní klienti rozlišeno 100 klientů a zbývajicích 17 bylo rozlišeno jako roboti. Po bližším prověření jsem mohl sestavit tabulku 8.8, ve které jsou vyčísleny chyby, které při rozlišování vznikly. Ověřování jsem u každého klienta prováděl osobní úvahou z dat získaných v záznamu klienta v hashtabulce, případně z logu. Vlastní chybu sice nemohu vyloučit, ale pro porovnání budu své rozlišení považovat za správné. Rozlišení robota (ze 117 klientů) False positive: 2 True positive: 15 False negative: 6 True negative: 94 Tabulka 8.8: Vyhodnocení označení klienta jako robota Procentní vyhodnocení rozlišení robota False positive: 1, 7% True positive: 12, 8% False negative: 5, 1% True negative: 80, 3% Tabulka 8.9: Vyhodnocení označení klienta jako robota v procentech Shrnutí a porovnání s laboratorním měření Při ostrém měření mě překvapilo množství klientů, kteří na server během několika hodin pošlou pouze jeden požadavek. Po zjištění, že se jedná o čtečky novinek a podobné nástroje bylo množství těchto klientů objasněno. Rozlišovací algoritmus naštěstí z důvodu omezení nepřesností provádí hodnocení klienta až od 5. požadavku, který klient pošle, a tak jsem tyto klienty mohl v měření ignorovat. Toto měření se od předchozích měření lišilo v tom, že probíhalo za skutečného provozu se skutečnými klienty. V tomto měření také neprobíhal na server žádný (D)DOS útok. Klienti, kteří byli označení za roboty byli většinou vyhledávací roboti, případně roboti provádějicí jiný typ útoků. V případě (D)DOS útoku by rozlišení dosahovalo přinejmenším stejné přesnosti.

66 50 KAPITOLA 8. MĚŘENÍ A TESTOVÁNÍ Obrázek 8.4: Graf s chybami v rozlišení klientů jako robotů S výslednou chybou rozlišení znázorněnou na grafu 8.5 jsem poměrně spokojený, nicméně pro skutečné ostré použití je třeba dosáhnout ještě vyšší přesnosti, případně spouštět blokování klientů až při probíhajícím útoku, kdy je zablokování legitimního klienta menší problém, než při normálním provozu.

67 8.4. MĚŘENÍ SCHOPNOSTI ROZLIŠOVAT POŽADAVKY (OSTRÉ) 51 Obrázek 8.5: Graf poměru správně a špatně vyhodnocených klientů