Identifying P2P Users Using Traffic Analysis

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

ROZPOZNÁNÍ UŽIVATELŮ P2P SÍTÍ NA ZÁKLADĚ

ANALÝZY SÍŤOVÉHO PROVOZU

BAKALÁŘSKÁ PRÁCE

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

ROZPOZNÁNÍ UŽIVATELŮ P2P SÍTÍ NA ZÁKLADĚ

ANALÝZY SÍŤOVÉHO PROVOZU

IDENTIFYING P2P USERS USING TRAFFIC ANALYSIS

BAKALÁŘSKÁ PRÁCE

AUTOR PRÁCE

ZOLTÁN JALSOVSZKY

AUTHOR

VEDOUCÍ PRÁCE

Ing. ŽÁDNÍK MARTIN

Abstrakt

Bakalářská práce se zaobírá moţnostmi detekce uţivatelů P2P sítí jako BitTorrent, DC++, Gnutella a jiné. Byla vytvořena aplikace, schopná detekovat tyto uţivatele vícerými způsoby. Metoda kombi-nuje analýzu datové části paketu a analýzu síťového provozu a spojení, díky které je moţná přesnější detekce. Aplikace je napsána v programovacím jazyku C++, a vychází z volně dostupného nástroje L7-filter.

Abstract

Bachelor’s thesis deals with methods of detection of P2P users like BitTorrent, DC++, Gnutella and others. An application was created, which is able to detect these users using multiple ways. This me-thod combines analysis of packet payload and analysis of network traffic and flows, so more exact detection is possible. Application is written in C++ programming language, and is built on open-source tool L7-filter.

Klíčová slova

P2P, detekce, Internet, síťová komunikace, NetFlow, packet, BitTorrent, DirectConnect

Keywords

Rozpoznání uživatelů P2P sítí na základě analýzy síťového

provozu

Prohlášení

Prohlašuji, ţe jsem tuto bakalářskou práci vypracoval samostatně pod vedením Ing. Martina Ţádníka. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal.

……… Zoltán Jalsovszky 15. mája 2009

Poděkování

Tímto bych chtěl poděkovat Ing. Martinovi Ţádníkovi za poskytnutou pomoc, konzultace a trpělivost při tvorbě této bakalářské práce.

© Zoltán Jalsovszky, 2009

Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních tech-nologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je

nezákon-Obsah

1 Úvod ... 2

2 Princípy sieťovej komunikácie ... 3

2.1 Sieťové modely ... 3

2.2 PDU a systém prenosu dát ... 6

3 Peer-to-Peer ... 8

3.1 P2P ako nástroj na zdieľanie súborov ... 8

3.2 Problémy spojené s P2P ... 10

3.3 Detekcia P2P ... 10

4 Nástroj na detekciu P2P spojení ... 14

4.1 Nástroj L7-filter ... 14

4.2 Získavanie packetov ... 14

4.3 Triedenie packetov a spojení ... 17

4.4 Payload analýza ... 19

4.5 Analýza pomocou štatistík spojení ... 20

4.6 Tabuľka P2P spojení ... 22

4.7 Rozpoznanie uţívateľov samotných ... 22

4.8 Časovač ... 23

5 Testovanie nástroja ... 24

5.1 Podmienky testovania ... 24

5.2 Zisťovanie vlastností rôznych protokolov ... 25

5.3 Testovanie úspešnosti detekcie ... 27

5.4 Hardvérové nároky ... 29

6 Záver ... 30

Literatúra ... 31

Zoznam príloh ... 33

1

Úvod

V dnešnej dobe sa spôsob pouţívania internetu uberá výrazne iným smerom, neţ sa pred pár rokmi predpokladalo. Oproti minulosti, keď najväčšiu časť sieťovej prevádzky tvorili prenosy cez HTTP a FTP protokol, dnes sú komunikačné linky zaťaţené hlavne streamovaným videom a prenosmi P2P. V roku 2008 tvorilo P2P pribliţne 65% cez internet prenášaných dát [1]. Hoci sa objavili štatistiky tvrdiace, ţe toto číslo sa zmenšuje, na druhej strane sa rapídne zväčšuje podiel šifrovaných prenosov. A práve tu sa objavuje problém - stále viac P2P softvérov obsahuje moţnosť kódovania či šifrovania prenosu, čím sa znemoţňuje ich detekciu spôsobom analýzy dátovej časti paketov. Je preto potrebné tieto P2P prenosy identifikovať novým spôsobom. Ale čo je vlastne to P2P?

Obecne o P2P (Peer-to-Peer) môţeme hovoriť vtedy, ak myslíme na spojenie dvoch nezávis-lých počítačov, s vynechaním serveru. Všeobecne známe protokoly pouţívajú princíp klient-server, ktorý spočíva v tom, ţe beţný uţívateľ (klient) sa pripojí na server poskytujúci určitú sluţbu. Iniciáto-rom spojenia je vţdy klient, a najčastejšie sa jedná a komunikáciu typu otázka - odpoveď. P2P je však priame spojenie medzi dvoma uţívateľmi, pri ktorom obe strany sú rovnocenné. Takýto spôsob ko-munikácie pouţívajú rôzne programy a aplikácie, určené na audio a video hovory, prenos súborov a zdieľanie dát. Tento princíp sa taktieţ pouţíva pri hrách, konkrétne pri multiplayer móde. Táto prá-ca sa zameriava na také P2P siete, ktoré sú určené na výmenu dát medzi uţívateľmi. Tieto siete sú veľmi rozšírené, a slúţia predovšetkým na vyhľadávanie a výmenu nelegálneho obsahu (hudba, fil-my, prografil-my, hry). Práve tieto siete tvoria drvivú väčšinu P2P prevádzky. Ako príklad môţeme spomenúť u nás najčastejšie pouţívané programy ako DC++ [2] (či je ho vo väčšej miere pouţívaná, modifikovaná verzia StrongDC [3]), BitTorrent [4] alebo LimeWire [5].

Na detekciu uţívateľov P2P sietí uţ vzniklo mnoho efektívnych aj neefektívnych nástrojov. Najjednoduchší spôsob, ako tieto aplikácie identifikovať, je pomocou čísiel portov. Tento spôsob uţ ale dávno nie je účinný, nakoľko moderné aplikácie pouţívajú náhodne generované čísla portov. Druhou, ďaleko účinnejšou metódou, je analýza dátovej časti paketov. Na samotnú analýzu slúţi veľa voľne dostupných nástrojov, asi najznámejší z nich je Wireshark [6]. Ten síce rozpoznáva protokoly len na základe čísiel portov, ale poskytne nám aj podrobný prehľad o paketu vrátane payloadu. Najú-činnejším nástrojom tejto kategórie je však L7-filter [7], z ktorého aj program popísaný v tejto práci. L7-filter dokáţe identifikovať analýzou dátovej časti paketov a regulárnych výrazov veľkú časť pro-tokolov beţiacich na 7. vrstve modelu ISO/OSI, ale aj protokoly na iných vrstvách (napr. DNS). Tre-ťou, v dnešnej dobe čoraz efektívnejšou metódou je analýza sieťovej prevádzky bez analýzy payloa-du. Tu sa berú do úvahy len zdrojové/cieľové IP adresy, čísla portov a typ protokolu (TCP/UDP).

V druhej kapitole táto práca popisuje základné informácie o sieťovej komunikácii, o jednotli-vých vrstvách sieťového modelu ISO/OSI a TCP/IP. Sú vysvetlené princípy a spôsoby komunikácie počítačov pomocou paketov, rozdiely medzi protokolmi TCP a UDP. Práca sa zaoberá protokolom IPv4, novší protokol IPv6 môţe byť predmetom ďalšieho štúdia. Tretia kapitola popisuje P2P proto-koly a aplikácie, a moţné spôsoby ich detekcie. Štvrtá kapitola sa venuje aplikácii pre detekciu P2P uţívateľov, ktorá vychádza z open-source nástroja L7-filter a snaţí sa zdokonaliť detekciu kombiná-ciou analýzy payloadu a analýzy sieťovej prevádzky. Je stručne popísaný princíp fungovania nástroja L7-filter, jeho nedostatky a navrhnutý spôsob vylepšenia. Je dôkladne vysvetlený návrh implementá-cia tohto rozšírenia a spôsob funkčnosti. V piatej kapitole sa práca zaoberá s testovaním novej apliká-cie. Sú popísané rôzne moţnosti vyuţitia, rýchlosť, stabilita ako aj úspešnosť detekapliká-cie. Posledná, piata kapitola, je záver, kde je vyhodnotenie aplikácie. Sú uvedené hlavné nedostatky, výhody a návrh

2

Princípy sieťovej komunikácie

2.1

Sieťové modely

Čo je to vlastne sieť? V informačných technológiách hovoríme o sieti vtedy, keď spojíme dve alebo viac počítačov za cieľom komunikácie a výmeny dát. Tento spoj je realizovaný najčastejšie pomocou káblov, ale celkom beţné, a v súčasnosti čoraz viac preferované, je aj bezdrôtový prenos. Komuniká-cia samotná prebieha, ako je uţ vo svete počítačov zvykom, prenosom binárnych informácii pomocou elektrických impulzov (v prípade bezdrôtového prenosu sa pouţívajú rádiové vlny). Tieto „jedničky a nuly“ sú organizované do skupín, nazývaných PDU (Protocol Data Unit). Je to obecné pomenova-nie pre skupinu dát, ktoré má potom pri kaţdom protokole špecifický názov.

Pre popis sieťovej architektúry môţeme pouţiť rôzne spôsoby. Najčastejším a najefektívnejším spôsobom je však popis pomocou vrstvových modelov. Tieto modely rozdeľujú sieťovú komunikáciu do niekoľkých vrstiev. Vzniká tak jeden hierarchický systém, pri ktorom kaţdá vrstva poskytuje urči-tú sluţbu vyšším vrstvám. V praxi sa pouţívajú dve referenčné vrstvové modely. Prvým z nich ISO/OSI, ktorý rozdeľuje architektúru na sedem vrstiev, druhý je model TCP/IP.

