Slashdot Mirror

I was in China last summer. Essentially exactly the same thing happened to me, although I was using SOCKS5/ssh not PPTP. My girlfriend and I subsequently had a hell of a time playing Heroes 3 for Linux remotely even when not using ssh, so they must have shit-listed my IP address. Then, a few months later, everything magically started working again and the ssh proxy my girlfriend was using worked fine. So did Heroes 3, thankfully.

During the shit-listed time, I came across this list: https://www.torproject.org/doc...

Another option might be this: http://www.nocrew.org/software...

One of these options might be enough into fooling them the traffic isn't encrypted. Ultimately, if there's a way of exchanging data, there's a way of getting around the block. It's just a question of obfuscation.

Somewhat reminiscent of cisco's start.

I had a similar problem with O2 Telefonica, over 3G, in Czech Republic. Their FUP is quite bad. After you reach the imposed limit, they will throttle *all* connections individually to something like 4-5KB/s. Using OpenVPN, or even just HTTPS was impossible.

However, I noticed that HTTP connections were allowed a throughput 4-5 times higher. It's still very low, but usable. My guess is that they separate HTTP connections from everything else. Note that using OpenVPN over TCP port 80 did not help. So, I've started using OpenVPN over httptunnel. While it has some problems, it did offer me an overall better throughput. The downside is that you need it server-side too.

Bottom line, try httptunnel

I had a similar problem with O2 Telefonica, over 3G, in Czech Republic. Their FUP is quite bad. After you reach the imposed limit, they will throttle *all* connections individually to something like 4-5KB/s. Using OpenVPN, or even just HTTPS was impossible.

However, I noticed that HTTP connections were allowed a throughput 4-5 times higher. It's still very low, but usable. My guess is that they separate HTTP connections from everything else. Note that using OpenVPN over TCP port 80 did not help. So, I've started using OpenVPN over httptunnel. While it has some problems, it did offer me an overall better throughput. The downside is that you need it server-side too.

Bottom line, try httptunnel

If I only have access to a kiosk, I won't login. To anything, even Slashdot. And that's ignoring trusting a third-party to run said web interface.

It might be useful -- maybe -- if it was run on my own server, over https, and I only connected to it from trusted devices (meaning devices I control pretty much entirely). But if that last part is true, then said devices already have an ssh client which likely works better.

It might be useful if the Internet connection is firewalled to oblivion. In that case, if they allow port 443, it should work to simply run an SSH server on that port, on a spare IP address -- and if they only allow port 80, it should be possible to run something like HTTP tunnel, and again, a real SSH connection on top of that.

It's just the way it is.

I often am tasked in working with some of the systems in (small) 911 dispatch centers, which often lets me see rather more than I'd like of what holds them together.

First off, the infrastructure is horrible, almost as a rule[1]. Take the messiest, most confusing, and disgusting wiring closet you've ever seen, and add another layer of funk and wayward cross-connects and a nameless PC under the floor, and you'll have yourself a fairly typical-looking E911 telephone system.

And, generally speaking, the network isn't in much better shape. The tools to secure and lock things down ceased being new long, long ago, but just aren't generally in use. And every system that the dispatchers see (including those that operate the fucking radios) runs Windows, and if it is anything based on HTML, it also has a dependency on Internet Explorer.

It goes downhill from here in all of the obvious directions.

[1]: Of notable contrast to this is the 911 center in the county where I live, where I had to request a hole in the firewall in order to make NTP work on some new equipment. Things there are generally pretty tidy and well-kept... However, nothing at all prevented me from plugging my laptop into an available Ethernet port on the wall, getting a DHCP address on the same subnet as the rest of the building, and then doing some random web browsing and DNS lookups. This was very convenient for me because it let me finish the job a little quicker, and I did have permission for it. However, it only takes one compromised or malicious PC, along with one motivated person, to bring down the whole house of cards with even this small amount of implicit trust. Just a cursory Google search shows that there are lots of ways for one to whatever one wishes with a network like this.

Beg to differ. Apple announced a product named iPhone. It's not officially released yet.

If I could walk into a store today or go to a Cingular store and purchase a product that was called iPhone, Cisco would have a case.

They instead have no case, just another pathetic technology lawsuit. I got an email today from Cisco about their 'cutting-edge technology."

This is what Cisco considers cutting-edge technology.

Sue Apple for using a name. Wah, wah, wah.

Crybabies.

