The one thing that I think we should consider in addition to the trusted (local) subnets is to also include the full local subnets of any local network interfaces. That is to say, we can iterate over the network interfaces, look at their address and netmask, and include anyone in the same network.
I think this will make it less likely to break existing clusters on upgrade, and less surprising for users during a first installation. For most smaller clusters, like one would start with in a PoC/dev scenario, I'd guess that all of the servers are at least in the same subnet, so this takes away the burden of extra configuration. The additional permissiveness doesn't seem like a big issue for security -- non-routed subnets are typically small and within a single organization. The only time I'm on a subnet that I wouldn't consider trusted is when I bring my laptop to a public wifi or hotel, but in those cases I'm usually on a non-routed 10.x.x.x or 192.168.x.x anyway, in which case it's not really any worse. I think the main goal of this work is to prevent people from being portscanned and attacked "from across the world", not from the mustachioed hipster sitting next to you while you drink your single-origin espresso in your favorite Mission district cafe. -Todd On Wed, Apr 26, 2017 at 12:04 PM, Hao Hao <[email protected]> wrote: > Hi Dan, > > Thanks a lot for your response! Here is my thoughts about your questions > inline. > > * Should we include the link-local block, 169.254.0.0/16? It seems this > is > mostly used for DHCP discovery, so maybe it's not necessary (I think it's > better to be overly restrictive here than overly permissive, given the > security focus). > > It appears to me that link-local address is to allow machines to have an > IP address on a network if they haven't been manually configured or > DHCP services are not available. Therefore, I think link-local block should > also be considered as private network. > > * Do we need to support IPv6 private and loopback blocks? Does Kudu > support IPv6 in general? > > AFAIK, Kudu does not support IPv6 in general. And I think loopback > block (local addresses: 127.0.0.0/8) should be considered as trusted > subnet > by default. > > * Are there subnets we're missing? Is this going to cause a lot of undue > pain to users? > > Here you mean are we missing any subnets that should be considered as > trusted > by default, right? I cannot think more than the ones mentioned (private > IPv4/IPv6 address, > loopback address, link-local address). > > One thing to note is that users can always config the 'trusted-subnets' > flag > to > add more subnets in case we miss some. It does not seem to be a huge pain > to users from my perspective. But maybe others have more thoughts on this? > > Best, > Hao > > On Wed, Apr 26, 2017 at 11:08 AM, Dan Burkert <[email protected]> > wrote: > > > Hi Hao, > > > > First off, thanks for working on this. I think it's crucial to avoid the > > bad reactions that a lot of other databases have been getting recently. > > Secure by Default! > > > > I like the idea of a 'trusted-subnets' flag, which defaults to the > private > > and loopback address blocks. E.g. something along the lines of: > > > > DEFINE_string(trusted_subnets, " > > 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16", > > "Trusted subnetworks. Connections originating from outside > of > > these " > > "networks must be authenticated, even if authentication is > > not " > > "otherwise required (e.g. --rpc-authentication=disabled)." > > > > I do have a couple of questions: > > > > * Should we include the link-local block, 169.254.0.0/16? It seems this > > is > > mostly used for DHCP discovery, so maybe it's not necessary (I think it's > > better to be overly restrictive here than overly permissive, given the > > security focus). > > > > * Do we need to support IPv6 private and loopback blocks? Does Kudu > > support IPv6 in general? > > > > * Are there subnets we're missing? Is this going to cause a lot of undue > > pain to users? > > > > - Dan > > > > On Tue, Apr 25, 2017 at 5:23 PM, Hao Hao <[email protected]> wrote: > > > > > Hi everyone, > > > > > > In the work of refusing from publicly routable IP addresses > (KUDU-1875), > > it > > > would be useful to > > > provide users a way to whitelist any 'trusted' but publicly IP address. > > So > > > that unauthenticated > > > connections coming from those public IP addresses will not be rejected. > > > > > > One way I am proposing here, is to provide a Gflag that can take a list > > of > > > subnet (in CIDR notation). > > > And consider those subnet as trusted and do not refuse any > > unauthenticated > > > connections. > > > > > > Please let me know your thoughts or if you have any alternatives in > mind. > > > Thanks a lot! > > > > > > Best, > > > Hao > > > > > > -- Todd Lipcon Software Engineer, Cloudera