2.1.1

Model ISO/OSI

Na modeli OSI (Open System Interconnection) začala pracovať organizácia ISO [8] v roku 1977. Cieľom bolo zjednodušiť a hlavne štandardizovať popis počítačových sietí a poskytnúť základňu pre vypracovanie noriem pre účely prepojovania systémov. V roku 1984 bol model definitívne schválený ako referenčný model. Popisuje vrstvy, ich funkcia a sluţby, ale z dôvodu jednoduchosti nezahrňuje ţiadne protokoly. ISO/OSI sa skladá zo siedmych vrstiev, ktoré sú znázornené na obrázku 2.1.

Názov vrstvy Príklad protokolu Názov jednotky PDU

Application Layer HTTP, FTP, DHCP, SMTP Data

Presentation Layer SSL, MIME, XDR, Samba Data

Session Layer Sockets, RTP, NetBIOS Data

Transport Layer TCP, UDP Segment (Packet)

Network Layer IPSec, ICMP, IGMP Datagram

Datalink Layer PPTP, L2TP, Ethernet Frame

Funkcie jednotlivých vrstiev sú nasledovné [9]:

 Aplikačná vrstva (Application Layer) komunikuje priamo s aplikáciami a programami, je najbliţšia k uţívateľovi. Zaisťuje prístup k celému komunikačnému systému a umoţňuje tak ich spoluprácu. Na tejto vrstve beţia protokoly ako HTTP (protokol pouţívaný v internetových prehliadačoch), FTP (prenos súborov), AIM (instant messaging) alebo SMTP (prenos pošty).

 Prezentačná vrstva (Presentation Layer) slúţi na transformovanie údajov do tvaru, ktorý pouţívajú aplikácie v aplikačnej vrstve. Najčastejšou úlohou tejto vrstvy je kódovanie a šifrovanie dát. Patria sem bezpečnostné protokoly ako SSL a TLS, alebo sieťové súborové systémy XDR a Samba.

 Relačná vrstva (Session Layer) organizuje a synchronizuje dialóg medzi spolupracujúcimi relačnými vrstvami dvoch systémov a riadi výmenu dát medzi nimi, slúţi tieţ na oznamova-nie výnimočných stavov a chýb. Riadia sa sem protokoly NetBIOS, RPC alebo aj RTP.  Transportná vrstva (Transport Layer) zabezpečuje spoľahlivý prenos dát medzi

jednotli-vými strojmi. Pri návrhu sa počítalo s piatimi triedami prenosov (TP0-TP4), kaţdý z nich po-skytuje iné vlastnosti. Dnes sa ale pouţívajú len dve protokoly. TCP, nazývaný aj spojovaná sluţba, poskytuje spoľahlivý prenos dát, zaručuje správne poradie doručenia paketov, je odolný voči chybám a state paketov. Zabraňuje aj zahlteniu sieťových prvkov dátami. UDP je nespojovaná sluţba, ktorá má síce menšiu hlavičku a je menej náročná na počet prenesených bitov, je nespoľahlivá a nezaisťuje ani jednu z hore uvedených vlastností ponúkaných TCP.  Sieťová vrstva (Network Layer) poskytuje hlavne smerovanie a adresovanie sieťových

prv-kov. Poskytuje spojenie medzi systémami, ktoré priamo nesusedia. Pracuje sa tu s hierarchickou štruktúrou adries. Na tejto vrstve pracuje protokol IP, ktorý tvorí základ celé-ho internetu. Môţeme sem zaradiť aj protokoly ICMP a ARP.

 Spojová vrstva (Data Link Layer) vytvára spojenie medzi dvoma susednými zariadeniami. Opravuje chyby, ktoré môţu nastať na prvej, fyzickej vrstve. Stará sa aj o adresovanie fyzic-kých zariadení. Najznámejší protokol v tejto vrstve je Ethernet, ale sem patrí aj Token Ring alebo PPP (Point-to-Point), pouţívaný pri VPN.

 Fyzická vrstva (Physical Layer) reprezentuje elektrické a fyzické špecifikácie zariadení. De-finuje vzťahy medzi zariadením a fyzickým médiom. Zariadenie pracujúce na tejto vrstve konvertujú digitálne dáta reprezentované jedničkami a nulami na elektrické signály.

2.1.2

Model TCP/IP

Model TCP/IP poskytuje zjednodušené a efektívnejšie rozdelenie do vrstiev. Jeho vývoj bol zvlášť odlišný od ISO/OSI, nakoľko tento model sa vyvíjal a v prvých niekoľko rokov fungovania sa pouţí-val na vojenské účely v USA. Tento model bol prvýkrát testovaný v roku 1975, a oficiálne sa začal pouţívať v roku 1983. Neskôr sa postupne z vojenskej siete stala verejne dostupná sieť, dnes nazýva-ná Internet. Vrstvové rozdelenie je znazýva-názornené na obrázku 2.2.

Názov vrstvy Príklad protokolu Názov PDU

Application Layer DNS, FTP, HTTP, POP3 Data

Transport Layer TCP, UDP Packet

Network Layer IPv4, IPv6, ICMP, IGMP Datagram

Link Layer ARP, NDP Frame

Obrázok 2.2: Sieťový model TCP/IP s názvami PDU

Úlohy jednotlivých vrstiev v modeli TCP/IP je sú nasledovné[10]:

 Aplikačná vrstva (Application Layer) ponúka sluţby priamo softvérovým aplikáciám a programom. Pre rozlíšenie rôznych programov sa pouţívajú porty. Kaţdý špecifický proto-kol má pridelený jeden port (napr. DNS má port s číslom 53), ktorý ale nie je pevný, a pri ur-čitých aplikáciách sa dá zmeniť. P2P aplikácie napríklad pouţívajú náhodné porty pri kaţdom spustení, aby tak zabraňovali blokovaním pomocou čísiel portov.

 Transportná vrstva (Transport Layer) poskytuje spojovanú a nespojovanú komunikáciu. Spojovaná sluţba TCP je spoľahlivá, odolná voči chybám a stratám paketov. UDP je nespo-ľahlivé, negarantuje správnosť poradia doručených paketov, a neošetruje zahltenie sieťového prvku dátami. Na druhej strane, je menej náročná na prenesené bity, lebo UPD packet má menšiu hlavičku.

 Sieťová vrstva (Internet Layer) vytvára jednotné komunikačné prostredie pre vyššie vrstvy. Zaisťuje sieťové adresovanie, smerovanie a predávanie datagramov. Na tejto vrstve pracujú protokoly ARP, ICMP, IGMP, IPSec a IP. Protokol IP delíme na staršie IPv4 a nové IPv6.

2.2

PDU a systém prenosu dát

Dáta sa po počítačovej sieti neprenášajú ako celok, ale sú rozdelené do menších častí, blokov. Toto delenie je veľmi dôleţité preto, aby sa cez jeden fyzický spoj mohlo realizovať viac - teoreticky ne-konečne veľa - logických spojení. Dáta sa prenášajú ako malé „balíky“, ktoré majú určenú presnú alebo maximálnu veľkosť. Kaţdý takýto balík, nazývaný PDU (Protocol Data Unit), obsahuje aj hla-vičku, ktorá obsahuje dôleţité informácie o tom, kam tento balík smeruje, kto je jeho odosielateľom, aká je veľkosť uţitočných dát alebo aj kontrolný súčet. Kaţdá vrstva modelu TCP/IP pridáva k exis-tujúcemu PDU svoju vlastnú hlavičku, a nezaujíma sa o informácie uloţené v hlavičkách vyšších vrstiev.

2.2.1

Transportná vrstva

K zapuzdreniu dát z uţívateľských programov dochádza na druhej vrstve sieťového modelu TCP/IP. K uţívateľským dátam sa tu pridá hlavička, ktorá obsahuje všetky potrebné informácie a zdroji, cieli ako aj typu dát. Na tejto vrstve tak vzniká packet.

+ Bits 0–3 4–7 8–15 16–18 19–31 0 Version Header length Type of Service Total Length

32 Identification Flags Fragment Offset

64 Time to Live Protocol Header Checksum

96 Source Address

128 Destination Address

160 Options

160/

192+ Data

Obrázok 2.3: Hlavička packetu protokolu TCP/IP

Tento protokol zaisťuje fragmentáciu packetov, nosí so sebou informáciu TTL (Time to Live), a čo je najdôleţitejšie, obsahuje IP adresu odosielateľa a adresáta. Táto informácia bude dôleţitá pri detekcií P2P aplikácii pomocou analýzy sieťovej prevádzky. Kaţdá dátová jednotka PDU tejto vrstvy môţe obsahovať TCP alebo UDP packet, ktoré sú stručne popísané niţšie.

2.2.2

Protokol TCP

Protokol TCP, ako uţ bolo spomenuté vyššie, poskytuje spojovaný prenos medzi dvoma stanicami. Zaručuje doručenie a správne poradie packetov. Komunikácia sa nadväzuje pomocou metódy tzv.

Three-way handshake. Tá spočíva v tom, ţe stanica, ktorá iniciuje spojenie, pošle packet s príznakom

SYN. Adresát odpovie packetom SYN-ACK, na záver iniciátor odošle packet ACK. Tým je TCP spojenie naviazané, a môţe začať prenos dát. Kaţdý packet sa potvrdzuje packetom ACK. Veľká väčšina P2P programov a protokolov pouţíva práve TCP. Najdôleţitejšia časť, ktorá nás bude zaují-mať pri analýze a detekovania P2P spojení, je zdrojový a cieľový port, ako aj príznaky (predovšetkým SYN, FIN a RST). Časť Data, nazývaná tieţ Payload, obsahuje samotné čisté dáta vyššej vrstvy, a pomáha nám pri detekcií P2P metódou analýzy payloadu.

