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

David Allsopp commented on CASSANDRA-2274:
------------------------------------------

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

        

Reply via email to