Iptables - torrent szűrése

Linux-kezdő

Sziasztok!

Iptables-ben szeretnék megoldani torrent korlátozást. Olvasgattam ajánlásokat, hogy sokan az l7-filter, iptables-p2p és hasonló dolgokra esküsznek, de kezdőként nekem a lenti logika értelmezhetőbb lenne. Ezt a lenti 7 sort egy külföldi fórumon találtam, elvileg működik is. De nálam, miután a script lefut, ezekre hibát dob. Ha a lenti rész megjegyzésben van, akkor a tűzfal többi része rendesen lefut, olyankor semmire nem jelez hibát, és nmap-pal tesztelve is minden OK-nak tűnik.

Aki rutinosabb, tudna pár hasznos tanácsot adni, hogy hol nem stimmel a dolog? (A tesztelt környezet Wheezy lenne.)

iptables -A FORWARD -m string --string "torrents" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "torrent" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "info_hash" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "announce.php?passkey=" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "announce_peers" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "BitTorrent protocol" --algo -kmp --65535 -j DROP
iptables -A FORWARD -m string --string "BitTorrent" --algo -kmp --65535 -j DROP

  • 6222 megtekintés

( uid_7086 | 2014. 06. 20., p – 15:48 )

Hol találtad?
Szerintem a -kmp és a --65535 lehet hibás.
A -kmp nem biztos, de az a --algo paramétere, én csak "-" nélküli formában találkoztam vele (--algo kmp), az a --65535 meg... szóval azzal nem tudok mit kezdeni. Persze ettől még lehet, hogy van ilyen, mindenesetre első menetben nekem arra jelez hibát az iptables.

( blr v | 2014. 06. 20., p – 15:53 )

A „kmp” elé nem kell a mínusz jel, a --65535 pedig fogalmam sincs, mi akar lenni. (Gondolom from vagy to, de mindegy, mert értelmetlen, mert nagyobb mint a max. csomagméret.)

( cala | 2014. 06. 20., p – 16:05 )

Ez nekem így műxik éles szerveren több helyen is:

iptables -A FORWARD -m string --string "BitTorrent" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "BitTorrent protocol" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "peer_id=" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string ".torrent" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "announce.php?passkey=" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "torrent" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "announce" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "info_hash" --algo bm --to 65535 -j DROP
iptables -A FORWARD -m string --string "peer_id" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "BitTorrent" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "BitTorrent protocol" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "bittorrent-announce" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "announce.php?passkey=" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "find_node" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "info_hash" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "get_peers" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "announce" --algo kmp --to 65535 -j DROP
iptables -A FORWARD -m string --string "announce_peers" --algo kmp --to 65535 -j DROP

Köszi, hogy megosztottad! Nálam is gond nélkül lefut és működik. Idővel majd a Suricatat akarom belőni ilyen célra, de azzal még csak ismerkedem, ez meg bőven megteszi addig. Van még egy olyan illesztése az IPTABLES-nek amiben a letöltött file-oknak lehet felső korlátot adni, azzal fogok még próbálkozni.

( gergelykiss | 2014. 06. 20., p – 16:14 )

Nem kifejezetten a kérdésre válaszolok, de a tapasztalat azt mutatja, hogy egyre több a titkosított torrent kapcsolat, ezért a szűrés csaknem lehetetlen (de minimum nehézkes), még layer7 szinten is. Arról nem is beszélve, hogy minél magasabb OSI rétegben van a szűrés, annál inkább erőforrásigényes.

Az egyetlen garantáltan működő megoldás, ha DROP policy-t vezetsz be az OUTPUT láncon (is), és utána csak azokat a portokat engedélyezed kifelé, amelyeket valóban ki akarsz engedni (pl. 80,443,995,21 stb).

Ezzel sajnos keresztbe teszel (többek között) a passzív FTP-nek, de ezen segíthez a conntrack_ftp modul használata (nem használtam még):

http://unix.stackexchange.com/questions/93554/iptables-to-allow-incomin…

Nekem a fentebb leírt script részlet egy squid transzparens proxyval együtt fut, egyelőre nem sikerült senkinek se torrentezni ezen keresztül, pedig erősen próbálkoztak (kollégium, etc.)

A kettő valóban együtt hatékony: azaz kifelé csak az amit engedélyezni is kell, azaz HTTPS, NTP egyebek. Én még megfejeltem azzal, hogy belső caching DNS van, kifelé nem enged DNS kérést a tűzfal a belső hálóból, és fake zónákat megadva a bindnek simán keresheti a kliens localhoston az ismertebb torrent trackereket.

Tudom favágó megoldás, de működik egy ezer éves vason is. Persze átjárható is ha valaki nagyon akarja, de a célnak megfelel. És a 80-as port prerouting miatt a keresőszavak nem zavarnak be a normál HTTP forgalomba sem.

Mondtam, hogy nem 100%. Kikerülni simán ki lehet, de, sejtem a topik indítója nem a NASA -nál kell hogy megoldja ezt a gondot, hanem egy kis hálón szűrné a userek forgalmát egyszerű módon. :)

"Az egyetlen garantáltan működő megoldás" -t nem tudom hol olvastad, vagy miért szúrta a szemed, hogy adtam egy olyan működő és különösebb beruházást valamint hozzáértést sem nagyon igénylő tippet, ami adott esetben valakinek segíthet. Szólj, és többet nem teszem :)

( Crayon | 2014. 06. 20., p – 16:18 )

az egyik sor helyesen:
iptables -D FORWARD -m string --string "BitTorrent" --algo kmp --to 65535 -j DROP

Ez viszont már csak azért sem a legjobb módszer, mert próbálj meg ezek után pl. ide a fórumra feltenni egy kérdést amiben szerepelnek a fenti szavak :)
Tényleg jobb egy layer7 tűzfal erre a célra, ha komolyan gondolod.

( bAndie9100 | 2014. 06. 20., p – 19:05 )

Ha a lenti rész megjegyzésben van, akkor a tűzfal többi része rendesen lefut, olyankor semmire nem jelez hibát

milyen meglepő :D

viccet félretéve, a string modul szerintem sok csomagot blokkolna, amit nem kéne, mert 64k-ig az egész tcp stream-ben keres.

én ezt aklalmazom, titkosítatlan torrent forgalom kezdeményezés ellen eddig úgy tűnik, bevált: 


iptables -t mangle -A FORWARD ! -f -m connbytes --connbytes 0:255 --connbytes-mode bytes --connbytes-dir original -m state --state ESTABLISHED -m length --length 46:375 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x0=0x13426974" -j torrent
iptables -t mangle -A torrent -m limit --limit 12/min --limit-burst 1 -j LOG --log-prefix "Firewall: torrent: " --log-level 6
iptables -t mangle -A torrent -j DROP

ez az u32 modulban használt sztring a bittorrent negotiation elején található "bittorrent" stringre illeszt rá. tehát más - legális - protokolt eléggé kis esélyben gátol.
a loggolás természetesen opcionális.

azt hogy miért a mangle táblába raktam, ne kérdezd :) lehet a filter-ben is mint a te példádban.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy yazzy repack

( Winter | 2014. 06. 24., k – 16:12 )

Az XBT alapértelmezetten a 2710-es porton fut. Ha azt blokkolod, a legtöbb zárt oldalt már kilőtted, mert nem tud a trackerhez kapcsolódni a kliens.

Bye Bye Nyuszifül