Maybe the city of San FranCISCO should sue CISCO for using part of their name without a license. Yeah - that's how Cisco got their name. Very creative - ummm...what do we call our company? Oh look, there's the Golden Gate Bridge! OK - let's call it cisco! Lucky for them they weren't driving near Buttsville, PA.

Then again, they way they reacted, it would have been a more appropriate choice.

For a great early history of the company -

http://pdp10.nocrew.org/docs/cisco.html

The article is not scary but is a good reminder of the different ways a network's security can be circumvented. This HTTP-Tunnel should keep everyone awake at night!

Regards,

a non y mouse

Hey everyone. Well as far as "tools" go on the "thumbdrive" I carry.... PCTOOLS' Registry mechanic and Spyware Doctor for most of my repair situations.. Other than that another MUST is an HTTP Tunnel http://www.nocrew.org/software/httptunnel.html . At my former school they had this draconian firewall that only permitted HTTP traffic through a proxy on port 80. I setup a box with a HTTP Tunnel server on port 80 that redirected the traffic to a SOCKS proxy to break out of it. The motorola phone tools suite to setup a my phone as a dialup broadband connection. Everything else I download over the internet when I need it. Best all.. Googlebear

The answer would be a http tunnel like http://www.nocrew.org/software/httptunnel.html (never had to use it though)

The original PDP-10 had a 1-microsecond memory cycle time, which gives a 1 MHz cycle rate. Its logic apparently wasn't synchronous, though. Instruction speed was supposedly around 1 MIPS. Later models had synchronous logic with clock rates ranging from about 10 to 30 MHz.

The machine actually used for TRON was a Foonly F-1, a high-speed implementation of the PDP-10 not made by DEC. Only one F-1 system was ever produced, although Foonly did go on to make slower, less ambitious machines. The F-1 had a 10 MHz clock and used fast ECL logic; it was a pipelined architecture, and common instructions would execute in one cycle. Instruction throughput was supposedly around 6 MIPS.

Check out the F-1's entry (and the links in that entry) in the first table on this page for more details.