+ Bits 0–3 4–7 8–15 16–31

0 Source port Destination port

32 Sequence number

64 Acknowledgment number

96 Data offset Reserved CWR ECE URG ACK PSH RST SYN FIN Window Size

128 Checksum Urgent pointer

160 Options (optional)

160/

192+ Data

Obrázok 2.4: Hlavička protokolu TCP

2.2.3

Protokol UDP

Protokol UDP je alternatívou k TCP. Poskytuje nespojovaný prenos dát. Jeho dátová náročnosť je vďaka menšej hlavičke niţšia, ale neposkytuje ţiadnu záruku, ţe bude packet doručený a v správnom poradí. Niektoré P2P programy v poslednej dobe uţ pouţívajú pre svoje potreby aj UDP protokol, a zabezpečenie dát riešia na vyšších vrstvách. Časť Data je rovnaká ako pri protokole TCP, obsahuje teda dáta vyššej vrstvy.

+ Bits 0 - 15 16 - 31

0 Source Port Destination Port

32 Length Checksum

64 Data

3

Peer-to-Peer

3.1

P2P ako nástroj na zdieľanie súborov

Po rýchlom rozšírení počítačom v 90tich rokoch a na začiatku 21. storočia, ľudia začali pociťovať potrebu vymieňať medzi sebou súbory. Spočiatku sa jednalo o dokumenty, hudbu, neskôr so zrýchle-ním internetového pripojenia aj filmy a hry. Najprv sa pouţívali výkonné servery, ktoré tento obsah uchovávali, a poskytovali ostatným ľudom. So zvyšujúcim sa počtom pouţívateľom o zvýšenému objemu prenesených dát sa ale vyskytol problém s kapacitou serverov. Problémom bolo aj to, ţe tieto servery často obsahovali nelegálny obsah, hlavne hudbu a filmy. Riešením je sieť rovnocenných počí-tačov pouţívateľov - Peer-To-Peer (skrátene P2P). Pri jednotlivých sieťach sa stále pouţívajú cen-trálne servery, ale tie hrajú uţ len synchronizačnú a indexovaciu funkciu. Záťaţ a sieťová prevádzka sa teda rozloţí medzi uţívateľmi daného programu / protokolu.

Myšlienka takéhoto distribuovania súborov je síce revolučným prínosom, na druhej strane sa však po čase objavili určité problémy. Najváţnejší problém a negatívny prínos systému P2P pociťujú poskytovatelia internetového pripojenia. Objem prenesených dát v ich sieťach sa kaţdým mesiacom zvyšuje, a do rozširovania kapacity a posilňovania infraštruktúry investujú nemalé peniaze [11]. Prvým pokusom o P2P systém na zdieľanie súborov bol Napster, ktorý bol vytvorený v roku 1999, a ponúkal vyhľadávanie a sťahovanie MP3 súborov. Nasledovníkom bol veľmi úspešná Gnutella, ktorá existuje dodnes. Na základe úspechov týchto programov sa neskôr sa objavili ďalšie, ako

eDon-key2000, Kazaa, FastTrack, LimeWire, BearShare, DirectConnect a BitTorent. Táto práca sa

sústre-ďuje v súčasnosti najviac pouţívaným P2P programom v našich krajinách, a to BitTorrent, Direc-tConnect a Gnutella.

3.1.1

DirectConnect

DirectConnect je u nás druhý najpouţívanejší P2P protokol pre zdieľanie súborov medzi uţívateľmi. Poskytuje vyhľadávanie a sťahovanie súborov od iných uţívateľov a textový chat. Funguje na princí-pe tzv. HUB-ov, ktoré sú servery, na ktoré sa jednotlivý uţívatelia pripájajú. Server zohráva len úlohu sprostredkovateľa, nenachádzajú sa na ňom ţiadne informácie o zdieľaných súboroch. Poskytuje tieţ textový chat, privátne správy, a obsahuje zoznam uţívateľov, ktorí sú aktuálne pripojení na server. Klienti aţ do momentu začatia sťahovania nekomunikujú so sebou priamo, ale cez server. Ten je sprostredkovateľom vo vyhľadávaní, v posielaní správ, a pomáha klientom nadviazať medzi sebou spojenie. Princípom spočiatku bolo, ţe jeden klient môţe sťahovať jeden súbor len od jedného uţíva-teľa, príchodom novších klientov sa však uţ čoraz viac uplatňuje tzv. segmentované sťahovanie, ktoré umoţní prijímať jeden súbor z viacerých zdrojov. Takto sa výrazne zvýši rýchlosť a čas potrebný na stiahnutie súboru, ale nastáva problém s obsedenými slotmi, nakoľko v prípade klasického sťahovania obsadím jeden slot, pri segmentovanom to môţe byť viac. Kaţdý uţívateľ má pritom nastavený určitý počet slotov na odosielanie súboru, pri ich obsadení neprijíma ţiadne spojenia na odosielanie súboru. Najčastejšími pouţívanými klientmi sú DC++, StrongDC++ a CzDC.

3.1.2

BitTorrent

V dnešnej dobe najvyspelejší a najpouţívanejší P2P protokol vznikol v roku 2001 ako dielo progra-mátora Bram Cohen [12]. Je oveľa efektívnejší, neţ hore uvedený DirectConnect, a dosahuje vyššie prenosové rýchlosti. V súčasnosti BitTorrent prenosy tvoria aţ 56,54% celkovej internetovej pre-vádzky vo východnej Európe [1], [13]. Ako väčšina P2P protokolov, aj BitTorrent sa spolieha na riadiaci server, nazývaný tracker. Ten obsahuje torrent súbory, ktoré nesú také informácie o zdieľanom obsahu, ako názvy súborov, veľkosť, SHA1 kontrolný súčet a adresu trackeru. Klienti si na začiatku stiahnu torrent súbor, ktorý je len niekoľko kilobajtov veľký. P2P program sa po tom pripojí na tracker určený v torrent súbore, a získa informácie o ostatných klientoch. Klienti, pouţíva-telia sa u BitTorrentu delia na dve veľké skupiny. Prvú skupinu tí, ktorý uţ majú stiahnutý celý súbor alebo súbory, a uţ len umoţňujú ostatným sťahovanie od nich. BitTorrent ich označuje výrazom

see-der. Druhá skupina, ktorá ešte sťahovanie súborov dokončené nemá, sa označuje slovom leecher.

Čiţe kaţdý uţívateľ, ktorí začne sťahovať určitý súbor, alebo skupinu súborov, je leecher aţ do mo-mentu, keď bude mať u seba k dispozícii 100 % celého súboru/súborov popísaného v danom torrente. Najväčší rozdiel oproti DirectConnectu je fakt, ţe BitTorrent jeden súbor nesťahuje len od jedného uţívateľa, ale implicitne od viacerých. Torrenty, ktoré môţu pozostávať z viacerých súborov alebo aj adresárov, delí na menšie časti, tzv. bloky. Bloky nesťahuje za sebou, ale v náhodnom poradí, alebo podľa dostupnosti. Podporuje tieţ šifrovanie prenosu, ale táto funkcia je aktivovaná len u malého percenta uţívateľov. Je oveľa odolnejší voči výpadku riadiaceho serveru, nakoľko ten pouţíva len na načítanie zoznamu uţívateľov. Spojenie s inými klientmi sa uţ nadväzuje bez asistencie trackera. Môţeme tu teda očakávať oveľa väčší počet neúspešných spojení, nakoľko nový zoznam uţívateľov sa sťahuje zo trackeru len kaţdých 15 alebo 30 minút. Pouţívaní klienti sú: rovnomenný BitTorrent, Azureus, uTorrent a veľa ďalších.

3.1.3

Gnutella

Protolok Gnutella, vyvinutý v roku 2000, bol najúspešnejším protokolom v roku 2007 na svete. Dnes uţ ale jeho podiel klesá [1], a protokol je zastaraný. Tento protokol pouţíva pomerne veľa progra-mov, napr. LimeWire, BearShare a Shareaza, ktoré podporujú rôzne funkcie. Na rozdiel od hore uve-dených je v plnej miere decentralizovaná, nepouţíva ţiadne riadiace servery. Nedá sa preto odstave-ním centrálnych serverov odstaviť celá sieť. Nový klient sa pripája na predom definované vstupné body do siete. Hľadania prebiehajú rekurzívne, ale nedostanú sa ku kaţdému pouţívateľovi siete, lebo otázka sa zahodí po 7-8 prechodoch cez uzly. Protokol podporuje aj uţívateľov za bránou firewall, keďţe umoţňuje push správy, cez ktoré informuje vzdialeného klienta za bránou firewall, ţe od neho chce stiahnuť súbor, a ten sa následne pripojí na iniciátora. Zaviedol sa aj pojem ultrapeers, ktorým sa označujú uţívatelia, ktorí prenášajú poţiadavky na hľadanie a na riadenie siete. Okrajoví uţívate-lia, tzv. leaves, takúto funkciu nemajú. Za ultrapeera je obvykle vyhlásený uzol, ktorý disponuje veľ-mi rýchlym internetovým pripojením. Toto správanie, ako aj protokol Gnutella je podrobne analyzo-vaný v [14].

3.2

Problémy spojené s P2P

