On the other hand, I can see where they're coming from by banning the whole netblock. Otherwise you could scrape until your IP get banned for blowing a rate limit, then tear down that instance and spin up a new one.
... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now.
I tried contacting SO about this, and got a negative response.
It's a pity that StackOverflow doesn't allow me to do this (so I end up turning the proxy on and off and back on again). It's not like you couldn't rent a cheap Linode instance (or from another provider, take your pick) and do whatever you want with SO, if you really wanted to.
SO needs more sophisticated tools to block the access for bots/crawlers. IP blocking just doesn't cut it and tends to discriminate against legitimate users with special needs.
FoxyProxy (and probably other extensions) make site-specific proxy settings feasible.
Not so much 'news' but perhaps a quick hack, nice reminder, a quick intro for the less experienced (who may not know what they are missing in the first place). Or perhaps someone who has set this up before in a different way might want to change how they do it.
So whilst this is probably not front news worthy of LEET HACKERS it's probably made someone go 'hey thats cool' and that's all it needed to do.
doesn't imply being "LEET".
Back to the topic: I my own router to create a tunnel similar to the one described by the OP. It is not as fast as an Amazon instance but free wi-fi is neither.
Anyway, as much as I complain about all the puff pieces, there are still plenty of articles with real technical meat on HN, you just got to wade through some crap to get to them.
That's the hacker ethos - show what you know, if you are wrong someone will point it out and others (and hopefully youtself!) will learn from it.
The sort of attitude you are display is the sort of hypercritical one that prevents people from submitting "Show HN", which is a real pity.
Maybe they don't want the hassle of configuring the browser (or other sw)
Nifty one-liner to set it properly up: "ssh user@host -D 8080". Then you just point your system wide proxy to localhost:8080 and magically see all your data be tunneled.
Used the command for years to my own boxes. The amazon spin up version I guess is cool. I'll spin one up at some point just in case. Never know.
Unfortunately many utilities don't support SOCKS or have non-standard flags, so you would need a wrapping program like tsocks to force TCP through your proxy.
It's not very efficient, though.
If you have a server somewhere, there's no real limit to the creative ways you can get around network restrictions.
I had some time on my hands and got TCP over DNS working. It's obviously quite slow, but certainly useable. A fun exercise anyway.
It's also interesting to note that Julian Assange (AFAIK) was the first person to come up with this idea back in 2006.
I have to interject here - not to blow my own trumpet, but as a 'point of fact'. (Oops... once you start correcting misinformation on the internet, you are going to be busy for a long time.)
I wrote about this in 1998, when I released source code that did this on the bugtraq mailing list - http://gray-world.net/papers/dnstunnel.txt has a copy of my mail.
Before that there was a long standing existing technique to tunnel data through UDP packets that simply pretended to be destined for the DNS port (53). That stopped working if the network admin filtered outbound UDP and forced people to use their local DNS server instead. My method still works in that scenario though.
(If anyone knows of an earlier reference to the method I posted about, please let me know.. for all I know it was a well-known tactic in the underworld before I posted to bugtraq.)
From Julian's post, it's not possible to see which of the two methods his code used, since the rb file seems to have disappeared. I suspect it was "my" method.
I do like the ppp interface through - mine just tunneled bash commands + responses.
HN'ers -- Despite Kaminsky's ego, all signs indicate Oskar invented DNS tunneling.
Also, a quick search for "dns-over-tcp" yields several results.
* September 2005: Google Secure Access goes beta: http://lifehacker.com/126454/google-secure-access-+-encrypt-...
* October 2005: Google Secure Access shuts down: http://www.zdnet.com/blog/google/google-secure-access-is-his...
Although, some of their endpoints are EC2 as well ... so you won't be going around the block that some sites have set up for EC2 instances...
Highly recommended. The author of the program hangs out on HN sometimes too.
So my suggestion is to have multiple alternatives instead, as in lines of defense.
First, a simple SSH server also running a socks and a http proxy is useful. Easy to reach and configure - some browser work better with http proxy (or was it sock? Opera only supports one but I can't remember which at the moment)
In the second line, you want to run the SSH server on a nonstandard port as the author does. I suggest multiplexing the port : simply run SSLH on both port 80 and 443, with the patch published on http://rutschle.net/pipermail/sslh/2012-April/000202.html
But that will not look like a standard SSL connection. Even worse, if you use your own certificate - operators could deny all self-signed certificates.
So get stunnel running on port 443 with a "usual" certificate instead, and pass the traffic on port 80 where you'll be happy to have SSLH or whatever you prefer - like Openvpn which can do port sharing or which can be put "behind" stunnel and sslh, so that you will use a standard 443 port, and do a genuine SSL connection on that port. Much better. Have some fun with burst.net - they offer you 2 IP for like $7/month : you can do some routing and give the 2nd IP address to your laptop on the other end of the tunnel. Now that is freedom :-) Every port will be opened in both ways :-)
Still, I do not believe anything of that will be enough to resist to statistical analysis. I've seen interesting tools, but if I down to that I'd better use a standard DNS tunnel (iodine, dns2tcp, ntsx, whatever).
Once again, multiplexing port 53 could be good to have them on different subdomains (you never know which tool you'll have on hand, or can easily recompile on the go) or to run a standard DNS server too (named, maradns, ...).
It will be a good idea to "rate limit" one of them because having too much traffic flow on port 53 to a given IP is something that stands out. (And I have seen DNS tunnels broken by a simple rate limit rule)
I found something interesting to multiplex DNS request in C, which name I don't remember at the moment. If anyone is interested I can dig that up.
Finally, deploy all that setup on at least 2 machines, using different domains and different subnet so that if one of your "lines of defenses" goes down (ie get blacklisted) you can safely move to the next one.
Total time it takes : 2 hours, then you'll always have a way out of a locked connection.
I'd love to hear about your plans for "deep packet inspection" on SSL packets...
> your only S3 machine could get blacklisted
I thought the whole reason the original article was suggesting S3 was so that you could just spin up a random Micro instance, with a new IP address.
Sorry about the S3/EC2 confusion, but in the end it's still a better idea to go with a smaller VPS resaler to avoid preexisting subnet blacklists.
And what relevance does statistical analysis have? It's about providing access and preserving privacy, it's not about covering tracks.
A nicer sshuttle command for VPN may be:
$ ./sshuttle -v --remote=server_USERNAME@serverIP:port_number --dns 0/0
If you sshuttle to your home router you may be able to samba or nfs to the ARM on your home network (using tcp and udp, I think).
Alternatively, SSHFS or something more normal could be used for mounting the ARM filesystem without a VPN but if you want to try Samba over SSH you could try:
$ ssh -C -c blowfish -L[host_bind_port]:localhost:445 server_USERNAME@serverIP
$ mkdir /Users/username/mount_spot
$ mount -t smbfs //server_USERNAME@localhost:[host_bind_port]/server_drive ~/mount_spot
Tools like rsync over SSH and UFTP are also nice for moving large files to and from the ARM server.
I tried making an instructible on this last week but it's kinda poor: http://www.instructables.com/id/Personal-ARM-Cloud-Server/
It's about 160 lines of code, you can find it at https://github.com/wvdschel/ProxyBash.
I first wrote it to circumvent the firewall at a summer job to be able to connect to IRC, and I recently got it out of the dust to do something similar at my current job. I couldn't use anything pre-existing, because I was on a tightly locked down Windows system. This approach only required some kind of portable Ruby runtime.
Corkscrew does pretty much the same thing, but my script doesn't require an SSH server to run on port 443 and does away with SSH encryption for most connections. The latter can be either a good or a bad thing, depending on your use case.
Just make your server listen for ssh on port 80 or 443, and then tunnel away!
What sshuttle buys you is transparent interception and forwarding of tcp with firewall rules (no proxies), more reliable DNS tunnelling, packet reassembly that avoids the worst tcp-over-tcp performance nightmares, and control of any or all networks that should be tunneled to. There are a couple of nice bonuses like better traffic reporting, toggle for latency vs. throughput, and the ability to offer tunneling to other local machines, but really it's a decent alternative to a vpn for anything that only uses UDP for DNS.
TL;DR Less tinkering needed, more reliable, more pleasant to use, supports more applications.
OpenVPN, on the other hand, can go through TCP 443, which is all but guaranteed to be unblocked.
But, you're right that there isn't any iPhone support for non-jailbroken phones. I'm not sure about Android, but I see less of a problem getting it working on an Android phone.
I have squid running on a vps, but NOT exposed externally (and it has basic auth). Then just set up an ssh tunnel "ssh -f email@example.com -L 3128:mydomain.com:3128 -N" and now you have a proxy server available on localhost:3128. Then its as simple as pointing a single proxy supporting app, your OS wide proxy settings, etc.. to localhost:3128 with the correct basic auth credentials and you are in business.
I use this on linux and windows (cygwin) every day, works beautifully
if [ $1 == 'off' ]; then
echo "Disabling Proxy..."
networksetup -setsocksfirewallproxystate "Wi-Fi" off
echo "Enabling Proxy on port 12345"
networksetup -setsocksfirewallproxy "Wi-Fi" localhost 12345
I also have an openvpn for when I want full tunneling, but that takes more time to setup properly.
 https://code.google.com/p/shellinabox/ (there are quite a lot of others web-based terminals if this one doesn't suit you)
My concern is that this knowledge -- about VPN's, much of the "for dummies" versions using 443 -- is becoming mainstream. Whereupon there will be further escalation.
(As long as it was a niche, it was missed or ignored by many "public wifi" providers.)
This is way overkill anyway.
Change the SSHD port (since the filters are naive enough to just whitelist ports apparently), then run `ssh -D 8080 user@ec2-instance:80` and voila, you have a SOCKS proxy that will proxy any traffic, including DNS requests. (and good OSes will easily allow you to utilize that proxy system wide)
The tool needs an update or two regarding a few features (notably it only supports a single tunnel at once), but it pierces through literally any HTTP proxy, since it's really HTTP and not some CONNECT trick over SSL.
Then you just use your favorite OpenVPN over that, and make all traffic (including DNS, and except your httptunnel endpoint) go over it.