[
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
