přejít na obsah přejít na navigaci

Linux E X P R E S, IPP2P – kladivo na stahovače

IPP2P – kladivo na stahovače

Někteří z vás již možná znají ten bezmocný pocit, když se před vaším zrakem mění graf přenesených dat na souvislou čáru, která kopíruje maximální dovolenou propustnost sítě. Tato nemilá věc se stala jednoho dne i mně, proto bych vám rád poradil, jak takovéto situaci předejít, případně jak z ní elegantně vybruslit.


Peer-To-Peer - často označováno jako P2P. V překladu doslova znamená "rovný s rovným". V počítačových sítích tak označujeme stroje (nodes), které plní zároveň funkci serveru i klientu. Peer-To-Peer je používáno především pro sdílení dat - většinou se jedná o audio a video soubory, ale výjimku netvoří ani streaming či IP telefonie.

V mém případě bylo nejprve důležité zjistit, co samotný traffic způsobuje. Po noci a půl strávené za terminálem s mými nejlepšími kamarády (což jsou TCPdump, kafe a dobrá muzika) jsem odhalil viníka. Za toho byl prohlášen DC++ společně s Kazou - klienty P2P sítí.

Traffic není nic jiného než tok dat v síti. Správci větších počítačový sítí jej s oblibou rozdělují na webový traffic - množství dat přenesené návštěvníky webových stránek, mail traffic - množství dat přenesených při odesílání elektronické pošty a peer-to-peer traffic - množství dat přenesených klienty povětšinou decentralizovaných sítí.

DC++ je open-source peer-to-peer klient, kterým se lze připojit do velmi rozsáhlé internetové sítě Direct Connect Network. Na rozdíl od programu KaZaA neobsahuje žádný spyware. Existuje nespočetné množství jeho modifikací včetně několika českých. Stejně jako KaZaa disponuje funkcemi sekvenčního stahování a navíc experimentálně přidává nové funkce, jako je například omezování rychlosti či hashování.

Ihned po odhalení protivníka jsem počal upravovat pravidla firewallu, ovšem jak se ve velmi krátkém čase ukázalo - zcela bezúspěšně. V okamžiku, kdy jsem zablokoval patřičný port, přes který jeden z klientů komunikoval, tak se na dalším kanále otevřel port nový, v té chvíli neblokovaný. Pochopil jsem, že tudy cesta nevede a vydal jsem se pátrat po internetu, jakým způsobem se těchto potvůrek navždy zbavit.

Na konferencích jsem vyčetl spoustu postřehů, jak bojovat proti P2P sítím na firewallu za pomoci blokování portů, omezování počtu aktivních konexí či hledání řetězce daného protokolu v každém paketu. To mě však vnitřně neuspokojilo, neboť se vždy jednalo pouze o polovičatá řešení, která měla negativní účinky, a to většinou v podobě zablokování jiných služeb, které jsem běžně na routeru provozoval. Srdce mi zaplesalo teprve poté, co jsem objevil programy iptables-p2p, L7-filter a ipp2p.

Jako první jsem vyzkoušel iptables-p2p. Bylo potřeba stáhnout hlavičkové soubory iptables, vše zkompilovat a zavést do jádra. Po této operaci jsem začal s testováním. Zjistil jsem, že iptabes-p2p výtečně blokují postarší klienty sítě Fastrack, ovšem DC++ si funguje vesele dál. Na domovských stránkách bylo datum posledního release 6. 3. 2004, takže jsem nedoufal v rychlé vyřešení problému a vydal se dál - testovat L7-filter.

FastTrack je peer-to-peer protokol používaný především programem KaZaA a jeho modifikacemi - jako je iMesh či Grokster. Jeho oblíbenost stoupla díky možnosti navázání přerušeného stahování a možností tzv. sekvenčního stahování (současné stahování stejného souboru nebo jeho části od několika uživatelů najednou).