(Oh, by the way, one of those links does mention "the Cray at Digital Productions", so I guess I was wrong in saying that Crays weren't used much for rendering work.)

The original PDP-10 had a 1-microsecond memory cycle time, which gives a 1 MHz cycle rate. Its logic apparently wasn't synchronous, though. Instruction speed was supposedly around 1 MIPS. Later models had synchronous logic with clock rates ranging from about 10 to 30 MHz.

The machine actually used for TRON was a Foonly F-1, a high-speed implementation of the PDP-10 not made by DEC. Only one F-1 system was ever produced, although Foonly did go on to make slower, less ambitious machines. The F-1 had a 10 MHz clock and used fast ECL logic; it was a pipelined architecture, and common instructions would execute in one cycle. Instruction throughput was supposedly around 6 MIPS.

Check out the F-1's entry (and the links in that entry) in the first table on this page for more details.

(Oh, by the way, one of those links does mention "the Cray at Digital Productions", so I guess I was wrong in saying that Crays weren't used much for rendering work.)

Here is a new head-ache for you: http://www.http-tunnel.com/html/ http://www.nocrew.org/software/httptunnel.html

Even then those ports are monitored for the correct kind of data.
 
So, just encapsulate. Stir in some encryption goodness, and nobody is the wiser...
 
(Yes, it is this concept that keeps me awake at night...)

Of course I'm assuming that that VPNs, SSH can be supported. It would not surprise me in the least if the aircraft only supported http through some kind of proxy.

And that would stop stop me how exactly?

Corkscrew (Unix, Windows) : Tunnel SSH connections through an HTTP proxy.

Curl (Unix, Windows) : Utility who permits to easily download and upload files by using different protocols: FTP, HTTP, HTTPS, Telnet, LDAP, ... Also supports proxies, cookies, authentification, resumes, ...

DesProxy (Unix, Windows) : Tunnel TCP connections through an HTTP proxy, eventually by converting SOCKS requests.

FizzBounce (Unix) : TCP redirector through HTTP proxies.

HTTPort (Windows) [Closed source]: Tunnel TCP connections through the HTTP protocol, by simulating a SOCKS server, and by eventually using an intermediate server.

HTTPTunnel (Unix, Windows) : Bidirectionnal tunnel through HTTP requests, eventually through an HTTP proxy.

LibCurl (Unix, Windows) : Library who permits to easily download and upload files by using different protocols: FTP, HTTP, HTTPS, Telnet, LDAP, ... Also supports proxies, cookies, authentification, resumes, and lots of languages: C, C++, Perl, ...

MultiProxy (Windows) [Closed source]: HTTP proxies tester. MultiProxy can be used as a proxy server who use a different proxy for each request.

Numby (Unix) : Scanner for HTTP vulnerables proxies.

Proxomitron (Windows) [Closed source]: Scanner and redirector through HTTP proxies, who can also delete or modify informations contained in HTML transferred pages. For example, this permits to easily filter automatic popups, DHTML or JavaScript.

ProxyTools (Unix, Windows) : Set of Perl utilities, who permits to use, sort, test and search for HTTP proxies.

TransConnect (Unix) : Transparently tunnel TCP connections through an HTTP proxy.

Zylyx (Unix) : permits to access to files through HTTP proxy caches.

oops, that was the Foonly computer. But really it was a pdp10 on steriods...doing Tron helped drive the company out of business.

The funnest console player program I've encountered so far is juke. I'll often fire up an xterm just so i can run it, even if I am in X. It's a pure jukebox prog, no fixed play lists. It just plays then in the order you pick them. The fast browsing with the arrow keys lets you pick lots of music fast, so it makes it sort of a game.

Heard of HTTP tunnelling? Check these out:

GNU HTTP tunnel
Commercial HTTP tunnel (monthly sub)

You need HTTP tunnel.

I actually built my own half-baked (but workable) HTTP tunnel six or seven years ago when working in an environment with annoying firewalls. I did it by writing a pair of simple Java applets, one for use on my laptop, the other to run on the server in my basement. It's pretty simple, actually, but now you don't have to write it yourself!

Allow me to be more detailed:

sshd -p 80

HTH!

Or, if one is extremely worried:

httptunnel.

Although the second method isn't mentioned, so, if your company has enough money to waste on packeteers, yeah, NZs post would need work.

Yeah, working with HTML forms to upload data. That works, I tried that and itwas nice, sort of :) It's a bad solution if I'd ever want to upload larger files due to various issues, like the initial drawbacks of http. (being stateless and all that) Still, it works up to a level and it works nicely if you don't expect too much out of it.

HTTP tunnels are a good solution so far but I don't have any working tunneling software yet apart from a trial version of a commercial tunneler. Granted, I haven't taken a very good look at gnu/httptunnel yet, so that might be an answer. Once I get back in college that is and by then I'll have one of those USB keys :)

For even more pertinacious network environments, one can use httptunnel or the more advanced desproxy

1. Get Http tunnel. You have to install it inside the network with the proxy, and in another machine on the internet (outside that lan).
2. Create a tunnel from the first machine to the ssh server of the second machine (http tunnel creates a socket).
3. Do ssh-keygen on the first machine, and copy the .ssh/indentity.pub file from the first machine to .ssh/autorized_keys on the second host. That way you can login without password.
4. Now configure both machines to do PPP over ssh. I wrote the explanations here , look at the comment with a subject saying "PPP over SSH". It's in spanish, but you can translate it with babelfish, and at least you can get the scripts from there. If you don't manage, look in google for "ppp over ssh" or "firewall piercing".
5. Configure the first machine to use the second host as the default gateway (through this new ppp network device), and configure the second machine to do NAT for the first one.

You need to have root in both machines, but is worthwile, trust me! ];>> The first time it could look a little bit complicated, but afterwards you can just create a script to do the whole thing, so next time you'll only have to do "./create_tunnel" on the first machine to do the whole process.

What, never heard of Debian GNU/MiNT for the Atari ST?

-uso.

This link explains how to convert a single IDE disk Linux setup into a tripple IDE disk RAID5 Linux setup (while keeping your original data).

According to the policies, HTTP traffic is given the highest priority. This probably means traffic to port 80 (and maybe port 443) of external computers.

To take advantage of this, of course, you need to use GNU Httptunnel or a similar program to route your filesharing traffic through a proxy on the outside.

To make this more clear:

1. Get access to a high-bandwidth network on the outside
2. Run httptunnel's server on that computer
3. Run the httptunnel client on your UCI computer
4. Tunnel all your connections either through SOCKS proxies, SSH tunnels, or the like, via this HTTP traffic

This makes all your file-sharing traffic look like legitimate web traffic to the QoS device. You just have to send your data through port 80!

"clever users will also note that you can tunnel this over just about any port you want. Make this an encrypted tunnel and no filter in the world will detect it. If your school/network allows even a single TCP port out to the Internet you can do this. "

