rtorrent through a proxy - ssh

It's not that much of a question, rather a confirmation that what I did is right or not and if it is safe or not.
Until now what I have found googling around is that you cannot run rtorrent through a proxy. You can either put the http request through a proxy, or tsocks, in both cases either the actual transfers are done directly or not done at all. Therefore until now the only proposed viable solution is a VPN which I wanted to avoid.
What I did was use an http proxy for the http part and a port forwarding for the actual download part. For example, lets assume the following:
192.168.1.10 --> Local machine with the actual rtorrent
remote.machine.com --> The remote machine used as a proxy
Procedure:
I created 2 ssh tunnels
ssh -N -D 9090 user#remote.machine.com
ssh -R 9091:localhost:9091 user#remote.machine.com
From the local machine I installed polipo as the html proxy and configured it to use a socks proxy in the remote.machine.com.
I edited the following lines in /etc/polipo/config so that I can get the socks proxy.
socksParentProxy = "localhost:9090"
socksProxyType = socks5
I also changed the html proxy port for extra security, again in /etc/polipo/config
proxyPort = 9080
On the local machine I changed the ~/.rtorrent.rc as following:
#Proxy of the http requests through polipo
http_proxy=localhost:9080
# The ip address reported to the tracker.
#Really important, in order to get connections for downloads
ip = remote.machine.com
# The ip address the listening socket and outgoing connections is
# bound to.
bind = 192.168.1.10
# Port range to use for listening.
port_range = 9091-9091
# Start opening ports at a random position within the port range.
port_random = no
The system seems to work. I connect to the trackers and I have up and down traffic. So the questions are:
Am I safe that all the traffic concerning rtorrent is done through the remote.machine.com?
Did I miss something?
Are there any problems or concerns regarding this method?

As far as I see, you have covered inbound connections, as well as outgoing HTTP traffic, but any outbound peer-to-peer connections will be created directly, not through any tunnel. Currently, rtorrent does not appear to support passing outbound P2P connections through a tunnel or proxy of any kind, so in order to handle these, you'll need some other mechanism.
You mentioned tsocks and that it does not work – not even in addition to the rtorrent configuration you have set up above? (Although with tsocks you should be able to drop the HTTP proxy part.)
If that fails, there are alternatives to tsocks mentioned on the tsocks project page. A slightly more involved alternative would be to create a new loopback interface (lo:1 with IP 127.0.0.2), bind your rtorrent to that one and use something like sshuttle to direct all traffic originating on that interface through an SSH tunnel. Unfortunately, sshuttle doesn't let you restrict its operation to a specific interface at the moment, though, so you'd have to fiddle with the iptables rules it creates to make them match your needs. I assume a patch adding this feature to sshuttle would be welcome.
As a side note, you can create multiple port forwards and SOCKS proxies in a single SSH connection, like this:
ssh -N -D 9090 -R 0.0.0.0:9091:localhost:9091 myself#my.example.com

Related

How SOCKS5 infers the destination port within SSH dynamic forwarding?

When using local forwarding we are free to pick destination port:
ssh -L 8000:10.10.1.11:80 user#192.168.56.102 - 80 is destination port - we explicitly specify which port to forward to.
Take a look at diagram in this article. If I understand correctly, in dynamic forwarding destination port is somewhat implicit (?):
ssh -D 8080 user#192.168.56.102 - 8080 is local host port, but still it somehow forwards to 80 for us.
Questions:
How SOCKS5 proxy knows which port to forward traffic to?
Does SOCKS5 proxy somehow sniff destination from the protocol of the traffic it proxies?
Can that destination port be configured?
Where is it configured - on my local machine, or remote that does final forwarding for us? Nowhere?
Is it a predefined fixed set of protocols/ports? Smth like http=80 destination port?
Any other internal details of forwarding you can add to clarify the picture.
thanks.
PS. Here https://unix.stackexchange.com/questions/213213/difference-between-local-port-forwarding-and-dynamic-port-forwarding#comment401063_213219 i found some hint to what i'm interested in, pity there are no details provided...
SSH and SOCKS are two completely different and unrelated protocols. But, to answer your questions:
How SOCKS5 proxy knows which port to forward traffic to?
A SOCKS client explicitly tells it where to connect. The destination host/ip and port are input fields in the SOCKS CONNECT command. So, there is no guessing/infering at all.
Does SOCKS5 proxy somehow sniff destination from the protocol of the traffic it proxies?
No. SOCKS is just a tunnel of raw bytes, it has no concept of protocols beyond its own.
Can that destination port be configured?
Not on the proxy itself, no. Since the client decides where to connect, any configuration would be on the client side.
Is it a predefined fixed set of protocols/ports? Smth like http=80 destination port?
No.
Any other internal details of forwarding you can add to clarify the picture.
Read the SOCKS protocol specs.
SOCKS v4: https://www.openssh.com/txt/socks4.protocol
SOCKS v4a: https://www.openssh.com/txt/socks4a.protocol
SOCKS v5: https://datatracker.ietf.org/doc/html/rfc1928

coturn: Need help configurating my server correctly