L7-filter potřeboval stejně jako iptables-p2p patch do iptables a do jádra. Po úspěšném zkompilování a prostudování manuálu jsem byl mile překvapen možností zvolit z několika desítek protokolů (od filtrování služby SNMP přes FTP až po ne příliš standardní protokoly, jakým je například quake-halflife). Z changelogu jsem poznal, že se projekt neustále vyvíjí a navíc mě utěšovala možnost dopsat si vlastní blokovací řetězec pro protokol, který by mi v budoucnu chyběl. Blokování programů KaZaA a DC++ až na malé detaily fungovalo tak, jak se sluší a patří. Jediné, co mě zamrzelo, byl zvýšený load serveru, a tak jsem se rozhodl do třetice všeho dobrého ještě vyzkoušet IPP2P.

KaZaA je momentálně jeden z nejpoužívanějších peer-to-peer klientů využívající sítě FastTrack. Slouží převážně k výměně hudebních souborů a videonahrávek přes síť internet. Oficiální klient je sponzorován obsaženou reklamou, mallwarem a spywarem navzdory hlášce "No Spyware" na jejich domovské stránce.

Stáhl jsem si z domovské stránky projektu poslední (ne)stabilní verzi a pročetl manuál. U IPP2P jsem měl na výběr dvě možnosti kompilace. Buďto použít sadu patchů z balíku Patch-O-Matic. Nebo vše bez patchů ručně zkompilovat. Vydal jsem se druhou cestou. Bylo třeba získat zdrojové kódy pro aktuální verzi iptables a kernelu. Jádro jsem zvolil z řady 2.6. Důvodem této volby byl modul CONNMARK (potřebný pro plnou funkčnost IPP2P). Na kernelech z 2.4 řady byl problém s jeho kompilací, kdežto u kernelů řady 2.6 se jedná pouze o malý patch. V kernelu 2.6.10 a vyšším je pak již modul CONNMARK přímo obsažen.

Kompilace jádra probíhala standardně. Použil jsem konfigurační soubor předešlého kernelu, který byl ve stejné verzi a tím pádem pouze stačilo pozměnit položku CONFIG_IP_NF_TARGET_CONNMARK na CONFIG_IP_NF_TARGET_CONNMARK=m a poté jádro zkompilovat. Následně jsem zkompiloval iptables a restartoval testovací router. Posledním krokem byla kompilace samotného modulu IPP2P. Ta je velmi přímočará - stačí v rozbaleném adresáři se zdrojovými kódy zadat obligátní příkaz make. Po pár vteřinách se vygenerují dva soubory. První z nich je libipt_ipp2p.so, který nakopírujeme do adresáře knihoven iptables - v mém případě /usr/lib/iptables. Druhým souborem je pak ipt_ipp2p.ko, který nakopírujeme do adresáře netfilteru - v mém případě /lib/modules/2.6.15/kernel/net/ipv4/netfilter. Jakmile máme nakopírováno, vygenerujeme novou mapu závislostí příkazem depmod -a a nahrajeme modul do jádra příkazem modprobe ipt_ipp2. Pokud je vše v pořádku, měla by se nám po zadání příkazu iptables -m ipp2p -h vylistovat stručná nápověda. IPP2P na rozdíl od L7-filter podporuje pouze omezování P2P sítí, které je ovšem na druhou stranu daleko propracovanější než u výše zmíněných programů. Podporovány jsou následující protokoly:

  • eDonkey/eMule/Overnet na protokolech TCP i UDP
  • Direct Connect na protokolu TCP
  • KaZaA na protokolech TCP i UDP
  • Gnutella na protokolech TCP i UDP
  • BitTorrent na protokolech TCP i UDP
  • AppleJuice na protokolu TCP
  • WinMX na protokolu TCP
  • SoulSeek na protokolu TCP
  • Ares na protokolu TCP

Experimentálně (ve verzi 8.1) pak:

  • Mute na protokolu TCP
  • Waste na protokolu TCP

Jak je vidět, podpora P2P sítí je celkem široká. Samotná integrace IPP2P na router navíc nebude dělat problémy nikomu, kdo již má zkušenosti s konfigurací samotných iptables. Základní příkaz do firewallu by pak mohl vypadat asi nějak takto:

iptables -A FORWARD -p tcp  -m ipp2p --kazaa -j DROP

