6 ms·

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-r

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.

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.