Thanks Todd! If I understand you correctly, you are suggestion besides local subnets(127.0.0.0/8), instead of providing default trusted non-routed subnets(10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 <http://127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16>, etc.), only 'includes the full local subnets of any local network interfaces' to avoid extra configuration?
Best, Hao On Wed, Apr 26, 2017 at 2:46 PM, Todd Lipcon <[email protected]> wrote: > 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 >