Výmena súborov cez P2P aplikácie sa stala počas niekoľkých rokov veľmi populárnou, a začala zabe-rať veľkú časť internetovej prevádzky. Objem prenesených dát cez siete poskytovateľov internetové-ho pripojenia začala neúnosne rásť, a rýchlo sa dosiahli limity kapacít týchto sietí. Poskytovatelia samozrejme investujú kaţdý rok obrovské mnoţstvo peňazí do rozširovania kapacít svojich sietí, ale ukázala sa potreba hľadať aj iné cesty. Jedným z riešení je aj obmedzovanie P2P prevádzky v sieťach. Je to pomerne lacné riešenie, ako ušetriť kapacity, realizovanie je však uţ náročnejšie. V súvislosti s tým treba spomenúť aj fakt, ţe uţívatelia si vymieňajú prostredníctvom P2P sietí predovšetkým nelegálny obsah (filmy, hudbu, hry, software), a legálny obsah tvorí len zanedbateľnú časť prenese-ných dát. Na druhej strane, zasahovanie do sieťovej prevádzky je v rozpore s jedným zo základprenese-ných myšlienok internetu, a so slobodou (tj. kaţdý si môţe prenášať, čo chce). Pre poskytovateľov hrozí aj riziko, ţe po zablokovaní P2P aplikácii na ich sieťach, alebo ba aj obmedzovaním rýchlosti, uţívatelia si radšej vyberú konkurenčného poskytovateľa, ktoré svoje sluţby nijako neobmedzuje. Napriek tomu túto stratégiu si vyberá stále viac poskytovateľov, takţe v súčasnosti zdokonaľovanie techniky detek-cie P2P aplikácii je rovnako dôleţité (ak nie ešte dôleţitejšie), ako v minulosti.

3.3

Detekcia P2P

Aby sme mohli úspešne blokovať, či obmedzovať P2P spojenia, je najprv nutné tieto spojenia, a tak aj packety, rozlišovať od zvyšku dátovej prevádzky. Toto rozdelenie môţeme dosiahnuť tromi spô-sobmi: pomocou čísiel portov, s analýzou payloadu a na základe analýzy sieťovej prevádzky. Kaţdý z týchto metód má svoje klady aj zápory, podrobne je kaţdá metóda popísaná niţšie. Pri detekcii - je popri snahe dosiahnuť čím vyššie percento identifikovaných P2P spojení - je veľmi dôleţité dbať aj na to, aby sme minimalizovali počet falošne identifikovaných spojení (false positives). Tieto spojenia v skutočnosti nie sú P2P spojenia (môţe ísť napr. o DNS, Skype, streamované video, ktoré vykazujú podobné vlastnosti ako P2P), ale nástroj na detekciu ich označil za P2P a následne sú blokované alebo je obmedzená rýchlosť ich dátového toku.

3.3.1

Detekcia pomocou čísiel portov

Najstaršou a najjednoduchšou metódou detekcie a blokovania P2P programov je metóda pouţívajúca špecifické čísla portov určitých aplikácii. V minulosti to bol najúčinnejší spôsob detekcie, v dnešnej dobe je však skoro nepouţiteľná. Prvé P2P programy ako Napster, Gnutella a iné, pouţívali pre svoje potreby pevne dané čísla portov. V tabuľke 3.1 sa nachádzajú predvolené čísla portov niektorých najznámejších P2P programov. V tomto prípade teda stačí, ak sa pozrieme na TCP alebo UDP packet a zistíme čísla portu. Ak zdrojový alebo cieľový port je známy port pouţívaný P2P aplikáciu, uţ vie-me, ţe packet je súčasťou daného P2P spojenia a môţeme ho blokovať. Najslabšou stránkou tejto ochrany je fakt, ţe dnešné P2P aplikácie dovoľujú uţívateľovi zmeniť číslo portu na hocijaké číslo, a tak v podstate nie je moţné rozpoznať P2P protokol len na základe analýzy portov. Najnovšie verzie programov dokonca pouţívajú náhodne generované číslo portu predvolene, alebo sa maskujú takým spôsobom, ţe pouţívajú vyhradené porty pre iné, široko vyuţívané sluţby (napr. 80 pre HTTP, 443 pre HTTPS alebo 21 pre FTP).

Protokol Čísla portov Kazaa/Morpheus 1214 Gnutella 6346-6347 WinMX 6257 (TCP), 6699 (UDP) Direct Connect 411-412 BitTorrent 6881–6900, 6970-6999, 30301

Tabuľka 3.1: Predvolené čísla portov najznámejších P2P aplikácii

3.3.2

Detekcia pomocou payloadu

Táto metóda spočíva v analyzovaní samotných uţívateľských dát v packete. Je to oveľa účinnejšia a presnejšia metóda, ako detekcia pomocou portov. Vyţaduje však značný výpočtový čas, nakoľko sa musí prehľadať celý payload packetu a porovnať so šablónami. Metódami tohto typu sa zaoberá [15] ako aj [16]. Tento spôsob analýzy sa spolieha na to, ţe kaţdý typ P2P protokolu pouţíva špecifické textové reťazce v komunikácii. V tabuľke 3.2 sú uvedené reťazce charakterizujúce najznámejšie P2P protokoly. Tieto reťazce sú odchytené v hociktorom packete spojenia, po tom sa môţe celé spojenie označiť ako P2P spojenie. Najznámejší nástroj, ktorý vyuţíva tento princíp, je L7-filter [7]. Ten slúţi nielen na odhaľovanie P2P protokolov, ale aj na detekciu ostatných ako HTTP, SSH, FTP a iné. Práve z tohto nástroja vychádza aj program, ktorý táto práca opisuje.

Protokol Špecifické reťazce

BitTorrent „GET /announce?info_hash“, „GET /torrents/“, „GET TrackPack“ „0x13BitTorrent“

Gnutella „GNUTELLA“, „GET /uri-res/“, „X-Gnutel“, „GET /get/“ Direct Connect $Send, $Search, $Connect, $Get, $MyInfo, $MyNick, $Key,

$Hello, $Quit, $Direction, $Lock, $Pin Fasttrack GET /.hash, „GIVE“

Tabuľka 3.2: Špecifické reťazce charakterizujúce niektoré P2P protokoly

Táto metóda je dodnes najpouţívanejšou, avšak má svoje slabé stránky. Jedným z nich je, ţe sa kvôli kontrole obsahu kaţdého packetu vyţaduje značný výpočtový výkon. Dnešné výkonné počítače však uţ zvládajú takúto kontrolu rýchlosťou rádovo niekoľko GB/s. Väčší problém, ktorý sa prejavuje čím ďalej, tým viac, je nová schopnosť P2P klientov a aplikácii šifrovať prenosy. Klienti si medzi sebou vytvoria napríklad SSL spojenia, a všetky dáta aj riadiace príkazy prenášajú šifrovane. Tento

3.3.3

Detekcia na základe analýzy sieťovej prevádzky

Tento spôsob detekcie je najnovšou, ale aj najzloţitejšou metódou detekcie P2P protokolov. Jeho podstatou je, ţe na detekciu nepouţíva payload, čiţe dátovú časť packetu, ale štatistiky pripojení (flow statictics). Dôleţité parametre pri tejto analýze sú:

 Čísla portov a spôsob ich pouţívania  Zdrojové a cieľové IP adresy

 Protokol (TCP/UDP)  Veľkosť packetov

 Prijaté packety za sekundu  Rýchlosť prenosu dát

 Úspešné / neúspešné spojenia

Pouţitie tejto metódy má svoje výhody ale aj nevýhody. Medzi prínosy patrí predovšetkým fakt, ţe táto metóda je schopná detekovať aj kódované prenosy najnovších P2P aplikácii, čo nemô-ţeme povedať o predchádzajúcich dvoch metódach. Ďalšou pozitívnou stránkou tejto metódy je to, ţe nakoľko nečíta uţívateľské dáta z packetov, uţívatelia nemusia mať strach z narušenia ich súkromia. Nevýhodou však je, ţe je veľmi ťaţké odhadnúť špecifické správanie P2P aplikácii. Kaţdá P2P apli-kácia sa z tejto stránky správa odlišne, hoci vykazujú určité znaky podobnosti. Ešte väčším problé-mom je, ţe veľa aplikácii, ktoré neslúţia na zdieľanie súborov, pouţívajú tieţ P2P architektúru, a správajú sa veľmi podobne ako aplikácie slúţiace na zdieľanie súborov. Môţe tak veľmi často dôjsť k nesprávnemu označeniu programov slúţiacich na iné účely, neţ na zdieľanie súborov. Medzi takých programov patrí predovšetkým Skype a rôzne VoIP aplikácie, ako aj P2P TV a iné P2P video preno-sy. Popri tom sa správanie aplikácii stále mení kaţdou verziou, a môţe sa aj meniť závisle od zahlte-nia siete alebo dostupnosťou sťahovaného súboru (predovšetkým BitTorrent). Napriek tomu v budúcnosti bude táto metóda jedinou pouţiteľnou, za predpokladu, ţe kaţdá P2P aplikácia imple-mentuje (a bude aj predvolene pouţívať) nejakú formu šifrovaného prenosu. Detekciou pomocou štatistík spojenia sa zaoberali viacerí, niektoré informácie sú čerpané z [17], [18], [19] a [20].

Spoločné vlastnosti P2P protokolov:  Obojsmerné spojenia

Myšlienkou systému P2P na zdieľanie súborov je dať a dostať. Kaţdý uţívateľ, ktorý niečo sťahuje od iných uţívateľov, ponúkne niečo iné ostatným, ktorí tento súbor od neho sťahujú. Všetky P2P aplikácie majú niečo spoločného: stiahne sa podobne veľké mnoţstvo dát, ako sa aj odošle. Znamená to, ţe dáta v spojení tečú oboma smermi, alebo sa otvorí nové spojenie, kde bude prevaha odosielaných dát smerom od uţívateľa.

 Súčasné používanie TCP aj UDP protokolu

Väčšina P2P aplikácii pouţíva pre svoje potreby TCP aj UDP súčasne. U BitTorrentu sa na-príklad pouţíva UDP na kontaktovanie ostatných uţívateľov, u DirectConnectu na doručova-nie výsledkov hľadania. U oboch prípadoch sa na samotný prenos pouţíva TCP, hoci v naj-novších verziách aplikácii pre BitTorrent sa experimentuje aj s prenosmi cez UDP.

 Veľký počet neúspešných spojení

