I made my own VPN server in 15 minutes(techcrunch.com)
techcrunch.com
I made my own VPN server in 15 minutes
https://techcrunch.com/2017/04/09/how-i-made-my-own-vpn-server-in-15-minutes/
96 comments
Clearly written by someone who has never tried to browse the internet from an AWS instance. A lot sites block you thinking you're a bot.
Hi, author here. We support a diversity of different hosting providers (Google, Azure, DigitalOcean, AWS), including your own self-hosted server. It's an install script, we don't pick the host for you, that's your decision.
Have you also tested on Vultr and Linode?
Could you give some examples?
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.
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.
Grab the Alexa Top 10,000 list and curl them. You’ll be amazed at the big brand names that block you.
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).
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).
The idea of a "clean" IP range is great, but it won't help little guys like us. Amazon can either:
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.
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.
https://voip.ms blocks access from AWS IP ranges. It's a shame because they're a one of the best VoIP providers I've ever used.
I'm not sure what you're looking for in terms of examples, but I've had external tests for scraping code on different sites. We had to slowly disable tests that were failing because the sites were testing the request with a reCAPTCHA.
The same is true for DO as well. Sites, maybe rightfully, are super suspicious of traffic originating from their ranges. So many captchas.
Last month Netflix blocked my Linode VPN from accessing local content, it took them surprisingly long.
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).
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).
Try a small VPS provider in your area. There are many boutique ones. ARP Networks in Los Angeles is one I've used and it's ranges seem clean. Tried DO and Vultr and got captcha hell.
What's the proper solution to this if you need to run a legitimate service? (I'm in this spot where I'm trying to verify if old links in emails are still correct).
Move to an obscure provider? Many services block IP blocks based on registration not on prior malice.
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.
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.
Recently was traveling and was expecting to use unknown wifi at hotels, so tried to install Algo. After wasting hours on trying to set it up on Centos 7 (who reads the docs that it's not supported? -- was confused by one of the pages in wiki), I got it up and running within an hour on Ubuntu (why hour?
had to disable whatever I don't need, setup fail2ban, firewall and other essentials). Configured users, setup their phones, tablets and laptops to always connect to VPN when on wifi other than home one. It worked flawlessly for the whole trip.
Total costs for me $3.50 for VPS and one evening.
Total costs for me $3.50 for VPS and one evening.
Will this work for me in China when the Chinese ISPs ban VPN in the next year?
Hi! Author of Algo here.
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.
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.
It uses IPSEC, so depending on the Chinese authorities, maybe or maybe not. Keep in mind it's the same protocol that is used by foreigners to VPN back into their offices, so if they're willing to annoy them, it probably won't work.
better try to use something that hides itself as https traffic; or hard to distinguish from regular https traffic
Great piece for showcasing the security and practical uses of a VPN, but I feel it's skimps on the best reason, which is privacy. Using a hosting provider with your VPN will allow the provider (eg Amazon) to see all traffic leaving your server. Even if you're using https, they can gather domain information. If you are the only one using the VPN, then all the traffic leaving the server is yours.
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.
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.
While this is true, I have the feel that third party VPN companies would be more interesting targets for intrusions, both from private and state-backed actors. Also, VPN-company traffic logs could be a tempting asset to sell or steal.
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...
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...
"While this is true, I have the feel that third party VPN companies would be more interesting targets for intrusions, both from private and state-backed actors. Also, VPN-company traffic logs could be a tempting asset to sell or steal."
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.
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.
> Does not install Tor, OpenVPN, or other risky servers
what's risky about openvpn? (or tor, for that matter)
what's risky about openvpn? (or tor, for that matter)
I would like to know this as well. Why is OpenVPN risky?
the algo faq gave sort of an answer: https://github.com/trailofbits/algo/blob/master/docs/faq.md#...
this mostly points to bad defaults and openssl being problems, which I don't see as problems with openvpn itself. I do agree it's a pain that there isn't a multi-platform client maintained by the project.
its Open, duh.
In seriousness though, the author is not a infosec expert so I would take the advice with a grain of salt.
In seriousness though, the author is not a infosec expert so I would take the advice with a grain of salt.
you are very wrong about this; dan is most certainly an infosec expert and I take his recommendation not to use openvpn seriously.
Seems he was correct: https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...
Seems he was correct: https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...
the linked audit does reveal a DoS vuln that was patched, but I wouldn't discredit the project based on something so small. audits are a good thing for a project.
^ what he said.
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.
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.
[deleted]
Has the issue of a VPS operator being able to MITM your TLS connections been fixed?
https://twitter.com/FiloSottile/status/808355117011521537
https://twitter.com/FiloSottile/status/808355117011521537
Hi, author here. First, that issue was way overblown (it's exactly what streisand does, and assumes an attacker with local access to your VPN server... which means you are already wayyyy owned).
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
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
Hey Dan, thanks for the clarification! As a non-security professional, I'm always unsure what to think when I hear two people I deeply respect (you and Filippo) clash over an issue. I have a couple more questions about Algo:
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?
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?
1) Kind of (more details in the link below). You need a supervised profile on iOS in order to ensure that _every_single_packet_ gets sent over the VPN. Only large enterprises configure their devices this way and it requires wiping your device clean in order to install the profile, so we don't do it. On-demand is the 99.9% solution with the best balance of ease of use and security (allowing things like local network access, AirPrint, etc). You can find more info here: https://github.com/trailofbits/algo/issues/278
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.
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.
Thanks, I really appreciate this! :)
Is there any reason not to do this and use a provider instead?
I have been shopping for a VPN service the last month, and this looks like the most appealing.
I have been shopping for a VPN service the last month, and this looks like the most appealing.
Bandwidth cost? Uploading a TB of VPN'd data would cost you $90 on AWS and a bit more on GCP. There are VPN providers that will let you do that for under $5/mo.
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.
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.
It depends on your threat model. Are you just wanting to get around your ISP selling your personal data and (in the future) slowing down your internet to certain sites? Host a VPS at DO or Linode or AWS (though you'll look a lot like a bot). This way is also useful for hosting things at your house, but have them look and act as if they are hosted in your provider's DC.
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.
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.
Mostly I just want to get around ISP tracking. In that case I might just look into this solution and host on AWS.
> 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?
> 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?
Hi! Author of Algo here. You can read the full information about why we think a self-hosted VPN is better than a VPN service here: https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-th...
See my comment above, it's a tradeoff depending on if you trust the host provider or the VPN provider more really.
Do you want anonymity, because then you probably want a VPN service. All the traffic from your personal VPN is tied to your instance which is owned by you. The traffic isn't being merged with anyone else.
If you want anonymity, you use Tor.
Depends if you need a VPN Service integrated into your own AS or not.
"but I know they won’t sell my hosting data to third-party advertisers and scammers"
How do you know this for a fact?
How do you know this for a fact?
You can setup your own on AWS in 10 minutes for free 1st year. https://www.webdigi.co.uk/blog/2015/how-to-setup-your-own-pr...
I really don't feel like auditing this entire install script (https://s3.amazonaws.com/webdigi/VPN/Unified-Cloud-Formation...) but a quick glance leaves a lot to be desired. Weak authentication and crypto, lack of isolation mechanisms, etc. You're much better off with Algo, and it'll take the same amount of time to get it going.
The idea of "disposable" VPN's is attractive. I've noticed a huge uptick recently in the number of sites that are blocking me when I'm on a VPN, presumably because the shared server has been used by some other subscriber to cause trouble and get the server blacklisted.
A disposable VPN with a fresh external IP every time would go a long way towards mitigating that.
A disposable VPN with a fresh external IP every time would go a long way towards mitigating that.
What does this cost per month for someone who uses, say, 200GB per month?
If this becomes common, won't the ISPs just find a way (blocking ports) to monetize it? Or just outright TOS it out?
If this becomes common, won't the ISPs just find a way (blocking ports) to monetize it? Or just outright TOS it out?
digitalocean charge $5/mo for 1TB. Downloading 200GB will cost you just over 440GB of your 1TB limit
Assuming a 10% overhead
http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/
Assuming a 10% overhead
http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/
Probably not since they would anger a lot of corporate users.
I was expecting to read that somehow he wrote the software in few lines of code.
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)
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)
Has anyone ever gotten strongSwan clients (or IPSec VPNs in general) working on not-Ubuntu? It's poorly documented and pretty shit in general, it was a huge headache and I gave up on algo after several hours of trying to get it working.
Hi, author here. Yes! IPSEC works great in most of the major client platforms. All the information to set them up is documented in the Algo readme: https://github.com/trailofbits/algo#configure-the-vpn-client...
You might want to specify that you are the author of algo, otherwise people might assume you are the author of the article.
>These will require customization based on your exact use case.
This was my issue. They didn't just werk and the relevant docs are _awful_ (though not your fault).
This was my issue. They didn't just werk and the relevant docs are _awful_ (though not your fault).
What platform? We test on every current major client platform (macOS 10.12, Windows 10, Ubuntu 17.04, iOS 10, Android 7, etc.)
Arch Linux.
The Ubuntu instructions will work fine! We have many Arch users. You need to check the Y box for "Linux Network Manager support" during install. Make sure you're using a current version of Arch.
Network Manager as in the dbus driven sack of crap whose VPNs can only be configured through an Xembed GUI? I don't want to use that. I want to write a config in /etc and enable a unit and never think about it again.
hahah same!
Then you can use these instructions then: https://github.com/trailofbits/algo#ubuntu-server-1604-examp...
Then you can use these instructions then: https://github.com/trailofbits/algo#ubuntu-server-1604-examp...
yeah, a lot of work for little payoff.
l2tp makes authentication palatable.
l2tp makes authentication palatable.
I wish more people knew about Pritunl: https://pritunl.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).
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).
Author of Algo here: Pritunl looks great, but Algo aims to use less code to get the job done. Less code = less that can go wrong. We reduced the attack surface to a minimum, don't support out of date clients or crypto, and turned up operating system level hardening to the max. Our goal is to provide the most secure VPN hosting possible with standard clients and tools. Pritunl looks like it optimizes for different goals, and as a result, introduces a lot of additional failure points that I'm not comfortable with. It's certainly the right choice for some people though!
While less code = less possibility of mistakes, there are more factors at play. OpenVPN is often the best choice for most people, especially people who don't know what they are doing (who else needs a front end).
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.
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.
I'm not saying one should go for the 'easy' security, because if OpenVPN is not sufficient for their needs, they shouldn't be using a VPN in the first place.
When you write "less code" I see "less readable" and therefore "less maintainable" and more that can go wrong. Less code should not be the goal.
Less code can also be the consequence of having less superfluous features.
Code is a liability.
Having a dead code base in 3 years because the author left and nobody else wants to decipher it and contribute back is a bigger liability.
The irony here is OpenVPN's code is terrible, unmaintainable and verbose while strongSwan is much better maintained. (OpenBSD's IPSec stack is on another level)
Don't confuse "less code" with "fewer characters and/or lines." Sure, you can write "less code" by implementing trickery in compact bitwise C operators (or, $DEITY forbid, writing a Perl one-liner.) But I've never seen the phrase "less code" to describe that situation.
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.
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.
I've never seen the phrase "less code" used as a benefit to describe a code base as a benefit so something along the lines of an eye gouging Perl one-liner is what comes to mind. Using some existing module or library rather than building your own from scratch is absolutely something I would agree with.
[deleted]
Congratulations! You've now secured your connection — now you have a server to secure.
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
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
Hi! Author of Algo here. The beauty of Algo is that it takes care of all the server security for you, including deleting the keys used to access it if you want. There's nothing additional to secure after you install the server. Try it out! The server has no extra services, everything is AppArmor'd, and all unnecessary features are removed.
Does algo auto update?
Yes, we offer the option to turn those on during the install. It's one of only about 5 questions we ask.
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.
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.
what level of anonymity do VPNs provide from determined adversaries ? An adversary can trace a IP connection to the requesting VPN and then he could subpoena the infrastructure provider -- be it AWS or DO or a datacenter for their clients using that IP address . If the expected payout is large enough, adversary could deploy more resources to collect this data and sue the VPN User.
You shouldn't be using a VPN for anonymity. You should be using it to protect your traffic from ISP and to hide your personally associated IP from tracking. It moves your trust from your ISP to your hosting provider. If you need anonymity, there are tools for that, but their usage costs are high.
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.
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.
Maybe change the title from "made" to "setup", I thought this was about writing VPN server software. This is actually a lot less interesting.
Is there any manual for SSTP vpns?
Can't seem to configure one no matter how much i try.
Can't seem to configure one no matter how much i try.
Why not this script https://github.com/jlund/streisand ?
That's described in detail in this blog post on Algo: https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-th...
-----
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.
-----
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.