Re: [Gluster-devel] Attackers hitting vulnerable HDFS installations
> It is true default glusterfs installation is too open. A simple > solution would be to introduce an access control, either by > IP whitelist, or better by shared secret. > > The obvious problem is that it breaks updates. At least peer > know each others and could agree on automatically creating > a shared secret if it is missing, but we need to break clients. > The annoyance can be mitigated with an helpful message on mount > failure, in the log and on stdout such as "please copy > /etc/glusterd/secret from a server" You're correct that the management path is pretty easy. We have TLS support; we should use it. To facilitate testing, we should ship with a default set of certs/keys. For real use, we should provide a tool to generate new certs/keys on the first machine, which will be propagated to other servers as part of the "peer probe" process. That should be only a minor inconvenience, and drastically reduces our attack surface for the management path. For the I/O path, we run into the problem of managing keys or certificates on many clients, across many platforms. There's probably no solution that provides any respectable degree of security without some inconvenience, but we should probably try to shift away from having *no access control whatsoever* by default. That's only convenient until a hacker comes along. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Attackers hitting vulnerable HDFS installations
On Fri, Feb 10, 2017 at 08:30:40AM -0500, Ira Cooper wrote: > But I suspect... You got it right, Gluster isn't big enough to attack today. It is just a matter of time. -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Attackers hitting vulnerable HDFS installations
Honestly: >From what I know of Gluster, and my experience with Samba. If they target Gluster, you are going to get pwned. HARD. Many, many, many, many times. Trust me... On the Samba Team, we try to avoid security issues VERY actively, and we still get a few here and there. You can walk up to a gluster brick today with no auth... and goto town, never mind any of the "standard" attack vectors, like buffer overflows, bad data, etc. I'd like to believe I'm wrong. I want to be PROVEN wrong. But I suspect... You got it right, Gluster isn't big enough to attack today. ... I want to be proven wrong! -Ira - Original Message - > (warning, slightly offensive language) > > https://www.theregister.co.uk/2017/02/09/hadoop_clusters_fked/ > > Similar attacks have occurred against MongoDB and ElasticSearch. How long > before they target us? How will we do? > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Attackers hitting vulnerable HDFS installations
On Thu, Feb 09, 2017 at 03:53:52PM -0500, Jeff Darcy wrote: > https://www.theregister.co.uk/2017/02/09/hadoop_clusters_fked/ > Similar attacks have occurred against MongoDB and ElasticSearch. > How long before they target us? How will we do? It is true default glusterfs installation is too open. A simple solution would be to introduce an access control, either by IP whitelist, or better by shared secret. The obvious problem is that it breaks updates. At least peer know each others and could agree on automatically creating a shared secret if it is missing, but we need to break clients. The annoyance can be mitigated with an helpful message on mount failure, in the log and on stdout such as "please copy /etc/glusterd/secret from a server" -- Emmanuel Dreyfus m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