Táto vlastnosť je dôsledkom toho, ţe na rozdiel od serverov, uţívatelia si svoje počítače stále vypínajú a zapínajú, takisto ako aj samotné aplikácie na zdieľanie súborov. Dôsledkom je, ţe ostatní uţívatelia sa pokúšajú kontaktovať uţ nedostupného uţívateľa ešte nejaký čas po jeho odpojení. Počas písania a testovania nástroja, ktorým sa táto práca zaoberá, som zistil, ţe v prípade BitTorrentu prichádzali poţiadavky na pripojenie aj 3 dni po poslednom pouţití BitTorrent klienta.

 Maximálne veľkosti packetov

Ak je to moţné, P2P aplikácie sa snaţia pouţívať čo najväčšiu veľkosť packetov (v prvom rade TCP, nakoľko práve TCP pouţívajú k prenosu samotných súborov). Rôzne programy pouţívajú síce rozdielne maximálne veľkosti, rozdiel je ale len niekoľko bajtov, a obvykle sa táto hodnota pohybuje nad 1400 bajtov payloadu. Kľúčovým je fakt, ţe napr. VoIP programy a ani Skype, tak ako ani online hry nebudú pouţívať k prenosu packety maximálnej veľkosti, a to kvôli zabezpečeniu dostatočnej odozvy.

 Čísla portov nad 1024

P2P programy síce pouţívajú pre svoje potreby náhodné čísla portov, okrem ojedinelých vý-nimiek ale tieto čísla sú vţdy väčšie ako 1024. Môţe to teda byť návodom k vylúčeniu ne-správneho identifikovania niektorých sluţieb ako P2P, ktoré beţia na štandardných portoch menších neţ 1024, a v skutočnosti P2P aplikáciami nie sú (DNS, SMTP, SSH a ďalší).

4

Nástroj na detekciu P2P spojení

Všetky tri hore uvedené spôsoby detekcie P2P prevádzky majú svoje výhody ale aj nevýhody. Vy-značujú sa účinnosťou pre určitý typ P2P spojení, ale na iné sú nedostatočne účinné, alebo oVy-značujú za P2P aj spojenia, ktoré v skutočnosti nie sú. Bolo by teda účinné tieto metódy kombinovať, a vytvo-riť tak nástroj, ktorý spája pozitívne vlastnosti týchto metód. Program je upravenou verziou nástroja L7-filter, ktorý je predstavený niţšie. Detailný popis programu nasleduje ďalej v kapitole 4.1.

4.1

Nástroj L7-filter

Voľne dostupný nástroj L7-filter [7] slúţi na klasifikovanie packetov sieťovej prevádzky. Dokáţe detekovať všetky najpouţívanejšie protokoly siedmej vrstvy ISO/OSI, vrátane P2P protokolov. Pou-ţíva metódu analýzy payloadu, opísanú v kapitole 3.3.2. Obsah packetov kontroluje pomocou šablón, ktoré fungujú plug-in systémom a môţu sa ľubovoľne doplňovať, upravovať alebo odstraňovať. Kaţ-dá šablóna je v podstate regulárny výraz, ktorý opisuje špecifický textový reťazec v packetoch daného protokolu. Po detekovaní nejakého známeho protokolu, sa packet označí známkou, ktorá definuje, o aký protokol sa jedná. Touto známkou sa potom označuje kaţdý packet, ktorý patrí do daného spo-jenia. Známka v packete sa potom dá vyuţiť na blokovanie packetov, na upravovanie šírky pásma (tzv. shaping), alebo na jednoduché sledovanie prevádzky a triedenie packetov za účelom vytvárania štatistík.

Nástroj L7-filter je dostupný na stiahnutie v dvoch verziách. Prvá, štandardná verzia (označo-vaná Kernel Version), sa ako pouţíva ako súčasť linuxového jadra, je ho preto potrebné pred pouţitím skompilovať do jadra systému, spolu s upravujúcimi modifikáciami. Táto verzia sa vyvíja od začiat-ku, je spoľahlivejšia a rýchlejšia, avšak jeho inštalácia je zloţitá a pre neskúsených uţívateľov nebez-pečná, práve kvôli nutnosti kompilovať jadro Linuxu. Druhá, novšia verzia (Userspace Version), sa pouţíva v štandardnom uţívateľskom prostredí bez kompilácie jadra. Komunikáciu s jadrom zaisťujú moduly jadra libnetfilter_netlink a libnetfilter_queue. Táto verzia je pre beţného uţívateľa dostupnejšia, je ale stále v začiatkoch svojho vývoja. Jeho inštalácia sa môţe zdať na prvý pohľad jednoduchou, podľa mojich skúseností ale zaberie v skutočnosti viac času, ako inštalácia predchádzajúcej verzie, nakoľko je potreba najprv nainštalovať rôzne kniţnice, vrátane uţ spomínanej kniţnice libnetfilter, ktoré sú často ťaţko dostupné, a sami sú závislí na ďalších kniţniciach. Napriek tomu má táto verzia väčšiu budúcnosť, nakoľko je moţné vypracovať jednoduchší inštalačný systém. Aj preto som vybral práve verziu fungujúcu v uţívateľskom prostredí, ako základ tejto baka-lárskej práce. Jeho funkčnosť je mnohými kritizovaná, počas môjho testovania ale fungovala stabilne a dosahovala takmer 100%-né výsledky u známych protokolov, vrátane P2P. Pouţitá bola najnovšia verzia 2.11, uvoľnená 27. februára 2009.

4.2

Získavanie packetov

Ako uţ bolo spomenuté vyššie, nástroj na rozpoznanie P2P beţí v uţívateľskom prostredí Linuxu, a nie v jadre. Je preto potrebné všetky packety nejakým spôsobom dostať do uţívateľského prostre-dia, a po klasifikácii ich poslať späť na ich pôvodnú cestu. Táto operácia síce spôsobí určité meškanie packetov, ale dáva do rúk programátora oveľa efektívnejší spôsob na odchytávanie packetov, a na

4.2.1

Netfilter

Na získavanie packetov a informácii o spojeniach boli pouţité dva moduly zo stránky Netfilter-u [21]. Tieto moduly sú taktieţ potrebné pre beh jadra L7-filteru, ktorý sa pouţil ako základ. Prvým z modu-lov je libnetfilter_conntrack. Slúţi na odosielanie informácii do uţívateľského priestoru o zmenách stavov všetkých spojení. V programe sa pouţíva zahrnutím hlavičkových súborov linux/netfilter.h a libnetfilter_conntrack/libnetfilter_conntrack.h. Na prácu so spojeniami slúţia štruktúry typu nfct_connctrack a nfct_handle. Prichádzajúce udalosti sú spracované v triede p2p_conntrack, vo funkcii p2p_handle_conntrack_event(). Ako prvé sa skontroluje, o aký protokol sa jedná. Zaoberáme sa len protokolmi TCP a UDP, ostatné pri analýze P2P prevádzky nemajú ţiadnu dôleţitosť. V ďalšom kroku sa rozhodne o postupe podľa toho, o aký typ udalosti sa jedná:

 NFCT_MSG_NEW

Tento typ správy nás informuje, ţe sa zaznamenalo nové spojenie. Pri TCP sa táto informácia objaví z neznámych dôvodov aţ nejaký čas po detekovaní prvého packetu v spojení, táto vlastnosť je nezmenene pouţívaná aj v nástroji L7-filter. Toto správanie ale znemoţňuje de-tekovanie neúspešných spojení, ktoré neobsahujú nič iné, okrem prvého SYN packetu odo-slaným zdrojom spojenia. Preto je nutné toto chovanie upraviť, a nové spojenia detekovať aj podľa prvého packetu. Keďţe táto správa neskôr, ale predsa príde, a dané spojenie uţ máme zaregistrované, správa sa zahodí a na výstup je vypísaná informácia o tomto fakte. Je to štan-dardné správanie nástroja, a nie je to chybou, práve naopak, pomocou toho sa dajú presnejšie merať neúspešné spojenia, a tak je moţný aj spoľahlivejšie rozpoznanie P2P klientov.

 NFCT_MSG_UPDATE

Informuje o nejakej zmene v stave spojenia. Najčastejšie sa jedná o nový prichádzajúci alebo odchádzajúci packet, alebo o stave, keď sa jedna strana pokúsi spojenie zavrieť. Túto infor-máciu však tento nástroj nevyuţíva, nakoľko nové packety sú odchytené iným spôsobom.  NFCT_MSG_UNKOWN

Znamená, ţe nevieme, v akom stave spojenie je. Najčastejšie sa jedná o chybu, ktorá sa ale počas niekoľkomesačného testovania neobjavila ani raz.

 NFCT_MSG_DESTROY

Je pre nás tá najdôleţitejšia správa. Informuje, ţe dané spojenie bolo aktívne zavreté, alebo nastal timeout spojenia v dôsledku nečinnosti, ktoré bolo následne zrušené. Nakoľko sa berú do úvahy aj UDP spojenia, ktoré vlastne spojeniami v skutočnosti nie sú, táto správa sa posie-la po určitom čase po poslednom UDP packete na cieľovú / zdrojovú IP adresu. Tento čas zá-visí hlavne od operačného systému, obvykle sa pohybuje od 30 do 180 sekúnd. Počas testo-vania sa ukázalo, ţe tento čas bol 60 sekúnd na notebooku, kde bol nástroj nainštalovaný.

Informácia Spôsob získania Popis

char ip_protocol = data[9]; Protokol (IPROTO_TCP

alebo IPROTO_UDP)

char * src_addr sprintf(src_addr,"%d.%d.%d.%d",data[12],

data[13], data[14], data[15]); Zdrojová IP adresa char * dst_addr sprintf(dst_addr,"%d.%d.%d.%d",data[16],

data[17], data[18], data[19]); Cieľová IP adresa char src_port = data[ip_hl]*256+data[ip_hl+1]; Zdrojový port

