Page 1 of 1

Socks5 proxy iptables rules / "kill-switch"

Posted: Tue Jun 12, 2018 11:00 am
by mhertz
I've just reverted to using deluge and a socks5 proxy, instead of rtorrent/VPN. I prefer a socks5 proxy because it's overkill to me to use a VPN for torrenting only. You use alot of CPU cycles for nothing really and need extra stuff running in background and if you use split-tunnel and only use VPN for torrenting, then it's just a glorified proxy anyway imho.

The reason for using a VPN instead of proxy(for torrenting), is to mask your downloads for the ISP too(encryption), but after an abundance of research, i'm pretty sure the ISPs don't do DPI for analyzing what specifically you're downloading, and so it's only the copyright-trolls we need to hide from, which a proxy does. Second reason, is still a valid one imho, and that is for if you're being shaped/throttled, which would make all that extra encryption done, actually have a real purpose instead of just a tinfoil-hat one(forcing encryption in torrent-client limits peers).

Lastly, the last reason for preferring a VPN over proxy, is that it can potentially leak your IP, which this post is about and presenting a fix for that, so no longer applies.

I've here posted a shell-script which only lets outgoing-connections go through from your proxy and only lets incoming connections go through, on your defined listen-port, from the proxy.

Still I'll much advice to anyway use ltplugin and enable force-proxy and annonymous-mode too.

There's a single thing that this script cannot do, and that is the issue of leakage of your IP through HTTP and UDP tracker-announces optional IP field, but libtorrent hasen't defined that field for a long time anyway, + you can hardcode it with ltplugin to your proxy's IP if wanted(announce_ip). Also, even though force-proxy disables ipv6, then you can also disable that with a single command: 'sysctl -w net.ipv6.conf.all.disable_ipv6=1' The net lists you need a command additionally for each of your interfaces, but I've tested this and you don't, the single command is enough, as it's name too applies ;)

Change PROXY to one of your proxy's IP's(use this e.g. http://tejji.com/ip/url-to-ip-address.aspx) and change PORT to your defined listening-port. Also change the deluge username if needed, and note you have to run deluge under this name always for this to work, but many distro-packages by default runs deluge as deluge user e.g. arch-linux when running 'sudo systemctl start deluged.service'.

You have to run it at every boot before running deluge(I run the script and deluge from another script), unless adding it to your startup-sequence, which i'd advice, if not running it automatically from a script anyway, like me.

deluge-iptables:

Code: Select all

#!/bin/bash

sudo iptables -F
sudo iptables -A INPUT -p tcp -s PROXY --dport PORT -j ACCEPT
sudo iptables -A INPUT -p udp -s PROXY --dport PORT -j ACCEPT
sudo iptables -A INPUT -p udp --dport PORT -j DROP 
sudo iptables -A INPUT -p tcp --dport PORT -j DROP
sudo iptables -A OUTPUT -p tcp -m owner --uid-owner deluge -d PROXY -j ACCEPT
sudo iptables -A OUTPUT -p udp -m owner --uid-owner deluge -d PROXY -j ACCEPT
sudo iptables -A OUTPUT -p udp -m owner --uid-owner deluge -d 192.168.0.0/24 -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m owner --uid-owner deluge -d 192.168.0.0/24 -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m owner --uid-owner deluge -d 127.0.0.1 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner deluge -j DROP
Note, the line for the LANs is because deluge tries to connect to those, I don't know why, and you can remove the line if wanted, but i'm guessing it tries 192.168.0.1 for DNS, or else it's LSD or something.

You can check if anything was blocked, by running:

Code: Select all

sudo iptables -nvx -L OUTPUT
And:

Code: Select all

sudo iptables -nvx -L INPUT
To see what specifically was blocked(if any), then you can e..g use iptables-strace, but you need to run it first, before anything got blocked(ptables-strace start) and then if one of the two commands listed above, shows something blocked, then you can check for BLOCKED entries in your syslog or journalctl log and see src/dst IPs. Afterwards you can disable it(ptables-strace stop).

iptables-strace: https://pastebin.com/WRe1nJaX

Re: Socks5 proxy iptables rules / "kill-switch"

Posted: Tue Jun 12, 2018 8:36 pm
by mhertz
Hmm, I think I didn't think this out completely through... Damn, now i'm back to using a VPN again I think :) Typical, after spending alot of time adapting/changing scripts and whatnot :) Anyway, if you're using a proxy, then the above post for sure is a good idea and i'd fully recommend using it + force-proxy and anonymous-mode with ltplugin. However, I thought the optional IP field in tracker-announces where the only possible issue, if there ever was a bug in libtorrent, but after thinking about it some more, then there could obviously also be bugs in libtorrent where is hands out your real un-proxied IP through handshakes with PEX/DHT! The proxy-settings/force-proxy/annonymous-mode are supposed to fix that, but i'm here talking about if there ever comes a bug with that, in a later update or something. The script above will not stop libtorrent/deluge from doing that if such bug arose! It would not receive any answers back on your real IP and the port defined would appear closed because of the above script, but i'm guessing it's still enough to get you possibly listed in a copyright trolls database for infringements unfortunately! I think i'll have to make a post about this on libtorent's mailing-list and ask Arvid's help on if what I just wrote here is true, which i'm guessing it is i.e. the possibility for it, not that it's like that now.