I am trying to set up a STUN/TURN server on my local computer for a webrtc application of me. I decided to use coturn. Note that my server is running behind a NAT.
So i fired up my Ubuntu VM and installed it. After reading through the wiki I got it working, atleast on my local network. For testing purposes, i use this site. Therefore, when i try it there with 192.168.178.25:3478, it works. When i try it with "public-ip":3478, it doesnt.
This told me, it is working locally and it should be a port/NAT issue. What i did:
1) I set the VM to Bridging
2) I opened the port 3478 on my router. To test if this is really working, i used telnet on a remote machine and it worked. Another test was that i set up a quick apache server on my local machine on port 3478 and it could be accessed from the outside. This told me that there is, or should be, not port/NAT issue and my turn server should be working.
Any ideas?
I am running my server with the following command:
"sudo turnserver -X "public-ip" -listening-port=3478 -v
The turnserver.conf looks something like this:
fingerprint
realm="myRealm"
lt-cred-mech
user=test:test
As telnet and apache server are both working, i am pretty sure i have a configuration issue. I basically spent the weekend trying and im really lost on what could be wrong.
Thanks for any help!
From the documentation of turnserver
-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X ", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used.
So, it is not enough that you expose only the listening port from the inside LAN to the public network but all ports that you are going to use to relay. Please, note what is said in the same documentation:
--min-port <port> Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port <port> Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
You should choose a range of ports in the server, configure with them the options --min-port and --max-port and create a NAT rule to expose those ports to the public side of the router without change.

UDP port forwarding using xinetd

I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.

DNS through socks proxy. How do I change windows settings for domain resolution.

I am looking for a program to reroute windows domain resolution lookup through a socks proxy capable with many internet browsers and internet proxies.
So far in Control Panel, Local Area Connection 1, TCP/IP Properties, I use the following DNS server addresses, preferred DNS Server, I put 127.0.0.1 and use the default in-built port request 53.
I am reading that it is possible to forward this. I can not find a program to forward it through socks 4/5. I think this is possible because Socks supports UDP.
Has anyone come up with the answer to a solution about a UDP-to-socks forwarding program capable and adapted for socks and windows DNS.
It's really quite easy to configure.
You could write your own server and set the server to listen to incoming calls to port 53 or use this program
http://dns2socks.sourceforge.net
here my sample configuration for a socks server running on 1050 and TCP / IP settings on 127.0.0.1
DNS2SOCKS.exe /la:socks.log 127.0.0.1:1050 8.8.8.8:53 127.0.0.1:53
For such a program you can have a look at dnsadblock. Their free daemon/cli app opens up a proxy server that can be configured to use a proxy/socks to communicate with the upstream server. It works since the remote endpoint listens on https which makes DOH (dns over https) possible. Config options/install instructions: https://knowledgebase.dnsadblock.com/how-to-install-and-configure-our-software/

Tunnel over HTTPS

At my workplace, the traffic blocker/firewall has been getting progressively worse. I can't connect to my home machine on port 22, and lack of ssh access makes me sad. I was previously able to use SSH by moving it to port 5050, but I think some recent filters now treat this traffic as IM and redirect it through another proxy, maybe. That's my best guess; in any case, my ssh connections now terminate before I get to log in.
These days I've been using Ajaxterm over HTTPS, as port 443 is still unmolested, but this is far from ideal. (Sucky terminal emulation, lack of port forwarding, my browser leaks memory at an amazing rate...) I tried setting up mod_proxy_connect on top of mod_ssl, with the idea that I could send a CONNECT localhost:22 HTTP/1.1 request through HTTPS, and then I'd be all set. Sadly, this seems to not work; the HTTPS connection works, up until I finish sending my request; then SSL craps out. It appears as though mod_proxy_connect takes over the whole connection instead of continuing to pipe through mod_ssl, confusing the heck out of the HTTPS client.
Is there a way to get this to work? I don't want to do this over plain HTTP, for several reasons:
Leaving a big fat open proxy like that just stinks
A big fat open proxy is not good over HTTPS either, but with authentication required it feels fine to me
HTTP goes through a proxy -- I'm not too concerned about my traffic being sniffed, as it's ssh that'll be going "plaintext" through the tunnel -- but it's a lot more likely to be mangled than HTTPS, which fundamentally cannot be proxied
Requirements:
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
I have or can write a simple port forwarder client that runs under Windows (or Cygwin)
Edit
DAG: Tunnelling SSH over HTTP(S) has been pointed out to me, but it doesn't help: at the end of the article, they mention Bug 29744 - CONNECT does not work over existing SSL connection preventing tunnelling over HTTPS, exactly the problem I was running into. At this point, I am probably looking at some CGI script, but I don't want to list that as a requirement if there's better solutions available.
Find out why the company has such a restrictive policy. It might be for a good reason.
If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.
To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.
If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECT to port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but then you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.
You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.
Try a rule like this:
iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 443 -j REDIRECT --to-port 22
Where 111.111.111.111 is your office computer's ip address.
That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.
Documentation for iptables is at http://www.netfilter.org.
Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)
Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.
I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.
Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.
How about using 2 IP adresses on your machine?
Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?
Could you set up a middle man?
Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.
It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.
I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?
Proxy tunnel may be your answer
http://proxytunnel.sourceforge.net/
lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37
I would add this to my local ssh config
Host host.domain.tld
ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p
ProtocolKeepAlives 30
See:
SSH Through or Over Proxy
http://daniel.haxx.se/docs/sshproxy.html
http://www.agroman.net/corkscrew/
Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.
See http://chm.duquesne.free.fr/blog/?p=281 for details.
Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)
Is it possible to bind your HTTPS server to a different port? Depending on what it's used for, you may even be able to get around the problem of not being able to directly access it from work by just SSHing home and then using lynx from there.
So, then, give proxifier a try (- it supports HTTP Proxy Server)!
http://www.proxifier.com/documentation/intro.htm
I managed to bypass my company's firewall using the following design via AjaxTerm, it works for me.
PC on company network --> company's proxy via https --> INTERNET --> My home Apache reverse proxy server on SSL + .htpasswd protection --> AjaxTerm Server(From here on ward, I can SSH to any other servers ).
Still not the perfect world... would be good if I can can tunneling to my home network via HTTPS.