Even without an open TCP port, you can do this over HTTP if you have a proxy server. Just tunnel everything over HTTP. Of course, then you're tunneling http over ssh over http , which gets a little complicated, but it works.

See the GNU HTTPtunnel home page for more details.

I have worked for two different banks, both of which blocked everything, including 22. They then set up proxies which would allow 80 & 443 out to the world, monitored by proxy authentication.

The reason that blocking port 22 is so important is that SSH enables trivial tunneling. This will allow anyone in the corporation who runs outbound ssh to determine what the corporations inbound security policy is. Or translated from business-speak to techno-speak: those who run ssh are allowed to let any TCP port back into the corporation.

Breaking the firewall policy is not something that large corporations, especially banks, are fond of.

Of course, the fact that you can tunnel tthrough firewalls on port 80 and port 443 does not sit easily with these type of corporations.

You certainly can preach about 'feature-above-security mindset that needs to go' for as long as you want, but when it will come to the product not working at your biggest customer site due to the firewall setup and them not willing to mess it up just for trying out yet-another-beta proggy, you will consider SOAP, stunnel, httptunnel and anything else that will get you closer to the goal.

I agree that positioning SOAP as firewall-transparent protocol is .. err .. may get interpreted incorrectly by less experienced members of comp.sci society, but .. hey! .. you can misuse almost everything.

.. and (not re: your post, but a thread head) XML-based marshalling ? Give me a break ... Once you start tuning the performance, you realize that bottleneck is often exactly in the freaking SOAP layer with its bloated XML data encoding. You certianly can compress it, but what's the need in XML there for then ?

Well, OK.

SOAP traffic is actually quite easy to detect in HTTP, just examine the Content-Type field.

Then you say:

Actually selling firewalls is a large part of my business.

So, in order to filter SOAP we need to get a firewall with significantly more horsepower in order to examine the Content-Type field... and you sell firewalls.

How convenient.

You also say

However the issue you raise does not actually arise since a firewall should not be accepting incomming HTTP requests to the internal network in the first place

That is irrelevant. If you allow arbitrary outgoing requests, and their replies, then it's trivial to encapsulate an incoming request in the replies. Witness httptunnel which can be used to setup outgoing SSH connections, which in turn can be used with PPP over SSH to establish the entire IP protocol... INBOUND... All of this over port 80. Think this can't be done? Well I'm an IT auditor, whose opinions you seem to eschew. I've done it (in the lab, of course.)

All things considered, I disagree with your conclusions.

You would be surprised. At gigabit ethernet speeds, protocol and memory management and packet size suddenly become very very important. Imagine all your bandwidth being taken up by 1Kbyte packets. That means 100,000 packets per second! So that means you have only 10 microseconds processing time per packet before they start piling up and eventually get tossed.

Special consideration must be taken in order to be efficient.

Take a look at uvm-zero-copy.ps as an example of the kernel changes made to *bsd in order to get high throughput in gigabit ethernet.

Also, most of those cheapie gig-e adaptors in the mac and for pc's usually won't cut it for real high bandwidth.

--jeff

Mindterm looks interesting, but the GNU httptunnel application (here is another link) mentioned in another post will do roughly the same thing, and you can easily use ssh over httptunnel to tunnel other protocols.

Better yet, unlike Mindbright's applet, httptunnel is free software (GPL). Mindbright's applet does sound like it has some nice bell's and whistles, though. Probably worth paying for if you were going to roll SSS over HTTP out as a solution to a larger group of users. (using ssh over httptunnel works great, but it can be a little confusing to set up the first time.) Otherwise, try httptunnel instead.

BlueCollarTech.com

Then you go to tunneling ip over http. (:

This will work through any proxy:
GNU HTTP TUNNEL

Unfortunately it does need a server on the outside, and is a pottential security problem since it goes through the firewall.
But at least there is very little chance they can filter it.

I'm assuming that you've already discussed this with the local überBOFH and decided that ssh is not acceptable, but a tunnel is. My personal opinion of your situation is that a tunnel is only acceptable if the remote endpoint is behind a firewall with a ruleset as least as restrictive as the home network's firewall and is subject to usage rules (who has access, what is each user allowed to do, etc) at least as restrictive as those of the home network. Remember that establishing a tunnel between two nets is equivalent to connecting the two networks behind their firewalls - if someone has access to one network, he won't be bothered by the firewall on the other.

That said...

At a client site I'm currently tunneling past a NAT router (because I want to run a protocol that the router can't masquerade) by having a machine behind the router establish a connection to a machine outside. I'm using a program called Tunnel Vision (http://www.worldvisions.ca/tunnelv/, or package tunnelv on Debian), but since your firewall probably won't allow it past you should use a protocol that your firewall does allow in ways that it dosen't expect.

