Advertisement
     
 
 
Search:
General | Linux Hacking | Linux Networking | Linux Security | Windows Hacking
       
Torrents and SSH Tunnels PDF Print E-mail
Written by gr00ve   
Thursday, 26 June 2008

After the collapse of Napster, with places like donkax and the one and only original html suprnova, a brand new era of file sharing was upon mankind. Switch from the regular p2p networks to bittorrent seemed somewhere along the lines of changing a beat up dodge for a shiny new ferrari (blond included). Lightning fast and error free transfers of premium content, which previously took ages to receive and distribute now flowed like the precious spice throughout the filesharing galaxy. Luckily emperors were too busy to notice, while they were raping those poor few pioneers behind “napster like” p2p networks and and dump ftp “owners”, that a whole lot besides regular file sharing in its traditional sense, was going on. Spiraling out of control a brand new fully blown culture of file sharing was finding its ways into every other way of society. It was no longer something only a few chose to participate in, the event truly took a firm place, in average persons life, somewhere between the toaster and tv.

 


Not surprisingly “the industry” had little good to say to something which infringed on its own very very sacred place in our lives. Humans as far as society trends are concerned, are amazingly foolish beings - while progressively developing in one layer consciousness and awareness, we totally stall in a number of directions which potentially offer great advancement possibilities to human race and to some extent progress as we know it. Anti p2p campaigns of present remind of holy crusades, with noticeable difference that not only some enemy is fought somewhere out there but also one's loyal subjects are treated just like the enemy. So while a lot of nations these days claim to be democratic (which for the sakes of the argument is supposed to be the top in the evolution link) in reality - in many aspects of life we really are just a little out of dark ages. A lot of potentially bad things started with 2 factors “...it is the leaders of the country who determine the policy and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. ” (from Nuremberg trial archives), or the corporate world in modern business which to my view reflects much what world used to be like last century. Technological progress simply develops faster than society can adapt, so instead of evolving at faster pace there are those few with most influence which tend to for one reason or the other hold the majority back, getting them exploited to the most extent possible along the way of course.

So as the industry rushed into brand new battlefront for much controversial reasons, several developments also occurred in the heartland of the Internet – the ISP land that is. Bittorrent phenomena revealed yet another weak link in our democracies [which in theory should self adjust to such obstacles], developments with growing traffic were far from promising because for little over a decade, the industry sold broadband to the masses without those masses actually using up their broadband potential to the max. And now some hypothetical filesharing traffic transformed into very real numbers, which didn't look good at all to the industry, since investment into better technology to support the growing demand would very likely transfer to some corporate royal ass kicking – it is simply not in the interest of maximizing revenue given that forceful measures are readily available. So what does this industry do? Well they looked around and what they've found was a fellow king fighting the holy crusade and burning witches one by one, so naturally the “why should we be any different if the masses don't mind a couple of burned witches too much” times the new mass burning technology and there we have it - all kinds of p2p traffic restrictions from isps.

[p2p armor]

There are a number of headaches to the p2p netizens – privacy concerns and availability of the p2p services are among the few first ones. Privacy is a problem for a simple reason that no matter how distributed the transfer network is, in the end your upload/download node will always be visible to the interested parties. Then there is a problem with those resources carrying user identifiable logs which might find their ways to the “other side”. Finally there is a potential problem with information leaks at intermittent nodes between the source and destination of the p2p traffic. Availability of the p2p service pretty much boils down to p2p traffic being somehow tampered with before it actually reaches the p2p network in either direction.

When thinking of hiding one's IP from the rest of the world surely proxies of some sort or fashion pop into the picture. Traditional socks proxy concept takes care of this problem to the most extent if traffic is viewed upon as being exchanged from client to proxy and then to the other party and visa versa, so the real ip does not interact with the other party directly, but through an additional layer of communications. This was now widely adopted by a number of “anonymizing” services from free Tor network (which must never be used for torrents!) to commercial BTGuard like services. There is however a problem with the latter - this kind of service is undoubtedly good for public tracker resources but it offers no way of connecting to private trackers. Mostly this happens because private trackers will require you to login to their site, they then allow ip from which login originated to interchange data with others on their network. Another problematic point with this approach is such that communication between the client and the service is very much readable and open to any tampering. So while effectively hiding your ip, you might fall into the trap of having traffic tampered with before it reaches the proxy. Most modern clients like utorrent, azureus and deluge have an option to fully encrypt incoming and outgoing traffic. So this is a good additional step in making it harder to tamper with traffic [not encrypted traffic - dns queries as well as browser info exchange with the host of torrent origin].