Tímto příkazem zahodíme všechny pakety, které putují přes náš server na vrstvě TCP a jsou generovány programem KaZaA. Ne vždy je však nutno všechny pakety přímo blokovat - jsou případy, kdy P2P sítě potřebujeme pouze označkovat, vyhradit jim určitou šířku pásma, nastavit jim TOS flagy a podobně. Nový příkaz (například pro označkování paketů) by pak vypadal následovně:

ToS znamená anglickou zkratku "Type of Service" neboli typ služby. ToS je včleněn do hlavičky IPv4 paketů a používá se obvykle při prioritizaci jednotlivých spojení. Mezi pět nejznámějších ToS flagů patří: minimize delay (minimální zpoždění), maximize throughput (maximální propustnost), maximize reliability (maximální spolehlivost), minimize monetary cost (minimální cena) a normal service (standardní služba).

iptables -A PREROUTING -p tcp -m ipp2p --kazaa -j MARK --set-mark 10

Tento typ značkování je samozřejmě za podmínky správného umístění ve firewallu plně funkční, má ovšem jednu obrovskou nevýhodu. Pokud byste řekněme v době od 23:00 do 7:00 měli pro značku 0xa ve firewallu pravidlo

iptables -A PREROUTING -p tcp  -m mark --mark 10 -j ACCEPT

a ráno v 7:00 ho změnili na

iptables -I PREROUTING -p tcp -m mark --mark 10 -j DROP

byli byste pravděpodobně asi zklamaní. Stahovačům se již sice nepodaří otevřít nová spojení, ovšem ta spojení, která jsou již navázaná, budou fungovat i nadále. Na grafech pak v lepším případě uvidíte velmi pozvolné snižování trafficu, namísto jeho totálního "utnutí".

O funkčnosti takového filtru vás možná přesvědčí graf průtoku dat na jednom z routerů ve firemní síti. Úmyslně jsem toto blokovací pravidlo zapnul chvíli před osmou hodinou. Postupně pak na grafu můžete sledovat snižování uploadu přibližně až do druhé hodiny ranní, kdy již není žádná P2P sít funkční a všechna spojení jsou zablokovaná.

Obrázek: 1.jpg

Když jsem s omezováním P2P sítí začínal, nepřikládal jsem tomu "efektu" přílišnou váhu a spíše jsem si říkal, že je to vlastně výhoda, neboť jednotlivým klientům stahování neskončí například v 95 %, aby pak museli zbytečně čekat na další den. Slovy klasika to mohu shrnout větou "šedivá je teorie, zelený strom praxe…" Uživatelé na tuto "výhodu" během několika málo dní přišli, a místo aby zapínali své "sčoty" na noc, vždy si jen o půl hodinky přivstali a spustili stahování, které jim v ideálním případě vydrželo přes celý den až do večera, kdy byly P2P sítě opět povoleny.

Proti této nectnosti se však lze úspěšně bránit použitím zmíněného modulu CONNMARK. Ten funguje na principu jakéhosi sledování paketů. Označí si první paket, který obsahuje řetězec KaZaA, ale sleduje i ostatní pakety, které na něj navazují. Za použití CONNMARKu pak můžeme utnout okamžitě veškerý P2P traffic, a to v kteroukoliv chvíli se nám zamane. Příkazy iptables pro označení všech protokolů IPP2P na protokolu TCP by byly následující:

iptables -t mangle -A PREROUTING -p tcp -j CONNMARK -restore-mark
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --edk -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --dc -j MARK --set-mark 0x2
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --kazaa -j MARK --set-mark 0x3
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --gnu -j MARK --set-mark 0x4
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --bit -j MARK --set-mark 0x5
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --apple -j MARK --set-mark 0x6
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --winmx -j MARK --set-mark 0x7
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --soul -j MARK --set-mark 0x8
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ares -j MARK --set-mark 0x9
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --mute -j MARK --set-mark 0xa
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --waste -j MARK --set-mark 0xb
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --xdcc -j MARK --set-mark 0xc
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK -save-mark

Ti bystřejší z vás si jistě všimli, že markujeme všechny známé protokoly, ovšem pouze na vrstvě TCP. Autor filtru IPP2P totiž na domovských stránkách důrazně doporučuje umístit markování paketů na UDP vrstvě samostatně (klidně i se stejnou značkou) až za modul CONNMARK.