If your firewall allows https through, you should be able to run anything you please through port 443 as long as it's SSL-wrapped (so the firewall dosen't think anything's amiss). You could use the stunnel package (http://www.stunnel.org/, or package stunnel on Debian) for this - set a server running on port 443 of a machine outside the firewall, and start the client running inside. This will establish a stream between the two endpoints, and you can run anything you please over it - I'd choose to run pppd.

If your firewall dosen't allow https but does allow http, you can use httptunnel (http://www.nocrew.org/software/httptunnel.html, or package httptunnel on Debian). I haven't used httptunnel, so I don't know if you need to run pppd inside it. If it dosen't do strong authentication and encryption, you'll need something inside it for that, too.

These solutions require that an IP be reserved inside the firewall for the machine on the outside end. The machine inside should proxy-ARP for the machine outside.

You could also tunnel traffic over DNS queries - see http://nstx.dereference.de/nstx/ for a program that will do that - but it's doubtful that you'll need to do that.

I've never really had a problem with tunelling, as most firewalls I've dealt with generally let out either HTTP (in which case, check out this site) or telnet.

While I know that telnet isn't secure; a rinky-dink server at home generally lets me get my job done in tunnelling.

From a hacker's point of view; you can use the Firewall-Hacking tutorial on linuxdoc (I believe it ends up pointing to This site)

The real point is that the moment you open up a port; you no longer have security. True security is having your machine turned off, not connected to a network, and in a steal cage...

How about this: GNU httptunnel

IP over HTTP implementation:

http://www.nocrew.org/software/httptunnel.html

What about httptunnel?

I performed a quick search on Freshmeat for you. Here's the results (filtered for stuff that's actually relevant, I think). In no particular order:

CYCAS - not sure if it's open-source, but will run on Linux and BSD and looks pretty powerful

Jcad - written in Java, this is an open-sourced CAD which works with DXF file formats. Not the most powerful of tools out there, but it's a start

iCADis - can't tell much from the site, but it might be worth a try. Uses GTK and is covered by the GPL

OCTree - looks like it has a really innovative interface. Not sure about the license though.

Varicad - for mechanical engineering. Looks good, but unsure if it's open.

QCad - seems to be one of the better ones, and it's open.

That's all I can find. You can judge yourself if you need it to be 100% open-source, if you need it to be free, and if you need it to run on a particular platform. Perhaps you might settle on a combination of these, since it doesn't look likely that you'll find something that meets all 3 conditions (assuming you were looking for it).

If you're a programmer, then by all means help out with one of the open-source projects out of the ones mentioned above. Lots of them could use things like improved rendering (speed, effects etc), and the ability to load lots of different file formats.

TCP/IP is your friend. :)

http://www.nocrew.org/software/httptunnel.html

If anything, the comment could have been re-phrased better as Linus+Minix+(gnu tools)=Linux, but (apologies to Andy Tannebaum) I don't believe Linus ever used any of the minix source on his development path, since he says just that in the initial announcement of his plans.

aem

" This will make all current firewalls obsolete as not there will be all of your data going thru the 80 port. To me, this means that the firewall is now useless...."

I suspect you don't understand the value of firewalls.

You can still stop external computers from initiating connections to local computers. No need for the whole world to see my intranet web server. So blocking incoming port 80 is still valuable. Maybe I have a public web server behind my firewall, I can block incoming port 80 for all destinations except my public web server. The rule of thumb that you should firewall all incoming ports you don't need remains useful.

This leaves outgoing ports. If you open HTTP, a desperate enough program or user can always sneak out through the port. If it's possible to tunnel IP over DNS, it's darn well possible to tunnel IP over HTTP.

All you've lost is your false sense of security.

Tunnelling over port 80 is (part of) the answer. The other part is having a server on the other side of the facist firewall that proxies for you. Oddly, this weeks Need to Know mentions this problem. See http://http-tunnel.com/newpage/icqp.htm for Windows software that does it and http://www.nocrew.org/software/httptunnel.html for Unix software.

Yes. See www.nocrew.org/software/httptunnel.html.

This appears to be for Linux, btw.