More effective mechanism is another layer of encryption, offered by such services as Relaks or Torrentfreedom, there you basically create a vpn connection which tunnels all of your traffic to their servers, from there on it travels the internet “as is” outside the tunnel. For reference – some isp's specifically do not allow vpn connections from their networks, (where it is officially prohibited by tos/aup) the line pretty much drops instantly as soon as vpn tunnel was established. Finally p2p netizens have an option of running secure connection to a rented virtual private (dedicated) server.

Surely a physical server would do a much better job comparing to a virtual image, but costs come into concern so the virtual option is significantly cheaper (less then 10$ a month in some cases). Virtualization comes at a price of having lesser resources available for the money, therefore all kinds of windblowz installations are largely out of the topic much like gui effect rich desktop environments of modern linux distributions due to cpu/ram constraints. Resource usage literally has to be kept to the minimum, concentrating on having enough resources supplied to the services which will assist with p2p.

Such virtual server needs to supply encryption as well as act as a web and socks proxy. Typically, out of the box installations of VPS/VDS providers come significantly stripped and optimized to offer the very bare minimum installation possible. For the sakes of example ubuntu was used, so server with original installed base occupying about 240mb's of space. Out of the box service remotely accessible for further setup is ssh, so this is how such server will be configured. There are a number of ssh clients out there, rumor has it that putty rocks but feel free to use whatever you like. Establishing connection to the ssh server is also easy enough and there are great many tutorials out there on how to do so.

[setup]

So there you have it – a big black box of established connection with root@yourbox and a cursor. Next thing to do would be to install all the software required to p2p it through the rented server. Luckily this became all too easy now with package management tools requiring 0 configuration or compiling. Ubuntu has yum and apt-get to cover the bases, installation is as simple as yum update, then yum install stuff or apt-get update and then apt-get install stuff. Some initial configuration will likely require editing configuration files, so either get familiar with vi / nano editors, or jump into installing midnight commander by apt-get update update and then apt-get install mc. MC's minimalistic ncurses interface will help you browsing the filesystem as well as editing files.

1)Navigate to /etc/ssh and open sshd_config for editing, for the moment only change (add if missing) following right after GSSAPI options: X11Forwarding yes and AllowTcpForwarding yes; after this save the file and run /etc/init.d/ssh restart, logout of the server's session.

2)Next in putty load your hopefully saved session, expand SSH, X11 and select Enable X11 forwarding, selecting remote X11 authentication protocol as MIT-Magic-Cookie-1. What this does is this enables any gui application located on the server to run under your local X11 server. Windows folks without the X11 pleasures might want to check “X11 Forwarding over SSH using X-Deep/32 and PuTTY”. There is of course very little need to install graphical applications to the server which is meant to be guiless, but chances are not every other reader will like tuning iptables by hand, so this is just to make things simple.

3)apt-get install iptables conntract libnetfilter-conntrack1 firestarter will help with getting the box locked down before further setup takes place. Once installed start firestarter, which if all was configured ok will start using your local X11 server.
3.1) Policy inbound – allow connections from host = add your client ip which will run torrents. In case you happened to have a dynamic ip, get one of the free dns services to have a pointer to you and input dns name instead of ip address. Also add allow service – ports 36881-36889 – everyone and a couple of other ports for torrentflux.
3.2) Edit preferences – under interface > events = enable all opitons; under Policy enable all options; Firewall > icmp filtering = mark checkbox for enable icmp filtering; Firewall > ToS Filtering = mark enabled, for servers & X Window, prioritize for Throughput; Firewall > advanced options > mark drop silently and check all below that.

4)Edit /etc/hosts.deny to have ALL: ALL and then /etc/hosts.allow to have ALL: YOURPUBLICIP ALL: PRIVATEIPOFYOURCLIENT.

5)apt-get install xinetd.

6)apt-get install mysql_server apache2 php5 php5-mysql torrentflux phpMyAdmin squid dante-server.

7)Edit /etc/mysql/my.cnf to have key_buffer, max_allowed_packets, thread_stack, query_cache_limit set to 128K & query_cache_size set to 1MB.
7.1) /etc/init.d/mysql start and then mysql_secure_installation removing testdb and user/access to such, while having root login remotely disallowed. Adding a non root user is an extremely good idea.

