I think I would suggest all of the subnets you mentioned (10.0.0.0/8, etc) _in addition to_ the local subnets of the local net interfaces.
Would be good to make sure there's consensus on this, though. -Todd On Mon, May 1, 2017 at 11:35 AM, Hao Hao <[email protected]> wrote: > 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 > > > -- Todd Lipcon Software Engineer, Cloudera
