Setting up your new external account

Introduction

Simple, but inconvenient ways of bypassing the censor exist (and have been discussed elsewhere on this site), but these are restrictive and difficult to use. The best methods involve an external ISP shell account. This page describes the general techniques with a specific example. For details concerning specific accounts, see recommended accounts

Possible strategies

There are several ways to use such an account. All of these involve a certain amount of setup and configuration. I'll start with the easiest (but not the best!) and work along as I get the time.

Some strategies involve simply arranging for web access to bypass a censoring proxy, while others are more general and will allow this as well as bypassing blocking on other ports, to allow access to other censored services (e.g. Usenet news, Internet telephone etc.).

I hope to discuss and implement the following methods (and some extensions of these):

• ssh as a redirection server
• rinetd as a redirection server
• junkbuster
• http-gw
• VPNs
• stone as both a redirector and a proxy
• running a Perl proxy

Implementation

ssh as a redirection server

Ssh is a very flexible tool for our purposes. Not only can it be used to log into your external account, but it can set up a tunnel for your requests. This means that packets go in at one end and pop out the other and proceed on their way as if nothing special had happened. This is useful for bypassing packet filtering (on, for example, port 8080 as practiced in the UAE to stop you using public access, uncensored proxies outside the country). It works because ssh tunnels everything through port 22 (by default) and port 22 is not blocked. But I'm not about to use even this much of the functionality of ssh to get you set up with a redirection server which will (seem to) do everything you need for web browsing, Usenet news etc. Extensions later will add a few things you didn't know you needed.

Here's a simple way to use it, which has the disadvantage of not being encrypted. I don't think this is such a big deal because it's on a strange port and isn't being logged by the censoring proxy. Anyway, it's a start and you can build from the understanding this will give you. It's simplicity will (surely) encourage you to get the external account, if you haven't already done so!

So the concept is clear, I've listed the basic steps first and then follow with implementation details and an example.

1. get an external shell account with sshd capability.
2. login to your external shell account
3. choose a fast public proxy to use.
4. run ssh on the external account to listen on a port of your choice and redirect anything heard on that port to your public proxy.
5. configure your web browser to use the address of your shell and the port you chose as a proxy
6. surf!

Implementation details:

1. telnet, ssh, secureCRT, even a web cgi that executes a command will do. You MUST be able to do this or you wouldn't even have the account :-). Let's say your external account is at panix.com. On this one, you will need to get a shell prompt ($) by typing ! because they put you in a 'user-friendly' menu when you logon. You can configure this later.
2. get the fast public access proxy from one of the lists on the net or on my page (https://www.angelfire.com/wy/1waynes/, then go to 'setting up the external account'. Let's say you choose 194.85.132.86 on port 3128. You could not normally get to this proxy from within the UAE since direct access to port 3128 is blocked.
3. In the example we're using we'll listen on 12000. So, (in your external shell), type:

   ssh -R 12000:194.85.132.86:3128 nether.net

   It will ask for your password - enter it. You should end up at a shell prompt again. Essentially what's happening here is that you are logging in again! But this time you are telling ssh to forward all the port 12000 activity to 194.85.132.86. There are many other ways to do this - and this is the essential step which allows your requests to bypass the packet filtering in the UAE/KSA (they don't block 12000, and if they ever do, you can choose another one).
4. Back home, configure your web browser to use this as a proxy. There are two important things here: you must stop the autoconfiguration (set up by default in browsers set up with the Emirates Internet disks) and you must specify to use a proxy with the external isp as the address (the address of your shell account) and the port as 12000. In IE5 be sure you are changing the settings for the dialup connection (not the lan connection, unless this is what you are really using, of course).
5. Please choose a random port (not 12000) once you're sure it all works. Any port (which is not accidentally in use by someone on the ISP already) over 1024 and below 65535 will do. If it doesn't work, you may have chosen a port which is blocked - see my blocking by country page for a list of these for the UAE, KSA etc.

Rinetd as a redirection server

Rinetd is a nice little redirection server written in in C. It allows you to listen on your host at a given set of ports and have your connection to those redirected to other host/ports. Set one unblocked port up to redirect you to a good, fast, public proxy and another (for example) to redirect your requests to a public access Usenet news server. If your host account has either of these, use that.

Details TBD

Junkbuster

TBD

http-gw

TBD

VPNs

TBD

Redir

Redir is another redirection server written in C. It sets up in a default manner on Panix (NetBSD) and can be set up as described below on Sun OS systems such as nether.net (a free account). I intend writing a Perl script to ensure a trouble-free installation on any system, but for the moment, for those with some Unix abilities, here's the setup for nether.net. If anyone can streamline this for me, I'd appreciate the hints - it's a hack at the moment. Please tell me about bugs, so I can make this work for everyone.

1. get your new account, by telnetting to nether.net, login as 'newuser', specify a Bash shell.
2. get redir and unpack it with tar zxvf redir-2.1.tar.gz; cd to the redir directory (where the Makefile is)
3. cd getopt
4. gcc -O2 -Wall -c getopt.c
5. gcc -O2 -Wall -c getopt1.c
6. cp getopt.h ..
7. cd ..
8. edit redir.c line 62 to say "getopt.h", instead of
9. edit the Makefile to use all the OBJS (remove all the '#'s in this line. Also edit to use all the LIBS, but remove the '-lwrap' lib completely.
10. make Makefile
11. you may get some errors, but they can probably be ignored. You should now have a runnable redir
12. start it up by typing: ./redir --lport=12000 --cport=3128 --caddr=216.40.128.3 &
13. don't log off!
14. back home, configure your browser to use nether.net:12000 as the proxy and surf away.

Stone

Stone is a really nice redirector. If you get this one running, you won't need to look for another one. It's a tcp AND udp redirector, it can be a web proxy all by itself (no need to find other proxies to point it to), it's non-forking by default (no problems with bugs causing runaway or zombie processes to get the ISP mad at you), and if you compile the SSL version (harder to do) it will encrypt the connection between you and it. What more could you want? I recommend this over all of the other redirectors I've listed.

The SSL version requires you set up openSSL and md5c.c etc. which is all a bit difficult to describe in a simple recipe etc., so I won't go into it now.

The normal build (no encryption)

It can be used the same way as redir, ssh -R etc, of course. ./stone -h will give a complicated list of commands, Take a look at the Stone home page for some examples.

Perl proxies (and redirectors etc.)

Pfproxy is a web proxy all by itself (no need to find other proxies to point it to);

How to run pfproxy

Aseef has written a page which describes in excruciating detail, the steps needed for anyone to run this thing. It's good work, and guides you through the steps for getting a shell account, logging on, common Unix commands, etc. as well. This is certainly the easiest way to make an http proxy. Note pfproxy doesn't offer news, IRC etc. like the redirectors above.