8)Edit /etc/apache2/apache2.conf to have StartServers, MinSparseServers set to 1 and MaxSparseServers set to 2 with maxclients = 10.
8.1) /etc/init.d/apache2 restart.

9)Create a db for torrentflux in phpMyAdmin and import /usr/share/doc/torrentflux/dbfiles/mysql.gz there.
9.1) chmod -R 777 /var/cache/torrentflux.

10)Edit /etc/danted.conf to include >> client pass { from YOURPUBLICIP/0 port 1-65535 to 0.0.0.0/0 }.

11)Edit /etc/squid/squid.conf to include (right below acl all src) acl tor src YOURPUBLICIP, then scroll down to http_access where you will need to add http_access allow tor. [note as alternative to squid, just drop one of the php based proxy scripts into www/html directory of apache]

12)One final edit to /etc/ssh/sshd_config, add Port 443 right below 22, add GatewayPorts yes right below AllowTcpForwarding yes, also change KeepAlive to yes. Set Protocol 2, UsePrivilegeSeparation yes, StrictModes yes, remove # character (uncomment) from beginning of the line AuthorizedKeysFile, ChallengeResponceAuthentication yes, PasswordAuthentication no, UsePAM yes.

13)Next generate a public/private keypair at the client side, as result you will have /home/someuser/.ssh/id_rsa & id_rsa.pub.

14)On the server create a non root user via useradd (remember to use the home dir flag), navigate to /home/user/.ssh and run touch authorized_keys.

15)From the client side run scp /home/someuser/.ssh/id_rsa.pub ipoftheserver:/home/user/.ssh, then one the server do cat id_rsa.pub >> authorized_keys.

16)apt-get install logwatch. Edit /etc/logrotate.conf to include daily instead of weekly, rotate 1, compress. Reboot the server.

Once rebooted /given that all configs worked out ok/ such server will have squid serving as proxy for the browser and dante can be used as socks4 server. These are good to share between several people to not broadcast the real ip addresses to the swarm/tracker. Encryption from client side's is available via autossh in the form of:
autossh -M 40511:40522 -i /home/localclientuser/.ssh/id_rsa -2 -R 36881:localhost:36881 -R 36882:localhost:36882 -R 36883:localhost:36883 -R 36884:localhost:36884 -R 36885:localhost:36885 -R 36886:localhost:36886 -R 36887:localhost:36887 -R 36888:localhost:36888 -R 36889:localhost:36889 -D 9920 -N -T -p 443 nonrootuserattheserver@serverip

If you would like to (and you do) use squid encrypted add -L 3128:serverip:3128 right after the last -R switch above. Edit browsers preferences to have proxy specified as localhost:3128, edit your favorite bittorrent client [deluge!] configuration to use socks5 proxy at 127.0.0.1:9920 and ports 36881-36889 for communication. Finally don't forget about torrentflux as your means of downloading directly to the rented server :) thus using up bandwidth not capped by your client line's upload/download limit. Use either scp or rsync to transfer files off the server. Another way to increase usable space directly on the server would be to mount some ftp share from client to the server, but again this connection is subject to speed limits of the client.

This kind of setup has a lot of applications and will bypass various restrictive measures. Much like most of todays privacy measures it is not perfect, but it will help at least to some extent. Comparing to readily available zeroconfig services, it might at first seem more complex to setup, but in reality it takes around 40mins to do all of this from scratch and it is still cheap comparing to other commercial setups especially if shared among several people. Ohh yeah and welcome back demonoid!


Add as favourites (677)

  Comments (2)
Written by Jimmie, on 26-06-2008 20:23
thanks!
Written by stefan, on 08-11-2008 04:02
very good article,thx!

Write Comment
  • Please keep the topic of messages relevant to the subject of the article.
  • Personal verbal attacks will be deleted.
  • Please don't use comments to plug your web site. Such material will be removed.
  • Just ensure to *Refresh* your browser for a new security code to be displayed prior to clicking on the 'Send' button.
  • Keep in mind that the above process only applies if you simply entered the wrong security code.
Name:
Comment:

Code:* Code

 
< Prev   Next >
 
© Copyright 2002-2008 - Linux Exposed - Sponsored by ConsultPlanet http://www.consultplanet.nl - Contact Linux Exposed