I made my own VPN server in 15 minutes
techcrunch.com
techcrunch.com
It is a 100% open source front end for OpenVPN.
It has one of the slickest interfaces in open source history, and supports numerous features you'd expect from enterprise VPN solutions (SSO, 2FA, etc).
I see "less code" used to mean that the solution has been distilled down to the essentials without fluff. For example, no need to write a full-featured JSON parsing library when a simple decode-to-native-dictionary will do. I don't have a good example for VPN-related code.
HTTPS, while seen as a liability in case of IPSec and therefore avoided, is actually good for OVPN. OpenVPN traffic, if set to tcp/443, can pass off as HTTPS traffic, in most cases (except for DPI). I've had problems with IPSec since it operates at a different layer and sticks out like a sore thumb. In environments where the network manager doesn't appreciate VPNs, IPSec is useless.
Better security is important, but not when it comes at a steep cost of not being able to use it when one needs it the most, a not-so-friendly network.
While I'm sure these exists, I'm using VPN on EC2 micro instance (installed with http://github.com/jlund/streisand) and haven't been blocked, yet.
This has big implications if you are trying to move some of your corporate edge to “the cloud”, or even your personal edge.
AWS needs to procure and curate a group of IPs to be used for this class of use case, ensure the services that the big brands subscribe to for their web firewalls are not blocking these IPs (very like curating IPs on anti-spam blocklists for SMTP/MX).
1. Make it available only to Fortune 500s or AWS accounts with a monthly spent >$X million; heavy penalties and even legal action for anyone caught spamming. This way the IP range stays clean, but is out of reach for little guys like us trying run an VPN edge.
2. Make it available to everyone. But then spammers will farm AWS accounts and abuse the clean IP range until it is banned just like any other AWS IP range.
But I guess it is worth it to try out smaller hosting providers, or even self-host. I did consider a Raspberry Pi at my parents home (they live in a different country).
So your recourse is to hope who ever you chose as your provider isn't big enough to get their IP block blacklisted. A great way to check is to stream Netflix using the IP address.
Honestly, it frightens me how many people run their own servers without monitoring, security precautions, keep patches up to date, etc. And all the save a few $. Even if you can do it professionally, you probably shouldn't do it as a hobby. The idea of a transient / throwaway instance is more appealing but I still think most people will fire it up, leave it running, forget about, and not notice when it's been compromised.
But those botnets have got to live somewhere, I suppose
In general, the configuration is so minimal, so hardened, and intended to be ephemeral that updates are rendered somewhat moot. For example, StrongSwan is highly modular and we only enable precisely the extensions needed for it to operate in the _single_ configuration we offer. That extremely limited functionality is then constrained by both custom cgroups and AppArmor policies. So, you might find an issue in StrongSwan, but it's unlikely to affect this configuration of it.
If you have any issues, our recommendation is typically to just rollover the server every once in a while and deploy a new one. Or just check that box during install for automated updates.
As for why it's not turned on for everyone: turning on automated updates will literally lock up certain VPS's if too many updates are sent down at once. We have observed this problem, repeatedly, on 512mb VPS's. Second, kind of remote, risk is backdoored patches. In many cases, I'd just rather deploy software on my server and lock it in stone at the point of its creation, especially if I know I'm going to trash it in 1 month anyway.
Anyway, the best thing you can do is to make some friends or have family in other country and setup your vpm in their home. This way you can have more privacy and yet not being blocked by governments nor bot-checking software (such as what happens with ec2)
what's risky about openvpn? (or tor, for that matter)
In seriousness though, the author is not a infosec expert so I would take the advice with a grain of salt.
Seems he was correct: https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...
Also, he's a business school grad. But you taking infosec advice from one is none of my business.
dont forget to downvote this one too on your way out.
Second, yes, we moved certificate generation to the client and delete keys by default after we generate them to avoid this issue entirely: https://github.com/trailofbits/algo/pull/169
1) When I use MacOS with an Algo connect on demand profile, does there exist a time before connected to the VPN when non-encrypted data leaks?
2) What's the best procedure for security updates on the VPN server? Are automatic security updates enabled? If not, maybe it would be an option to consider when configuring a server?
3) Any plans to integrate with Vultr's API for their $2.50/m VPS?
2) If you choose the option for "enhanced security" during the install process then you get automated updates turned on. We have seen issues where automated updates will brick VPS servers on DigitalOcean and other VPS providers. Considering the extreme lengths we went to in reducing attack surface and disabling features, hardening what remained, for example, with AppArmor, and the intention of Algo to exist ephemerally, we think automated updates are generally not necessary. We investigated a custom binary distribution of strongswan with new exploit mitigations to make this issue even MORE far fetched but that proved a bridge too far (see here: https://blog.trailofbits.com/2017/02/20/the-challenges-of-de...).
3) You can use the local deployment option to run on Vultr. You should be able to follow the docs as typical. Several people have tried to get it going on via the API here: https://github.com/trailofbits/algo/issues/488. In general, I do not add support for new hosting providers unless I have reasonable confidence in their security, ie. they have a staff of security engineers that I can verify on LinkedIn. Also, an Ansible module exists for the VPS provider. Vultr is lacking those things.
While I agree that third party VPN providers are not necessarily to be trusted, if they are deleting their logs as some claim they do, then no one knows which traffic is yours. Your privacy is protected from end to end only in this case.
On the other hand, your lonely AWS instance is a drop in the sea of Amazon vast traffic. Amazon has plenty of other valuable assets and revenue streams that would be more interesting than traffic logs. Nor has Amazon a reason to analyze outbound traffic for each of their millions and millions of instances.
Of course, if someone is actually tracking you, identifies your instance and has the capability to collect and filter outbound AWS traffic leaving your instance, this approach is not valid.
Then again, if someone like this is tracking you, VPNs are probably the least of your worries...
Exactly. They'll either be malicious themselves or have a pile of secrets in one place increasing the odds that those who come a hackin' have more skill and dedication than average. I also haven't seen evidence that they're great at securing systems on average. That could be a sampling error but lots of security suppliers aren't that secure. A well-vetted, open solution that can be deployed on user-controlled hardware or VM's is more trustworthy.
Total costs for me $3.50 for VPS and one evening.
A disposable VPN with a fresh external IP every time would go a long way towards mitigating that.
l2tp makes authentication palatable.
This was my issue. They didn't just werk and the relevant docs are _awful_ (though not your fault).
Then you can use these instructions then: https://github.com/trailofbits/algo#ubuntu-server-1604-examp...
If you need to truly operate anonymously it comes with an enormous amount of preparation and opsec. You originating IP should not be one that is associated with you. You definitely shouldn't be paying for hosting with a credit card in your name.
How do you know this for a fact?
If this becomes common, won't the ISPs just find a way (blocking ports) to monetize it? Or just outright TOS it out?
Assuming a 10% overhead
http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/
-----
Streisand is no better
Good concept. Poor implementation.
It installs ~40 services, including numerous remote access services, a Tor relay node, and out-of-date software. It leaves you with dozens of keys to manage and it allows weak crypto.
That’s a hefty footprint and it’s too complicated for any reasonable person to secure. If you set up an individual server just for yourself, you’d never know if or when an attacker compromised it.
I have been shopping for a VPN service the last month, and this looks like the most appealing.
Are you trying to partially anonymize yourself on the internet and download Linux ISOs? Use a provider like PIA. The benefit of those is you're going to (probably) be connected to a node with dozens of others, certain entities would be dissuaded from tracking you, and cease and desist letters stop at PIA and never make it to you, as they don't maintain logs.
If you really want to be anonymous and not be able to be tracked by even governments, TOR is really your only option.
> partially anonymize yourself on the internet and download Linux ISOs...cease and desist letters stop at PIA
You can get cease and desist orders for downloading Linux ISOs?
Also, if you want your public IP to be in a specific country, the cloud providers don't have regions in a lot of the smaller countries where VPN providers have servers. Or perhaps you if you want to jump around periodically (today I want my internet traffic to look like it's coming from Peru, tomorrow France, etc). To do that with VPS, you'd need to provision a bunch of them.
My VPN provider also has a features like nodes that route traffic through TOR or something they call "double VPN" where the VPN server connects to the internet through one of their other VPN servers. These are, perhaps, gimmicky features from a security standpoint, but if they're doing what they claim to and they've been implemented without introducing any vulnerabilities (big if), they could offer protection that would be expensive and complicated to setup yourself.
Can't seem to configure one no matter how much i try.
Probably not! Algo is not made for circumvention, it's made for security. You need to go to the extremes of anti-circumvention tech to get ANYTHING to work in China too. It's not a matter of OpenVPN vs IPSEC. None of them work. Tough problem! I'd love to get funding to work on it though.
At the very least, you'll look nearly exactly like a regular business traveler trying to VPN back to HQ with an Algo setup, so it'll attract less suspicion for that reason alone.