Digital Ocean Private Networking Is Not Private
incoherency.co.uk
incoherency.co.uk
What about "Shared Intranet" instead. Why has the word "intranet" fallen out of style? And why use the word private to describe something that is inherently non-private by design?
I actually think the addition of this free inter-droplet channel is amazing (and a potential massive cost saver), but the name sucks.
Having said that, people who are concerned about privacy should always be validating their setups themselves. The maxim of "trust but verify" comes to mind.
[1]: https://en.wikipedia.org/wiki/Private_network
[2]: https://www.digitalocean.com/company/blog/introducing-privat...
[3]: https://www.digitalocean.com/community/tutorials/how-to-set-...
[4]: https://www.digitalocean.com/community/tutorials/how-to-set-...
I never said they weren't "technically correct," I said the name sucked and confused people [0].
They could also just use "Data Center LAN." No confusion there.
It's not completely terrible. It's a private network in the usual sense of the word, in that it isn't part of the Internet.
> Why has the word "intranet" fallen out of style?
'Intranet' has other connotations that don't apply here. Mostly that it's an internal Web.
An example is that a network at starbucks is private to the people at the starbucks, but public in a sense that anyone there can connect.
The first time you set up one of these clusters, you might follow one of Linode or DigitalOcean's handy guides, where they might suggest i.e. a reverse proxy server receiving (and decrypting e.g. HTTPS) inbound traffic, routing it out to multiple worker machines, and a single backend database system. Linode sells dedicated Load Balancers for the front end of exactly this sort of set-up.
These guides almost always fail to mention that the data is observable as cleartext in the internal network. They ought to be reedited with big bold warnings starting that these links ought to be secured. (Can Linode's Load Balancers even secure these links?) Besides other eavesdropping customers, there could potentially be little magic government agency plugs installed -- or the eavesdropping customers could be government security agencies themselves. (Sorry, tinfoil, I know...)
OpenVPN connections are a lightweight, efficient solution. They're also transparent once you change IPs from those of the virtual network interfaces to those of the secure virtual network interfaces. Such a configuration is still non-trivial, though, for someone configuring their VPS via a control panel rather than the command line.
That doesn't mean I don't support the cloud, don't use or don't like the technologies that we have today. I wish I could learn and use all modern services out there.
There are various levels of security needed, depending on a case-to-case scenario. I don't believe any company wilfully would create any kind of problems to any of it's users/clients. There are hosting providers (the PirateBay was using one) who are renowned for resisting subpoenas and what not.
BUT if you need absolute security - for whatever reason - in today's world you start by combining carefully the HARDWARE, you don't even buy ready-made products, then you place the server in a place where is physically safe from discrete eyes and hands. Then we can talk software...
I previously tried using a distributed VPN setup without a single main server; that didn't work out so well however, mostly because the software was somewhat unreliable.
The configuration overhead of OpenVPN on an internal network like this is lunacy. The correct answer is a secure L2 network... a private one.
Your VM vendor has access to your host ram. Encrypting isn't going to protect you from them. The threat model here is other customers, which are trivial to partition. They just didn't do it.
Most cloud providers recommend you configure your firewall rules keeping in mind that other people could be on your internal network connection. This is really a security best-practice anyway.
I think part of the problem is that people confuse DO, who just rent out cheap boxes, with more "full service" cloud providers. DO is partly to blame because they keep marketing themselves as a cloud platform when really they're yet another company who rents out servers with a few extra features.
https://www.digitalocean.com/community/questions/questions-a...
You still have to secure your server, even if it's only communicating over the "private" interface. I usually use this feature for database servers, and lock down the firewall so that only the web servers can communicate with the db servers, and only via the "private" interface.
Granted we're probably now distinguishing between being able to see unencrypted traffic and being able to access ports on a machine. They're both bad, but I'd argue having your DB port exposed to the world is probably worse.
But, in that is a deeper truth: a VPS is a cheaper machine. It becomes "cloud" when you use many machines together. If you're using many machines, you really want intercommunication between those machines to be easy, fast and - yes - reasonably secure.
I just automated the firewall and SSH tunnels/TLS certificates setup to restrict access and encrypt communication between my droplets when necessary.
[1] -- https://rubber.io/
When you call something private, that carries a lot of connotations. To me that distinction that you think is so clear is anything but. While I use Linode they also talk about a private network that I assume their switches are configured in such a way that the data doesn't leak outside of my VMs. That I could ping and connect other linodes needs to be made explicit. Why not call it the "Linode-wide Network" or "Shared DO-only Network"?
Ambiguity is not a good thing when the consequences are high.
The word "private" is kind of in the name, I would have expected it to be private (to my droplets) too.
It's like the whole industry has Stockholm Syndrome or something from decades of vendor abuse.
People, really: private means private. They lied. There's no two ways about it. We didn't misunderstand because we're stupid, we misunderstood because they were cutting corners and being intentionally misleading by using words that have definitions different than the thing that was actually happening.
This isn't new with Digital Ocean. Their contempt for their customers is palpable. A year or two ago I caught them leaking customer data and they made a huge handwavey blog post full of lies about how nothing was leaked.
Don't do business with liars.
Anyone who was using DO's private network for security reasons and complains is just being hypocritical. They don't care about security: if they really cared about security they would spend the time to implement it themselves.
This is deceptive and it shouldn't be acceptable. Maybe you shouldn't be a sysadmin without knowing all this, but I don't know how you learn it without getting burned by it every step upon the way. It's not like the defaults are sensible in most cases.
Mrh, not quite. If you are a relatively new EC2 customer, then you are a VPC customer, which might effectively be your own VLAN.
EC2 has also been this way for ages, but it has also always had security groups. If you open something up on EC2 Classic to 10.0.0.0/0, any other customer within that region will be able to access your services.
Sometimes this is desirable for collaboration sake, but bridging VPCs is probably a better solution.
> I don't know how you learn it without getting burned by it every step upon the way. It's not like the defaults are sensible in most cases.
Welcome to #SysadminLife ;)
I do agree that everyone could be clearer about this, Rackspace, Linode, Digital Ocean, and Amazon. A substantial motivation is to keep your inter-VM traffic off the edge routers.
Except that's not how anyone did it. You could define rules that used a security group as the source. And since every instance belonged to a default security group, locking down access to other machines you owned was quite trivial -- you only added rules to allow access from that default security group. If you wanted to add subnet rules, that was usually limited to special cases you would have to actively think about.
> Welcome to #SysadminLife ;)
> I do agree that everyone could be clearer about this, Rackspace, Linode, Digital Ocean, and Amazon. A substantial motivation is to keep your inter-VM traffic off the edge routers.
My source of issue was with the grandparent blaming people that get burned by it. As long as the only way to learn this stuff is to get burned by it, it's counterintuitive to blame people for getting burned by it. And in this case, there are measure DigitalOcean could take to make things easier on everyone. E.g., configure the droplets to save and restore iptables rules on shutdown/power-on and lock the instances down by default to only have port 22 publicly exposed.
I can affirmatively tell you that more than one of my employers, successful startups several years in, _did_ do this when I started.
Anyway, I don't blame people that get burned by this, very little in hosting is obvious.
That's a great example of why people need skilled ops help. Understanding how one computer connected to a cablemodem works and understanding what happens inside of a datacenter are very different things.
Now we're talking.
It could be posited that anyone who is really concerned with these things will want to protect data in transit, but also won't want to use a hosting service relying upon multi-tenant hypervisors which may be susceptible to exploit.
One has to assume AMZN didn't invent AWS Dedicated Instances just for shits and grins. :)
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedica...
Security is pretty black and white. There are a limited number of people who have reason to look at your data. If people other than those people can see your data, then you aren't secure. Amazon is typically not part of that group.
There have been plenty of POC's of side channel attacks against sharded/virtual infrastructure including retrieval of encryption keys from a co-hosted VM. On top of that you inherit the risk of potential vulnerabilities within the hypervisor itself which could be potentially exploited to execute code on the host or to compromise co-hosted machines.
There is no mode for any virtual infrastructure to give you neither truly private networking (since at best it's going to be on a virtual switch) or a private host for that matter. Unless you control everything including the datacenter it self any true sense of privacy should not be considered, especially not in a virtualized multi-tenant environment.
Not understanding the platforms you choose to use is not an excuse to write something like this article. It's also not an excuse to not understand how to manage the platform(s) you run your services on.
They were caught lying. Why is it important to you to to cover for them?
The "you should have known they were lying because $5 is obviously too cheap to provide the service they are claiming" argument doesn't hold water.
http://en.wikipedia.org/wiki/Private_network
This is purely a case of not knowing industry terminology.
So you have to have a dedicated solution running something comparable to openvswitch in software, or interface with your hardware really fast and really often. Usually the hardware is not really built to be reconfigured constantly every second (or more often).
Once you start adding more than address filtering, you get an explosion of rules. For example in openstack (neutron), it's pretty common to just put a hard limit on the number of entries - otherwise you end up with one vm spawning and suddenly every router has to add another entry for each of the ports to each of the possible 1000s of other vms. And then clean up and keep everything consistent when vms are killed again. It really does get hard beyond the bare basics.
Why is it amazing to you that people take a company's statements at face value? Why blame the user when the other party is actively misleading them to cut corners and reduce costs?
Private: belonging to or for the use of one particular person or group of people only. "all bedrooms have private facilities" synonyms: personal, own, individual, special, exclusive, privately owned "his private plane"
This would fit Digital Ocean's interpretation of private - not accessible to the general public, but accessible to other members.