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 Sat, 05 Nov 2011 15:36:51 GMT

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

David Allsopp edited comment on CASSANDRA-2274 at 11/5/11 3:35 PM:
-------------------------------------------------------------------

>From a quick scan through the code, it looks as though we'd need MessagingService (and
possibly JMX) to check the list of IPs or a supplied token, in addition to the existing Thrift
authentication.

Currently it appears that (in the absence of a firewall) there is no security against reading
data from a cluster - the Thrift interface requires authentication, but the MessagingService
doesn't, so I _think_ you can just send Read messages etc to pull data out of a cluster. Is
that right, or is there something I've missed? 

I think we need to be precise about what threat we are trying to defend against, so we can
weight up whether it's worth the effort. For example, does our hypothetical attacker have
root access to a host on the LAN? If so, then presumably they may be able to spoof IP addresses,
completely bypassing any IP checks? What happens if they simply set their IP to the same as
that of one of the genuine nodes? I assume that you can defend against this with a suitably
configured switch/router (with Sticky ARP / Dynamic ARP Inspection), but our scenario here
seems to be that we don't have control over this sort of detail (which makes any kind of security
very difficult).  If our attacker has the same privileges as us, then IP-based checks are
probably OK.

Note also that none of the defences discussed so far would defend against denial-of-service
attacks from an insider on the network (by trying to overload or crash nodes in the cluster).


Physical attacks require physical defences - if untrusted people have access to your hardware
then it's game over.
                
      was (Author: dallsopp):
    From a quick scan through the code, it looks as though we'd need MessagingService (and
possibly JMX) to check the list of IPs or a supplied token, in addition to the existing Thrift
authentication.

Currently it appears that (in the absence of a firewall) there is no security against reading
data from a cluster - the Thrift interface requires authentication, but the MessagingService
doesn't, so I _think_ you can just send Read messages etc to pull data out of a cluster. Is
that right, or is there something I've missed? 

I think we need to be precise about what threat we are trying to defend against, so we can
weight up whether it's worth the effort. For example, does our hypothetical attacker have
root access to a host on the LAN? If so, then presumably they may be able to spoof IP addresses,
completely bypassing any IP checks? What happens if they simply set their IP to the same as
that of one of the genuine nodes? I assume that you can defend against this with a suitably
confgured router, but our scenario here seems to be that we don't have control over this sort
of detail (which makes any kind of security very difficult).  If our attacker has the same
privileges as us, then IP-based checks are probably OK.

Note also that none of the defences discussed so far would defend against denial-of-service
attacks from an insider on the network (by trying to overload or crash nodes in the cluster).


Physical attacks require physical defences - if untrusted people have access to your hardware
then it's game over.
                  
> 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