So again, use this if you're using a proxy, and together with force-proxy/anonymous-mode, but the only thing that is 100% bullet-proof, is using a VPN and having a proper kill-switch in place, e.g. using namespaces or iptables or something alike.

EDIT: Hmm, I didn't think this post through either it seems, lol :) I realized, after checking the specs, that I don't believe DHT/PEX sends out your IP, but instead the IP is recorded from the source-address, only port is sent out for DHT, and PEX just sends out already connected/disconnected peers. So this should be fine to use anyway I think. I still wanna make a post at the libtorrent mailing-list and see if i'm mistaken in anything, because as far as I know, the IP is only sent in a package, without it first being recorded from source-address, in the case of HTTP and UDP tracker announces by use of IP field, which libtorrent doesn't set unless using announce_ip, which also could be hardcoded to proxy IP by ltplugin, and in an IPv6 extension, where there also is an IPv6/IPv4 field to be sent with packages, but force-proxy also disables IPv6 + as said in previous post, you can run a command(or set it in sysctl.conf) from your script to disable IPv6 completelly. Still, I guess, libtorrent could begin to set that field again in a later version and use your real IP by mistake, but e.g. that can always be checked from e.g. doileak.com, which shows embedded IPs, if present, for both HTTP and UDP tracker announces(I don't know if ipmagnet shows those if present). I'm still going a little back and fourth on if I should use proxy or VPN(and which client, lol!), but just wanted to add that the previous "worries" I think was unfounded. I'll update this when I get a reply from the mailing-list, when I make the post there.

Re: Socks5 proxy iptables rules / "kill-switch"

Posted: Sat Jun 16, 2018 12:31 pm
by mhertz
I've made a post at the libtorrent mailing-list about this, but I guess Arvid is busy at the moment, as no reply yet, but I have glanced again the bittorrent specs, and I cannot really see any "issues", if disabling IPv6, other than the before mentioned optional 'IP' field of tracker-announces, as all other packets with IPs comes from src-address, or lists of IPs gathered from said src-addresses.

I looked at the libtorrent tracker-anounce C++ source, and as far as I can see, libtorrent never sets the IP field if announce_ip setting is undefined/empty as per default, and if it is defined then it's set accordingly, though just not if anonymous_mode is defined.

I'll update when I eventually get a reply from the mailing-list.

Note, I ran the iptables-strace script a few times during downloads, and cought some blocked packets, even though using force_proxy and anonymous_mode, but I looked up the IPs, and they where:

Code: Select all

8.8.8.8
64.50.233.100 
239.255.255.250
The first is my defined DNS server, which I don't understand why is used, when I have proxy hostnames defined, but oh well. Second, is an IP related to deluge's own site, and it can also have a sligthly different IP resolving to same URL - it's most probably related to either auto-update checking, or the option for sending anonymous usage-statistics back to deluge. Last, is an IP correlated with UPnP.

I just wanted to add this, so anyone doesn't freak out and posts "Deluge leaks my IP!" on the forum :) Neither of these "leaks" are actual swarm-leaks. Though it could be nice to have an option like qbittorrent, where you can select to proxy everything, or just torrent(swarm)-related.

Personally, i'm still undecided in what i'm preferring i.e. VPN/namespace or proxy/iptables-hardening, but atleast i've made a new shell-script to automate the relevant changes for me i.e. 'deluge-install [vpn] [proxy] [remove]', which greatly simplifies this for me, also seeing as I changed back and fourth twice just yesterday, lol :) (Much of it, is also because I have a lifetime socks5 account already paid, and so could terminate my VPN account if not needing it)

Re: Socks5 proxy iptables rules / "kill-switch"

Posted: Wed Jun 20, 2018 8:07 pm
by mhertz
Sorry folks, last post in row, but just wanted to finish this topic properly.

When looking through the specs, I forgot the extensions to said specs also, so the answer is that even if all packets goes correctly through proxy by using force_proxy and/or iptables rules, then there's 3 places where your IP can get leaked still and which anonymous_mode should hopefully fix for us(not include in packet-headers):

Optional IP field of HTTP and UDP tracker announces.
Optional IPv6/IPv4 field of the IPv6 tracker extension(bep7).
Optional IPv6/IPv4 field of extended handshakes.

This means that i'm gonna switch to VPN run in isolated namespace(containing only tun0/lo), instead of proxy, as with a proxy we will have to count on that anonymous_mode hasen't been broken somehow in a new update, and the same with force_proxy unless using iptables to mitigate such scenario like as my first post up-top describes. Of course we could monitor every new version with wireshark, but that's a little much imho, considering there's better alternatives available.

Last thing, some believe they don't even need force_proxy as if they remove a char of there password, then the download will not work and hence, thinks that's proof for it already features force_proxy behavior, but that's false. It has been checked by wireshark, that without force_proxy, then yes, no packets gets through when failing to login, but during transfer, then if something fails, then the packets will go through normal connection if not having force_proxy enabled!

Anyway, if still using a proxy, then I would recommend using the iptables rules from first post(in addition to force_proxy and anonymous_mode), so that any possible bugs with force_proxy wouldn't get through, so half of the issue atleast is overcome, though I would also raise a point for considering switching to a more bullet-proof solution instead, using a VPN, like e.g. listed here: viewtopic.php?f=7&t=49883&p=228232#p228232 This also stops ISP throttling/shaping and possible ISP monitoring if such should take place, now or in future, in addition to being 100% secure.