VYSOK ´ EU ˇ CEN ´ I TECHNICK ´ E V BRN ˇ E BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMA ˇ CN ´ ICH TECHNOLOGI ´ I ´ USTAV INFORMA ˇ CN ´ ICH SYST ´ EM ˚ U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS DETEKCE A IZOLACE ´ UTO ˇ CN ´ IK ˚ U POMOC ´ I Z ´ AZNAM ˚ U NETFLOW DETECTION AND ISOLATION OF ATTACKERS USING NETFLOW DATA DIPLOMOV ´ A PR ´ ACE MASTER’S THESIS AUTOR PR ´ ACE MAT ˇ EJ GR ´ EGR AUTHOR VEDOUC ´ I PR ´ ACE Ing. PETR MATOU ˇ SEK, Ph.D. SUPERVISOR BRNO 2009
Transcript
VYSOKE UCENI TECHNICKE V BRNEBRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMACNICH TECHNOLOGIIUSTAV INFORMACNICH SYSTEMU
FACULTY OF INFORMATION TECHNOLOGYDEPARTMENT OF INFORMATION SYSTEMS
DETEKCE A IZOLACE UTOCNIKU POMOCIZAZNAMU NETFLOWDETECTION AND ISOLATION OF ATTACKERS USING NETFLOW DATA
DIPLOMOVA PRACEMASTER’S THESIS
AUTOR PRACE MATEJ GREGRAUTHOR
VEDOUCI PRACE Ing. PETR MATOUSEK, Ph.D.SUPERVISOR
BRNO 2009
Zadanı prace
1. Seznamte se s protokolem NetFlow a nastroji pro analyzu dat zıskanych ze sondyNetFlow.
2. Seznamte se s penetracnımi nastroji pro zjist’ovanı informacı o sıti a sıt’ovych zarızenı(nessus, nmap, apod.).
3. Simulujte utok na sıt’ v laboratornıch podmınkach. Analyzujte zaznamy NetFlows cılem detekce a izolace utocnık.
4. Navrhnete a implementujte system pro automatickou detekci a izolaci utocnıka.
5. Demonstrujte pouzitelnost systemu na realnem sıt’ovem provozu (podle doporucenıvedoucıho).
Licencnı smlouvaLicencnı smlouva je ulozena v archıvu Fakulty informacnıch technologiı Vysokeho ucenıtechnickeho v Brne.
AbstraktDiplomova prace se zabyva pouzitım zaznamu NetFlow pro detekci skenovanı sıte. Jakozdroj dat jsou pouzita anonymizovana data NetFlow z paternı sıte VUT. Z techto dat jsouvytvoreny statistiky, na jejichz zaklade je navrhnuta sada skriptu. Pomocı techto skriptu jemozne detekovat skenovanı i ve velkych akademickych sıtıch.
AbstractThis thesis deals with using NetFlow records for detection network scanning. AnonymizedNetFlow records from backbone VUT network are used as the source. Based on statisticscreated from these records, several Bash and Python scripts are implemented. With thesescripts it is possible to detect network scanning even in large academics networks.
PodekovanıDekuji Ing. Petrovi Matouskovi, Ph.D. za vedenı diplomove prace a cenne pripomınky aIng. Tomasi Podermanskimu za zprıstupnenı zaznamu NetFlow a poskytnute konzultace kdosazenym vysledkum.
Pocıtacove sıte celı v dnesnı dobe stale vetsımu mnozstvı bezpecnostnıch hrozeb a za-bezpecit je proti temto hrozbam prinası celou radu problemu. Samotny firewall jiz nakvalitnı zabezpecenı prestava stacit a proto byva kombinovan s dalsı technologiı. Jednouz moznostı jak zvysit bezpecnost pocıtacove sıte, by mohlo byt vyuzitı zaznamu NetFlow,ktere jsou generovany sondami nebo smerovaci s podporou teto technologie. Aby mohlutocnık naplanovat utok na pocıtacovou sıt’, potrebuje znat o dane sıti co nejvıce informacı.Pokud se pri zajist’ovanı bezpecnosti pocıtacove sıte zamerıme take na tuto pocatacnı faziutoku, muzeme dıky vcasne detekci utoku minimalizovat vznikle skody, prıpadne utok zcelaodvratit.
1.1 Cıl diplomove prace
Hlavnım cılem diplomove prace bude analyzovat, zda lze pomocı zaznamu NetFlow uspesnedetekovat pocatecnı fazi utoku - skenovanı sıte. Pokud by se tyto typy utoku daly dete-kovat, byl by to prınos pro bezpecnost sıte. Reakcı na detekovany utok by mohla bytblokace utocnıka, omezenı utocnıka nebo zaslanı informace spravci sıte. Tato diplomovaprace navazuje na semestralnı projekt, ve kterem byly popsany principy a fungovanı proto-kolu NetFlow, jaka zarızenı slouzı ke generovanı zaznamu NetFlow a jake nastroje muzemepouzıt k analyze techto zaznamu. Byly take popsany techniky skenovanı sıte a dostupnenastroje, ktere se ke skenovanı pouzıvajı. Jednotlive skenovacı nastroje byly otestovanyv laboratornıch podmınkach.
V diplomove praci se dale budu zabyvat daty NetFlow zıskanymi z realneho provozuvelke sıte. Z techto dat bude vytvorena statistika, ktera pomuze urcit, ktere udaje jsou z hle-diska detekce skenovanı dulezite. Dale bude implementovana aplikace, ktera bude schopnatato skenovanı detekovat a zaznamenat. Dosazene vysledky by mely byt konzultovany sespravcem sıte, aby se aplikace dala pouzıt prakticky a zıskane vysledky umoznily zvetsitzabezpecenı sıte.
1.2 Clenenı prace
Kapitola 2 popisuje soucasne pouzıvane techniky pro detekci sıt’ovych utoku. V kapitole3 se zabyvam technikami skenovanı zarızenı na sıti a skenovacımi nastroji (at’ uz hard-warovymi nebo softwarovymi). Kapitola 4 popisuje protokol NetFlow, princip fungovanıprotokolu a volne dostupne nastroje urcene pro praci s tımto protokolem. Pouzitı skeno-
3
vacıch nastroju a testovanı skenovacıch technik pri skenovanı v laboratori jsou popsanyv kapitole 5. Kapitola 6 popisuje problematiku analyzy zaznamu NetFlow ve velkych sıtıch.Je zde take popsano, odkud byla zıskana data NetFlow, pouzita v teto praci a jaka tatodata majı omezenı. V kapitole 7 je popsano, jak byly vytvoreny z dat NetFlow statistiky,ktere jsou pouzity pro zjistenı, ktere informace jsou dulezite z hlediska detekce skenovanı.V kapitole 8 jsou tato data analyzovana a je vytvoren navrh aplikace, ktera bude schopnadetekovat skenovanı. Kapitola 9 popisuje konkretnı implementaci pro sıt’ VUT. V kapitole10 jsou shrnuty dosazene vysledky a diskutovana mozna rozsırenı. Soucastı diplomove pracejsou take prılohy. Seznam viz 11.
4
Kapitola 2
Utoky a jejich analyza
Utok na sıt’ vzdy zacına zkoumanım sıte (network reconnaissance), kdy se utocnık pokousıo neautorizovane zmapovanı sıte, sluzeb nebo zranitelnostı. Cılem teto faze je zıskat dostatekinformacı k provedenı dalsıch typu utoku se zamerenım na zıskanı prıstupu nebo odmıtnutıprıstupu legitimnım uzivatelum. Pokud by byla pocatecnı faze (tedy zkoumanı) neuspesna,dalsı utok by byl pro utocnıka daleko obtızneji realizovatelny. Pri mapovanı sıte se pouzıvajıprevazne nasledujıcı techniky:
• Skenovanı IP adres: Zjist’ovanı aktivnıch IP adres v podsıti ci organizaci. Realizovaneprevazne pomocı protokolu ICMP a zprav Echo request, Echo reply (ping).
• Skenovanı portu: U aktivnıch IP adres moznost zjistit, jake sluzby dane sıt’ove zarızenıpodporuje. Vıce v kapitole 3
• Naslouchanı: Odposlouchavanı datoveho provozu na sıti. Ztezujı to prepınane sıte, alepokud se bude analyzovat provoz na hranicnıch bodech, lze zıskat mnozstvı informacı.
• Informacnı dotazy na aplikacnı vrstve: Vyuzitı dotazu DNS, databaze whois, zjistenırozsahu IP adres organizace
Pro detekci techto a dalsıch typu utoku se dnes ve vetsıch sıtıch pouzıvajı Network In-trusion Detection System (NIDS) a Network Intrusion Prevention System (NIPS). SystemNIDS utoky detekuje a rozpoznava. Utokum se nesnazı aktivne branit - jedna se o pasivnıobranny system. NIPS se snazı utokum aktivne zabranit. System NIDS/NIPS tvorı sen-zory na vstupnıch bodech sıte, ktere analyzujı sıt’ovy provoz a snazı se detekovat utoky.Zıskana data posılajı centralnı stanici, ktera je zpracovava. Resenı muze byt ciste softwa-rove, napr. program snort, nebo specializovane zarızenı, napr. Cisco Guard. Pri reakci nautok je spusten alarm. To je obecny nazev pro akci, kterou system upozornuje na deteko-vanou aktivitu. Zalezı na systemu, jak je tato akce realizovana. Muze se jednat naprıklado poslanı e-mailu spravci nebo zaznamenanı udalosti do logovacıho souboru. Zadny systemNIDS/NIPS ale nenı natolik presny, aby generoval pouze korektnı alarmy. Cılem je mini-malizovat falesne pozitivnı a negativnı alarmy.
– falesne negativnı alarmy - nevygenerovan alarm pri znamem utoku
5
• Prave alarmy - spravne vyhodnocenı situace
– prave pozitivnı alarmy - vygenerovan alarm pri utoku
– prave negativnı alarmy - pri normlnı aktivite nenı generovan zadny alarm
Pro analyzu datoveho toku a detekci utoku se pouzıva nekolik typu analyz [19].
• Analyza vzoru - Cılem je najıt vzor, ktery je pro utok specificky. Z techto vzoru jsoupak vytvoreny databaze, ktere se vyuzıvajı pro detekci (muze byt dodana naprıkladvyrobcem spolu se systemem IDS). Posloupnost paketu, ktere majı nastaven pouzeprıznak SYN, muze byt naprıklad vzor utoku pro skenovanı. Kazdy novy utok musıbyt analyzovan a ulozen jako novy vzor. Podle poctu paketu potrebnych k detekciutoku muzeme klasifikovat vzory atomicke - stacı jeden paket, nebo slozene - jetreba vıce paketu. System IDS vyuzıvajıcı tento typ analyzy muze generovat zvysenemnozstvı jak falesnych negativnıch alarmu (napr. pri male zmene znameho utoku)tak falesnych pozitivnıch (vzor je prılis neurcity).
• Statisticka analyza - Nekdy oznacovana take jako detekce anomaliı. System pracujıcıs touto analyzou se naucı normalnı provoz v dane sıti, tzv. profil. Pokud nasledneprofil sıte presahne zvolenou odchylku, je generovan alarm. Vyhodou tohoto systemuje i moznost detekce novych utoku a pokud je vytvoren kvalitnı profil, tak i snızenıfalesnych pozitivnıch alarmu. Uzivatele sve chovanı mohou ale menit, coz negativneovlivnuje pocet falesne pozitivnıch alarmu (je nutne aktualizovat profily pri zmenesıte).
• Kontrola obsahu protokolu - Aplikacnı protokoly jako FTP, HTTP, SMTP a jine mo-hou byt analyzovany na zaklade obsahu jednotlivych paketu. Tato detekce a analyzase tyka spıse systemu IPS, ktere mohou blokovat vybrane prıkazy, slouzit jako proxyservery a podobne. Jedna se o aktivnı obranu.
Pokud je nejaky utok detekovan, zavisı na pouzitem systemu, jaka bude dalsı reakce.Pokud se jedna o system NIDS, utok je zpravidla zaznamenan do souboru se zaznamy (logu)a system upozornı spravce, ktery provede bezpecnostnı opatrenı. System NIPS zpravidlareaguje ihned a utoku se snazı aktivne zabranit. Nasleduje faze prevence, kdy se snazıupravit odolnost systemu, aby zabranil dalsım podobnym utokum. Mozne reakce a prevence:
• Reset spojenı TCP - u spojenı TCP je zaslan paket s prıznakem RST obema ucastnıkum.U spojenı UDP se generuje paket ICMP se zpravou Port Unreachable.
• Blokace spojenı - sıt’ove spojenı je ihned zruseno a zdrojova IP adresa je zablokovana.
• Odebıranı pridelenych prostredku - v prıpade vycerpanı zdroju se menı napr. max.pocet castecne otevrenych spojenı, max. doba necinnosti spojenı (idle timeout), max. pocetsoucasne otevrenych spojenı, delka cekanı na ukoncovacı paket (prıznak FIN) a jine.
• Vyuzitı proxy - u protokolu HTTP i jinych aplikacnıch protokolu, u spojenı TCP semuze vyuzıt tzv. SYN cookies.
6
Kapitola 3
Skenovacı techniky a nastroje
Skenovanı sıte byva rozdeleno vetsinou na tri typy, podle zpusobu, jakym skenuje porty (vizobrazek 3.1). Pri horizontalnım skenovanı utocnık skenuje jeden port na vıce pocıtacıch.U vertikalnıho skenovanı skenuje vıce portu na jednom pocıtaci a blokove skenovanı jekombinacı obou.
blokové skenování
vertikální skenování
horizontální skenování
IP
porty
1.1.1.1 1.1.1.255 1.1.2.1~ ~ ~
1
22
23
21
1023
~
~
~
Obrazek 3.1: Typy skenovanı
Skenovanı je realizovano u protokolu TCP a UDP skenovanım portu [8]. Porty mohoubyt v nasledujıcıch stavech:
• open, accepted: Pokud je port open (otevreny), znamena to, ze na nem bezı sıt’ovasluzba a je mozno s nım navazat spojenı.
• closed, denied: closed port znacı uzavreny port. Na pokus o pripojenı k takovemuportu je u TCP portu poslan zpet paket s nastavenymi prıznaky RST a ACK,v prıpade portu UDP je poslan ICMP paket typu 3, kod 3 (port unreachable).
• filtered, blocked: Pri pokusu o kontaktovanı tohoto portu nebyla zjistena odpoved’(kladna ani zaporna)
Dalsı zjist’ovanı informacı o tom, co na danem portu bezı za sluzbu, prıpadne jaky OSdany pocıtac pouzıva, je uz prevazne zalezitost analyzovanı odpovedı ze skenovanı portu.
7
3.1 Skenovacı techniky
3.1.1 TCP
U skenovanı TCP portu muzeme vyuzıt vıce technik. Vetsina vyuzıva ruznych nastavenychprıznaku v TCP paketu a toho, ze u protokolu TCP se navazuje a ustanovuje spojenı. Prinavazovanı spojenı jde o tzv. trıfazovou synchronizaci (three-way handshake). Pokud portodpovı tak jak ma (prıznaky SYN/ACK), je ve stavu open. Pri odpovedi RST je ve stavuclosed a pri zadne odpovedi ve stavu filtered/blocked.
Skenovanı SYN
Skenovanı SYN nikdy nedokoncı TCP spojenı. Pro zjistenı toho, zda je port otevren, mustacı poslat pouze paket s prıznakem SYN a cekat na odpoved’. Pokud prijde SYN/ACK,utocnık vı, ze port je otevreny. Podle trıfazove synchronizace by mel poslat paket s prıznakemACK, ale ten neposle a kompletnı spojenı tedy nenavaze. Tento typ skenovanı se vyuzıvapro svou rychlost a proto, ze je vetsı pravdepodobnost, ze nekompletnı navazanı spojenınebude logovano.
Skenovanı connect
Skenovanı connect je vlastne klasicke kompletnı navazanı spojenı. Pokud je port ve stavuopen, probehnou vsechny tri kroky synchronizace TCP. Tato skenovacı technika nenı prılisvyuzıvana, protoze poskytuje stejne informace jako SYN scan, ale je pomalejsı a kompletnıspojenı byvajı logovana.
Skenovanı Null, FIN a Xmas
Tyto zpusoby skenovanı vyuzıvajı znenı TCP RFC 793 [15], kde je receno, ze pokud jeport ve stavu closed, na kazda prıchozı data, ktera neobsahujı prıznak RST, ma odpovedetpaketem s prıznakem RST. Pokud je port ve stavu open, ma na jakekoliv pakety, kde nejsounastaveny ani jedny z prıznaku SYN, RST, ACK, zareagovat zahozenım paketu.
• Skenovanı Null posıla pakety bez nastavenı jakehokoliv prıznaku.
• Skenovanı FIN nastavuje u paketu pouze prıznak FIN.
• Skenovanı Xmas nastavuje prıznaky FIN, URG a PSH.
Skenovanı Ack
Tento zpusob skenovanı ma za ucel zjistit pouze to, zda je port filtrovan nebo ne. Pokudje port nefiltrovan, tak open i closed port by na paket s prıznakem ACK mel odpovedetpaketem s prıznakem RST. Pokud je port filtrovan, tak neodpovı.
3.1.2 UDP
U protokolu UDP se vyuzıva pouze jedineho skenovanı. Pro oskenovanı UDP portu se posılapaket UDP pouze s hlavickou, ktery neobsahuje zadna data. Pokud se vratı jako odpoved’paket ICMP typu 3, kodu 3, je port oznacen jako closed. Pokud se vratı paket ICMP jinehokodu (1,2,9,10,13), muzeme port oznacit jako filtered. Pri otevrenem portu jako odpoved’prijdou nejaka data z dotazovaneho UDP portu.
8
3.2 Skenovacı nastroje
Vetsinu vyse zminovanych technik skenovanı lze vyzkouset pomocı skenovacıho nastroje.Krome skenovanı connect, ktere je v podstate stejne, jako pripojenı se na dany port telne-tem, vyuzıvajı ostatnı techniky upravene prıznaky v hlavickach TCP paketu, ktere vyzadujıexternı knihovny a administratorska opravnenı. Nejznamejsı a nejpouzıvanejsı skener portua sıte obecne je nastroj Network Mapper, zkracene nmap.
Nmap [14]
Nmap (”Network Mapper”) je bezpecnostnı a sıt’ovy skener. Dokaze odhalovat pocıtacev sıti a sluzby, ktere na nich bezı. Z pokrocilejsıch nastavenı lze pouzıt detekci operacnıhosystemu, jake filtry a firewally jsou pouzity a jake verze sluzeb bezı na danem pocıtaci apod.Je sıren pod licencı GNU GPL. Pokud ponechame zakladnı nastavenı, tak zakladnı prıkaz#nmap ip.skenovaneho.pocıtace zadany na prıkazove radce otestuje, zda je pocıtac ak-tivnı a pokud ano, testuje priblizne 1000 nejpouzıvanejsıch portu. Nmap ma obrovskemnozstvı nastavenı a ruznych zpusobu jak zjistit, jake sluzby pocıtac poskytuje. Vıce in-formacı lze zıskat v manualove strance nebo na strance projektu.
Nessus [1]
Nessus je program pro kompletnı bezpecnostnı analyzu. Sklada se z demona nessusd, kteryse stara o samotne skenovanı a klienta nessus, ktery nastavuje ruzne parametry skenovanı,spoustı skenovanı a zobrazuje vysledky uzivateli. Pro samotne skenovanı pouzıva zasuvnemoduly, napsane ve vlastnım skriptovacım jazyce NASL1. Techto modulu existuje velkemnozstvı (pres 20 000) a stale se aktualizujı, podle aktualnıch bezpecnostnıch zranitelnostı.Pri testovanı zranitelnosti pouzıva Nessus na zacatku skenovanı portu daneho pocıtace. Mavlastnı skener, ale dokaze pouzıt take externı, jako napr. nmap. U zjistenych otevrenychportu zkousı vyuzıt znamych bezpecnostnıch chyb sluzeb, ktere na danem portu naslouchajı.Testuje take konfiguraci a chybejıcı bezpecnostnı zaplaty, zda se nepouzıvajı standardnıa nevyplnena hesla a dalsı. Do roku 2005 to byl projekt s otevrenym zdrojovym kodem,pak byl uzavren. Pro nekomercnı vyuzitı je stale k dispozici zdarma (je nutna registrace),ale aktualizovane moduly jsou nabızeny se sedmidennım zpozdenım.
EtherScopeTMSeries II [2]
Sıt’ muzeme skenovat i pomocı hardwarovych zarızenı. Jednım z analyzatoru, je prıstrojEtherScopeTMSeries II od firmy Fluke networks. Tento prıstroj dokaze analyzovat sıt’, doktere je pripojen. Zvlada otestovat kabelaz, analyzovat provoz v sıti, identifikovat VLANsıte, odhalit aktivnı zarızenı v sıti. Je schopen zobrazit statistiky a grafy protokolu, ktere sena sıti pouzıvajı, detekovat uzka mısta v sıti (bottleneck) a mnoho dalsıho. Zarızenı pouzıvajako operacnı system Linux a pro zobrazenı vysledku platformu Qtopia od firmy Trolltech.Podrobnejsı popis je k dispozici v dokumentaci u vyrobce.
1Nessus Attack Scripting Language
9
Kapitola 4
NetFlow
Tato kapitola popisuje protokol NetFlow. Je zde popsan princip fungovanı protokolu, nastroje,ktere se pri praci s tımto protokolem pouzıvajı, a sonda NetFlow, coz je hardwarove zarızenıvyuzıvajıcı NetFlow protokol. Pomocı tohoto protokolu lze ukladat zaznam o provozu v sıti.Tato data budou v praci dale analyzovana a pokusım se zjistit, zda lze z techto dat odhalitskenovanı sıte.
4.1 Protokol NetFlow
4.1.1 Zakladnı popis
Protokol NetFlow je protokol pro prenos zaznamu o tocıch, ktery vyvinula spolecnost Cisco.NetFlow je take chapan i jako cely proces merenı toku. Jako dalsı protokoly teto spolecnostije uzavreny, ale je k dispozici jeho specifikace v RFC 3954 [5](poslednı verze 9). Dıkydostupnosti specifikace je protokol implementovan a podporovan take na jinych platformachnez Cisco IOS napr. smerovace Juniper nebo distribuce FreeBSD, OpenBSD a GNU/Linux.Vzniklo nekolik verzı tohoto protokolu. Nejpouzıvanejsı je v dnesnı dobe verze 5 a rozsirujese take poslednı verze 9. Poslednı verze protokolu NetFlow je take zakladem protokoluIPFIX1, vytvoreny IETF, ktery pravdepodobne bude v blızke dobe schvalen jako standard.Protokol definuje nekolik pojmu, se kterymi je nutne se seznamit.
• IP tok (IP Flow): Casto se pouzıva pouze nazev tok. Tok je posloupnost paketuprochazejıcı monitorovanym rozhranım za urcity casovy interval. Tyto pakety se sho-dujı ve zdrojove a cılove IP adrese, zdrojovem a cılovem portu UDP nebo TCP,protokolu, rozhranı a stejne nastavenym bajtem Type of Service [6].
• NetFlow zaznam (Flow Record, NetFlow data): Podrobnejsı informace k danemuIP toku. Jsou zde informace o delce toku, poctu prenesenych bajtu, paketu a dalsıch.
• Exporter (Exporter): Zarızenı (napr. smerovac), ktere monitoruje prochazejıcı pa-kety a vytvarı z nich IP toky. Informace z techto toku jsou ve forme zaznamu NetFlowodesılany do kolektoru.
• Exportovany paket (Export Packet): Paket vytvareny exporterem, ktery obsahujezaznamy NetFlow. Je odesılan exporterem do kolektoru.
1Internet Protocol Flow Information Export
10
• NetFlow kolektor (NetFlow collector): Kolektor, ktery prijıma a zpracovava paketyz jednoho nebo vıce exporteru. Tyto pakety jsou pak ukladany na disk.
Schema fungovanı protokolu lze videt na obrazku 4.1. Zde jsou na pozici exporterusmerovace Cisco. Ty vytvarejı toky, ktere jsou dedikovanou linkou posılany do kolektoru.Nasledne mohou byt tato data zobrazena napr. pomocı nastroju nfdump 4.3 nebo nfsen4.3.
Obrazek 4.1: Princip fungovanı protokolu
4.1.2 Princip fungovanı a vznik protokolu
Kvuli urychlenı prepınanı na modernıch prepınacıch, ktere pracujı na tretı vrstve refe-rencnıho modelu ISO/OSI a vyuzıvajı pokrocilejsı techniky pri prepınanı jako napr. accesslist, byl prepracovan system vyrovnavacıch pametı na prepınacıch a smerovacıch Cisco.Zacalo se vyuzıvat informacı o sıt’ovem toku. Tento tok se shodoval ve zdrojove a cıloveIP adrese a zdrojovem a cılovem portu, viz obrazek 4.2.
zdrojová IP adresa
cílová IP adresazdrojový port
cílový port
L3 protokol
TOSvstupní rozhraní
síťový provoz
analýzapaketu
Vytvoření tokůz atributů paketu
Informace o toku Počet paketů Bajtů/paket
adresy, porty . . . 13 456 1 234
. . .
Vyrovnávací paměť NetFlow
Zařízení s podporou NetFlow
Obrazek 4.2: Princip vytvarenı toku [6]
Vedlejsım efektem byl zisk zajımavych statistik o sıt’ovem toku. Tyto statistiky bylyrozsıreny a za cenu mırne vyssı rezie pri pruchodu paketu jsou zıskavany informace, kteremohou byt pouzity k celkove analyze vytızenı sıte, analyze provozu dat prochazejıcı jednot-livymi uzly v sıti atd. Vznikl tak protokol NetFlow. Postupne se pridavaly dalsı aplikace,
11
ktere dokazaly s protokolem NetFlow pracovat a pouzıvat ho napr. k uctovanı zakaznıkuza mnozstvı odeslanych dat nebo konektivitu.
Protokol NetFlow vytvarı pro vsechny aktivnı toky vyrovnavacı pamet’, ktera je vy-tvorena na zaklade prijetı prvnıho paketu daneho toku. V teto vyrovnavacı pameti se po-stupne ukladajı dalsı informace o toku, ktere jsou pozdeji odeslany do kolektoru. Tytoexporty jsou provadeny jednou za cas podle nastavenı zarızenı, ktere export dat provadı.Export dat u protokolu NetFlow by mel byt dostatecne efektivnı a podle statistik by meltvorit pouze 1,5 % [20] prenesenych dat na smerovaci. Ukoncovanı toku a nasledny exportse obvykle rıdı podle nasledujıcıch pravidel:
• Spojenı TCP bylo uzavreno, at’ uz pomocı ukoncenı spojenı (prıznak FIN) nebozrusenı (prıznak RST).
• Tok je po urcitou dobu neaktivnı.
• Tok trva prılis dlouho (zakladnı hodnota v nastavenı je 20 minut).
Ukoncene datove toky se zaznamy NetFlow jsou spojeny do paketu viz. 4.1.1 - Exporto-vany paket a odeslany do kolektoru. Tento paket muze obsahovat az 30 zaznamu NetFlow.Data se posılajı jako datagramy UDP a po odeslanı jsou exporterem zahozeny. Protoze jeprotokol UDP bezestavovy, muze dojıt ke ztrate datagramu.
4.1.3 Ukladane informace
V nasledujıcı tabulce lze videt, co vse protokol NetFlow uklada a jake informace tedymuzeme pouzıt k nasledne analyze. Tato data lze zıskat pomocı nastroje nfdump 4.3
Date flow start Cas, kdy byl tok poprve zaznamenan. Ukladan ve formatuISO 8601 vcetne milisekund.
Date flow end Konec toku. Cas, kdy byl tok naposledy detekovan. Ukladanve formatu ISO 8601 vcetne milisekund.
Duration Delka toku v milisekundach. Pokud jsou toky agregovane,delka toku je souctem delek vsech techto toku.
Proto Protokol, ktery byl pouzit v danem tokuSrc IP Addr:port Zdrojova adresa a portDst IP Addr:port Cılova adresa a portTCP flags Prıznaky u paketu TCP (SYN,ACK aj.)ToS Typ sluzby (Type of service)inif, outif Zdrojove a cılove sıt’ove rozhranısrc AS, dst AS Zdrojovy a cılovy autonomnı systemPackets Pocet paketu v toku. Pokud jsou toky agregovane tak jejich
soucetpps Pocet paketu za sekundu: pocet paketu / delka tokubps Pocet bitu za sekundu: 8 * pocet bajtu / delka tokuBpp Pocet bajtu za paket: pocet bajtu / pocet paketuFlows Pocet toku. Pokud jsou toky jenom vypsany - vzdy 1. Pokud
jsou toky agregovany - soucet toku
12
4.1.4 Architektura NetFlow
Klasicky se predpoklada na pozici exportera Cisco smerovac se zapnutou sluzbou NetFlow.Smerovace pak potom krome preposılanı paketu musı svuj vypocetnı vykon venovat taketvorbe statistik. Pokud smerovacem prochazı vyssı datovy tok, nemuze vypocetne zvladatzpracovavanı kazdeho paketu a zaroven generovat statistiky pro dany tok. Proto se provadıvzorkovanı, tedy pro vypocet statistiky se vyuzıva pouze kazdy n-ty paket. Pokud zaznamyNetFlow z techto smerovacu slouzı pouze pro sber statistik, pak vzorkovanı nema vetsı ne-gativnı vliv. Pouze snizuje presnost. Pokud ale chceme zabranit bezpecnostnım incidentum,je vyber pouze kazdeho n-teho paketu problem.
Problem se vzorkovanım paketu resı hardwarove akcelerovane sondy NetFlow. Podrobnejsıpopis sondy je v sekci 4.2.
4.2 Sonda NetFlow
Sonda NetFlow je pasivnım (data jsou pouze monitorovana, nezasahuje se do nich) monito-rovacım zarızenım [22]. Je schopna monitorovat IP toky a posılat je do externıch kolektoru.Pokud sondu zapojıme na linku, kterou chceme monitorovat, prıchozı provoz je poslanprımo ke svemu cıli a zaroven je kopie predana sonde ke zpracovanı. Pokud data odesılamededikovanou linkou prımo do kolektoru, je sonda neviditelna na linkove a vyssı vrstve. Dıkytomu je temer vyloucen prıpadny utok proti sonde. Pouzitı teto sondy mısto smerovacuodstranuje problem se vzorkovanım paketu a prinası dalsı vyhody. Smerovace pak mohousvuj procesorovy cas vyuzıt pouze k tomu, k cemu jsou urceny - smerovanı. Analyzou bylozjisteno, ze sonda zvlada na lince datovou propustnost 1Gbps bez ztraty paketu a bezohledu na velikost paketu [10].
4.2.1 Vlastnosti sondy:
• monitorovanı dvou 1Gbps portu
• presny cas pri analyze paketu
• aktivnı casovy limit - za jak dlouho se tok, ktery je povazovan za aktivnı, musı odeslatdo kolektoru
• neaktivnı casovy limit - umoznuje nastavit casovy interval, za ktery bude tok klasifi-kovan jako ukonceny a odeslan do kolektoru
• export dat ve verzi NetFlow 5, verzi 9 nebo IPFX
• export dat na vıce kolektoru zaroven
• moznost nastavit vzorkovanı
• sber statistik - zıskavanı statistik o IP adrese, cıslech portu, protokolech, poctechprenesenych bajtu a paketu atd.
13
4.3 Nastroje
Pro praci se zaznamy NetFlow existuje cela rada nastroju:
• nfdump (netflow dump) [4]: Nastroj pro ctenı a zpracovavanı dat NetFlow ulozenychpomocı nfcapd. Dokaze z techto dat vytvaret statistiky. Napsan v C pro vetsı rychlost.Dıky tomu dokaze filtrovat vıce nez 4 miliony toku za vterinu na 3GHz procesoru Intel[9], nebo vypocıtat statistiku top N za 2.5s pri 1,5 milionu toku. Pracuje v prıkazoveradce, podobny programu tcpdump. Podporuje zaznamy NetFlow verze 5, 7 a 9. Lzepouzıt filtrovanı podobne jako u libpcap nebo WinPcap, ktere pouzıva napr. tcpdumpa wireshark.
• nfcapd (netflow capture deamon): Zaznamenava data NetFlow ze sıte a uklada je dosouboru. Dokaze pracovat se zaznamy NetFlow verze 5, 7, 9.
• nfprofile (netflow profiler): Dokaze prochazet soubory ulozene pomocı nfcapd. Tytosoubory filtruje podle zadanych filtru a uklada pro pozdejsı analyzu.
• nfreplay (netflow replay): Cte soubory s daty NetFlow ulozene pomocı nfcapda posıla je po sıti na jiny pocıtac.
• nfclean (netflow cleanup): Skript pro mazanı starych dat.
• nfsen (netflow sensor): Jedna se o graficke rozhranı pro nastroj nfdump. Dıky tomutonastroji lze pomocı webovych stranek jednoduse prochazet ulozena data z kolektoru.Dokaze z techto dat zobrazit grafy pro jednotliva rozhranı, protokoly, zvolit si casovyusek, za ktery budou grafy vykresleny, a dalsı. Ukazka rozhranı je v prıloze B
Pro praci s daty NetFlow bude v teto praci pouzit hlavne nastroj nfdump.
14
Kapitola 5
Skenovanı a NetFlow
Skenovacı nastroje jsou bezne pouzıvany pro analyzu sıte. Muze je take ale pouzıt utocnıka informace zıskane z techto skenovanı pouzıt pro dalsı utok. Pokud chceme toto ske-novanı detekovat, je treba analyzovat, co za pakety tyto nastroje pouzıvajı. V laboratornıchpodmınkach jsem vyzkousel skenovanı pomocı nastroju nmap a EtherScope.
5.1 Skenovanı pomocı nmap
Nasleduje prıklad, jak se ulozı data NetFlow pri skenovanı pomocı nastroje nmap. Schema5.1 ukazuje zapojenı sondy NetFlow v laboratori. Muzeme si povsimnout, ze sonda nenızapojena prımo do prepınace. Je to z toho duvodu, ze dane skenovanı bychom potom vubecneodhalili. Na sıti tvorene prepınaci a smerovaci se data posılajı pouze od zdroje k cıli(pokud pomineme ruzne utoky jako arp cache poisoning, zaplnenı CAM tabulky a jine)a data by pro sondu nebyla vubec viditelna.
Obrazek 5.1: Schema zapojenı
Pokud nynı provedeme skenovanı pomocı nastroje nmap, zakladnım prıkazem #nmap 10.10.10.1,a prohledneme si, pomocı nastroje nfdump, co sonda zaznamenala, zıskame udaje, kterejsou videt v tabulce 5.1.
Pro prehlednost byly z tabulky vypusteny nektere udaje. Jsou to informace o delce toku,typ protokolu, ToS1 a pocet bajtu. Jak lze videt, je skenovano asi 1000 nejpouzıvanejsıchportu. Tok se vzdy zobrazuje jako jednosmerny provoz. Tedy tyto stejne toky dostanemei v opacnem smeru, ale budou mıt nastavene jine prıznaky u paketu TCP (prıznak RST,odmıtnutı spojenı). Na prvnı pohled lze videt, ze bylo pouzito skenovanı SYN. Toho muzemepri pozdejsım navrhu vyuzıt. Dalsı vec urcujıcı skenovanı je kratka delka toku a maly pocetpaketu v toku. Tyto informace bude treba zpracovat a na zaklade nich se rozhodovat.Nastroj nfdump umoznuje i tvorbu filtru. Jednoduchym filtrem, ktery muzeme pouzıt nasnadnejsı odhalenı skenovanı SYN, by mohl byt naprıklad filtr
proto tcp and flags S and not flags ARFPU
Tento filtr vypıse vsechny TCP toky, ktere majı u paketu TCP nastaveny pouze prıznakSYN.
Vyzkousel jsem vsechny typy skenovanı, ktere nmap poskytuje. Podrobneji jsou tytotechniky a principy, ktere pouzıvajı k detekci portu, popsany v kapitole 3. Pokud se jednao skenovanı SYN, tak je funkcnı, rychle a spolehlive. Skenovanı connect je pomalejsı, alepokud na danem zarızenı nema uzivatel administratorska opravnenı, je taktez pouzitelne.U mene obvyklych technik jako skenovanı FIN a XMASS zalezı na zarızenı. Vetsinou alezobrazı pocet otevrenych ci filtrovanych portu. U skenovanı NULL jsem se spıse setkal s tım,ze na ne sıt’ove zarızenı vubec neodpovedelo, prestoze by u zavrenych portu melo generovatpaket s prıznakem RST.
5.2 Skenovanı pomocı EtherScopeTMSeries II
Dalsı skenovacı zarızenı, ktere jsem vyzkousel v laboratori je prıstroj EtherScope [2]. Tentosıt’ovy analyzator skenuje celou sıt’. Sondu jsem zapojil prımo za toto zarızenı, jak je videtna obrazku 5.2, abych zıskal veskere udaje o paketech, ktere toto zarızenı posıla. Pribliznadata lze videt v nasledujıcı tabulce 5.2
Z teto tabulky byly odstraneny udaje o casu skenovanı a ToS. Tady vidıme, ze zarızenıEtherScope posıla prevazne pakety ICMP a UDP. U techto paketu nemuzeme provest fil-trovanı jako u skenovanı SYN. Jsou to ale toky vesmes velmi kratke, s malym poctem pa-ketu a kratkou dobou trvanı. Tyto toky by se v sıti nemely vyskytovat prılis casto. Vetsinauzivatelu pouzıva pripojenı pro prohlızenı webovych stranek, komunikaci nebo mail a tamje trvanı toku delsı, s vetsım poctem paketu. Statisticke vysledky, ktere zjist’ujı, zda tototvrzenı je pravdive, jsou probrany v kapitole 7
17
Kapitola 6
Prace s daty NetFlow v rozsahlychsıtıch
Objem dat NetFlow ukladanych smerovaci nebo sondami NetFlow zalezı na velikosti pro-vozu sıte. Velikost exportovanych souboru se muze pohybovat od nekolika MB v malychsıtıch do stovek MB ve velmi rozsahlych sıtıch.
V malych sıtıch mohou byt pouzity pro vytvarenı zaznamu NetFlow smerovace, kteretento protokol podporujı. Ve vetsıch sıtıch s velkym datovym provozem to jiz ale nenı moznea je nutno zaznamenavat data pomocı hardwarove akcelerovanych zarızenı, jako jsou napr.sondy NetFlow 4.2. Ty byvajı nasazovane do sıtı od velikosti padesati zarızenı. Casto jsounasazovany v sıtıch o 100-500 zarızenı. Nasledujı banky, poskytovatele pripojenı, statnıinstituce aj., kde se velikost sıte pohybuje v nekolika tisıcıch zarızenı.
6.1 Zdroj dat NetFlow
Pri zkusebnım provozu sondy NetFlow zapojene v ramci vnitrnı sıte FIT, byl ukladanyprovoz minimalnı a nehodil se k zadne analyze. Pro podrobnejsı analyzu byla poskytnutadata z paternı sıte VUT, ktera je pripojena do akademicke sıte CESNET. Tato data jsouzıskavana ze dvou externıch 10Gb/s linek, ktere pripojujı sıt’ VUT do CESNETu. Sberdat je provaden 10Gb/s kartami na provozu odbocenem prostrednictvım TAPu. TAP jehardwarove zarızenı, ktere umoznuje monitorovat komunikaci mezi dvema body. Zarızenıma minimalne tri porty. Port pro monitorovanı a port pro kazde monitorovane zarızenı.Veskera probıhajıcı komunikace mezi temito body je pak zkopırovana na monitorovacı port.
Data jsou ukladana jako hodinovy zaznam (dump) provozu. Toto je celkem nestandardnıresenı, protoze NetFlow exporter je standardne nastaven na petiminutove exportovanı a totododrzuje dle zkusenostı z praxe vetsina firem.
Dodana data, s kterymi jsem pracoval, nejsou kompletnı data NetFlow. Chybı jimnekolik polozek, napr. prıznaky u paketu TCP. Toto do znacne mıry ztezuje vyhledavanıskenovanı, protoze nejvıce skenovacıch utoku je skenovanı SYN [13]. Pokud bychom meliulozeny i prıznaky, mohli bychom pouzıt filtry, ktere by z toku vypsaly pouze ty s na-stavenym prıznakem SYN a tımto do jiste mıry odhalit skenovanı. U ustanovenı novehospojenı TCP se sice take posıla paket SYN, ale tento paket ma nastaven i prıznak ACKa tedy by nezkreslil filtrovane vysledky. Dalsı podstatna chybejıcı polozka je u protokoluICMP. NetFlow dokaze u tohoto protokolu ukladat typ a kod paketu. Tyto polozky ukladajako zdrojovy a cılovy port. Tedy naprıklad u nejpouzıvanejsı dvojice paketu Echo Request-
18
100
150
200
250
300
350
400
00:00 05:00 10:00 15:00 20:00čas / hod
velik
ost s
oubo
ru /
MB
Obrazek 6.1: Prumerna velikost souboru s NetFlow daty
Echo Reply, pouzıvana prıkazem ping, bude ve zdrojovem portu ulozena 0 a v cılovem 8.0.Odpoved’ Echo Reply (typ 0) na dotaz Echo Request (typ 8, kod 0). Tento nedostatek,stejne jako chybejıcı prıznaky u protokolu TCP, ztezuje nasledne odhalenı utoku, kteretechto paketu ICMP vyuzıvajı k zjistenı zivosti sıt’ovych zarızenı. Casem se vsak planujezakoupenı sondy, ktera bude schopna exportovat plnohodnotne data NetFlow.
Data jsou postupne ukladana na server od 15.11.2008 a zatım je mozno analyzovatpriblizne 740 GB dat. Priblizna velikost jednotlivych souboru a pocet toku za hodinu lzevidet v grafu 6.1 a 6.2. U grafu 6.1 je vypocıtana prumerna velikost souboru za jednotlivehodiny. Prumer je vypocıtan z ulozenych zaznamu za tri mesıce. V grafu 6.2 je pocet tokuvypocıtan obdobne, jako prumerny pocet toku za danou hodinu v dany den. Prumer jevypocıtan take za tri mesıce zaznamu. Zakaznıci pouzıvajıcı sondy NetFlow v CR dosahnoumaximalnı propustnosti okolo 400 toku za sekundu. Jak lze videt, pocet toku dosahovanychv ramci paternı sıte VUT je nejmene 1600 toku/s, bezne ale dosahne 3500 toku/s.
Zpracovavat takove mnozstvı dat je casove velmi narocne. Prumernou dobu generovanıstatistik na pocıtacıch, ktere jsem pouzıval, lze videt v tabulce 6.1.
Prumerna doba vytvorenı statistiky je doba, za kterou se vytvorı statistika top 20 IPadres serazenych podle poctu toku z jednoho souboru, ktery obsahuje hodinovy zaznamprovozu. Nastroj nfdump umoznuje prochazet i vıce souboru najednou a generovat z nichglobalnı statistiky. To je ale extremne narocne na vypocetnı zdroje a operacnı pamet’. Dobapro vytvorenı takove statistiky je v desıtkach minut.
19
5e+06
6e+06
7e+06
8e+06
9e+06
1e+07
1.1e+07
1.2e+07
1.3e+07
1.4e+07
1.5e+07
00:00 5:00 10:00 15:00 20:00
poče
t tok
ů
čas / h
Obrazek 6.2: Prumerny pocet toku za jednotlive hodiny
6.2 Zpracovanı dat
Z vyse uvedenych dob zpracovanı a velikostı dat lze stanovit urcite postupy, jak budou datadale zpracovana. Nabızejı se dve moznosti. Ukladat data do relacnı databaze a pokusit se jezpracovat dotazovacım jazykem ci nejakym rozsırenım pro data mining u databaze Oracle,nebo se je pokusit zpracovat prımo pomocı skriptovacıch jazyku. U relacnı databaze byse nejprve musel vygenerovat skript pro ulozenı dat, nasledne data nahrat do databazea zpracovat, pravdepodobne jazykem PHP nebo podobnym. U skriptovacıch jazyku se datamohou zpracovat rovnou a pravdepodobne jsou ke zpracovanı vhodnejsı.
U obou resenı se potykame s velkymi objemy dat pro zpracovanı. Tento objem dat bymohl byt snızen filtrovanım. Abychom vedeli, jaka data je mozne odfiltrovat, jsou v kapitole7 vytvoreny statistiky ze zıskanych dat, ktere by mohly pomoci s rozhodovanım, ktera datajsou dulezita pro nasledne zpracovanı.
20
Kapitola 7
Statistika dat NetFlow vrozsahlych sıtıch
V rozsahlych sıtıch s velkym poctem aktivnıch uzlu a nekolika tisıci spojenımi za sekunduje obtızne vubec zıskat plnohodnotna data NetFlow v pomeru 1:11. Data jsou bezne vzor-kovana a hodı se hlavne pro statisticke ucely. Pokud jsou zıskavana kompletnı data, lzev kapitole 6 videt, ze techto dat je velke mnozstvı a zpracovanı nenı nejrychlejsı. Muzemese tedy pokusit podıvat na data jako celek, zjistit jake sluzby jsou v tocıch dominantnı,jake jsou prenosy dat, atp.
Na nasledujıcım grafu 7.1 je videt prumerne mnozstvı unikatnıch IP adres v prubehudne. Tento graf bude posleze dulezity pri navrhu zpracovanı dat pro odhalenı skenovanı.Pokud bychom chteli porovnavat jednotlive zaznamy mezi sebou, casova slozitost takoveoperace by byla kvadraticka O(n2). U zaznamu, ktery ma 2 mil. unikatnıch IP adres zahodinu, by pocet operacı potom dosahl 412, coz je neumerne narocne a musı byt pouzit jinyprıstup.
1e+06
1.2e+06
1.4e+06
1.6e+06
1.8e+06
2e+06
2.2e+06
2.4e+06
2.6e+06
00:00 05:00 10:00 15:00 20:00
poče
t unik
átní
ch IP
čas/hod
Obrazek 7.1: Pocet unikatnıch IP adres v toku
Graf 7.2 ukazuje, kolik je prumerne vymeneno paketu v toku. V datech, ze kterych je1Je zaznamenan kazdy paket. Nedochazı tedy ke vzorkovanı
21
1
10
100
1000
10000
100000
1e+06
1e+07
1e+08
1 10 100 1000 10000 100000 1e+06
Četn
ost
Počet paketů v toku
Obrazek 7.2: Frekvence poctu paketu v toku
tento graf vygenerovan, se vyskytovalo temer 35 mil. jednopaketovych toku, coz predstavujepriblizne 55 %. Toky do 3 paketu pak tvorily priblizne 80 % vsech toku. Dıky teto statisticese vyrazne zmenilo tvrzenı, ktere jsme uvazovali v kapitole 5, tedy ze kratkych toku budemale mnozstvı.
Pokud se na toky podıvame z hlediska sluzeb, nenalezneme prılis prekvapive vysledky.Dominantnı sluzbou je protokol HTTP, HTTPS. U UDP je to protokol DNS. Co se tyceprenesenych dat, zde je dominantnı tunelovacı protokol GRE2 od firmy Cisco.
Počet toků u služeb
HTTPS 1.7%
HTTP 9.2%
ICMP 4.0%
DNS 2.7%
rest of 82.3%
Počet bytů u služeb
GRE 2.9%
HTTP 1.7%HTTPS 0.4%
dynamic ports 1.6%SSH 0.3%
rest of 93.1%
Obrazek 7.3: Statistika jednotlivych sluzeb
Z nasledujıcıch grafu 7.3 se muze zdat, ze tyto sluzby jsou zastoupeny v mizivemmnozstvı. Je treba si ale uvedomit, ze celkove mnozstvı portu je 65535. Tedy soucetvsech ostatnıch toku a bajtu proudıcı na ostatnı porty je samozrejme vetsı. Polozka dy-
2Generic Routing Encapsulation
22
namicke porty znamena porty od 49152 vyse. Tyto porty se ve statistice menı kazdy dena pravdepodobne to budou vytvorene tunelovacı spoje. To usuzuji za predpokladu, ze tytodynamicke porty majı velice podobny pomer poctu toku ku prenesenym bajtum. Jako dalsıvyznamna polozka z hlediska poctu toku je protokol ICMP. Predpokladam, ze vetsina techtotoku jsou pakety ICMP Echo-Request a Echo-Replay, ale z duvodu uvedenych v kapitole6 to nelze presne urcit. Pokud jsem zkoumal data, ktera byla k dispozici od firmy Invea,lze v tocıch ICMP pozorovat take hodne paketu kodu 3 - Destination unreachable. PrestoEcho pakety prevazujı.
V tabulce 7.1 lze videt priblizny pomer toku a bajtu u nejfrekventovanejsıch sluzeb.Tato statistika je generovana za ctyr hodinovy provoz v nejfrekventovanejsı dennı dobu. Zatyto ctyri hodiny bylo v priblizne 77 mil. tocıch preneseno 1,2 TB dat. Lze videt, ze pomocıtunelovacıho protokolu se prenası velke mnozstvı dat, ale pocet toku je velice maly, dıkyvelice dlouhemu trvanı spojenı. U protokolu HTTP je naopak preneseno velke mnozstvıbajtu pri nekolikanasobnem mnozstvı toku. Proto jsem vyse usoudil, ze dynamicke porty,ktere se objevujı ve statistikach budou pravdepodobne dalsı tunelovacı protokoly, jako napr.VPN.
U skenovanı se pripojuje utocnık na jednotlive porty zarızenı, ktere skenuje. Pokudskenuje napr. pomocı zakladnıho nastavenı skeneru nmap, testuje u jednoho pocıtace tisıcportu. Bylo by tedy zajımave zjistit, na kolik portu se v realnem provozu prumerne uzivatelpripojuje. Toto lze videt na grafu 7.4. Lze videt, ze prumerne se uzivatel pripojuje na velicemale mnozstvı portu. V 80 % prıpadu je to dokonce pouze jeden port.
1
10
100
1000
10000
100000
1e+06
1e+07
0 200 400 600 800 1000 1200 1400
Četn
ost
Počet navštívených portů
Obrazek 7.4: Frekvence poctu navstıvenych portu
Stejne tak jsem vytvoril statistiku poctu toku za jednotlive IP adresy. Graf 7.5 je vy-
23
tvoren z 26,3 mil. toku, ve kterem bylo 2,6 mil. unikatnıch IP adres. Pocet IP adres, kterevytvarı pouze jeden tok je sice nejvetsı, ale z celkoveho mnozstvı je to pouze okolo 6 %. Jetotiz daleko vıce IP adres, ktere majı vetsı mnozstvı toku.
1
10
100
1000
10000
100000
1e+06
1e+07
1 10 100 1000 10000 100000 1e+06
Četn
ost
Počet toků na IP
Obrazek 7.5: Frekvence poctu toku za IP adresu
24
Kapitola 8
Analyza zıskanych dat a navrhaplikace
V predchazejıcıch kapitolach jsem vytvoril radu statistik, ktere popisujı provoz v sıti. Zezıskanych udaju je nynı nutne vybrat zakladnı prvky, dıky kterym bude mozno odhalitskenovanı i v takto rozsahle sıti. Dale je nutno zodpovedet otazky tykajıcı se samotneaplikace. Nasleduje shrnutı nejpodstatnejsıch udaju.
8.1 Shrnutı zıskanych statistik
• Unikatnı IP adresy: V provozu jsem zjistil velky pocet unikatnıch IP adres. Bezne jeto kolem 2 mil. adres za hodinu. Kazda adresa se samozrejme pripojuje v libovolnycas a v zaznamu se tedy vyskytuje tisıce toku se stejnou IP adresou. Pokud bych chtelna zaklade IP adresy toky analyzovat, musel bych pro kazdou IP adresu projıt celyzaznam.
• Navstıvene porty: Pokud jsem sledoval prumerny pocet navstıvenych portu u IP ad-resy, v 80 % prıpadu je to pouze jeden port. Jak jiz bylo zmıneno, u skenovanı seutocnık pripojuje k velkemu mnozstvı portu nebo k jednomu, ale na velkem mnozstvıpocıtacu.
• Pocet paketu v toku: U skenovanı je vyuzıvano predevsım skenovanı SYN, kterepouzıva pouze jeden paket. Toku, ktere obsahujı pouze jeden paket, je ale vıce nezpolovina. Tato situace je tedy podobna jako u unikatnıch IP adres.
• Mnozstvı dat: Zaznamy v hodinovych dumpech provozu obsahujı velke mnozstvı dat.Zpracovavat tato data je pak casove narocne.
Je nutne si uvedomit, ze i kdyby byla k dispozici velka vypocetnı sıla a nebyl bych ome-zen pametı apod., analyzovat data delsı casovy usek je bezpredmetne. Skenovacı utok castopredchazı utok jiny a je tedy vyhodne na nej rychle reagovat a dalsım utokum tak zabranit.Take je ale dulezite si uvedomit, ze vysledky, zda doslo v realnem provozu ke skenovanı,nemohu odhalit ihned. Zaznam NetFlow nemuze exporter odesılat kazdou sekundu, protozeby zahltil sıt’. Standardne je posılan po peti minutach.
Co z vyse uvedenych bodu vyplyva? U dat by bylo vhodne se pokusit odfiltrovat tadata, o kterych jsme presvedceni, ze neobsahujı podezrelou aktivitu a zmensit tak objemdat k dalsımu zpracovanı. Problem u filtrovanı je ten, ze dat, ktera jsou pro odhalenı
25
skenovanı nejdulezitejsı, je nejvıc. Ve vetsine prıpadu jsou to totiz kratke, nekolikapaketovetoky, tedy stejna data, jaka posılajı nastroje pro skenovanı portu. Odfiltrovanım delsıchtoku sice zmensım castecne objem, ale 80 % dat mi stejne zustane a resım stejny problem.
Cas na zpracovanı dat aplikacı musı byt prinejhorsım stejny, jako cas, za ktery se vytvarızaznamy. Pokud jsou zaznamy posılany do kolektoru v desetiminutovych intervalech, nelzedata zpracovavat dele nez 10 minut. Zpracovanı by ale melo trvat podstatne kratsı dobu.
Odhalit vsechna skenovanı v sıti, ktera ma miliony spojenı za hodinu, je nemozne. Pokudbude utocnık skenovat pouze nekolik pocıtacu a portu, je to v takto objemnych datechneodhalitelne. Toto ale ani nenı pozadavkem. U takto velkych sıtı je cılem odhalit utocnıky,kterı provadı horizontalnı skenovanı celych podsıtı, prıpadne velke blokove skenovanı.
Zamerme se tedy na horizontalnı skenovanı. Pro toto skenovanı platı:
• Pouzıva jedno az dvou paketove toky
• Skenuje velke mnozstvı IP adres
• Toky trvajı kratce. Delka skenovanı zavisı na poctu IP adres.
• Pocet bajtu je stale stejny
Protoze v hodinovem zaznamu o provozu jsem nedokazal efektivne odhalit zadne utoky,zameril jsem se na omezenı velikosti zpracovavanych dat. Jak jsem ukazal v kapitole 7,velky pocet toku na IP adresu je relativne maly. Skenovanı trva take relativne kratkoudobu. Za tuto kratkou dobu ale vytvorı utocnık velke mnozstvı toku. Omezil jsem si tedyhodinovy zaznam na nejkratsı rozumny ”petiminutovy”zaznam. Pokud se v tomto kratkemcasovem useku objevı utocnık, mela by nastat nasledujıcı situace:
1. Utocnık vytvorı velke mnozstvı spojenı. Toto by se melo projevit ve statice toku nazaklade zdrojove IP adresy.
2. Toky utocnıka by mely vykazovat stejny pocet paketu, stejny pocet bytu a kratkoudobu trvanı.
3. Legitimnı uzivatele by nemeli podle zıskanych statistik vytvaret velke mnozstvı toku.
4. Servery, ktere obsluhujı hodne klientu, vytvarı take hodne toku. V techto tocıch byale pocet paketu mel kolısat, stejne tak pocet prenesenych bajtu.
Z vyse uvedenych uvah jsem postupoval nasledujıcım zpusobem.
1. Z petiminutoveho toku je vytvorena statistika o nejfrekventovanejsıch IP adresach nazaklade poctu toku.
2. U kazde IP adresy je vyfiltrovan zaznam o vsech jejıch tocıch v danem casovemintervalu.
3. Tento zaznam je zpracovan pomocı rozhodovacıho algoritmu.
4. Vysledky jsou zobrazeny na standardnı vystup.
26
8.2 Rozhodovacı algoritmus
Pro rozhodovanı, zda dany tok je, nebo nenı soucast skenovanı, je vhodne pouzıt technikypro strojove ucenı a dolovanı z dat. Pri dolovanı z dat se zde uplatnı hlavne analytickametodologie, pri ktere se pouzıvajı rozhodovacı stromy, neuronove sıte nebo geneticke pro-gramovanı. Pro tuto praci jsem usoudil, ze bude nejvhodnejsı pouzıt rozhodovacı stromgenerovany algoritmem ID31 [16].
Rozhodovacı stromy jsou induktivnı algoritmy vytvorene ke klasifikaci instancı. Muzemeje pouzıt, kdyz jsou instance popsany atributy a hodnotami (napr. VLHKOST: normalnı,vysoka) a cılova funkce nabyva diskretnıch hodnost (napr. ANO / NE). Trenovacı datamohou obsahovat i chyby a take nemusı obsahovat hodnoty vsech atributu.
Cılova funkce je reprezentovana rozhodovacım stromem (sekvencı rozhodnutı if-then-else).Klasifikace se provadı pruchodem stromem od korene k listum, kdy se testuje hodnota jed-noho atributu instance pro kazdy uzel. Kazda hrana odpovıda jedne hodnote. Kazdy listpak urcuje klasifikaci instance.
U ID3 algoritmu vytvarıme na zaklade trenovacıch dat rozhodovacı strom. Strom sevytvarı od korene. V kazdem uzlu se zjist’uje, ktery atribut je pro prave tento uzel nej-vhodnejsı. Pocet potomku odpovıda poctu hodnot vybraneho atributu. Trenovacı data serozdelı podle prıslusne hodnoty atributu na prıslusne podmoziny. Algoritmus pracuje re-kurzivne v nasledujıcıch krocıch.
Prıklad vytvoreneho rozhodovacıho stromu muzeme videt na obrazku 8.1. U tohotoprıkladu je strom pouzit k rozhodnutı, zda mam nebo nemam jıt hrat golf.
Předpověď
Slunečno Zataženo Déšť
Vlhkost
Vysoká Normální
NE ANO
ANO Vítr
Silný Slabý
NE ANO
Obrazek 8.1: Prıklad rozhodovacıho stromu
1Iterative Dichotomiser 3
27
ID3(Trenovacı data, Cılovy atribut, Atributy)
1. Zaloz Koren stromu
2. Pokud jsou vsechna Trenovacı data pozitivnı, vytvor jednouzlovy strom s korenemoznacenym +
3. Jsou-li vsechna Trenovacı data negativnı, vytvor jednouzlovy strom s korenem oznacenym-
4. Je-li mnozina atributu Atributy prazdna, vrat’ jednouzlovy strom s korenem oznacenymnejcastejsı hodnotou cıloveho atributu v trenovacıch datech
5. Jinak:
Vyber atribut A, ktery nejlepe klasifikuje trenovacı data, Koren = A
5.1 Pro kazdou jeho moznou hodnotu vytvor novou vetev5.2 Vytvor Podmnozinavi z trenovacıch dat, pokud A = vi5.3 Je-li Podmozinavi prazdna, pod danou vetvı zaloz list stromu oznaceny
nejcastejsı hodnotou cıloveho atributu v trenovacıch datech5.4 Jinak pridej pod vetev podstrom ID3(Podmnozinavi, Cılovy atribut,Atributy - A)
Kriterium ocekavaneho zisku muzeme definovat jako mıru ocekavaneho snızenı entropie porozdelenı trenovacıch dat podle hodnoty vybraneho atributu [23]. Tedy informace, kterounam prinası znalost hodnoty atributu. Formalnı zapis potom ukazuje rovnice 8.1:
Gain(D,A) ≡ H(D)−∑
v∈V alues(A)
|Dv||D|
H(Dv) (8.1)
• A - atribut; A(d) - hodnota atributu A v instanci d
• V alues(A) - mnozina vsech moznych hodnot atributu A
• D - trenovacı data
• Dv - trenovacı data takova ze: Dv = {d ∈ D; A(d) = v}
28
Trenovacı data
Pro klasifikaci, zda tok je nebo nenı soucastı skenovanı, jsem vytvoril nasledujıcı sadupravidel. Popis atributu:
• Cılova IP:
– maly rozdıl v rozsahu: Tato hodnota znamena, ze IP adresy jdou postupneza sebou v jedne podsıti. Napr 10.10.10.1, 10.10.10.2 atd.
– stejna: Stejna IP adresa ve dvou po sobe nasledujıcıch tocıch
– rozdılna: IP adresa je z rozdılnych podsıtı
• Cılovy port:
– rozdıl < 5: Podobne jako u IP adresy tato hodnota atributu urcuje, zda portyjdou postupne za sebou.
– stejny: Porty po dvou po sobe jdoucıch tocıch jsou shodne.
– rozdılne: Dva po sobe jdoucı toky majı rozdılne porty.
• Pocet paketu:
– < 5: Tok obsahuje mene nez pet paketu.
– > 5: Tok obsahuje vıce nez pet paketu.
• Pocet bytu:
– stejny, nebo dvojnasobny nebo polovicnı: Tok ma stejny, nebo dvojnasobnynebo polovicnı pocet bajtu jako tok predchazejıcı.
– rozdılny: Rozdılny pocet bajtu ve 2 tocıch.
Cılova IP Cılovy port Pocet paketu Pocet bajtu Skenovanımaly rozdıl v rozsahu stejny < 5 stejny, nebo 2x nebo 1
2 ANOstejna rozdıl < 5 < 5 stejny, nebo 2x nebo 1
2 ANOrozdılna rozdılny < 5 rozdılny NEstejna rozdılny < 5 rozdılny NEstejna rozdıl < 5 > 5 rozdılny NEmaly rozdıl v rozsahu rozdıl < 5 < 5 stejny, nebo 2x nebo 1
2 ANOrozdılna rozdıl < 5 > 5 rozdılny NErozdılna rozdılny > 5 stejny, nebo 2x nebo 1
2 NEstejna stejny > 5 rozdılny NEmaly rozdıl v rozsahu rozdılny > 5 rozdılny NEmaly rozdıl v rozsahu rozdıl < 5 < 5 rozdılny ANOstejna rozdıl < 5 < 5 rozdılny ANO
Tabulka 8.1: Trenovacı data pro ID3 algoritmus
29
Z tabulky 8.1 jsem vytvoril mnozinu trenovacıch dat. Algoritmus pro vytvorenı rozho-dovacıho stromu jsem vytvoril v jazyce python. Casti algoritmu jsou prevzate z [18]. Povytvorenı rozhodovacıho stromu jsem zjistil, ze z hlediska ocekavaneho zisku jsou dulezitepouze atributy Pocet paketu a Cılovy port. Tım by ale nebylo moc moznostı, jak ovliv-nit ”citlivost”detekce. Doplnil jsem tedy i dalsı atributy. Cast vetve vysledneho stromu jena obrazku 8.2
Pakety
IP
Porty
> 5
NE
IPIP
Počet bajtů...
> 5
rozdíl < 5= rozdílný
=< 5
rozdílná
= !=
.
.
.
.
.
.
.
.
.Počet bajtůPočet bajtů
ANO Podezřelé
Obrazek 8.2: Cast ID3 stromu
30
Kapitola 9
Implementace
9.1 Popis implementace
Ulozena data NetFlow zpracovavam pomocı nekolika skriptu implementovanych pomocıskriptovacıch jazyku Bash a Python. Vytvaret univerzalnı aplikaci je narocne z nekolikahledisek. Data mohou byt umıstena na ruznych systemech rozdılne. Toto lze castecne resitkonfiguracnım souborem, kde nastavıme vychozı adresare. Ty ale mohou mıt rozdılnouadresarovou strukturu, rozdılny zpusob pojmenovanı, atd. Vytvoril jsem nekolik skriptu,ktere spojuji do vetsıho celku. Duvodem, proc jsem vytvarel male, jednoucelove skripty, jevetsı univerzalnost. Data z paternı sıte VUT tvorı zaznamy hodinoveho provozu. Tytozaznamy potrebuji rozdelit na petiminutove, ale jine systemy mohou ukladat data jizv pozadovanem casovem rozsahu. Proto muze byt vetsina skriptu vynechana a spravcepouzije pouze ty, ktere potrebuje pro analyzovanı dat. Sadu skriptu jsem tedy vytvorils ohledem na univerzalnost, ale primarne pro zpracovanı dat ze sıte VUT. Pro zpracovanına jinych systemech bude pravdepodobne potreba je prekonfigurovat, prıpadne prizpusobit.
Data na serveru VUT jsou ulozena v teto adresarove strukture:
kde yyyy = rok, mm = mesıc, dd = den, hh = hodina(24h/den), mm = minuta. Tytosoubory jsou hodinove zaznamy provozu. Nejdrıve je nutne je rozdelit na petiminutovezaznamy.
Prıklad rozdelenı hodinoveho souboru na petiminutovy.
• -t: filtruje data pouze podle casoveho okna zadaneho jako parametr
• -w: soubor uklada jako NetFlow zaznam do pozadovaneho adresare (v zakladnımnastavenı jsou zaznamy vypsany na standardnı vystup a nemohou byt zpracovanaznovu pomocı nastroje nfdump)
Schema volanı skriptu je na obrazku 9.1.Pro rozdelenı hodinovych zaznamu NetFlow slouzı skript split.sh. Pomocı nastroje
nfdump jsou tyto zaznamy rozdeleny na mensı o pozadovane delce. Tento skript dale spoustı
31
Soubor NetFlow s hodinovým
záznamem síťového provozu
split.shSkript rozdělí daný hodinový
záznam na pětiminutové
soubory NetFlow
main_skript.sh parseIP.py
pětiminutový záznam
síťového provozu
vytvoř statistiku topN
Skript získá ze statistiky IP adresy,
s počtem toků tisíc a víc
seznam IP adres
detectScan.py
Skript vygeneruje statistiku topN.
Z souboru s daty NetFlow vyfiltruje
záznam o komunikaci pro jednotlivé
IP adresy.
záznam o síťové komunikaci
jedné IP adresy
Skript analyzuje záznam o komunikaci.
Výsledek detekce je přidán do logu prodaný den.
Zápis do souboru
Obrazek 9.1: Schema volanı skriptu
skript main skript.sh, kteremu preda v argumentech nazev petiminutoveho souboru, da-tum a cas, ze ktereho je tento souboru vytvoren. To je nutne, pokud bezı vıce procesua skript split.sh rozdelil data z jedne hodiny. Tato data ale jeste nebyla zpracovana;data by se prepisovala. Skript main skript.sh vytvarı z daneho souboru statistiku topNpodle nejfrekventovanejsı IP adresy, serazene podle poctu toku. Samotny nastroj nfdumpumoznuje si definovat vlastnı format vystupu. Toto funguje spravne. Problemem je, ze nelzenadefinovat vlastnı format vystupu u tisku statistik, i kdyz podle dokumentace by to melobyt mozne. Program tento format nebere na vedomı a zobrazuje vysledek v zakladnım nade-finovanem formatu. Musel jsem proto vytvorit skript printIP.py, ktery dane IP adresy vy-filtruje. Vysledek preda pomocı roury zpet skriptu main skript.sh. Ten na zaklade techtoIP adres ulozı provoz jednotlivych IP adres do souboru. Provoz je ukladan jako text, abymohl byt zpracovan dalsım skriptem. Pro ukladanı provozu dat pouzıvam preddefinovanyformat pipe, ktery jednotlive polozky oddeluje znakem |.
Jednotlive polozky jsou popsany v prıloze A.Soubor se zaznamem o provozu je nasledne zpracovan skriptem detectScan.py. V tomto
skriptu je rozhodovacı strom ID3 transformovan na sadu if-then-else pravidel. Sou-bor s provozem je nacten do pameti. Tok, ktery prochazı stromem, se vzdy porovnavas predchazejıcım tokem. Pro podrobnejsı nastavenı jsou k dispozici ctyri vahy.
Tyto promenne urcujı vahu jednotlivych vetvı pri pruchodu stromem. Jednotlive vahyse tykajı poctu paketu, IP adresy, poctu bajtu a cıloveho portu. Vahy jsou na zakladepruchodu toku stromem scıtany. Pokud se dva porovnavane toky nebudou shodovat napr.v poctu bajtu, vaha poctu bajtu nebude do vysledne vahy pripoctena. Vysledna vahatak nebude maximalnı, ale dıky velke shode v ostatnıch polozkach tento tok bude porad
32
podezrely. Vyslednou vahou se vynasobı krok prahu. Ten se vypocte jako 100/pocet tokudane IP. Dojde tak k tomu, ze pokud kazdy tok IP adresy splnı vsechna podezrenı, ze jesoucastı skenovanı, vysledny prah bude roven hodnote 100. Castecne podezrele toky paktuto hodnotu snizujı.
Vysledny prah je nasledne zanalyzovan. Empirickou cestou jsem pak stanovil hraniciprahu > 70. Pokud tedy vysledny prah odpovıda teto hodnote, je provoz z dane IP ad-resy povazovan za skenovanı. Do logu jsou potom zapsany statisticke informace o danemskenovanı. Prıklad detekovaneho skenovanı a jeho zaznamu v logu.
Ukladane polozky jsou:
IP adresa start konec prah pocet IP port soucet132.171.123.72 1231973529 1231973695 90.35730912481 1778 25 429638.160.27.218 1231962908 1231963096 84.31409716371 44034 80 5341539.172.242.61 1233443400 1233443699 88.01718092571 48 53 7130
Tabulka 9.1: Ukladane udaje o skenovanı
Vyznam jednotlivych polozek:
• IP adresa: IP adresa utocnıka.
• start: Zacatek skenovanı, format casu - UNIX.
• konec: Konec skenovanı, format casu - UNIX.
• prah: Celkovy vypocıtany prah.
• pocet IP: Pocet skenovanych IP adres.
• port: Ktery port byl skenovan.
• soucet: Kolikrat byl dany port skenovan.
Pokud bylo detekovano vıce portu, jsou ukladany postupne za sebou ve formatu cısloportu|kolikrat byl skenovan
9.2 Cas zpracovanı
V realnem provozu predpokladam nasledujıcı pouzitı.
• Data budou ukladana v petiminutovych intervalech.
• Skript pro detekci bude spousten v techto intervalech na nove vytvorene soubory.
• Vysledky analyzy mohou byt poslany na e-mail, nebo zobrazeny ve webovem rozhranı.
Dalsı moznostı je propojit tento detekcnı system se skriptem, ktery bude automatickygenerovat pravidla pro firewall. Moznostı je cela rada a zalezı na spravci sıte, co budepozadovat.
Doba zpracovanı jednotlivych souboru zavisı na provozu v sıti. Z dat, ktere mam k dis-pozici, obsahuje petiminutovy zaznam priblizne 1.5 mil. toku. Vytvorenı cele statistiky u ta-koveho souboru trva priblizne 10 sekund. Vytvorenı petiminutoveho zaznamu trva priblizne
33
15 sekund. Analyza dat jednoho dne trva priblizne 1.5 – 2 hodiny. Zalezı na mnozstvı data na poctu adres, ze kterych se generuje statistika topN, tedy u kolika IP adres se kontrolujıvsechny toky.
34
Kapitola 10
Vysledky analyzy
Pomocı implementovanych skriptu jsem provedl zpetne analyzu na anonymizovanych da-tech. Vysledkem jsou zaznamy (logy), ve kterych jsou zaznamenany bezpecnostnı incidentyza jednotlive dny ve formatu jak ukazuje tabulka 9.1. Bezpecnostnı incident je jeden zaznamv souboru. Pokud se skenovanı opakuje delsı dobu, bude toto skenovanı zaznamenanovıcekrat. Provedl jsem analyzu za mesıce leden a unor. Celkem bylo analyzovano 393,7GB dat. Dıky problemu ve skriptu, ktery ukladal data NetFlow na serveru, nejsou u dalsıchmesıcu ulozena kompletnı data. Chybı napr. nekolik hodin zaznamu za den, u nekterychdnu nejsou ulozeny zaznamy vubec. Pokud by se z techto nekompletnıch dat generovala sta-tistika, byly by vysledky oproti mesıcum leden, unor zkreslene a neporovnatelne. V prılozeC je vyber nekolika detekovanych IP adres a ukazka komunikace, ktera byla zıskana z datNetFlow.
Pocet vsech bezpecnostnıch incidentu za jednotlive mesıce a nejcasteji skenovane portyjsou zobrazeny na obrazku 10.1 a 10.3. Jednotlive polozky jsou popsany v tabulce 10.1.
200
400
600
800
1000
1200
1400
1600
01.0
1.20
0902
.01.
2009
03.0
1.20
0904
.01.
2009
05.0
1.20
0906
.01.
2009
07.0
1.20
0908
.01.
2009
09.0
1.20
0910
.01.
2009
11.0
1.20
0912
.01.
2009
13.0
1.20
0914
.01.
2009
15.0
1.20
0916
.01.
2009
17.0
1.20
0918
.01.
2009
19.0
1.20
0920
.01.
2009
21.0
1.20
0922
.01.
2009
23.0
1.20
0924
.01.
2009
25.0
1.20
0926
.01.
2009
27.0
1.20
0928
.01.
2009
29.0
1.20
0930
.01.
2009
31.0
1.20
09
Poč
et in
cide
ntů
Obrazek 10.1: Pocet skenovanı za mesıc leden
35
0
1000
2000
3000
4000
5000
6000
7000
dnscap
1027http
icmp
board-voip
ms-sql-s
telnet
sshssc-agent
Poč
et s
keno
vání
Obrazek 10.2: Nejcasteji skenovane porty za mesıc leden
200
400
600
800
1000
1200
1400
1600
01.0
2.20
0902
.02.
2009
03.0
2.20
0904
.02.
2009
05.0
2.20
0906
.02.
2009
07.0
2.20
0908
.02.
2009
09.0
2.20
0910
.02.
2009
11.0
2.20
0912
.02.
2009
13.0
2.20
0914
.02.
2009
15.0
2.20
0916
.02.
2009
17.0
2.20
0918
.02.
2009
19.0
2.20
0920
.02.
2009
21.0
2.20
0922
.02.
2009
23.0
2.20
0924
.02.
2009
25.0
2.20
0926
.02.
2009
27.0
2.20
0928
.02.
2009
Poč
et in
cide
ntů
Obrazek 10.3: Pocet skenovanı za mesıc unor
Jak lze videt, pocet bezpecnostnıch incidentu je relativne vysoky. Pokusil jsem se tedyzjistit, zda jsou tyto vysledky pravdive a detekovane bezpecnostnı incidenty jsou opravduskenovanım.
U anonymizovanych dat nelze urcit, komu odpovıda jednotliva IP adresa. Skripty byly
36
0
1000
2000
3000
4000
5000
6000
7000
dnsm
icrosoft-ds
cap1027
httpicm
pm
s-sql-s
telnet
ssc-agent
ssh
Poč
et s
keno
vání
Obrazek 10.4: Nejcasteji skenovane porty za mesıc unor
Protokol Port PopisICMP Protokol ICMP, pravdepodobne ping
cap + 1027 1026, 1027 Calendar Access Protocol. Pravdepodobne pokus o spam po-mocı sluzby Windows Messenger [21]
ssh 22 Protokol SSHssc-agent 2967 Symantec System Center. Pravdepodobny pokus o zneuzitı
chyby v programu Symantec AV Corp. [3]
Tabulka 10.1: Popis nejcasteji skenovanych portu
pro testovacı ucely tedy spusteny nad jednodennım zaznamem neanonymizovanych dat.Mohly byt tedy dohledany jednotlive IP adresy a zjisteny nektere dalsı informace o zarızenı,ktere by umoznily urcit, zda se nejedna o falesny pozitivnı alarm. Ukazalo se, ze detekovaneIP adresy opravdu byly skenovany, nebo skenovanı pouzıvaly.
Nabızı se otazka, jak tyto vysledky realne zpracovat, aby byly prınosem pro bezpecnostv dane sıti. Dosazene vysledky byly konzultovany se spravcem paternı sıte VUT Ing. TomasemPodermanskim. Zıskane poznatky z prıpadneho praktickeho uplatnenı jsem shrnul v nasledujıcıchbodech.
• Nelze provadet blokaci detekovanych IP adres. Blokace je obecne velice problematicka,protoze celım nekolika problemum.
37
– Delka blokace: Nelze rozumne urcit delku blokovanı. Kratke blokovanı pravdepo-dobne nebude prılis efektivnı. Dlouha blokace zase komplikuje pruchod filtro-vacımi pravidly na firewallu. Detekovanych IP adres je velke mnozstvı, firewallby tedy musel prochazet velke mnozstvı pravidel.
– Podvrh adresy: Zdrojova IP adresa (tedy IP adresa utocnıka) muze byt podvrh-nuta. Pokud bych pristoupil k blokovanı, zablokuji nepravem prıstup legitimnımuuzivateli.
– Blokace zarızenı PAT: Muze se stat, ze skenovanı sıte prochazelo pres zarızenıslouzıcı pro preklad adres. Pokud bych zablokoval IP adresu tohoto zarızenı,muzu tım zablokovat prıstup velkemu poctu legitimnıch uzivatelu.
Pri blokovanı pak v praxi vznikajı nedeterministicke chyby. Zakaznıkovi obcas necofunguje, obcas ne. Tyto chyby se velice tezko odhalujı a opravujı.
• Na skenovanı mırıcı do vnitrnı sıte VUT nelze z vyse uvedenych duvodu adekvatnereagovat. Pokud je ale detekovano skenovanı ze sıte VUT, lze uz tento pocıtac vy-hledat, zjistit, kdo je za nej zodpovedny a proc ke skenovanı doslo. Z tohoto duvodujsou informace o skenovanı ze sıte VUT smerem do Internetu vyznamnejsı.
Lze tedy videt, ze reakce na detekovane skenovanı je velice problematicka. Pokud nekdoskenuje sıt’ VUT, nelze na to ve vetsine prıpadu adekvatne reagovat. Blokace z vyse uve-denych duvodu nepripada ve vetsine prıpadu v uvahu. Porty byvajı blokovane pomocı fi-rewallu a jedine ceho tak utocnık dosahne je automaticke uzavrenı spojenı TCP. Bylo tedynavrhnuto resenı, ktere by melo prakticky prınos pro bezpecnost sıte.
Budou detekovana pouze ta skenovanı, ktera pochazı ze sıte VUT. Dıky tomu budemozno dohledat problematicke pocıtace a sjednat napravu. Tyto udaje budou ulozeny do jizimplementovaneho systemu, ktery se v soucasnosti pouzıva ke zıskanı informacı z pocıtacu,ktere fungujı jako honey-pot. Tyto informace jsou pak predkladany spravcum jednotlivycharealu, kterı na zaklade techto informacı adekvatne reagujı na zjistene hrozby.
38
10.1 Vyzkum ve svete
Neustala potreba zvysovat zabezpecenı sıte vede ke snaze pouzıt pro zvysenı bezpecnostinove technologie, napr. NetFlow. V konferencıch je publikovana cela rada clanku, ktera sezabyva vyzkumem, jak tento protokol a zıskana data vyuzıt pro bezpecnost sıte. Jednımze zpusobu je snaha o vizualizaci dat NetFlow ve forme grafu a naslednou analyzou zjistitbezpecnostnı chyby [12]. Dalsım zpusobem vyuzitı zaznamu NetFlow je klasifikace sıt’ovychskenovanı do novych kategoriı. Nektere skodlive programy provadı skenovanı, ktere spadado urcitych kategoriı a tak lze do jiste mıry odhalit bezpecnostnı incidenty v sıti [11].Prevazne je ale snaha vyuzıt tuto technologii v systemech NIDS a NIPS. Vetsina techtoresenı pouzıva pro analyzu utoku detekci anomaliı. Prıkladem muze byt cesky prototypsystemu NIDS, CAMNEP [17]. Je vyvıjen Ceskym vysokym ucenım technickym a Masa-rykovou univerzitou. Tento system pouzıva data NetFlow zıskana z vıce bodu v sıti. Datajsou nasledne analyzovana pomocı agentu, kde kazdy agent pouzıva jinou funkci pro detekcianomaliı. Vysledkem je mıra duvery v dany tok. Nasledne lze toky podle zıskanych hodnotfiltrovat a vizualizovat.
Protokol NetFlow je relativne nova technologie, ktera nenı ve velkych sıtıch zatım mocrozsırena. Tyto sıte pro kvalitnı a uplna data NetFlow potrebujı hardwarove sondy NetFlow,aby zamezily vzorkovanı a zatezi smerovacu. Dıky temto sondam se ale tato technologie stalevıce rozsiruje. Ukladana data NetFlow obsahujı mnozstvı informacı o provozu v sıti. Je tedysnaha pouzıt tato data pro zvysenı bezpecnosti sıte a navrhnout kvalitnı NIDS, ktery byna zaklade techto dat byl schopen detekovat utoky i ve vysokorychlostnıch sıtıch.
10.2 Mozna rozsırenı
Protoze protokol NetFlow je uzavreny protokol a funguje pouze na Cisco zarızenıch, jemozne pouzıt jiny standard pro monitorovanı sıte. Nabızı se pouzıt standard sFlow. Tentomonitorovacı standard je jednodussı nez protokol NetFlow. Je implementovan na vıcezarızenıch. Vetsina prepınacu tento standard podporuje a je tedy vıce rozsıreny. Dıkytomu by data mohla byt zıskavana z vıce mıst v sıti. Nevyhody standardu sFlow alepravdepodobne prevazujı. sFlow pouzıva vzorkovanı paketu. Jak bylo zmıneno v kapitole 7a 4 je toto u bezpecnostnı analyzy nezadoucı. Podle zkusenostı z praxe jsou pak zarızenı,ktere majı zapnute zaznamenavanı statistik pomocı sFlow a prochazı jimi vetsı datovy tok,velice nestabilnı. Presto je to jedna z moznostı, ktera by mohla byt uzitecna a rozsırila byfunkcionalitu tohoto projektu. Casem bude take pro sıt’ VUT dodana hardwarove akcele-rovana sonda NetFlow, pomocı ktere budou zıskavany plnohodnotna data NetFlow. Byloby tedy vhodne implementovane resenı otestovat na techto datech a doplnit zpracovanıprıznaku u paketu TCP a jednotlivych kodu u paketu ICMP. Dalsım rozsırenım by mohlobyt samostatne webove rozhranı, optimalizace algoritmu a prıpadne pouzitı algoritmu prodetekci anomaliı. Dalsım rozsırenım by mohla byt detekce utoku na odeprenı sluzby.
39
Kapitola 11
Zaver
V uvodnıch casti diplomove prace jsem se zabyval prevazne teoretickou castı. Nastudovaljsem protokol NetFlow, udaje o sonde NetFlow a seznamil jsem se s nastroji, ktere jsoupotrebne k praci s daty NetFlow. Dale jsem nastudoval problematiku skenovanı zarızenıv sıti. Seznamil jsem se s ruznymi typy skenovanı jak u protokolu TCP, tak UDP. Nut-nost byla nastudovat manualy a informace o skenovacıch nastrojıch jako je nmap, nessusa o prıstroji EtherScope. V laboratori jsem za pomoci techto nastroju a sondy NetFlowoskenoval zarızenı v sıti a analyzoval zıskane udaje ze sondy.
V prakticke casti diplomove prace jsem analyzoval data z paternı sıte VUT. Z techtodat jsem vytvoril statistiky, ktere umoznujı detailnejsı pohled na fungovanı sıte. Na zakladetechto statistik jsem implementoval sadu skriptu, dıky kterym jsem schopen v datechNetFlow detekovat pokusy o skenovanı.
Pro analyzu toku je pouzita technika pro data-mining - rozhodovacı strom.Dosazene vysledky byly konzultovany se spravcem paternı sıte VUT, byla diskutovana
omezenı, ktere vyplyvajı z praxe a byly navrzeny upravy skriptu, aby se vysledky dalyrealne vyuzıt pro zajistenı vetsı bezpecnosti sıte VUT, napr. omezenı detekovanı skenovanıpouze z vnirnı sıte.
V diplomove praci jsem dokazal i z nekompletnıch, anonymizovanych dat NetFlow de-tekovat skenovanı sıte. Ve vysokorychlostnıch sıtıch, jako je sıt’ VUT, je techto utoku velkemnozstvı. Reakce na tato skenovanı nenı trivialnı a je probrana v kapitole 10. Zpracovanızıskanych dat tedy zavisı na spravci sıte, ktery urcı dulezita data z hlediska bezpecnostidane sıte.
Detekovana skenovanı lze take pouzıt pro odhalenı skodlivych programu. Vetsina techtoprogramu pri sırenı se sıti skenuje danou podsıt’ a tato skenovanı by byla implementovanymiskripty detekovana.
Tato prace muze byt prınosem pro velke akademicke sıte nebo pro poskytovatele pripojenı,kde detekovane udaje mohou byt pouzity pro zvysenı bezpecnosti dane sıte. V kapitole 9je popsana konkretnı implementace pro sıt’ VUT. Moznosti rozsırenı jsou popsany v 10.2.
[2] Portable Gig and a/b/g wireless LAN testing, analysis and throubleshooting. [online],2006-2009, [cit. 2009-02-23].URL http://www.flukenetworks.com/etherscope
[9] HAAG, P.: Watch your Flows with NfSen and NFDUMP. [online], Kveten 2005.URL http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-nfsen-nfdump.pdf
[11] KIKUCHI, H.; FUKUNO, N.; KOBORI, T.; aj.: Automated Port-scan Classificationwith Decision Tree and Distributed Sensors. Information Processing, rocnık 16, Zarı2008: s. 165–175.
[12] Lakkaraju, K.; Yurcik, W.; Lee, A. J.: NVisionIP: netflow visualizations of systemstate for security situational awareness. In VizSEC/DMSEC ’04: Proceedings of the2004 ACM workshop on Visualization and data mining for computer security, New
York, NY, USA: ACM, 2004, ISBN 1-58113-974-8, s. 65–72,doi:http://doi.acm.org/10.1145/1029208.1029219.
[13] LEE, C. B.; ROEDEL, C.; SILENOK, E.: Detection and Characterization of PortScan Attacks. Technicka zprava, University of California, San Diego.URL http://www.cs.ucsd.edu/~clbailey/PortScans.pdf
[14] LYON, G.: Free Security Scanner For Network Exploration and Security Audits.[online], Duben 2009, [cit. 2009-05-10].URL http://nmap.org/
[15] POSTEL, J.: Transmission Control Protocol. RFC 793 (Standard), Zarı 1981,updated by RFC 3168.URL http://www.ietf.org/rfc/rfc793.txt
[16] QUINLAN, J.: Induction of Decision Trees. Mach. Learn., rocnık 1, c. 1: s. 81–106,ISSN 0885-6125, doi:http://dx.doi.org/10.1023/A:1022643204877.
[17] REHAK, M.; PECHOUCEK, M.; BARTOS, K.; aj.: CAMNEP: An intrusiondetection system for high-speed networks. Zarı 2007, s. 65–74.
[18] ROACH, C.: Building Decision Trees in Python. [online], Zarı 2006, [cit. 2009-05-10].URLhttp://www.onlamp.com/pub/a/python/2006/02/09/ai_decision_trees.html
[19] SCARFONE, K.; MELL, P.: Guide to intrusion detection and prevention systems.Technicka zprava, NIST, Unor 2007.
[20] CALIGARE s.r.o..: What is Netflow? [online], Kveten 2006, [rev. 2006-03-10],[cit. 2009-01-03].URL http://netflow.caligare.com/
[21] STEWART, J.: Windows Messenger Popup Spam on UDP Port 1026. [online],Cerven 2003, [cit. 2009-05-19].URL http://www.secureworks.com/research/threats/popup-spam/
Vystup formatu pipe je urcen k dalsımu zpracovanı jinym programem. Jednotlive polozkyjsou oddeleny |. IP adresy jsou ukladany jako 4 po sobe jdoucı 32bitova cısla. Pro IPv4adresy se pouzıva pouze poslednı 32bitove cıslo. Ostatnı jsou nastaveny na 0.
Address family PF INET or PF INET6Time first seen UNIX time secondsmsec first seen Mili seconds first seenTime last seen UNIX time secondsmsec last seen Mili seconds first seenProtocol ProtocolSrc address Src address as 4 consecutive 32bit numbers.Src port Src portDst address Dst address as 4 consecutive 32bit numbers.Dst port Dst portSrc AS Src AS numberDst AS Dst AS numberInput IF Input InterfaceOutput IF Output InterfaceTCP Flags TCP Flags
Prıklad formatu u prıznaku TCP paketu. Kazdy prıznak je reprezentovan 6-ti bity.U bitu se provede xor a vysledek se zapıse dekadicky. Takze SYN + RESET = 6
44
Prıloha B
Graficke rozhranı vytvorenenastrojem nfsen
Obrazek B.1: Hlavnı a navigacnı stranka
Obrazek B.2: Detaily grafu a pouzitı nastroje nfdump ve webovem rozhranı
45
Prıloha C
Ukazka detekce a zaznamkomunikace
V teto prıloze jsou ukazky detekovanych skenovanı. Protoze tyto udaje jsou citlive, IPadresy jsou anonymizovany. Pro lepsı orientaci ale uvadım, ze IP adresa 106.226.xxx.xxxodpovıda sıti VUT.
U ukazky komunikace jsou jednotlive zaznamy nasledujıcı:
• Datum a cas skenovanı: 2009-01-01 00:23:14.560
• Protokol: ICMP
• IP adresa utocnıka: 183.48.16.38
• Skenovana IP adresa a port: 106.226.254.42:23
• Pocet paketu v toku: 1
• Pocet prenesenych bajtu v toku: 64
C.1 Skenovana IP adresa pomocı protkolu ICMP
Tato IP adresa byla pravdepodobne skenovana pomocı protokolu ICMP. Nelze to jedno-znacne urcit, protoze data NetFlow nejsou kompletnı. U teto IP adresy se podarilo zıskatdalsı informace o danem zarızenı. Jedna se o prepınac HP ProCurve 3500 yl. Toto skenovanıbylo potvrzene spravcem sıte. Jedna se tedy o spravnou detekci.
C.2 Detekce utoku snazıcı se zneuzıt sluzbu Windows Mes-senger
Tento typ skenovanı je velice casty. Rozsah IP adres odkud pochazı toto skenovanı jepridelen organizaci pochazejıcı z Cıny. Toto skenovanı bylo take oznaceno spravcem sıtejako spravne detekovane.
Skenovanı sluzby DNS je nejcasteji se vyskytujıcım typek detekovaneho skenovanı. U tohotoprıkladu se pravdepodobne nejedna o skenovanı. IP adresa utocnıka pochazı ze sıte VUTa podle spravce sıte se jedna o pocıtacovy cluster, na kterem bezı webove servery. Je mozne,ze tyto servery majı nastaveno prevod pripojenych IP adres na DNS jmena. To by mohlozpusobit zvysene mnozstvı jednopaketovych toku.
Skenovanı teto sluzby je mene caste, nez skenovanı sluzby DNS. Presto jsou tyto detekovanespojenı dulezita. Po uspesne detekci teto sluzby je vetsı pravdepodobnost nasledneho utoku,ktery by zajistil vzdaleny prıstup k tomuto pocıtaci. IP adresa utocnıka pochazı z USA.
