cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Allsopp (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-2274) Restrict Cassandra cluster node joins to a list of named hosts
Date Mon, 24 Oct 2011 20:42:32 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134465#comment-13134465
] 

David Allsopp edited comment on CASSANDRA-2274 at 10/24/11 8:41 PM:
--------------------------------------------------------------------

OK, I understand now!

Just a few things to clarify my understanding:

As far as I can see from the docs online, the Cassandra authentication is configured on a
per-node basis, and is used to control Thrift/CQL client access, but not inter-node messages
(hence it is possible to add a rogue node as you describe above)?

Once this new node starts accepting data, its SSTables will presumably be accessible to the
attacker, and the subset of data held on that node could then be extracted without any userid
and password? And, given plenty of time, and assuming nobody is paying attention to nodetool
etc, one could move this node around the ring to get a sampling of the data from around the
keyspace.

Finally, if the rogue node is queried via Thrift/CQL, presumably it won't be configured to
require any userid/password. When it passes on queries for rows held on other nodes, will
those nodes require credentials as if the rogue node were a client contacting them directly?
Or would these inter-node queries bypass the authentication? If the former, how does that
work, since the authentication is configured (I think) separately on each client, so the credentials
coudl be different? If the latter, then the rogue node bypasses all authentication.
                
      was (Author: dallsopp):
    OK, I understand now!

Just a few things to clarify my understanding:

If I understand right, the Cassandra authentication is configured on a per-node basis (or
so it appears from the docs I can find online), and is used to control Thrift/CQL client access,
but not inter-node messages (hence it is possible to add a rogue node as you describe above).

Once this new node starts accepting data, its SSTables will presumably be accessible to the
attacker, and the subset of data held on that node could then be extracted without any userid
and password? And, given plenty of time, and assuming nobody is paying attention to nodetool
etc, one could move this node around the ring to get a sampling of the data from around the
keyspace.

Finally, if the rogue node is queried via Thrift/CQL, presumably it won't be configured to
require any userid/password. When it passes on queries for rows held on other nodes, will
those nodes require credentials as if the rogue node were a client contacting them directly?
Or would these inter-node queries bypass the authentication? If the former, how does that
work, since the authentication is configured (I think) separately on each client, so the credentials
coudl be different? If the latter, then the rogue node bypasses all authentication.
                  
> Restrict Cassandra cluster node joins to a list of named hosts
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-2274
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2274
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.7.2
>         Environment: All
>            Reporter: Andrew Schiefelbein
>
> Because firewalls and employees are not infallible it would be nice to restrict the ability
of any node to join a cluster to a list of named hosts in the configuration so that someone
would be unable to start a node and replicate all the data locally.  I understand that in
order to do this the person must know the seed servers and the cluster name and to extract
the data they will need a userid and password but another level of security would be to force
them to execute any brute force attack from a locked down server instead of replicating all
the data locally.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message