[ 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