char dst_port = data[ip_hl+2]*256+data[ip_hl+3]; Cieľový port

char * payload = (char*)(data + app_data_offset((const _{unsigned char*)data));} Uţívateľské dáta v packete

Tabuľka 4.1: Spôsob získania informácii z dát netfilteru

4.2.2

Presmerovanie packetov

Na to, aby packety prúdili cez uţívateľské rozhranie, potrebujeme hore uvedené moduly jadra načí-tať, a packety presmerovať pomocou iptables. Načítanie modulov sa realizuje nasledovnými príkaz-mi:

modprobe nf_conntrack_netlink – informácie o spojeniach modprobe nf_conntrack_ipv4 – IPv4 packety

Ďalej je potrebné nastaviť presmerovanie packetov do uţívateľského rozhrania (QUEUE) po-mocou iptables:

iptables -A INPUT -j QUEUE – prichádzajúce packety iptables -A OUTPUT -j QUEUE – odchádzajúce packety

iptables - A FORWARD -j QUEUE – packety prechádzajúce cez NAT

Samozrejme nie je potrebné presmerovať kaţdý smer packetov, napr. ak chceme analyzovať len dáta prechádzajúce cez zariadenie, pouţijeme len posledný príkaz. Tieto príkazy je ale potrebné previesť po kaţdom reštarte počítača alebo smerovača.

4.3

Triedenie packetov a spojení

4.3.1

Spôsob spracovania packetov

Po odchytení packetu, ktoré bolo popísané v kapitole 4.2, ich treba zaradiť do príslušného spojenia. Pre správnu identifikáciu sa pre kaţdý packet a pre kaţdé spojenie vygeneruje reťazec maximálnej dĺţky 255 znakov, ktorý je unikátny pre kaţdé spojenie. Obsahuje typ a číslo protokolu, zdrojovú a cieľovú IP adresu, ako aj zdrojový a cieľový port. Spôsob získania údajov bol popísaný v kapitole 4.2.1. Po vygenerovaní kľúča sa vyhľadá v tabuľke príslušné spojenie, do ktorého packet patrí. V prípade, ţe sa spojenie nenašlo, môţe sa stať, ţe packet prichádza nie od iniciátora spojenia, ale od cieľa (je vlastne odpoveďou). V tom prípade sa pouţije druhý kľúč, ktorý sa vygeneroval spolu s prvým, na základe obrátených zdrojových a cieľových adries, ako aj portov. Ak sa spojenie nenašlo ani na základe obráteného kľúča, jedná sa o prvý packet v spojení. Tu nastáva situácia, keď prvý pac-ket príde skôr, ako informácia o novom spojení. Ako bolo popísané vyššie, pre zamedzenie stratenia prvého packetu sa preto nové spojenie zapíše do tabuľky uţ pri príchode prvého packetu, na základe informácii z packetu. Po tom, čo sa v tabuľke spojení vytvorilo nové spojenie, pokračuje sa ďalej tak, ako keby sa spojenie našlo na základe prvého kľúča. Navýši sa počítadlo packetov v spojení, a skontrolujú sa tzv. „známky“, ktoré nosia informácie o tom, či je spojenie povaţované za P2P spo-jenie, alebo nie. Sú to bezznamienkové celé čísla (okrem známky štatistík, ktoré je typu float), ktoré sa môţe počas spojenia viackrát meniť. Jedno spojenie nosí so sebou celkovo 3 známky:

 Známka payload analýzy

Táto známka udáva, či payload analýza rozpoznala spojenie ako P2P, alebo (zatiaľ) nie. Táto známka, ak je väčšia alebo rovná, neţ 5 informuje, ţe spojenie bolo rozpoznané ako P2P. Čís-lo známky udáva, ktorý P2P protokol bol na základe payČís-load analýzy rozpoznaný. Táto známka sa po nadobudnutí hodnotu väčšej neţ 5 nemení, a zároveň v tom prípade sa vypína aj payload analýza.

 Známka analýzy štatistík spojení

Slúţi hodnotenie pravdepodobnosti, ţe spojenie je P2P spojením. Môţe mať hodnoty od 0 do 10. Čím vyššia je táto hodnota, tým je pravdepodobnejšie, ţe sa jedná o P2P spojenie. Prah, podľa ktorého sa rozhodne o zaradení do kategórie P2P, je nastaviteľný parametrom progra-mu.

 Celková známka

Je to kombinácia predchádzajúcich dvoch známok. V prípadoch, ţe je povolená aj payload analýza, aj analýza štatistík, celková známky hodnotí spojenie ako P2P len vtedy, ak tak hod-notia aj predchádzajúce dve známky. Ak je povolená len payload analýza, celková známka kopíruje známku payload analýzy. Ak je povolená len analýza štatistík, celková známka môţe mať len dve hodnoty - buď je spojenie rozpoznané ako P2P, alebo ako iné spojenie. Celková známka sa pouţíva aj na označovanie packetov, ktoré patria do určitého spojenia. Toto

ozna-Kaţdá známka má navyše 5 špeciálnych hodnôt, ktoré pomáhajú pri analýze:

 NO_MATCH Ţiadna zhoda sa nenašla, ďalšia analýza zastavená  UNTOUCHED Zatiaľ nekontrolované ţiadnou metódou

(pozostatok z L7-filtra, nepouţíva sa)  NO_MATCH_YET Zatiaľ ţiadna zhoda, kontrola pokračuje

 FLOW_MATCH Analýza štatistík spojení označila spojenie / packet ako P2P  PAYLOAD_MATCH Payload analýza označila spojenie / packet ako P2P

Ak sa zistí, ţe spojenie je uţ označené celkovou známkou ako P2P, tak kaţdý packet, ktorý patrí do tohto spojenia, dostane rovnakú známku, a analýza sa uţ nevykonáva. V prípade, ţe chýba známka jedného z metód analýz, prevedie sa len tá analýza, ktorá zatiaľ neoznačila spojenie ako P2P. Výnimkou je analýza štatistík, ktorá sa v prípade malého mnoţstva informácii môţe previesť znovu, aby sa výsledok stal spoľahlivejším. Payload analýza sa na druhej strane aplikuje len do určitého mnoţstva packetov a dát, nakoľko špecifické reťazce protokolov sa v drvivej väčšine prípadov na-chádza v prvých niekoľkých packetoch. Ak neuspeje ani jedna z analýz, a spojenie je ešte označené ako NO_MATCH_YET, toto označenie sa zapíše aj do packetu, ktorý sa prenesie späť z uţívateľského prostredia a bude doručená adresátovi. V tomto bode by bolo moţné testovaním známky veľmi jed-noducho packet aj zahodiť (v prípade, ţe sa jedná o P2P packet), a blokovať tak P2P spojenia. Táto úloha sa ale zvyčajne vykonáva aţ pomocou iptables, kde je moţné aj na základe našich známok aj obmedzovať rýchlosť prenosu.

4.3.2

Tabuľka spojení

Všetky aktívne spojenia sa ukladajú do tabuľky, ktorá sa pouţíva na hocijakú prácu s týmito spoje-niami. Ako kľúč sa pouţíva textový reťazec maximálnej dĺţky 255 znakov, ktorý je generovaný pri kaţdom packete aj udalosti spojení, a obsahuje zdrojové a cieľové IP adresy a porty, okrem toho pro-tokol a číslo propro-tokolu. Je to teda jednoznačná a unikátna identifikácia kaţdého spojenia. Informácie, ktoré by mali byť uchované v tabuľke spojení, sú uvedené v tabuľke 4.2.

Názov položky Popis Príklad

num_packets Celkový počet bajtov v spojení 43 mark Celková výsledná známka spojenia 7

mark_p Známka payload analýzy 7

mark_f Známky analýzy štatistík FLOW_MATCH

buffer Buffer pre payload analýzu

lengthsofar Dĺţka bufferu 33

total_data_out Prenesené dáta smerom k cieľu 33552 total_data_in Prenesené dáta smerom k zdroji 5532

key Unikátny identifikačný kľúč tcp 6 src=147.229.44.44 _{dst=147.229.193.33 sport=9053 dport=443}

sport Zdrojový port 9053

dport Cieľový port 443

saddr Zdrojová IP adresa 147.229.44.44

daddr Cieľová IP adresa 147.229.193.33

spair Zdrojová IP adresa a port 147.229.44.44_9053 dpair Cieľová IP adresa a port 147.229.193.33_443

Nový záznam v tabuľke sa vytvorí pri prvom packete nového spojenia, alebo pri prijatí správy NTFC_MSG_NEW. Záznam sa z tabuľky odstráni pri správe NTFC_MSG_DESTROY.

4.4

Payload analýza

Payload analýza je v implementovaná v triede p2p_classify bola prebratá z nástroja L7-filter, preto tu bude len stručne popísaný jeho princíp činnosti.

