Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
zakładając że w .rtorrent.rc mamy m.in.
port_range = 10001-10001 dht_port = 20001
i iptables z polityką blokowania
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP
jakie reguły dodać do iptables żeby rtorrent działał bez przeszkód?
Ostatnio edytowany przez hurlmann (2013-01-02 03:14:30)
Offline
Sznurek:
http://pl.wikibooks.org/wiki/Sieci_w_Linuksie/Netfi … s#Dopasowania
PS,
Na tym forum było o tym XXX razy.
Offline
Chyba nieprecyzyjnie się wyraziłem. Orientuję się o tyle o ile w konfiguracji iptables. Problem w tym że, nie ogarniam przepuszczenia rtorrenta (czy wogóle jakiegokolwiek kliena torrent) przez firewall.
W moim przykładzie rtorrent używa jednego tylko portu (10001) plus drugi dla dht (20001). Jak rozumiem odbokowany musi być ruch w obydwie strony czyli:
iptables -A OUTPUT -p tcp --dport 10001 -j ACCEPT iptables -A OUTPUT -p udp --dport 20001 -j ACCEPT iptables -A INPUT -p tcp --dport 10001 -j ACCEPT iptables -A INPUT -p udp --dport 20001 -j ACCEPT
do tego
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
niestety to niewystarcza więc gdzieś jest błąd albo czegoś brakuje i tu moje pytanie.
Offline
Zobacz to:
http://ubuntu.pl/forum/viewtopic.php?f=150&t=103825#p613705
Z tym zastrzeżeniem, że zamiast:
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
teraz używa się:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Moduł state wyleciał z nowszych wersji kernela i iptables, zamiast niego używa się modułu conntrack.
Offline
Nic już z tego nie rozumiem. Już samo przepuszczenie wychodzących + powiązanych przychodzących, powoduje że rtorrent działa (przynajmniej download, upload nie sprawdzałem):
iptables -P OUTPUT ACCEPT iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
wcale nie potrzeba:
iptables -A INPUT -s 0/0 -p tcp --dport 10001 -j ACCEPT iptables -A INPUT -s 0/0 -p udp --dport 10001 -j ACCEPT iptables -A INPUT -s 0/0 -p udp --dport 20001 -j ACCEPT
Problem w tym że, na codzień trzymam OUTPUT zamknięty i przepuszczam tylko to co trzeba:
(...) iptables -P OUTPUT DROP (...) iptables -A OUTPUT -p udp --dport 53 -d 208.67.222.222 -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -d 208.67.220.220 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT itd itp
Myślałem, że przepuszczenie torrentów sprowadza się po prostu do otwarcia kolejnego portu dla przychodzących i wychodzących, tak jak napisałem w poprzednio, ale to nie działa. Czy koniecznie cały OUTPUT musi być odblokowany?
Offline
Spróbuj na otwartym OUTPUCIE, czy działa.
Generalnie masz firewalla z kontrolą stanu pakietu, jeśli blokujesz INPUT, a wpuszczasz tylko nawiązane z kompa połączenia śledzone przez conntrack, to firewall masz prawidłowo skonfigurowany,
Żeby używać filtrowania OUTPUT, trzeba dużo więcej doświadczenia, bo całlkiem sporo programów komunikuje się na różnych portach, a P2P zazwyczaj działa praktycznie na każdym porcie, na jaki się wbije.
Dodatkowo różni pacjenci ustawiają torrenty na rożnych portach (u siebie), nie ma na to reguł.
Listę protokolów sieciowych i domyślnych portów masz w pliku /etc/services.
Także rtorrenta wypuść na cały zakres powyżej portu 1023 (do 1023 są usługi sieciowe, jak http czy poczta, które można atakować atakiem ddos przy pomocy torrent, a sztuczką hakerską, w czym twój rtorrent mógłby uczestniczyć, gdybyś go puścił na port np 80 lub 993, czy podobny port powszechnie używanej usługi sieciowej).
Taki numer można wyciąć podrzucając odpowiednio spreparowane ziarno albo modyfikując trackera (o ile pamiętam, ale słabo pamiętam, jak to dokładnie działało).
W każdym razie torrenta się wypuszcza na porty 1024:65535.
Jak w ten sposób obciąć rtorrenta? - osobny user systemowy i moduł iptables owner:
RTFM:
iptables -m owner --help
Ostatnio edytowany przez Jacekalex (2013-01-03 02:27:02)
Offline
Ok, czyli jeszcze raz:
1) W przypadku p2p OUTPUT w zakresie 1024:65535 musi być zawsze otwarty, ponieważ różni użytkownicy ustawiają różne porty w swoich klientach (często są to domyślnie porty z zakresu 6881-6999, ale jeszcze częściej może być to cokolwiek innego).
Czyli jeżeli ja mam w iptables otwarty OUTPUT dla 6881-6999, a ktoś w swoim dajmy na to transsmisionie ustawił port na np 56789, to nie będę w stanie od niego pobierać. Czy tak?
1,5) Znalazłem informację że trackery bittorent używają domyślnie portu 6969. Czyli analogicznie jak powyżej muszę przepuścić 6969 OUTPUT bo nie będę w ogóle mógł połączyć się z trackerem, tak?
Czy ten 6969 to rzeczywiście norma dla trackerów czy w praktyce jest to robta co chceta?
2) Dawniej w iptables, -m owner oferował takie rzeczy jak:
--uid-owner {userid/username} Matches if the packet was created by a process with the given effective username.
--gid-owner {groupid/groupname}: Matches if the packet was created by a process with the given effective group id.
--pid-owner {processed}: Matches if the packet was created by a process with the given process id.
--sid-owner {sessionid}: Matches if the packet was created by a process in the given session group.
--cmd-owner {name} : Matches if the packet was created by a process with the given command name.
Używając ostatniej opcji można było otworzyć OUTPUT 1024:65535 tylko i wyłącznie dla konkretnej aplikacji - np rtorrenta.
Niestety od kernela 2.6.14. z jakichś powodów -m owner został wykastrowany i obecnie dostępne są tylko 2 pierwsze opcje z powyższej listy.
Więc jeżeli ktoś chce mimo wszystko przymknąć jako tako OUTPUT ale też jednocześnie używać torrentów, powinien:
- utworzyć w systemie specjalnego usera "MEGAMASTERTORRENTHEJ"
- dodać dodać do iptables:
iptables -A OUTPUT -p tcp --dport 1024:65535 -m owner --uid-owner MEGAMASTERTORRENTHEJ -j ACCEPT iptables -A OUTPUT -p udp --dport 1024:65535 -m owner --uid-owner MEGAMASTERTORRENTHEJ -j ACCEPT
W ten sposób OUTPUT 1024:65535 jest otwarty tylko dla aplikacji uruchomionych przez usera MEGAMASTERTORRENTHEJ. Dobrze to rozumiem?
2.5) Czy istnieją jakieś alternatywne sposoby ograniczenia/umożliwienia dostępu do sieci konkretnym aplikacjom ? (coś w stylu --cmd-owner {name})
3) Z tego co zauważyłem wystarczy jedynie otworzyć OUTPUT żeby móc normalnie pobierać. Nie potrzeba wcale otwierać W INPUT zakresu portów jakie ustawione są w kliencie torrent. Jak rozumiem jest to możliwe dzięki regule:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Domyślam się jednak, że przy takim ustawieniu upload nie będzie działał, ponieważ nowe połączenia przychodzące od ludzi chcących coś pobrać będą odrzucane. Dlatego do uploadowania trzeba jeszcze przepuścić w INPUT port(y) ustawione w kliencie torrent. Tak czy nie?
4) Jak do tego wszystkiego mają się protokoły? Czy wystarczy przepuszczenie samego tcp czy trzeba również udp?
to już znalazłem - trzeba przepuścić obydwa
Ostatnio edytowany przez hurlmann (2013-01-04 16:11:02)
Offline
Cześć, przepraszam za podpięcie się do tematu, ale chciałbym zapytać - a właściwie otrzymać potwierdzenie - kolegi Jacka, czy owa zmiana -m state na rzecz -m conntrack dotyczy absolutnie wszystkich reguł w których korzystamy, bądź zamierzamy skorzystać, właśnie z tych modułów? Tak więc, np. reguła blokująca pakiety INVALID ma przyjąć teraz formę; iptables -A INPUT -m conntrack --ctstate INVALID -j DROP? Wcześniej, wykorzystując moduł state, w/w zapis mógł wyglądać w następujący sposób; iptables -A INPUT -p all -m state --state INVALID -j DROP.
edit: Mógłbyś doprecyzować, które konkretnie wersje masz na myśli, pisząc "moduł state wyleciał z nowszych wersji kernela (...)"? Rozumiem, że dotyczy to oczywiście wydań oznaczonych numerkiem 3.X.
Ostatnio edytowany przez remi (2013-01-05 20:05:40)
Offline
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT WARNING: The state match is obsolete. Use conntrack instead.
iptables --version iptables v1.4.16.3
W której wersji wyleciał dokładnie, nie wiem, w Iptables 1.4.13 jeszcze był, w 1.4.15 już nie.
Także najprawdopodobniej w *.14 lub *.15.
Ja aktualizowałem od razu z 1.4.13 na 1.4.16.
zgrep -i match_state /proc/config.gz CONFIG_NETFILTER_XT_MATCH_STATE=y uname -r 3.7.1-gr2
W jaju moduł state jeszcze jest, ale cóż z tego, jeśli firewall go nie trawi i sypie ostrzeżeniami?
Ostatnio edytowany przez Jacekalex (2013-01-05 23:00:44)
Offline
boo hoo a mi nikt odpowiedzieć nie chce...
Offline
Serwus! Jacku, dziękuję serdecznie za wyjaśnienia.
Offline