3 ms·

This is a complete non-issue; anyone really concerned with privacy wouldn't rely on DO's security. Anyone who was using DO's private network for security reaso

This is a complete non-issue; anyone really concerned with privacy wouldn't rely on DO's security. 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.

nirvdrum 12y ago
You may as well written "anyone really concerned with privacy wouldn't use a VPS." You don't have to outsource security to screw this up. You're given a non-routable IP. It's called "private networking". And you've just been sold on moving from EC2, where you're effectively on your own VLAN. It's very easy to mess this up. And adding a firewall rule doesn't work because you probably added the subnet anyway. Even if you were diligent enough to detect that, you'd have to propagate rules per droplet every time a new droplet is created or another destroyed (wouldn't want a new account to get your old IP). Doing that in a fault-tolerant way can be a lot of fun. Oh, and your iptables rules look great, but Ubuntu won't restore them for you upon reboot. So even more chances to mess up. 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.
- justizin 12y ago
  > And you've just been sold on moving from EC2, where you're effectively on your own VLAN. 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.
  - nirvdrum 12y ago
    > 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. 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.
    - justizin 12y ago
      > Except that's not how anyone did it. 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.
- copsarebastards 12y ago
  > anyone really concerned with privacy wouldn't use a VPS. Now we're talking.
nixgeek 12y ago
Security and privacy aren't black and white topics, they're shades of grey, with the exact shade depending on your specific personal or business requirements and appetite to risk. 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/dedicated-instance.html http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedica...
- copsarebastards 12y ago
  Amazon didn't invent AWS Dedicated Instances for security, they invented them for money. Now they can sell services to people who, for example, fall under HIPAA. And often those people don't care about security either--they just care about complying with regulation so they can do business. 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.

nirvdrum 12y ago

You may as well written "anyone really concerned with privacy wouldn't use a VPS." You don't have to outsource security to screw this up. You're given a non-routable IP. It's called "private networking". And you've just been sold on moving from EC2, where you're effectively on your own VLAN. It's very easy to mess this up. And adding a firewall rule doesn't work because you probably added the subnet anyway. Even if you were diligent enough to detect that, you'd have to propagate rules per droplet every time a new droplet is created or another destroyed (wouldn't want a new account to get your old IP). Doing that in a fault-tolerant way can be a lot of fun. Oh, and your iptables rules look great, but Ubuntu won't restore them for you upon reboot. So even more chances to mess up. 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.

justizin 12y ago
> And you've just been sold on moving from EC2, where you're effectively on your own VLAN. 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.
- nirvdrum 12y ago
  > 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. 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.
  - justizin 12y ago
    > Except that's not how anyone did it. 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.
copsarebastards 12y ago
> anyone really concerned with privacy wouldn't use a VPS. Now we're talking.

nixgeek 12y ago

Security and privacy aren't black and white topics, they're shades of grey, with the exact shade depending on your specific personal or business requirements and appetite to risk. 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/dedicated-instance.html http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedica...

copsarebastards 12y ago
Amazon didn't invent AWS Dedicated Instances for security, they invented them for money. Now they can sell services to people who, for example, fall under HIPAA. And often those people don't care about security either--they just care about complying with regulation so they can do business. 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.