Princípom payload analýzy je, ţe v obsahu packetov hľadá špecifické textové reťazce, ktoré charakterizujú určitý protokol, a v iných protokoloch sa nevyskytujú (podrobne je problém opísaný v kapitole 3.3.2. Táto payload analýza definuje tieto textové reťazce pomocou regulárnych výrazov, ktoré sú uloţené v externých súboroch. Kaţdý súbor reprezentuje jeden protokol, kde je uvedený meno protokolu a k nemu patriaci regulárny výraz. Okrem toho sa pouţíva ešte jeden súbor, ktorý definuje, ktoré súbory s protokolmi budeme pouţívať, a priraďuje ku kaţdému protokolu známku (v nástroji L7-filter väčšiu ako 2, v našom nástroji väčšiu ako 4, nakoľko potrebujeme špeciálne známky na analýzu pomocou štatistík spojení). Pri spustení nástroja sa tieto súbory načítajú, a k protokolom sa priradia známky. Pre kontrolu je v kaţdom spojení vyhradený buffer veľkosti niekoľkých packe-tov, a ten buffer sa kontroluje pri kaţdom novom packete aţ dovtedy, kým sa nezaplní, alebo rozpoz-nanie daného protokolu nebude úspešné. Samotná kontrola spočíva v tom, ţe buffer sa kontroluje na všetky regulárne výrazy v zozname. Táto operácia je však časovo náročná, preto je treba zvoliť ro-zumný počet regulárnych výrazov. Nástroj na detekciu P2P uţívateľov pouţíva dva typy konfigurač-ných súborov, v jednej je definovakonfigurač-ných 12 rôznych P2P protokolov1_{, a v druhej rýchlejšej verzii je 6} najčastejšie pouţívaných protokolov.

Ak payload analýza zistí prítomnosť niektorého z definovaných protokolov, vráti ako výsledok známku daného protokolu, čo znamená, ţe spojenie môţeme označiť ako P2P. Ak sa ţiadna zhoda nenašla, vracia sa NO_MATCH_YET, v prípade, ţe je buffer plný alebo spojenie sa zavrelo, výsled-kom je NO_MATCH.

4.5

Analýza pomocou štatistík spojení

Typ tejto analýzy bol predstavený v kapitole 3.3.3. Na získavanie dostatočných údajov sa pouţívajú rôzne spôsoby, ktoré budú predstavené niţšie. Základom tejto analýzy sú 3 štatistiky: pomer úspeš-ných a neúspešúspeš-ných spojení, pomer odoslaúspeš-ných a prijatých dát v spojení a priemerná veľkosť packe-tov v spojení. Kaţdá z týchto vlastností ovplyvňuje jednu zo štatistických premenných, ktoré môţu nadobúdať hodnoty od 0 do 10, pričom sa jedná o reálne, a nie o celé čísla. Na základe týchto pre-menných sa potom určí konečný index, čo je v podstate samotná známka analýzy štatistík v spojení. Prahové hodnoty premenných, po ktorých sa spojenie vyhodnotí ako P2P, sú nastaviteľné ako para-metre z príkazového riadku.

4.5.1

Pomer neúspešných spojení (FCR)

Ako uţ bolo spomenuté v kapitole 3.3.3, jedným z charakteristických vlastností P2P programov je vysoký počet neúspešných spojení, čo je následkom nepravidelného obnovovania zoznamu aktívnych uţívateľov v týchto programoch. P2P klienti sa pokúšajú kontaktovať iných, uţ nedostupných klien-tov, a preto vykazujú väčší počet zlyhaných spojení. O klasický webových sluţbách sa dá povedať, ţe počet neúspešných, či odmietnutých spojení je veľmi malý alebo nulový. V nástroji zisťujeme pomer neúspešných spojení tak, ţe vydelíme počet neúspešných spojení počtom všetkých spojení pre určitú IP adresu, a z tohto pomeru sa určí známka tejto vlastnosti. Výpočet v pseudokóde vyzerá takto: pomer = neúspešné_spojenia / všetky_spojenia;

if (0.0 <= pomer <= 0.5) známka = pomer * 20;

if (0.5 < pomer <= 1.0) známka = (1.0 - pomer) * 20;

Pre tento cieľ je potrebná tabuľka, ktorá obsahuje zoznam IP adries, z ktorých sme zaznamenali aspoň jeden packet. Kľúčom tabuľky je IP adresa vyjadrená v textovej forme (napr. "147.229.200.201"), uchovávané informácie o IP adresách sú uvedené v tabuľke 4.3.

Názov položky Popis

TTL Doba platnosti

check_me Rozhoduje o vyhodnotení údajov

conn_attempts Počet všetkých spojení conn_failed Počet neúspešných spojení

conn_in Počet prichádzajúcich spojení

conn_out Počet odchádzajúcich spojení

ports_above Počet pripojení, kde je číslo portu väčšie, neţ 1024 ports_under Počet pripojení, kde je číslo portu menšie, neţ 1024

Tabuľka 4.3: Informácie uchovávané v tabuľke IP adries

Za neúspešné spojenie sa v tomto prípade povaţuje spojenie, ktoré neobsahovala v payloade ţiadne uţívateľské dáta. Môţe ísť buď o jediný packet SYN zaslaný odosielateľom (v tom prípade je uţ vzdialený klient pravdepodobne nedostupný), alebo o packet SYN zaslaný odosielateľom a následne o packet RST zaslaný cieľovou adresou (tj. vzdialený klient odmietol poţiadavku o spojenie, je za bránou firewall alebo vypol P2P program). Táto skutočnosť a veľkosti uţívateľských

lo conn_failed. Počet všetkých spojení, tj. conn_attempts, sa zvyšuje vtedy, keď pridávame nové spojenie do tabuľky spojení. Vtedy sa testuje aj to, či uţ tabuľka IP adries obsahuje práve spra-covávanú IP adresu. Ak nie, vytvorí sa nová poloţka v tejto tabuľke.

Pri analyzovaní pomeru neúspešných spojení treba brať do úvahy aj situáciu, ak má niektorý klient nestabilné internetové pripojenie. V tom prípade môţe byť dokonca počet neúspešných spojení vyšší, neţ počet tých úspešných. Práve preto, ak je počet neúspešných spojení značne vyšší, pravde-podobnosť, ţe spojenie je P2P, sa zníţi. Tento fakt tieţ spôsobí, ţe túto štatistiku musíme brať ako doplnkovú k ostatným, a v ţiadnom prípade nesmieme zaraďovať spojenia len na základe výsledku tohto merania.

4.5.2

Pomer odoslaných a prijatých dát (IOR)

Základnou myšlienkou systému P2P je dávať a dostať. Preto väčšina P2P protokolov sa vyznačuje tým, ţe dáta sa posielajú oboma smermi v spojení. Protokol BitTorrent dokonca takéto spojenia uprednostňuje, presnejšie uprednostňuje odosielanie dát tým klientom, od ktorých dáta aj dostáva. Dôleţitým ukazateľom je preto pomer odoslaných a prijatých dát v spojení. Tento pomer sa vypočíta vydelením odoslaných bajtov prijatými bajtmi, z ktorého sa vypočíta výsledná známka:

pomer = počet_prijatých_bajtov / počet_odoslaných_bajtov; if (1.0 <= pomer <= 11.0) známka = 11 - pomer;

if (0.1 <= pomer < 1.0) známka = (pomer - 0.1) * 11.1;

Veľkosť uţívateľských dát packete sa zistí spôsobom opísaným v kapitole 4.2.1. Sluţby ako HTTP, SMTP, FTP alebo MMS budú mať vţdy dosť vysoké číslo tohto štatistického ukazateľa, alebo naopak extrémne nízke pri odosielaní, nakoľko dáta v nich tečú len jedným smerom.

4.5.3

Priemerná veľkosť packetov (APS)

Veľkosť packetov je nasledujúcou vlastnosťou, ktorou môţeme charakterizovať P2P spojenia. Sluţby ako HTTP, Skype, video a audio streaming, pouţívajú obvykle packety menších rozmerov. Ich veľ-kosť sa obvykle pohybuje od niekoľko desiatok bajtov do niekoľko stoviek bajtov. Spôsobuje to, ţe nepotrebujú preniesť väčšie mnoţstvo dát, alebo v prípade streamingu či VoIP treba zaistiť dostatoč-ne nízku odozvu, práve častejším odosielaním menších packetov. Na rozdiel od nich, P2P programy, ktoré sú orientované na prenos dát, pouţijú aţ na výnimky plné veľkosti packetov. Ich presná veľkosť je síce závislá od daného protokolu a na verzii klienta, ale pohybuje sa takmer vţdy nad 1000 bajtov na packet. V nástroji sa analyzuje priemerná veľkost packetov v spojení, čo sa získa vydelením počtu všetkých prenesených dát, a následne sa vypočíta známka pre túto vlastnosť. Výpočet napísaný v pseudokóde vyzerá takto:

priemerná_veľkosť_packetov = prenesené_bajty / počet_packetov; známka = priemerná_veľkosť_packetov * 0.0066;

4.6

Tabuľka P2P spojení

Dôleţitým prvkom v tomto nástroji je tabuľka, ktorá uchováva uţ rozpoznané P2P adresy a porty. Táto tabuľka pomáha nielen rozpoznať P2P spojenie bez hocijakej analýzy, a tak zvýšiť rýchlosť, ale pomáha identifikovať aj také spojenia, ktoré by inak rozpoznané neboli. Princíp tabuľky je, ţe ak sa jeden pár adresy a portu identifikuje ako P2P, tak sa na určitý čas tento pár zapíše do tabuľky. Kaţdé nové spojenie je potom testované, či sa zdrojový alebo cieľový pár IP adresy a portu nenachádza v tabuľke. Ak tak tomu je, tak sa spojenie tieţ označí za P2P, lebo klient, ktorý sa pripája na P2P port, je veľkou pravdepodobnosťou tieţ P2P klientom. Kľúčom tabuľky je pár IP adresy a portu, v podobe IPadresa_port (napr. "147.229.4.5_5555"). Uchovávajú sa informácie uvedené v tabuľke 4.4.

Názov položky Popis

TTL Doba platnosti

mark_p Známky payload analýzy

mark_f Známka analýzy štatistík

mark Celková výsledná známka

Tabuľka 4.4: Informácie uchovávané v tabuľke P2P spojení

4.7

Rozpoznanie užívateľov samotných

V nástroji bolo implementované aj rozpoznávanie samotných uţívateľov na základe sieťových štatis-tík. Nástroj skúma rôzne štatistiky, a pre kaţdú z nich určí hodnotu od 0 do 10, ktorá predstavuje mie-ru chovania ako P2P. Platí, ţe čím vyššie číslo, tým vyššia je pravdepodobnosť, ţe sa jedná o P2P aplikáciu. Pri zisťovaní sa berú do úvahy nasledovné ukazateľe:

 Pomer úspešných a neúspešných spojení

Pouţívanie P2P programov má za následok veľký počet neúspešných spojení. Známka sa pre túto vlastnosť vypočíta nasledovným spôsobom (pseudokód):

pomer = neúspešné_spojenia / všetky_spojenia; if (0.0 <= pomer <= 0.5) známka = pomer * 20;

if (0.5 < pomer <= 1.0) známka = (1.0 - pomer) * 20;  Pomer prijatých a odchádzajúcich spojení

U klienta pouţívajúce klasické protokoly prevaţujú odchádzajúce spojenia. Klient pouţívajú-ci P2P program má pribliţne rovnaký počet odchádzajúpouţívajú-cich, aj prijatých spojení. Známka sa vypočíta nasledovne:

pomer = odchádzajúce_spojenia / prijaté_spojenia; if (1.0 <= pomer <= 2.0) známka = (2.0 - pomer) * 10; if (0.5 <= pomer < 1.0) známka = (pomer - 0.5) * 20;

 Pomer používania portov nad 1024

P2P programy aţ na výnimky pouţívajú vţdy čísla portov nad 1024, kým klasické aplikácie ako HTTP a FTP tieto čísla pouţívajú zriedkavo. Výpočet známky uvedený v pseudokóde: pomer = porty_pod_1024 / porty_nad_1024;

if (1.0 <= pomer <= 2.0) známka = (2.0 - pomer) * 10; if (0.5 <= pomer < 1.0) známka = (pomer - 0.5) * 20;

Nástroj označí kaţdú IP adresu, ktorá reprezentuje jedného uţívateľa, známkou od 0 do 10 typu float. V príkazovom riadku je nastaviteľné, nad akou známkou sa adresa povaţuje za adresu pou-ţívajúcu P2P programy.

Treba si ale uvedomiť nasledovné fakty:

 Adresa môţe byť označená ako P2P aj po dlhšej analýze niekoľkých desiatok minút

 Uţívatelia v tzv. Pasívnom režime, ktorí sú za bránou firewall alebo nemajú nastavené pre-smerovanie portov na smerovači, nie sú schopní prijímať ţiadne spojenia. Tento fakt môţe značne zníţiť úspešnosť detekcie.

Táto detekcia neprebieha neustále, dáta sa vyhodnocujú len v určitom intervale. Tento interval udáva časovač, ktorý je popísaný niţšie.

4.8

Časovač

K vylepšeniu nástroja bola pridaná trieda ttl_timer. Tá zaisťuje, aby v tabuľke IP adries a v ta-buľke P2P párov dáta nezostali naveky, ale po určitom čase zmizli. Čas, ktorý ostáva kaţdej poloţke, je daný premennou TTL v štruktúre. Predvolené časy, ktoré sú nastavené pre určité typy poloţiek, sú uvedené v tabuľke 4.5. Záznam, ktorý obsahuje známe P2P páry adresy a portu, a ktoré boli zdrojové v spojení, majú oveľa kratšiu platnosť, neţ cieľové páry. Je to kvôli tomu, ţe zdrojové porty nie sú pevne dané, a menia sa veľmi často. Bolo by moţné tieto páry dokonca z tabuľky celkom vypustiť. V predvolenom nastavení časovača, tj. interval 60 sekúnd, môţeme chápať tieto časové jednotky za sekundy. Interval časovača je ale moţné meniť ako parameter pri spúšťaní nástroja. Pri kaţdom uply-nutí intervalu sa aktivuje funkcia, ktorá zníţi premenné TTL v kaţdej poloţke oboch tabuliek. Ak hodnota TTL dosiahne nulu, znamená to, ţe danej poloţke vypršala platnosť, a je odstránená z tabuľky. Zaisťuje tieţ v danom intervale vyhodnotenie nazbieraných dát pre rozpoznanie uţívate-ľov. Časovač je implementovaný ako nekonečná slučka, a vyuţíva sa príkazu sleep(interval).

Popis položky Predvolená časová jednotka

Štruktúra hostinfo 120

5

Testovanie nástroja

5.1

Podmienky testovania

Spočiatku sa počítalo s troma verziami moţného testovania:

1) Testovanie na vzorke dát

