The problem with a home-grown VPN is that you lose some of the plausible deniability that's gained from a shared VPN. If you have a VPN connected to a privately-owned AWS instance, the IP coming from that AWS instance is easily traced back to you. Whereas if your external IP is coming from a cluster that is shared by thousands of other people using that VPN, it is more difficult for someone to tie that specifically back to you.
Define "easily" as used in this context. Easy is a product of whom your enemy is.
Is your enemy your ISP? If that's the case, I don't think it's "easy" for them; they would have to pay Digital Ocean or Amazon to get your data, and probably isn't really that valuable to them.
Is your enemy the MPAA? If that's the case, I still don't think it's particularly "easy" for them. Unless you are a MAJOR pirate distributor, the extra effort(money) to track you down isn't worth it.
Is your enemy the NSA or the FBI? If that's the case, then yes, it's trivially easy for them to Subpoena digital ocean or amazon to get your data, but similarly they can use techniques on PIA to get your data too.
In the end, it comes down to whom you trust with your data. And whether you want a managed VPN service, or are willing to put up with the inherent problems of maintaining your own system. will PIA sell your surfing habits to advertisers, will DO sell your surfing habits to advertisers? Who gives faster speeds?
I agree overall, but PIA has may not be the best example, as they have been shown to not keep any data that could be subpoenaed[1]. One nice thing about running your own (if your client machine is on Linux) is being able to use Wireguard[2], which is quite a bit faster than OpenVPN, for example.
Never heard of Wireguard before, but it looks really cool, especially the mosh-like roaming. However, I found this warning on their website.
WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
Amazon's not in the business of terminating accounts the second a copyright request comes in. They want to build trust with their customers that they won't just turn you off on a whim.
I can vouch for this, from the other side. We routinely catch AWS hosts running password-guessing bots against our login forms. Emailing abuse@amazonaws.com doesn't seem to lead to reductions in our fail2ban and custom tarpit logs.
Claiming someone is brute forcing your logins doesn't have the legal weight of a DMCA notice. Why should they do anything? DMCA provides provisions for counter notice and legal remedies for false filings.
This is always a battle - for big operations you've got people farming out signups using stolen data to random 'buddies' on the other side of the world with the dark hat team ready to stand up outbounding traffic as fast as they can get a processor to execute it on, not to mention the hosts that get cracked automatically..
That's their official response, and rightly so it should be. Talking from experience, I've had many requests for different websites I run and almost all were frivolous. Some content I took down anyways, and some I explained to Amazon why it was frivolous. They've never cancelled any of my services or even threatened to.
Not all hosts are US-based, though; some hosts in other countries prefer to get a court order in their own jurisdiction before taking action against a customer.
This exact thing happened to me on DO; I got an email from them (also automated) telling me to cut it out our have my account terminated. I was traveling overseas and had no other option for watching my shows, so I switched to PIA.
FYI MPAA can and will go after you even for a small site with 100 of visitors daily. They went after me, tried to sue me, got my servers shut down and sent lots of scary emails to my personal email.
It's easy for anyone who can do traffic analysis on your traffic, eg your ISP and mass surveillance perpetrators.
And whoever your ISP decides to sell or give this data to.
They can of course see the individual packets and their exact timings. This can be trivially correlated with egress traffic from your VPN gateway to other ISP affiliated networks or web properties. And since it's your private gateway, there is no other traffic mixed in.
There are use cases that make sense. My home linux router intercepts and sends all DNS and NTP requests, then routes all DNS requests to multiple VPS nodes that in turn, use multiple DNS recursors at each VPS datacenter. I intentionally avoid google and opendns. I override the min-ttl of all requests to avoid some shenanigans and I am well aware of the issues this can cause.
At a minimum, my ISP can not see or tamper with DNS requests. My VPS nodes are multi-purpose so it isn't really extra cost.
This also gives me the capability to intercept some of my traffic and route it over my VPN using a combination of haproxy and squid. I can do this by source PC, or by destination, or protocol, or any combination thereof.
For me, this has worked great for years and gives me a lot more flexibility, options and control over my data flows. If I want more privacy, I can use my existing tc cbq QoS and rate limited rsync's of random noise to hide some traffic patterns.
"At a minimum, my ISP can not see or tamper with DNS requests."
Are you encrypting each DNS packet at the source (e.g. your home recursor/DNS-forwwarder)?
If yes, when are your sent packets decrypted? At the authoritative nameserver, or at some intermediary recursor?
If no, how do you believe that your DNS packets are opaque and tamper resistant?
There are very few authoritative nameservers on the internet that accept and return encrypted DNS packets. Thus third party recursors must send out unencypted DNS packets. Nothing protects these unencrypted packets from being captured, viewed or tampered with.
It sounds more like you are creating a chain of recursors (that you control?) to make tracing the requests more difficult.
If you are using any third party recursors are you concerned about applications you use that implement support for ends-client-subnet extensions?
My home ISP can not see my DNS packets. Those are the adversaries I am defending against specifically. All DNS packets on my home ISP are encapsulated in a VPN to my VPS nodes. I also pre-cache popular requests via cron and via settings in Unbound.
From there, for sure, the risk increases. I am not sure I trust DNSSEC to help me much. That said, I rotate through many local recursors at each location, so they have to rewrite my traffic right as it leaves my node. That is doable, but that isn't really what I am defending against. Anything I care about, I validate in a script and write into /etc/hosts.
You are correct, there are not that many recursors that support TLS.
Beyond that, things like software updates I don't trust DNS at all and certainly not public mirrors. I validate packages with GPG signatures. Even that is tricky, because chicken+egg, so I validate the GPG sigs from trusted sources.
On a funny side note, you would be surprised how many people rely on trusting GPG keys that are contained in a package, signed by those same keys, in the same repo.
DNSSEC doesn't really protect you at all here. The last mile between you and your recursor has no DNSSEC protection at all (DNSSEC is server-to-server). There are a whole bunch of other places to redirect your traffic before and after name resolution. And, of course, DNSSEC offers no privacy whatsoever: any ISP MITM can still see every domain name you're looking up, because DNSSEC is a signing-only protocol.
Pretty clear to me he's running DNS over the VPN, and so yes, 'ISP' referred to 'his immediately upstream ISP', and so yes,
OP is "creating a chain of recursors (that you control?) to make tracing the requests more difficult"
but also, as a result less difficult to tamper with by a less trusted party such as a mass market commercial ISP - tampering with his forwarder would entail either tampering with random many other peoples traffic or compromising the 'percieved as more secure' ISP.
Pretty sure someone mucking around with TTL's on these packets to make sure they don't get too far out of intended range and the numerous other things would be aware of these issues..
Sorry, I do not. I set it up manually. While I do have some scripts, they are custom tailored to my network setup. That said, it's really easy to do.
You could use the other github scripts that folks have linked for setting up the VPN. Then you would want to set up recursive DNS servers on your home router and VPS nodes. Then look into iptables mangle to intercept DNS, NTP, etc. HAProxy L4 vip on the router is an easy way to forward some web traffic to Squid running on multiple VPS nodes. Squid has an intercept mode you can use for any traffic you want to throw at it. Unbound DNS can override min-ttl and allows overriding partial or complete DNS zones for block some shenanigans. Calomel.org has some articles on some of these things.
It's probably even better if you research each step yourself so that adversaries have to work harder to generalize attacks around your configuration.
Exactly. The author says because hosting companies are big they would never give information but this is a complete flaw. Google and Reddit are both known to hand information to law enforcement. Companies like digital ocean don't put as high as emphasis on customer privacy as companies likes PIA. On 90% of the service portals for servers I've purchased have had a message showing my IP was logged for safety reasons. So by making your own vpn you're just turning a direct link to you into link to a link pointing right back at you instead of thousands of people.
People are afraid to file share but not because of GEMA which for once has nothing to do with this. Right holders (especially of popular music, movies, and TV shows) connect to torrents and log who is also in the swarm (i.e. uploading and downloading). They then go to court quickly with your IP which orders your ISP to give up your name and address.
>The problem with a home-grown VPN is that you lose some of the plausible deniability that's gained from a shared VPN.
Yes, but what good is a VPN where you cannot trust your own network? I would have zero trust in any closed source private VPN. There are ways to gain anonymity from your host that wont require setting up a MITM attack vector for your traffic.
I get a lot of value from a VPN that prevents my ISP from spying on my traffic. I see from looking around this conversation that two other people cited this same reason.
I could totally see that many people wouldn't care about this particular thing.
Not just spying either, but if you are in oz at least, keeping all that metadata in a big, juicy, government mandated, and poorly secured bundle for 2 years!
VPN is one layer. Filtering all port 80, only permitting TLS, and aggressively paring down your trusted root cert list can effectively mitigate the MITM threat.
But they are likely to provide IP addresses used to connect to your server. So now you're facing the same problem, if you wanted to hide your IP address.
Are they so likely? Do you mean they keep logs of every attempted connection to every vps? Even in countries like Netherlands? I'd bet that's less likely than keeping a log of their paying customers' names
