[Gluster-devel] Attackers hitting vulnerable HDFS installations
jdarcy at redhat.com
Fri Feb 10 13:58:54 UTC 2017
> 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.
More information about the Gluster-devel