Podstatou tohto testovania by bolo spustiť nástroj na niekoľkými gigabajtmi alebo terabajtmi dát nazbieraných z reálnej prevádzky, a simulovať tak reálnu prevádzku. Bohuţiaľ sa nepoda-rilo zohnať potrebné vzorky dát, a tak sa táto varianta stala neuskutočniteľnou.

2) Nahratie nástroja na smerovač

Cieľom by bolo nainštalovať nástroj na smerovač beţiaci na platforme Linux, na ktorý je na-pojených niekoľko ľudí, a analyzovať prevádzku v reálnom čase. Vyriešili by sa tak problé-my ohľadom porušenia súkromia, nakoľko ľudia pripojený na náš smerovač by dali súhlas so sledovaním ich dátovej prevádzky. Táto varianta sa zdala byť najreálnejšou, ale nastali tech-nické problémy na strane smerovača, ktoré znemoţnili nainštalovanie nástroja a sledovanie prevádzky. Ďalším problémom tejto varianty by mohol byť slabý výpočtový výkon smerova-ča a nízka priepustnosť dát. Varianta však bude po vyriešení technických problémov určite vyskúšaná, čo ale vyţaduje značný časový priestor a finančné prostriedky, ktoré v čase písa-nia tejto bakalárskej práce nie sú k dispozícii.

3) Notebook ako smerovač

Bol ďalším z moţných riešení. Notebook pripojený na internet cez Ethernet, a ostatný uţíva-telia by sa pripájali cez rozhranie WiFi. Internet by bol zdieľaný pomocou technológie NAT na notebooku. Nastali však technické problémy, a sieťové rozhranie WiFi sa nepodarilo na-konfigurovať v systéme Linux tak, aby prijímal bezdrôtové spojenia, nakoľko jediný ovládač danej sieťovej karty tento mód nepodporuje.

4) Testovania na notebooku

Bolo poslednou variantou v prípade, ţe sa predchádzajúce 3 nepodarí realizovať. Testovala by sa len dátová prevádzka jedného uţívateľa, ale otestovalo by sa viac protokolov.

Konečným riešením sa napokon stala posledná varianta. Jednoduchá schéma zapojenia je na obrázku 5.1. Užívateľské rozhranie na notebooku KolejNET (Internet) Nástroj na detekciu P2P užívateľov

5.2

Zisťovanie vlastností rôznych protokolov

Na zistenie niektorých vlastností protokolov sa pouţil samotný nástroj upravený tak, aby pri kaţdom ukončenom spojení vypísal štandardný výstup nasledovné informácie:

 Počet packetov v spojení

 Celkové prenesené dáta v spojení  Priemerná veľkosť packetov (APS)  Počet prijatých bajtov

 Počet odoslaných bajtov

 Pomer prijatých a odoslaných bajtov (IOR)

 Celkový počet pokusov o spojení pre zdrojovú adresu  Celkový počet neúspešných spojení pre zdrojovú adresu  Pomer neúspešných spojení (FCR)

Jedna poloţka po zavretí spojenia vyzerala napríklad takto:

<<< Connection closed: 192.168.1.20:40573 -> 87.229.111.19:36341, length:62 Packets: 17590, Data: 14488850 (APS=823.698124)

Data_in: 14462476, Data_out: 26374 (IOR=548.361113) Conn: 16, Failed: 2 (FCR=0.125000)

Tento test sa pouţil na niektoré známe protokoly, aby sa zistili dôleţité údaje o nich. Výsledky sú uvedené v tabuľke 5.1. Je ale nutné poznamenať, ţe nie pre všetky protokoly sú výsledky presné. V prípade načítania webovej stránky cez protokol HTTP nemá význam analyzovať jedno spojenie, ale celú skupinu, ktorá slúţila na načítanie jednej stránky. Preto nie je v tomto riadku výsledok pres-ný. Druhým problémom bolo zvláštne správanie protokolu Skype, ktorý dáta prenáša cez UDP packe-ty. Jedno „spojenie“ obsahovalo niekoľko packetov, UDP packety sa ale prenášali po niekoľkých packetoch na inú IP adresu. Táto situácia nastala kvôli tomu, ţe sám Skype pouţíva určitý špeciálny P2P systém na prenos hovorov. Od P2P aplikácii slúţiacich na zdieľanie súborov ho však odlišuje veľkosť packetov, ktorá je podstatne menšia. Z tabuľky je dôleţité si všimnúť, ţe neúspešné spojenia sa vyskytujú jedine u P2P protokolov, vrátane Skypeu, ktorý ale počtom neúspešných spojení zaostá-va za P2P protokolmi slúţiacimi na zdieľania súborov.

APS IOR FCR

948,06 506,4756 0,1654 BitTorrent - sťahovanie súboru s veľkým počtom seederov

932,49 2,3691 0,1638 BitTorrent - sťahovanie súboru s malým mnoţstvom seederov a veľkým mnoţstvom peerov

903,98 0,0015 0,1111 BitTorrent - Seedovanie (odosielanie) súboru

1139,78 0,000002 0 DC++ - sťahovanie súboru

1280,21 602093,7 0 DC++ - odosielanie súboru

803,10 866,1293 0,0608 eMule - sťahovanie súboru

749,85 0,008 0,0712 eMule - odosielanie súboru

500-700 5,0-15,0 0 HTTP - načítanie webovej stránky

1095,83 11409,29 0 HTTP - sťahovanie veľkého súboru

8,08 3,8095 0 FTP - komunikačný kanál (port 21)

986,01 ∞ 0 FTP - sťahovanie súboru

950,45 0 0 FTP - odosielanie súboru

88,76 6,0758 0,0177 Skype - dvojminútový hovor

190,71 9,1866 0 ICQ - hlavné spojenie, prihlásenie

130,40 5,7916 0 ICQ - posielanie niekoľkých krátkych správ