A couple of things that I'd like to see in this script:
1. Go ahead and apply all of the software updates. The RAX Ubuntu images are behind on a lot of security updates.
apt-get -q upgrade
apt-get -q dist-upgrade
reboot (at the end)
2. While you're at it, enable automatic security-related upgrades. It's likely that the user of your service is less technical and not Linux-saavy. Let's keep their cloud server from being owned.
3. Force public key auth (disable password auth) on their OpenSSH server and (preferably) disable root logins entirely. Create a user account for them if needed, with sudo access.
4. Set up IPtables as default-deny with holes punched for OpenVPN and OpenSSH.
5. Configure OpenSSH to listen on port 443 in addition to 22. Some hotspots block port 22. Almost nobody blocks port 443/tcp. This is super-handy if you're ever working from some place with a restrictive or filtering firewall. SOCKS over SSH is awesome, especially when you're dealing with censorship or malevolence at the DNS level. I used this technique when I was in the Army and our Army housing had horrible DNS servers that censored a lot of legitimate sites.
6. I would prefer you not ask for people's cloud provider API keys. This has huge potential for abuse. Instead, give them a script that they can run on any Mac or Linux box that takes the root password and IP and provisions their server for them.
I suppose I should make a PR for you; maybe later this weekend
We agree with all but the last point. We do provide the script but sadly most people using this won't know how to run such a script. We tried to make it as easy as possible.
Great points otherwise, would love to see a PR. :) thanks for the feedback!
I'd also install fail2ban. I looked at the auth logs for my DigitalOcean VM, and it's amazing how many bots/people try to log into it, even though it doesn't contain anything necessarily valuable.
The script is currently generating a 512-bit (EDIT: 2048-bit after merging my pull request) DH modulus. DH over a finite field modulo a 512-bit prime is weak sauce, about as hard to break as a 56-bit or 64-bit key for a symmetric cipher.[1] You're using DH over a finite field, not ECDH.
Please upgrade your script to generate a 4096-bit DH modulus. EDIT: A 2048-bit safe prime provides over 100 bits of security and is much faster to generate.
I'm not sure why OpenSSL hasn't upgraded their default modulus size, but to have the same strength as a 150-bit symmetric cipher key, against the best attack techniques 2004 had to offer, you'd need about a 4575-bit DH modulus.[1] AES-128 is about as hard to break as a 3200-bit DH modulus given the best techniques of 2001.[2]
EDIT: Times to generate different sized safe primes on my MBP maxing out one core:
Need secure internet? Just drop your API key in here. Yes, I know they link to the script, but you don't have any assurance that they're running the same script when you give them your creds.
Promoting the use of VPNs and secure browsing habits is awesome, and I applaud them for open sourcing the script. But asking people to trust them to do the work negates much of the benefit they're trying to provide.
We hear you. We think that getting more people using VPNs is more important, so we made that trade-off. We built this for people who are mostly non-technical, but we wanted to provide the script such that those who are more technical are able to run this on their own. :)
I get that you can make the argument that we're training people to stick their API keys in random textboxes on the internet, but we thought getting more people on a VPN was worth the risk.
Can you possibly link the script more prominently, with a suggestion that folks run it themselves? I found it easily enough, but I was also browsing with the primary intention of finding out what it was you were running on the servers, not as someone looking to make a VPN.
Edit: I should add that I do not think your DNS requests will go over the proxy. You might be able to configure your browser to do that. Caveat emptor.
FoxyProxy is useful to have for other reasons, e.g. geolocation blocking / ISP censorship. I rent a cheap virtual server (3 USD/month or so) and keep a constant SSH proxy connection to it, and redirect blocked websites (e.g. TPB in UK) via the proxy using FoxyProxy's URL patterns.
Flash will honor browser proxies for HTTP connections initiated within an app (e.g. via getURL()), but Flash apps can also open arbitrary sockets, which go directly. For Flash video, recent versions will first try a direct RTMP connection, but will fall back to RTMPT (RTMP tunneled over HTTP) if that fails, so they'll successfully go via the browser proxy if you block other outgoing connections at your firewall.
But yes, if you allow plugins that have the ability to initiate arbitrary connections, there's no way to guarantee they aren't making un-proxied connections, unless you either use firewall rules to block outgoing un-proxied connections, or you transparently proxy everything (VPN). Same as with running arbitrary non-browser apps that might open socket connections.
I'm still trying to find a VPN solution that can stream 1080p video across the Pacific Ocean, but I still haven't been able to get something working with enough bandwidth.
That's awesome. We used OpenVPN because that's what we were familiar with, but your L2TP script looks great. Would you mind if we tried to integrated that at some point?
I've been looking for the same thing as well. Depending on whether anonymity is your goal, I'm curious if a cheap dedicated server might work as a high-bandwidth VPN.
Note that deep packet inspection will be able to identify this as OpenVPN traffic the way its configured right now. You can configure OpenVPN to use a fixed key [1] at which point the traffic is indistinguishable from random noise and no longer has any protocol data. The big tradeoff here is that this disables perfect forward secrecy; you can't add this as an extra layer on top.
You may also want to specify "cipher AES-256-CBC" in both client and server config to upgrade from the default AES-128 it uses.
This is awesome, but there's always something that makes me feel uneasy when asked for API keys like this. They could probably list and delete any and all of my droplets with that kind of credentials, couldn't they?
Definitely agree. We hopefully answer some of those questions on our FAQ (https://www.tinfoilsecurity.com/vpn/faq). We also link to the script we run if you want to set it up yourself.
Thanks for the info! That's definitely helpful. Maybe it should be a bit more prominent, like adding that "Why should I trust you?" section to the main page below(or above) "What is a VPN?".
On a site claiming to be about security, the FAQ should explain how and why it works even if the user doesn't trust the server. That's the whole point.
Is anyone else getting their DigitalOcean IPs banned from certain sites? I use it as a personal VPN sometimes and lately any application hosted on Google App Engine is inaccessible. Sometimes Gmail, Google Analytics and Google Drive are also inaccessible.
The strange part is that the server I am using should not be sending email or doing much really except hosting some git repos and a basic website.
I've run into that before on VPNs using AWS. Likely the public IP my server is using was used for abuse before I got it, especially as they usually only stick very ephemerally unless you upgrade to an Elastic IP.
The site talks about deleting or pausing servers, then going back to the TinFoil page to start over in the future. However, it looks like DigitalOcean charges a flat $5 per month for the lowest tier. Is there any harm in leaving it running 24/7 and connecting when I'm in public? The most I'd be charged is $5/month, right?
There's no harm in that at all, and you're correct. But keep in mind it's $5/mo/server at the lowest tier, so if you have multiple running simultaneously you'll get charged more.
If you don't mind paying the $5, by all means leave it up 24/7. :)
I've been kicking around a similar idea for some time now, only that it would be a standalone iOS/Android app. On iOS, it'd output a .ovpn file that could be directly loaded into the OpenVPN app and started up. I'm sure Android would have a similar process, though I admit to not being as familiar with it.
Android is basically the same, you have a .ovpn file that gets put into the OpenVPN app. I think you have to put it in /sdcard/openvpn/ or something, but im not 100% sure
Very nice! You could make the linked script a bit more prominent, but the API key way is a good tradeoff between security and convenience. I'd still use the script myself, but I know that most people wouldn't bother with it.
We're totally OK with you using the script. :) Most people, especially those just looking for a way to be secure without knowing anything about the command line, was whom this tool was built for. Glad you liked it!
This VPN won't anonymize any traffic, just encrypt the traffic between you and the server. The Rackspace account would be tied to you, so any piracy-type violations will go to them first, which they will pass along to you.
>"Sidestep is an open-source application for Mac OS X that sits quietly in the background, protecting your security and privacy as you browse the web."
>[...]
>"When Sidestep detects you connecting to an unprotected wireless network, it automatically encrypts all of your Internet traffic and reroutes it through a secure connection to a server of your choosing, which acts as your Internet proxy. And it does all this in the background so that you don’t even notice it."
Sorry about that! Digital Ocean ran out of boxes in the SFO region, so we've switched it to Amsterdam, but our release process broken for a few minutes. Should be fixed now!
Thanks! I was able to get to it via the blog post link. Just configured my own VPN. Been meaning to do that for a while and was already planning to use DigitalOcean. Thanks for the boostrapping!
Okay, followed the script but the VPN won't connect to the internet. :( Even blew away the first build of the VPN server and rebuilt from scratch, no dice. :(
This relies on properly configuring all relevant software to use the SSH tunnel as a proxy. That's very difficult to do in a way that you don't end up leaking information over the real connection.
OpenVPN works on a lower level and just tells the operating system to use it as a gateway (as configured here) and every software will magically start routing traffic over it. This is generally what you want for security, but can be annoying for bandwidth or latency sensitive applications.
"vpns are too painful to set up for everyone else"
Its been a long time i did not not see as much bullshit. In linux, its as simple as going into the vpn tab of your connections, entering your username, password and crt file, and you are done.
1. Go ahead and apply all of the software updates. The RAX Ubuntu images are behind on a lot of security updates.
2. While you're at it, enable automatic security-related upgrades. It's likely that the user of your service is less technical and not Linux-saavy. Let's keep their cloud server from being owned.3. Force public key auth (disable password auth) on their OpenSSH server and (preferably) disable root logins entirely. Create a user account for them if needed, with sudo access.
4. Set up IPtables as default-deny with holes punched for OpenVPN and OpenSSH.
5. Configure OpenSSH to listen on port 443 in addition to 22. Some hotspots block port 22. Almost nobody blocks port 443/tcp. This is super-handy if you're ever working from some place with a restrictive or filtering firewall. SOCKS over SSH is awesome, especially when you're dealing with censorship or malevolence at the DNS level. I used this technique when I was in the Army and our Army housing had horrible DNS servers that censored a lot of legitimate sites.
6. I would prefer you not ask for people's cloud provider API keys. This has huge potential for abuse. Instead, give them a script that they can run on any Mac or Linux box that takes the root password and IP and provisions their server for them.
I suppose I should make a PR for you; maybe later this weekend