[proxyTools-users] escaping a very restrictive firewall/proxy (was: Re: Hello Wayne)

[wayne <wa...@ny...>]

> Date: Tue, 17 Sep 2002 09:05:46 +0100
> From: Michael Foord <Mic...@tb...>
> To: wa...@ny...
> Subject: Hello Wayne
> 
> They finally did it and cut off all but rudimentary access to the
> internet at work!!! (Not exactly the end of the world I`ll admit!!)

You need to run master.pl to know what's been done.
make sure they have blocked all the CONNECT possibilities before 
you go spending time on the stuff you discuss below.

> 
> This meant  that I couldn`t even get to the new mailing list when the
> proxy-elite list went belly up.
> 
> Unfortunately I managed to corrupt my version of localproxy - but hat or
> milhaus (can`t remember which!!) sent me another copy of the last
> proxytools.zip - doh..... I had a copy of that and could have just

There's a new release (2002/9/5, I think it was) at proxytools.sf.net

> decompressed it. Anyway - I`m making a meal of this, it looks like none
> of the proxies in the localproxy database are in the limited range of
> IPs currently allowed by superscout. I ran it several times, for a long
> time and it didn`t find its way out.

Bummer. The new version might though (see below).

> I now have no socks, no ftp can`t download any .exe files etc etc and
> have no way of knowing which ip`s are allowed other than by trial and
> error.
> 
> I eventually blagged our IT manager to allow my hypermart website (the
> new policy is enforced by the general manager who thinks we (I) waste
> too much time on the internet, possibly a fair point - but they`ve just
> given me a new challenge!!). This means my cgiproxy is back in operation
> and I can once again roam the web.
> 
> My ambition !! is still to get access to a fileshare network, preferably
> imesh or Kazaa !! Unfortunately I never got a chance to try out the
> eDonkey profile you set up for me.

My advice is to use one that only needs TCP.

> Localproxy is probably not an option for me as things stand and it looks

Can you get to google.com? You can argue that you *need* that.
Make sure you can get to translate.google.com (you *need* to be able to 
translate web pages into English for work occasionally, right?). 
Then commStrat 2.g in the new release will work for you. 
If you like this, I can probably generalize the service used by 2.g, 
so it can be placed in the user config file. Then you could use your 
own CGI proxy there - 2.g works the same way. There's no real 
advantage to this though. CommStrat 2 is only good for web pages, 
not services like socks, edonkey, news etc., so it's no different than 
your CGI, just faster.

> like the difficulties in terms of translating UDP traffic into TCP/IP
> traffic would require a seperate program anyway. What I would propose is
> writing two programs.
> 
> One to run an external machine, preferably on a free shell account and
> one to run on my machine.

Yeah, this is almost certainly necessary.

> They would need to convert all traffic to standard tcp/ip traffic on
> port 8080 via the superscout proxy server, incoming traffic to be
> disguised as html and outgoing as God knows what. Within each packet
> would need to be the information to reproduce the packet the other end
> unencoded.

Yes. Things like this exist (for tcp at least). 
HttpTunnel is one example.
Socks2http is another. 
HTTPort in one of it's modes is also like this.

I've seen (somewhere) limited udp/tcp conversion too.
LP has this too, but not properly debugged.

> Great, I`ve never programmed for the PC`s and don`t understand the
> internet protocols involved - nor even what a shell account is !!
> However I do understand the hardware principles of computing and can
> learn, Ive done some assembly language programming before and it`s about
> time I learnt a language again - interesting problem to tackle.
> 
> The solution ought to be reasonably portable to other peoples needs as
> well although there is no possibility of it being available soon if I`m
> coding it !!
> 
> 
> It would operate something like this. Intercept all traffic on my local
> machine except that addressed to dav-serv:8080 (`intercept` is here a
> neat word - this might be *extremely* difficult - otherwise I might need
> 
> to turn to something like Direct Connection the open source fileshare
> and try and get someone to modify the code to directly conenct to my
> program which then routes all traffic via dav-serv:8080). Spoof a new
> header as a TCP/IP packet (in some allowed innocuous looking format,
> possibly encrypted) to the external program
> via port 8080 with the original header intact inside.
> 
> The external program would reformat the packet to its original format
> and send on - obviously the response would need to be directed back at
> the external program which would then need to perform the operation in
> reverse.

What you need ideally is a tunnel to the shell. On your machine it 
would need to look like another network interface. Take a look at how 
PPP works, or the virtual private network stuff. Many shell accounts 
(example Panix) will allow you to make a PPP connection to them. 
How to do that via a proxy is another issue though.
Once you have the network interface, it's easy to set up a route so 
that traffic goes there.

I'd try to settle for socks2http though, if the source code for the 
server end is available.

> This means I would need an understanding of the TCP/IP and UDP protocols
> 
> and packet structures. In theory shouldn`t actually be very difficult as

In theory, there should be no difference between theory and 
practice - in practice, there is. :-)

> it mainly a relay service. The nice part would be to make it operate
> invisibly on my machine - i.e. intercept the traffic without the program
> 
> (e.g. Kazaa) knowing it is there - but this may be impossible. More
> likely to be able to set it up as say localhost and direct the program
> to that - the trouble is that most fileshare programs don`t accpet
> configuration like that aand a special modified version might be
> necessary.

The trouble is that now they are all peer to peer. The server you 
access first might be configurable like that, but then your client 
needs to get to all the other clients out there.

> Anyway I`m gonna start by investigating the TCP/IP protocol via some
> links you gave me earlier. The next question is which language is most
> versatile - I guess Perl would be an answer you are likely to give and
> also leads me to the reason for contacting you...... it is likely that
> whole chunks of the localproxy code would be `re-useable` so as I get
> anywhere near that stage I might contact you again !!

The UDP/TCP conversion code is in there (debugged at that level, at 
least), but to be honest I think you're biting off more than you can 
chew unless you can find utilities which are already coded to do what 
you want.

> I`m still having trouble subscribing to the new mailing list - which is
> why this is addressed personally !! I replied to the confirmation email
> but it doesn`t seem to have worked yet, will try again.

OK. I see your subscription was successful, so I'm posting this reply 
back through the list. The discussion is worth having in the archives.

> Mike

--
wa...@ny...
http://proxytools.sourceforge.net/