You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kudu.apache.org by Hao Hao <ha...@cloudera.com> on 2017/05/01 18:35:05 UTC
Re: UI for whitelist unauthenticated connections from public IP address
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 <to...@cloudera.com> 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 <ha...@cloudera.com> 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 <da...@apache.org>
> > 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 <ha...@cloudera.com> 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
>
Re: UI for whitelist unauthenticated connections from public IP address
Posted by Todd Lipcon <to...@cloudera.com>.
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 <ha...@cloudera.com> 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 <to...@cloudera.com> 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 <ha...@cloudera.com> 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 <da...@apache.org>
> > > 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 <ha...@cloudera.com>
> 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