V této chvíli máme tedy P2P pakety označkovány a záleží jen na nás, jak s nimi naložíme - můžeme je trvale vypnout, povolit pouze v určitou denní dobu za použití CRONu (nebo například modulu time do iptables), případně je také omezit na šířce pásma.

Uveďme si proto malý příklad. Řekněme, že bychom měli linku o rychlosti 1536 kbit a chtěli bychom v ní omezit veškerý provoz sítě KaZaA na pásmo o šířce maximálně 64 kbit při zatížené síti a na 128 kbit při síti nezatížené. Sekvence příkazů by pak vypadala přibližně následovně:

iptables -t mangle -A PREROUTING -j CONNMARK -restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -m ipp2p --kazaa -j MARK --set-mark 0xa
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark
tc qdisc add dev eth1 root handle 1:0 htb default 2
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1536kbit
tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1536kbit
tc class add dev eth1 parent 1:1 classid 1:3 htb rate 64kbit ceil 128kbit
tc filter add dev eth1 parent 1:0 protocol ip prio 2 handle 10 fw classid 1:3

Považuji za ideální spojit tyto dva uvedené příklady dohromady. Dostanete tak mocnou zbraň, která vám dává možnost omezit "sosače" v přesně stanovenou dobu na přesně stanovenou rychlost. Krásnou ukázkou může být opět graf průtoku části naší sítě, kde jsou P2P povoleny pouze v době od 23:00 do 7:00 ráno.

Obrázek: 2.jpg

Na naší síti není žádoucí filtrovat jiné protokoly než ty, které jsou používány P2P programy, a proto jsem se rozhodl právě pro IPP2P. Po dlouhodobém používání tohoto filtru mohu říct, že jsem v souvislosti s ním nikdy nepozoroval žádné problémy. Pro někoho bude spíš výhodný layer7 filtr, který, co se týče blokování P2P sítí, nedosahuje takových kvalit, ale má zase jiné výhody. U svých kolegů jsem viděl i kombinaci obou programů. Instalaci iptables-p2p bych však již nikomu nedoporučoval.

Nahoru

Odkazy

Příspěvky

Re: IPP2P – kladivo na stahovače
26. 07. 2006, 08:28:16
Odpovědět  Odkaz 
Nádherný článek děkuji
Re: IPP2P – kladivo na stahovače
29. 07. 2006, 20:15:14
Odpovědět  Odkaz 
Pěkný článek. Jen otázečka, jedná se o firemní síť, tj. zaměstnanci si mohou stahovat data z p2p a dokonce mají pro tento účel zapnutá PC přes noc?
Re: IPP2P – kladivo na stahovače
31. 07. 2006, 13:24:27
Odpovědět  Odkaz 
Urcite nemohou :-), ale sikovny cesky clovek toho nedba, stahne si klienta, ktereho nemusi instalovat (pokud nema treba win98) a pc pres noc klidne necha zapnute. Pokud je to velka firma, nikdo to nekontroluje. A pres den to v klidu zamaskuje, jeste ze nam soudruzi v NDR vynalezli ten multitasking.
Re: IPP2P – kladivo na stahovače
18. 04. 2007, 21:21:36
Odpovědět  Odkaz 
Tohle ovšem můžou pouze pokud nemají ve firmě správce sítě.
Chytit kohokoliv kdo dělá po síti něco nepovoleného není velká věda. Jenom namátkou - sběr statistik ze switchů | sběr statistik z routerů => sběr neposlušných pracovníků.

Nechápu jak je to možné zamaskovat (teda pokud tam je, jak jsem říkal, správce sítě, alespoň na středoškolské úrovni (rozumíme cca CCNA :) ))
Milan Kozák Re: IPP2P – kladivo na stahovače
Milan Kozák 20. 04. 2007, 20:57:21
Odpovědět  Odkaz 
DD, zamaskovat jakykoliv provoz dnes neni vubec zadny problem. Zpusobu existuji desitky - od zapozdreni cele komunikace do nejakeho VPN tunelu, zasifrovani komunikace do SSL kanalu (dnes bezne vyuzivane vetsinou P2P klientu) az po tunelovani provozu pres DNS dotazy nebo treba ping. Opet zde totiz plati, ze uzivatele jsou o krok napred pred spravci.

