Menu
▾
▴
Re: [proxyTools-users] escaping a very restrictive
|
From: wayne <wa...@ny...> - 2002-10-11 14:43:36
|
> From: Michael Foord <Mic...@tb...> > To: wayne <wa...@ny...>, noc...@fr..., > pro...@li... > Subject: Re: [proxyTools-users] escaping a very restrictive > > > > > > 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. > > > > My boss was away for a while so the IT man switched us over to `ipchains` - > which gave me unfettered access AND meant I couldn`t check what they`d done. > Sadly my boss has returned so I`m back to a censored connection. Thanks for > replying Wayne. > > Here`s the results of master.pl > > C:\>cd "program files" > > C:\Program Files>cd localproxy > > C:\Program Files\localproxy>perl master.pl > I'm assuming this IP address is 192.168.4.67 > Most (maybe all) ports are blocked, but we will continue > (and assume you are 'connected' to the Internet) ... > I'm assuming this IP address is 192.168.4.67 > Timeout selected for connect tests: 5.5 > Mapping the firewall rules, please wait ... > Testing for blocking on port 21 ... blocked > Testing for blocking on port 22 ... blocked > Testing for blocking on port 23 ... blocked > Testing for blocking on port 25 ... open > Testing for blocking on port 80 ... blocked > Testing for blocking on port 81 ... blocked > Testing for blocking on port 82 ... blocked > Testing for blocking on port 110 ... open > Testing for blocking on port 119 ... blocked > Testing for blocking on port 443 ... blocked > Testing for blocking on port 1080 ... blocked > Testing for blocking on port 3128 ... blocked > Testing for blocking on port 6588 ... blocked > Testing for blocking on port 7021 ... blocked > Testing for blocking on port 7033 ... blocked > Testing for blocking on port 7070 ... blocked > Testing for blocking on port 7137 ... blocked > Testing for blocking on port 7475 ... blocked > Testing for blocking on port 8000 ... blocked > Testing for blocking on port 8001 ... blocked > Testing for blocking on port 8080 ... blocked > Testing for blocking on port 8081 ... blocked > Testing for blocking on port 8141 ... blocked > Testing for blocking on port 8180 ... blocked > Testing for blocking on port 8616 ... blocked > Testing for blocking on port 8888 ... blocked > Testing for blocking on port 8965 ... blocked > Testing for blocking on port 9001 ... blocked > Testing for blocking on port 9081 ... blocked > > Testing for blocking on port 9274 ... blocked > Testing for blocking on port 9589 ... blocked > Testing for blocking on port 10080 ... blocked > Testing for blocking on port 14000 ... blocked > > Saving the results in master.xml > Test your ISP proxies now (y or n)? y > Proxies found in environment: 192.168.4.1:8080 > Checking proxies: 192.168.4.1:8080, dav-serv:8080 > Please enter any further proxies to be tested (in addr:port > format; for example 123.22.13.24:8080, or proxy.bbb.com:3128). > Type one per line and end with a blank line. > > Checking proxy capabilities ... > send() on closed socket PROXY at statProxy.pl line 1016. > Your vendor has not defined POSIX macro EWOULDBLOCK, used at statProxy.pl line > 1 > 017 This bug has been fixed. Get a new statProxy.pl > Hangs.......... > > Interesting result though - I thing my IT must have made an error configuring > Superscout this time, I`ve never had an open port before...... They are for email (pop and smtp). So you can use email directly, without using any kind of proxy or internal email servers. If you have access to a computer outside, and the rights to listen on these low ports, you can tunnel *everything* (TCP) through them. It's likely that udp is also open on those ports, so you might get your p2p stuff going that way too. Until they close them, that is :-) > Had to exit with ctrl-c.... > > C:\Program Files\localproxy>perl statproxy.pl 192.168.4.1:8080 > Warning: If you are testing any proxy through a redirector, > the proxy anonymity test will reveal your true IP address. > Normally you would be connecting directly to the proxy for these > tests anyway, so it doesn't matter. The test won't work if you > block incoming connections with a firewall, or a NAT. > I will disable the anonymity test if you wish. > Disable anonymity test (y or [n])? y > > ...anonymity test is disabled > > statProxy v4.95 report from 192.168.4.67: > 192.168.4.1 :8080 AFFFFFFFFFFFF FFFFsend() on closed socket PROXY at These all failed because your environment doesn't contain the required authentication stuff. Or, I have another authentication bug :-( > statpr > oxy.pl line 1016, <STDIN> line 1. > Your vendor has not defined POSIX macro EWOULDBLOCK, used at statproxy.pl line > 1 > 017 Fixed. > > C:\Program Files\localproxy> > > Bombs out.... > > > > > > > > > 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. > > Hmmm... have yet to find such a beast - but that would be ideal. > > > > > > > > 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. > > > > Have asked for this and am pretty certain I`ll get it. Yep - done. Would > prefer to use localproxy than my CGI proxy.... Oops ... too late! The google translate got blocked by the UAE about a week after my last LP release, so I've changed it to the Alatavista translator now. We'll see how long that one lasts. :-) I haven't allowed any options for this choice yet, but you can find the (new) file cgiAmbles.txt which will allow you to edit the cgi to use. Uncomment the one you want, and comment out the one currently in use (commented/unused lines are the ones with '#' at the start). > [snip... for now...] > > Am sure you are right about it being beyond me to program a tcp to udp > conversion and relay program.... but would still like to learn about the > protocols involved so will look at the sources you point me too. You will need the latest localProxy2.pl too. If I can help, just ask. > Mike -- wa...@ny... http://proxytools.sourceforge.net/ |