Nemyslim si, ze absolvent CCNA je schopny rozpoznat, zdali se pres SSL prihlasujete zrovna do banky, nebo stahujete via BitTorrent fotky nahe Britney Spears...
Re: IPP2P – kladivo na stahovače
17. 08. 2006, 11:21:53
Odpovědět  Odkaz 
DD
pekny clanek uz se tesim az to bude fungovat
pri instalaci ipp2p je v souboru makefile vyzadovana cesta k iptables kterou nejsem schopen najit a zadat pozivam FC5
dekuji za jakoukoli odpoved
Milan Kozák Re: IPP2P – kladivo na stahovače
Milan Kozák 18. 08. 2006, 15:35:44
Odpovědět  Odkaz 
Dekuji vsem za pozitivni ohlasy.

Co se tyce iptables - doporucuji stahnout aktualni verzi z domovskych stranek (do libovolneho adresare) a v makefile upravit cestu.

Stahnout aktualni verzi iptables muzete nasledovne:

# cd /usr/src/
# wget ftp://ftp.netfilter.org/pub/iptables/iptables-1.3.5.tar.bz2
# tar xjvf iptables-1.3.5.tar.bz2
# ln -s iptables-1.3.5 iptables

Nyni jiz staci prepsat v makefile vsechny cesty k iptables na /usr/src/iptables a zkompilovat ipp2p...
Re: IPP2P – kladivo na stahovače
22. 09. 2006, 10:29:44
Odpovědět  Odkaz 
which iptables
Re: IPP2P – kladivo na stahovače
26. 11. 2006, 12:28:59
Odpovědět  Odkaz 
Vynikajuci clanok, kvalitne spracovanie problemu.

Akurat malicky dotaz - na grafoch je chybka. Spravne je "Data Analysis"
Milan Kozák Re: IPP2P – kladivo na stahovače
Milan Kozák 27. 11. 2006, 13:59:22
Odpovědět  Odkaz 
> Vynikajuci clanok, kvalitne spracovanie problemu.

Diky

> Akurat malicky dotaz - na grafoch je chybka. Spravne je "Data Analysis"

Ano mate pravdu. Bohuzel tato chyba je primo v monitorovacim systemu (BBstatus), ze ktereho jsem screenshoty porizoval.
grafy
27. 01. 2007, 12:52:09
Odpovědět  Odkaz 
Bezva clanek, ale mam otazecku z trochu jineho soudku, ale souvisi to s tim. Zajimalo by me jakym programem jsou udelany ty grafy ktere autor clanku prezentuje. Rad bych je pouzil i u sebe na routeru. Diky za odpoved.
Milan Kozák Re: grafy
Milan Kozák 31. 01. 2007, 16:20:49
Odpovědět  Odkaz 
V mych screenshotech jsou grafy z monitorovaciho systemu BBStatus. Jedna se o jednoduche grafy s RRD.

Sam si muzete podobny graf udelat za pouziti MRTG a to nejen na prenesena data, ale i na ostatni sluzby.

Vice informaci naleznete na:
http://freshmeat.net/projects/bbstatus/
http://oss.oetiker.ch/mrtg/
http://gentoo-wiki.com/HOWTO_SNMP_and_MRTG_Made_Easy
IPP2P – kladivo na stahovače
Vladimír 22. 02. 2008, 15:36:07
Odpovědět  Odkaz 
Vypadá to dobře, ale nefunguje mi to na šifrovaný BitTorrent. Nevíte někdo, zda existuje řešení?
Milan Kozák Re:IPP2P – kladivo na stahovače
Milan Kozák 25. 02. 2008, 10:49:26
Odpovědět  Odkaz 
...
I have seen some pieces of code from ipoque which can detect encypted bittorrent
and edonkey traffic. Unforunately, this code will not work with iptables, because it needs
more information about the flow history and the history of an ip address
...

Odpovědět

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Top články z OpenOffice.cz